# From Delivery to Direction

Subject: Arcos, Inc — UX Leadership & AI Delivery
Role: Head of UX
Timeline: Oct 2024 – Jul 2026
Canonical URL: https://jason.sonderman.info/case-studies/ways-of-working-ai-delivery/

When the delivery pipeline started working, the recovered capacity had to go somewhere. This is the story of what the efficiency revealed: that the upstream problem — purpose, data shape, user intent — is harder and more valuable than the downstream one. And what it means when your team’s documented ways of working become the training set for an AI agent someone else built.

## Key outcomes
- Rebrand + light mode: 1 wk (Down from a full 2-week sprint)
- Sprint recovery: ½–1 sprint (Per milestone cycle within a 6-week cadence)
- Story point shift: 5–8 → 1–3 (Fibonacci UI estimates after design system hardening)

## Summary
Jason built an AI-assisted delivery pipeline at Arcos connecting a custom design-system npm package, Figma MCP, Zeplin, and Claude Code — which recovered team capacity and revealed that the higher-leverage problem was upstream clarity of purpose, not handoff translation.

## Facts
- Sprint recovery: Half to a full sprint recovered per six-week milestone cycle
- Story point shift: UI estimates moved from 5–8 to 1–3 on the Fibonacci scale as token maturity increased
- Rebrand + light mode: Completed in 1 week, down from a full 2-week sprint
- Team grown: From 1 designer + 2 consultants to 3 Senior Designers + 1 consultant

## Scope
This case study covers the delivery-pipeline mechanics and what building it revealed about where design creates value — pair with UX as Organizational Strategy for how that upstream role was earned, and Control Tower for where the 3-day kickoff was exercised on a real product.

**Tags:** UX Leadership, UX Team Scaling, Design Systems, AI-Accelerated Delivery, Token Architecture, Cross-functional Leadership, Enterprise SaaS

<section id="context" aria-labelledby="context-heading">
<h2 id="context-heading">The terrain</h2>

Control Tower and Arcos Field run on two stacks, serve two kinds of users, and opens every six-week cycle the same way — four days of planning sessions where product, design, and a development pod walk every defined outcome together before a line of code is written. Three senior designers cover that work across three pods. I carry the connective tissue role: coherence between the two surfaces, continuity into the legacy tools underneath, and the thread that keeps what gets built on one side from quietly drifting away from the other. The team is small by design. Constraints tend to produce clarity, and clarity, as it turns out, became the whole story.

For most of the time I’ve been here, those planning sessions were where the friction lived. This is the story of what changed when the friction went away — and what it revealed when it did. For the technical story of how the delivery infrastructure was built, see <a href="/case-studies/arcos-handoff-is-the-bug/">The Handoff Is the Bug</a>. This study picks up where that one ends.

{/* IMAGE: Hero/thumbnail — a single Control Tower component shown in two states: Figma/Zeplin with token annotations visible on the left, the same component rendered accurately in the dev environment on the right. No arrow between them. Tight crop, consistent color grade across both sources. */}

</section>

---

<section id="evidence" aria-labelledby="evidence-heading">
<h2 id="evidence-heading">What the efficiency revealed</h2>

The pipeline worked. Half a sprint to a full sprint recovered per six-week cycle. UI stories that pointed at 5s and 8s came back as 1s and 2s. A rebrand and light mode implementation that would have taken two weeks took one. The work was understood before it began.

{/* STAT BAR: Four metrics — render using the site's existing StatBar or outcomes component from frontmatter.outcomes */}

{/* IMAGE: A generated before/after timeline — two horizontal rows labeled Before and After, each showing a 6-week milestone cycle divided into sprints. In the Before row, the first two weeks are marked as Scaffolding + investigation. In the After row, that space is open or redirected. Two colors only, no gradients. */}

Working inside it closely enough revealed something the original hypothesis hadn’t accounted for. The ambiguity that remained wasn’t in the handoff. It was earlier — in whether the purpose behind a layout decision had ever been made explicit, in whether the shape of the data matched what a user actually needed to see, in the distance between what the interface asked someone to do and what they were actually trying to accomplish. Those questions don’t come from the design file. They come from being close enough to real users — in research, in testing, in the accumulated evidence of watching people work — that the intent behind a decision is grounded in something observed rather than assumed. The smarter the agent got, the more plainly it showed us how much that grounding mattered. Speed was compressing the cost of skipping it, not eliminating it.

> We came looking for a better bridge. We found that the other side needed work first.

Then the mobile pod showed us what documentation is actually for.

The mobile surface had always been the harder one to plan for — there is no clean way to prototype in React Native, and the pod had never been part of the original delivery model rollout. During a planning session, we learned they had connected the Zeplin MCP to pull design context and user flows directly into a Claude Code workflow, using it to visualize shaping outcomes mid-discussion before the formal handoff. They had also built a UX Designer agent — trained on the ways-of-working documentation our team had published. Not a tool handed to them. Not a process they’d been asked to follow. Our own documented values and process norms, used as a behavioral frame for a model working alongside their developers. They built it themselves because the documentation was precise enough to make it possible.

I hadn’t written that documentation for this. I’d asked for it because unclear process wastes senior people’s judgment on questions that shouldn’t still be open — the same instinct behind Clarity of Purpose, just aimed inward at how the team’s own knowledge gets recorded. It turned out to double as something else entirely: the discipline that makes documentation useful to a new hire and the discipline that makes it useful to a model training on it are the same discipline — say the actual reason a thing is done, not just the rule. If the ways-of-working docs had been checklists instead of reasoning, the mobile pod would have had nothing to build on. Good documentation was never just about onboarding humans. It’s what makes your judgment portable to people, and processes, you never planned for.

</section>

---

<section id="principle" aria-labelledby="principle-heading">
<h2 id="principle-heading">Clarity of Purpose</h2>

Oracle’s Redwood Design System named two things that have stayed with me. Clarity of Purpose — every design decision grounded in a specific outcome before execution begins. And the shape of the data — not what the system holds, but what form a user needs it to take to act with confidence. Both principles are older than any library. Both became more urgent when the time between a decision and its built expression collapsed to days.

AI is a domain I’ve worked in long enough and closely enough that other leaders inside the organization began bringing me into the room when strategic decisions about it were being made — not as a title, but as a point of view that had been tested against real work. Those conversations kept returning to the same reframe: the efficiency story is the smaller story. What AI-assisted delivery actually creates, if the recovered time goes somewhere intentional, is the conditions for design to do the work it was always supposed to be doing. Not generating UI. Holding purpose accountable. Defining the right shape for the right data. Staying close enough to what users actually need that the thing being built is worth building.

> AI doesn’t make UX faster. It makes UX more valuable — if the recovered capacity goes back into the questions that determine whether velocity creates anything worth having.

</section>

---

<section id="signal" aria-labelledby="signal-heading">
<h2 id="signal-heading">Early, and honest about it</h2>

One sprint in. The volume of UX updates to screens has dropped. More tellingly, the nature of the work has shifted — designers are no longer the primary producers of UI in Figma, then advocates for its faithful translation into code. They are reviewers: informed, principled, checking that what has been built holds to the UX decisions that were made upstream, that accessibility hasn’t been traded away in the handoff, that the experience arriving at user acceptance testing is one the design team can stand behind. The production work moved to the agents. The judgment work stayed with the people.

Whether that holds, and what it looks like at scale across all three pods, is still being learned. What is visible so far is a design function that moved upstream without shrinking — AI handling the translation layer, developers owning architecture and integration, UX with its attention on the questions that don’t resolve themselves.

What the user is actually trying to accomplish. Whether the thing being built gets them there. Whether the purpose behind the decision was ever made clear enough to survive the distance between intent and code.

That last question turns out to be the one that matters most. It was there before the AI. It will be there after whatever comes next. The tools changed what it costs to ignore it.

{/* IMAGE: A Control Tower screen in the dev or alpha environment alongside a Zeplin annotation or comment referencing a UX principle or accessibility consideration — showing UX engaging with built work rather than producing Figma files. Anonymize any sensitive data visible in the UI. */}

</section>