Picture an internal application where entering an order takes eleven clicks because every department asked for its own field and nobody wanted to remove the previous one. They grew screen by screen, and each decision looked reasonable on its own.
Understand before drawing
Design starts with plain questions: who uses this, at what time of day, on which device, what are they trying to get done and what gets in their way today. A few short conversations with real users usually clarify more than a week of guessing in a meeting room. Sometimes they reveal a step that should not exist.
With the eleven-click example, that means watching three or four people enter real orders and noting which fields they fill in every time and which they leave blank. The ones almost nobody uses get removed or moved to an optional section. The ones only one department needs show up only for that department. The decision rests on what was observed, not on who pushed hardest.
Flows come out of that: the path a person takes to finish a task, with its detours and its possible errors. Drawing them on paper or in Figma is cheap. Changing them once they are in code costs more, because screens, tests and data all need to change.
Cheap prototypes, fast decisions
A clickable prototype with no code behind it is enough to put in front of someone and watch where they hesitate. If three out of five people look for the save button in the wrong place, you already know what to move. A prototype like that takes little time and belongs to a short discovery phase, as we explain when talking about estimates.
A visual system saves repeated decisions
When colors, typefaces, spacing and components come from a shared system, the team stops debating whether the button gets rounded corners and focuses on the user's problem. The product also looks coherent even when several people build it, and for development a design system means reusable components and less duplicated code.
Accessibility from the start
Enough contrast between text and background, touch targets of at least 24 CSS pixels (WCAG 2.2 success criterion 2.5.8, level AA, though 44-pixel targets are comfortable to tap on mobile), a logical order for people who navigate with a keyboard and clear labels on every field. These are design decisions. Making them early avoids reworking finished screens.
The words are part of the design
An error message that says one thing in the form and another in the confirmation email means rewriting texts on three screens once someone notices. Deciding the tone, the section names and the wording of errors together with the flow avoids that rework.
Six questions for the first session
Bring them to the discovery meeting and do not close the design until each one has an answer:
- Who will use this every day and who only now and then?
- Which task is the most frequent and how many steps does it take today?
- On which device and in what conditions is it used: in a rush, on a poor connection, standing up?
- Which part of the current process exists only out of habit?
- Which mistake costs the most and how should the interface warn about it?
- Who decides when two departments ask for opposite things?
Pick the clumsiest screen in your product and send it to us. We walk through it with you before touching code, as part of our custom web applications service.