By Kido - Design Operation Partners
Author: Ira Zubarev
Published: September 24, 2024
How do you know if clear design processes exist in your company?
When does the stage come where my supervisor reviews my design?
Where is the brief for the task located?
If I have questions, what is the communication path I should follow? How long will it take to get a response?
What types of edge cases should a feature include?
Who does QA for the design?
How do you define a new version for the design?
What does the hand-off process include?
Where are all the previous versions saved?
If you also answered at least one of the questions with "I don't have a clue", it means that the design processes in your company are not clear and unambiguous, and decisions can be made in hallway conversations or during coffee breaks.
Why Define Design Processes at All?
When dealing with a startup that includes +/- 10 people, sprints and design processes are developed in the shared space or Zoom call for everyone. Once the company grows and there's the beginning of PMF (Product Market Fit), it becomes harder to track changes, and the process of building new features becomes more complex and requires attention from various stakeholders.
In the early stages, there's still no consideration for the design and development debt caused by the rapid race toward PMF.
But once the company begins to mature, every addition of a small feature might cause things to break and become a major task requiring involvement from quite a few stakeholders.
Product design processes can include systemic design processes such as:
Launching a new feature (a process that includes involvement of various stakeholders in the company).
Adding a component to the design system.
Additionally, they can include local processes related to working on a design system that reflects systemic decisions locally, such as:
Adding new tokens to the design system (like new colors, typography, spacing, etc.).
Fixing or replacing an existing component in the design system.
And if we're already talking about transparency, when building a new feature or adding a component to the design system, the process doesn't end just with the hand-off.
Along the way, we need to check with UX researchers (if they exist in the company) that the behavior we chose is correct, that development can develop the component, and that the feature meets the PM's requirements.
Important to emphasize: In every company, the process may be slightly or very different depending on the number of stakeholders, resources, requirements, and more... There is no single truth - there is your truth.
Before starting to define the design processes in the company, you need to map the roles and responsibilities in the company:
-Basic Roles Include:
-Product Designers
-Design Lead
-Product Managers
-UX Designers
-Development Team
-Design Ops Team (if exists)
-Figma Champions* (we'll elaborate on the role's meaning later)
Once we've mapped the roles, the next step is to define what the stages of work and design processes are and what the areas of responsibility and requirements might be at each stage.
Very important: Each stage should have an estimate of the number of working days required to complete it.
Stage 1 - Initiation Process
When starting to work on a new feature or new component for the design system, you need to create a brief or requirements list that will be sent to the person responsible for reviewing and checking them (this could be a designer, design ops, design lead, or whoever you define as appropriate for your company).
The brief will include generic questions that can suit the initiation of any design process. You need to define together with the relevant stakeholders what they will include.
Examples of questions/requirements that a brief should include:
Date
Feature/component requester
What will the feature/component address?
What edge cases might the feature/component include?
Possible error types
(Ask yourself the 5Ws)
📆 Estimated work time - between 1-2 working days.
Stage 2 - Brief Review and Approval:
The second stage will include the required stakeholders reviewing the brief and asking questions before starting work.
It's important to define at this stage the time range for responses and establish the format in which this will be conducted (the format can be a meeting or dedicated channel for questions).
The type of stakeholders who need to be involved in this part can vary between processes. If it's a design lead or design ops who can advise and reduce the designer's work time. The type of initial research is also determined here - is it enough to do competitor research? Or should we deepen research based on questionnaires to existing users? It's recommended to decide at the current stage to arrive as prepared as possible for the next stage.
*The development team might also be involved in this part and give their opinion on constraints that might exist.
📆 Estimated work time - between 1-6 working days.
Stage 3 - Design Stage
At this stage, the design team needs to define the design guidelines for a new feature/new component for the design system.
One way is to create a short guide that includes checklists.
A prominent example of such checklists can be found on a website called, how else, "checklist design."
📆 Estimated work time - between 2-5 working days.
Stage 3.1 - Design Review:
In this part, we conduct a review of the design. Here too, you can follow a list of checklists and see whether the design indeed meets the requirements defined in the initiation process, provide feedback on the overall design, and if it's a component for the design system, ensure it's built correctly and according to the brand guidelines.
At this stage, it's important that whoever reviews the design is never the designer who designed it. It could be a design lead, design ops, or Figma champion.
*A Figma Champion is a designer from within the company, usually skilled in Figma, who also knows quite a few features in the system.
📆 Estimated work time - between 1-4 working days.
Stage 4 - Development:
This stage can include documentation, meeting with a developer, or even comments written in the designated place for developers within Figma (or any other tool you work with).
It's important that developers have access to the final design - this is also the design according to which versions should be managed.
After development develops the feature/component, any change made will be documented from that first version that was handed over to them - what's called release notes.
In this part, you'll need a dedicated developer who will compile the requirements for the development team together with you.
In large and mature companies, development processes already exist that take into account edge cases, responsiveness of the feature/component to different screens and browsers, performance evaluation (including loading times and rendering efficiency), and more.
📆 Estimated work time - 7 working days (or depends on what development defines).
Stage 4 - Development:
This stage can include documentation, meeting with a developer, or even comments written in the designated place for developers within Figma (or any other tool you work with).
It's important that developers have access to the final design - this is also the design according to which versions should be managed.
After development develops the feature/component, any change made will be documented from that first version that was handed over to them - what's called release notes.
In this part, you'll need a dedicated developer who will compile the requirements for the development team together with you.
In large and mature companies, development processes already exist that take into account edge cases, responsiveness of the feature/component to different screens and browsers, performance evaluation (including loading times and rendering efficiency), and more.
📆 Estimated work time - 7 working days (or depends on what development defines).
Stage 4.1 - VQA (Visual Quality Assurance):
This is a stage not worth giving up on. In many companies, it only comes after the feature/component is released to the air, but it's actually recommended to hold it beforehand.
You need to decide together with development what the platform will be on which the demo of the feature/component will be presented.
In the demo, the design team will check that development developed the designs and put emphasis on:
Responsiveness
Interactions
Typography (font sizes and weights)
Icons and illustrations
General visual alignment with the design handed over in the hand-off
📆 Estimated work time - between 1-3 working days (including development fixes - if development needs more).
Stage 5 - Release and Implementation:
We've reached the crucial and final stage where we hereby announce the release of the feature/component to all relevant teams (development, design). It's recommended to make the announcement in a channel where the entire design/development team is present.
When releasing a component to the design team - it's recommended to also add a few words about how to use it, and if a sticker sheet exists, add it there as well.
This is the stage where we also update the version, or start it if it's the first one.
There are several types of version management; the most common is the one that development also uses.
📆 Estimated work time - 1 working day.
Final Tips
Once you've managed to gather and define all the touchpoints between design teams and other various departments in the company, it's recommended and advisable to document everything in a schema and keep it in a repository that every employee has access to.
It's recommended to ensure that the schema indeed matches the company's needs and capabilities, to guarantee that it can meet the defined process.
In agile work planning, many things return to the backlog and create development debt (remember we talked about this at the beginning). It's important that we're aware of this and avoid such situations as much as possible.
In the end, the process you define will be the written law, and from there you'll continue to the oral law, from which you'll shorten, expand, and deepen where appropriate for you and your company.
