In this guide 6 sections
Release in stages for most internal software. Start with the screens behind the most support calls and entry mistakes, keep the patterns staff already know and send a short note with each release. A single switch suits only small tools with few users, where one afternoon of training covers everyone.
Find the screens that hurt first
Open the support log before you open a design tool, and count which screens produce the calls, the corrections and the “where did it go” messages. Ask whoever answers staff questions. Ten minutes beats a week of guessing.
Look at the data itself, because rejected entries, duplicate customer records and invoices reissued after a typo all point to a screen that misleads people under pressure. Sit beside a clerk. Watch where the eyes stop.
These screens are your first release. Everything else can wait, since most screens look fine once the worst offenders are fixed and the support log goes quiet for a fortnight.
- Screens with the most support calls
- Fields that are often left blank or mistyped
- Steps where staff keep a paper note beside the keyboard
- Reports that users rebuild in Excel every week
Keep the patterns people already know
A redesign that moves the Save button, renames Dispatch to Fulfilment and reorders the tabs forces relearning for no gain, because staff spent years building muscle memory. Do not fight that habit.
Change what causes errors and leave the rest alone, keeping menu positions, keyboard shortcuts, tab order inside forms and the words printed on invoices and delivery notes. If a label must change, show the old name in small text beside the new one for a few releases, so nobody hunts.
Keep a written list of what will not move, because it stops well-meaning designers from tidying away a label that clerks type from memory.
- Menu order and screen names
- Tab order and keyboard shortcuts
- Wording on printed documents
- Column order in the lists people scan daily
What a staged release looks like
Ship one cluster of screens at a time, order entry first and stock adjustments a fortnight later, giving each release to one branch before the whole company sees it. Small problems get fixed within days.
Add a one-page note showing the old screen, the new screen and a line on what changed and why, then pin it inside the app and mail it.
Staff keep working on familiar screens for everything not yet redesigned, so nobody stops for a training day while dispatch carries on. The pickers keep picking.
When a single switch is the better choice
Some tools cannot be half old. A shared database schema, a barcode scanning flow spanning receiving and putaway, or a month-end close will break if two layouts run side by side. There, one switch is cleaner.
Plan it for a quiet weekend. Expect a heavy week after. You will need classroom training, a printed quick guide at every desk and someone floating on the shop floor to answer the small questions that stall a picker. Many offices also keep parallel sheets for a few days as a safety net, and the double entry wears people out by the middle of the week.
Rehearse it on a copy first.
Decide with a short comparison
Score each option on four things. How many people use the tool daily? How tightly are the screens linked? How much training time can you spare? Can you reverse a bad release quickly? Staged wins when users are many and the screens are loosely linked, because each release stays small enough to fix by Friday.
Whichever you pick, name one person who collects feedback for the first fortnight and put their phone number in the release note. One name, one number.
Your next step: list your ten most complained-about screens, order them by support calls and write the first release around the top three.
Redesign release planner
A one-page worksheet. The first table lists screens, with columns for weekly support calls, common entry mistakes, owner and release number. A second block holds the “will not move” list of menus, shortcuts and printed wording. A third block compares staged and single-switch release on user count, screen dependency, training time and rollback speed, with a tick box for the choice.
Open a blank worksheet to printQuestions owners ask
Should we run the old and new screens in parallel?
Only for the screens being replaced, and only for a short time. Running a full old system beside the new one doubles entry work and invites mismatched numbers. A link back to the old screen for a fortnight is usually enough.
How much training does a staged release need?
Usually a one-page note and a ten-minute huddle with the affected team. A heavy classroom session is needed mainly for a single switch that changes every screen at once.
How do we know the redesign worked?
Compare the support log and the rejected-entry count for the same screens before and after. Fewer calls and fewer corrections mean the change helped.
Can staff test the new screens before release?
Yes, and they should. Give two or three daily users a clickable prototype and ask them to enter a real order. Watch where they hesitate rather than asking what they think.