One account or every customer? Design for mistakes before they spread

An administrator means to change the price for one account. The screen still has “all customers” selected from an earlier task. They enter the new value, choose Save and only discover the scope when support starts receiving questions.

It is easy to focus on the missed selection. A more useful design question is how the product could have prevented the mistake, revealed it earlier or limited the work needed to recover.

Those three questions give product, design and development colleagues a concrete way to review a risky action together.

The UK Defence connection

The UK Military Aviation Authority offers an Effective Error Management course covering organisational error management systems and the people responsible for them. It is a reminder that managing mistakes involves more than asking individuals to pay attention.

The prevention, detection and recovery review below is my practical adaptation for software products. It is not the course syllabus or a claim that these ideas originated in the military. The focus here is the design of one action and its consequences.

A practical tech example

For example, a subscription software company has an internal pricing administration screen. Staff can change a price for one account or update a whole customer group. A previous selection remains active when the next task begins, and the Save confirmation says only “Changes saved”.

Choose the account-specific update as the task to review. Include someone who uses the screen alongside product, design, engineering and testing colleagues. Their first job is to agree the intended behaviour and map what could happen if the wrong scope is used.

How to put it into practice

1. Prevent an unintended scope

Purpose: Make the action match the user’s task.

Consider separate entry points for an account change and a bulk change. An account page should keep the account identity visible throughout the flow. A bulk update should require an explicit scope selection, with permissions appropriate to that task.

Check the request on the server as well as the screen. A disabled control is not enough if the underlying operation still accepts a broader scope. Avoid silently carrying a high-impact selection from an unrelated task.

Write a concrete requirement: an account-specific price change must never submit an all-customer update. Engineers and testers can then check how that condition is enforced.

2. Detect the mismatch before and after saving

Purpose: Make the consequence visible while action is still possible.

Before a bulk update, show the chosen group, number of affected accounts, old and new values, and when the change will take effect. Let the administrator return to edit the selection. Use clear labels and text as well as colour.

After saving, confirm what changed and provide a link to the recorded operation. “Price updated for account A” communicates more than “Success”. Keep a history showing who changed what and when, with access limited to appropriate staff.

Consider a review or alert for unusually broad changes. Give it a named recipient and response expectation. An alert that nobody can act on adds noise without creating a useful check.

3. Recover without creating a second problem

Purpose: Understand which consequences can actually be reversed.

Define what restoring the previous price means. Does it affect future renewals only? Has an invoice already been created or payment collected? Restoring a field will not automatically correct those downstream events.

For this screen, a recovery view could identify the affected accounts and recorded previous values, while the operations owner coordinates billing corrections through the approved process. Restrict restoration to authorised colleagues and record it as another change.

Test recovery in a safe environment with a small dataset. Include the possibility that one account has received a legitimate later update. A broad restore must not overwrite that newer decision without review.

4. Test the task, including the mistake

Purpose: Check behaviour rather than the presence of controls.

Ask a regular user to make an account-specific update in a test environment. Start with a prior bulk selection, include a change of task and observe what scope they believe is active. Avoid coaching them towards the intended answer.

Test the server checks, confirmation, history and recovery path separately. Record where the design relies on someone noticing a subtle cue. Prioritise the gap with the greatest potential consequence, then repeat the relevant task after changing it.

A record you can use

What to try next

Pick one action with consequences beyond the current screen, such as changing access, sending a bulk message or updating prices. Review its prevention, detection and recovery controls with someone who uses it.

Start with the biggest uncovered consequence. A useful outcome is one specific design change and a test that shows what happens when the original mistake is attempted again.

Source: Military Aviation Authority, Effective error management course information (updated September 2024). The tech examples and working tools are Coded Female adaptations.