Enterprise administration design system: Admin UI Kit

Founding designer and long-term steward. I stood this up from scratch and led it over multiple years, working with a team of two to three junior designers who paired with me on component design and adoption work, and eventually a senior designer who took over stewardship when I moved on. I aligned with and helped pilot the central Atlassian Design System team's strategic model for local and centralised systems.

Originally called Admin Foundations Kit (AFK), later renamed Admin UI Kit to conform with Atlassian's naming convention for local design system libraries.

The administration app integrates across the entire Atlassian product suite, and as such had many contributor teams from all over the company — each doing their best to add to a cohesive whole, but lacking alignment on norms and existing functionality. As the capabilities and IA of the app continued to grow, more inconsistency in both interaction design and visual communication became apparent, and began surfacing in customer feedback.

Given that the rate of growth was only going to increase, there was no dedicated engineering team to own a shared front-end component layer. The problem was clear, but the ownership model was not.

I ran what I called a consistency baselining exercise — a full audit of the admin hub, demarcating components that were spiritually the same but implemented differently.

The results were stark:

• 27 pages leveraged tables — over 80% of the entire admin surface
• 27% provided filters, with 0% using a common component
• 50% provided pagination, with only 23% using the most scaleable API method
• 5 different UI formats for action buttons, with only 38% conforming to guidelines
• 23% provided sortable columns

I went deeper. I advocated for and was granted time to pair with a front-end engineer, and we dug into the code to identify a second layer of variation: components that looked the same visually but were disconnected codebases. Then a third layer: pages where a component should have existed but was absent entirely — tables without filters that needed them, lists without pagination at enterprise scale.

This gave me three dimensions of inconsistency: different designs for the same concept, same design but disconnected code, and missing capabilities. I connected these findings to customer feedback — users were explicitly calling out filtering issues, clunkiness, and lack of capabilities in support channels.

With no dedicated engineering team, the kit team needed to find other pathways to get shared components built and adopted. We ran office hours where feature teams could sign up, discuss their needs, and where we'd identify opportunities to align their work with shared componentry. From there, three main mechanisms emerged:

Partnership with feature teams. When teams were designing new features and encountering deficient precedents in the app, we'd insert ourselves into the conversation. The pitch: we'll help you design this properly, your engineers will build it as a shared component in the right repository — it'll be accessible, scaleable, and sanctioned. You won't create a rogue component that gets flagged. The component gets built without our team expending engineering resources. The constraint was timing — this was entirely opportunistic.

Opportunistic refactoring. When feature teams were touching code in areas where we'd already built shared components, we'd advocate for them to swap out the old implementations while they were in there. This paid down refactor debt incrementally and was a shared effort across the team.

Engineering alliances. I personally sought out engineering leaders who had KRs around accessibility or scalability. The argument: you can do spot fixes across the surface area, or you can refactor to shared components and lift accessibility across the board in one move. This appealed to engineering values and gave us an alternative pathway that bypassed the feature team bottleneck.

Adoption was also enforced through critique — the craft excellence standards I'd written required designs to use shared componentry where it existed, and design leads would flag bespoke implementations in review.

The Admin UI Kit grew from one or two fledgling attempts at shared componentry across the application into a singular, governed library.

• Weekly component insertions grew from ~5,000 to 11,500 over the life of the project
• The Focus Task component (a wizard pattern) saved roughly 23 story points of dev time per implementation — across 7 known implementations, that amounted to approximately one month of designer time saved as of December 2022. These time savings compounded with each subsequent usage.
• The library became an acknowledged local system within Atlassian's design system ecosystem

The consistency work continued beyond my direct involvement. Other designers carried the refactoring forward. Bar the most legacy surfaces of the application, tables and action buttons have been fully refactored to shared components. Filters have been refactored across many pages. The application is now fully tokenised, which enabled delivery of dark mode.

In July 2025, the administration experience received a visual refresh — announced to customers via the Atlassian Community — which was made possible by the foundational component and token work the kit had established.

I successfully handed stewardship to another designer when I moved on to other projects.