Information architecture, the flows a person passes through, and the component system everything else is built on. Done before the code, because that is where mistakes cost hours rather than weeks.
When a digital product does not work, the feedback rarely sounds like design criticism. It sounds like "I could not find where to do it", "I did not understand what to put there", "I thought I had submitted it and it had not been submitted". All of these are design problems, only not of the kind discussed in meetings.
The meeting discussion is about colour, about how modern it looks, about whether the logo is big enough. Those are legitimate questions, but they are the last ones, not the first. The first are: what is the person trying to do, in how many steps do they succeed, and what stops them.
That is why we work in this order: information structure first, then flows, then components, and only at the end visual refinement. Every stage can be shown and corrected before a single line of code exists.
What content exists, how it groups, what each thing is called and how you get to it. It is the least spectacular layer and the one that decides most whether people find what they are looking for.
Concretely: a complete inventory of what you have, grouping tested on real people rather than assumed, names taken from your customers' vocabulary rather than the company's internal one, plus the navigation structure that results from all of it.
The complete path of an action, from intent to confirmation. Every step, every decision, every place where somebody can go wrong or give up.
Here we also handle what happens when things go badly, the part most projects discover in production: a field filled in wrongly, a connection lost halfway, a product sold out between two screens, a return using the browser back button.
The components everything is built from, with the rules for using them. Buttons with all their states, fields with their errors, cards, tables, the spacing scale, the palette with contrasts verified, the typography with its scale.
Without a system, every new page is invented again. With one, a new page is assembled in hours and looks like the rest of the product straight away, even if somebody else builds it a year from now.
The visual layer, applied over an already validated structure. Clear hierarchy, consistent spacing, contrast verified numerically rather than by impression, defined behaviour for every screen size.
It is worked on with real content, not placeholder text. A layout that looks immaculate on three word headings falls apart at the first ten word one, and real headings are almost always longer.
A design can be tested at sketch stage, and there a mistake costs an afternoon. The same mistake discovered after launch costs weeks and the users' trust.
| Method | What it answers | When we use it |
|---|---|---|
| User conversations | What they are trying to do and what stands in their way today | At the beginning, before any sketch |
| Card sorting | How they group information, against how we group it | When the navigation structure is not obvious |
| Prototype testing | Do they complete the main task without help? | On interactive sketches, before code |
| Accessibility check | Contrast, keyboard navigation, screen reader | On every component, not at the end as a checklist |
| Testing on real content | Does the layout hold up with long headings and real text? | Before handover to implementation |
| Measurement after launch | How many succeed, in how long, where they give up | Continuously, so we know what still needs work |
User testing frightens people through its imagined cost, but in practice five people attempting to complete a task surface most of the big problems. The sixth repeats what the others said. It is not academic research and does not pretend to be. It is the cheapest way of finding out that the thing which is obvious to you is not obvious to anybody else.
Most accessibility problems are born in design, not in code: insufficient contrast chosen because it looked elegant on the designer's screen, information conveyed only through colour, tap targets too small, forms where the label disappears once you start typing, the focus indicator removed because it spoiled the aesthetic.
All of these are free if decided at the design stage and become a rebuild if discovered afterwards. We verify contrast numerically for every colour pair, define the focus state as part of the system, and make sure nothing important is communicated by colour alone and that every flow can be completed without a mouse.
The result is a product that can also be used by people with low vision, colour blindness or who navigate by keyboard, which is around one visitor in five. It is also an expanding legal obligation, but even without that the number would be reason enough.
The same design system sits behind a website, an online store, a mobile app and an internal tool for a company. It is made once and used everywhere, which is exactly why it is worth building as a system rather than as a series of separate screens.
UX is how it works: what steps a person takes, in what order, what they understand at each one, where they get stuck. UI is how it looks: colours, typography, spacing, components. A beautiful UI over a poor UX gives you a product that looks good and frustrates, and that shows in the numbers before it shows in the comments.
It can, and it is done all the time. The result is that the team's assumptions go straight into the product, and if they are wrong you find out after launch, when correcting costs ten times more. Research does not necessarily mean months of study. Five conversations with real users surface, in practice, most of the big problems.
It is the set of components and rules everything is built from: buttons, fields, cards, spacing, colours, typography, plus when each is used. Without it, every new page is invented from scratch, seven shades of blue and five kinds of button appear, and within a year the product looks like several products glued together.
Both, and it is usually better that way. A design handed over as an image, with nobody to carry it into code, gets lost in translation: spacing approximated, states undefined, small screen behaviour invented on the spot. When we also build, the design system ends up in the code as real components rather than as a reference file.
By what can be measured: how many complete the main action, in how long, how many make mistakes along the way, how many give up and where. Beauty is an opinion, and opinions in a meeting are settled by whoever speaks loudest. Numbers are not.
We look at the existing product or site and tell you concretely where people are being lost and what is worth fixing first.