AI-Native Design Operations

The problem

The University of Melbourne is not a startup. It serves over 50,000 students and employs more than 10,000 staff. It has governance committees, risk frameworks, and procurement processes designed to prevent things from moving fast.

Into this environment, AI arrived — not as a gradual evolution but as a step change. Suddenly, the tools existed to generate design artefacts, analyse complex systems, and build software from natural language. The question wasn't whether AI would change how design teams operate. It was whether the change would happen to the team or with the team.

Most design functions in similar institutions were either ignoring AI or bolting on a ChatGPT enterprise licence and calling it a strategy. Neither approach was going to cut it. A design function that doesn't learn to operate with AI becomes a production bottleneck. A design function that uses AI without governance becomes a liability.

The context

When I took on the Associate Director role for Service Experience & Design, the function had three separate teams, no unified operating model, and no AI capability to speak of. The implicit assumption was that design teams produce artefacts — journey maps, wireframes, research reports — and AI might make those artefacts faster.

That assumption was wrong. AI doesn't just make artefacts faster. It changes what a design team is — from a production function to an intelligence function. The artefacts become byproducts of the thinking, not the thing itself.

But making that shift inside a risk-averse institution required more than enthusiasm. It required infrastructure, governance, and an operating model that could survive scrutiny.

The approach: four pillars

I designed a strategy around four interconnected pillars. None works in isolation. Together, they create a flywheel.

1. Governance

Before building anything, I needed to answer the question every institution asks first: who's accountable?

I developed a Governance Matrix that specified decision rights across four layers: strategy (what we build), architecture (how it connects), delivery (who builds it), and operations (who keeps it running). For each layer, the matrix named the accountable person, the informed stakeholders, and the escalation path.

This wasn't bureaucracy. It was air cover. When someone asked "who approved this AI agent running at 3am?", there was an answer — and a person attached to it.

I also proposed Experience-Based SLAs — a framework for measuring AI operations not by uptime but by whether the people using them could complete their tasks. This reframed the conversation from "is the technology working?" to "is anyone better off?"

2. Experience

The second pillar was about what the team actually builds — and how. I established the Enterprise Services Group GitHub organisation as a shared home for the team's work: 10 repositories spanning AI agents, journey management, information architecture redesign, and team tools.

This wasn't just about code. It was about visibility. When work lives in a public GitHub org, it's discoverable. Other teams can see what's being built, contribute, and reuse. The org became the single source of truth for the function's technical output — replacing scattered local folders, emailed files, and the institutional amnesia that comes with them.

3. Technology

This is where most AI strategies start and end. I treated it as the third pillar, not the first, because technology without governance and experience context is just expensive noise.

What we built, all inside VSCode as the development environment and published through our GitHub org:

• Claude Code agents: 8+ specialised AI coding agents running inside VSCode, each with its own project conventions, quality standards, and domain knowledge. They handle feature development, code review, and automated testing across multiple codebases.
• GitHub Copilot integration: The shared baseline every team member already had access to. A common floor that meant a win for one person was a win everyone could copy within five minutes.
• Team enablement repos: Journey Management governance, online retrospectives, team prioritisation tools, and UX Agent — repositories that turned the team's internal processes into shared, version-controlled artefacts.

The architecture was designed around the tools the team already had. VSCode wasn't a new platform to learn — it was the editor they opened every morning. AI capability was layered into the existing workflow. And by publishing everything through the ESG GitHub org, we made the invisible visible — turning individual productivity into organisational capability.

4. Capability

The fourth pillar was about people — because infrastructure without capability is just an expensive toy nobody uses.

I ran the five-move playbook described in You Can Just Do Things: start where people already are, show them the ceiling, get air cover, make it personal, and build an engine that compounds.

The AI Capability Team I established now teaches other divisions how to use AI — not because they were hired to, but because they became the people who actually knew how.

What changed

The transformation happened in layers.

Layer one: time. Tasks that used to take days — research synthesis, IA audits, first drafts of strategy documents — now take hours. AI agents handle the heavy lifting while the team focuses on judgment and direction. Design artefacts that used to take days of production work now take hours.

Layer two: leverage. Building in public — through the ESG GitHub org — meant every project became discoverable. When one person built a retro tool, the whole team could use it. When a journey map got committed, it didn't sit in someone's inbox. The org turned individual effort into shared assets. Team members who had never pushed code before were opening pull requests within weeks of the org being established.

Layer three: posture. This is the one that matters most. The team stopped being people who were nervous about AI and started being the people other teams come to because of AI. That shift — from defensive to generative — is worth more than any individual tool or workflow.

Layer four: governance credibility. The Governance Matrix and Experience-Based SLAs gave the function a seat at tables it had never been at before. When the institution needed to think about AI governance, the design function had already built it.

What didn't work

Not everything landed.

The "everyone codes" ambition was unrealistic. Some people on the team took to vibe coding immediately. Others didn't — and pushing them created anxiety, not capability. The lesson: AI capability is a spectrum. Some people will become builders. Others will become expert prompters. Both are valuable. Forcing everyone to the same point on the spectrum is counterproductive.

Autonomous workflows accumulate cruft. Scheduled agents need regular pruning. Without it, you end up with orphaned processes chewing resources for no reason. I now run quarterly infrastructure spring cleaning.

Lessons

1. Governance first, technology second. In a risk-averse institution, the governance framework is what makes everything else possible. Build it before you need it, not after someone asks.
2. Dogfood everything. I built the AI infrastructure for myself before asking anyone else to use it. When I demonstrated a working system, permission followed. When I pitched a vision, it didn't.
3. Build in public, lead by example. I didn't tell the team to use GitHub — I set up the org, wrote the foundational repos, and made the work visible. When people saw what was possible, they joined in. Leadership through demonstration beats leadership through directive every time.
4. Air cover is not optional. Grassroots energy without leadership buy-in fizzles. Leadership buy-in without grassroots energy is theatre. You need both.
5. The best capability building is indirect. Don't mandate AI training. Make it personal, give people permission, and let them teach each other. The capability that emerges is stickier than the capability that's assigned.