The practice
Design histories are a way of documenting design decisions: not just the outcome, but the reasoning. Why we tried something. What the research said. What we rejected and why. What the constraints were. They originated in UK government design teams and have spread as a way to preserve institutional memory when people move on.
The problem they solve is familiar: designers make good decisions, but those decisions live in people’s heads. When someone leaves, the knowledge leaves with them. When a new team member joins, they spend weeks piecing together why things work the way they do. Design histories change that. They make the design thinking visible.
What goes in a design history
A design history entry typically covers:
- The context: What problem were we solving? What did we know at the start?
- The options: What did we consider? What did we try?
- The research: What did users do? What did we learn?
- The decision: What did we choose and why?
- The outcome: Did it work? What would we do differently?
The format is flexible. Sometimes it’s a short note. Sometimes it’s a full case study. The point is traceability. Future you, or a colleague, or an assessor, can read it and understand the reasoning.
Why a CMS
Many design teams wanted to use design histories, but the barrier was tooling. Writing in Markdown, pushing to a repo, understanding the publishing pipeline: that’s friction for people whose primary job is design, not code. So we built a CMS integration: a content management interface layered on top of the publishing system. Anyone on the team could write and publish a design history without touching the underlying technology.
That changed adoption. Service designers, content designers, delivery managers: they could participate. Design histories stopped being something only the technically confident did. They became a team practice.
The principle
Design histories aren’t bureaucratic overhead. They’re how you scale design thinking. When decisions are documented, they can be reviewed, reused, and refined. When research findings are written down, they inform future work. When someone new joins the team, they read the history instead of guessing.
I believe that in the process of teaching design leaders and their teams how to create and use design histories, you set design direction and good practice. The history is the curriculum.