Design Process
Building a Design Process in a Cross-functional Product Team
Context
In mid-2022, I joined a newly formed product team working on an automotive services marketplace operating across 13 European markets. The product had existed since 2009 and carried significant legacy design and technical debt.
My role
I worked as a Senior UX/UI Designer and led several projects. I also took responsibility for operational improvements within the design practice. I treated this as part of my role: not only delivering strong UI/UX solutions, but also making the design environment scalable and comfortable for the entire team.
In addition to feature work, my focus was on establishing a clear file structure, a streamlined governance model for the design system, and a reliable designer-developer handoff process.
I partnered closely with the Product Owner, Business Analyst, developers, QA specialists, and other designers to identify pain points in the design workflow. I proposed solutions, aligned the team around clear rules and ownership, documented the process, and iterated whenever something didn’t work.
Challenges
When the new team started, we faced several operational issues that slowed delivery and increased risk:
We had no stable, shared design process, and design work was happening inconsistently across team members.
The product had years of legacy UI and technology constraints. We didn’t have a maintained design system or a reliable component library for development. Existing design files were difficult to navigate and reuse.
UX research maturity was low for this product: usability testing and in-depth interviews were not part of the standard practice.
Because the marketplace ran in 13 different countries, there were many stakeholders (often with market-specific needs), which increased design variance.
We couldn’t use branching in Figma due to the organisation’s subscription plan at the time. That made “parallel work” risky because changes in a file could unintentionally affect ongoing development.
As we began working, additional problems and challenges gradually emerged throughout the process:
Onboarding new designers was difficult because the design environment wasn’t structured.
The product served two distinct user groups: drivers and automotive workshops. The workshop account lived inside another application with a different UI, which meant we had to align with two design systems.
Design and development often ran in parallel. Designers continued iterating in Figma while developers were implementing earlier versions, leading to version confusion and rework.
Sometimes designers created new components while exploring ideas. If those components were added too early to the shared library, and the concept was later rejected, we ended up with “orphan” components in the design system, sometimes already reused by others.
Developers sometimes lacked clarity on which Storybook components to use and how to apply them correctly.
Solution part 1: Figma information architecture
Archive strategy
We evaluated legacy files and separated outdated drafts from current work. We created a dedicated Archive project and moved inactive designs there. Archiving is our default approach rather than deleting work, as it preserves history for comparison and enables rollback if stakeholders revisit previous ideas.
Three types of files in the main product project
Over time, the product project stabilised into 3 file groups:
Approved UI (“design production”)
These files contain only the latest mockups approved by the Product Owner. They act as the source of truth for designers: a place to reliably reuse patterns, screens, and decisions. Pages are typically organised by feature, flow, or screen family.
Process support files
These support ongoing work and documentation: the design system library, research planning boards, a user testing prototype file, and stakeholder presentation materials.
Individual drafts
Each designer maintained a drafts file as a safe workspace for exploration: references, early concepts, and iterations. Once a solution was approved, it was promoted to the source-of-truth files. Later, when we upgraded the plan, we complemented this approach with Figma branching.
A dedicated Figma project for development handoff
To reduce version conflicts, I proposed separating “designing” from “building”. Designers work and iterate in their drafts and in the approved source-of-truth files. For development, designers copy finalised screens into a dedicated Developers project and freeze them after refinement with developers. These files remain stable references during implementation. We mapped every file to a Jira epic and organised pages by user story/ticket. This let designers and developers work in parallel without breaking each other’s references.
Consideration: this approach works best when refinement → development cycles are relatively short. If refinement is delayed and business requirements change in the meantime, designers may need to update multiple locations (source-of-truth and handoff pages). We mitigated this by keeping the handoff scope tight.
Solution part 2: five-step design process
I organised and structured the entire design workflow into five clearly defined phases, including iteration loops between stages.
Planning
Requests can come from stakeholders, the Product Owner, or designers (based on research insights). All requests go through a basic triage: business value, UX impact, and technical feasibility. No one bypasses this by directly assigning work to a designer.
If research is needed, the designer prepares a research plan: goals, methods, and how outcomes will influence decisions. Depending on the topic, this may include analytics review, surveys, session recordings, deep interviews, usability testing, card sorting. The Product Owner may decide to stop the initiative at this stage if the available evidence does not support it.
Design
Design exploration happens in the designer’s drafts. Collaboration is part of the process: frequent checkpoints with the Product Owner and Business Analyst, early alignment with developers on feasibility, and clear rationale behind decisions. Designers use the design system by default and propose additions when needed.
User testing
When testing is required, we define scenarios and tasks, build a prototype aligned to those tasks, run sessions with users, synthesise results, and present a concise report. Testing can validate the solution or justify stopping the project if it doesn't solve the problem adequately or if the effort outweighs the value.
Design deployment (promoting to source of truth)
Before moving work into the approved files, we run a “ready for build” checklist to catch gaps that are easy to miss during concept work:
responsive mockups for all required breakpoints
required component states (hover and focus/focus-visible as a baseline; plus disabled, loading, error states as applicable)
error messaging, loaders, and placeholders
We also clean up drafts (layers, naming, hidden elements). If new styles or components are truly reusable, we add them to the design system, publish updates, and then apply them consistently before promoting screens into the approved files.
Preparation for development (handoff)
We annotate designs directly in Figma to reduce misinterpretation. Business logic stays in Jira tickets, but interaction and UI behaviour notes stay near the UI. We use standardised “stickers” for notes, questions, and Storybook component references.
Designers copy the approved screens into the Developers project and keep them stable while implementation is in progress. If new components are required in Storybook, designers create the corresponding development tickets and define acceptance expectations.
Below you can find the complete process flow with all key interactions. Click on the image to explore the full details and annotations in FigJam.
Summary & Outcomes
While building this operating model, I focused on four core components: cross-functional, horizontal communication; Figma information architecture; research; and the design system.
This helped us address the challenges we were facing and led to the following outcomes:
The first development iteration aligned more closely with the intended design. We reduced the number of UI testing rounds from 2–3 to 1, and the number of reported issues dropped noticeably.
Incorporating research and detailed analysis into the design workflow reduced the risk of wasting resources on low-value or ineffective solutions.
Establishing “Design Production” as a source of truth allowed designers to work faster with fewer inconsistencies.
The time invested in the design system paid off through reduced design and development effort, because new features could be built from reusable building blocks.
Our product team’s design process was adopted by other teams in the company as a model for effective organisation.
While working on these improvements, I learned that strong outcomes depend not only on individual professionalism, but also on how well each person is connected to the end-to-end process through a healthy team culture, clarity of ownership, and motivation.
Going deeper into organisational improvements gave me a strong opportunity to apply and further develop my managerial skills: presenting, negotiating, finding compromises, making evidence-based decisions, documenting processes, and mentoring.
What I would do next
Introduce AI agents into designers’ workflows.
Refactor the design system library based on recent product updates and capabilities in Figma.
Track not only UX metrics, but also success indicators for the design delivery process itself.