UX as Organizational Strategy

It was January 2025, and the Enterprise Architects and Product Managers were spinning. The Lighthouse platform — Arcos’s new emergency preparedness suite — was in early shaping, and every conversation about scope and process was circling back to the same unresolved questions. My team had done the foundational work: service blueprints, personas, early research synthesis. But none of it was “on paper” in a way that could anchor a room of people who think in systems and specifications.

I made a call that felt risky at the time. I asked UX to take the thin slice of requirements we had and create draft screens — not polished, not validated, explicitly aspirational — of what this platform might be. The goal wasn’t to propose a solution. The goal was to give every person in that room something specific to push back on.

The hypothesis was that pointing at something wrong is easier than defining something right. And it worked. Within weeks, the conversation shifted from open-ended scoping to focused triage. Engineers could say “that workflow would never work with our current stack.” PMs could say “that’s out of scope for this milestone.” The architects could see the seams in the system before they’d been written into a spec. The draft screens hadn’t answered the question — they’d changed what question we were asking.

The diagnosis

When I was hired at Arcos, the company had never had a formal UX function. The CPO’s intent was clear: establish a strong UX strategy and design voice, ask the uncomfortable questions about the experience, and unify the product across a set of genuinely complex variables — emergency versus normal operations, wildly different persona needs, and a product suite that had grown through acquisition as much as through deliberate design.

What I walked into was not hostility to UX — it was ambiguity about what UX was for. Different product and engineering pods had different answers. Some teams saw UX as a visual polish layer, applied after the real decisions had been made. Others were skeptical that a centralized UX function could understand the technical constraints they were living with. A few were curious but waiting to see if this was a real commitment or a title on an org chart. None of them had a shared language for collaboration.

The deeper problem was structural. Arcos had made product decisions — real ones, shipped ones — without grounding them in user reality. The prior attempt at a Timesheet capability was the clearest proof point: a feature the company had tried to build before UX existed, and one that hadn’t landed. That story was known internally. It was the kind of miss that lingers in institutional memory and, if handled carefully, could become an argument for doing things differently.

What had to be true for UX to actually change how Arcos built things: I had to earn credibility with each pod on their own terms, not demand it by title. I had to demonstrate that UX could hold the long-term vision while respecting the near-term constraints. And I had to make our artifacts genuinely useful to the people making decisions — not outputs that sat in Figma, but instruments that changed what happened in a room.

The vision

The frame I was working from wasn’t “UX needs a seat at the table.” That framing is passive — it positions UX as waiting to be invited. My actual argument, which I made explicitly to the CPO and implicitly to every product pod I engaged, was that UX is most valuable as a forcing function: a discipline that makes ambiguity concrete early enough that course corrections are cheap rather than catastrophic.

This reframe had practical implications. It meant UX shouldn’t wait for specs to arrive — it should be generating the artifacts that inform those specs. It meant personas and service blueprints weren’t documentation artifacts produced after discovery; they were navigation tools that made product conversations faster. And it meant that a rough screen shown at the right moment could do more strategic work than a polished one shown too late.

The vision for the product itself — what the CPO called “Harmony” — was to unify the user experience across emergency and normal operations, across the range of personas Arcos served, and across the contexts in which their software lived. That was a systems problem, not a UI problem. Holding both the long-term vision of what the experience could be and the near-term reality of what could actually ship with a given tech stack required a specific kind of discipline: knowing when to push, when to negotiate, and when “good enough” was a genuine win rather than a compromise.

The approach

With resistant pods, I didn’t lead with process. I led with listening. Every engineering team had a legitimate set of constraints — tech stack debt, timeline pressure, context that UX didn’t have by default. Before I asked anyone to change how they worked, I needed to understand what they were actually up against. That meant sitting in on engineering conversations I wasn’t required to attend, asking questions about what made certain problems hard, and demonstrating that UX wasn’t coming in to add friction to their pipeline.

The negotiation model that emerged from those early relationships became a pattern I applied across the org. For any given release, I’d define the ideal experience — the thing UX research and our understanding of user goals said was right — and then open the floor to what was actually buildable given the constraints at hand. We’d negotiate toward a release target that was meaningfully better than the current state, even if it wasn’t the full vision. The software is mutable. A strong, honest relationship with a tech team is worth more than a single perfect release, and everyone involved knew the long-term vision wasn’t going away.

Building a team capable of holding that model was inseparable from the approach. When I arrived, UX was one person — me — plus two consultants. Over the following two years, I hired three Senior Designers with the specific combination of skills the work required: researchers who could operate at a systems level, designers who could engage directly with engineering constraints, and practitioners who could hold a long-term experience vision while negotiating toward what could actually ship in a given cycle. The team didn’t grow because the org chart said it should. It grew because the scope of what UX needed to do — across Lighthouse, Timesheet, and the full range of Arcos personas and scenarios — required it.

By August 2025, that credibility was buying real access. When the Timesheet capability was being shaped — a feature Arcos had already tried and missed before UX existed — I pressed to be involved at the objective-setting stage, not after it. I used AI to aggregate the user and customer data we had, surface the top-value threads, and quickly built working Proof of Concepts in Lovable around that model. Not to propose a final design, but to put something specific in front of leadership and customers early enough that bad ideas could be eliminated before anyone had spent real engineering time on them. The pattern from January’s Lighthouse session — give people something to react against — had become a repeatable method.

Building credibility

The clearest indicator of earned trust isn’t being invited to a meeting — it’s being sought out before one. That shift happened at different times with different pods, but it happened. The teams that were skeptical early on weren’t won over by process decks or capability presentations. They were won over by UX showing up with something useful, consistently, in the context of problems they were already trying to solve. When a PM realized that the personas and flows we’d developed before shaping began made their kickoff conversations faster, that was more persuasive than anything I could have said in the abstract.

The Timesheet milestone was the sharpest credibility moment because it had a named failure attached to it. The prior attempt — built before UX existed at Arcos — had shipped and missed. That institutional memory was in the room when I made the case to be involved in objective-setting, not just design execution. Leadership agreed not because UX had earned that access by policy, but because the alternative had a known outcome. Early UX involvement wasn’t a preference anymore — it was the variable that had determined whether the previous attempt hit or missed. That argument landed because it was traceable. The Timesheet miss wasn’t ancient history; it was the reason we were having the conversation.

What shipped

The most important thing that exists now that didn’t before isn’t a screen or a component — it’s a position. UX is a necessary participant in product shaping at Arcos. That’s structural, not relational, and it’s the difference between influence that depends on the right people being in the room and influence that is baked into how the process works.

More concretely:

• Service blueprints and personas developed by UX are now active inputs to early-stage product and architecture conversations — not documentation produced after the fact.
• The draft-screens-first method, introduced in January 2025, has become a repeatable tool for focusing scope conversations before requirements are written.
• The Timesheet capability is being shaped with UX-aggregated user data and POC validation as a first step — a direct inversion of the process that produced the previous missed attempt.
• Both accepting and resistant product and engineering pods are now engaged in UX process, with the negotiation model allowing each team to participate in defining what ships without sacrificing the long-term experience vision.
• The UX team has grown from one person and two consultants to three Senior Designers and one consultant — a team that can hold the full scope of the Harmony vision across multiple simultaneous product workstreams.

The larger argument

What this story proves is that UX influence isn’t granted — it’s built, incrementally, through artifacts that are genuinely useful to the people making decisions. The draft screens in January 2025 worked not because of their visual quality but because they changed what kind of thinking was possible in the room. The Timesheet POCs worked not because of technological novelty but because they gave leadership and customers something concrete to invalidate before the cost of being wrong became engineering time. The persistent engagement with resistant pods worked not because of organizational authority but because UX kept showing up with something worth engaging with.

The model I’ve built at Arcos — design artifacts as strategic instruments, long-term vision held alongside near-term negotiation, UX as an upstream shaping function rather than a downstream delivery service — isn’t specific to Arcos. It’s what UX leadership looks like in an organization where the function is new and the credibility has to be earned. What comes next, as UX becomes structurally embedded in the product process, is the harder and more interesting problem: maintaining that position as the organization scales, holding the Harmony vision across a growing team and an expanding product surface, and continuing to ask the uncomfortable questions even after the answers have become more convenient to avoid.