Interfaces people actually want to use
Research, flows, interface design and design systems for products and internal tools, because software nobody adopts is a failed project however correct the data model is.
- UX research
- User flows
- Design systems
- Prototyping
Design is not the coat of paint at the end
Three positions that shape everything below, and that we would rather state up front than have you discover halfway through.
- 01
Adoption is the metric
An internal tool people avoid is a failed project, however correct the data model is.
- 02
Design the empty states
Real software is mostly edge cases. We design the loading, error and nothing-here screens too.
- 03
Accessible by default
Contrast, focus order and keyboard paths are part of the design, not a retrofit before launch.
Six stages, each ending in something you can react to
Nothing here ends in a document that gets filed. Every stage produces an artefact you can look at, argue with and take to your team.
- 01
Research
Interviews and observation with the people who will actually use it.
User and task map
- 02
Flows
The paths through the product, argued out before anything is drawn.
Journey and flow diagrams
- 03
Wireframes
Structure and hierarchy at low fidelity, where change is still cheap.
Annotated wireframes
- 04
Interface
Visual design, states, empty cases and the awkward edges nobody mocks up.
High-fidelity screens
- 05
System
Tokens, components and rules so the tenth screen matches the first.
Design system
- 06
Prototype
A clickable build to test with real users before engineering commits.
Interactive prototype
From business challenge to working solution
Five stages, whichever practice you start with. Each one ends in something you can look at and react to.
Stage 01
Discover
Understand business objectives, users, workflows and challenges.
In Odoo ERP: Walk the order-to-cash and procure-to-pay cycles as they run today.
What comes out of it
- Stakeholder interviews
- Process walkthrough
- Requirement map
The questions worth asking before the first screen
Including whether you need us for the build at all.
Is design worth it for an internal tool nobody outside sees?
Often it matters more there than on a marketing site. Your team spends hours a day inside an internal tool, so a confusing screen is a recurring tax on every person using it, and the usual result is a shadow spreadsheet that quietly becomes the real system. Internal software is where good design pays back fastest and where it is skipped most often.
Can you design without building it too?
Yes. We hand over screens, states, a design system and a clickable prototype that another team can build from, and we are happy to review the build as it goes. The handover is the deliverable, not a hook to win the development work.
We already have a brand. Do you work within it?
Yes, and we would rather extend what you have than replace it. A brand gives us colour, type and tone; a product needs considerably more than that: states, density, data display, error handling. We build the product layer on top of your brand and hand back a system that stays recognisably yours.
How do you test designs without a live product?
With a clickable prototype and the people who will actually use it. Five or six sessions with real users reliably surfaces the problems worth fixing, and it costs days rather than the weeks it takes to discover the same thing after engineering has built it.
What does accessible by default mean in practice?
Contrast checked against WCAG AA as colours are chosen, not audited afterwards. Keyboard paths and focus order designed alongside the click path. Labels, error messages and empty states written as part of the design rather than filled in later. It is cheaper as a constraint than as a remediation project, and it makes the interface better for everyone using it.
Let’s build something that moves your business forward.
Tell us what you’re trying to improve, automate or build. We’ll help you identify the right technology approach. No obligation, no sales script.