Enterprise Practice Lead (Service Design) (Remote From Anywhere In Colorado)

Enterprise Practice Lead, Service Design

The Governor's Office of Information Technology is in the middle of a transformation worth joining. We're building cross-functional pod teams that partner directly with agencies to design, deliver, and continuously improve services that work for Coloradans. Good government depends on technology that works, and OIT exists to make that true for every Coloradan. The State of Colorado is seeking an Enterprise Practice Lead, Service Design, to help build the next generation of public services. We're looking for people who want to do the best work of their careers in the service of the public.

Enterprise Practice Lead, Service Design, owns how human-centered design and user research are practiced across OIT, enabling Service Designers embedded in pods to conduct research with real constituents, map current and future state services, and produce the artifacts that ground the PM's backlog. The Enterprise Practice Lead owns the standards, methods, and professional community that make every service designer more capable. Guilds at OIT enable consistency, quality, and community across a federated team structure. IT Directors (ITDs) are responsible for the people management of their pod of practitioners; Enterprise Practice Leads guide and support the practitioners to deliver good work. GDS Digital and Data Capability Framework describes the head of service design as an expert practitioner who "can define and assure best practice while influencing, leading and mentoring others." That is precisely what this role is at OIT, operating across a distributed pod structure rather than a centralized design team. The central challenge is sustaining research rigor in conditions that constantly push toward skipping discovery: constrained timelines, agencies that think they already know the answer, and practitioners who are often the most variable-capacity member of their pod.

What you'll do:

• Define research method standards: which methods are appropriate in which contexts, what rigorous synthesis looks like, and what constitutes a research artifact, such as a journey map, service blueprint, or problem statement, that the PM and Delivery Engineer can actually use.
• Establish journey mapping and service blueprinting standards: what level of fidelity is appropriate for a discovery phase versus a live service, and how to calibrate depth to the decision being made rather than producing documentation for its own sake.
• Build and maintain design system literacy standards: what every service designer needs to understand about OIT's design system and accessibility requirements, drawing on GDS's skills of "designing for everyone" and "designing strategically" as reference competencies.
• Identify and address systemic gaps in research and design quality across the portfolio: discovery being skipped, accessibility treated as an afterthought, and synthesis that never reaches the people who need to act on it.
• Run a service design guild: critique sessions, shared research repositories, peer learning, and a culture where practitioners feel professionally connected despite being distributed across agencies.
• Develop a career pathway for service designers that distinguishes research-depth from design-depth profiles, recognizes the GDS-aligned skills of "evidence-based design," "iterative design," and "leading design," and creates growth that doesn't require moving into management.
• Build and deliver training that builds statewide capability in the hardest parts of the job: holding space for research when stakeholders think they already know the answer, facilitating workshops with resistant participants, and translating findings into language that motivates action from program leadership.
• Create and maintain shared resources that practitioners across pods can adapt without starting from scratch, such as research guides, synthesis templates, and example artifacts at different fidelity levels.
• Advise ITDs and product directors on what good service design work looks like and how to give feedback to a practitioner in a discipline many technology leaders have limited direct experience with.
• Distinguish between a practitioner skill gap, a pod structural problem (not enough access to users or research time), and an agency partnership problem, and advise accordingly.
• Surface patterns of weak research practice across pods that point to a training or standards gap rather than individual performance.

What you bring:

• Knowledge of service design methods at a deep practitioner level: journey mapping, service blueprinting, current/future state process mapping, co-design facilitation, and how to choose the right method for the problem and phase at hand.
• Knowledge of user research methods including qualitative interviews, contextual inquiry, usability testing, and survey design, and how to select, scope, and conduct research that produces decision-enabling insights rather than data the team doesn't know what to do with.
• Knowledge of problem framing: how to define a problem space from user evidence before any solution is proposed, and how to help teams hold that space when stakeholders are pushing for answers.
• Knowledge of accessibility and equity in service design: WCAG 2.1/2.2 and Section 508 standards, and how to design government services that work for users with disabilities, limited English proficiency, limited digital access, and other access needs that disproportionately affect the populations Colorado agencies serve.
• Knowledge of EA accessibility and UX standards applicable to OIT-delivered services, and how to translate those standards into practical design guidance.
• Knowledge of the relationship between service design and adjacent disciplines: how research artifacts become PM backlog inputs, how service blueprints inform engineering and delivery management, and how to build feedback loops that keep design grounded in delivery reality.
• Knowledge of the landscape of government design practice: GDS's design principles and capability framework, 18F's research and content design approaches, and USDR's user experience and language access work as reference points for what rigorous human-centered practice in government looks like.
• Ability to protect discovery from delivery pressure. Service designers in pods face constant pressure to skip research and jump to solutions. The Enterprise Lead builds a professional community resilient enough to hold the line and gives practitioners the language and backing to do so.
• Ability to make research standards practical. Guidance that's too abstract doesn't get used. Translate rigor into usable tools that work in constrained government delivery environments with real constituents who are hard to recruit.
• Ability to build literacy for the discipline across non-designers. ITDs, product directors, and program leadership need enough understanding of service design to make space for it and to recognize what good looks like. Part of the Enterprise Lead's job is building that understanding.
• Ability to hold accessibility as a baseline, not an enhancement. Equity, plain language, and inclusive design are embedded in guild standards and are not optional for services that reach all Coloradans.
• Ability to create a community in a distributed structure. Service designers often work in isolation within their pods. The Enterprise Lead builds the connective tissue that makes them feel part of a discipline rather than just a team.