< PEOPLE & CONTEXT / STUDIO NOTE />

DESIGN FOR

REAL CONDITIONS.

Devices, connectivity and context belong in the brief.

Lagos, Nigeria / Nupo Deyon Daniel / Unsplash

Start with the conditions

An experience does not happen in a blank room on a perfect connection. People use different devices, move between places and fit tasks into the rest of their work. Treat those conditions as part of the design brief, rather than as edge cases discovered at the end.

Ask specific questions

Which devices are common? Where will the software be used? What happens when a connection is interrupted? Who needs to share or transfer information? A specific question produces a more useful design decision than a general claim about what all users need.

Make important states understandable

Waiting, saving, retrying and recovering are part of the experience. Clear feedback helps people understand what happened and what they can do next. The system should not leave them guessing whether a request was completed or whether information was lost.

Keep the essential task clear

A considered experience gives the main task room to breathe. Prioritise useful information, readable content and understandable actions. The result should help people complete the work, even when the circumstances are less comfortable than the design team’s testing setup.

Review in the real context

Test the experience with representative people and conditions. Listen for workarounds and assumptions. Context is a source of understanding, and the design becomes stronger when it reflects the world it needs to serve.

< YOUR NEXT CHAPTER />

A QUESTION

WORTH ASKING.

Start a project

VERAXON STUDIO / PART OF VERAXON / © 2026

< PEOPLE & CONTEXT / STUDIO NOTE />

DESIGN FOR

REAL CONDITIONS.

Devices, connectivity and context belong in the brief.

Lagos, Nigeria / Nupo Deyon Daniel / Unsplash

Start with the conditions

An experience does not happen in a blank room on a perfect connection. People use different devices, move between places and fit tasks into the rest of their work. Treat those conditions as part of the design brief, rather than as edge cases discovered at the end.

Ask specific questions

Which devices are common? Where will the software be used? What happens when a connection is interrupted? Who needs to share or transfer information? A specific question produces a more useful design decision than a general claim about what all users need.

Make important states understandable

Waiting, saving, retrying and recovering are part of the experience. Clear feedback helps people understand what happened and what they can do next. The system should not leave them guessing whether a request was completed or whether information was lost.

Keep the essential task clear

A considered experience gives the main task room to breathe. Prioritise useful information, readable content and understandable actions. The result should help people complete the work, even when the circumstances are less comfortable than the design team’s testing setup.

Review in the real context

Test the experience with representative people and conditions. Listen for workarounds and assumptions. Context is a source of understanding, and the design becomes stronger when it reflects the world it needs to serve.

< YOUR NEXT CHAPTER />

A QUESTION

WORTH ASKING.

Start a project

VERAXON STUDIO / PART OF VERAXON / © 2026