You Design the Same Mistakes

TL;DR:
When people leave, knowledge walks out with them. What stays in the docs is the decision, not the reasoning behind it. The sidebar argument that was settled two years ago is back because the person who settled it left. Teams don't learn, they relearn, at full price.

Somewhere right now, a design team is debating whether to put navigation in a sidebar or along the top. This exact argument was settled inside that same company three years ago. Someone ran the research, made the call, shipped the thing, and watched it underperform. The decision was reversed. Lessons were noted. And then the person who ran that research left. Another person left. A new designer joined who had come from a company that used sidebars. The debate is back, fresh as if it never happened, burning another two weeks and landing in roughly the same place.

This is not a failure of intelligence. It is a failure of memory.

Knowledge walks out the door

Every organization runs on two kinds of knowledge. The first kind lives in documents: specs, postmortems, design files, meeting notes. The second kind lives in people’s heads: the context behind decisions, the nuances that never made it into the writeup, the understanding of why a certain approach was tried and abandoned. Psychologist Daniel Wegner called this second kind transactive memory, knowledge that is stored not in any single mind but distributed across the group, with each person knowing roughly who knows what.

The system works as long as the people stay. Wegner’s research showed that groups with stable membership performed better on recall tasks than groups where individuals had changed, because they had built up an internal map of expertise. Colleague A knows the user research history. Colleague B remembers what happened with the last nav redesign. Colleague C was in the room when the CEO killed the modal pattern. As long as all three are there, the team has a working memory. Ask one of them what happened in 2021 and they can tell you. They know who to ask.

Then Colleague A leaves. Then B. The knowledge does not transfer to documents, because most of it was never the kind of knowledge that writes itself down well. What made that sidebar fail was a combination of the user segment at the time, the technical constraints of the build, and a product strategy that has since changed, none of which appear in the changelog. The new team has no access to any of it. Levitt and March described organizational learning as

“encoding inferences from history into routines that guide behavior.”

Levitt & March

That encoding process breaks the moment the people doing the encoding leave. What remains in the documents is the outcome without the reasoning. You see what was decided, not why, not what was tried before, not what the failure mode was.

The organization forgets and calls it fresh thinking

Walsh and Ungson described organizational memory as the stored information from an organization’s history that can be brought to bear on present decisions. Their research identified six places where organizations try to store what they know: individual members, culture, transformations like standard procedures, structures, physical workspace, and external archives. Of those six, individual members carry the most nuanced knowledge. They also carry the most fragile. Leave them out of the picture and the rest cannot compensate.

Organizations seldom recognize forgetting as forgetting. Nobody says they have lost the institutional knowledge on this. Instead they say let’s think about this with fresh eyes. They run another workshop. They build another prototype. They call it iteration. From the outside it looks like progress. Inside, it is rediscovery at full price.

Levitt and March found that organizations encode lessons from experience into routines, but that this encoding is fragile. When routines break down through turnover, restructuring, or rapid growth, the learning those routines carried can disappear without anyone noticing.

MySpace relearned everything it already knew

When News Corporation acquired MySpace in 2005 for $580 million, it inherited a platform with real technical problems: slow load times, an ad-saturated layout, and weak performance on mobile. Internal teams had raised all of these issues before the acquisition, and some work to address them had begun. News Corp brought in new managers with new priorities. Key product people who understood why certain decisions had been made left during the transition. New teams arrived with their own instincts and their own frameworks.

What followed was a set of technical and product decisions that anyone from the earlier conversations would have recognized. The slow load-time problem got worse. The ad model intensified rather than changed. Mobile strategy was deferred again. Every one of these had been discussed before the acquisition. The reasons why they had stalled evaporated along with the people who understood them. MySpace was sold in 2011 for $35 million, about six cents on the dollar, to Justin Timberlake and Specific Media Group. By 2019 it had seven million monthly visitors, down from 115 million at its peak.

What killed MySpace was not one bad call. It was a series of decisions made by teams who did not know what the previous teams had already tried, already learned, and already walked away from.

The question that saves the sprint

The fix is not more documentation, though documentation helps. Most teams already have too many documents nobody reads. The fix is a habit: before making a decision about anything that feels unresolved, ask whether someone here has tried this before.

Not in a general sense. Ask for the name. Who ran usability tests on the sidebar layout? What did the data show the last time the onboarding flow changed? What happened when the tooltip system launched in 2022? These questions have answers. Those answers are sitting in someone’s brain, in a Notion page that has not been opened in eighteen months, or in the head of a contractor who worked there three summers ago and is still on Slack.

Design systems are one partial answer, not because they document decisions but because they encode reasoning into reusable patterns that carry some of the why, not just the what. Nielsen Norman Group describes a design system as a shared language that reduces the need to relitigate choices across teams and time. That is true, as far as it goes. But a design system captures craft decisions, not research decisions. It tells you how the button should look. It does not tell you that the team already ran an A/B test on the full-screen modal onboarding and watched completion rates fall by 31%.

For that, someone needs to remember. And for someone to remember, the team has to treat memory as an asset, not an obstacle to fresh thinking. The person who has been there the longest is not slowing you down. That person is the closest thing your organization has to a hard drive.

The most expensive thing your team does is learn the same lesson twice.