I love a design review where I get to be right. This was not one of those.
At Scaler I opened a colleague’s file and found a filter that was clearly mine. Or almost mine. The spacing was off, and the empty state did something I would never, ever do. I felt that little rush of being right and started typing a very "helpful" comment.
Then I went looking for the documentation to link, and realised there wasn’t any. I’d used that filter all over my own modules and never documented it once.
I deleted the comment and sat with that for a minute. It’s very hard to stay annoyed at someone for breaking a rule you never wrote down.
Naturally, my next move was to overcorrect. I wanted to standardise everything, down to the tooltips. We were a tiny team with no time for that, so I did an audit instead and mapped every interaction across the modules to see where things didn’t match.
Some of the differences were just mistakes. Our filters worked four different ways in four modules, for no better reason than different people having a Monday. That got fixed fast.
The filter works the same in every module
2 estimated rows hidden
2 estimated rows hidden
Illustrative data
The same filter works differently in each module
2 estimated rows hidden
Illustrative data
The tables were different for a good reason. Analysts scanning thousands of rows of emissions data want tight, dense rows, and most other people need more space than that. If I’d forced one table on both, I’d have built something that disappoints two groups of users at once, which is efficient in the worst possible way.
A few things were teams improvising because the system had nothing for them yet. Some I killed. A couple I stole and made official, and I’m only slightly sorry.
Only accidental variation should be standardised
Kinds of variation, and what each one needs
Two designers solved the same problem separately and came up with different answers, because nobody compared notes.
Genuine differences in workflow, user type, or information density. A dense analytical table and a summary card table serve different needs.
A team working at the edge of what the system addresses has made a local decision. May be wrong (standardise away) or right (promote to pattern).
My test for all of it was one question. Does this make someone relearn something they already learned somewhere else in the product? If it does, it goes. If the difference makes sense for that screen, it stays, and I write down why.
We didn’t rebuild old screens either. New work followed the rules and old screens caught up whenever someone touched them. I’d love to call that strategy. Mostly, we just didn’t have the people.
These days I get nervous when a design review turns into a checklist, and the only thing anyone asks is whether it matches the library. Nobody asks if it’s right for the person using it. The library can’t tell you that, and believe me, I’ve looked.
Too much standardisation shows up as symptoms you can spot
What to watch for
A component clearly derived from the system, applied to a context the system wasn't designed for. Spacing right, colour right, behaviour subtly wrong.
Designers stop making judgment calls and start checking compliance. Design reviews evaluate whether something follows the spec, not whether it's right.
Teams facing legitimate edge cases accumulate one-off decisions outside the official framework: an undocumented shadow system.