Keeping design decisions from being lost when people leave

The team kept losing the reasons behind its own decisions

I worked in a design and research team of six, across more than 60 car and home insurance journeys. The work was good. But when someone asked why a flow worked the way it did, the answer lived in the memory of whoever had been in the room, and they had often moved on.

• Boards showed that a decision had been made. They did not show the options weighed or what ruled them out.
• So when a question came back, the team had the argument again.
• When people could not find answers in the documentation, they stopped checking it, then stopped updating it.

I was building a fix for people leaving, as someone who would leave

Anything that depended on me would fail on my last day. And a manager can ask for documentation, but nobody can be made to use it. It had to fit how people already worked.

The head of service design mentored me through the operational side, and we introduced the templates to the team together. Service blueprinting was new to me. I learned it on the job.

I checked the documents against the live product

• I walked every journey in the live product and compared it with its blueprint.
• Where a journey was missing or out of date, I rebuilt it from how the system really behaved and matched each step to its screens.
• Then I listened for where knowledge failed. The same few decisions kept being re-argued. The team recorded conclusions and lost the arguments behind them.

That made the problem small enough to solve in six months: record the reasoning behind the decisions that are expensive to re-argue.

Would it survive when nobody is paid to look after it?

• A wiki was searchable, but it sat outside the team’s daily tools, and that had already failed once.
• Notes in design files matched habits, but had nowhere for reasoning that spanned several decisions.
• Briefing my successor moved the knowledge into one more head.
• A shared workspace with rules, where the team already worked, was the one most likely to outlast me.

Built inside the tools the team already opened every day

• Every blueprint in Miro, linked to its live Figma screens, so the documentation and the product sat side by side.
• Templates that record the reasoning: the decision, the options weighed, the constraint that ruled one out and who shaped it.
• A change log on every card: what changed, why, when and who changed it.
• Named owners, agreed before I built anything.

It deliberately does not record everything. A complete system would have been stale within a quarter.

The first version was too heavy, so I changed it

When I took it to designers, researchers and people in other departments for feedback, some pushed back on the change log. With deadlines close, it felt like extra admin. They had a point: my first template was too detailed and written for design specialists.

• I cut it down to a standard card with a short log, so it took less time to keep up.
• I made a sample page, run like a short workshop, that showed why it asked for anything at all: out-of-date screens come off the blueprints, every screen links to its one current version and every change is logged.

People started using it when a decision came up for the third time and the reasoning was already written down.

Anyone could look up why, without chasing a designer

• The team adopted it without being told to, and reused the templates on work I had no part in.
• Anyone in another department who hit a blocker could open a journey and see what had changed and why.
• It left a trail for meetings, stakeholder presentations and lining up work with other teams.
• Whoever joins next starts with the blueprints, the reasoning and a place to record their own decisions.

I would agree a measure on day one, and test the template sooner

Adoption is my only evidence, because I never agreed a before and after. I would also put the first template in front of the people who had to fill it in before building around it, and lock in who owns it earlier.