Design & UX
Uptime is not the same thing as adoption
A system can meet every functional requirement, pass every test and still fail. The signs are familiar: people keep a parallel spreadsheet, data quality degrades because a mandatory field is easier to fake than to fill correctly, training keeps getting requested for a tool that has been live for a year, and one team quietly still uses the old process.
That is a design failure, not a user failure. And it is expensive in a way that rarely gets attributed correctly, because the cost shows up as training budget, data cleanup and support tickets rather than as a line item labelled ‘the interface was hard to use’.
We treat design as an engineering discipline. It begins with understanding what people are actually trying to accomplish, what constraints they work under — gloves, sunlight, one hand, a poor connection, forty repetitions an hour — and where the current process genuinely hurts. The visual layer comes last, and it comes from the structure rather than the other way around.
Because we also build the software, our designs are grounded in what is actually buildable in your environment. A prototype that cannot be implemented within your constraints is an expensive picture.
What we offer
The work, specifically
Six services, delivered standalone or as the front half of a build.
User research and workflow mapping
Interviews and contextual observation with the people who will use the system, mapped into a documented picture of the current workflow with its pain points, workarounds and hidden dependencies. Frequently the highest-value part of the engagement, because it surfaces requirements nobody thought to state.
Information architecture and interaction design
Structuring the system so people can find things and complete tasks without training — navigation, task flows, form and data-entry design, error prevention and recovery, and the state model that determines what a user sees when something is loading, empty or broken.
Wireframes and clickable prototypes
Low-fidelity structural wireframes through to high-fidelity interactive prototypes that people can actually click through and react to. Testing a prototype with real users costs a fraction of discovering the same problem after it has been built.
Design systems and component libraries
Reusable components with defined states, spacing scales, typography and colour tokens, and usage documentation. Means every subsequent screen is faster to design and build, and the product stays visually coherent as different people work on it over years.
SAP Fiori design and UI5 interfaces
Role-based Fiori applications that replace multi-screen SAP GUI transactions with focused, task-oriented interfaces, including mobile-capable designs for warehouse, field and approval workflows. Built to SAP Fiori design guidelines so they feel native alongside standard applications.
Accessibility and WCAG 2.2 compliance
Design and build to Level AA as standard — contrast, keyboard operability, focus management, semantic markup and screen reader support — plus audits of existing products with a prioritised remediation plan. Required for government procurement, and worth doing regardless.
Deliverables
What you actually receive
Design deliverables that a developer can build from without guessing at your intent.
| Deliverable | What it contains |
|---|---|
| Research findings | What users are trying to do, where the current process fails them, and the design implications — with evidence attached rather than assertions. |
| Workflow and journey maps | Current and proposed process flows showing decision points, handoffs, and the moments where things currently go wrong. |
| Interactive prototype | A clickable prototype covering the primary task flows, suitable for user testing and stakeholder sign-off before build cost is committed. |
| Design system | Components with all states defined, tokens for colour, type and spacing, and usage documentation. Delivered in Figma with developer handoff notes. |
| Accessibility statement | WCAG 2.2 conformance level, known limitations, and the testing method used to establish both. |
| Developer handoff | Specifications, assets, interaction notes and a walkthrough session, so the build team implements the intent rather than approximating the picture. |
Stack
What we build with
Tools chosen for collaboration and handoff quality, not for their own sake.
- Figma
- SAP Fiori Guidelines
- SAPUI5
- Design tokens
- Storybook
- Maze
- Axe DevTools
- WCAG 2.2 AA
- Prototyping in React
Why it matters
Good design is cheaper than the alternative
Adoption is the only measure that counts. A system nobody uses properly delivers none of its business case, regardless of how well it performs technically. Designing for the actual working conditions — not the demo conditions — is what determines whether the investment returns anything.
Interface quality determines data quality. When a form is confusing, people enter something to get past it. That bad data then flows into every report and every downstream system, and it is far more expensive to clean than it would have been to prevent. Data quality problems are frequently interface problems wearing a disguise.
Fixing it in a prototype costs almost nothing. Changing a flow in Figma takes an afternoon. Changing it after it is built takes a sprint, a regression cycle and a data migration. The entire economic argument for design work is that it moves decisions earlier, where they are cheap.
Questions
Design & User Experience, answered
We already have a developer. Can you just do the design?
Yes. We regularly deliver design systems and prototypes for in-house teams to build. You get component specifications, states, spacing tokens and interaction notes in a form a developer can implement without reverse-engineering the intent from a static image.
Does UX matter for internal software nobody chooses to use?
It matters more, not less. Consumer software with poor UX loses customers, which is visible. Internal software with poor UX generates training cost, data-entry errors, shadow spreadsheets and workarounds — costs that are absorbed silently and never attributed to the interface that caused them. A captive audience does not make usability optional; it makes the failure harder to see.
What is SAP Fiori and do we need it?
Fiori is SAP's design system and application framework for building modern, role-based interfaces over SAP data. It matters if your users still work in classic SAP GUI transactions for tasks that would be far quicker in a focused screen, or if people need SAP access from a phone or tablet. It is not automatically the right answer — for a heads-down power user doing high-volume entry, the classic transaction is sometimes genuinely faster.
How do you handle accessibility?
We design and build to WCAG 2.2 Level AA as the default: colour contrast, keyboard operability, focus visibility, semantic structure and screen reader labelling. For government and utility clients this is usually a procurement requirement. For everyone else it is simply a better product for a meaningful share of users, and retrofitting it later costs several times more than building it in.
Next step
Is there a system your team quietly works around?
That workaround is telling you something specific. Show us the system and we will tell you what it is and what it would take to fix.