UX/UI design: the real process from research to handoff

UX vs UI: the difference that costs money

UX is how a site works. UI is how it looks. Good design starts with a user's problem, not with a colour palette. If someone can't tell where to click, the prettiest interface won't save you — they close the tab and go to a competitor whose button was visible.

Formally, user experience is the whole journey: how a person arrived, what they were looking for, what they found, how many steps it took, where they stumbled, how they felt at the end. UI is the visual layer of that journey: typography, colour, grid, button states, icons, spacing. The layers are connected, but they solve different problems.

Why the difference is commercial, not academic

Picture two online shops. The first looks plain, but filters respond instantly, prices are visible up front, and checkout takes three fields. The second has beautiful animation, huge photography, and a cart that demands registration before it will show shipping costs. The first one sells more. Not because looks don't matter, but because revenue comes from a completed action, not from an impression.

So here is the working formula: UX decides whether someone reaches the goal, UI decides whether they trust you on the way there. You need both. But when you have to choose what to fix first, fix the logic.

What design does not do

• It doesn't rescue a bad product. If your price is above market with no explanation, layout won't hide that.
• It doesn't replace traffic. Strong UX/UI design lifts the conversion from visitor to enquiry, but somebody still has to bring the visitors.
• It doesn't read minds. Without data about customers, a designer guesses — and guessing costs more than research.

That's why in our studio services design never appears as a standalone line item called "draw a mockup". It runs alongside analytics, content and development — otherwise you get an expensive picture that nobody can actually build.

Step 1. Research, goals and a competitor review

Design starts with the question "what must happen on this site", not "which colour do you like". Until that's answered, every revision is argued on taste — and taste is an argument nobody wins.

What we establish up front

• The business goal. Enquiries? Orders? Bookings? Job applications? One goal is primary; the rest are secondary.
• The target action. The specific button a person should press. If there are five and all of them are "the main one", none get pressed.
• The audience. Who they are, how much they know about the subject, what device they use, what they already know about you.
• The objections. Why they hesitate: too expensive, too slow, unclear, "will they even do my kind of job".
• The constraints. Deadlines, budget, existing CRM, brand identity, legal requirements.

Data doesn't have to be expensive. Sales call recordings, chat threads, on-site search queries, heatmaps, the questions customers ask most often — that's already enough to stop guessing. If analytics are running, look at where people drop off and at which step.

Competitor review — not for copying

You look at competitors to learn the rules of the market and to find the gaps. The rules are what a user expects by default: price, timelines, what's included, reviews. The gaps are what nobody offers: a calculator, honest lead times, real photos instead of stock, a plain explanation of the process. Copying someone's layout is pointless — you don't know whether it works for them, and you inherit their mistakes along with their decisions.

A heuristic review

If a site already exists, walk it against basic website usability principles before anyone draws anything: is it clear where you are; is system status visible; can an action be undone; are errors understandable; does the interface speak the customer's language; do you have to keep things in your head between screens. Two days of this produces a problem list, half of which can be fixed without a redesign at all.

Step 2. User scenarios instead of pages

People don't come "to a website" — they come to get something done. So you design scenarios, not pages: what a person does, step by step, from arrival to result.

A scenario fits in one plain sentence. "A parent is looking for an after-school club near home, wants to see the schedule and the price, and to book a trial session from a phone in five minutes." That's it. From that sentence alone you can see the requirements: a location filter, a readable schedule, a price without "contact us for details", a short form and a tappable phone number.

How many scenarios you need

For a services site, usually three to five. More and you spread thin; fewer and you're missing something. A typical set: "never heard of this company, just researching", "comparing with a competitor, looking for a reason to pick one", "already decided, want to get in touch fast", "existing client, need a contact or a document".

Different states, different screens

Junior designers draw only the perfect state: full catalogue, short names, every photo in place. Reality is richer. Every key screen needs states:

• Empty — the filter found nothing, the cart is empty, there are no orders yet. What does the person see, and where do they go next?
• Loading — what's on screen while the data travels.
• Error — the server is down, the payment failed, a field is wrong.
• Overflow — a three-line product name, 40 items, a 2,000-character review.
• Success — the form is sent. Now what? "Thank you" is not an answer; people want to know when someone will call.

States are the dullest and the most valuable part of the job. They're exactly what separates a mockup you can build from a mockup that has your developer messaging you every half hour.

Step 3. Information architecture

Information architecture is where things live and what they're called. It solves half your navigation problems before the first pixel exists.

The work sounds simple and is tedious in practice: collect all the content, group it by meaning, name the groups in the customer's words, set the priority. The key part is the customer's words. "Solutions" makes sense to you; the person is searching for "fridge repair". Your internal org chart should never leak into the menu.

Rules that save time

• The menu is not a dumping ground. Five to seven top-level items. If it doesn't fit, the grouping is wrong.
• Depth of three clicks max to any important page. Past that, you lose people.
• One meaning, one page. Two similar pages compete with each other in navigation and in search.
• The label is the query. A menu item should match how a person actually thinks and talks about it.

Priority within the page

Inside a page the same logic applies: answer first, then detail, then proof, then action. A visitor decides in seconds whether they're in the right place, and they decide from the first screen. If the top of the page says "Welcome to our website", you've spent your most valuable real estate on a placeholder.

Block order is design too — and it's the part that moves money most. We broke down the logic of block sequence in our piece on landing page structure: same mechanics, compressed into a single page.

Testing architecture with no mockup

Give the list of section names to five people outside the project, ask them to sort it into groups and say what they'd expect to find where. The disagreements will show you the trouble spots in an hour. It's cheap and it beats arguing in a meeting room.

Step 4. Wireframes: the skeleton without makeup

A wireframe is a black-and-white schematic of a screen: what comes after what, what matters more, where the action is. No fancy type, no shadows, no photography. Deliberately.

The point of the greyness is to strip out everything that distracts from structure. Show a coloured mockup and the client will inevitably say "make the button brighter", and the conversation about the button being in the wrong place never happens. A greyscale wireframe drags the discussion back to substance: is it clear what this company is, what it offers, why to trust it, and what to do next.

What belongs in a wireframe

• Real headings and labels, not Lorem ipsum. Dummy text lies about both length and meaning.
• The real number of elements: if the catalogue has 12 items, don't draw three.
• Every key state from the previous step.
• Mobile and desktop versions of key screens right away, not "we'll adapt it later".

How many screens to draw

Not all of them. You draw page types: home, service page, catalogue, item page, form, article, contact, utility pages (404, thank-you). Everything else assembles from the same blocks. If every new page needs a new mockup, you don't have a system — you have a pile of pictures.

This is the cheapest place to argue

Moving a block in a wireframe takes minutes. Moving it in a built, CMS-wired site takes days and money. So this is exactly where you should push back, ask awkward questions and demand reasoning. From here on, the price of a change climbs with every step.

Step 5. The UI concept: what trust looks like

Once the structure is agreed, the visual layer arrives. Its job isn't decoration — it's making the structure obvious and earning trust.

Trust in an interface is built from boring things: a tidy grid, consistent spacing, readable text, real photos instead of stock, honest numbers, an absence of visual noise. Nobody thinks "I love this modular grid" — they simply feel that things here are in order, so the work will probably be in order too. The reverse holds: misaligned client logos and three different blues read as "thrown together".

What a UI concept is made of

• Typography. The type pairing, sizes, line height, line length. It's 80% of how a site feels, because a site is mostly text.
• Colour. A neutral base, one accent reserved for the target action, functional colours for errors and success. Spend the accent only on what matters, or it stops working.
• Grid and rhythm. One spacing step (a multiple of 4 or 8, say) instead of eyeballing every gap.
• Imagery. Your own photos of the work and the people beat perfect stock, because nobody believes stock.
• Tone. The interface speaks: formal, friendly, technical. That's a decision, not an accident.

A concept is one screen, not the whole site

Usually you present the home page or a key service page in two or three directions. The goal is to agree on a language, not to sign off a final build. What that language looks like on real projects is easier to see in the portfolio: different sectors need a different visual tone of voice, even though the process behind them is identical.

And the essential bit: a concept is judged on "does it serve the goal", not "do I like it". More on that in the feedback section.

Step 6. Design system and components

A design system is a set of ready-made bricks plus the rules for building with them. Buttons, fields, cards, headings, spacing, states — defined once and reused everywhere.

Without a system, every new screen is drawn from scratch. Six months later the site is home to seven shades of grey, four button sizes and three kinds of product card, and nobody remembers why. With a system, a new page assembles in hours instead of days and looks like part of the whole.

What's in a system

• Tokens. Colours, type sizes, radii, shadows, the spacing step — as named variables, not values invented on the spot.
• Components. A button with every state (default, hover, focus, pressed, loading, disabled), an input with error and hint, a card, a modal, a table, pagination.
• Composition rules. Which heading when, how much air between blocks, how elements behave on overflow.
• Patterns. Forms, filters, checkout — standard assemblies built from components.

Why the client should care, not just the designer

A system is savings on your future. A new service, a campaign landing page, an extra section — all of it assembles from what exists and needs no new design project. It also stops the site drifting apart over time as different people make edits.

Scale depends on the project: a small brochure site needs a single page of rules, a large catalogue or product needs a proper library. On the Shokava project the component system is exactly what kept every page type looking consistent without drawing each screen separately.

Step 7. Prototype, developer handoff and design QA

A prototype is a clickable mockup in which you can walk a whole scenario before a single line of code exists. It answers the question a static picture can't: "what happens when I press this?"

Prototypes catch expensive mistakes: a redundant step in a form, a dead end after submission, a confusing way back, a filter that resets itself. Five people walking the scenario out loud teach you more than a month of internal debate. You don't need a lab — you need someone from the audience, a task, and an observer who keeps quiet.

What a handoff actually contains

• Mockups at two or three key widths: mobile, tablet/intermediate, desktop.
• Every component and screen state.
• Tokens and rules: colours, type, spacing step, overflow behaviour.
• Behaviour: what's clickable, what opens, what animates and over how many milliseconds.
• Final copy, not placeholder copy. Assets: icons, images, logos in the right formats.
• Edge cases: a very long title, a missing photo, zero results.

A good handoff is not "here's a link to the file". It's a meeting where the designer and the developer walk the mockups and say the non-obvious parts out loud. Half an hour of conversation saves a week of messages.

Design QA: the check after the build

Once the site is assembled, the designer goes through it again — this time in a browser. Spacing, text wrapping, states, behaviour on real data, focus, animation speed, form behaviour. It's a short stage, but skip it and there's always a gap between the mockup and the live site. The rule is simple: until design QA is passed, the project isn't finished.

Mobile-first and accessibility in plain language

You start designing on the phone screen — not because it's fashionable, but because the constraints are harsher there. If the content fits and works at 360 pixels wide, it will unfold onto desktop painlessly. The other direction almost never works.

Mobile-first is a discipline of priorities. On a small screen you can't show everything at once, so you're forced to answer honestly what matters more. That answer then improves the desktop version too.

What to check on mobile

• Tap targets no smaller than a fingertip. Tiny links crammed together produce mis-taps and irritation.
• Nothing runs off the edge; there's no horizontal scrolling.
• The phone number dials, the address opens a map, form fields summon the right keyboard.
• The important action is reachable without endless scrolling.
• Heavy images don't kill loading on a mobile connection.

Accessibility: four things that give you 80% of the result

• Contrast. Light grey text on white looks elegant in a mockup and is unreadable outdoors in sunlight. Contrast helps people with low vision — and it helps you, on a cheap screen, on the move.
• Focus. When navigating with a keyboard you can see which element you're on. Removing the focus ring "because it's ugly" is a common and serious mistake.
• Keyboard. The whole form can be filled and submitted without touching a mouse. A modal can be closed; a menu can be escaped.
• Alt text. A short description of what an image means. It helps blind users and search engines alike.

Accessibility isn't a separate expensive phase. It's a set of habits: never rely on colour alone to carry meaning, label fields instead of relying on placeholders, write error messages a human can act on. Built in at design time it costs pennies. Bolted on after launch it costs real money.

Copy is part of the design

An interface is made of words more than of graphics. The heading, the field label, the button text, the error message — all of these are design decisions that happen to be spelled out in letters.

Which gives us a rule: designing without finished content is fortune-telling. The designer invents a three-word headline; the client's is twelve. Invents three benefits; the real ones are two, and they're different. The mockup falls apart at the content stage, and everyone is surprised.

Words that fix interfaces

• Buttons describe the outcome. "Get a quote" beats "Submit". A person should know what happens after the click.
• Headlines answer, they don't tease. "Websites for medical clinics" works; "We create the future" doesn't.
• Errors say what to do. "Invalid format" is bad. "Enter the phone number as +44…" is good.
• Labels beat guesswork. If a field needs something specific, say so before the error, not after.
• Fewer words, same meaning. Every extra sentence lowers the odds that the necessary one gets read.

One practice saves weeks: draft the copy for key screens before anything is drawn — even roughly, in a spreadsheet. Then the designer works with real lengths and real meanings instead of bending reality to fit a layout.

How to give useful feedback, and how many revision rounds are normal

The most common cause of dragged-out projects isn't "a bad designer" — it's feedback expressed as taste. "It doesn't grab me", "make it more modern", "my wife didn't like it" — you can't respond to those with work, only with another attempt to guess.

The formula for a useful comment

Talk about the problem, not the solution. The shape is: what I see → what worries me → what it risks. For example: "The first screen doesn't say we work nationwide. Customers ask about that on the very first call — I'm afraid some of them won't reach the form at all." That's something a designer can work with. "Make the button red" is a finished solution, and it's probably not about the button.

Rules that speed up sign-off

• Collect revisions into one list from everyone involved, instead of dripping them into chat all day.
• Appoint a single decision-maker. If five people approve, the mockup becomes an average — and averages don't sell.
• Look at it on your own phone, not just on a big monitor. That's how your customers look at it.
• Don't reopen settled decisions. An agreed structure reopens for new facts, not for a new mood.

How many rounds is normal

Common practice: two rounds of revisions per stage (structure, concept, mockups) plus one final polish. That's not studio stinginess — it protects the project. Endless rounds almost always mean the goal isn't agreed, not the pixels. If the third round is arguing about the same thing, the problem lives back at the research step, and that's where you should return.

Expensive, common mistakes

• Designing without content. A mockup built on dummy text collapses when the real text arrives. Always.
• Copying a competitor. You're copying a picture without knowing whether it works for them.
• Decoration over clarity. Animation, parallax and sliders instead of answering "what do you sell".
• Many goals on one screen. Five equally weighted buttons equal zero clicks.
• Designing for the jury. An awards mockup and a selling mockup are different genres.
• Nobody owns acceptance. A project without a decision owner drags on for months.

Checklist: judging a design before it goes to development

Before mockups go to the build, run this list. Every item is a change that costs minutes now and days later.

Meaning

• In 5 seconds the first screen tells you: what company this is, what it offers, to whom, and what to do next.
• Each screen has one main action, and it's visually the main one.
• Key objections are answered: price or a price range, timelines, guarantees, who you are.
• Every claim is backed: case studies, reviews with names, numbers you can actually prove.

Structure

• Blocks follow "answer → detail → proof → action".
• Navigation: 5–7 items, labels in the customer's words, anything important within 3 clicks.
• No two pages about the same thing.

Completeness

• There's a mobile version of every page type, not just desktop.
• States are drawn: empty, loading, error, success, long text, many items.
• Copy is final, images are real, no Lorem ipsum anywhere.
• Utility pages exist: 404, thank-you, payment failure if you need one.

System and accessibility

• Buttons, fields and cards come from one set instead of being redrawn per screen.
• Spacing follows a single step; there are exactly as many colours as needed.
• Text contrast is sufficient, focus is visible, the form can be completed by keyboard.
• Images have alt descriptions, fields have labels, errors have human text.

Build readiness

• A developer reviewed the mockups before sign-off and confirmed it's buildable on schedule.
• Behaviour is documented: clicks, openings, animations, form behaviour.
• It's clear what's editable in the admin and what's hard-coded.
• Someone is named to accept design QA after the build.

If every item is a yes, hand it over with confidence. If more than three are a no, you're not ready — and the build won't patch those holes, it will set them in concrete. Want an outside look at your current site or at the mockups someone drew for you? Get in touch — we'll run it against this same list and tell you honestly what to fix first.

FAQ