Enterprise Design System — Nexus Platform

Node4 is a UK managed services provider. Nexus is the portal its customers log into to run the things they buy — cloud, connectivity, data centre capacity, security, voice. It is also the tool Node4’s own staff use to administer those accounts. One product, two audiences, opposite needs.

I came in as the first dedicated product designer on it, with several squads already shipping modules in parallel: Engage for voice and SIP routing, Data Centre for power and sensor commitments, plus Cloud, Network, Security, Managed IT and billing.

The most useful early research was internal. Service desk staff and account managers were the people absorbing the cost of an unclear interface — every ambiguous screen arrived on their phone as a support call. They could name the exact screens that generated the calls, which is a better bug list than most usability studies produce.

I ran discovery workshops with product and engineering to map what each module actually did against what the navigation claimed it did. The gap between those two things was the project.

Nexus had grown a module at a time. Each squad had independently solved the same set of problems — tables, filters, status, forms, empty states — and each had solved them slightly differently. A customer moving from Data Centre to Engage was effectively learning a second product.

Underneath the visual inconsistency was a structural one. Inconsistency was cheaper for any individual team than consistency was. Nobody was being careless; the incentives simply pointed that way. Any fix that relied on goodwill would decay the moment a deadline arrived.

So the brief was not ‘make it consistent’. It was: make the consistent path the fastest path for a team under pressure.

I built the system on Atomic Design principles, but the taxonomy mattered less than the shared vocabulary. Once a designer and an engineer could both say ‘that’s the standard data table with the filter bar variant’, most of the argument disappeared.

Rather than inventory the whole product first, I started with the patterns carrying the most traffic: the data table, the filter bar, the status indicator, and the form. Between them they accounted for the overwhelming majority of screens.

Every component shipped with its states documented — empty, loading, error, partial permissions, too much data, not enough data. Those states are where enterprise software actually breaks, and they are exactly what gets skipped when components are drawn as happy-path pictures.

The work ran through wireframes and prototypes, tested with internal staff before build, into a Figma library mirrored by the front-end implementation.

All of it was remote, from Lisbon, against UK product managers and engineers across a time zone. That changed how I designed: written specification had to carry the reasoning, because I would not be in the room to explain a decision when someone hit it three weeks later.

Nexus modules ship against a shared library rather than as one-off screens. New features start by assembling existing patterns, which is the point — the system is only real if using it is easier than not using it.

Documented states and specifications removed a large share of the design-to-engineering back and forth, particularly around the edge cases that previously got discovered in QA.

The system stayed in use after I left the engagement. For a design system that is the only outcome that really counts; anything that depends on its author being present was a style guide, not a system.

I don’t publish post-launch metrics from client engagements. What I can point to is the artefact and its adoption: a component library with documented states, running across multiple squads, still in service after the consultant went home.

Want the detail behind any of this?