A Design System for an Internal Operations Tool
A concept design system for the unglamorous internal tool a growing team actually opens every day.
The brief / approach
We set ourselves the brief of designing not a marketing site but an internal operations tool — the kind of software a scaling team builds to track its own work, that nobody outside the company will ever see, and that gets judged purely on whether the people using it eight hours a day find it fast and legible.
The constraint we imposed was zero decoration: no marketing polish, no hero imagery, no persuasion — every screen had to justify its own density, because an internal tool's users don't need convincing, they need throughput. That's a genuinely different design problem from every marketing-site service on this roster, and it's why Product UI/UX is scoped in screens and flows rather than pages.
The approach here was to design the data table and the bulk-edit flow first — the screens an operations team actually lives in — before any dashboard summary view, because a dashboard is what gets demoed, not what gets used. A design system followed from those working screens, not the other way around.
Constraint & decisions
The constraint: no screen gets decoration it can't justify with throughput.
- The dense data table was designed before the dashboard, because that’s where the actual work happens.
- A bulk-edit flow scoped as a first-class screen, not an edge case bolted on after the main flows shipped.
- A component system built from the table and form patterns this tool needed, not a generic UI kit applied on top.
