Designer from the first sprint:
Article date
08 24 2026
Article Author
Lebedev Igor
Reading Time
7 minutes
Designer fr om the First Sprint: Why It Saves Money
Introduction
Typical story: a designer is brought in when the backend is already built, the architecture is fixed, and developers are starting the frontend. The designer looks at the technical spec and sees several decisions they would have made differently. But "it's too expensive to redo," so the product ships with compromises that could have been avoided.
This isn't a problem with a specific team — it's a systemic pattern. And it has a very real and measurable cost.
The Cost of Late Design
Research on the cost of fixing defects is well-established: the later a problem is found, the more expensive it is to fix. The same applies to design.
If a designer discovers early on that the authorization logic doesn't support a required scenario, it's a one‑hour fix. If it's found after authorization is already implemented, it takes days of rework. If it's found after release, it gets pushed to the next quarter — plus users have already faced the issue.
Multiply this by a dozen similar decisions in an average product, and you get the real cost of "end‑of‑pipeline" design.
What Happens When a Designer Comes in Early
Bringing the designer in early changes several things at once.
The designer influences how the task is framed. Development often starts with a technical spec — "implement module X with features A, B, C." A designer involved from the very beginning asks a different question: what's the user actually trying to achieve? Sometimes the answer completely redefines the task.
Architectural decisions start accounting for user scenarios. Data structure, navigation, state models — all of this affects what the interface will look like. If the designer sees these decisions before they are finalized, they can suggest a version that is both easier to implement and easier to use.
The amount of rework drops. Developers don't waste time implementing solutions that will later have to be redone for design reasons.
Real‑World Case Study
When the ROOT CODE team was launching an internal tool for working with routing data, a designer was brought in at the task formulation stage — before development began. This allowed the team to work out the navigation structure and interface object hierarchy in advance, aligning them with the data logic.
As a result, the team avoided a situation wh ere developers implement one conceptual approach and the designer comes in with another. The entire first iteration went without fundamental reworks of architectural decisions — only refinements and detail tweaks. The team's rough estimate is that this saved about two weeks of development on a three‑month project.
Why This Still Doesn't Happen by Default
There are several reasons why designers continue to be brought in late.
First is organizational: design is perceived as a service rather than co‑authorship. The designer receives a task rather than participating in shaping it.
Second is resource‑related: it seems the designer is only needed when there is "something to draw." Participation in requirements discussions is seen as not the best use of their time.
Third is cultural: in some teams, technical decisions are seen as the developers' domain, and designer involvement is viewed as interference rather than contribution.
All three reasons are solvable — but they require conscious changes to the process.
Practical Recommendations
• Invite the designer to requirements gathering meetings, not just implementation meetings
• Give the designer access to user research, analytics, and feedback — not just the technical spec
• Conduct joint workshops on user scenario mapping before development begins
• Build a habit: before finalizing technical decisions, do a quick review with the designer to check for user impact
Conclusion
A designer at the task formulation stage is not an extra meeting attendee. It's a way to reduce the cost of errors that would otherwise be discovered later. The interface is formed not only in Figma — it is formed in decisions about architecture, data structure, and system logic. The earlier the designer participates in these decisions, the less you have to compensate for their consequences later.
Introduction
Typical story: a designer is brought in when the backend is already built, the architecture is fixed, and developers are starting the frontend. The designer looks at the technical spec and sees several decisions they would have made differently. But "it's too expensive to redo," so the product ships with compromises that could have been avoided.
This isn't a problem with a specific team — it's a systemic pattern. And it has a very real and measurable cost.
The Cost of Late Design
Research on the cost of fixing defects is well-established: the later a problem is found, the more expensive it is to fix. The same applies to design.
If a designer discovers early on that the authorization logic doesn't support a required scenario, it's a one‑hour fix. If it's found after authorization is already implemented, it takes days of rework. If it's found after release, it gets pushed to the next quarter — plus users have already faced the issue.
Multiply this by a dozen similar decisions in an average product, and you get the real cost of "end‑of‑pipeline" design.
What Happens When a Designer Comes in Early
Bringing the designer in early changes several things at once.
The designer influences how the task is framed. Development often starts with a technical spec — "implement module X with features A, B, C." A designer involved from the very beginning asks a different question: what's the user actually trying to achieve? Sometimes the answer completely redefines the task.
Architectural decisions start accounting for user scenarios. Data structure, navigation, state models — all of this affects what the interface will look like. If the designer sees these decisions before they are finalized, they can suggest a version that is both easier to implement and easier to use.
The amount of rework drops. Developers don't waste time implementing solutions that will later have to be redone for design reasons.
Real‑World Case Study
When the ROOT CODE team was launching an internal tool for working with routing data, a designer was brought in at the task formulation stage — before development began. This allowed the team to work out the navigation structure and interface object hierarchy in advance, aligning them with the data logic.
As a result, the team avoided a situation wh ere developers implement one conceptual approach and the designer comes in with another. The entire first iteration went without fundamental reworks of architectural decisions — only refinements and detail tweaks. The team's rough estimate is that this saved about two weeks of development on a three‑month project.
Why This Still Doesn't Happen by Default
There are several reasons why designers continue to be brought in late.
First is organizational: design is perceived as a service rather than co‑authorship. The designer receives a task rather than participating in shaping it.
Second is resource‑related: it seems the designer is only needed when there is "something to draw." Participation in requirements discussions is seen as not the best use of their time.
Third is cultural: in some teams, technical decisions are seen as the developers' domain, and designer involvement is viewed as interference rather than contribution.
All three reasons are solvable — but they require conscious changes to the process.
Practical Recommendations
• Invite the designer to requirements gathering meetings, not just implementation meetings
• Give the designer access to user research, analytics, and feedback — not just the technical spec
• Conduct joint workshops on user scenario mapping before development begins
• Build a habit: before finalizing technical decisions, do a quick review with the designer to check for user impact
Conclusion
A designer at the task formulation stage is not an extra meeting attendee. It's a way to reduce the cost of errors that would otherwise be discovered later. The interface is formed not only in Figma — it is formed in decisions about architecture, data structure, and system logic. The earlier the designer participates in these decisions, the less you have to compensate for their consequences later.