Design
UI/UX Design
For applications, portals and tools. A marketing site people visit once is web design, and it is a different problem with a different measure of success.
UI and UX design is for products people return to repeatedly, where the interface has to be efficient rather than merely persuasive. The Nexclick maps the tasks, prototypes the flows, and tests them before anything is built — because rebuilding a shipped feature is the expensive version.
Is this you?
What usually prompts the call
- Your product works and every new user needs it explained to them.
- Support tickets cluster around the same three screens.
- Users complete the first step of a flow and drop out at the third.
- Features get built, shipped, and then quietly go unused.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Task mapping before screen design
- What users are actually trying to accomplish, in what order, and where the current interface makes it harder. Screens designed before this is understood tend to be redesigned later.
- Evidence gathering from the existing product
- Support tickets, session recordings and funnel data. The three screens generating most of your tickets are usually the three worth redesigning first.
- User interviews where access allows
- Five or six conversations with actual users surfaces more than any amount of internal debate. Where users are not reachable, we say so rather than substituting assumption for research.
- Interactive prototypes
- Clickable flows tested before development. Finding a flow does not work in a prototype costs an afternoon; finding it after release costs a sprint and a migration.
- Interface design across every state
- Loading, empty, error, partial and success. Products fail on the states nobody designed far more often than on the happy path.
- Accessibility designed in
- Keyboard operation, focus order, contrast, and labelling planned at design time. Products are used daily by people who rely on it, and retrofitting is far more expensive here than on a marketing site.
- Developer-ready specification
- Components, spacing, states and behaviours documented so the build matches the design without a fortnight of clarifying questions.
Comparison
The states everyone forgets to design
Products break on the states nobody designed, not on the happy path. This is the checklist we work through per screen — most designs we inherit cover the first row and none of the rest.
| State | When it happens | What goes wrong without it |
|---|---|---|
| Default / populated | Normal use | Nothing — this is the one everyone designs |
| Empty | First use, or all items deleted | A blank screen that looks broken and teaches nothing |
| Loading | Slow connection or heavy query | Users click twice, or assume it has failed |
| Partial load | Some data arrives, some does not | Layout jumps as content fills in |
| Error | Request fails or validation rejects | A raw error message, or silent failure |
| No results | Search or filter returns nothing | Indistinguishable from a broken feature |
| Permission denied | User lacks access | A dead end with no explanation or route onward |
| Offline | Connection drops mid-task | Work lost silently |
| Long content | Names, titles or lists longer than expected | Truncation, overflow, broken layout |
| Single item | A list designed for many contains one | Layout looks unfinished or wrong |
| Maximum content | A list of 500 where 5 was assumed | Unusable page, no pagination designed |
| Success confirmation | Action completes | User repeats the action, unsure it worked |
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1–2
Understand the tasks
Task mapping, existing-product evidence and user interviews where possible. This determines what to design and, as usefully, what not to.
- 02Week 2–4
Prototype the flows
Low-fidelity first, clickable, tested with real users where they are reachable. Cheap to change at this stage and expensive later.
- 03Week 4–7
Design the interface
Visual design across every screen and every state, with two structured review rounds.
- 04Week 7–9
Specify and support the build
Component documentation, handover, and availability during development for the questions that always arise.
What you get
Reporting and ownership
- A task map showing what users are trying to do and where the current product obstructs them.
- Clickable prototypes tested before anything is built.
- Every state designed — loading, empty, error, partial — not just the happy path.
- A developer-ready component specification with behaviours and states documented.
- Editable source files transferred to your ownership.
Tools and platforms
- Figma (design and prototyping)
- Session recording tools
- Support ticket analysis
- Usability testing sessions
- WCAG contrast and keyboard testing
Timeline
How long this actually takes
Seven to nine weeks for a substantial product area. Research adds a week or two and reliably saves more than it costs. The constraint is usually access to users: where we can speak to five or six real ones, the work is considerably better, and where the company is protective of that access, the design rests on internal assumption instead. We will always ask, and we will be explicit in the deliverable about which decisions were evidenced and which were reasoned. That distinction matters when something later turns out to be wrong.
Pricing model
Fixed-price project
Fixed price by scope, or a day rate for ongoing product design alongside a development team. Research can be scoped in or out, and we will recommend in.
Questions
UI/UX Design questions
Do we need user research, or can you just design it?
We can design without it and the result will rest on assumption. Five or six conversations with real users typically changes at least one significant decision and costs a week. Where access genuinely is not possible, we proceed and state clearly in the deliverable which decisions were evidenced and which reasoned.
What is the difference between UI and UX?
UX is the structure — what the flow is, what happens in what order, whether the task is achievable. UI is the surface: layout, type, colour, components. They are separable in theory and rarely worth separating in practice, since a beautiful interface over a broken flow fails and vice versa.
Can you work alongside our development team?
Yes, and it works considerably better than designing in isolation and throwing it over. Attending your planning sessions, answering questions during the sprint and reviewing the built result catches the small divergences that otherwise accumulate into something nobody designed.
How do you test a design before it is built?
Clickable prototypes in Figma, put in front of five or six real users completing a specific task. It is not perfect — a prototype is not a product — and it reliably catches the flows that do not work, which is where the expensive mistakes are.
Do we need a design system as well?
Only if more than one person will produce work in this product, or it will keep growing. For a single well-scoped area, a component set within the design files is sufficient. For a product with a roadmap and a team, a system pays for itself within months. We will say which you are.
What if our developers cannot build what you designed?
That is a scoping failure on our side and we would rather catch it early. Technical constraints get established during discovery, and where something is genuinely difficult the specification says so with an alternative. Designs that ignore what the stack can do are decoration.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.