Technology · UX/UI
UX/UI for digital products and complex systems.
User journeys, prototypes and a visual system engineering can implement consistently.
When clients usually bring us in
- the existing system no longer keeps up
- the work happens in spreadsheets
- data is duplicated across systems
- you need a new application
- you want to modernise an old system
- you're building a new digital product
You don't always have to build from scratch
If the existing system can be properly modernised or connected to others, that's usually faster and cheaper than a new application. We start by looking at what's worth keeping.
What this means for you
- Fewer spreadsheets and manual status updates.
- Less duplicated data across systems.
- One view of the process for management and the team.
- A system that grows with the company.
- Less dependence on the one person who knows how it works.
Problem → solution
What you get
- user and task inventory
- user journeys
- wireframes and a clickable prototype
- visual system and components
- documented design system
- admin interfaces
- user testing
Product design is not website design
A visitor looks at a website once and leaves. The same person opens a business product every day and spends hours in it. So different things matter: how many clicks a frequent task takes, whether the system state is visible, and whether it can be driven from the keyboard.
A beautiful landing screen does not save a product. The screens someone opens a hundred times a week do.
Website
First impression, clear message, fast loading, one job: an enquiry or a purchase.
Product
Repeated tasks, lots of data, several roles, and mistakes that have to be recoverable.
The screens that get forgotten
A design that only shows the system when everything is fine does not tell development enough. The missing states then get invented on the fly, each one different.
- the empty state, before there is any data
- loading on a slow connection
- an error that tells the user what to do
- long text and names that do not fit
- a list with a thousand rows and a list with three
- permissions: what each role sees and does not see
- confirmation before an irreversible action
What development actually needs
A picture of a screen is not enough. So development does not guess, the design must also say what happens on click, what is mandatory, what happens on error and how the screen behaves in a narrower window.
- reusable components rather than one-off screens
- behaviour notes for every input and button
- spacing, sizes and colours as values, not pictures
- a clickable prototype to agree on before development
- accessibility: contrast, keyboard, screen reader
How the work runs
Brief
What the work has to achieve, for whom and in which environment it will be used.
Research
A review of the current state, the competition and user expectations.
Concept
A proposed direction that you approve before production starts.
Design and system
Final assets plus the rules for using them, so it stays consistent when you produce content yourselves.
Related work
FAQ
Can we produce content ourselves later?
Yes. You get templates and usage rules so the look stays consistent.
Do you work with our existing team?
Yes, we often take on only the part your team doesn't cover.
Related solutions
Sounds like your project?
Send us the project description, your existing system, the tender documents or the event date.