SERVICE 04 / DESIGN DECISIONS GROUNDED IN HOW PEOPLE REALLY WORK
Clearer screens,
fewer dead ends
People do not come to admire an interface. They come to place an order, submit a claim or finish a shift, and design decides how easily they can.
THE BUSINESS CHALLENGE
What this work
is for.
Your support queue is full of the same four questions. Each one is a design problem that somebody is answering by hand, over and over, instead of being fixed once in the interface.
WHAT WE DO
Good design work is mostly good decisions made early: what the thing is for, who it serves, what belongs on which screen. We talk to the people who will use it, including the staff who use internal tools all day, and turn what we learn into information architecture, flows and interfaces. We design in the browser where we can, so what you review behaves like the real thing rather than a picture of it. The result is a design that the team building it can actually implement, with the edge cases drawn rather than guessed.
BUSINESS PROBLEMS THIS ANSWERS
- Support answering the same questions. A recurring ticket is often an unlabelled button or a missing confirmation. The queue absorbs a cost the interface created.
- Internal tools nobody likes using. Staff tools are designed last and used most. Workarounds accumulate, and data quality suffers for it.
- Features added, structure never revisited. Each release adds a menu item. Eventually nobody can find anything and new users give up at the first screen.
- Designs that cannot be built as drawn. Beautiful screens that ignore loading, empty and error states hand the real decisions to a developer at the last minute.
CAPABILITIES AND DELIVERABLES
What is involved,
and what you get.
RELEVANT CAPABILITIES
- User research. Interviews, observation and usability sessions with the people who will actually use the thing.
- Service design. Mapping the whole journey, including the phone calls, emails and back-office steps that surround the screens.
- Information architecture. Organizing content, navigation and labels so people can predict where something will be.
- Interface design. Screen-level design covering the ordinary states as well as the empty, loading, error and permission-denied ones.
- Design systems. Reusable components and rules so the tenth screen takes less effort than the first and still matches it.
- Accessibility review. Checking contrast, keyboard use, focus order and screen reader behavior as part of design rather than after launch.
TYPICAL DELIVERABLES
- Research findings and quotes
- Journey and service map
- Site or app structure
- Interactive prototype
- Interface design files
- Component and pattern library
WHAT COULD IMPROVE
- Fewer repeat support questions caused by the interface itself
- Staff tools people use as intended rather than around
- Shorter paths through the tasks that matter most
- A design the development team can build without guessing
Possible improvements, not guaranteed outcomes.
EXAMPLE WORKFLOW
How an engagement
usually runs.
A typical shape. The order changes with the situation, and we say so when it does.
Learn
We speak to users and staff, and read what your support and analytics data already says about where people struggle.
Structure
We agree the content, navigation and flows before anyone argues about colour.
Prototype
We build something clickable early so the questions are settled by watching people use it.
Design properly
We take the agreed direction to full fidelity, including the unglamorous states that break builds.
Support the build
We stay available while it is implemented, because detail questions always arrive and answers age badly in documents.
RELATED PATHWAYS
Where this service
usually fits.
Improve Customer Experience
A consistent journey where staff and customers see the same picture, and self-service covers the questions people would otherwise call about.
Build a Digital Product
A defined first version is live with real users, instrumented so the team can see how it is used and decide what comes next.
QUESTIONS
Questions we are
asked about this.
Yes, though it changes the risk rather than removing it. Even a handful of conversations and a review of existing support tickets usually surfaces the big problems. We will be clear about which decisions are then based on evidence and which are informed judgement.
It helps a lot, and we will work inside it rather than quietly replacing it. If we find gaps, such as missing form or table patterns, we propose additions in your existing style and leave them in your library. Where something in the system is actively getting in the way, we will show you rather than argue about it.
That is common and better surfaced early than discovered late. Prototypes and user sessions are useful here because they move the discussion from preference to evidence. Where a genuine business trade-off remains, we will frame the options and the consequences, but the choice stays yours.
Either, depending on how you want to work. Some clients want design files and patterns for their own front-end team, others want us to build the interface as well. We will tell you which we think fits your setup, and the handover includes the reasoning behind the design, not just the artwork.
A CLEARER VIEW
Your next move starts with a clearer view.
Tell us what you want to improve, what is getting in the way, or what you want to build. We will help you explore a practical path forward.