UI/UX design services that reach production intact
UI/UX design is two disciplines. UX design decides what the screens are and in what order. UI design decides how they look and how they behave. InApps runs them as separate roles, grounded in user research rather than opinion, and hands over Figma files annotated tightly enough that engineers build them without a Slack thread per screen.
Trusted by engineering teams across 15+ countries - from startups to Fortune 500.
Why most product design fails to convert
Six things we hear on almost every first call. Not one of them is solved by a redesign that starts in Figma.
Users drop off at the one step that was supposed to convert, and nothing in your analytics says why.
A design that tests well internally and falls over the first time a real user meets it.
UI that looks like three teams built it in three different years, because they did.
No design system, so every new feature reopens the argument about buttons, spacing and colour.
A handoff that costs twenty Slack threads per feature to establish what was actually meant.
A mobile experience that was designed for desktop and scaled down afterwards.
UI and UX are two jobs, not one hyphenated one
Is the problem the layout, or the flow that led to it?
One designer doing both is how you get neither
UX design is research, information architecture, user flows and wireframes. It answers what the screens are, in what order, and why. UI design is the visual system on top: type, colour, spacing, components, states and motion. It answers how those screens look and behave.
Most agencies staff one designer across both, and research is what gets cut, because it is the part nobody can see in a portfolio. We staff them separately. A researcher runs the interviews and usability tests, a UX designer owns the architecture, a UI designer owns the visual system, and a design lead owns the handoff. On a small engagement two people cover four roles, and we tell you which two before you sign.
What UX design covers
The decisions taken before anything looks like anything.
- User interviews and behavioural analysis of what people actually do
- Competitive audit and heuristic evaluation of the product you have
- Journey maps naming where the friction is, not where it feels like it is
- Information architecture and user flows for every primary journey
- Wireframes signed off before a single visual decision is made
What UI design covers
The system that makes the tenth screen as fast to build as the first.
- High-fidelity screens at every breakpoint you actually ship
- Design tokens, components and the rules for using them
- Every state drawn: empty, loading, error, disabled, too much data
- Motion and micro-interaction specified in units an engineer can read
- A prototype real enough to put in front of a user and learn something
Six engagements, one delivery standard
Embedded in your product team, or end-to-end ownership of a design project. Both start with the same discovery and end with the same annotated files.
Product design
End-to-end product design services for a product that already has users and a number that is not moving. We start with the behavioural data and the interviews, not with a redesign brief.
Deliverables Research synthesis · Journey map · Prioritised design backlog · High-fidelity screens
Mobile app UI/UX design
Mobile app UI UX design services for iOS and Android, designed at mobile first rather than scaled down from a desktop layout. Platform conventions respected, because users notice when they are not.
Deliverables Native patterns per platform · Touch target audit · Offline and error states · App store assets
Web app and SaaS interfaces
Dense, data-heavy screens where the hard part is hierarchy, not decoration. Tables, filters, dashboards, permissions and the states nobody remembers to design until QA finds them.
Deliverables Responsive screens per breakpoint · Table and filter patterns · Empty and error states · Accessibility pass
Design systems
A token set, a component library and the rules that stop the next feature reopening the argument. Built to hand to engineers as Storybook components, not just as a Figma page nobody opens twice.
Deliverables Design tokens · Component library · Usage guidelines · Storybook parity check
UX audit and usability testing
A two to three week read on a product you already shipped. Heuristic evaluation, moderated testing with real users, and a ranked list of fixes with the effort against each one.
Deliverables Heuristic findings · Session recordings · Ranked fix list with effort · Retest after implementation
Design for a new product
A first version that has to prove something rather than cover everything. If you want the build as well as the design, that is MVP development, and the design work folds into it rather than sitting beside it.
Deliverables Concept directions · Clickable prototype · Usability test results · Build-ready screens
Agency, freelancer, in-house, or us
Three of these four are the right answer for some products. Here is the comparison without the part where we win every row.
| Criterion | InApps | Design agency | Freelance designer | In-house hire |
|---|---|---|---|---|
| User research | Included, by a researcher who is not the designer | Usually included, often the same person | Quoted separately, if offered | Whatever one person has time for |
| Design system | Tokens and components, handed over as Storybook | Figma library, code parity rare | Rarely, and rarely maintained | Yes, once there is time to build one |
| Usability testing | Moderated sessions before and after launch | Varies by scope and budget | Varies | Depends on recruitment support |
| Developer handoff | Annotated files reviewed by an engineer before delivery | Dev-mode file, questions by email | Sometimes annotated | Direct, which is the real advantage |
| Design QA during build | Included until the release ships | Usually ends at handoff | Ends at invoice | Included |
| Who builds it | Your engineers, or ours on the same contract | Not our problem | Not our problem | Your engineers |
| Time to start | Two to three weeks from brief | Often a queue of four to eight weeks | Fast, if they are free | Three to four months to hire |
| Scaling down | Two weeks notice, no minimum term | Retainer, often a minimum term | Immediate, and the context leaves with them | A headcount conversation |
From user research to developer-ready design
Seven weeks to a design system and a full screen set on a typical product. Every stage ends in something you can review, not a status update.
Research and discovery
We talk to your users and look at what they do, not what they say they do. If you have analytics we start there.
Architecture and wireframes
Structure settled in grey boxes, where changing your mind is cheap. Nothing visual until this is signed off.
Visual design and design system
The system first, then the screens. Building the tokens before the tenth screen is what keeps the tenth screen fast.
Handoff and design QA
We stay through implementation. The build gets reviewed against the file, and the file gets corrected where the build was right.
UI/UX design and development services, on one contract
A design file is not a product. Most agencies stop at the handoff because building is somebody else's job. We are an engineering company that designs, so the handoff can be internal.
An engineer reads the file before you do
Every deliverable is reviewed by one of our own developers before it reaches you, against one question: could you build this without asking anything? Whatever they ask, we annotate. That review is why the handoff does not generate twenty threads a feature.
The design system arrives as code, not just as Figma
Tokens exported in the format your stack consumes, and components mirrored in Storybook so a developer can diff the built component against the designed one. A Figma library with no code counterpart drifts within two sprints.
Design QA runs against the build
We review each release against the file and log the differences with the same severity language your engineers already use. Some of those tickets close by changing the design, because the build was right and the file was not.
Or we build it
Same contract, same design lead, no second discovery phase. For an existing product that is custom software development; for a first version it is MVP development. If you would rather add designers to your own team and keep delivery in-house, that is staff augmentation and we will say so.
Four stages before a designer touches your product
Five per cent of design applicants get through. Research, UX and UI are separate roles here, so each one is vetted against its own work rather than against a general portfolio.
Portfolio and design challenge
- A real brief with real constraints
- Portfolio review across product work
- Walkthrough of the reasoning, not the pixels
Communication and English
- Defending a decision to a sceptical stakeholder
- Client-facing scenario
- Written and spoken English
Agile collaboration and ownership
- Working inside an engineering cadence
- Ownership and accountability
- Taking critique without taking it personally
Final review and reference check
- Panel interview with a design lead
- Reference and background check
- Culture and values alignment
Five things move the number, and screen count is only one
We do not publish a rate card, because a per-hour figure tells you nothing about a design project. These are the five variables we ask about on the first call, in the order they matter.
| Driver | What pushes it up | What brings it down |
|---|---|---|
| Unique screens | Counting features instead of screens. Forty features can be twelve screens or ninety. | A design system built early, so screen forty costs a fraction of screen four. |
| Research depth | A market you have never sold to, or no analytics on the product you have. | Existing users we can interview, and session data we can read on day one. |
| Design system | Building one from nothing, including the brand decisions nobody has made yet. | Extending a system you already have, even a partial or inconsistent one. |
| Platforms | Web, iOS and Android each need their own patterns, not one layout resized. | Picking the one platform that has to be right first and following later. |
| Who builds it | Design QA against an engineering team we have no contract with and cannot schedule. | One contract covering design and the build, which removes a handoff phase entirely. |
What we work in, and what leaves with you
Everything below is a tool you can take over. No proprietary file format, no design held hostage in an account we own.
Design and prototyping
Figma for everything, because it is where your engineers already are and it produces the most readable handoff. FigJam and Miro for discovery workshops. Framer or Webflow when a marketing site should ship without an engineering ticket. Files live in your Figma org, not ours.
Research and testing
Maze for unmoderated tests at volume, moderated sessions for the questions Maze cannot ask. Hotjar and Mixpanel for what users already do before we change anything. Notion as the research repository, so a finding from month one is still findable in month nine.
Handoff to code
Design tokens exported to whatever your stack consumes, usually Tailwind config or CSS custom properties. Storybook so a React component can be diffed against the designed one. LottieFiles for motion that would otherwise be a paragraph of prose. Zeplin if your team already runs it.
Ask the people who stayed
Every quote below is from a verified review. None of them were written by us.
“Clear expectations, rules that actually hold, delivered on time. And the people are genuinely easy to work with, not just professionally, but as humans.”
Worth the call, or worth a no on the call
Design services are the wrong shape for plenty of good products. Here is where this works and where we will point you elsewhere.
This works well if
- You are a B2B or SaaS company with a product in market and a conversion or retention number that will not move.
- Your engineers are ready and the design is the bottleneck, not the other way round.
- You want research in the engagement rather than quoted as an extra nobody approves.
- You need a design system that survives the next three features, not one redesign.
This is not a fit if
- You want a designer sitting in your team on your sprint board under your design lead. That is staff augmentation, it costs less, and we will tell you so.
- What you actually need is a logo, a brand system or a campaign. We are a product design team, not a brand agency, and the good ones are not us.
- You need the product built and the design is incidental. Start at MVP development or custom software development, where design is folded in rather than billed beside.
- You have already decided what the screens look like and want them drawn. We will do it, but you are paying for research you have overruled.
Everything you need to know
Still deciding?
Send us the screen or the flow that is not working. We will tell you on the first call whether it is a design problem, and what it probably is if it is not.
Book a design discovery callWhat are UI/UX design services?
How much do UI/UX design services cost?
Which design tool do you use?
Do we need user research if we already know our users?
How do you make sure developers build the design accurately?
Can you work with our existing design system and brand?
How long does a UI/UX design project take?
Can you build the product as well as design it?
Show us the screen that is losing people
No credentials deck and no portfolio parade. Send a link, a flow or a Figma file and we will come back with what we think is wrong, what it would take to fix, and whether it is a design problem at all.