Most software projects start with a picture. Someone draws the home page, the client likes it, and the developers start building. A few weeks later the questions arrive: what does this screen show when there is nothing in it yet? What happens when the payment fails? Where does a customer change their address? Who is allowed to see this list? Each question is answered in a hurry, by whoever is closest, and the product slowly drifts away from the picture everyone approved.
A design phase is supposed to prevent exactly that. Done properly, it is not about making the project pretty. It is about deciding, before anything expensive happens, what the product does, for whom, on every screen and in every situation that will really occur. This article is about what you should have in your hands at the end of that phase, how to tell a useful design from a nice drawing, and how to keep the design and the built product the same thing.
Why design before code at all
A change made while designing costs an afternoon: move a box, redraw a screen, try again. The same change made after the screen is built means changing the code, the data behind it, the tests and sometimes the screens around it. Made after launch, it also means retraining staff, answering confused customers and migrating data that was saved the old way.
That is the whole case for designing first. Not because design is more important than code, but because it is the cheapest place to be wrong. A design phase that only produces a few attractive screens wastes that advantage: the difficult decisions are still unmade, they are just made later, at a higher price.
Start from the tasks, not the pages
A useful design phase starts from what people come to do, not from what the pages look like. For a shop: find a product, decide, pay, track the parcel, return something. For a booking system: find a free slot, book it, move it, cancel it. For an internal tool: find the record, change it, see who changed it last.
Write those tasks down first, in plain words, with who does them and how often. A task done a hundred times a day by staff deserves a different screen from one a customer does once a year. Everything that follows, the screens, the navigation, the order of fields, is there to make those tasks quick and hard to get wrong. Decoration is what is left after that works.
What you should receive
At the end of a design phase you should be able to point at each of these:
- The list of tasks and the people who do them, agreed with you.
- The screens for every task, including the boring ones: settings, account, lists, the admin side your staff will use every day.
- Every screen in its real states: empty, loading, full, with an error, with too much text, on a phone.
- A small set of components, buttons, fields, cards, tables, used everywhere, instead of a different button on every page.
- The text that matters written for real: buttons, error messages, confirmation e-mails. Not lorem ipsum.
- A clickable prototype of the main task, so you can try it before anyone builds it.
- A written handover: spacing, behaviour, what happens on click, how screens adapt to a phone.
If any of these is missing, a decision has been postponed rather than made. That can be the right choice, but it should be a choice you know about.
Empty, loading and error are most of the real experience
The screens shown in a presentation are almost always the happy version: a full list, a perfect photo, a short name. Real use is mostly the other versions. The first time a customer opens their account, the order list is empty. Their internet is slow, so the page is half loaded. Their name is thirty characters long. The card payment is declined. The product has no photo yet.
A design that does not show those states leaves them to whoever builds the screen, at the last minute, without the context of the rest of the product. That is where most of the inconsistency in a finished product comes from. Ask to see, for each important screen: empty, loading, error, and too much content. If the answer is "the developers will handle it", the design is not finished.
Components, not pages
A product designed page by page ends up with seven slightly different buttons, four styles of table and three ways to show a date. Each one has to be built, tested and maintained separately, and users notice the difference even when they cannot name it.
A product designed as a set of components works the other way round. There is one button with a few variants, one field style, one table, one way to show a status. A new screen is then mostly assembling pieces that already exist and already work, which is why a new screen can cost hours instead of days. It is also what keeps the product consistent two years later, when the screens are being designed by someone who was not there at the start.
The words are part of the design
Words are part of the design. The label on a button decides whether people press it; an error message decides whether they fix the problem or give up and call you. "Error 422" and "This phone number is missing a digit" describe the same event, and only one of them helps.
So the important text should be written during design, by someone who knows the customer: button labels, form hints, error messages, empty-state messages, the subject lines of the e-mails the system sends. If your product is in more than one language, the design should also show the longest translation, because German and Bulgarian words do not fit where short English ones did.
Readable by everyone
A design should be readable by everyone who will use it: people with weaker eyesight, people using a keyboard instead of a mouse, people on a small phone in the sun. In practice that means enough contrast between text and background, visible focus when moving through a form with the keyboard, buttons large enough to tap, and information that does not depend on colour alone.
These are much easier to get right in the design than to add later, because they affect colours, sizes and layout, which are the hardest things to change once everything is built. I check designs against the WCAG AA level before handover, which is also the level most European accessibility rules point to.
Try it before you build it
Before building, try the main task on a clickable prototype. Not a presentation, a prototype: you click through it on your own phone, as a customer would, and see where you hesitate.
Better still, give it to three or four people who match your customers and watch them, without helping. You will learn more in an hour than in a week of discussing opinions. Where everyone hesitates at the same spot, the design needs to change, and it costs nothing to change it yet. When there is no budget for sessions like that, the honest thing is to say which decisions are therefore assumptions, so they can be checked after launch.
Designed to be built
A design that cannot be built within the budget is a drawing. The cure is to design against the real constraints from the first sketch: what the platform already does well, what the data actually contains, what has to load quickly on a mid-range phone.
This is why I prefer the design and the build to be planned together. A beautiful animation that takes a week to build is a decision with a price, and you should see the price before you approve it. So should an image-heavy home page that will be slow on mobile data. Neither is forbidden; both should be chosen knowingly.
The most common way a project goes wrong is not a bad design but a design that slowly stops matching the product. A detail is changed during the build because it was easier, then another, and six months later the design file describes a product that does not exist.
Three habits prevent that. The components in the design and the components in the code have the same names, so everyone means the same thing. Any change made during the build is either taken back into the design or rejected, never left in between. And before release, the built screens are compared with the design on a real phone, not only on a large monitor.
A handover anyone can build from
The handover is what lets anyone build the product, including someone other than the people who designed it. It should contain the design file, the component library, every state of every screen, and a written specification: spacing, sizes, behaviour on click and hover, how each screen changes on a phone, and which parts are fixed and which can be adjusted.
If you own the design file and the specification, you are free to choose who builds it, and you can come back to it years later. If the design exists only in someone's head or account, you have paid for it without owning it.
A checklist before you approve a design
Before you approve a design and pay for the build, check:
- Can you name the main tasks, and is there a screen for each?
- Is there a version of each important screen with no data, with an error and on a phone?
- Are the buttons, fields and tables the same everywhere?
- Are the real words written, including error messages?
- Have you clicked through the main task yourself on your own phone?
- Do you know which parts are expensive to build, and have you agreed to them?
- Do you have the design file and the specification in your own hands?
Seven yeses mean the design phase has done its job. Each no is a decision that will be made later, at a higher price, by someone in a hurry.
How much design does your project need?
Not every project needs a long design phase. A small change to an existing product can often be designed in a day, using the components it already has. A new product, a redesign, or anything your staff will use all day long deserves the full phase, because its cost is small compared to building the wrong thing.
And sometimes the better answer is not a redesign at all. When an existing product has a problem, I start by finding where people actually fail, and often a targeted fix to two or three screens does more than a new look for everything.
Planning a new product or a redesign?
Discuss your projectTell me who uses it and what they come to do.