What to do?
Each component has to be well-defined and documented. This helps us keep components consistent across the platform in every known use case.
This process is set up to bring a straightforward checklist to avoid missing any particular part of the flow.
1. Design flow
2. Production flow
3. Final release
It doesn't matter if you add a new or update an existing component. In both cases, you should respect the process and be sure everything is specified and documented.
In case of a component updates, you should always update the existing specification (in the dedicated Figma file) and documentation rather then create a new one.
Design flow
Design flow specifies a continuous process in which the parts follow one another. We recommend respecting the order in which they are built and not skipping any of them. That's the only way you may be sure the final version of the component will meet the expectations.
✍️ Plan
Assignees
- Product Manager, Designer, and Developer
Everyone can propose a candidate for the new component or its update. It doesn't matter if you are a Product Manager, Designer, or Developer; once you see a candidate that fulfills our checklist, you should process it to start to plan.
Output
- Audits, explorations, and scope
As an output of this part, we expect to complete an audit of existing cases in our platform, a mood board with an exploration of the solution other companies or systems use, and, finally, the complete scope of the version you want to build.
This gives us a clear view of complexity and also prepares the ground for future updates once exploration can show some ideas that we can postpone for the needed version.
Objective
- Understand what we want to make, why, and if it's worth it
The main objective of this plan part is to understand what we want to make and to decide if it is worth it. The final scope should always cover most cases we need and consolidate inconsistencies, especially if we rebuild existing components.
The goal is not to bring a version that covers hypothetical cases from the far future that we think can happen. This should be noted as a possible future update but should not affect the estimation.
Activities
The following activities should help you focus on the right path. The first one is mandatory, and you must complete it in every case. The rest are optional, but we recommend them, too, to ensure the highest quality of the final component.
- Audit existing cases and comparative examples (Always)
- Design and/or code explorations (Sometimes)
- Other research (Sometimes)
Please keep in mind that you don't need to complete everything in every case, and it depends on the content of the case and time.
🔍 Design
Assignees
- Product or UI designer
There should always be one dedicated designer who takes care of the output and takes responsibility for delivery.
Output
- Figma concepts, iterated, testing
The expected output is the final version of the design that is tested and also approved by DS Advocates and the Product design team. Only then can you be sure you have completed the whole scope of the version, and it also gives you solid ground for the next step of the process.
Objective
- Fully explore and validate a design solution
As the output says, the final design should be validated, tested, and well-explored. Remember that you want to deliver the best possible solution when you design it.
Activities
The following activities should help you see the scope of the design and following them will provide you deliver the most acurate solution for the component.
- Design multiple variants and concepts (Sometimes)
- Test the design and concepts internally or externally (Sometimes)
- Match accessibility standards and rules (Always)
📝 Specify
Assignees
- UI or Product designer
There should always be one dedicated designer who takes care of the output and takes responsibility for delivery.
Output
- A document that describes how an interface is composed, configured, visually designed, behaves, and more, whether a component, page or something else
The final document must be available to the whole team and stored in a dedicated Figma project. If you update or improve an existing component, you should always use the existing file and specify changes on a new page.
Objective
- Fully documented a design solution
As an outcome of this part has to be a complete design specification the design system developer and designer can take and prepare a final asset for the library.
As a part of the document, there should also be specifications for naming conventions, which should be a source of truth for designers and developers.
Production flow
Production flow is not continuous, and each part can be completed in different time frame. This provides us with flexibility and should help avoid postponing; for example, a dev asset can be delivered sooner than a design asset.
🔴 Design Documentation
Assignees
- UI Designer & Content Designer
There should be always one dedicated content & UI designer who takes care about the output and take the responsibility to delivery.
Output
- Documentation site content
As a final state, there should be a page published on suite.emplifi.io in a particular section that is checked by the content designer and, ideally, by a few design team members.
🔴 Design Asset
Assignees
- Design system Designer
There should always be one dedicated designer who takes care of the output and takes responsibility for delivery.
Output
- Figma assets published in the library
As an outcome, a dessign asset will be placed in our library and publishet to be availabel for our design team. This asset will provide the same options and naming conventions as a dev asset.
🔵 Dev Asset
Assignees
- Design system Developer
Output
- Code package(s)
As an outcome, a dev asset will be placed in our repository and available for implementation to the Emplifi's products. This asset will provide the same options and naming conventions as a design asset.
🔵 Dev Documentation
Assignees
- Developer & Content Designer
Output
- Dev docs, possibly within a code package
- Design preview in the storybook
As a final state, there should be a documentation page published in our storybook in a particular section that the content designer checks and, ideally, by a few developers to be sure the target group understands it.
There should also be a design preview that shows the most common cases and helps the designer understand the setup of the component.
🎉 Release
Once all four production parts are completed, we can officially release the component as a complete thing. This will create a clear line between versions.
However, this doesn't mean the component can not be used before it is released. Designers or developers should be confident in using the component once the asset is created. This should speed up the adoption and usage of the component, as well as the whole design system.