UX/UI design services: an interface built on research and tested with users.

We wrote this guide for product, marketing and corporate site teams who want to see, based on evidence, why their site or app wears users out. In describing the UX UI design process, we draw on the human-centered design standard ISO 9241-210, W3C’s accessibility documentation and WCAG 2.2 (Web Content Accessibility Guidelines), the user research guides in the GOV.UK Service Manual, Apple’s Human Interface Guidelines, Google’s Material Design system and Figma’s help center, Figma Learn; the sources are numbered at the bottom of the page. We verified product names and features against the source as of September 2026. Our own field observations are marked separately under the heading “Expert note”.

Our work runs in three layers: research that finds the user’s task and where they get stuck, information architecture and interaction that test the task in a prototype, and an interface and design system that tie decisions to components and accessibility rules.

What do UX and UI mean, and how do they differ?

UX (user experience) is the whole of the experience a person has while using a product; UI (user interface) is the screens, components and interactions that experience passes through. The concept that makes UX measurable is usability: W3C defines usability as designing products to be effective, efficient and satisfying, and counts user experience design within this field.² According to the ISO 9241-11 definition W3C cites, usability is the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.² The definition’s three conditions take UX out of the realm of taste: could the user finish the job, how much effort did it take, and were they satisfied?

UI is the visible face of these questions: where the button sits, how an error is shown, whether focus is visible when navigating with a keyboard. An interface that looks good but makes the task longer carries a UX problem; that’s why we run UX design and UI design as two layers of the same work.

Why does UX UI design rest on a human-centered process?

The human-centered design process rests on a cycle of research, design and evaluation, repeated throughout the product’s life, in which decisions are made on evidence from users. ISO 9241-210:2019 sets out requirements and recommendations for human-centered design principles and activities throughout the life cycle of computer-based interactive systems; it’s written for those managing design processes.¹ The standard doesn’t go into the detail of methods and techniques; it leaves detailed usability and accessibility topics to other parts of ISO 9241 and other standards.¹ The second edition, published in July 2019, was reviewed and confirmed in 2025.¹

We build the methods side on the research guides the GOV.UK Service Manual wrote for public services. GOV.UK recommends treating every opinion and suggestion that doesn’t come from users as an assumption that needs to be proven by research.³ This principle changes the language of meetings: a suggestion that starts with “I think” isn’t rejected; it goes on the list of things to test.

What does UX research start with?

UX research starts with reading the evidence you already have before collecting new data. As ways of getting to know users, GOV.UK lists reviewing existing evidence such as analytics, search logs, call center data and previous research reports, talking to and observing actual or potential users, and talking to people who work with those users.³ The guide defines a user need as a need the service must meet for the user to get the right outcome, and asks that needs be written in words the user would recognize and use themselves.³

Each method shows one side of the problem; before prioritizing, we expect at least two methods to show the same problem:

We cover session recordings and funnel analysis on our CRO consulting page.

How are user interviews done?

User interviews are done with questions that, without asking participants what they want, get them to describe how they do the job today through lived examples. According to GOV.UK, in-depth interviews help you learn about different types of users, their circumstances, how they use a service and what they need from it; they can last between 30 minutes and 2 hours depending on the complexity of the topic and the number of questions.⁴ The guide recommends open, neutral questions such as “how do you do that?” and follow-up questions such as “can you tell me more about that?”, and asks you to focus on stories and real examples rather than how things “should” work.⁴

GOV.UK writes that an interview can be combined with a moderated usability test: you talk to the participant first, then ask them to try a prototype or the service.⁴

How are user flows and wireframes built?

A user flow is built by drawing, in a single diagram, the steps a task goes through from its entry point to the target screen, with its decision points and error paths; a wireframe turns each step into a screen draft stripped of color and imagery. We draw a flow with five parts:

1. Entry point: a search result, an ad, an email link or an app notification; each entry point is drawn separately.
2. Steps: every screen or screen state the user sees; a pop-up window is a separate step too.
3. Decision points: questions that branch the flow, such as member or guest, in stock or not; every branch must have an end.
4. Error and empty states: invalid input, no results found, a dropped connection; screens that aren’t drawn in most projects but where users often get stuck.
5. Target screen: the screen that clearly shows the task is complete; the key event in measurement is defined here too.

In wireframes we decide only on content priority, navigation and form structure; because there’s no color or imagery, stakeholders’ attention stays on whether the flow is right. Before moving to a prototype, we check that every screen is tied to a need and to a step in the flow; a screen that can’t be tied to one comes out of the flow.

Why should a prototype be clickable?

A prototype should be clickable because users show their real behavior only while moving through the flow; comments made on a static screen remain opinions. According to Figma, prototyping features let you build interactive flows to explore how a user might interact with your design; with these flows you get feedback from the team and test interactions with users.⁵ Four of Figma’s prototyping concepts describe how a connection works:⁵

• Connection: the arrow that links an interaction point to a destination screen.
• Trigger: the interaction that advances the prototype, such as a click, a tap, a hover or a drag.
• Action: the type of progress, such as moving to another screen or opening an external URL.
• Destination: must be a top-level frame placed directly on the canvas; an object inside a frame can’t be a destination.

In Figma, the network of frames and connections on a page is called a flow; a prototype can have several flows showing different tasks, and each flow opens from a starting point.⁵ For testing, you can share a link to the whole prototype or to the starting point of a single flow.⁵ On sites where most visitors come from phones, we run the test on a phone; a flow tested on desktop can get stuck in other places on a touchscreen.

How is usability testing run?

In usability testing, the participant is given a realistic task and asked to think aloud while trying it, and the moderator running the session mostly stays quiet and watches where they get stuck. GOV.UK defines moderated testing as a method where you watch participants try to complete specific tasks using a service; the test helps you see whether users understand what they need to do, and find language and layout problems.⁶ Thinking aloud makes it easier to understand what the participant is doing, thinking and feeling.⁶ Here’s how we set up the test on GOV.UK’s recommendations:⁶

According to W3C, usability processes and user involvement alone can’t solve every accessibility problem.² So where possible we include participants who use screen readers or magnification in testing, and in every case we audit the interface separately against WCAG 2.2.

What does a design system and component library get you?

A design system stops the same decision from being made again on every screen: a button, a field or a card is defined once and used everywhere from the same source. In Figma, the main component defines the properties; instances are copies linked to the main component and receive updates made to it.⁷ Components can be shared across files and folders with a team library.⁷

The layer below the component is design tokens. Material Design defines tokens as small, reusable design decisions that make up a design system’s visual style; each token consists of a code-like name and a value, and they fall into three classes:⁸

According to Material, when the designer’s drawing and the engineer’s code are tied to the same token, both sides use the same color even if the value is updated later; tokens also reduce confusion at handoff.⁸ According to the same document, tokens are less useful in an app written with hard-coded values that isn’t expected to change in the next year or two, or in a product without a design system.⁸ That’s why we choose the system’s scope based on the size of the product.

Material Design defines six states to show a component’s interaction state: enabled, disabled, hover, focused, pressed and dragged.⁹ For accessibility, each state has two visual indicators; states such as selected and hover can also combine.⁹

How is accessibility built into the interface?

Rather than auditing accessibility after the design is done, we write it into components’ sizes, colors and states as rules from the start; our yardstick is WCAG 2.2. WCAG 2.2 was published as a W3C Recommendation on 5 October 2023 and added nine new success criteria; the 2.0 and 2.1 criteria stayed essentially the same, except for the removed 4.1.1 Parsing.¹⁰ Four of the new criteria are at level AA and directly affect the interface:¹⁰

• 2.4.11 Focus Not Obscured (Minimum, AA): a component receiving keyboard focus isn’t entirely hidden by the page’s own content; we audit sticky headers and bottom bands against this criterion.
• 2.5.7 Dragging Movements (AA): every function done by dragging can also be done with a single pointer without dragging, unless dragging is essential.
• 2.5.8 Target Size (Minimum, AA): a target selected with a pointer is at least 24 × 24 CSS pixels, except for defined exceptions such as spacing, an equivalent control and inline text.
• 3.3.8 Accessible Authentication (Minimum, AA): no step of authentication requires a cognitive function test unless that step offers one of the defined alternatives.

Two new criteria at level A are also part of our audit: 3.2.6 Consistent Help requires help mechanisms repeated across pages to appear in the same order relative to other content; 3.3.7 Redundant Entry requires information requested again in the same process to be auto-populated or available to select, except for defined exceptions.¹⁰

Apple’s Human Interface Guidelines recommend a separate default and minimum control size for each platform: on iOS and iPadOS, the default size is 44×44 pt and the minimum is 28×28 pt.¹¹ Apple’s Accessibility Inspector tool uses WCAG AA values when assessing contrast: at least 4.5:1 for text 17 points and smaller, and 3:1 for 18-point text and bold text at any size.¹¹ The document also recommends that text can ideally be enlarged by at least 200 percent (140 percent on watchOS).¹¹

In web interfaces we treat WCAG 2.2 AA as the floor, and leave touch areas close to Apple’s default value for primary buttons used often on phones.

How do our UX/UI design services run through the first 30 days and handoff?

The first 30 days are given to a cycle of research, flows and testing; after that, the approved design is handed over to development with a delivery that leaves no state to guesswork. The first four weeks go in this order:

1. Week 1 · Evidence and plan: analytics, support logs and previous research are read; priority tasks and the interview guide are drawn up.
2. Week 2 · Interviews and needs: user interviews are held, and findings are turned into the user need pattern.
3. Week 3 · Flows and prototype: flows and wireframes for priority tasks are drawn, and a clickable prototype is built in Figma.
4. Week 4 · Testing and decision: the prototype is put through usability testing; the scope of the next phase is set together.

Figma Dev Mode, which we use at handoff, is according to Figma a developer-facing interface for navigating design files and translating designs into code: finished sections, frames and components are marked “Ready for dev”, measurements and notes are added with annotations, and frame versions can be compared.¹² Dev Mode is available on all paid plans and requires a Full or Dev seat.¹²

We cover work that spans the whole site on our corporate website page.

UX agency, freelance designer or in-house team: what’s the difference?

Who does the UX/UI work decides whether research and the interface stay in the same hands.

How should you choose a UX/UI design agency?

However good the screens in a portfolio look, only testing with users shows whether an interface works. Ask about these points in the meeting:

1. Research source: what research are decisions based on; do they talk to users, or only to managers?
2. Testing: is the prototype tested with realistic tasks, written so they don’t give away the answer?
3. Accessibility criteria: what is the interface audited against, for example WCAG 2.2 AA?
4. Handoff: are error, empty list, loading and disabled states drawn at handoff, and how are measurements and notes passed to developers?
5. File ownership: whose name are the Figma team space, the component library and research recordings opened in?
6. How results are stated: task success measured before and after, rather than a promised conversion increase.

What determines UX/UI design pricing?

The cost of UX/UI work depends more on the scope of research and testing than on the number of screens:

We work out the scope together in the first meeting, then send a written proposal. If a paid tool such as Figma is needed, the license is opened in your name and paid directly to the tool provider.

UX/UI design pricing: starting prices and ranges

The lower end of each range is the starting price; excluding VAT. Scope is confirmed in a written proposal after the first meeting. As of October 2026.

If you’d like to see together which task your users struggle with, pick a meeting day that suits you below; in the first meeting we settle the priority tasks and the data you already have.