Chris.Jack hello@chrisjack.au

Chris Jack · Product Design Practice

Twenty-two years leading design. Two years shipping with AI. This page is how I work.

I've built and led the design function inside some of Australia's largest retailers, and for the last two years I've designed and built production AI products myself, from the first sketch through to the deploy. Most people have one half of that. This role needs both, which is why I'm here.

Where I'm coming from

Building got cheap. Judgement is the bottleneck now.

Building got cheap. That's the whole story of the last two years. Work that used to take a squad a quarter now takes people a weekend, and the cost of trying something has fallen far enough that trying isn't the expensive part anymore.

So the bottleneck moved. It isn't capacity. It's judgement. When anyone can produce a working screen in an afternoon, the scarce skill is knowing which screen is worth producing, and being willing to bin the four that aren't.

The second scarce skill is holding quality while moving at that speed. Fast exposes weak taste. A team that ships ten times more will ship ten times more mediocrity unless somebody sets the bar and keeps it there in public, on real work, where people can see the difference.

The third is the one I care most about now. Individual capability is nice. Team capability compounds. An hour spent making my own workflow faster is worth less than an hour spent making the same thing repeatable for twenty other people. That's the job I want. It's also the job I've already done, just with a different payload.

How I build

The system, not the vibe.

Same loop every time, whether it's a weekend build or a client engagement. AI runs through all of it, not bolted on at the build step. It isn't a mood. It's a sequence, and I can teach it.

  1. 01 Analyse

    User research, analytics, support tickets, industry reporting, all of it in at once. Claude synthesises across sources faster than I can read them. Then I argue with what it found until the pattern holds up.

  2. 02 Frame

    Two or three core problems come out of that, written as problem statements. Not features. If I can't say who's stuck and what it costs them, it isn't a problem yet.

  3. 03 Prioritise

    Each statement scored on business impact, customer impact and technical cost. Claude makes the case both ways, I make the call. The score isn't the decision. It's what makes the decision arguable.

  4. 04 Brief

    A PRD for the top three. Problem, users, scope, out of scope, success measures, edge cases. Everything downstream runs on this document, so it's the one I spend real time on.

  5. 05 Context

    Before anything gets generated, the repo gets its context. Brand, business rules, design principles, and a file that maps the design system to real components. The model is only as good as what it's standing on.

  6. 06 Ideate

    Rapid divergence against the brief. Claude and the Figma MCP put up directions in an hour that used to take a week, and most of them get binned. They come out as working screens rather than pictures of screens, so the narrowing happens against something real.

  7. 07 Build

    Claude Code, working to the PRD and the .md files rather than to a chat prompt. Same guardrails every time, which is what makes the output predictable instead of lucky.

  8. 08 Review gate

    A separate agent reviews the build against the principles file and the acceptance criteria in the PRD before I do. It catches the drift I stop seeing after the fourth hour.

  9. 09 Ship and learn

    Small, early, to real users, instrumented from day one. Cut what nobody touched, sharpen what they did, then take the data back to step 01.

Steps 01, 04 and 07 are where the model does the work. Steps 02, 03 and 06 are where I do. Getting that split wrong is how a team ships confident nonsense at speed.

The context layer

Prompts are disposable. Context is an asset, and it's the part a team can actually share. Every build starts from the same set of files sitting in the repo.

brand.md
Voice, tone, and the things we never say.
design-principles.md
Calls already made, so they don't get re-argued screen by screen.
design-system.md
Tokens, components, and what maps to what in code.
business-rules.md
Logic, constraints and edge cases that hold true regardless of screen.
prd.md
What this specific build is, and what it isn't.
CLAUDE.md
How the agent behaves in this repo. What to check, what to never touch, how to verify.

Writing these is the slow part, and it's the part that pays. The first build takes longer. Every build after it starts from a model that already knows the brand, the rules and the system, which is why the second one is fast and the tenth one is consistent.

The failure mode is real and I've hit it. Files go stale, the model keeps building confidently against last quarter's rules, and nobody notices until review. So each file has an owner and gets checked at the same gate as the code.

The toolchain, and where each one stops

A tool list on its own says nothing. What matters is knowing the edge of each one.

Claude Code, Kimi, GLM 5.2

Where it fits

My main build surface. Multi-file changes, refactors, test coverage, deploys, and anything I can describe faster than I can type.

I run more than one on purpose. The tooling turns over every few months, so keeping pace with it means testing it rather than reading about it. Same prompt and the same guardrails across each one, so the only variable is the model and the thing I'm actually comparing is cost per build.

Where it doesn't

Novel interaction design. It will build the wrong thing beautifully if I haven't framed the problem first.

Figma, Paper, Pencil

Where it fits

Figma is still where the craft happens. The thinking surface before code, and the shared artefact when other people need to see the system rather than one screen. MCP wires Figma context straight into Claude Code, so what gets built uses the real tokens rather than a translation of them.

Paper and Pencil sit closer to the build. Both are pointed at AI and at getting design out as code rather than as a file someone has to reinterpret.

Where it doesn't

Final visual polish. That happens in the browser now, against the real type rendering and the real content.

The rest of the stack

Hosting and deploy
Cloudflare, Vercel, GitHub
Analytics and insight
PostHog, Sentry
Database and auth
Supabase
Payments
Stripe
Email
Resend
Issue tracking
Linear
Documentation
Notion, Markdown in the repo
Code editor
VS Code, Cursor

How I decide what tools earn a place

Written so another team can run it without me in the room. That's the test of whether it's a process or a preference.

  1. Name the job, not the tool

    One sentence on the job to be done and who's currently doing it the slow way. If I can't write that sentence, I'm shopping, not solving.

  2. Rebuild something you've already built

    Take a piece of work the team has already shipped the old way and do it again with the new tool. Document it and time it, then put that against what the first run actually cost. A benchmark beats an opinion.

  3. Set the adoption bar before you start

    It has to beat the current path on the measure we agreed, and a second person has to reach the same result from the written instructions. One person's magic isn't adoption.

  4. Kill criteria and a review date

    Both set on day one. If it hasn't cleared the bar by the date it goes, and I write down why, so nobody reopens the argument in six months.

    Things I've killed on this basis: v0, Lovable, Bolt and Windsurf, among others. Each one was worth the two weeks it took to find out.

Shipped

Five builds, one repeating pattern.

Every one of these ran the same loop. A real problem worth solving or a passion project, designed and built by me end to end, shipped to real users, then measured.

Three of them circle the same problem space on purpose. Groups of people organising and paying for a trip together. Plans handles the itinerary, Savora handles the money, Bogey Mates is where the group already is.

Commercial client Automotive trade · designed and built end to end

Lucar

The problem

Lucar's jobs move through the sheds in stages: panel, weld, paint, assembly. The workers were stamping and writing each one up on paper as they went, and at the end of the day those sheets went to the office admin, who typed them into Excel and built the reports the business and the board ran on.

Ten minutes a day per worker on paperwork, and they raised it constantly. One to two hours a day for the admin just on data entry, then another three to four building the reports and going back and forth with the board about the numbers.

What I built

A worker app running on two tablets in the sheds. Tap your name, the job, the task and the time. That's the whole interaction, because anything more would have gone back to paper.

Then a web app for the office: dashboards across operations, jobs, tasks, workers, timesheets, models and makes, and issues. AI sits on top of it doing prediction and status, so the board can see whether a job is heading over time or over budget while there's still room to act. Reports are live and on demand rather than assembled by hand.

  • 4 Weeks from brief to production
  • 10 min Back in each worker's day
  • 4 to 6 hrs Off the office admin's day, and the board gets live numbers
Lucar office dashboard. Live tiles for active projects, hours logged, budget burn and average efficiency, above charts for hours per project and hours per stage, with an active projects table below showing status per job.
The office dashboard. Budget burn and efficiency against estimate, live, instead of assembled overnight.
Own product Itinerary tool for travel agents

Plans

The problem

Travel agents assemble the same itinerary by hand every time. The confirmations land in an inbox as a pile of PDFs and forwarded emails, and somebody has to turn that into something the client can actually use on the road.

What I built

A tool that reads the confirmation emails and pulls out the flights, the accommodation, the tours, the tickets and the dining, then builds the client's itinerary from them. The client has the lot on hand before the trip, during it and after it, and can still reach their agent directly when something urgent comes up.

It started as a tool for one travel agent, my wife. It's still being built out, because it turned into something much bigger than that.

Plans on a phone. A live itinerary for a Torquay trip with the day-by-day timeline and the first flight pulled out of a confirmation email.
A live itinerary, built from the confirmations rather than typed up again.
  • 8Weeks to the MVP
  • 20Travel agents on it, using it constantly
  • 100Client itineraries built
Own product Group funding

Savora

The problem

Getting a group to pay for something together always collapses into a spreadsheet and one person chasing everybody. End-of-year trip for a sporting team, a golf weekend, money towards a wedding present. Same mess every time.

What I built

One place that holds what the group is funding, who owes what, what's already been paid and where the money is going. Timelines sit next to it, and the group makes the calls together in the app instead of in a chat thread nobody can search.

Stripe Connect handles the money, Supabase handles the database and auth. Still in progress, with the MVP out in front of potential investors for feedback.

  • 4Weeks to build
  • 3Goals running on the MVP
  • 16Users
Savora goal page for a golf trip. The pool sits at 86% funded, $1,550 of $1,800, with a funding breakdown of raised, remaining and per person, milestone payments, and a members panel showing who has paid in full and who still owes.
A real pool, 86% funded. Who owes what, what's paid, and where the money is going.
Own product Social golf

Bogey Mates

The problem

Golf is a social game that gets recorded like an accounting exercise. The scoring apps handle the numbers and throw away everything that made the round worth turning up for.

What I built

A chat-first app built around the playing group, so the scoring and the banter live in the same place, with the group structure to run tournaments and events off the back of it.

The other half is trips. Build the golf trip, have a travel agent book it, pool the money for it, then keep the scores and the conversation in one spot so the group holds together between trips.

The holes are modelled rather than drawn. I pulled lat and long data from OpenStreetMap and the golf APIs, then trained a model to lay each hole out as polygons, which is what makes shot optimisation possible on a course nobody has hand-built.

Bogey Mates on a phone. A golf trip page for a Mornington Peninsula long weekend with seven members, an invite code, and the rounds booked across three courses.
A trip, its group, and the rounds. The social layer the scoring apps throw away.
  • 4Weeks to build
  • 2Golf groups on it
  • 24Rounds logged
Open source Golf sim connector

BirdieSmash

The problem

The Square golf launch monitor doesn't connect to simulator software easily, and left handed players get the worst of it. I hit the problem myself and there was no fix coming.

What I built

I used AI to decompile the client and work out how it talked to the device, then built a connector on top of the API. It's open source, and it's now being used by a group of left handed golfers running the same launch monitor.

Then the better part. My six-year-old knows I build things, so he asked whether we could make games for it. We opened Claude and built six of them together. He's left handed as well, and he plays them constantly.

A young boy mid-swing on a golf simulator mat in a garage, playing the Pirateships game on BirdieSmash with live shot data down the left of the screen.
Pirateships, one of the six. Tested on the mat in the garage by the person it was built for.
  • 6Games built with my son
  • 47Users
  • 2Contributions back from the community
Craft at scale

Before AI was my medium, scale was.

Two stories, told through what they changed rather than what they looked like. There's some old UI here, but it isn't the point. The systems are.

Coles Digital platform · design leadership

The web platform behind $3.7B a year

The remit

I led 20-plus designers across six product crews and three C-suite pillar projects. We built the web platform from scratch. It now carries more than $3.7 billion in annual online sales.

Why it's here

Not for the screens. For what happened to the way that group worked, and the fact that it held after I left. Four things did the work.

  • A design platform with an owner

    One component library, one set of tokens, a named owner and a release process. Crews stopped rebuilding the same date picker six ways.

  • Rituals with a standing format

    Weekly critique, same time, same agenda, and a rule that you bring work in progress rather than work you've finished defending.

  • A written quality bar

    A short definition of ready and definition of done for design, applied at crew level. The argument happened against a document instead of against me.

  • Hiring that didn't need me in the room

    I wrote the scorecard and the portfolio exercise, then trained four other people to run it, so the standard survived my calendar.

A Coles recipes and inspiration page built on the web platform, showing the seasonal collection header, an in-season produce row and recipe guide cards.
One page off the platform. The interesting part isn't this screen, it's that six crews could build it the same way.
Coles Group Design Manager, 2022 · Vision and strategy

The everyday life vision

The question

Could the whole spread of Coles brands work as one lifestyle app, the way they do across much of Asia. Grocery, health, insurance, mobile, fuel, financial services and marketplace each lived in its own app and channel. Leadership wanted to know whether it could become one thing, and why it should.

What I did

I built the vision with the exec suite rather than for them, and tied it back to the five year growth plan. That's the part that mattered. It meant they could weigh it against everything else on the table instead of filing it under interesting.

I mapped the everyday-life categories Coles could own or partner into, then designed four of them end to end so there was something real to look at rather than a diagram. One journey ran through the lot: a family holiday booked through partners, green credits planting trees on a Coles Forest map, health rewards tied to a wearable, and payments and fuel through Scan&Go and Pay-at-Pump.

It was never meant to ship. The deliverable was a decision, and it gave a fairly abstract ambition enough shape for leadership to weigh it up properly.

Four Coles Superapp screens side by side: the hub with a wallet and eight everyday-life categories, Food and Drink with supermarket and restaurant browsing, Health with activity tracking and rewards, and Sustainability showing trees planted and impact badges.
Four areas designed in depth, so the idea was concrete enough for executives to argue with.
The Sally's family holiday journey map. A single winding path across fifteen touchpoints, from booking flights and accommodation through marketplace, green credits, games, healthcare, utilities, step counts, fuel at Pay at Pump and a grocery delivery waiting at home.
Sally's family holiday, running end to end through booking, green credits, health rewards, payments and fuel.

Shared with permission.

Seek
Sole designer on the mobile apps. Applications up 75%, to 1.5 million a month.
Woolworths
Fulfilment platform for the people picking and packing orders in store.

I've run this adoption play before

Then

Rolling out a design system

Four retail organisations, including Coles and Myer

Now

Rolling out AI ways of working

Same job, different payload

Both need the same four things

Who has to say yes
GM through to C-suite. Not the design team. Design was never the blocker on either one.
What buys the yes
A funded owner and a number. Not a manifesto, and not a deck of examples from other companies.
How it actually spreads
Find the crews already curious, help them ship something good, let everyone else notice. A mandate from the centre gets complied with. It doesn't get adopted.
What proves it worked
Other people using it when you're not in the room. Everything else is a vanity metric.
What's different this time

  • The pace

    A design system held its shape for years. AI tooling turns over every few months, so kill criteria and review dates carry much more of the load.

  • The fear is bigger

    With a design system, designers worried about losing craft. With AI they're worried about losing the job. You have to answer that out loud and early, or the rollout stalls quietly and nobody tells you why.

The point isn't the artefacts. It's that I've run this play before, four times, and it stuck. AI is the new payload. The scaling skill is the same.

Where design goes next

When everyone can build, design splits in two.

A view of where the discipline is heading, and where I want to be standing when it gets there. Every claim here comes from something I've run, not something I've read.

The weight moves to both ends

Design used to run like a relay, with the fat part in the middle. That middle is the part AI ate.

The craft didn't die. The volume of it did. What used to take three weeks of state-by-state polish now takes an afternoon, so the value moved to the decisions either side of it.

The front half

What it is

What are we building, why, and is it the right thing. Does it fit the longer plan.

Why it got more valuable

Accessibility, usability and whether the thing actually works for the person who needs it. None of that got easier. Everything around it got cheaper.

The middle

What it was

Pixel work as a full-time job. Not the taste behind it, the hours of it.

Where it went

Into the tooling. This is the part of the job most portfolios are still built to show, which is why so many of them read as dated.

The back half

What it is

Designers who ship, and who hold the quality line while the rest of the org ships too.

Why it got more valuable

When everyone can build, somebody has to own whether the thing that got built is any good. That's a design job now, not a favour.

AI doesn't fit the design process we've got

Not in its current shape. The honest answer isn't to bolt it onto the existing stages. It's to change what the stages are.

Discovery and synthesis

Where it pays

The historic bottleneck. Weeks of reading and sorting compressed into hours, so you reach the underlying problem while people still care about it.

Where it stops

It can't tell you which problem is worth solving. That judgement is still the job, and it's the half that got more valuable.

Continuous optimisation

Where it pays

Build it, ship it, watch it, tweak it. Small moves you can attribute, instead of a long run at a feature nobody has touched yet.

Where it stops

It won't rescue a bad direction. Optimising the wrong thing faster is still the wrong thing, just with better charts.

The stage-gate process itself

Where it pays

Nowhere. This is the bit teams get wrong first.

Where it stops

Drop AI into a process built around long runs at pixel-perfect features and all you get is the same handoffs, arriving sooner. The shape has to change, not the speed.

Roles converge. Depth becomes governance.

An engineer can design now. A product manager can build. A designer can do both. That doesn't collapse three roles into one. Everyone gets broader, and each discipline stays deep enough to govern one thing for everybody else.

Design

Everyone can now

Produce a screen that looks right.

Design still governs

Whether it's the right thing, whether it works for everyone who needs it, and whether it holds together with everything around it.

Engineering

Everyone can now

Generate code that runs.

Engineering still governs

How it's built. Whether a designer's build or a PM's build fits the codebase and the standards that keep it maintainable after they've moved on.

Product

Everyone can now

Write a spec and ship a feature.

Product still governs

Whether it ladders to the business strategy, and whether everyone's working to the same framing and the same definition of done.

This has happened before. UX, research and content design used to be separate specialists. They merged into product design, and the discipline came out stronger rather than thinner. The same merge is happening now across a wider boundary, and the people who did well last time were the ones who got specific about what they still owned.

It only works if people are comfortable giving each other direct feedback on work they used to own outright. That's a culture problem before it's a tooling problem, and it's the part I'd expect to spend the most time on.

What didn't work

Honest limits.

Building custom software for generic problems

What I tried

Custom internal tools for problems that thousands of other companies have too. It felt clever at the time. It was mostly ego.

Where the boundary is

Off-the-shelf software wins on generic problems and it isn't close. Someone else already paid for the edge cases, the security review, the mobile app and five years of support. My version is cheaper on day one and more expensive every day after.

What I do now

Generic problem, buy it. Misfit problem, where the shape of the business is the reason nothing off the shelf fits, build it. I ask which one it is out loud before I open anything, and I say no to my own ideas fairly often.

Blaming the model for a thin brief

What I tried

The first version of Plans. I ran it across a few models with a prompt that opened "you are a professional travel agent who is looking for", and not much after that. No principles, no guardrails, and no real account of what I actually wanted.

I got a basic site with no depth. Exactly what I'd asked for.

Where the boundary is

The model didn't do anything wrong. The prompting and the guardrails weren't meaningful. This is the most common lesson when a team first brings AI in, and it's the one that makes people write the whole thing off. They judge the tool on work they under-specified.

What I do now

I treat context as the deliverable. Principles, constraints, examples of good and bad, and the reason the work exists all go in before anything gets generated. When the output is thin, I fix the input before I touch the tool.

A living document nobody wanted to live in

What I tried

An end to end service blueprint for fulfilment at Woolworths. In all the time I was there they'd never had a single map of the systems, the processes and the experiences across fulfilment, so I built one with the team and asked them to keep contributing to it as a living document.

Where the boundary is

Two months after I handed it over, adoption was low and there were several copies of it floating around. The blueprint wasn't the problem. Its purpose was. I'd never made the case for the role it played beyond the mapping exercise, so the designers read it as one more thing to maintain, and they were right to.

What I do now

Nothing gets handed over as a living document without a named owner and a reason it exists that survives me leaving the room. If I can't say which decision it makes easier, I don't ask anyone to maintain it.

Making it scale beyond me

How I turn one person's practice into a team's.

What I've already systematised

Written down, handed over, and still running in places I no longer work. That's the only test I trust.

  • The 30/60/90 gateways

    Discovery, design and build reviewed with stakeholders at 30%, 60% and 90%. The 30% gate is the one that saves the money, because it's the last point where you can change direction without anyone losing face.

  • A prioritisation framework

    So the roadmap argument happened against agreed criteria instead of against whoever was loudest in the room.

  • Career development framework

    Levels, expectations and what actually moves someone up, written down so progression didn't depend on which manager you happened to get.

  • The cadence model

    Which meetings exist, who's in them, and what decision each one makes. A team of 20-plus needs that written once so nobody has to arbitrate calendar drift every quarter.

  • Four design system rollouts

    Funded, adopted, and still in use. That's the same play I'd run for AI ways of working, and the reason I think I already know where the hard parts are.

  • The working-session diagnostic

    A fixed format I run with a team. Map where design time actually goes, name the biggest frictions, leave with one thing to change this week. Written down, so someone else can run it.

  • A shared context layer

    The brand, rules, principles and design system files a team builds against, versioned in the repo with a named owner each. Same rollout play as a design system, same reason it works. One set of decisions, made once, used by everyone.

  • Documentation habits

    Everyone leaves a record of the decisions and the why. A README, a Confluence space, or best of all on the file itself, so whoever picks it up knows what we already tried and what we ruled out.

The known quadrant

A 2x2 we used to sort incoming work before anyone committed to a date. Problem across, complexity down, so you could see at a glance what needed discovery and what only needed an estimate.

Known known

Clear problem, clear complexity. The only quadrant where a confident estimate means anything.

Unknown known

We can see how hard it is, but we haven't pinned down the problem we're actually solving.

Known unknown

The problem is clear. How hard it is to solve isn't, so scope it before you size it.

Unknown unknown

Neither is clear yet. This is discovery work, and calling it anything else is how roadmaps break.

It fed straight into the gateways. Work sitting in the known known corner could run from kickoff to the 90% gate quickly, because there was nothing left to find out. Work in the unknown unknown corner got the whole design process.

First 90 days

Month 1

Listen and map

Where design time actually goes, counted rather than guessed. I sit in the crews and watch the real work before I have an opinion about it.

Month 2

Build, ship, show

Pick the highest-friction problem on that map. Build it, ship it, then show the before and after in public. One thing, done properly.

Month 3

Systematise

Write it down, teach two other people to run it without me, and put the next six months on a roadmap with named owners.

My AI practice was built solo, at production depth. My team-scaling practice was built at enterprise breadth. This role is the intersection, and that's exactly why I want it.