Continuous design: a framework for digital products
Most digital designers today are participating in some form of “continuous design”– iteratively improving and scaling a post-launch product — yet this is not reflected in the most common models that we use to describe the design process.
Continuous design is often implemented poorly, in part because of this mismatch between design theory and design practice. This leads to unhappy designers, inefficient teams, and inadequate design outcomes.
I propose a new process framework for continuous design to bridge this divide between theory and practice. While I acknowledge that process is just one of many levers needed to create the enabling conditions for good design, I hope this framework can be a useful tool to design leaders working to improve their teams' impact, efficiency, and happiness.
Contents
Why develop a new framework?
Building up the framework
Interpreting the framework
Where to from here?
Why develop a new framework?
When I studied industrial design in the 1990s, a simple design process was baked into the structure of our coursework. We received a brief, did some “pre-design” to better understand the problem, came up with a bunch of concepts, picked one to refine, and built a prototype.
In my early professional career in design consultancies, the process was pretty much the same, with the addition of some user research at the pre-design and concept stages. Along the way I encountered the Stanford d-school design thinking model and the design council’s double diamond, essentially sanitised descriptions of what we were already doing. It seemed like everyone agreed — this was the way design should be done!
Over time, I started to wonder if the popularity of this approach might be because it provides an easy way to package and sell design projects, not because it is always the best way to solve design problems. In the design consultancy business model, a stage-gated structure with clear directionality helps everyone feel safe. Hugh Dubberly highlights the sameness of consultancy models in his invaluable compendium of more than 100 design process models, how do you design.
Despite this apparent consensus, disruption to this process was on its way. In the early 2010’s, the digital design community got swept up in a great wave of ideas from software development, product management, and business strategy, including agile, lean start-up, and design sprints. Some of this felt like we were being sold our own hard-won design methods under new labels — but there was also a transversal theme running across all these approaches that challenged the very core of how we worked. Instead of agonising about getting things right first time, we were told we should build something quickly, get it into customers hands, and iterate on the live product based on its performance in the real world. This clashed with our familiar stage-gated, deliverables-based processes, and with the design consultancy business model itself.
I found myself straddling two era’s of design. The old, born in the world of design consulting for industrial products, conceptualises design as a project-based activity that begins with a brief and ends with prototypes and specifications, which are subsequently used to build and launch a product. The new, born in the world of digital product management, conceptualises design as part of a continuous build-measure-improve loop between product customers and product teams, with no beginning or end.
I quickly saw that the new conceptual model was a better fit to the needs of digital product design. I also saw there was a lot of value being lost in the implementation of this model. The emphasis on shipping product seems to encourage teams to build products without foundational user insights, design principles, or architectural vision. Designers are usually embedded in the process — a huge win on the face of it — but often in a structure that doesn’t allow them to orchestrate the user experience. Products become bitsy and incoherent very quickly — and although in theory teams are “learning from real user behaviour”, it often isn’t clear exactly what has been learned, and what should be done as a result. A decade into this new era, I am reminded of these challenges daily by people who are confused and disoriented by the digital tools they live and work with.
These challenges have been fiercely debated and analysed in the design community, which seems to have coalesced into pro-agile and anti-agile camps. For me, this “agile vs UX” framing is a red herring. Of course the design activities that are closest to the coal face of software development need to be fully integrated into the agile process (or whatever other software development process your company or client follows). But what about everything else that design does? Can we articulate the whole breadth of our contribution to successful digital products, including activities that are not directly connected to software development, in a common framework? Can we give our old-school UX methods a new lease of life in a framework that is fundamentally continuous and iterative?
When I moved into an in-house head of design role, tasked with improving design outcomes across a portfolio of products, these theoretical questions suddenly became pressing practical concerns. I needed a way to show my team and my cross-functional partners how I wanted design to fit in to the bigger picture. Having built a framework primarily to address this need, I am sharing it in the hope that other design leaders will find it useful in their own organisations.
Building up the framework
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.
Interpreting the framework
This is a framework, not a step-by-step guide. It aims to articulate the different kinds of design activities that are needed for continuous design of digital products, and establish the relationships between those activities — without prescribing how those activities should be performed. When interpreting the framework and applying it in practice, four key concepts are important to bear in mind.
- Focus on relationships, not sequencing
- This is not a rolled-up waterfall!
- This is not a rolled-up delivery train, either
- Everything everywhere all at once
1. Focus on relationships, not sequencing
The framework does not specify a sequential order of activities. Rather, it defines a set of enabling relationships. To clarify this point, the framework can be visualised as a concept map, where the arrows represent relationships rather than activities:
2. This is not a rolled-up waterfall!
This should go without saying…but the framework does not imply that one should first produce exhaustive insights, then all-encompassing concepts, then build a comprehensive product, and then launch it. Quite the opposite, it suggests that the 4 key constructs — messy reality, insights, concepts, and product — are in continuous evolution, dynamically influence each other, and are never “done”.
3. This is not a rolled-up delivery train, either
This framework does not suggest that each new feature, epic, or user story should move through dedicated research and concept generation stages before it is built. Rather, it suggests that backlog items should be written and prioritised based on a continuously evolving body of insights and concepts, allowing them in many cases to go directly into detailed design and development.
4. Everything everywhere all at once
From a design leadership perspective, implementing the framework requires balancing activities from all quadrants of the framework at once. For example, the current mix for my team includes active work across:
- Broad cross-product or pre-product research activities. These provide long-lasting, generalisable insights that inform multiple products and the overall strategy.
- Narrower product-specific research activities. These include evaluative research on newly designed features, and generative research informing major next steps on the product.
- Development, refinement, and dissemination of domain-level conceptual models, such as design systems and patterns, cross-product user journeys, and personas.
- Product-level conceptual design work preparing the ground for development. Includes things like information architecture, vision prototyping, and development of concepts for use as probes in generative research.
- Ongoing agile design and delivery sprints across multiple pre-launch and in-market products.
- Experiments with deployment teams to test hypotheses with live customers.
These activities have different organisational sponsors, cross-functional partners, funding mechanisms, and levels of visibility in the organisation. But they are not a disconnected collection of tasks or projects. Together, they form a coherent whole with the goal of keeping our products relevant to our customers; our conceptual models relevant to the next steps on the products; and our insights relevant for key product and portfolio decisions. Falling behind on any one of these goals will compromise the success of the others.
Where to from here?
The continuous design framework aims to provide a shareable, digestible, actionable and testable description of design as a continuous activity throughout the lifecycle of digital products. It suggests solutions to some of the challenges faced by contemporary digital design teams, while leaving plenty of space for tailoring to the specific context of application. My hopes for this framework are that it will stimulate:
- Digital design professionals to pause and reflect on their current practices and mental models, perhaps realigning them towards this framework or some version of continuous design
- Design educators to consider how they might provide tomorrow’s digital designers with the skills and mental models to engage with continuous design
- The design community at large to zoom out from “agile vs UX” debates and re-engage constructively with the topic of design process
- Our partners in product, engineering and business roles to expand their understanding of design, and in particular the role of models and the need for continuous investment in insights and concepts
Ultimately, I hope that a critical re-evaluation of design process provides a valuable piece of the puzzle for teams seeking to create the enabling conditions for impactful, productive, and enjoyable design work.
I would be delighted if you feel inspired to adopt, adapt, build on, or respond to this framework with your own ideas. Please comment here or mention me if you publish a response elsewhere.
