00.0

Home  /  Services  /  Senior UX and UI design

01  ·  What I do

Deciding what goes on the screen, and removing the rest.

An enterprise product can show you forty things. It is usually correct about all of them, and no help at all, because the person in front of it has one question and has to assemble the answer themselves.

The work is the subtraction. Which of the forty this person needs, at this point in their journey, for this case, and being willing to take the other thirty-four away when the room would rather keep them.

Over ten years of it, at senior and lead, in insurance, telecom, public administration, fleet software and virtual events.

40 availabledeciding
In plain terms

UX design is deciding what goes on a screen, in what order, and what gets left off, so somebody can finish the task they arrived with. UI design is the visible layer of that: type, spacing, colour, and what every state looks like when things go wrong.

In enterprise products the hard part is almost never how it looks. It is that the subject is complicated, several different jobs run through one screen, and somebody has to decide which of them this screen is actually for.

The shape of the job

Three questions, asked before anything is drawn.

None of them is about layout. Answer them and the layout is close to decided; skip them and no amount of craft rescues the screen.

OneWhat are they trying to reach?

Not the task the ticket names. The thing they will be judged on when they close the laptop. An underwriter is not filtering layers, they are pricing a risk, and the difference decides what the screen leads with.

TwoWhich case is this?

Enterprise products serve several jobs through one interface and are usually designed for the average of them, which is nobody. Naming the cases separately is what lets a screen be good at one rather than adequate at four.

ThreeWhere in the journey are they?

The same screen is a different screen on the first day and on the two hundredth. What is orientation early is clutter later. Designing for one of those and shipping to both is the most common reason a good screen ages badly.

On your side of the table

Artefacts your engineers can build from without a meeting to interpret them.

Which of these apply depends on what you are trying to decide. I would rather produce four that get used than eleven that get filed.

The argument, before the pictures

Written down and agreed while changing your mind is still cheap.

  • What we are deciding, who has to agree, and what would count as evidence
  • Information architecture, and the reasoning for why it is that way rather than another
  • The cases the product serves, named separately instead of averaged
The design

At the fidelity the question needs, not the fidelity that photographs well.

  • Interaction design for the states that actually occur: empty, partial, wrong, too much
  • Interface design tested with the people who will use it, not reviewed by the people who ordered it
  • Prototypes that answer one question each, and are thrown away once they have
The handover

The part where design usually fails, and the reason the studio exists.

  • Specification precise enough to build from, in the tool your team already uses
  • Accessibility built in and recorded, rather than audited at the end and argued about
  • Design QA through the build, in the browser, on the real thing
What you keep

All of it, in the source file, not a PDF of a source file.

  • Including the messy research notes. Especially those
  • A decision log: what was chosen, what was rejected, and what it cost
  • Enough that the next designer does not have to start by guessing what I meant

Where this has actually happened

Three products, three industries, three numbers.

Insurance  ·  LexisNexisMap View Global

Forty layers of risk data, each correct alone and unreadable together. The map was made to answer one question at a time, with the analyst changing the question.

35% satisfaction  /  24% capability →
Telecom  ·  EricssonDigital Services Portal

A contract promising 99.999% that the customer paying for it could not see. The threshold was drawn on the chart, so the answer became a position rather than a calculation.

~70% of issues caught pre-handoff →
Public sector  ·  EngineeringThree services at once

Services organised by the department that owned them, for citizens who only had a problem. Fourteen months, four stakeholder groups, one delivery lane each.

3 services  /  2 regions  /  4 groups →

The other five

Rarely bought on their own, and never sold that way.

These are facets of one engagement rather than a menu. A contract usually contains most of them, weighted differently depending on what is broken.

Everything on one screen

Role, length, hours, right to work and contracting

Services →