Building a Scalable UX Practice
During my seven years at Bethesda.net, my role evolved from Senior Product Designer to UX Manager. Alongside delivering product work, I led the effort to formalize how UX initiatives were researched, planned, designed, documented, and handed off for development.
I believe an effective design process is not bureaucracy it is infrastructure. It gives teams enough structure to work consistently while remaining flexible enough to support projects of different sizes and levels of complexity.
The Challenge
As the product ecosystem and design workload grew, the team needed a shared operating model that could:
Bring UX into product planning early enough to influence direction
Establish clear expectations for each initiative
Improve coordination among Design, Product, Engineering, and Research
Make design work easier to plan, estimate, and track
Create consistent documentation without forcing every project through the same level of effort
Ensure designs were ready before development began
The UX Operating Model
I established a flexible, end-to-end process organized around five stages:
1. Early Exploration
When an initiative required additional definition, the team could begin with one of two time-boxed activities:
Initiative Research explored user needs, market opportunities, behavioral data, and product value. Depending on the project, this could include market research, analytics, surveys, interviews, or focus groups conducted with our research partners.
Vision Design used early visual concepts to communicate possibilities, test the product direction, and help stakeholders align before detailed requirements were finalized.
This allowed UX to contribute to product definition—not simply respond to completed requirements.
2. UX Design Planning
Once the product direction was defined, the assigned designer created a UX Design Plan outlining:
The design methods appropriate for the initiative
Expected deliverables and artifacts
The epics and major experience areas requiring design
Dependencies, approvals, and estimated effort
The planned approach to validation
The process distinguished between essential activities and optional methods based on project complexity. This created consistency without imposing a rigid, one-size-fits-all workflow.
3. Discovery and Ideation
Designers moved from focused discovery into workshops, sketches, information architecture, user flows, wireframes, prototypes, and interface design.
Product Owners and Engineering Leads reviewed key artifacts throughout the process, allowing feasibility concerns and product questions to be addressed before formal handoff.
4. Design Readiness and Handoff
Design work was expected to be completed before or alongside technical design and before an initiative entered development.
A formal handoff brought Design, Product, and Engineering together to review the intended experience, resolve open questions, and confirm that the work was ready to build.
5. Validation and Iteration
Validation was planned according to project risk, complexity, and available team capacity. It could take place before handoff using prototypes or during development using functional builds.
When validating every individual epic was not feasible, related epics were tested together at the initiative level. Issues discovered after development began entered an established change-request process, keeping iteration visible and manageable.
Connecting Design to Delivery
I aligned the design workflow with the company’s product governance and development lifecycle.
Design owned its work in Jira using a clear hierarchy:
Initiatives represented the broader product objective.
Design epics represented major features, flows, information-architecture areas, or holistic experience work.
Stories represented work that one designer could complete within a sprint.
Tasks captured operational or exploratory work that did not yet belong to an initiative.
The same hierarchy was reflected in our SharePoint documentation:
Initiative landing page → Epic landing page → Supporting design documentation
This created a consistent connection between product strategy, design decisions, delivery work, and long-term documentation.
Organizational Impact
The operating model gave the team a shared language for planning and delivering UX work. It made design effort more visible, clarified ownership, improved cross-functional alignment, and created reusable standards for future initiatives.
Most importantly, it moved UX further upstream—from producing screens after requirements were written to helping define problems, shape product direction, and assess readiness before development.