The Biggest Lie that Designers Believe about Software Development

This way of thinking leads to the false assumption that all of the exploration, creativity and iteration should occur during the design phase. But thinking that the job of the developers is just to turn designs into code undermines collaboration, increases frustration and results in missed opportunities for better outcomes.

How Did We Get Here?

This divide between "creative" and "logical" work traces back to the early 20th century and the rise of mass manufacturing. Factory owners broke down complex product builds, once the domain of master craftspeople, into simple, repeatable tasks that could be performed consistently by less skilled workers.

Design still existed as a creative act in order to agree on the products that would be made in the factories. But once in the factory, creativity was the enemy of efficiency – variation meant defects, and defects meant waste.

When software development emerged as a discipline in the late 20th century, organizations naturally borrowed from this manufacturing mindset. The result was processes like waterfall, or it’s more recent cousin water-scrum-fall, which treat development as the mechanical execution of design decisions. Developers are expected to "just follow the instructions".

Theory meet reality

Unlike manufacturing, where we repeatedly build the same product, software development is about creating something new every time. If we've built it before, we can just copy and paste the code. New features require customers to change their behaviour and we can’t predict that ahead of time.

Designs, no matter how polished, are hypotheses because we never really know if customers want the product until they have it in their hands. Any attempt to lock in a solution earlier in the process inevitably means locking in assumptions, and this is risky.

We need to “probe” with initial versions, “sense” the reaction from customers and “respond” with the necessary product changes. This fundamental difference means that development, like design, is inherently exploratory and creative.

In addition, there is the challenge of trying to comprehensively communicate designs. No matter how thorough the documentation or how polished the prototypes, every handoff involves assumptions. Designers make assumptions that they think are apparent, and developers interpret requirements through their own lenses with their own, different biases. These seemingly small miscommunications can result in big differences in expectations for a solution.

The result? More iterations. Instead of a smooth linear process, teams are often stuck in rework cycles.

Development Is Design

Development is not the mechanical execution of a design; it is a continuation of the design process in two key ways: the need to iterate to find what customers want and the creative act of turning a blank page into something functional.

When developers sit down to write code, they’re not just filling in blanks. They start with an empty code editor and make countless decisions to bring an idea to life.

• Architectural Choices: Should we use a microservices architecture or a monolith? How do we structure our data for both performance and flexibility? Which design patterns will make our code maintainable?

• User Experience Decisions: How should error states be handled? What's the most efficient way to cache data for instant responses? How can we make the system feel fast even when it's doing complex operations?

• Stylistic Decisions: How do we make the codebase consistent and easy to read? What's the best way to name variables and functions? How can we ensure that the code is easy to maintain and extend?

Each of these decisions shapes the final product just as much as the visual design decisions that preceded them.

Embracing Iteration Over Certainty

The idea that design is the creative phase and development is a linear execution process is not only false—it’s limiting. By viewing development as a continuation of the design process, we unlock the full potential of our teams to iterate, adapt, and innovate.

Instead of aiming for perfect certainty in design, teams should focus on reducing risk enough to move forward. Development continues this process of risk reduction, uncovering and addressing unknowns as they arise.

When designers and developers embrace their shared responsibility for exploration and iteration, they create the conditions for innovation. Teams become more resilient, solutions become more robust, and products become better aligned with user needs.