In this guide 6 sections
Software looks like four products when each module was built separately without shared components. The fix: inventory every difference, choose one pattern for each, build those once in a component library, and send back new screens that skip it. Migrate old modules one release at a time.
How modules drift apart
The first module was built by one developer with one idea of how a button should look. The second came a year later from a contractor who copied the HTML and changed things to meet a deadline, adding a second blue and a third date format. By the fourth, nobody remembers which came first.
Nobody chose the mess. Each decision made sense alone. That is the trap. Together they cost users their trust, because an interface that keeps changing its habits makes people double check every click.
Inventory the differences before arguing about them
Take a screenshot of every screen type in every module: list, detail, create form, approval, report and settings. Group the images by pattern, not by module. Seeing four date pickers in a row ends most debates. Opinions fade.
Log each difference in a spreadsheet. Note the screen, the module and the version in use. Keep it factual. Opinions come later.
- Button position: Save at top right, bottom left or floating
- Date formats such as 03/04/26, 3 Apr 2026 and 2026-04-03
- Labels: Customer, Client and Account for the same record
- Status colours: green meaning active in one module and paid in another
- Table behaviour: sorting, paging and filters that reset or stay
Pick one pattern for each and write down why
For every row in the log, choose the version that fits the people using it. Count which one is most common, check which passes contrast and keyboard tests, and ask three users which they find quickest, noting any hesitation.
Write the reason in one line. When a developer asks why Save sits bottom right, the answer should live in the file, not in someone’s memory.
Give each word one meaning. If Order means a customer request in sales and a purchase in stores, rename one of them on screen, and in the database if the change is cheap.
Build the patterns once in a component library
Decisions on paper drift again within a quarter. Code holds them. Build each chosen pattern once as a shared component. Every module imports that package, so a change to the Save button reaches all four in one release.
Start with the pieces on every screen. Then add the data table, the filter bar and the date formatter, because those cause most of the visible mismatch.
- Shared button, input, select and date picker
- One formatter for dates, numbers and currency
- A page header with title, breadcrumb and action area
- A table with sorting, paging and a column chooser
Migrate one module at a time
Rebuild the module with the heaviest daily use first; staff will notice the gain there. Leave the others alone until their next planned release. A big restyle in one go risks breaking forms that people rely on at month end, when nobody has time to retrain.
Add a rule to code review: a screen that skips the library is sent back. Without it, module five becomes the fifth product. Simple as that.
Open a spreadsheet today and list ten mismatches you can spot without trying, then bring it to your next planning meeting.
Mismatch log and shared vocabulary
A two page worksheet. Page one is the mismatch log with columns for screen, module, element, variant found, chosen standard, reason, owner and fix release. Page two is the vocabulary list: each word, its single meaning, and the modules where it appears.
Open a blank worksheet to printQuestions owners ask
Do we need to redesign everything to fix inconsistency?
No. Fix the shared pieces first, such as buttons, inputs, dates and tables. Visual polish on rare screens can wait. Most of the feeling of four products comes from a few dozen repeated elements.
How do we stop new modules drifting again?
Make the component library the only source for common parts, and add a code review check. A screen that builds its own button gets sent back with a link to the library.
What if two teams disagree on the standard pattern?
Test both with three real users on the same task and keep the one that is quicker or causes fewer slips. Record the result in the log so the question does not return next quarter.