ThemeProduct & Offering
CardCard 14 of 66
Questions5 to explore

Design

How design shapes the business

Design shapes everything the organization makes, and when the thinking behind design decisions is not captured, those decisions get relitigated from scratch every time.

Design in this context means more than aesthetics. It includes how decisions get made about what the product looks like, how it works, who it is for, and what problems it is solving. The reasoning behind those decisions is as important to capture as the decisions themselves.

Many organizations treat design as something that happens in dedicated tools (Figma files, prototype links, style guides) and forget that the thinking lives in conversations and in people's heads. When designers change, or when a non-designer has to make a product decision, that thinking disappears.

Good design documentation connects the visible output to the problem it was solving. It captures design principles, the reasoning behind key choices, what was considered and rejected, and where the current source files live.

What to capture

For this part of the company brain, what is worth writing down and keeping current. The goal is not a complete archive but a living record that new people can read and returning people can trust.

Design principles

Write down the two to five principles that guide design decisions in your organization: what you optimize for, what you are willing to trade off, and what design failure looks like.

Source files & tools

Record where design files live, what tools are used to create them, and how files are named and organized. Include access instructions so someone new can find the current version without asking.

Key decisions & rationale

For major design choices (navigation structure, core interaction patterns, visual language), capture why the decision was made and what alternatives were ruled out. This is the most perishable knowledge.

Design review process

Note how design gets reviewed and approved inside the organization: who is involved, what stages exist, and what sign-off looks like before something ships.

Questions to explore

Use these on your own or in a group. There are no right answers, only better conversations.

Where do the current design files live, and does everyone who needs access actually have it?
Are the principles behind your design decisions written down anywhere, or do they exist mainly in the heads of the people who made them?
When a new person joins the team, how do they learn the design conventions and why they exist?
What design decisions have been reversed or relitigated multiple times, and is there a record of why the original decision was made?
Who has the authority to make final design decisions, and is that clear to everyone involved in the process?

Things to notice

Design files are not design documentation. Files show what was decided; documentation captures why, which is what new team members and future decision-makers actually need.
Principles written as vague aspirations ('be simple', 'delight users') do not help anyone make a real decision. Useful principles say what to do when two good things are in tension.
Design knowledge is particularly vulnerable to walking out the door with individual contributors, because so much of it lives in institutional taste rather than written rules.