A design system for a platform we did not control

The company-wide employee support portal is where people report something broken, request a service, and check the status of earlier submissions.

Research ran on both sides of the ticket: employees who submit, and IT staff who receive. What came out was not a layout problem. People could not reliably tell an incident from a request. Catalog labels used internal service language, categories overlapped, and when the distinction was unclear the safest move was always the broadest option. Tickets landed in the wrong queue, got recreated, and a catch-all category absorbed everything the taxonomy had failed to name.

The taxonomy was IT's model of its own services. Nobody outside IT held that model, and no amount of visual refinement was going to install it.

The taxonomy was IT's model of its own services. Nobody outside IT held that model.

The portal lives inside an enterprise platform with its own page-building model, its own component markup, and its own styling system. There is a portal, which is what employees see, and a native view, which is where IT works records. Neither is a codebase a designer hands React to.

So the deliverable could not be a stack of page comps. Anything expressed as a pixel redline gets applied once, to the pages someone designed, and diverges on every page nobody did. The design had to arrive as primitives: a global token sheet authored to compile into platform-compatible SCSS, a type scale, a spacing scale, and a small number of patterns strict enough to survive being applied by someone who never read the research.

One neo-grotesque across the page with a clear scale. A near-white ground, one interactive blue, and a single reserved accent used only for the two assistant entry points, so 'this is an AI surface' is a color rule instead of a badge stuck on every component.

One card pattern reused nine times, fixed height, labels top-aligned so a two-line service name cannot break the row. That constraint exists because the catalog content is not under design control and never will be. Designing for the ugliest string the catalog can produce is cheaper than asking service owners to shorten their names.

The Figma file was structured as the backlog: an epic spine, feature lanes, user story sections, and the global token frame sitting above all of it. That is delivery hygiene rather than craft, and on this project it is what kept the tokens from being read as decoration.

The default catalog view was ranked by what people actually requested over the previous three months, not by the service taxonomy. Alongside it, a personalized carousel scrolls while a popular grid does not, so the two lists read as different kinds of content rather than two rows of the same thing.

That is a small change with an organizational cost. Ranking by volume demotes services whose owners expect to see them near the top, and it has to be kept current. It was the right call because the taxonomy was the thing that had failed, and reproducing it as navigation would have reproduced the failure.

Platform developers built the portal. I worked directly with them on CSS primitives and interface structure, because the system would survive only if its implementation carried the same logic as the Figma file.

The portal shipped, but ticket routing, help-desk load, and satisfaction were not measured after launch. Those remain goals, not outcomes I can claim.

No build step enforces the tokens, so adherence depends on review and shared practice. In a codebase I owned, I would make that a lint rule.