UX as Organizational Strategy

What I walked into

When I joined Arcos, the company had never had a formal UX function. The CPO wanted a strong UX voice that would ask uncomfortable questions and unify a product suite across emergency and normal operations, very different personas, and tools that had grown through acquisition.

What I found wasn’t hostility. It was ambiguity about what UX was for. Some pods saw it as a visual polish layer, applied after the real decisions had been made. Others doubted a central UX team could understand the technical constraints they lived with. UX was one designer, me, plus one consultant, Erin Gold from Slalom. By my own count it touched about three initiatives a quarter: one each in Arcos Control Tower; Clearion, a vegetation management tool Arcos acquired in October 2024; and Mobile Workbench.

Arcos had made real, shipped product decisions without grounding them in user reality. The clearest proof was an earlier attempt at a Timesheet capability, built before UX existed, that shipped and missed. Handled carefully, that memory could become an argument for working differently.

Something to push back on

In January 2025 the Enterprise Architects and Product Managers shaping Arcos Control Tower and Arcos Field were going in circles. We had service blueprints, personas, and early research synthesis, but nothing concrete enough to anchor a room of people who think in systems and specifications. I took the thin slice of requirements we had and drew draft screens to present my user-lenses vision to the design team and product leadership: not polished, not validated, explicitly aspirational. They were the start of the user lenses in the Control Tower study.

The bet was that pointing at something wrong is easier than defining something right. Within weeks the conversation moved from open-ended scoping to focused triage. Engineers could say a workflow wouldn’t work with their stack; architects could see seams before they reached a spec. The screens didn’t answer the question. They changed which question the room was asking.

With resistant pods, process came second. Listening came first: sitting in on engineering conversations I didn’t have to attend and asking what made their problems hard. UX defined the ideal experience; then the pod and I negotiated toward a release that was meaningfully better than the current state, even when it wasn’t the full vision. A strong, honest relationship with a tech team is worth more than one perfect release.

A team that owned its domains

UX started as one designer plus one consultant and grew to three Senior Designers and one consultant, because the work across Control Tower, Arcos Field, and Timesheet needed it. I hired for a specific mix: research at a systems level, direct engagement with engineering constraints, and the ability to hold a long-term vision while negotiating a release. Ownership went by skillset rather than spreading everyone across everything. Ales Karoza owned field and mobile experiences, including login. Oswaldo Vazquez owned workforce management, command-center flows, and the heaviest data visualizations. Alina Shaulinskaya owned the Clearion tool, mapped to work order management and workflow. Erin Gold, our consultant, carried user-flow strategy and back-office data.

Coded prototypes followed the same lines. Oswaldo built the Roster feature’s prototypes once he had requirements from Erin and product management and a couple of rounds of Figma ideation. Ales built most of his in Figma Make, but Roster’s mobile surface ran on React Native, which didn’t suit in-tool coded prototyping, so that work happened in Figma Design against the Harmony Mobile theme and went to Zeplin. In March 2026, two weeks of training and environment setup moved all three senior designers into VS Code with Claude Code CLI.

Earning the Timecards milestone

By August 2025 that credibility was buying access. The Timesheet capability, later shipped as Timecards, was the feature Arcos had already tried and missed, and I pressed to be involved at objective-setting rather than after it. Leadership agreed, not because policy required it, but because the alternative had a known outcome. I used AI to aggregate the user and customer data we had, surface the threads with the most value, and quickly build working proofs of concept in Lovable, so bad ideas died before they cost engineering time.

A coded Mobile Timecards prototype existed midway through the Milestones phase. It went to the convention floor at the Linemen’s Rodeo, where roughly 400 field users gave live feedback before the Outcomes phase had started, and Arcos’s 20-member Storm Response Advisory Committee reviewed it too. Outcomes-phase shaping, which had routinely run the full six weeks, had initial outcomes ready for validation by week 3. That happened once, on Mobile Timecards; it is not a measured average.

Testing changed the build, too. Before the delivery pipeline existed, the only initiative tested end to end was convoy tracking, with Storm Response Advisory Committee leaders and internal Customer Success users, and testing stopped once its scope was cut to creating and tracking a convoy. Login (mobile and back office) was never tested with users. Neither was the first AI expense agent, a hackathon proof of concept with no design involvement; the version I designed later was tested internally and with the advisory committee. Once the pipeline was running, coded prototypes were tested with users for Roster Requests, Roster Response, Timecards Mobile, Timecards Backoffice, and Demobilization. On Timecards Mobile, storm-response users said the kind of hours they logged (travel, idle, working, resting) mattered less than role level and pay type (regular, overtime, doubletime), so logging moved to match. Timecards Mobile and Timecards Management shipped in June 2026, in beta, and reached production in September 2026, after I left.

What the efficiency revealed

The delivery pipeline itself, a design-system npm package I built plus Figma, Zeplin, and Storybook MCPs and Claude Code, is told in The Handoff Is the Bug.

Across three piloted Arcos Control Tower cycles, by my own observation and Product management’s reports to executives, a three-day Shape Up Delivery Kickoff replaced a two-week investigation sprint. Half a sprint to a full sprint came back on each six-week milestone cycle. UI stories that had pointed at 5–8 came back as 1–3 on the Fibonacci scale as the token layer matured. A rebrand with light mode, which would have taken a two-week sprint, took one week.

The recovered time went to different places on each side. Assuming a 65-hour per-person sprint, front-end delivery started reaching cycle goals in about 30 hours, helped by a shift to one engineer owning one outcome instead of a whole pod sharing it. The other 35 hours went to platform support, backend stories, overflow from earlier cycles, and tech debt. Design capacity moved upstream. Once a designer could take a concept to delivery-ready in roughly two and a half days, the freed time went into shaping the next iteration’s outcomes, carrying what the last one taught straight into it.

The efficiency showed something the original hypothesis hadn’t accounted for. The remaining ambiguity wasn’t in the handoff. It sat earlier: in whether the purpose behind a layout decision had ever been made explicit, and whether the shape of the data matched what a user needed to see. Oracle’s Redwood Design System names both: Clarity of Purpose and the shape of the data. The smarter the agents got, the more plainly they showed how much that grounding mattered.

Then the mobile pod showed what documentation is for. They had connected the Zeplin MCP to a Claude Code workflow, and they had built a UX Designer agent of their own, trained on the ways-of-working documentation my team had published. Nobody asked them to. The documentation made it possible because it gave the reason a thing is done, not only the rule.

Rollover shows the operating-model side. Before Shape Up, unfinished work could consume an entire six-week cycle, with no room for anything new. Shape Up capped rollover near 20%, and the cap had a real mechanism: if projected rollover looked likely to pass it, Product and Engineering had to meet and agree on a new scope before work continued. In late April 2026, leadership agreed to retire the formal Milestone and Shaping phases for a shorter planning cadence, betting on what one engineer could own across four weeks rather than what a pod could commit to across six. May and June went to cleaning up before the first cycle began.

Early, and honest about it

I left in the second week of the first four-week, engineer-owned cycle, after one kickoff, so this account stops there. By then, designers were no longer the primary producers of UI in Figma. They had become reviewers, checking that what got built held to the upstream UX decisions, that accessibility hadn’t been traded away, and that what reached user acceptance testing was something the design team could stand behind.

The engineering side wasn’t settled either. AI-minded engineers were invested advocates, and the Zeplin MCP had real traction with them. Engineers skeptical of AI tended to feel UX couldn’t produce trustworthy code without formal engineering training, a reasonable position I didn’t try to argue past. Showing output before pitching the model was the only thing that moved it, and by the time I left, the conversation with Tech leadership had shifted from whether UX should produce code to what the review and merge process should look like.

By my own count, UX went from about three initiatives a quarter to active work in four pods: two in Control Tower, one in Clearion, one in Mobile Workbench. It is a before and after, not a share of all pods. The pace figures rest on my observation and Product’s reports to executives; the pod counts and capacity figures are my own estimates. None of it is instrumented analytics.

Some of it outlasted me. After my time at Arcos ended, the remaining team reported that across two six-week iterations, kickoff took Monday plus part of Tuesday, with Design and Product presenting scope and specs. That is their account, not something I measured. All three designers I hired, plus one of the original consultants, were still at Arcos at my last conversation with them in August 2026, and they named AI-assisted design delivery, a refined research framework, and design-system expansion as what came next.

The thing that existed at the end that didn’t before isn’t a screen. It’s a position: UX shaped product scope before engineering began, not just how things looked once specs arrived.