Design Delivery Survey Report
Taylor
Jordan
- Methodology & data
- Research summary
- Mixed results with design systems
- Iterative design changes are easiest to miss
- Enforcing file organization is an uphill battle
- Product managers are common design partners
- Design behavior isn’t straightforward to communicate
- User journeys are more commonly understood
- It’s common to communicate what’s “final”
- Demographics & toolkits
Sign up for the newsletter
Join 70k+ other subscribers and get updates on all our resources! You'll also get the latest articles directly in your inbox.
Methodology & data
- The survey was sent to our newsletter subscribers (primarily UX and product designers) and posted to social media.
- Respondents were disqualified from the survey if they worked with fewer than 3 designers or fewer than 11 developers. This helps us better assess how these practices take place across teams (instead of individuals).
- 75+ survey responses were gathered, and 5 participants were interviewed about their design delivery practices.
- You can download the raw (anonymized) survey results for your own personal use here.
Research summary
After uncovering user problems and designing a solution, the product and development team must collaborate to turn the design into a product.
To understand the state of design delivery, we asked designers to rate the quality of the final product and how their team navigated the path from design to development. We also wanted to know whether they followed common practices and whether these practices successfully gave the rest of the team clarity on what they needed to build.
When we asked designers to rate the overall quality of design implementation, 10% said the implementation was pixel-perfect, and an overwhelming 90% said there are “some” to “many” differences between the design and the final product.
Based on interviews and free responses, the barriers to implementation range from low organizational UX maturity to inflexible development partners. Teams that reported higher-quality implementation usually had stronger design systems and higher trust with developers.
We looked at the processes and practices design teams use to do design delivery, some notable observations include:
- Almost all teams surveyed (92%) have a design version management system to keep track of changes for development. However, the systems aren’t perfect, with 85% of respondents saying clarification was “often” or “sometimes” necessary.
- Almost all teams surveyed (91%) are separating in-progress and finalized designs by keeping designs in different files, pages, or projects. There are separate spaces for work-in-progress and in-development.
- Most teams surveyed (67%) have a system for communicating design system elements to developers, but nearly half of respondents (45%) say that developers “rarely” or “sometimes” use the correct design system element.
- Most teams surveyed (54%) have a standardized system of organizing design files, but more than half of respondents (57%) say those standards are rarely followed.
Mixed results with design systems
Most teams surveyed have standardized practices for communicating how designs relate to design systems, though many designers struggle to follow these practices. As a result, only half of teams surveyed consistently use the correct design system element in the final product.
Most design teams (68%) have standardized practices for communicating design system elements to developers. However, 35% of respondents mentioned that they don’t follow these practices, one of the higher rates of non-compliance.
Since there is inconsistent follow-through for these standardized communication practices, nearly half of designers (45%) say that developers only sometimes or rarely use the correct design system element when implementing designs.
When we asked designers about their level of familiarity with how their component library corresponds to their codebase, 44% said they were very familiar, and 56% said they were somewhat familiar or not familiar. Only 31% of designers said all or nearly all of the components in their library match the components in their codebase.
What is your level of familiarity with how components in your library correspond to components in your codebase?
Based on our interviews, even the most mature design systems suffered from “tribal knowledge” (where only some experts in the organization know certain aspects of the design system and it’s not easy for others to learn). Almost universally, designers acted as the glue who knew which components were implemented in the code base, which had flaws, and how the design elements differed from the implemented components.
Some designers (especially with larger teams) expressed concern when requesting changes or updates to design system elements because they feared the back-and-forth required to gain approval for their changes. These barriers can drive some teams to go rogue and break off from the approved design system or use lower-quality patterns that might harm the user experience.
Iterative design changes are easiest to miss
While most teams have a process for design versioning, it doesn’t always keep up with ongoing changes, causing developers to miss changes to an existing design.
Consistent communication is part of the challenge. While 89% of designers have an official process for informing developers about changes, more than a third of these designers report that the process is not consistently followed.
Version control and change management is the area where teams struggle most — 85% of designers say clarification is “often” or “sometimes” needed, the highest percentage of all the areas surveyed. In addition, 80% of designers say that changes to designs are often or sometimes missed by developers.
How often do developers miss changes to an existing design?
In our qualitative interviews this wasn’t felt as a significant pain point, which is somewhat surprising given the survey results. Participants felt confident in their existing workflow methods (usually involving design software, like Figma or Zeplin, and communication software, like Slack or email).
Enforcing design file organization is an uphill battle
Teams are split on whether to standardize design file organization. Many designers report standardized design organization is difficult or time-consuming to follow. The teams that choose standardized organization tend to be complex or have developers who are not design tool fluent.
Design teams are split on whether to have a standardized way to organize design files for developers (53% do, 47% don’t). Design teams with standardized organization practices also have exceptionally low rates of compliance — more than half (58%) of these designers say that standardized rules are not always followed.
This suggests that design organization standards are either ineffective or difficult to follow. In fact, designers are spending 50% more time organizing their designs when teams have standardized rules (2.8 hours vs 1.8 hours per week).
"On average, how much time do you spend organizing and maintaining designs so developers can understand them?" (Segmented by standardization)
One interesting note is that we don’t see a pattern between the likelihood of having a standardized design organization and company size.
In our qualitative interviews, we found that these practices can even vary from team to team within the same organization (making it even trickier to pin down these practices for entire organizations). One interesting term we heard was “Figma literacy” — the idea that developers may not be comfortable or knowledgeable enough to navigate a Figma file, which can cause them to guess or estimate specs instead of utilizing precise measurements and sizes. A lack of standardization might make this issue worse.
Product managers can’t always find what they need
Product managers (PMs) are a critical component of the design delivery workflow, yet the majority still struggle with understanding designs and subsequent changes to designs.
Almost every respondent works with PMs who review their designs. Half of the respondents report that company executives also review their designs. Other roles are less likely to review designs.
"Other than developers, who else looks at your designs?"
PMs successfully understand the meaning of designs at the same level as developers, which matches what we heard in interviews. The best teams seem to collaborate on the design from the very start of a project so that by the time final designs are being reviewed, most team members are aware of the details and how to move forward.
Clarification needed for designs, segmented by role
Design behavior isn’t straightforward to communicate
Most teams don’t have standardized practices to communicate design behavior, and respondents say this is a common area of confusion for developers.
Most design teams (61%) don’t have standardized practices around how to communicate design behavior (such as interactions) to developers. As a result, they are often required to provide clarifications — 76% of designers say clarification is often or sometimes required, one of the areas most prone to confusion.
"Does your team have guidelines for how to communicate design behavior (such as interactions) to developers?"
One common tactic we heard in interviews for clarifying interactions was to use a prototype, but this is certainly a time commitment.
User journeys are more commonly understood
While most teams don’t have standardized practices to communicate user journeys, most teams don’t have problems communicating user journeys.
Most design teams (64%) don’t have standardized practices around how user journeys should be communicated to developers, and there is no pattern between the likelihood of having standardized practices and company size.
"Does your team have guidelines for how to communicate user journeys to developers?"
Surprisingly, 44% of designers say developers rarely ask for user journey clarification, making user journeys one of the clearest areas in design communication.
In interviews, we discussed the differences between user journeys and user flows and heard that user journeys change far less frequently than user flows. User flows, on the other hand, often accompany the early stages of project lifecycles but are rarely maintained—making them more of an alignment mechanism than a source of truth.
It’s common to communicate what’s “final”
Virtually all respondents have a system of keeping in-progress separate from ready-for-development.
Most designers use some method of keeping their in-progress designs in a different place than the finalized designs that developers are working on. This creates better clarity and allows designers to keep iterating on the next version of a product while the current version of the product is being built.
"How do you organize in-progress designs from finalized designs that are ready to be built?"
Our interviews didn’t turn up any further insights on this topic.
Demographics & toolkits
These responses give you an idea of who took the survey and help frame the preceding insights.
"Which of the following best describes your role?"
"How many designers work at your organization?"
"How many developers work at your organization?"
"What is your primary design tool?"
"Which of these designer/developer collaboration tools does your organization use?"
(If you’re here looking for tool recommendations, be sure to check out our Design Tools Survey and our Design Tools Database).
To understand how product teams collaborate to implement designs, we looked at common practices teams use to maintain clear communication between designers and developers. We asked designers if their team adopted the practice and if the information communicated was accurate and clear.
|
Standardized team practice |
Standardized team practice not regularly followed |
No standardization, designers do it in a variety of ways |
Clarification is often needed in this area |
Clarification is sometimes needed in this area |
Clarification is rarely needed in this area |
||
|
Separation between in-progress and finalized designs |
92% |
N/A |
5% |
15% |
48% |
37% |
|
|
Communicating changes to an existing design to developers |
57% |
32% |
11% |
24% |
61% |
15% |
|
|
Communicating design system elements for developers |
44% |
24% |
32% |
N/A* |
N/A* |
N/A* |
|
|
Organizing designs for developers |
23% |
31% |
47% |
21% |
49% |
29% |
|
|
Organizing designs for product managers |
N/A |
N/A |
N/A |
17% |
51% |
31% |
|
|
Communicating user journeys for developers |
21% |
15% |
64% |
13% |
43% |
44% |
|
|
Communicating design behavior for developers |
25% |
13% |
61% |
28% |
48% |
24% |
Note: Some rows add to 99% or 101% due to rounding
*We didn’t ask whether design system elements needed clarification. We asked other questions to assess clarity of design systems communication. See the design systems section for more details.
Sign up for the newsletter
Join 70k+ other subscribers and get updates on all our resources! You'll also get the latest articles directly in your inbox.