Platform & Navigation Design at Scale

Context

NavX exists because navigation is an obvious cross-product problem, and historically it's been solved independently by each product. NavX's job is to own consistency at the platform level while keeping product teams unblocked.

This is platform work. Every decision we make has downstream consequences for other product teams, their release cycles, their change control processes, and their customers. The craft challenge is real: balancing standardisation against flexibility, centralised control against contributor autonomy, and speed against the risk of breaking customer trust.

Custom Theming: shipping platform change inside enterprise constraints

Atlassian's navigation theming is fragmented. Jira and Confluence each have their own Look and Feel settings, they don't talk to each other, they don't cover all apps, and they aren't compatible with where navigation is heading. Custom Theming is the project that fixes this — a single global theming model, managed centrally by admins, applied consistently across every app.

I joined this project after initial research and concepts were already in play. My work has been to refine the design post-testing, incorporate what we learned from enterprise admin interviews, and shape the solution against the constraints that emerged from that research.

The research gave us a clear guardrail: admins strongly resist org-level changes that remove site-level exceptions, especially for sandboxes. Org-level settings were rated well when overrides were preserved, and badly when they weren't. That single finding shaped most of the design decisions that followed — including where to land on global-vs-site hierarchy and how to handle the preview experience admins asked for.

The harder work has been sequencing. Custom Theming is a large model, and trying to ship all of it at once would have delayed work that other teams were waiting on. I helped shape the case for phasing the rollout — landing a Phase 0 first that establishes the foundation, unblocks dependent teams, and gets the theming model in customers' hands, with the broader vision delivered in subsequent phases.

Compromising on scope without compromising on the destination is a craft in itself. The goal at platform scale isn't always to ship the most complete design in one go — it's to ship the design that creates the most momentum for what comes next.

Making design systems AI-readable

The second project I'm leading is a shift in how our design system documents itself — specifically, making it readable by AI tooling as well as by humans.

Navigation component documentation is currently built for designers and engineers reading it in Confluence. MCP servers, AI agents, and vibe coding workflows need something different: structured, complete, well-tagged source content that can be consumed programmatically. An audit of our component pages found most of them below the quality bar for AI consumption — placeholder descriptions, missing usage guidance, stale references, inconsistent structure.

I'm the DRI on this work. I defined the problem through a content quality audit and an MCP readiness audit, scoped the project into phases (quick wins, content authoring, MCP structuring, AI-assisted maintenance), and I'm leading the effort with a content designer supporting part-time.

The design decisions are less about visual output and more about content architecture: what structure makes documentation useful to both a designer reading it and an AI agent consuming it. The work maps to two of Core Design's key results on AI-native infrastructure, which has helped me build the case for prioritisation and capacity.

Designers contributing to design systems in 2026 aren't just shipping components; they're shipping context. If the documentation isn't AI-readable, the design system doesn't scale into the tools designers and engineers actually use.

What I've taken from this work

Platform work doesn't look like feature work. The decisions are rarely about a single screen; they're about the system behind it, and the teams who depend on that system. The craft is in the judgement calls — what to standardise, what to leave flexible, when to push for the ideal and when to ship the phase that unblocks the next step.

I've been surprised how much of the work is in building the argument, not just the design. Evidence, stakeholder alignment, and trade-off articulation matter at least as much as the craft itself.