What did I do on ADNOC's design system?
IBM iX was building a new app for ADNOC to plan and manage turnarounds: the planned shutdowns in oil and gas when a plant stops for maintenance. ADNOC had a starter design system, made for its internal HR tools. It worked more like a style library than a full system, and it didn't cover what a turnaround app needs.
With a team of six designers, growing to ten, working on different flows across time zones, the screens kept drifting apart. So I became the team's dedicated design system manager. We didn't replace ADNOC's system, we extended it: components, templates and guidelines for the new app, in four parts.
- Audit firstMeasured the starter system against the new app before building anything: tables and graphs were about 70% of the UI, and about 75% of the app was inconsistent.
- A modular tableSplit one rigid table into parts, with cell types for text, dates, statuses, attachments and more, plus filtering and sorting.
- Templates and patternsPage templates and new shared patterns, the missing levels that stopped every designer inventing their own layout.
- A gatekept library and a handbookOne person owns the library file, requests go through a backlog, and a design handbook says how to use it all.
How did we keep it from drifting again?
The library had been an open file, so anyone could add a component, and copies of the same thing kept appearing. We locked the file, and I became its gatekeeper. Designers asked for new parts through a backlog, and I checked each request before it went in.
Components came with enough options, and no more. We learned that too many options make a component harder to use than to rebuild, and then designers detach it. Everything ended up in a design handbook with usage guidelines, templates, patterns, colour, type, accessibility, and how to contribute.
The product side of the same project, the app itself, is in ADNOC: a turnaround and shutdown management app.
