Technologies
Operational software and AI products share a problem: the screen has to make something complicated legible in a few seconds. We design for the person who uses it forty times a day, not for a portfolio shot.
From a single flow that is not working to a design system your team can build against for years.
Screens designed around the task, not around a layout that looked good empty.
The patterns specific to AI: uncertainty, provenance, correction and approval.
A shared vocabulary so every screen shipped afterwards is consistent.
Finding out how the work is really done before redesigning it.
Something clickable early, because opinions about static mockups are cheap.
Dense operational screens that stay readable under real volume.
Designed so nobody on your team or in your customer base is locked out.
An honest assessment of an existing product and what to fix first.
Most design problems in working software are not aesthetic. They are decisions that were never made.
A file gets approved, then engineering discovers it does not say what happens when the list is empty, the name is long, or the request fails. Those answers get invented during the build.
Presenting a model's output as a confident answer with no visible reasoning or source teaches users to either over-trust it or abandon it. Both are expensive.
Six months after launch there are four button styles and three date formats. Nobody decided that — it accumulated one deadline at a time.
Chosen for what a project needs. We work in whatever your team already uses rather than forcing a migration.
Six stages, each ending in something you can react to. No long silences between kickoff and delivery.
01
We watch the work being done today, talk to the people doing it, and agree which tasks the redesign has to make faster.
02
Information architecture, navigation and the token and component foundations are settled before individual screens are drawn.
03
Clickable flows with realistic content, tested with real users. Changing direction here costs a day rather than a sprint.
04
Screens delivered with their states, responsive behaviour and interaction notes, so engineering never has to guess at intent.
05
Contrast, type scale, focus order and keyboard paths checked against WCAG 2.2 AA before handover rather than after launch.
06
A documented system your engineers can build from, then refinement against how the product is actually used once it ships.
We are a software engineering team that designs, which means what we hand over can be built as drawn.
01
The same team engineers the result, so nothing is specified that cannot be implemented — and nothing is left undecided for a developer to invent.
02
Loading, empty, partial, error and permission-denied are designed alongside the happy path, because that is where products actually feel broken.
03
Contrast, focus and keyboard operation are constraints during design rather than a remediation project afterwards.
04
Decisions are grounded in watching people do the work. Taste settles what is left, not what matters.
05
You get a documented set of tokens and components, so the tenth screen your team ships still matches the first.
06
Your workspace, your components, your documentation. Nothing here requires us to stay.
Tell us what you are building or which part of your product people struggle with. We will come back with an honest view of the effort involved and where we would start.
