A UX designer researches how people use a product, maps user journeys and flows, creates wireframes and prototypes, tests usability, and works with developers to turn those decisions into working software. For a CTO, the key value is reducing product uncertainty before unclear decisions become production code.
Good UX also covers what happens when software leaves the happy path. A payment can be pending, rejected, reversed, or completed after the client loses its connection. Designing these states early helps the interface, API, business rules, and test cases describe the same event consistently.
That is where UX becomes an engineering concern rather than a final visual layer.
What does a UX designer do?
A UX designer decides how users should complete tasks in a digital product and checks whether those decisions work.
The UK’s National Careers Service describes UX work as understanding user needs and creating websites, applications, and software around them. Typical tasks include gathering business requirements, creating and testing prototypes, writing specifications for developers, refining designs using research, and meeting accessibility standards.
Day-to-day work can include:
- user research
- customer journeys and user flows
- information architecture
- wireframes
- interactive prototypes
- usability testing
- accessibility
- loading, empty, success, and error states
- developer specifications
- design QA after implementation
- product iteration after release
The scope changes by company. A startup may ask one designer to cover UX, UI, research, and parts of product design. A larger organisation may separate UX research, interaction design, UI design, content design, and design-system ownership.
The job is broader than drawing screens. A designer needs to understand what the user is trying to achieve, what the software can do, and what can go wrong between those two points.
UX starts with the problem, not the screen
Good UX starts by defining the user’s task, the business requirement, and the constraints around both.
Consider a FinTech team building a withdrawal feature. A polished withdrawal screen is easy to draw. The real product decisions are harder.
The team needs answers to questions such as:
- Which users can withdraw money?
- Are limits different by account type?
- Is identity verification required first?
- What happens if the available balance changes?
- Can a withdrawal remain pending?
- Can the provider reject it after submission?
- Can an administrator review it?
- What happens after a network timeout?
- What information does customer support need?
Those decisions can affect the interface, API contracts, permissions, validation, data model, QA scenarios, and support workflows.
A similar problem appeared during Code & Pepper’s work on United4, a property crowdfunding platform. The team worked on individual and corporate user types, personas, user journeys, KYC requirements, administrator permissions, software architecture, and development backlogs. The United4 product design case study shows how product design and specification prepared the idea for development.
A UX designer therefore does more than make an existing requirement easier to use. UX work can expose requirements that the product team has not defined yet.
From research to working software
A useful UX process moves from evidence to structure, then from structure to tested interaction.
These stages can overlap. An Agile team does not need to finish every screen before development starts. The goal is to resolve high-risk product questions early and keep design close to implementation.
Research users and product context
User research identifies what people are trying to achieve, what blocks them, and how the product fits into their work.
Research can include interviews, observation, usability sessions, analytics, support tickets, surveys, product data, and stakeholder interviews.
The key distinction is evidence versus assumption.
“Users do not like our onboarding” is an assumption.
“Users repeatedly leave during identity verification, and test participants misunderstand why a document is required” gives the team a specific problem to investigate.
Research depth should match risk. A small settings change does not need the same research effort as a new KYC flow, insurance claim process, or patient portal.
Map journeys and user flows
A user flow describes the steps a person takes to complete a task.
A basic healthcare booking flow may look like this:
Choose service → select clinician → choose slot → enter details → provide consent → confirm
Production software introduces more states.
The appointment may disappear before confirmation. A patient may already have an account. Consent requirements may differ by service. An availability API may fail. A clinician may cancel later.
Mapping those branches helps product and engineering teams decide what the system should do before missing cases appear as bugs.
Structure the information
Information architecture determines where information and functions belong.
The problem becomes clear in data-heavy products.
An investment platform may contain holdings, transactions, performance, risk, documents, notifications, and account settings. Showing everything at once creates noise. Hiding too much creates unnecessary navigation.
The designer decides which information belongs together, what deserves priority, and what users need at each stage of a task.
Create wireframes before polishing the UI
Wireframes describe structure without spending much time on visual detail.
They help teams discuss hierarchy, navigation, forms, tables, actions, and content placement while changes remain relatively easy to make.
If a team is debating colours while a payment flow has no defined failed or pending state, it is solving the easier problem first.
Prototype risky interactions
A prototype lets the team test behaviour without building the production feature first.
The prototype does not need to cover the whole product. A small interactive model can test one uncertain interaction, such as onboarding, transaction review, permissions, or account recovery.
The purpose is to answer a question.
Can users complete the task? Do they understand the terminology? Do they know what happens next? Can they recover when something fails?
Test tasks, not opinions
Usability testing checks whether people can complete realistic tasks.
“Do you like this screen?” gives weak evidence.
“Move £500 from this account and tell me when you believe the transfer is complete” reveals much more.
The designer can see where the user stops, what they misunderstand, which control they expect, and whether they recognise success or failure.
The team can then change the product based on observed behaviour rather than taste.
Specify behaviour for engineering
A Figma file alone is not a complete development specification.
Engineers may also need:
- responsive behaviour
- component states
- field validation
- role permissions
- focus behaviour
- loading states
- empty states
- error states
- success states
- interaction rules
- design-system references
Design also needs to connect with the backlog, architecture, and acceptance criteria. Code & Pepper’s end-to-end software development process connects product strategy and UX/UI with full-stack development, AI and cloud integration, launch, and ongoing product work.
That connection matters because an interface eventually has to work with real APIs, permissions, data, latency, devices, and failure conditions.
Design the state machine, not only the happy path
Strong UX defines the system states a user can encounter and the safe actions available in each state.
Take a payment flow.
An early prototype might show:
Amount → Review → Confirm → Success
A production system may need something closer to:
Created → Authentication required → Processing → Confirmed
Other paths can include:
- authentication failed
- insufficient funds
- provider rejected
- request timed out
- payment still processing
- payment reversed
- duplicate request detected
- server completed the operation but the client lost the response
Now UX and engineering share the same problem.
Suppose the frontend request times out. Should the interface say “Payment failed”?
Not necessarily.
The provider may still be processing the transaction. If the UI reports failure and immediately encourages another attempt, the user could submit the operation again.
The right behaviour depends on the system design. The backend may expose a pending state. An idempotency mechanism may prevent duplicate operations. The client may need to query the final status before offering another action.
The technical lesson is simple:
The interface should communicate the state the system actually knows rather than treating an uncertain outcome as final.
The UX designer does not need to define backend architecture. The designer does need to understand enough about system behaviour to represent it accurately to the user.
UX designer vs UI designer vs product designer
UX, UI, product design, and UX research overlap, but each role has a different primary concern.
| Role | Main concern | Typical output |
| UX designer | How users complete tasks | Research, journeys, flows, wireframes, prototypes, usability findings |
| UI designer | How the interface looks and behaves | Layouts, components, visual states, design systems |
| Product designer | How design supports product goals | Research, UX/UI, experiments, product decisions |
| UX researcher | What users need and how they behave | Interviews, studies, observations, research findings |
One person can cover several areas.
A small SaaS company may work well with one experienced product designer. A larger platform with several products and user groups may need dedicated research, UI, content, and design-system specialists.
For a CTO, the title matters less than ownership. Someone needs to own user evidence, flows, interaction behaviour, accessibility, and design decisions.
What should a UX designer deliver?
Useful UX deliverables help the team make a decision, test an assumption, build a feature, or improve an existing product.
| Deliverable | Question it answers |
| Research findings | What do we know about users? |
| User journey | Where does the wider experience create friction? |
| User flow | How does a person complete this task? |
| Information architecture | Where should information and functions live? |
| Wireframe | What structure does the screen need? |
| Prototype | How should the interaction behave? |
| Usability findings | Where do users fail or hesitate? |
| Design system | Which patterns should teams reuse? |
| Handoff specification | What does engineering need to implement? |
| Design QA | Does the built feature behave as intended? |
Do not judge UX output by the number of screens.
Ten frames that resolve a risky transaction flow can be more useful than 100 polished screens built around an untested assumption.
Accessibility belongs in UX design
Accessibility should shape interaction decisions before development rather than become a repair task before release.
WCAG 2.2 is a W3C Recommendation for improving web accessibility for people with disabilities. It includes criteria related to areas such as keyboard access, focus, contrast, target size, status messages, and accessible authentication.
A designer should consider:
- keyboard navigation
- visible and logical focus
- colour contrast
- readable text
- clear form labels
- error identification
- touch target size
- alternatives to colour-only meaning
- authentication flows
The UK’s National Careers Service also includes meeting accessibility standards among the typical tasks associated with UX design.
WCAG guidance and legal compliance are not interchangeable. Legal duties depend on the product, organisation, and jurisdiction.
For a software team, the practical rule is clear. Accessibility requirements need to enter the design early enough for engineering and QA to implement and test them.
UX gets harder in regulated products
Regulated software combines user needs with security, privacy, permissions, data handling, business rules, and regulatory requirements.
The shortest flow is not always the right flow.
FinTech
Financial software needs to communicate money, identity, status, risk, and irreversible actions clearly.
Typical UX work can include KYC, payments, account connections, wallets, transaction histories, investment dashboards, authentication, permissions, and administrative workflows.
A required KYC step may add friction. Removing the requirement is not a UX solution. The design problem is to explain what users need to provide, ask for it at the right point, and give users a clear path when verification cannot be completed.
HealthTech
Healthcare interfaces may serve patients under stress and clinicians under time pressure.
A patient booking an appointment has different needs from a clinician reviewing information or an operations employee correcting a record.
Designers need to consider sensitive information, consent, cognitive load, accessibility, permissions, errors, and recovery. Legal, clinical, security, and compliance specialists still own decisions within their areas.
InsurTech
Insurance products often contain complex rules around coverage, claims, pricing, documents, and eligibility.
Good UX does not remove genuine complexity by hiding important information. It structures that complexity so users can understand what they need to provide, what has happened, and what happens next.
The same principle applies across regulated products. UX should make constraints understandable without pretending those constraints do not exist.
UX can include developer experience too
A product may have several kinds of users, including developers who integrate with it.
Code & Pepper encountered this with Oathello, a LegalTech product built around external integrations. The product needed experiences for business users, end users, and developers. The Oathello LegalTech case study also describes mobile document signing as requiring its own interface and user flow.
This is a useful edge case.
Sometimes the user is another developer. API structure, integration behaviour, documentation, authentication, and predictable errors can all affect that person’s experience with the product.
UX is therefore broader than a graphical interface.
How does a UX designer work with developers?
UX designers and developers should resolve behaviour together when a feature depends on technical constraints.
Suppose an API operation can take 30 seconds.
The design needs more than a spinner.
The team needs to decide:
- Can the user leave the page?
- Can the user safely retry?
- Could a retry duplicate the operation?
- Does the API expose a processing state?
- How does the client learn the final state?
- What happens after a timeout?
- Can the user find the operation later?
The designer defines what the user needs to understand and control. Engineers explain what the system can reliably know and do. Product leaders define the business rules. QA needs enough information to test the important paths.
That collaboration prevents the frontend from inventing behaviour that the backend cannot support.
Which UX design tools matter?
UX tools help designers research, model, prototype, communicate, and test decisions.
A designer may use Figma or similar software for wireframes, interface design, components, and prototypes. Teams may also use collaborative whiteboards, product analytics, research platforms, usability-testing tools, and project-management systems.
The specific tool is secondary.
A designer who can produce polished screens but cannot explain permissions, failure states, user evidence, or technical constraints creates risk.
AI can also speed up research synthesis, ideation, interface variants, documentation, and prototype production. Faster production does not validate the result. An AI-generated interface still needs user evidence, accessibility checks, technical review, and testing.
How much does a UX designer cost?
UX design cost depends on location, seniority, hiring model, research scope, and product complexity.
There is no single reliable project price for UX work. An employee, contractor, embedded specialist, and product design agency have different cost structures. A focused usability review also has a very different scope from the design of a regulated multi-role platform.
For project work, these factors matter most:
| Cost driver | Why it matters |
| Product complexity | More roles, states, and workflows create more design work |
| Research depth | Interviews and usability studies require recruitment and analysis |
| Platforms | Web, mobile, tablet, and admin interfaces add different constraints |
| Design system | Reusable components need definition and documentation |
| Regulated workflows | Permissions, consent, sensitive data, and audit needs add constraints |
| Handoff depth | Detailed behaviour requires more specification |
| Testing | More validation requires more research and analysis |
For the UK hiring market, the National Careers Service publishes a UX designer salary range of £32,000 for starters to £65,000 for experienced professionals. Those figures are employment salary benchmarks, not project or agency prices.
For US buyers, the safest approach is to price the actual engagement rather than substitute salary data from a broader occupational category for UX-specific pricing. Location, seniority, engagement model, research requirements, and product complexity can all change the commercial model.
The useful buyer question is not “What does one UX screen cost?” It is “Which product uncertainty does the designer need to resolve?”
How long does UX design take?
A narrow UX task can take days, while UX work on a complex product can continue throughout development.
A redesign of one onboarding step is different from discovering and prototyping an MVP. There is no credible universal UX timeline without a defined scope.
The main timeline drivers include:
- access to users
- number of user groups
- number of workflows
- research depth
- stakeholder availability
- technical dependencies
- number of platforms
- design-system requirements
- accessibility requirements
- speed of product decisions
For a CTO, timing is often more useful than a generic duration. High-risk flows should be researched and specified early enough that engineers do not need to invent missing product behaviour during implementation.
When should you hire UX expertise?
Bring in UX expertise when uncertainty about users or interaction behaviour creates product risk.
UX support is especially useful before a high-risk feature enters full development, when flows and requirements are still easier to change.
Warning signs include:
- onboarding repeatedly loses users
- support keeps explaining the same workflow
- developers make interaction decisions without product guidance
- permissions are difficult to understand
- product patterns have become inconsistent
- mobile workflows do not translate well from desktop
- a regulated flow is being introduced
- users make costly mistakes
- teams disagree based on opinion rather than evidence
The engagement model should follow the problem. A focused research task may suit temporary specialist support. Continuous product work may justify an embedded or in-house designer.
Code & Pepper’s guide to hiring a UX/UI designer goes deeper into the role and the relationship between UX/UI work and software delivery. It was published on July 8, 2026.
Do not hire a designer simply because the interface “needs a refresh.” Define the product problem first.
How to evaluate a UX designer before hiring
Evaluate how the designer makes decisions, not how polished the portfolio looks.
Ask the candidate to explain one project from problem to release.
Then ask:
- What evidence defined the problem?
- Which assumption turned out to be wrong?
- Which options did you reject?
- Which technical constraint changed the design?
- How did you test the flow?
- Which edge cases did you find?
- How did you specify errors and loading states?
- How did developers challenge the design?
- What changed after release?
For FinTech, HealthTech, and InsurTech, add domain-specific scenarios.
Ask how the candidate would communicate a pending payment. Ask how permissions should change an admin interface. Ask how sensitive information affects a screen. Ask what should happen when an external API returns an unknown state.
Generic portfolio questions become less useful when the product handles money, health information, permissions, or regulated workflows. Code & Pepper’s UI designer interview questions for FinTech and HealthTech teams focus on hiring in that context. The article was published on June 29, 2026.
A portfolio shows what somebody produced.
Their explanation shows how they reached the decision.
The value of UX is clearer product decisions
Good UX gives product and engineering teams clearer answers before ambiguous behaviour reaches users.
A designer may discover a missing permission while mapping an admin flow. A prototype may show that users misunderstand an account state. A usability test may expose a confusing KYC step. A state model may reveal that the frontend cannot safely describe a timed-out payment as failed.
Those findings matter because they change what the team builds.
If your team can describe the screens it wants but cannot clearly explain the states, permissions, failure paths, user evidence, and interaction rules behind those screens, adding more frontend capacity will not solve the underlying problem.
The product needs stronger design definition.
Code & Pepper’s UX design services for digital products are relevant when that definition needs to connect with product and software delivery rather than stop at interface mockups.
For a CTO, that is the practical role of UX: define what the product needs to do for its users clearly enough that the team can build, test, and operate it.
What is a UX designer?
A UX designer researches user needs and designs how people interact with a digital product. Typical work includes user flows, information architecture, wireframes, prototypes, usability testing, accessibility, and collaboration with developers.
What does a UX designer do every day?
Daily work can include analysing research, mapping flows, creating wireframes, building prototypes, running usability tests, reviewing product data, discussing requirements, and resolving implementation questions with engineers.
What is the difference between UX and UI design?
UX focuses on how a person completes a task and experiences the product. UI focuses on the visual and interactive interface, including layouts, typography, components, spacing, and visual states.
Does a UX designer need to know how to code?
Production coding is usually not the main responsibility. Technical knowledge still helps a designer understand components, APIs, responsive behaviour, accessibility, system states, and implementation constraints.
What skills are most important for UX design?
Core skills include user research, information architecture, interaction design, wireframing, prototyping, usability testing, accessibility, product thinking, analytical thinking, and clear communication with product and engineering teams.
What tools do UX designers use?
UX designers use interface and prototyping software, collaborative whiteboards, analytics, usability-testing platforms, and project-management systems. The tools matter less than the quality of the research and decisions they support.
How much does a UX designer earn?
The UK’s National Careers Service publishes a salary range of £32,000 for starters to £65,000 for experienced UX designers. Salary varies by market, seniority, role scope, and employment model. Project and agency pricing should be assessed separately.
How long does UX design take?
A narrow UX task can take days, while work on a complex product can continue for months or alongside development. A reliable estimate depends on user access, workflows, research depth, platforms, technical dependencies, and stakeholder decision speed.
When should a startup hire a UX designer?
A startup should bring in UX expertise when important assumptions about users or product behaviour are about to become expensive to change. Onboarding, payments, permissions, dashboards, claims, and healthcare workflows are common examples.
How does UX reduce software development risk?
UX can expose unclear flows, missing states, user misunderstandings, and contradictory requirements before or during implementation. Research, prototypes, and usability testing let teams examine product assumptions before committing the full engineering effort.