The UX design process is a six-stage loop: Discovery, Define, Ideate and wireframe, Prototype, Test and iterate, then Launch and measure. Most UK practitioners build it on the Double Diamond, a framework created by the British Design Council in 2005, which alternates divergent thinking (explore widely) with convergent thinking (narrow down). For UK budgets in 2026, a small website UX project runs £3,000 to £8,000, a full website redesign £8,000 to £25,000, and a SaaS or platform build £25,000 to £80,000. Contract UI/UX day rates sit around £460 to £700, averaging roughly £546. Accessibility is not a final step: WCAG 2.2 has been the monitoring standard since October 2024, and UK public sector bodies must meet Level A and AA. The process is a loop, not a line. You discover, you build, you measure, and you go round again.
Last updated: June 2026
- What Is the Double Diamond and Why Does It Matter in the UK?
- What Happens During UX Discovery and Research?
- How Do You Define the Problem With Personas and Journey Maps?
- What Is Information Architecture and Wireframing?
- Why Does Prototyping De-Risk a Digital Product Before Build?
- How Do Usability Testing and Iteration Loops Work?
- How Does UI Design and Handoff to Development Happen?
- How Is Accessibility Woven Through the Whole Process?
- What Does the Transformation Junction UX Process Look Like?
- Frequently Asked Questions
What Is the Double Diamond and Why Does It Matter in the UK?
The Double Diamond is a four-phase design framework, Discover, Define, Develop and Deliver, created by the British Design Council in 2005, and it remains the spine of how serious UK digital products are built. The two diamonds describe a rhythm of thinking. In the first half you explore a problem widely (Discover), then sharpen it into a single clear brief (Define). In the second half you generate many possible solutions (Develop), then ship and refine the one that works (Deliver). Each diamond opens out and then closes in. That opening and closing is divergent and convergent thinking, and it is the engine of the whole process.
Why does it matter that the framework is British? Because it shaped how the UK public sector builds digital services. The Government Digital Service (GDS) and the GOV.UK Design System both lean on this discover-then-define discipline, and the Government Service Standard formalises it into assessments that public-facing services must pass. If you are building anything that touches central or local government, NHS, or regulated sectors, this is not academic. It is the vocabulary your assessors will use.
Our view, after twelve years of delivery: the Double Diamond is a thinking tool, not a project plan. Treat it as four stages on a Gantt chart and you will build the wrong thing efficiently. The value is in the discipline of staying open before you commit. The most expensive mistakes in UK digital products are not bad buttons; they are confidently solving a problem nobody had.
| Double Diamond phase | Mode of thinking | Core question | Typical output |
|---|---|---|---|
| Discover | Divergent | What is actually going on? | Research findings, insights |
| Define | Convergent | Which problem do we solve? | Problem statement, personas |
| Develop | Divergent | What could the solution be? | Wireframes, prototypes |
| Deliver | Convergent | Does the solution work? | Tested product, metrics |
The honest rule: never skip the first diamond. Clients often want to jump straight to screens because screens feel like progress. They are not progress if they answer the wrong question. The Discover and Define phases are cheap insurance against very expensive rework. A week of research saves a month of redesign.
What Happens During UX Discovery and Research?
Discovery is the structured exploration of who your users are, what they are trying to achieve, and where the current experience fails them, and it produces evidence rather than opinions. This is the open half of the first diamond. The goal is breadth: talk to enough people, watch enough real behaviour, and read enough data that patterns emerge. You are not looking for confirmation of a plan. You are looking for surprises, because the surprises are where the value hides.
A solid UK discovery phase usually blends several research methods, because no single method tells the whole story. Qualitative methods explain why; quantitative methods tell you how much and how often. The strongest discoveries triangulate the two.
- User interviews: six to twelve one-to-one conversations, semi-structured, focused on tasks and frustrations rather than feature requests.
- Surveys: wider reach to validate whether the interview themes hold across a bigger sample.
- Contextual observation: watching people use the existing product or a competitor's, in their real environment, not a lab.
- Stakeholder workshops: aligning the business on goals, constraints, and what success means before a line of design is drawn.
- Competitor and heuristic analysis: auditing rival products against usability principles to find the gaps you can win.
- Analytics review: mining existing data (drop-off points, search terms, support tickets) for evidence of where users struggle.
Be sceptical if a supplier promises a finished design after one kick-off call. That is selling templates, not building a product. Real discovery takes time, and on a UK project it typically accounts for fifteen to twenty-five per cent of the budget. Skimp here and you pay for it threefold in the build.
| Research method | Tells you | Best for | Typical UK cost |
|---|---|---|---|
| User interviews | Why people behave as they do | Early discovery | £1,500 to £4,000 |
| Surveys | How widespread a pattern is | Validation at scale | £500 to £2,000 |
| Contextual observation | What people actually do | Complex workflows | £2,000 to £5,000 |
| Analytics review | Where users drop off | Existing products | £500 to £2,500 |
For data-driven products, this is also where we map what should be automated versus what genuinely needs a human. A good discovery often reveals that half the "design problem" is really a process problem, which is where business process automation earns its keep long before any screen is sketched.
How Do You Define the Problem With Personas and Journey Maps?
The Define phase synthesises everything you learned in Discovery into a single, sharp problem statement, supported by personas and journey maps that keep the whole team pointed at the same user. This is the convergent close of the first diamond. You take a messy pile of findings and you narrow it to a decision: this is the user, this is their goal, this is where it breaks, and this is what we will fix first. Define is where research becomes a brief.
Personas are not demographic cartoons. A useful UK persona is built from real interview data and describes goals, context, pain points, and the jobs the user is trying to get done. "Sarah, 34, likes coffee" is useless. "A self-employed plumber who needs to invoice from a van between jobs and abandons anything that takes more than two minutes" is a design constraint you can build against. The honest rule: if a persona could not change a design decision, it is decoration.
The customer journey map is the other half of Define. It lays out the user's path across stages, the actions they take, the questions in their head, and the emotional highs and lows. Mapping it exposes the gaps between what the business thinks happens and what actually happens. Those gaps are your opportunity backlog.
| Journey stage | User action | User thought | Design opportunity |
|---|---|---|---|
| Awareness | Searches for a solution | "Can this even help me?" | Clear value above the fold |
| Consideration | Compares options | "Is this trustworthy?" | Social proof, transparent pricing |
| Decision | Signs up or buys | "How long will this take?" | Frictionless onboarding |
| Retention | Returns to use it | "Was this worth it?" | Habit loops, quick wins |
By the end of Define you should be able to write the problem statement on a single line: "How might we help [persona] to [achieve goal] given [constraint]?" If your team cannot agree that sentence, you are not ready to design. Going further would just be expensive guessing. We have walked back from kick-off meetings more than once because the Define line did not hold, and every time it saved the client money.
What Is Information Architecture and Wireframing?
Information architecture (IA) is how you organise and label content so users can find what they need, and wireframing is the low-fidelity sketch of each screen's structure before any visual styling is applied. Together they open the second diamond. Now you are exploring solutions, but cheaply, in greyscale boxes, where changing your mind costs minutes rather than days of development.
IA usually starts with a card sort. You write every piece of content on a card and ask real users to group and name the groups. The clusters they form become your navigation. This matters more than people expect: most "the site is confusing" complaints are IA failures, not visual ones. If users cannot build a mental model of where things live, no amount of polish saves you.
Wireframes then turn that structure into layouts. They answer questions of hierarchy and flow: what is the most important element on this screen, what does the user do next, what happens on error. Because wireframes carry no colour, type, or imagery, stakeholders critique the logic instead of bikeshedding the shade of blue. That is the point. Keep it ugly on purpose until the structure is right.
- Sitemap: the bird's-eye view of every page and how they connect.
- User flows: the step-by-step path through a key task, including decision points and error states.
- Low-fidelity wireframes: grey-box layouts that fix hierarchy and content priority.
- Content model: what data each screen needs, which drives any custom CRM development or backend work underneath.
Our stance: wireframe more than feels comfortable. Teams rush past wireframes to get to "real" designs, then discover structural problems in high-fidelity mockups where they are ten times harder to fix. A wireframe is a hypothesis about how the product should work. Test the hypothesis before you spend money making it beautiful. The cheapest place to be wrong is in greyscale.
| Fidelity level | What it shows | Tool | Cost of change |
|---|---|---|---|
| Sketch | Rough idea | Paper, whiteboard | Seconds |
| Low-fi wireframe | Structure, hierarchy | Figma, Balsamiq | Minutes |
| High-fi mockup | Visual design | Figma | Hours |
| Coded build | Working product | Front-end stack | Days |
Why Does Prototyping De-Risk a Digital Product Before Build?
Prototyping de-risks a build because it lets real users click through a realistic version of the product and reveal problems before a single line of expensive production code is written. A prototype is a working illusion: screens linked together in a tool like Figma so a tester can tap, scroll, and fail in ways that expose flawed assumptions. Catching a flow problem in a prototype costs an afternoon. Catching it after launch costs a sprint and a reputation.
Prototypes climb a fidelity ladder. Early on, a clickable low-fidelity prototype tests whether the structure makes sense: can someone complete the core task at all? Later, a high-fidelity prototype with real visuals and micro-interactions tests whether the experience feels right and whether edge cases (empty states, errors, loading) hold up. The closer to launch, the more realistic the prototype should be.
The maths is simple and brutal. The cost of fixing a usability defect rises sharply at each stage: cheap in a wireframe, moderate in a prototype, painful in code, and ruinous in production. A prototype is the last cheap checkpoint. Skipping it to "save time" is the single most common false economy we see on UK projects.
- Build the happy path first: prototype the core task end to end before any secondary flows.
- Add the unhappy paths: errors, empty states, slow connections, and edge cases that real users hit.
- Put it in front of users: five participants surface roughly eighty-five per cent of usability problems.
- Iterate, then raise fidelity: fix structural issues at low fidelity, then polish what survived.
For products with conversational interfaces, the prototype stage is where we pressure-test dialogue flows long before integration. An AI chatbot development or AI voice agent project lives or dies on how the conversation handles being misunderstood, and you only find that out by letting real people try to break it in a prototype. Designing the happy path is easy; designing graceful failure is the craft.
How Do Usability Testing and Iteration Loops Work?
Usability testing puts real users in front of the prototype, gives them tasks, and watches where they hesitate, fail, or misunderstand, and iteration is the disciplined loop of fixing those problems and testing again. This is the heart of the second diamond's convergent close. You are not asking people whether they like the design. You are giving them a job and measuring whether they can do it. Opinions are noise; task completion is signal.
A moderated usability test follows a script. You set a task ("find and book the earliest available appointment"), stay quiet, and observe. You record completion rate, time on task, error rate, and the moments of friction. The classic finding from research is that five participants per round expose the large majority of issues, so it is far better to run three small rounds than one big one. Test, fix, test again.
This is also where divergent and convergent thinking reappear. When a test surfaces a problem, the team diverges to generate several possible fixes, then converges on the one to try, then tests it. That loop is the product getting better in public, repeatedly, on purpose. The myth that design is a straight line from brief to launch dies here. Good products are not designed once; they are designed, tested, and redesigned until the data says stop.
| Test metric | What it measures | Healthy target |
|---|---|---|
| Task success rate | Can users complete the task? | Above 90 per cent |
| Time on task | How long the task takes | Trending down each round |
| Error rate | Mistakes per task | Near zero on core flows |
| System Usability Scale | Perceived ease of use | Above 68 (above average) |
Our honest stance: clients sometimes resist testing because they fear it will delay launch or expose their assumptions. Both fears are backwards. Testing protects the launch date by catching problems while they are cheap, and exposing a wrong assumption in a test room is a gift, not an embarrassment. The expensive version of that lesson is a one-star review and a refund request.
How Does UI Design and Handoff to Development Happen?
UI design applies visual craft, colour, typography, spacing, imagery and motion, to the validated structure, and handoff is the disciplined process of passing those designs to developers with everything they need to build them faithfully. This is the Deliver phase made concrete. The structure is proven; now you make it beautiful, consistent, and buildable. Crucially, UI comes after the experience works, not instead of it. A gorgeous interface over a broken flow is lipstick on a problem.
Serious teams do not design screens one at a time. They build a design system: a single source of truth for components (buttons, forms, cards, navigation), tokens (colour, type scale, spacing), and the rules for using them. The GOV.UK Design System is the canonical UK example, and it exists precisely because consistency at scale is impossible by hand. A design system makes the product faster to build, easier to maintain, and consistent across every screen and developer.
Handoff is where many projects quietly fail. The design looks perfect in Figma and ships looking wrong because the developer guessed at spacing, states, or behaviour the designer never specified. Good handoff removes the guessing.
- Specs and tokens: exact values for spacing, colour, and type, exported as code-ready tokens.
- Component states: default, hover, focus, active, disabled, error and loading, all designed, not left to chance.
- Responsive behaviour: how each layout reflows across mobile, tablet and desktop breakpoints.
- Annotations: interaction notes, animation timing, and accessibility requirements attached to the relevant screens.
The handoff is the seam between design and engineering, and seams are where products tear. We keep designers and developers in the same conversation through the whole build, which is far cheaper than the alternative: a beautiful prototype and a disappointing product. Whether the output is a web application or a mobile app, the design system is the contract that keeps the built thing faithful to the designed thing.
| Handoff artefact | Purpose | Who uses it |
|---|---|---|
| Design tokens | Consistent colour, type, spacing | Front-end developers |
| Component library | Reusable building blocks | Designers and developers |
| Interaction specs | Define states and motion | Front-end developers |
| Accessibility notes | WCAG conformance per component | QA and developers |
How Is Accessibility Woven Through the Whole Process?
Accessibility is designed in from Discovery onward, never bolted on at the end, because retrofitting an inaccessible product is far more expensive and far less effective than building it right from the first wireframe. WCAG 2.2 has been the monitoring standard in the UK since October 2024, and it sets the bar for whether disabled users can actually use what you build. For many organisations this is also a legal duty, not a nicety.
UK public sector bodies are bound by the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, which require websites and apps to meet WCAG Level A and AA and to publish an accessibility statement. The Equality Act 2010 extends a duty to make reasonable adjustments to private organisations too. So while only the public sector faces the specific regulations, any UK business can face a complaint if its digital product excludes disabled users. Be sceptical of any agency that treats accessibility as an optional extra line item.
Woven through the process, accessibility shows up at every stage. In Discovery you include disabled users in research. In Define your personas include assistive-technology users. In wireframing you plan logical reading order and focus paths. In UI you check colour contrast and tap-target size. In testing you test with screen readers and keyboard-only navigation. Done this way, accessibility costs little. Done at the end, an audit and remediation can run anywhere from £600 for a small site to several thousand for a complex platform.
| Accessibility activity | When in the process | Typical UK cost |
|---|---|---|
| Inclusive research | Discovery | Built into research budget |
| Contrast and focus checks | UI design | Minimal if designed in |
| Screen-reader testing | Usability testing | £500 to £2,000 |
| Full WCAG 2.2 audit (SMB) | Pre-launch | £600 to £5,000 |
| Public-sector GDS-aligned audit | Pre-launch | £3,000 to £7,000 |
Our position is blunt: accessibility is good design, not charity. The same things that help a screen-reader user, clear structure, predictable navigation, readable contrast, generous targets, help everyone on a small phone in bright sunlight on a patchy connection. Designing for the edge improves the centre. There is no version of "great UX" that excludes a chunk of your users.
What Does the Transformation Junction UX Process Look Like?
Transformation Junction runs a five-stage UX process built on the Double Diamond, with fixed-quote pricing agreed before work starts so you never face a surprise invoice. We are a London-based agency in Stanmore (HA7) and we have spent over twelve years building software, automation and digital products for UK businesses. Our process keeps designers, developers and the client in one continuous conversation, because the handoff seam is where most projects quietly fail. Here is exactly how we work.
- Discover and align: stakeholder workshop, user research, analytics and competitor review. We leave this stage with evidence, not assumptions.
- Define and map: personas, journey maps, and a single agreed problem statement. If we cannot write the problem on one line, we do not move on.
- Design and prototype: information architecture, wireframes, then a clickable Figma prototype that real users can test.
- Test and refine: moderated usability rounds with five users at a time, fixing and re-testing until the data says the experience holds.
- Build, launch and measure: UI design system, clean developer handoff, accessible build, then post-launch measurement and iteration. The process is a loop, so launch is a checkpoint, not the end.
We quote fixed prices against a defined scope after a short paid discovery, so the figure you approve is the figure you pay. Transformation Junction Limited is registered at Companies House, and our pricing reflects real 2026 UK market rates rather than offshore guesswork.
| Project type | Typical timeline | Starting price | What you get |
|---|---|---|---|
| Small website UX | 3 to 5 weeks | From £3,000 | Research, wireframes, UI, accessible build |
| Website redesign | 6 to 10 weeks | From £8,000 | Full discovery, prototype, testing, design system |
| SaaS or platform | 10 to 20 weeks | From £25,000 | End-to-end UX, multi-round testing, dev handoff |
| Enterprise transformation | 20 weeks plus | From £100,000 | Research programme, design system, phased delivery |
If your product also needs automation, a CRM, or an AI layer underneath the interface, Transformation Junction builds that in the same engagement rather than handing you off to a third party. That is the advantage of being a full-stack AI automation agency as well as a design studio: the experience and the engine are designed together. You can see our full approach on the about page, or tell us about your project directly.
Frequently Asked Questions
How long does a UX design process take in the UK?
It depends on scope. A small website UX project typically runs three to five weeks. A full website redesign takes six to ten weeks, and a SaaS or platform build runs ten to twenty weeks or more. Skipping discovery to go faster usually adds time later through rework, so the honest answer is that proper discovery saves weeks overall.
How much does UX design cost in the UK in 2026?
Small website UX projects run £3,000 to £8,000, a full website redesign £8,000 to £25,000, and SaaS or platform builds £25,000 to £80,000. Enterprise transformation programmes start around £100,000. Contract UI/UX day rates sit between £460 and £700, averaging roughly £546, while agency hourly rates range from £60 to over £200.
What is the Double Diamond design process?
The Double Diamond is a four-phase framework, Discover, Define, Develop and Deliver, created by the British Design Council in 2005. It alternates divergent thinking, exploring widely, with convergent thinking, narrowing down. The first diamond finds the right problem; the second finds the right solution. It is the spine of most professional UK UX work, including GOV.UK services.
Is UX design the same as UI design?
No. UX (user experience) is about how a product works: research, structure, flows and whether users can achieve their goals. UI (user interface) is about how it looks: colour, typography, spacing and visual polish. Good UI sits on top of solid UX. A beautiful interface over a broken flow is still a poor product.
How many users do you need for usability testing?
Roughly five participants per round surface about eighty-five per cent of usability problems, which is why running several small rounds beats one large one. You test, fix the issues, then test again with five fresh users. Three rounds of five tells you far more than a single session with fifteen people ever could.
Do I legally need an accessible website in the UK?
UK public sector bodies must meet WCAG Level A and AA under the Public Sector Bodies Accessibility Regulations 2018 and publish an accessibility statement. Private businesses are not bound by those specific regulations but still have duties under the Equality Act 2010 to make reasonable adjustments, so an inaccessible product can attract complaints regardless of sector.
What is WCAG 2.2 and when did it apply?
WCAG 2.2 is the Web Content Accessibility Guidelines version that became the UK monitoring standard in October 2024. It sets testable success criteria across three levels, A, AA and AAA, for making digital content perceivable, operable, understandable and robust. UK public sector services are expected to meet Level A and AA against this version.
Why is prototyping important before building?
A prototype lets real users click through a realistic version of the product before any production code exists. Fixing a flow problem in a prototype costs an afternoon; fixing it after launch costs a sprint and your reputation. The cost of correcting a usability defect rises sharply at each stage, so the prototype is the last cheap checkpoint.
Should I hire an in-house designer or a UX agency?
In-house suits a steady, ongoing product with continuous design work. An agency suits a defined project, a redesign, or work needing a range of skills (research, UI, accessibility, development) at once. For most one-off builds, an agency delivers the full process for a fixed quote without the overhead of a permanent hire.
Is the UX process linear or a loop?
It is a loop, not a line. You discover, define, design, test, launch and measure, and the measurement feeds straight back into the next round of discovery. Treating it as a one-way line from brief to launch is the most common myth. Great products are designed, tested and redesigned continuously after they go live.
Great UK digital products are built on a six-stage loop anchored in the British-born Double Diamond: Discover, Define, Ideate, Prototype, Test, then Launch and measure. Discovery and Define find the right problem; wireframing, prototyping and testing find the right solution; UI and handoff make it real; and accessibility threads through every stage rather than arriving at the end. The numbers that matter: small website UX from £3,000, redesigns £8,000 to £25,000, platforms £25,000 to £80,000, day rates around £546, and WCAG 2.2 as the standard since October 2024. The single biggest lesson from twelve years of delivery is that the cheapest place to be wrong is early, in greyscale, before code. Skip discovery and you build the wrong thing efficiently. Respect the loop, test with real users, and design accessibility in from the first sketch, and you ship products people actually love to use, then keep making them better.
Ready to build a digital product your users love? Talk to our team about a fixed-quote UX engagement through our London software development service, or tell us about your project on the contact page.
Written by Deen Dayal Yadav, Founder of Transformation Junction, a London-based software development and UX design agency in Stanmore (HA7). With over 12 years building software, automation and digital products for UK businesses, Deen leads a team that designs and builds web applications, mobile apps, CRMs and AI systems end to end. Transformation Junction Limited is registered at Companies House. Learn more about our approach and team on the about page.
