Product UX/UI design
Scenarios, prototypes and interfaces for tools people work in every day: dashboards, portals, personal accounts and admin panels.
02 04 service 2 of 4 in Web Design
What’s included
- Research into how people actually use the thing, not how you assume they do
- User flows, information architecture, interactive prototypes
- Interface design for dashboards, portals, tools and admin panels
- Complex data made readable — tables, filters, forms people finish
- Onboarding and empty states treated as features, not afterthoughts
- Design decisions documented, so the next person knows why
Who it’s for
- Teams whose product works but nobody can figure out how to use it
- SaaS and services losing users somewhere between signup and value
- Founders whose interface grew feature by feature and now fights itself
In short
Product UX/UI is the design of tools people work in every day: dashboards, portals, personal accounts, admin panels and SaaS. We start by looking at how people really use the product, not how it is assumed, then build the scenarios, the information architecture and interactive prototypes, and only after that the interface. Complex data becomes readable, forms get filled in to the end, onboarding and empty states are treated as full parts of the product, and every decision is documented. The price is counted in hours and fixed before the start.
UX and UI: what is the difference
They are often written together, but they answer different questions. A product needs both.
| Criterion | UX | UI |
|---|---|---|
| The question | how does a person reach the goal? | what does the interface look like? |
| What it works with | scenarios, structure, steps, logic | components, typography, colour, states |
| The result | a prototype people can click through | finished screens and a component library |
| If it is missing | a beautiful product nobody can figure out | a logical product that looks unfinished |
From research to interface
The interface is the last step. Before it comes understanding what people actually do.
-
Research
Conversations with users, analytics and watching real sessions: where they get stuck and what they work around.
-
Scenarios
The key tasks step by step: what a person wants and how they get there in the fewest moves.
-
Information architecture
Sections, navigation and names that match how users think, not how the database is built.
-
Interactive prototype
A clickable model checked on real people before the expensive part begins.
-
Interface
Screens, components and states — in code, so they work exactly as drawn.
-
Documented decisions
Why it is built this way — so the next person does not undo a decision without knowing the reason.
Complex data made readable
Work tools live on tables, filters and forms. This is where most hours of users are spent — and lost.
-
01
Tables
Columns by importance, aligned numbers, sorting, sticky headers and a version for the phone.
-
02
Filters and search
The filters people actually use come first; the result is visible at once.
-
03
Forms filled to the end
Only necessary fields, clear errors next to the field, a saved draft.
-
04
Dashboards
Answers to questions, not walls of charts: what changed and what needs attention.
-
05
Roles
Each role sees its own tasks, not the whole system at once.
-
06
Bulk actions
What is done a hundred times a day is done in one move, with a way to undo.
Onboarding and empty states: where users are lost
Between sign-up and the first benefit, most SaaS products lose people. These screens are designed as fully as the main ones.
-
01
The first benefit fast
A person sees the result before they get tired of setting things up.
-
02
An empty screen that helps
Not “no data”, but what to do to see data here — with a button.
-
03
Examples and templates
A demo project or a template to start from instead of a blank page.
-
04
Hints in place
Short tips next to the action, not a ten-step tour nobody finishes.
Common product interface mistakes
-
Feature after feature
An interface that grew without a plan starts arguing with itself: the same action in three places.
-
The database instead of tasks
Screens repeat the tables of the database, not what a person wants to do.
-
Designing without users
Assumptions in a meeting room are cheaper than research only until launch.
-
A wow effect for a work tool
What impresses in a demo tires a person who works with it eight hours a day.
-
Unclear errors
“Something went wrong” instead of what happened and what to do now.
Questions about product UX/UI
How much does product design cost?
The price is counted in hours: it depends on the number of scenarios, roles and screens. The sum is fixed before the start; the estimate is free.
Do you need access to our users?
It helps a lot: a few conversations and access to analytics give more than any assumption. If there are no users yet, we work with the target audience.
Can you improve the UX of an existing product?
Yes: research, scenarios, a prototype and new screens. We do not edit someone else’s code — we hand the interface to your team as components and rules, or build the new version ourselves.
How do you know the new interface is better?
By numbers agreed at the start: the share of people completing the key scenario, the time it takes, the number of support requests.
Do you design admin panels?
Yes — an admin panel is the same product, only for your staff. Their hours cost money too.
Online form
Discuss
a product interface
Tell us what the product does, who works in it and where people get stuck — we will suggest where to start and estimate the work. The consultation is free.