Design is an Afterthought in Team Function and Structure

Design is Treated as a Role, Not a Process

As design began gaining prominence in the software industry, companies were faced with a challenge: how to fit this new discipline into an already well-established system of building products. The best practice that emerged was to embed designers directly into existing engineering teams. The thinking was that proximity would lead to better collaboration. Designers would sit side by side with product managers and engineers, slotting into the same cadences and workflows. This approach, however, was incomplete, and the cracks soon began to show.

The structure and function of modern software teams can largely be traced back to methodologies that are output-oriented. Agile, sprints, kanban, roadmaps, backlogs, and tickets are all tools built around delivery. They are built on the assumption that the work is already known, and the challenge is to output it faster, more reliably, and at higher quality.

Design assumes that the solution is not yet known. Design is focused on discovering a way forward through exploration, testing, gathering feedback, and iterating. The design process may even reveal that the entire approach to a problem is flawed, and that an entire initiative needs to be taken back to the drawing board. This is valuable work that can save companies from failed feature and product launches that can cost millions.

Rather than rethinking how processes and companies should evolve to incorporate design as a process, however, designers were incorporated into frameworks optimized entirely around output. The underlying assumption was that design was just another role to be staffed, not a process to be supported. Consequently, a huge amount of the potential benefit of design teams was lost.

Designers Get Hit with Both Ends of the Stick

With software development teams expected to operate in tight delivery cycles, designers struggle to find time for divergent thinking, research, iteration, customer feedback, and learning from mistakes. They are often brought onto projects around the same time as engineers, and are seen as blocking everyone else's work. Designers often feel forced to just slap something together, regardless of whether the problem is fully understood or if they have confidence the solution will work. When the issues show up later, whether in usability, adoption, or customer complaints, it’s the designer who’s blamed.

In these structures, designers either burn out from the constant scramble to stay in front of the rest of the team, or they adapt by lowering their standards and focusing on speed. Neither path is good for the designer, the team, or the product. Over time, the organization internalizes the belief that design is slow, impractical, or even non-essential. And once that belief sets in, designers face an uphill battle in advocating for better product experiences.

I have often referred to this phenomenon as "hitting someone with both ends of the stick:" designers are first dismissed for raising concerns, then punished when those same concerns prove valid.

The problem isn’t the people. It’s the system. Modern software methodologies were optimized for building and delivering code quickly, not for solving problems holistically. As long as design remains bolted on to a system that wasn’t built to include it, designers are set up to lose.