Splitting Product Design and Implementation

Why do we continue to separate the design of a product from its implementation?

When we design a product in one place with one group of people and implement it somewhere else with a different group, we fail to do either effectively.

In software development, this is a ruinous separation. It is a rift that we force on ourselves that demonstrates a fundamental lack of understanding of effective software product development.

Software implementation involves more than the crucial, apparent aspects of the technology. It includes designing the surrounding system in which we assemble the product. It is here already that we start building a system that either hinders or accelerates our ability to create, and more importantly, evolve a product that delivers on the imperative.

We meticulously construct high-fidelity visual mock-ups of the apps we want. Then, when considering a mock-up in isolation, we become lost, repeatedly, in the minutia of all the code details we need to deliver on that fidelity.

What if, instead, we codify the underlying concepts of those high fidelity details as we define them. We build a system to code our user interface in a way that can’t help but be compliant with our design standards. Then we spend less time assembling new screens. Then our design system is centralized and easy to adjust.

Software developers can build systems like this.

Now, think of all those design details in your product that are non-visual. We could never have communicated those to our implementation teams through visual mock-ups.

Developers do not work in the world of visual representation. Logical abstractions like interaction models, the notion of a use-case, how money works, transactionality, are as easy to design as visual abstractions.

Your implementation teams must keep up with your business agility for you to realize its benefits. Without the opportunity to comprehend, build, and evolve the right abstractions, you will not achieve agility.

Developers aren’t used to working in this way. We don’t teach them to work in this way. We don’t make space for them to work this way. They are as trapped in ways of thinking that defeat agility as the business.

There is no business agility without technical agility.