Design Early, Code Smarter: A Case for Shifting Software Team Priorities
Whether you call it “Sprint Zero,” a “Design Sprint,” or a “Discovery Phase,” this exercise equips product teams with the confidence to build a product that delivers real value to the target audience.
As a designer, how many times have you experienced this scenario: You join a new product team staffed with a product manager, multiple software developers, perhaps a scrum master and a business analyst. Senior business stakeholders are already pressing for faster delivery, questioning timelines before you’ve even had a chance to contribute. The team has groomed a product backlog, planned several sprints, and now they’re looking to you—the new designer—for wireframes or detailed UI designs to guide development.
Sound familiar? I’ve been that designer more times than I’d like to admit. From the minute you join, the pressure is on to deliver design assets, even though the team knows very little about the target audience or their needs. Suggesting time for a discovery phase to conduct research, identify user problems, and validate concepts is often met with resistance: “We can’t have developers sitting idle, not coding.”
But why do software teams almost always start by assembling developers before understanding the problem space? How can you ensure the skills of your dev team align with building a solution users actually want or need?
I propose a different approach: beginning any new initiative by carving out time to focus on design and research. By prioritizing and time-boxing discovery upfront, teams can better understand their users, validate concepts, and ultimately reduce risk throughout the product development process.
This is So Obvious, and Yet…
The idea of a Discovery Phase isn’t new. Yet, more often than not, the reflexive first step for most software teams is to hire or assign development talent, which immediately pressures designers to rush into creating interfaces (don’t even get me started on the lack of involvement from content partners).
Why does this happen so often?
Institutional Immaturity: Design and research practitioners are often not seen as strategic partners capable of guiding a product vision. Instead, the design function is treated as a “nice to have,” brought in later to focus on delivery—making interfaces usable and visually appealing.
Deadline-Driven Delivery: Many organizations prioritize time to market above all else. The logic? The sooner developers start coding, the faster the product will be delivered.
Hubris: Leadership’s overconfidence—bordering on arrogance—in their knowledge of customers leads to the assumption that research is unnecessary. Why waste time confirming what they “already know”?
This prioritization of development puts designers in a difficult position. They often need to request additional time to conduct basic discovery research and investigate user needs—an essential foundation for effective design. However, asking for time to do this work can unfairly stereotype designers as obstacles to delivery, rather than essential contributors to the product’s success.
Try This: Start With Design
The next time you’re tempted to form a product team, resist the reflex to immediately hire software engineers. Instead, set aside dedicated time for a discovery phase that reduces the risk of delivering a product no one wants. Use this phase to:
Acknowledge and verify assumptions.
Understand real user needs.
Identify success metrics.
Validate potential solutions through prototypes and user feedback.
In addition to ensuring the team builds the right thing, this approach gives designers a head start on creating deliverables like user flows, prototypes, and wireframes. By the time software developers join, they’ll have a foundation to reference from day one.
Whether you call it “Sprint Zero,” a “Design Sprint,” or a “Discovery Phase,” this exercise—typically lasting one to six weeks—equips the team with the confidence to build a product that delivers real value to the target audience. Understanding your users also helps shape the type of solution to build and the resources needed to create it.
Finally, this approach is guaranteed to be less expensive than having an entire team spend months building a solution no one wanted in the first place.
