I used my observations of good and bad design practices in product teams to identify three key principles that could be used to build up the framework:
- Design engages with messy reality
- Design knowledge resides in models
- Most (digital) design happens post-launch
1. Design engages with messy reality
Many teams are so focussed on their product, they forget that it is just a small component of a larger system. They start to see the world through the filter of how their product works, becoming blind and deaf to the actual needs and priorities of the people the product is for.
“Messy reality” is my shorthand for the activity system of participants, roles, rules, tools, and goals that a product is deployed into and aims to improve. Or, to put it in plain English:
People doing stuff in the wild, with or without our product.
When designing digital products, we need to understand that messy reality; define what aspects of it we are trying to improve with our product; design solutions that we think will drive that improvement; and measure the impact (positive and negative) that our product has in the wild.
So, the starting point for the design process framework is to conceptualise design as a process that works backwards from messy reality to create products — which are then deployed back into messy reality, modifying it and closing the loop.
Along that loop designers observe and map messy reality, formulate and test solution hypotheses, collaborate with technical disciplines to build the real product, and measure outcomes — and in all of these activities, models play a critical role in creating and working with design knowledge.
2. Design knowledge resides in models
Design has its own ways of engaging with problems and building knowledge. Perhaps the most important of these is modelling — building visual or physical representations that help clarify, explore, and test aspects of the problem or solution space.
In my experience, teams that are “stuck” — not delivering value, and unable to define a path forward — often lack a strong set of design models underlying their work. While teams that are high-performing usually have strong alignment around a set of models that define what they are building and why.
Models used in digital design include personas and user journeys, ecosystem and actor maps, concept maps, value propositions, experience principles, service blueprints, architecture diagrams and interaction models, storyboards, wireframes, and simulations. Expert designers frequently build ad hoc models that combine features from multiple types, or develop their own unique modelling approaches — check out the Service Design Tools and NN/G websites for some great examples. What unites all these forms of models is that they describe — in ways that are shareable, digestible, actionable, and testable:
- aspects of “messy reality” i.e. insights
- aspects of a potential solution i.e. concepts
These models may also be used as probes with end-users and domain experts, providing an accelerated learning loop before things are built into the product.
By adding these modelling stages into the framework we can get a bit more granularity into how design works backwards from messy reality to create products, and identify the typical design activities in each quadrant of the framework:
It is important to think of these as activities rather than phases because in a post-launch product, all of these activities may be happening at once — and most digital design happens post-launch.
3. Most (digital) design happens post-launch
Design as a profession distinct from hand-craft was born out of the necessities of the printing press and the factory. Graphic and industrial designers can iterate and refine their designs on the drawing board, but once they go into production they are “frozen,” and any change is effectively a new product. In these industrial-era design disciplines, 100% of design happens pre-launch. The double-diamond process is optimised for this reality.
Digital products, however, have a fundamentally different dynamic. Most are continuously updated with a frequency ranging from a few days to a few months between releases. Typically, the first release is a Minimum Viable Product (MVP) which contains just a tiny subset of the functions and content that the mature product will eventually have. Therefore, most of the design activity occurs after the product is already launched and has active users.
This requires digital designers to let go of the perfectionist mindset we have inherited from our parent disciplines of graphic and industrial design. We need to be willing to deploy things that are “good enough” and come back to them later with improvements. It also opens up a wealth of new opportunities to explore problem-solution fit through usage analytics and experimentation (e.g. A/B testing). Adding these into the loop completes the framework.
What about pre-launch design?
Of course, pre-launch design activities are important too. Pre-launch design remains vital to ensure good initial framing and scope-setting, and to establishing the foundational insights and concepts that the product is built around. We can consider pre-launch design activities as a kind of “starter engine”: essential to get the wheels turning, but not intended to bring you to your final destination.