Existing Process and Experiments
The audit shows that the checkout button is a bright green, unlike every other button at Tiffinbox. You are about to "fix" it to orange. Then someone from the growth team mentions that they tested green against orange last year, and green led to more completed orders. That green was not an accident. It was a result.
The rule
Before changing how things look, learn how they got that way.
Pixels are only half of what exists. The other half is invisible: how the work gets done, and what the team has already learned.
The design process. Find out how a feature travels from idea to release today:
- Who designs, and in which tools? Where do the files live?
- How are designs handed to engineers, and how are they reviewed?
- Where are decisions recorded, if anywhere?
Interview designers, engineers and product managers, and follow one real feature from start to finish. A design system has to fit into this flow, or change it on purpose. If using Thali adds three extra steps to a designer's day, people will quietly skip it.
Experiments. Many companies run A/B tests: two versions of a screen are shown to different groups of users, and the results are compared. Gather the past tests that shaped the current interface, what was compared, and which version won. Some things that look inconsistent in the audit are proven winners. Others won under old conditions that no longer apply.
Two rules follow. Don't undo a tested result on taste alone. And when the system does change a tested element, test again rather than assume. The system should also make experimenting easy, for example by letting a team try a variant without leaving the system.
The shortcut
Ask "why" before "fix". For each odd thing in the audit, find out which of three it is: an accident, a constraint, or an experiment result. Only accidents are safe to fix straight away.
Spot the odd one
One button is green. Every other primary button is orange.
Drills
Answer fast — trust the rule.
What is an A/B test?
The audit finds an odd element. Following "ask why before fix", which kind is safe to change straight away?
Why study how designs currently travel from idea to release?
Thali's new button would replace a style that won an A/B test two years ago. What is the sound approach?
Remember
- Before changing how things look, learn how they got that way: the process and the experiments.
- Shortcut: ask "why" before "fix". Accident, constraint or experiment result; only accidents are safe to fix at once.
- Trap: undoing a tested result on taste, or building a system that doesn't fit how the team actually works.