Skip to content

Web & Digital Experience

Application frontends: designed for every state, not just the full one

The screen in the design file has perfect data. The screen people use is often loading, empty, half-loaded or failing to save. An application frontend is judged in those moments. We draw, word and build every state, so the app always tells people what's happening and what they can do next.
Discuss your applicationSee the six states ↓
Open requestsNew requestNo open requestsRequests from tenants appear here.Share the tenant link4BNo heat9ALeaking pipescheduled2CDishwasherwaiting on tenantnewassignedsaving…not savedCouldn't save. Your change is kept.Try againsaved · just nowstatesloadinggrey rows where data goesemptywhy, and what fills itfullthe usual daysavingthe change shows at oncecouldn't savekept, with a retrysavedand says so

Six states, each designed

Each one is drawn and worded before it's built. Defaults are where apps feel broken.
Loadingthe layout, with grey rows where the data will gosee where things will be; nothing jumps when it arrives
Emptywhy it's empty, and what fills itshare the tenant link
Fullthe requests, worst problems firstopen, assign, filter
Partialwhat loaded, and what didn'tuse what's there; retry the rest
Savingthe change at once, marked as savingkeep working
Couldn't savethe change still there, and why it failedtry again, or copy it

One save, three outcomes

A property manager assigns 4B to a contractor. What happens next depends on more than the button.

Saved

Screen shows
“assigned · saved just now”
Data
stored; the contractor is told
The person
carries on

Decided before the first screen

  1. 01

    Every state drawn

    Before anything is built

    Loading, empty, partial, error and done are designed, with words, not left to defaults.

  2. 02

    Where things live

    Navigation from the person's tasks

    Requests, units, contractors: organised by what a property manager does in a day.

  3. 03

    Built from shared parts

    The design system's components

    Buttons, fields and lists behave the same everywhere, so people learn the app once.

  4. 04

    Keyboard and screen reader

    Every action without a mouse

    Focus is visible and moves sensibly; changes of status are announced.

  5. 05

    Phone to desktop

    The same task, recomposed

    A table on the desktop becomes a list of cards on a phone. Nothing scrolls sideways.

What an application frontend hands off

In

Data
from the application's services
The person
taps, types, waits
Design system
components and tokens
Frontend
show every state

Out

Changes
sent, retried, never lost
Status
announced as it changes
Screens
on any device

Worth building when people spend their day in it

Good fit

  • Your team or your customers use the screens every day.
  • A slow or confusing screen costs time on every task.
  • The screens have to work on phones and in the field.

Not the right fit

  • A form or two will do; your site builder can make them.
  • The product you use already has screens that work.

Where this capability is used

Next to application frontends

Questions about application frontends

What do you build frontends with?

A current web framework chosen for the job, and the choice is written down with its reasons, so your team or another developer can maintain it.

Will it work without a connection?

Where the work needs it, such as technicians in basements. Changes are kept on the device and sent when the connection returns, and the screen shows which haven't been sent.

Do we need a design system first?

No. The first screens use a small set of shared parts, and the system grows from them.

A web app or a phone app?

Usually a web app that works well on phones. A phone app is worth it for things the browser does poorly, like scanning or working offline all day.