Establishing a UX practice:
From Assumptions to Evidence

Decisions at the company were validated at the most expensive possible moment — by paying customers, after shipping. I lived it early: we launched a product whose core design philosophy was wrong. The PM had designed the workflow without user testing, end users rejected it on contact, and the fix wasn't a tweak — it was rethinking the entire workflow. The investment was sunk and the customers were unhappy by the time anyone learned the original idea had been off.

That failure was structural, not accidental. There was no UX discipline, no shared design language, no central thought to challenge any of it — every product was built in isolation from the rest. The decade I spent building the practice was a sustained answer to that single problem, and every intervention that follows was a response to a specific gap in the feedback loop. The order was strategic, not chronological.

Developers were inventing UI mid-implementation, with no designed target to build against. My title at the time was front-end developer and there was no UX function at the company, so I started producing wireframes and flow diagrams for my own work first — before anyone asked. I needed proof of value before I could argue for anything bigger, and cheap deliverables on my own projects were the lowest-risk way to make the case.

Design prioritization was guesswork because nobody had data on how customers actually used the platform. Instrumenting the apps I was already working on didn't need organizational permission, so I started there — value compounding app by app while the bigger asks (research access, methodology adoption) were still building.

To keep instrumentation portable, I authored a shared analytics-plan template. Every product owner filled out the same workbook before tracking went in. Events were grouped by user intent rather than by layout, and each plan recorded which input method triggered the action (toolbar, context menu, keyboard, drag, footer) — so dashboards could compare adoption across applications without anyone reconciling naming after the fact.

The practice was outrunning my capacity to deliver it. I hired, onboarded, and grew the designers who carried it forward — defining the roles, writing growth plans, running performance conversations, and making the case for headcount each time leadership wasn't sure UX needed to scale with engineering. Every new designer went through a structured 30/60/90 onboarding that ended in a 30-day embed with a product team; after that, they could carry the practice into a project on their own.

Analytics told us what; research was the only way to learn why. The company had never tested with end users, and getting access to them was a multi-year organizational-change problem — so I built the program in phases, each one delivering value on its own.

The reach gap was simple: the UX team was never large enough to staff every project at the depth the work deserved. The strategic call was to extend design consistency and sensibility through channels — documentation, rituals, shared standards, internal writing — instead of through bodies. Each channel reached a different audience and did a different job.

By this point the research program was producing better evidence, the team was bigger, design quality was visibly improving — and management was telling me UX was the bottleneck. My read was the opposite. Product planning wasn't looking far enough out to account for a proper design process, and UX was the only function being asked to compress around an already-set delivery date.

The direct fix sat at the PM's part of the cycle, but that wasn't a fight I could win head-on without giving PMs a tool they actually wanted to pick up. So I went looking for methodology that could meet engineering where it was. Jake Knapp's Sprint and Lean UX both offered compressed, hypothesis-driven cycles that fit inside engineering's planning horizons — I adopted both, adapted them for enterprise SaaS, and wrote a facilitation playbook teams could pick up and run.

Methodology inside the design phase only goes so far without a surrounding process to support it. When the VP of Development asked me to help redesign the broader software development lifecycle, the SDLC was the lever big enough to move the planning behavior I couldn't change project-by-project. I interviewed staff across every functional role the SDLC touched, pulled the existing JIRA workflows onto a single canvas, and iterated the document and diagram with the VP across multiple versions.

The earliest draft on hand is v1.5 (October 2019): Lean UX sits on the canvas but isn't yet wired into the surrounding phases. By v4.3 — the version that landed — Lean UX had moved inside Requirements & Design as the engine of how design happens, with explicit research inputs, formalized per-iteration deliverables, and MVP/MMF branching in Deployment. The bottleneck I'd diagnosed earlier was visible as a sequence of phases with explicit time inside each.

Running in parallel to the practice work, the company's Java suite was being rewritten in React. Alongside that rewrite, I authored a set of shared standards (a responsive column grid, size classes, canonical layouts, full breakpoint specs) that every product team designed against. Those standards are part of the design system story, not the practice story, so the detail lives in the companion case study: UX Governance at Scale. I built the practice and the standards together. The methodology, research, and design enablement described in this study are part of what made building those standards possible.

Designing a rigorous process is easier than getting an organization to absorb its overhead. Where the organization wasn't ready, the better play was to meet teams where they were, prove value on one project, and let adoption spread on the strength of evidence.