From Discovery to Execution: The Ways of Working Journey

Scenario

What we deliver

The built Cobalt library (@Cobalt Design System) offers around 70+ components and 1400+ assets, distributed in 7 libraries for more than 50 designers from different parts of the world.Many engineers use 90+ repositories and have access to the Atomic Component Library and the community-built Marketplace Component Library used by 50+ shared repositories. In this shared library there is a contribution process that was created and documented so that anyone can actively collaborate with the ecosystem within Cobalt.

How we document

Guidelines were reviewed and documented on more than 150 pages using the Zeroheight tool. In addition to the structure documentation, tokens, and assets, a page was provided for each component and pattern with specific tabs for Design, Code, Accessibility, and Content.

To promote the productivity and efficiency of product teams, processes, tips, and best practices were also documented and shared in live sessions with designers. The recording was available later in the format of short pills, called Cobalt Tips.

The Ops team was responsible for planning the content, presenting it to the designers and later making the necessary cuts. Also, we provided the documentation for consulting.

How we communicate

We used Slack to communicate component updates, documentation, and any other topics. Live sessions were also held to share why and how some decisions were made or to provide knowledge about processes and other topics.We had weekly Ops team meetings to align release expectations, routine sync, fortnightly interviews with the community (design/devs), and biweekly sharing to report highlights and challenges with external designers, among others as team feedback (retro ceremonies).As team leader, I also indicated the team's main achievements to the Product, Engineering, and Design leadership with other company stakeholders to bring more visibility to Ops initiatives.The team also compiled support data such as bug openings, interactions in Slack channels to address questions, and DMs with specific questions, among others.

How we review

Every designer could submit their layout/project for a design review by our team. So we evaluated several topics such as:

• Context/Writing

• Accessibility

• Components and Guidelines

• Product and consistency

• Opportunities

After defining the process with a product agilist, an automation was created where any designer could add a new task and it would go straight to the backlog of our Ops team within Jira. Thus, in this process it was possible to indicate the subject and description of the need and indicate which category it was:

• Bug

• Revision

• Support

• Design

• Writing

How we support

We had a dedicated Slack channel to support the community by providing visibility into issues and actions, and also a consistency-focused channel for general application questions. Sessions could be held with the applicant and/or their team to better understand the problem and co-create solutions.We also supported, as much as possible, general questions from designers directly in Figma, and, when necessary, we indicated that a ticket should be created in Jira so that it was possible to prioritize and better account for the support provided.

How we discover

Definition and Search

After choosing a problem based on what was already defined within the initiative backlog and expected roadmap, it was then prioritized as a Discovery task. When starting this task, it was necessary first of all to do an initial exploration of internal documentation that may have already addressed or at least mentioned something related to the identified problem.

Then, a mapping of use cases and external references that could be useful to obtain a more detailed view of the whole was carried out. When necessary, it was also possible to hold meetings with specific product teams to collect more evidence about the problem and/or insights into the context of use. Therefore, it could also be interesting to explore the product journey and roadmap to seek even more history of how this problem has impacted teams, as well as analyze any product data and compile this before thinking about any final solution.

Ideation and proposal

A review of everything that was collected in the previous stage was carried out and ideas came naturally from this exercise. Thus, a proposal was made with one or more options that could solve the given problem in question, and with this it would be necessary to present and share with other designers (and developers, when necessary) in a critique or workshop format to validate whether the proposed solutions would work and cover all the main cases of the products.

These validation ceremonies were planned by the Ops team and a selection was made to define which people to call based on Discovery's context and objective. In any case, ideally, it has always been a suggested recommendation to call at least 5 people from different product teams to have greater scope in the debate and greater coverage of possible unforeseen use cases.

Validation and documentation

Once the solution was positively validated by the guests, the content presented was then documented in a simplified way so that it could be included as a deliverable in a future sprint. Therefore, when starting this task in the future as a deliverable, it would not be necessary to go through Discovery and/or have doubts about how to execute this initiative as the entire raw part had already been validated. This does not mean that it was not possible to carry out even more complementary research, but the main research had already been prepared to facilitate its execution.

However, if the solution suffered constructive criticism and/or was disregarded by the guests, a documentation was made about the points discussed and use cases not considered (example) and Discovery returned to be revised and its cycle was repeated until arriving at a new more complete solution.

Thanks for reading :)