Design how it behaves, not just how it looks
A design that only shows the perfect case has handed every hard decision to the engineer, at the worst possible moment.
The most expensive design is a beautiful screen with no empty state. It looks finished, it passes review, and it pushes every genuinely difficult question to an engineer sitting alone on a Thursday afternoon.
The states that decide the product
Data-heavy products are defined by their edges, not their middle. Our designers have to cover all of these before a screen counts as finished.
- Empty, and first-time empty. These are two different states with two different jobs.
- Loading — including the case where loading takes eleven seconds.
- Partly loaded. Some data arrived and some failed. Very common, and almost never designed.
- Errors, separating what the user can fix from what they cannot.
- Too much content. The name that is 90 characters long, the table with 40,000 rows.
- No permission. This is a design problem long before it is a security one.
Research that answers a real decision
We only run research when there is already a decision on the calendar and a realistic result that would change it. Research with no decision attached is a hobby with a budget. Research that arrives after the decision is just a record of a mistake.
If no possible finding would change what you build, you are not doing research. You are collecting reassurance.
Keep reading
Read the blogSlow onboarding is a warning sign, not a normal cost
Most teams accept that the first month of a project is wasted. Most of that month can be saved — and what is left tells you something important.
Write the test before you write the AI feature
The difference between an AI demo and an AI product is not the model. It is whether anyone can tell when the answers get worse.