Design the journey first, then the screens that make it usable
UI/UX for software is not “beautiful designs.” It is the design of jobs: what the operator sees when the queue is empty, when a payment fails, when a role cannot access a record. We work through user journeys, information architecture, wireframes, prototypes, usability, design systems, responsive layouts and developer handoff, alongside engineering, not as a PDF thrown over a wall.
Product design is not a coat of paint
If the data model cannot express the job, no layout will save it. We therefore start with objects, states and permissions, the same conversation as custom software, then we draw the screens that make those states visible. A dashboard that cannot answer “what do I do next?” is a failure, even if it photographs well.
Problems this work is for
- Screens that ignore roles
Everyone sees everything. Dangerous actions sit next to casual ones. Design should make authority visible.
- A prototype that only shows success
No empty states, no validation, no permissions. Engineering fills the gaps inconsistently.
- Visual refresh on a confusing structure
New colors, same maze. Navigation and naming are the UX problem.
- Mobile and desktop as unrelated products
Jobs split awkwardly. We map which jobs belong on which surface before drawing both.
- Forms that fight the domain
Fields in the wrong order, required too early, or missing the exception the staff always needs.
- Design files engineers cannot implement
Unnamed styles, magic numbers, no component states. Handoff is part of the deliverable.
What we typically deliver
- User journeys and information architecture
The path through a job, including branches and waits. Navigation and naming that match how people search for work.
- Wireframes and prototypes
Structure before visual polish. Clickable enough to review with operators, not a slideshow of success.
- Usability and states
Empty, loading, error, permission denied. The screens people actually live in.
- Design systems
Components, type, spacing and patterns reused across the application, not a one-off artboard per page.
- Responsive design
Layouts that work on the devices your users actually have, with jobs mapped to those surfaces.
- Developer handoff
Specs that sit next to implementation when we also build, or a clean file set if you implement in-house.
Where this usually shows up
- SaaS settings and day-1 experience
Onboarding that does not dump an empty tenant on a confused admin.
- Operations consoles
Queues, filters, bulk actions for business management systems.
- Commerce storefronts that match ops
Catalog, checkout and account areas that do not hide inventory truth.
- Mobile job companions
Thumb-reachable primary actions, readable outdoors, obvious offline.
How product design work runs
- Discovery
Watch or interview operators. Map the job and the current workarounds. Read the domain model if it exists.
- IA and flows
Structure before visual polish. Agree the states a record can be in.
- UI and review
Key screens including empty and error. Critique with operators and engineering for feasibility.
- Handoff
Components, copy, and open questions. If we engineer, this becomes implementation tickets.
- Build-time design support
Edge cases appear in staging. Design stays in the loop instead of vanishing after a kickoff.
Show us the job that feels heavy
Send the role, the screen they dread, and whether we are also engineering. We will tell you if this is information architecture, UI, copy, or a data-model problem wearing a design costume.