Turning a week of SaaS UI development into about an hour
Designing reusable admin interaction frameworks so recurring Settings, Create and Report experiences could be configured from shared patterns instead of redesigned and rebuilt from scratch.
- 01Requirement
- 02Shared framework
- 03Configuration
- 04Reusable interface
Some product visuals have been simplified or reconstructed to protect confidential platform and customer information. Examples use generic content.
The admin product kept solving the same problems differently.
As a SaaS admin product grows feature by feature, every team can invent its own settings, create form, report, list and confirmation. What duplicates is not only the development — it is the interaction decision.
Its own settings layout, its own save behaviour.
Its own create form, its own validation timing.
Its own report, its own empty state.
Its own confirmation, its own destructive treatment.
The technical platform already knew how to generalise UI.
A metadata-driven low-code architecture with reusable page generators — reports, settings, create, charts — and a shared component library already existed, built for rapid UI development and a lower learning curve. I did not build that foundation.
So the open question was never “can we generate UI?”
It was “what should the generated experience decide?”
Reuse the decision, not just the component.
A reusable button does not create a coherent product.
If every feature still decides navigation, hierarchy, saving, destructive actions and state handling for itself, the component library has not settled anything. The opportunity was to standardise at the pattern level — so the unit of reuse became the workflow.
Three reusable experience families.
An existing object needs ongoing management.
An admin is creating or configuring a new entity.
An admin is reading, filtering or acting on data.
Settings had grown feature by feature.
Course, school and profile settings followed different patterns, a card index added a hop before anyone reached a setting, and destructive actions carried the same weight as safe ones.
Rules for choosing a container
Large, frequent or complex settings — ten or more sections, or destructive actions live here.
Medium complexity, where the surrounding context should stay visible behind it.
One focused decision, roughly three to five fields.
Destructive confirmation only. Nothing else earns this container.
What replaced the card index
Irreversible actions get their own ground.
Not every setting deserves a page.
Consistency does not mean using the same container everywhere. It means having predictable rules for choosing one.
A card grid doesn’t get clearer when you add more cards.
Past roughly a dozen items the index became visual noise. Persistent navigation gives overview, spatial memory, direct access — and room for the sections the product hasn’t built yet.
“Delete” should never look like “Branding.”
Visual consistency does not mean equal emphasis. Irreversible actions were pulled out of the grid into an isolated danger zone with its own treatment and its own confirmation.
A framework should remove repeated friction too.
Save and cancel sat at the bottom of long pages, so editing ended in a scroll. The pattern now keeps the action bar in reach, and a field carries the context that used to live in a help doc.
A framework is a set of decisions teams shouldn’t have to remake.
Five questions every admin surface used to answer for itself, answered once at the framework level.
Configuration instead of bespoke implementation.
The same requirement, before and after — a reconstructed example rather than the real page.
Business rules needed one language, not one per feature.
Business rules entered the product through one shared state language instead of each feature inventing its own warning pattern.
Standardising the future also meant migrating the past.
The framework only mattered if teams could actually use it.
A design system only works if the intended hierarchy survives generated implementation.
- 01Design ruleDestructive actions live in a danger zone
- 02Framework contractWhat the pattern must support for that to hold
- 03ImplementationReusable framework behaviour, built with engineering
- 04MigrationAn existing feature mapped onto the pattern
- 05Design QADoes the generated result keep the intended hierarchy?
Reuse buys speed by giving up some freedom.
A framework constrains design, and a framework-level mistake reaches many surfaces at once. Both are true, and neither makes constraint a bad trade.
Recurring admin interfaces stopped being designed one at a time.
Recurring admin interfaces moved away from repeated one-off design and build work toward reusable product patterns that could be configured and migrated consistently. Predictable patterns reduce relearning for admins — which is what the low-code model was aimed at all along.
What this changed in how I think about design systems.
The highest-value reusable unit is often a behaviour, not a component.
Consistency needs rules for exceptions, not universal sameness.
A design system succeeds when it changes how fast the product can be built and maintained.
And migration is where design-system decisions meet reality.
What I’d measure next
- How often teams request an exception to the framework
- Accessibility consistency across generated pages
- Design and engineering time, measured separately
- Migration defects compared with bespoke implementations
This project taught me that a framework is a set of decisions teams shouldn’t have to remake.