Skim mode is on: just the key point of each paragraph. Turn it off to read the full case study.
What I inherited
The team ran on a startup’s habits. GoDaddy created its Commerce division when it acquired Poynt in 2021, and those ways of working carried over. When I joined in July 2024, the in-person selling design team was three designers, and it had no operating model of its own. The first designer I added was an internal transfer I made the case for, to staff our terminal design system work.
No one could see the team’s real load. There were two Jira systems. Product managers sent asks straight to designers, so much of the work never reached a backlog; I called it hidden work. Nobody, including me, could see the team’s real load or set priorities against it. There was no regular design review or critique, no shared practices or documentation, and no research practice beyond occasional hallway testing that nobody tracked. Each surface had its own design system.
Knowledge lived in people’s heads. Each designer owned a device, and its rules lived with them. How we reorganized around the merchant’s journey is its own case study; this one is about the team.
Building the operating model
| Area | Before | After |
|---|---|---|
| How work gets reviewed | No regular review or critique | Design quality reviews, and weekly cross-squad demos: “demo once, share wide” |
| How knowledge is shared | Device rules in one or two heads; research as an occasional event | Surface guides, device sheets, a payment flows reference, and field research every major release |
| How AI fits in | Individual experiments | Shared tools, agents and practices across the team (below) |
| How design systems fit together | One per surface, built and maintained separately | I led Glass 2.0, the terminal’s design system, then proposed converging all three through shared theming, so features are built once and shipped everywhere |
Before
After
Me, the design manager, coaching three squad leads
Before: one designer covered Terminal Pro and Terminal Flex, one covered Terminal Duo, and one covered the mobile app and the web.
After: Activation and setup has a squad lead and two designers. Catalog, inventory and orders has a squad lead and one designer. Payments and checkout has a squad lead and one designer. Each squad works across terminal, mobile and web.
- A designer
- Squad lead
I made research a practice. Every major release now includes in-person research in merchants’ stores, and every designer has monthly merchant conversations as a standing goal.
I wrote down what lived in people’s heads. It started in 2024 with a team operating template and how-to guides. Once squads put designers on devices they didn’t know, the next layer was Smart Terminal 101 and Commerce Mobile 101, each opening with the merchant’s jobs, plus a one-page sheet for every device. Each guide ends with a gap list, so missing knowledge stays visible and owned.
AI in how we work
AI is part of the operating model, not a side project. It’s also what made journey squads workable, by lowering the cost of designing on a device you don’t know.
AI runs through the whole design process. Designers use it to analyze research, explore and iterate on prototypes, and evaluate product managers’ requirements docs.
We built shared foundations everyone uses. A designer on my team wrote our playbook for prototyping in code with AI, and another built a component library so anyone can prototype on the terminal using our real components. Prototypes now show up in leadership reviews, not just Figma frames.
I built agents that check requirements docs before they reach a designer. Incomplete requirements docs kept the team going back and forth for days, so the agents review each doc against a UX bar and draft a design brief. A designer stays accountable for every call.
I had AI agents build every payment flow, on every terminal and app, in code. That’s our three Smart Terminals and the iOS and Android apps, checked against the designs and production. I held the line on complexity as we built it: the default payment screen went from 117 controls to 61. I’m making it the reference designers use to learn how payments work on each device, alongside the surface guides. It matters beyond our own hardware: payment partners run our terminal payment experience on their own devices.
We manage AI like any other practice, including my mistakes. A prototyping tool I pushed drifted from our design system and broke our reviews, so I moved the team to a code-based tool built on our own components. And I once reported AI adoption higher than it was; I corrected it, and now I quote adoption from tool telemetry, not a show of hands.
The limit we hit is handoff. Engineering still needs inspectable components, so going from prototype back to Figma can double the work. So some designers are starting to work with engineers to push changes directly into our codebases, where the work doesn’t have to be redone.
The trade-off: tighten control, or keep the team autonomous
Eight months in, a retro showed what journey squads cost. Device expertise had piled up on one or two people, mobile depended on a single designer, and squads were pulled between competing priorities.
More control or more ownership. I could add process: more check-ins, approval steps, and me in more decisions. That was the safer short-term move. Or I could keep the team autonomous and set a few rules everyone holds to. I chose the second. The retro produced about 13 proposed practices. I picked a top five plus five non-negotiables, like saying no to thin requirements docs, not carrying messages between product managers, and showing the week’s change in demos, and put the rest to a team vote.
The retro
About 13 practices, proposed by the team. 3 went to a team vote
What the team holds to
Among the ten kept
- Say no to thin requirements docs
- Don’t carry messages between product managers
- Own your calendar
- Show the week’s change in demos
How I put it to the team: “I run a pretty loose ship on this team, and I want to keep it that way. That only works if we own our calendars, if we own the demos, and we own the pushbacks.”
What it cost: bigger risks, and bigger misses. When I delegate real ownership, people take on larger calls, and when one goes wrong I often find out after the damage is done, so the course-correction is bigger too. It’s worth it. Designers with real ownership are taking on bigger calls, and I coach direction instead of checking every step.
The weekly demos are how I keep that risk in check. Each squad shows the week’s change, so I see decisions while they’re still cheap to adjust, and I coach there instead of sitting in every meeting.
Who grew, and what spread
Four promotions in two cycles, from early-career designers to a new senior. Each designer has growth goals set just past their comfort zone, and what I coach toward is owning an outcome end to end and having influence beyond our own team. The squad lead roles gave people room to do both.
“Thank you for always taking the time to mentor me, advocate for me, and help me navigate challenges along the way.”
— A product designer on my team
Squad leads became owners. The three designers I inherited became the squad leads, each owning a merchant journey and guiding the designers on it. Early on, squad leads read “accountable” as “do every task.” I reset that: being accountable means owning the squad’s part of the journey and making the calls, not doing every task.
I give away the work I start. I prototype a lot myself. When I built a rough seed showing one interaction cascading across terminal, mobile and web, I handed it to one of my designers instead of presenting it. She built it into a full cross-surface prototyping setup, and I had her showcase it to the wider Commerce UX org so she’d be seen as the person leading that work. I do this on purpose: my speed starts things, and the team owns the win.
I step in to protect people, not to take over. When our in-person selling vision was due ahead of planning and the designer who’d normally build it was at capacity, I built it myself rather than pile it on them. Then I made sure the squad model gave vision work a clear owner, so me stepping in stays the exception.
The designers own the system now. The mobile designer maintains the Commerce Mobile guide and shared it with the wider Commerce UX org. A squad lead co-edits the terminal guide. The operating model isn’t mine to keep alive anymore; it belongs to the people who use it.
“You proactively seek feedback from us and immediately implement solutions.”
— Another product designer on my team
Outcomes
- One intake replaced two Jira systems and hidden asks.
- Every designer on the team now uses AI across the work, from research analysis and prototype iterations to evaluating requirements docs.
- Requirements reviews with our AI review agent take about a third less time, by my estimate.
- The surface guides are early. The real test is whether the next designer who moves to a new device ramps up faster than our first moves did.
What I’d do differently
I’d plan the transfer of expertise before mixing designers across devices. We moved people first and wrote the guides after the retro showed what it cost. The guides should have come first.
What I carry forward: before I hand over more ownership, I make sure I’ll see decisions early. Here, the weekly demos are that check.
Figures are rounded or shown as relative change to protect GoDaddy’s confidential data. I’m glad to walk through the details in conversation.
Next case study · HubSpot From a feature list to one model of the admin’s job I ran the committed roadmap and a long-term vision in parallel, both organized around one model of the admin’s job, so the group never started from zero. Read the case study