Skip to content

One decision per screen: progressive disclosure

Published · Updated · 3 min read

A safety interface should support decisions under pressure without turning the path into a hunt for details. Give each screen one primary job, explain the next step, and preserve a way to correct the choice.

Define one decision at a time

Start by naming the task: send a signal, choose recipients, or review the summary. Putting every question on one screen increases comparison and makes the consequence of the next step less visible.

The primary button should describe the action, not merely say “Next”. People should know whether they are saving, asking for confirmation, or actually sending.

Build a short, predictable sequence

A useful sequence can be: choose the action, check recipients and location, read the summary, confirm, then see status. Each step keeps context and shows how much remains.

Remove screens that ask for the same thing again. If a value is already known, show it for confirmation; do not make people retype it or remember a choice from two steps earlier.

Make costs and consequences visible

Progressive disclosure can hide secondary detail, not information that changes the decision. Before confirmation, show recipients, shared location, possible charges, duration, and whether the action can be cancelled.

An “Other details” panel can explain permissions or limits. The main summary must still make sense when that panel is never opened.

Make going back possible

Use consistent labels such as “Back”, “Edit”, or “Cancel”. Returning should preserve earlier choices and show which value will be changed.

After sending, do not call an irreversible action “Cancel”. Separate an edit before sending from a new update that changes the people who receive information.

Use the summary as a checkpoint

The summary is an intentional pause: it shows who receives the signal, what information leaves, and what action is expected from others. Promotional copy should not compete with confirmation.

After the gesture, show an observable state such as preparing, sending, or response received. Technical delivery does not prove that a person read, understood, or acted.

Test the real path

Try the flow on the actual phone, with usual text size, language, brightness, and network. Ask different people to explain what will happen before tapping, without leading them.

Record hesitation, hidden costs, and recovery from mistakes. Agree a second channel for times when the product or network is unavailable.

Frequently asked questions

Is one screen always better?

No. It helps with a simple task; a separate review is useful when recipients or consequences need checking.

Does hiding detail make an interface safer?

Only when the information needed for the decision stays visible. Costs, recipients, and limits should not be hidden in an expansion.

Does confirmed sending mean someone will act?

No. It confirms a product step, not that another person read, understood, or intervened.

Sources consulted

Technical and safety information was checked against the following official sources.

Editorial note: this guide connects W3C principles and Nielsen Norman Group heuristics to a hypothetical family-coordination flow. Sources were checked on 8 September 2026; actual behaviour depends on the product.

TEST THE FLOW

One screen, one choice, one readable review

Test the path on the real phone and check costs, recipients, correction, and status before sending.

Explore My Safe Circle

This guide covers design and coordination; it does not replace emergency services. For immediate danger, call the relevant local number; 112 is the European number where applicable.