ASG ERP: One UI for Ten Departments
A modular Bootstrap 5 design system serving 10 departments across 8 group companies. The UI hasn't needed a structural redesign in two years — which means the fundamentals were right.
The Problem
Amanat Shah Group needed a single ERP capable of serving 10 functionally distinct departments — Inventory, HRM, Accounting, Purchase, Commercial, Admin, Planning, Production, and Marketing. Each department had grown its own workflows, data models, and reporting needs, largely because each had been served by a different tool or spreadsheet template. Building a separate UI for each wasn't sustainable: any shared bug fix or design change would need to be repeated ten times, and the ten copies would drift apart over time. The requirement was one unified system that could serve ten departments without forcing any of them to compromise on the workflows they actually needed.
The user base was non-technical. Many operators had limited prior computer experience beyond basic data entry, so the UI had to be intuitive enough that a factory supervisor could sit down cold and navigate core workflows on their first day, without a training manual open in a second window. That meant prioritizing clear visual hierarchy, predictable navigation patterns, and forgiving input validation over cleverness anywhere in the interface. We also had to design for the reality that operators would make mistakes — fat-fingering a number, picking the wrong item from a dropdown, submitting a form twice — and the system had to either prevent those mistakes at input time or make them trivially reversible afterward.
What We Built
A modular Bootstrap 5 system built around shared layout primitives — consistent page headers, sidebar navigation, card-based content containers, and a standardized table component reused across all ten modules. Bootstrap 5 was chosen over a more modern framework because the team that would maintain this codebase after delivery was familiar with Bootstrap conventions and could extend it without learning an entirely new mental model. Choosing the technology your maintainers can actually work with is often more important than choosing the technology that is technically superior in the abstract. Navigation was role-aware, so a purchase officer never saw HR-only menu items — that scoping reduced cognitive load on users already overwhelmed by their own department's complexity.
Chart.js powered KPI panels that gave leadership a real-time operational view without logging into individual modules, and the whole interface was fully responsive down to tablet-sized screens for supervisors walking the factory floor. The design system was the multiplier: because colors, spacing, typography, and component behavior were standardized from day one, adding a new module didn't require a fresh UI design pass — it required composing existing, already-tested pieces around new business rules. Once a user learned how one module worked, the learning curve for every subsequent module dropped sharply, since the interaction patterns carried over.
Outcome
The platform became the daily operational backbone for 8 group companies, replacing more than 5 legacy tools. Reporting consolidated into a single source of truth — a question like "how much did we produce last month versus what we shipped" could be answered in seconds from the system rather than hours of cross-referencing. The strongest signal that the design held up: the UI hasn't needed a structural redesign in two years, in an industry where requirements shift constantly. The changes that have happened have been additive (new modules, new report types) rather than structural (replacing navigation, redesigning tables). That kind of longevity is the real test of an information architecture: not whether it looks good at launch, but whether it can absorb two years of new requirements without buckling.
A system that needs a redesign every six months has an information architecture problem, not a styling problem, and no amount of restyling will fix it. The lesson I took from ASG ERP is that information architecture — the structure of navigation, the organization of data, the patterns of interaction — is the foundation that everything else rests on, and investing in getting it right at the start pays dividends for the entire life of the system. The visual layer can be updated; the information architecture is much harder to change once users have built mental models around it.
