User Experience Design Services: UX Deliverables Guide
Most design projects start with one request: "Can you design the screens?" It sounds like the obvious first step. But screens are answers, and most teams haven't agreed on the questions yet. Who is the product for? Which job are they trying to get done? Which workflows matter in version one? What belongs on which screen, and what do users actually call things?
Skip those questions and you can end up with a polished interface built on a weak structure. This guide shows what user experience design services should actually deliver before high-fidelity UI, stage by stage, and what each deliverable helps you decide. It's written for founders, product managers and teams hiring a design partner, whether or not that partner is us. If you already know you want help, our UI/UX design services page covers how we run these stages.
What Is UX Design?
UX design is the practice of shaping how a product works for the people who use it. It covers research into users and their goals, how information is organized, how people move through tasks, and how the product is tested and refined so users can do what they came to do.
In one line: UX design defines how a product should work for the user: what they need, what they do, how information is organized and how they move through the product.
What Is UI Design?
UI design is the practice of designing the visible, interactive layer of a product: the layout, typography, color, components, spacing and interaction states people see and touch. Good UI makes the structure defined in UX clear, readable, accessible and trustworthy on every screen and device size.
In one line: UI design defines how the product interface looks and communicates visually through layout, typography, color, components, spacing and interaction states.
UX vs UI Design: What's the Difference?
UX decides how the product should work. UI decides how that working product looks and communicates. The two overlap constantly, and on good teams they iterate together.
Core question
UX design: Does this product solve the right problem in a usable way?
UI design: Is the interface clear, consistent and appealing?
User research
UX design: Leads it
UI design: Uses findings, e.g. accessibility and context needs
Information structure
UX design: Defines it (IA, navigation model)
UI design: Expresses it visually
User flows
UX design: Maps them
UI design: Designs the screens and states inside them
Wireframes
UX design: Primary owner
UI design: Often contributes on layout
Visual hierarchy
UX design: Sets content priority
UI design: Makes priority visible through size, weight and contrast
Typography
UX design: Minor role (readability needs)
UI design: Owns it
Color
UX design: Minor role (meaning, accessibility)
UI design: Owns it
Components
UX design: Defines behavior
UI design: Defines appearance and states
Prototyping
UX design: Tests flows and logic
UI design: Tests look, feel and micro-interactions
Usability testing
UX design: Plans and runs it
UI design: Acts on visual findings
Final interface
UX design: Shapes what's on it and why
UI design: Delivers production-ready screens
What Do UX Design Services Actually Deliver?
Here's the framework that matters when you compare proposals. Each stage should produce something concrete, answer a specific question and protect you from a specific mistake. The right deliverables depend on the product's risks and maturity. A small internal tool might need a quick flow and wireframes. A new healthcare app with several user roles might need every row.
Product discovery
Typical deliverable: Problem statement, assumptions list, research plan
Key question it answers: What are we building, for whom, and what don't we know?
What it helps prevent: Building features for a problem nobody agreed on
User research
Typical deliverable: Findings report with themes, needs and pain points
Key question it answers: What do users actually need and do today?
What it helps prevent: Designing around internal opinions
Problem definition
Typical deliverable: Prioritized problems and V1 scope
Key question it answers: Which problems matter most right now?
What it helps prevent: An overloaded first release
Personas / jobs
Typical deliverable: Personas, segments or job statements
Key question it answers: Who are we designing for and what outcome do they want?
What it helps prevent: Designing for "everyone"
Information architecture
Typical deliverable: Sitemap, navigation model, labeling
Key question it answers: Where does everything live and what is it called?
What it helps prevent: Confusing navigation and duplicate features
User flows
Typical deliverable: Flow diagrams for core tasks
Key question it answers: How does a user complete each key task?
What it helps prevent: Dead ends, missing states and extra steps
Wireframes
Typical deliverable: Screen layouts at low or mid fidelity
Key question it answers: What goes on each screen and in what priority?
What it helps prevent: Buried actions and overloaded screens
Prototype
Typical deliverable: Clickable prototype of core journeys
Key question it answers: Can people actually use this flow?
What it helps prevent: Untested assumptions reaching code
Usability testing
Typical deliverable: Test plan, observed issues, recommended fixes
Key question it answers: Where do users hesitate, fail or get confused?
What it helps prevent: Shipping friction you could have seen
UI design
Typical deliverable: High-fidelity screens with states and responsive layouts
Key question it answers: How should this look and communicate?
What it helps prevent: Inconsistent, unclear or inaccessible screens
Design system
Typical deliverable: Components, tokens and usage rules
Key question it answers: How do we stay consistent as the product grows?
What it helps prevent: Duplicate components and visual drift
Handoff
Typical deliverable: Specs, states, flows, assets and source files
Key question it answers: Can developers build this without guessing?
What it helps prevent: Ambiguity that turns into rework
Stage 1: Product and UX Strategy
Strategy is where the team writes down what it believes and what it doesn't know yet. Useful inputs include the business goal, the target user, the current product (if there is one), known pain points, competitors and alternatives, technical constraints and a first guess at V1 scope.
The outputs can be short: a problem statement, a list of product assumptions, a research plan, priority workflows and feature hypotheses. A two-page document that the whole team agrees on beats a 40-slide deck nobody reads. The point is to make the next stage's questions explicit.
Stage 2: UX Research
Research replaces guesses with evidence. Common methods include stakeholder interviews, user interviews, a review of existing analytics, support-ticket analysis, surveys where they fit, competitive or alternative analysis, usability testing and contextual observation.
No project needs all of them. The method should match the question. "Why do trial users leave in week one?" calls for analytics plus interviews. "Do people understand our navigation labels?" calls for a quick test. This mirrors a principle in the human-centred design standard ISO 9241-210: design should be based on an explicit understanding of users, tasks and environments, and refined through evaluation in an iterative process.
What deliverables should you expect from UX research?
Research questions: what the team is trying to learn.
Interview or test notes: the raw evidence.
Themes and patterns: findings that repeated across people.
Jobs and needs: what users are trying to accomplish.
Pain points: where current workflows break down.
Behavioral insights: what users actually do, not what they say they do.
Risks and assumptions: what still needs validation.
Recommendations: which product decisions the evidence supports.
The last item is the one to insist on. Findings that don't connect to a decision are just interesting.
Do you always need personas?
No. Depending on the project, a team might use personas, user segments, jobs-to-be-done statements, role-based profiles or behavioral groups. Nielsen Norman Group describes personas and jobs-to-be-done as compatible: jobs focus on the outcome users want, while well-researched personas add behavioral and attitudinal context. Skip the invented details like favorite coffee brands. Keep only information that changes a product decision.
Stage 3: Information Architecture
Information architecture (IA) is how a product's content and features are organized, grouped and labeled so people can find what they need. Deliverables usually include a sitemap, a navigation model, content hierarchy, feature grouping, a labeling system and screen relationships. As NN/g explains, IA isn't the navigation itself. It's the structure that navigation is built on.
A project-management SaaS might settle on: Dashboard → Projects → Project Detail → Tasks → Reports. Good IA helps prevent duplicate features, confusing navigation, hidden functionality, inconsistent naming and screens nobody needs.
Stage 4: User Flows
A user flow is the step-by-step path a user takes to complete one task, including the decisions and branches along the way. For a new user of that project tool:
New user arrives
Creates an account
Creates a first project
Invites a teammate
Adds a task
Views the project
Drawing it exposes questions screens hide: what if the invite email bounces? What does an empty project look like? Can a teammate add tasks before accepting? Flows reveal missing states, dead ends, unnecessary steps, unclear decisions, role conflicts and missing error paths.
Information architecture vs user flow
Focus
Information architecture: Product structure
User flow: Task path
Main question
Information architecture: Where does information live?
User flow: How does a user complete a task?
Typical output
Information architecture: Sitemap and navigation model
User flow: Flow diagram
Stage 5: Wireframes
Wireframes explore page structure, content priority, layout, actions, navigation and interaction logic before visual polish. They don't have to be gray boxes. Fidelity can be low for early exploration or fairly detailed when the logic is complex. What matters is that the team is debating structure, not colors.
Wireframes catch a buried call to action, a missing critical field, hierarchy problems, overloaded screens, unclear navigation and workflow gaps. It is cheaper to move a box in a wireframe than to redesign and rebuild a feature after development.
Stage 6: Testable Prototypes
A prototype simulates navigation, core interactions, forms, key journeys and decision points without a production backend. It turns "we think users will do this" into something you can watch them try. If you want to move from flows to something clickable quickly, rapid software prototyping is one way to test the core flow before committing to a build. Our software prototyping guide covers what to validate at that stage.
Wireframe vs prototype
Primary purpose
Wireframe: Decide structure and priority
Prototype: Test how a flow works
Interaction
Wireframe: Usually static
Prototype: Clickable or interactive
Fidelity
Wireframe: Low to mid
Prototype: Low to high
Testing
Wireframe: Team and stakeholder review
Prototype: Usability testing with real users
Best question
Wireframe: What goes where?
Prototype: Can people actually do this?
Stage 7: Usability Testing
Usability testing means watching representative users attempt realistic tasks. NN/g's guidance on user testing treats it as an observational method: you learn from what people do, not their opinions.
So don't ask, "Do you like this?" Ask: "You need to invite a teammate to your project. Show me how you'd do that." Then watch for hesitation, wrong clicks, backtracking, terminology confusion, missing information and whether the task gets done at all.
Stage 8: UI Design
Once the structure and core flows are understood well enough, UI design defines layout, typography, color, visual hierarchy, components, interaction states, responsive behavior and accessibility considerations. "Well enough" matters. UI doesn't wait for every UX activity to be finished. Visual exploration often surfaces UX questions, and the two loop back on each other. For native apps, this stage also covers platform conventions, which carry straight into custom mobile app development.
Accessibility belongs in design, not just QA
Readable text, sufficient contrast, clear labels, helpful error messages, visible focus and interaction states, and sensible keyboard or navigation order should be designed in. For example, WCAG's contrast minimum sets 4.5:1 for normal text and 3:1 for large text. Design can't guarantee compliance on its own, because implementation matters too, but it's where most accessibility problems are cheapest to avoid.
Stage 9: Design System
A design system is a shared library of reusable components and the rules for using them. It typically covers buttons, inputs, forms, navigation, cards, modals, a typography scale, spacing, color, states and component rules. The payoff is consistency, faster iteration, clearer handoff and less duplicated work. An early prototype rarely needs a full system. A product with several teams or a growing feature set usually does.
What Should Developers Receive From UX/UI Design?
A good handoff can include final screens, responsive states, component behavior, design tokens where applicable, user flows, interaction notes, empty, loading and error states, assets, the prototype and design-system components. ISO 9241-210 lists communicating the design to the people implementing it as a design activity in its own right. Even a strong handoff doesn't replace conversation between design and engineering, which is why it helps when the team doing custom software development is involved before the last screen is signed off.
Why Research and UX Structure Should Inform Visual Design
If the team doesn't yet know who the user is, what they need, which task matters most, what belongs on screen or what the primary action is, polishing UI can lock in assumptions nobody tested. UI makes the product clear, usable and trustworthy visually. It works best when the underlying workflow is already grounded in user and product needs.
That's not a rule that UX must be "complete" before UI starts. It's an argument against jumping straight from idea to polished screens. Early UX work can reduce avoidable rework by exposing workflow, content and usability issues before they're embedded in development.
Example: Designing a SaaS Dashboard the Wrong Way vs the UX-First Way
Hypothetical example for illustration.
Screen-first approach. A team building a project-management SaaS goes straight to high-fidelity designs for a dashboard, analytics, settings, projects and a team page. The dashboard gets the most attention because it looks impressive in demos. After launch, user feedback shows people mostly need one path: Projects → Tasks → Approvals. The analytics they designed so carefully rarely get opened, and the approval step is buried two levels deep.
UX-led approach. Interviews reveal the core job: getting work approved without chasing people. The IA puts that path first: Projects → Tasks → Approval → Status. Wireframes and a quick prototype test whether users can find and complete an approval. Only then does UI bring that validated structure to life, with analytics added later where evidence supports them.
Does an Existing Product Still Need UX Research?
Usually, yes, but it starts from different evidence. An existing product can draw on analytics, funnel drop-off, search queries, support tickets, session recordings, user interviews, usability testing and customer feedback. A redesign shouldn't mean "make it look modern." It should fix specific product problems you can name and measure.
Main evidence
New product: Interviews, competitor and alternative analysis, assumptions
Existing product: Analytics, support tickets, recordings, current users
Research focus
New product: Is the problem real, and what's the core job?
Existing product: Where does the current experience break down?
Key risk
New product: Building the wrong thing
Existing product: Redesigning the wrong thing, or breaking habits users rely on
Useful deliverables
New product: Problem statement, V1 scope, flows, prototype
Existing product: Issue audit, revised IA, redesigned flows, before/after tests
Can You Buy UX Design Without Full Development?
Yes. Many teams buy UX in stages: research and strategy, IA and flows, wireframes, a prototype, UI, a design system, and development only when they're ready. Buying in stages helps control scope, lets you validate before committing, and lets you resolve one uncertainty at a time. It's an option, not a requirement. Some teams prefer one partner from research to launch. At Techallin, every stage of our UX design services can be bought on its own, including design without development.
How Long Does UX Research Take?
There's no honest universal number. Timelines depend on how many user groups you need to hear from, which methods you use, how hard participants are to recruit, how much existing data you have, how complex the product is, how many workflows you're covering and how risky the decision is. A focused round on one workflow with existing users moves much faster than research across several roles in a regulated industry. Ask any agency to tie its estimate to those drivers.
How Much Does UX Design Cost?
Cost follows the same drivers: research depth, participant recruitment, number of workflows, screen count, prototype fidelity, testing rounds, design-system scope and responsive requirements. Get proposals that price stages separately so you can see what you're paying for.
What Should You Ask a UX Design Agency Before Hiring Them?
What will you research before designing?
Why it matters: Shows whether design decisions will rest on evidence
Which assumptions are we testing?
Why it matters: Forces risks into the open early
What deliverables will I receive?
Why it matters: Prevents paying for vague "design work"
Will I get user flows?
Why it matters: Flows expose missing states and dead ends
Will I get wireframes?
Why it matters: Structure gets debated before polish
Is a prototype included?
Why it matters: Without one, usability can't really be tested
How do you test usability?
Why it matters: Tells you if testing means real tasks or opinions
Do I receive source design files?
Why it matters: Avoids being locked to one vendor
Is a design system included?
Why it matters: Affects consistency and future speed
Can I buy stages separately?
Why it matters: Lets you validate before committing more budget
How does handoff to developers work?
Why it matters: Weak handoff turns into rework
How do you handle iteration?
Why it matters: Shows how findings actually change designs
UX design red flags
Starts with visual style before understanding the product
Can't explain their research method or why it fits
No clear list of deliverables
No user-flow thinking
Designs only the happy path
No empty, loading or error states
No plan for testing
Personas built on guesses
Can't say how findings changed the design
Polished mockups with no rationale
One red flag isn't always a dealbreaker. A small, well-understood project may not need formal research. But several together suggest you're buying decoration, not design.
How Do You Know Whether UX Work Helped?
Pick metrics that connect to the original problem. Depending on the product, that could be task success, time on task, error rate, drop-off, completion rate, support requests, feature adoption, the number and severity of usability issues, or conversion where it's relevant. Measure a baseline first. A metric that has nothing to do with the problem you set out to solve won't tell you much.
How Techallin Approaches UI/UX Design
Techallin grounds UI decisions in product strategy, user flows and UX work first, then iterates as the product becomes clearer. Our current stages are research and strategy, information architecture (sitemap, navigation and user flows), wireframes and a clickable prototype for user testing, UI design with interaction states and responsive layouts, a design system your team can extend, and an optional build. You own every design file and component, and every stage is led by a human designer, with any AI-assisted output reviewed before it reaches you.
Our work on Cindera, a patient request platform for U.S. hospitals, shows why structure comes early. The product serves patients, caregivers, nurses, support staff and hospital leaders, and requests have to route to the right role and move through a clear status path: Sent → Seen → On the Way → Resolved. The 16-week engagement covered UX research, design, build, QA and deployment. Cindera's founder, David Evans, said the team "took the time to understand the problem before jumping into screens."
When the design is validated, it can move into a production-ready MVP, or stay as a design-only engagement with all source files.
Frequently Asked Questions
What do UX design services include?
UX design services typically include product strategy, user research, problem definition, information architecture, user flows, wireframes, prototypes and usability testing. Many agencies also offer UI design, design systems and developer handoff. Not every project needs every stage. The right mix depends on how much you already know about your users and how risky the product decisions are.
What is the difference between UX and UI?
UX design defines how a product works for users: their needs, tasks, information structure and flows. UI design defines how the interface looks and communicates through layout, typography, color, components and interaction states. They overlap and usually iterate together, but UX answers "does this work?" while UI answers "is this clear and consistent visually?"
What deliverables should I expect from UX research?
Expect research questions, raw notes from interviews or tests, synthesized themes, user jobs and needs, pain points, behavioral insights, open risks and assumptions, and recommendations tied to product decisions. Personas are optional. The most important output is the link between evidence and decisions, so you know why the design looks the way it does.
Do I need UX research before UI design?
You need enough understanding of users, tasks and core flows to make UI decisions with confidence. That might be a few interviews and a flow diagram, or a full research round. UX and UI often iterate together. What causes trouble is jumping from an idea straight to polished screens with no evidence behind the structure.
What is information architecture?
Information architecture is how a product's content and features are organized, grouped and labeled so people can find what they need. It's usually documented as a sitemap, navigation model and labeling system. IA isn't the navigation menu itself; it's the structure that navigation and screens are built on.
What is a user flow?
A user flow is the step-by-step path a user takes to complete one task, such as signing up or inviting a teammate, including decisions, branches and error paths. Flows expose dead ends, missing states and unnecessary steps before anyone designs or builds the screens.
What is a wireframe?
A wireframe is a simplified layout of a screen that shows structure, content priority, actions and navigation without final visual styling. Fidelity can range from rough sketches to detailed grayscale layouts. Wireframes let teams agree on what goes where before spending time on visual polish.
What is a testable prototype?
A testable prototype is a clickable simulation of key journeys, such as onboarding or checkout, that real users can try without a production backend. It turns assumptions into something you can observe. If users can't complete the core task in a prototype, it's far cheaper to fix there than after development.
Can I buy UX design without development?
Yes. Many teams buy research, flows, wireframes, a prototype or UI as separate stages and decide on development later. This helps control scope and validate before committing. Make sure you receive source design files and clear handoff documentation so any development team can build from the work.
How long does UX research take?
It depends on the number of user groups, research methods, participant recruitment, existing data, product complexity, number of workflows and decision risk. A focused study on one workflow moves faster than research across several user roles in a regulated industry. Be wary of any fixed timeline that ignores those drivers.
Do I need a design system?
Not always. An early prototype or small product can work with a simple component set. A design system pays off once several people design or build the product, the feature set grows, or consistency starts to slip. It defines reusable components, tokens and rules so the product stays coherent as it scales.
How does UX reduce development rework?
Early UX work can reduce avoidable rework by exposing workflow, content and usability problems while they're still cheap to change, in a flow diagram, wireframe or prototype. It doesn't eliminate rework entirely, because real usage always teaches something new, but it moves many expensive surprises earlier.
See Your Core Product Flow as a $19 Prototype in 24 Hours
Not ready to commit to full UI design or development? Start by mapping the core user journey, then turn the flow into a testable prototype before investing in the full build.
Get a $19 prototype in 24 hours, book a free consultation, or see how our product design services work stage by stage.
Tell us what you are building. We will recommend the right first step.