Skip to main content
flyingpenguinYOUR DIGITAL PARTNERBook a free call

Business systems / Behind the scenes

Changing tabs shouldn’t wipe out the work you were doing

You start changing a setting, open another section to check something and come back to an empty form. The screen may look tidier with tabs, but it has just given you the same job twice.

We recently split a busy Flying Penguin settings screen into separate sections. The important part was keeping the panels and their working state available while the person moved between them. That is a small design decision with a very practical test: return to the first section and check that the edit is still there.

Organise the screen around what people do

A long admin page often grows one feature at a time. Eventually the person looking for a connection setting has to scroll past reporting, configuration and pricing controls. Group related tasks so the labels give them a clear place to start.

Tabs suit some frequently used admin screens. GOV.UK’s design guidance warns that they hide content and are awkward when somebody needs to read everything in order or compare information across sections. If a task needs two values side by side, a comparison view or a shorter single page may work better.

Source: GOV.UK Design System: tabs

Keep the edit while the person checks another section

Changing the selected panel should not silently throw away a draft. In our settings change, the panels stay in place while the inactive ones are hidden. That preserves their local working state during tab changes. The saved record still changes only through the intended save action.

React’s documentation explains the technical reason this matters: removing a component destroys the state stored in it. A screen can accidentally lose a draft when its tab implementation removes and recreates the form. There are several ways to retain it; the right one depends on the size of the page and how drafts are meant to work.

Flying PenguinFrom the workshop

Return to the setting you were editing

First sectionEdit startedA fictional notification label has been changed.
Other sectionOpened for referenceThe first form is removed from the page.
ReturnOriginal valueThe unsaved edit has disappeared.

Changing sections has discarded the local edit.

Illustrative example with fictional records. These controls do not change a live business system.

Source: React: preserving and resetting state

A retained draft still needs an honest save state

Keeping a form alive while switching tabs does not make it a durable draft. A page refresh, closed browser or expired session can behave differently. Say whether the change is unsaved, saving, saved or failed, and test each of those claims.

If the business needs work to survive a refresh, agree a separate draft-saving design. Think about what happens when the same record is open in two places, when a save fails and when someone signs out. Avoid a reassuring saved badge until the server has actually confirmed the write.

Keep drafts attached to the right record

Preserving an edit is only useful if it stays with the correct account or job. Switching from one customer record to another must not carry the first customer’s unsaved text into the second one. React’s guidance also covers resetting state when the identity changes, which is the other half of this decision.

Use the stable record identity to decide what can be restored and when a reset is required. During testing, enter clearly fictional text in one record, move to another and check it cannot be saved there by mistake. Never test that boundary using private customer content.

Source: React: preserving and resetting state

Make the tabs work without a mouse

The WAI tabs pattern defines the relationships between a tab list, its tabs and their panels. It also describes keyboard movement within the tab list. A row of buttons with different colours needs those behaviours and states to become a usable tabs control.

Check the selected state, visible focus and labels with a keyboard. On a phone, make sure every section remains reachable without text spilling off the screen. Hidden panels should not leave their form controls in the normal focus order. Keep errors visible when the person returns to a section.

Source: WAI ARIA Authoring Practices: tabs

Use one realistic edit as the acceptance test

Enter a change, switch sections twice, return and save it. Then try a failed save, a refresh and a different record. Write down which edits should survive each step. The result should match what the screen tells the person.

This is the sort of improvement we make inside bespoke business systems as they grow. A cleaner layout is welcome, but I also want the everyday interruption to work properly: check another setting, come back and carry on from where you were.

Sources

Checked on 26 October 2026.