When a product designer leaves, the company can lose the reasoning behind the product, not merely the ability to produce new screens. The safest response is to capture decisions, rejected options and open questions before the designer’s final day.
In April 1970, the Apollo 13 crew faced rising carbon dioxide inside the lunar module. The command module carried square lithium hydroxide canisters, while the lunar module used round ones. The crew had the canisters they needed, but they did not fit the system keeping them alive.
Engineers at NASA’s Mission Control in Houston had to devise an adapter from materials already aboard the spacecraft. Their solution used items including plastic bags, cardboard and tape. The crew followed instructions from the ground and built a working device.
Jim Lovell and Jeffrey Kluger document the episode in Lost Moon. The hardware mattered, but hardware alone could not solve the problem. People who understood why the systems had been designed as they were had to reconstruct the path between two incompatible parts while the outcome remained uncertain.
A designer’s departure creates the same shape of risk at a smaller scale. The files may remain accessible. The reasoning that makes those files useful can still disappear.
Screens preserve outcomes, not decisions
A design file shows where the team landed. It rarely shows the routes the team rejected.
The shorter signup flow might look obvious until someone asks why the company removed a field that sales wants back. The designer may remember that three early customers misunderstood it, that the field changed the mobile layout, and that collecting the information earlier produced no useful signal. None of that reasoning is visible in the final screen.
This becomes expensive when the next designer, engineer or founder revisits the decision. Without the history, the team debates the same options again. Worse, it may restore an old idea because nobody remembers the constraint that killed it.
That is product memory: the connection between customer evidence, technical limits, commercial pressure and the interface the team shipped.
I have seen how quickly a small team can confuse access with continuity. The Figma workspace opens. The components still work. Tickets remain in the backlog. Everyone assumes the handover is complete because nothing appears missing.
The gap becomes visible during the first consequential change.
Capture the reasoning while it can still be challenged
A useful handover should let the departing designer explain the product to someone who is willing to interrupt.
Start with the decisions most likely to be reopened within the next three months. For each one, record the user problem, the options considered, the evidence available at the time and the reason one option won. Add what would need to change before the team should reconsider it.
The rejected options matter. A screen labelled “final” tells the next person nothing about the version that failed usability testing, required unavailable data or created too much work for a small operations team.
Then review the product’s unresolved edges. Ask which parts of the interface look deliberate but are temporary. Ask where the design system has exceptions, which customer requests are louder than they are representative, and which flows depend on an engineer remembering an awkward implementation detail.
Record the conversation. Turn the important parts into short decision notes. A polished internal handbook can wait. Searchable evidence cannot.
This is similar to the trust problem I described in what an incomplete supplier record taught Ama about trust. A record can exist and still omit the fact someone needs to make the next safe decision.
Test the handover with a real change
Documentation feels complete to the person who already knows the product. Give it to someone who does not.
Choose one realistic change from the roadmap and ask another team member to reason through it using the handover material. They do not need to implement the change. They should be able to explain which users it affects, which earlier decision it touches, what evidence is missing and who should approve the tradeoff.
Every question they cannot answer identifies missing product memory.
Run this test before the designer leaves. Once they have gone, uncertainty turns into Slack messages, delayed replies and reconstruction from old comments. That is manageable when the departure is calm and the relationship remains good. It is a serious dependency when the person is unavailable or the team is working across Accra, Berlin and the US.
The goal is not to document every pixel. It is to preserve enough context for the next person to make a different decision intelligently.
Make product memory a team asset
The lesson from Apollo 13 is not that every company needs heroic improvisation. NASA’s ground team could improvise because it understood the systems, the constraints and the materials available aboard the spacecraft.
A startup should not wait for a departure to discover where that understanding lives.
Add a short decision note when a major flow changes. Link customer evidence to the decision it influenced. Record exceptions that would surprise a new engineer or designer. Review open product questions during regular planning, while disagreement is still available in the room.
Before the departing designer closes the laptop on Tuesday, pick one important screen and ask a harder question: “What would we misunderstand if we had to change this next week?”
Keep asking until the file stops being the only answer.
Comments
No comments yet.