Product Design Teams Should Prototype Early and Internally — Here’s the Top Reason Why

A former director colleague of mine once said “I don’t understand why we need prototypers within design teams. Design should just partner with Engineering to do that work.” While it is true that a lot of great, collaborative work can be accomplished with this approach when done right, there is often an organizational hurdle — conflicting goals.

There are numerous benenfits to having design prototypers situated in a software UX teams. I would argue the strongest case to be made aligns with organizational goals. A Design team’s role (pardon the broad generalization) is to define the user experience — that is an effort for which they become bottleneck. By making prototyping a part of the design process to validate designed approaches early on through (semi-)functional, interactive examples (prototypes), a design team is empowered to test early, innovate further, and ultimately more confidently set Engineering up to implement a successful design.

In my experience if Design only prototypes in collaboration with Engineering after a design spec is delivered, course correcting becomes more expensive, and eventually when push comes to shove, Engineering will need to just implement the software — those tasks will be prioritized higher than design collaboration tasks, especially as deadlines approach. You will find engineers previously prototyping on the engineering side, now pulled into the vortex of implementation. Eventually something gets shipped, and at that point it becomes more up to the customer to validate for the first time, as a very expensive prototype — not a place anyone wants to be in.

Bottom line: Designers should promote prototyping at different stages in a software product development process, but especially make sure some prototyping is occurring early and within their organization. It’s not worth the risk to wait or make it another team’s job.