Governing Telstra AU design system nobody owns alone.
How I helped a component library scale into a set of shared, enforceable rules — so dozens of squads building across an A–Z system stayed consistent without slowing down.
The context
Telstra is Australia’s largest telecommunications company — mobile, broadband, entertainment and enterprise products, sold and serviced across many teams, campaigns and platforms. The design system I contributed to wasn’t a single component kit; it was an A–Z library spanning content modules, data visualisation, form and media components, documented down to breakpoint, state and interaction — used by product squads who rarely spoke to each other day to day.
At that scale, the hard part of a design system stops being “which components exist” and becomes “who decides what changes, how a new pattern earns its place, and how drift gets caught before it ships.” That’s the governance layer I worked in.
Where I worked in the system
Three overlapping areas of responsibility — design and documentation for what the system contained, rules for how it changed, and audits to check what actually shipped matched what was specified.
Component design & documentation
- Specified components across states — default, hover, focus, active, error, loading
- Documented usage at 320 / 768 / 1024 / 1360 breakpoints
- Wrote do’s / don’ts and content guidance alongside the visuals
Contribution & versioning rules
- Helped define how a new or modified component gets proposed, reviewed and approved
- Worked within a tiered model — see the model below — that set different bars for different kinds of change
- Kept version history so squads knew what changed and why
Cross-squad design audits
- Reviewed shipped screens against the spec to catch silent drift
- Flagged one-off variants that should have been proposed as system changes
- Fed recurring issues back into the documentation, not just the ticket
What governance was actually solving
A component library on its own doesn’t stop drift — it just gives drift better raw material. The recurring failure modes we were governing against:
Parallel variants. Two squads solving the same UI problem — a dropzone, a feature grid — differently, a few sprints apart, with no shared record of the decision.
Ambiguous ownership. When a component needed to change, it wasn’t always clear who could approve it, or whether a squad even needed to ask.
Documentation lag. Specs describing a state of the system that had already moved on in production, eroding trust in the docs themselves.
Inconsistent thresholds. A change to a colour token and a change to a whole new module pattern being treated with the same — or the wrong — level of scrutiny.
The governance model
The framework we worked within tiered components by how much scrutiny a change should get — so small, low-risk edits didn’t queue behind the same review as a brand-new pattern, and high-risk changes couldn’t slip through on a small-edit path.
Core
Foundational tokens and primitives used everywhere — colour, type scale, spacing, base controls. Changes here ripple across the whole system, so they carried the highest bar for review.
Extended
Composed components built from core primitives for recurring product needs. Reviewed for consistency with existing patterns before approval, with a lighter process than core.
Pattern / module
Larger, page-level modules assembled for specific product journeys. Faster to propose, but expected to be built from tier 1–2 parts rather than introducing new primitives.
How a change moved through the system
A slice of the system
Representative areas of the library I documented, governed or audited. Shown here as simplified recreations rather than the original internal specs.
HERE
This is a button →
Where governance got hard
Rigour vs. squad velocity
Squads under deadline pressure treated any review step as friction. Too strict, and teams routed around the system; too loose, and the drift problem came straight back.
Leaned on the tiering model so most day-to-day changes moved through a fast, predictable path — reserving the heavier review for the small number of changes that actually touched shared primitives.
Documentation as a moving target
Specs describing states, breakpoints and edge cases go stale fast if updating them is treated as optional once a component ships.
Made documentation updates part of the definition of done for any approved change, not a follow-up task — and used audits to catch specs that had quietly fallen behind shipped UI.
Component accessibility
Accessibility wasn’t a separate audit bolted on afterwards — it was built into what “documented” meant for a component, and it was one of the things I checked for in cross-squad reviews.
Visible keyboard focus
- Interactive controls — video play/pause/rewind, carousel tabs — were specified with a distinct focus state, not just default and hover
- Reviews checked that new or modified components kept a visible focus outline, so keyboard-only use wasn’t an afterthought
Never colour alone
- Data visualisation and status patterns paired colour with an explicit label or number — percentages, values, legend text — rather than relying on hue alone
- Traffic-light and status patterns kept a labelled legend alongside the colour coding
Error & loading as first-class states
- Components were expected to document default, hover, focus, active, error and loading — not just the happy path
- Error states paired an icon with plain-language text, so meaning didn’t depend on colour recognition alone
Metrics
The figures that mattered most for a governance role — reach of the system, and how much drift the process was catching.
Impact
The clearest impact wasn’t any single component — it was that decisions about the system became visible and repeatable instead of living in individual squads’ heads. Squads had a predictable place to check before building something new, and a predictable path to get a genuine gap filled.
What this taught me about governance
A design system succeeds or fails less on the quality of its components, and more on whether the rules around changing them are clear enough that people actually follow them.
Working inside an enterprise-scale system reframed how I think about design systems generally: they’re a governance practice as much as a design one. The components are the visible layer — the durable value sits in the tiering, the review paths, and the discipline of keeping documentation honest about what’s actually shipping. That’s the lens I now bring to any system I lead: design the rules with as much care as the components they govern.