Design practice
The parts of the job that decide whether a good idea survives contact with a real product. Craft details that get designed last, and the sequence that stops a redesign answering the wrong question.
What this covers
Most design advice is about the part of the work that photographs well. This category is about the rest of it: the screen nobody briefs, the rule nobody wrote down, and the reason a competent team ships something worse than it can do.
Three of these posts are about craft that gets designed last and matters first. Every product is empty on its first day, and the empty state is almost always the final ticket rather than the first. Colour contrast is a floor teams treat as a target, and 4.5:1 is where accessible type starts rather than where it finishes. Design tokens are worth having only when they name a decision instead of a colour, which is the difference between a system and a palette with extra steps.
Two are about what a system is for. A design system that feels slow is usually a product that has not decided anything: the library is not the bottleneck, the unmade decision is. And a dashboard rarely needs another chart, because an average tells you a state and a queue tells you what to do about it.
The last is about doing all of it faster without losing the judgement, which is the open question for anyone designing with a model in the loop.
They share one assumption. The interesting decisions in software design are not visual, they are structural, and they are usually made before anyone opens a design tool. What the craft does is make the structure survive.
Start with Name the decision, not the colour. It is the shortest route to the idea the rest of these posts assume: that the useful unit of a design system is a decision somebody made, not a value somebody picked.
How to redesign a SaaS dashboard without losing the people who live in it
The complaint that starts a dashboard redesign comes from new users. The people who suffer when it ships are the ones who use it every day.
The admin panel is the screen nobody briefs and everyone depends on
The customer-facing product gets the design budget. The admin screens get whatever an engineer had time for, and then become the thing support spends its week on.
Most SaaS onboarding teaches the product instead of getting the user somewhere
A product tour explains the interface. The user signed up to get something done. Onboarding that confuses those two goals is the most skipped thing a team will build.
Your startup does not need a design system yet. It needs three decisions written down.
A design system built too early freezes guesses. One built too late means a dozen versions of the same button. The timing is the decision.
How to build a scalable B2B software website with a design system and Claude
The goal is not to let AI build your website. It is to make a good page the path of least resistance, for humans and for models.
Your design system isn't slow. Your product decisions are.
The library is rarely the problem. The system is exposing decisions the organisation never made, and exceptions arrive faster than it can absorb them.
Your dashboard doesn't need another chart
Information accumulates faster than purpose. Six months later the dashboard is visually impressive and nobody can say which decision it improves.
4.5 to 1 is a floor, not a target
Contrast is the one accessibility requirement everyone can check in ten seconds, which is exactly why teams treat clearing it as finishing the job.
Name the decision, not the colour
Most token systems are a colour palette with extra steps. The layer that makes them worth the effort is the one teams skip.
Every product is empty on the first day and that screen gets designed last
The screen that greets every new account is routinely the one nobody was assigned. It is also the only screen guaranteed to be seen by one hundred per cent of users.
