Software nobody has to be trained to use.
Interface and interaction design for tools people sit in front of all day, plus the design system that keeps the tenth screen looking like the first one.
- WCAG 2.2 AA
- the baseline, not an extra
- Design tokens
- one source, every surface
- Tested
- with the people who will use it
Who this is for
You probably need this if…
01
Training is how you onboard
Every new hire needs a session with somebody senior before they can use the tool. That is a design cost, and you pay it again every time you hire.
02
People keep a spreadsheet alongside it
They use the software because they have to, and track the real state of things somewhere else. That gap is exactly where the design failed.
03
Every screen looks slightly different
Three developers, three interpretations, no shared components. It reads as unfinished to a customer even when it works perfectly well.
What this covers
The work, in detail.
7 capabilities
01
Product UI design
Screens for people doing a job under time pressure, organised around the task rather than around the shape of the database.
02
Interaction design
Empty states, loading, errors, and the confirmation step before something irreversible. The screens that decide whether software feels safe.
03
Design systems
Tokens, components and documentation, so the tenth screen matches the first one without anybody having to police it in review.
04
Prototyping
Clickable flows tested before the build, because changing a prototype costs an afternoon and changing production costs a sprint.
05
Accessibility
WCAG 2.2 AA as a build requirement. Contrast, keyboard paths, focus order and screen reader behaviour, all checked rather than assumed.
06
Usability testing
Five people from the actual user group, watched doing real tasks. It finds more in an afternoon than a fortnight of internal opinions.
07
Brand & identity
Marks, typography, colour systems, and the usage rules that keep it all consistent once other people start applying it without you.
How we approach it
Positions we actually hold.
Opinions cost something to have. These are the ones we would argue for on your project, including where they make the work slower.
01
Design for the tenth hour, not the first minute
Tools used all day should reward repetition with keyboard paths and predictable placement. Demo appeal and daily use pull in opposite directions.
02
Accessibility is a requirement, not a phase
Contrast and keyboard access are cheap when designed in and expensive when retrofitted. We check the numbers rather than trusting somebody's eye.
03
The error states are the product
Anyone can design the happy path. What people actually remember is what happened when the upload failed at ninety per cent.
04
Tokens over screenshots
Colour, type and spacing live as variables shared by the design files and the code, so a change lands in both instead of drifting apart quietly.
Technology
What we work with.
Defaults, not requirements. If you already run something else and have a team who knows it, we work in yours.
- Design
- Figma, design tokens, Storybook
- Implementation
- Tailwind CSS, shadcn/ui, Radix UI, CSS custom properties
- Accessibility
- axe, contrast auditing, screen reader passes
- Research
- Moderated task testing, session review
Where this shows up in delivery
- Our brand system runs on tokens shared between the design files and production CSS, with verified contrast ratios on every pairing.
- Charten is designed for clinicians working at speed, where a mis-tap has a cost and the keyboard path matters more than the animation.
- Accessibility checks sit inside the definition of done on every engagement rather than appearing as a separate line item.
Bought as part of
This practice is never sold on its own. It is quoted inside one of the engagements above, as part of a single number.
Proof
Where we have actually done this.
Projects we designed, shipped and wrote up. Each one names the decision that was genuinely hard to get right.
Questions
What people ask about design & experience.
- Can you work with our existing brand?
- Yes. We build the product design system on top of your brand rather than replacing it, and flag anything in it that will fail accessibility before we start using it everywhere.
- Do we need a full design phase?
- Not always. For an internal tool on an existing system, working inside your current patterns is usually both faster and better than starting from a blank canvas.
- What does accessible actually mean here?
- WCAG 2.2 AA: measured contrast, full keyboard operability, correct focus order and sensible labels. It is checked with tooling and by hand, not simply asserted in a proposal.
- Will you hand over the Figma files?
- Yes, together with the token definitions and component documentation. Same rule as the code: you own what you paid for.
Related reading
Written on this, by us.
Engineering · 6 min read
Design for the Tenth Hour, Not the First Minute
Software that demos beautifully and software that is pleasant to use all day are pulling in opposite directions. If your users live in the tool, optimise for the tenth hour.
Search & Marketing · 7 min read
Structured Data Is How You Get Quoted by ChatGPT
Ranking rewards authority. Being cited by an assistant rewards being parseable and complete. They are different jobs, and most sites are only doing one of them.
Usually combined with
All practice areas →Tell us what you’re trying to build.
Describe the problem in your own words. We’ll come back within one business day with a scope, a number and a date.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits