Personal Philosophy of UX Management and Leadership
I strive to be a UX leader that nurtures an organization's design culture to reach full maturity in order to bring a fully-realized, self-sustaining CX foundation to both the user and the business. I want my Design Team to be "UX citizens".
Problems in UX Management
UX Roadmapping
A UX roadmap is a strategic, living artifact that aligns, prioritizes, and communicates a UX team’s future work and problems to solve. Roadmaps should make realistic promises, value functionality over pretty visuals, and be strategic documents instead of feature-specific release plans.
Roadmaps can take several tangible forms:
organized lists
spreadsheets
slide decks
high-fidelity visualizations
sticky-note walls
The context dimension frames the meaning and use of your roadmap so it can be fully understood by anyone who reads it.
-Scope gives the artifact an owner and purpose and has several components:
Title: The product or portfolio team the roadmap++ will be used by (likely a mix of researchers, designers, and potentially developers)
Roadmap owner: The team (or person) who created the roadmap (i.e., who should a question about the roadmap be directed to?)
Date: When the roadmap was created or last updated
High-level goals (or vision): A broad company (or organization) strategy that the roadmap works towards
++ Roadmaps can be narrow or broad. A narrow roadmap focuses on a singular initiative, while a broad roadmap covers a portfolio-wide UX redesign or the conception of a completely new service. The more granular the scope, the more concrete the time horizons in the roadmap (the Next column may be completed within the next 6 months and is less likely to change). Conversely, the broader the roadmap, the longer the time horizons (the Future column will be completed in a year or more and is highly likely to change).
-Time provides the roadmap with a timeframe and includes 3 horizons:
Now: UX work (research or design) that is in progress and will be completed in the immediate future; this work is well-defined and more specific in nature
Next: near-future work
Future: UX work that is 6 or more months away (Themes in this horizon are most likely to change and ambiguous in nature.)
The theme dimension represents future UX work. Are areas of focus, initiatives, or problems to be solved and plugged into a corresponding time horizon depending on when the work is going to be completed?
Beneficiary and need
Beneficiary: The prioritized recipient(s) of the UX work (e.g., end users, fellow employees, or even internal stakeholders)
Need: The problem that will be solved (the purpose of the UX work)
Business objective(s): Objectives and potential outcomes (from a business point of view) that will be achieved upon completion (e.g., new market insight, user growth, increased engagement, ease of discovery, revenue, etc.) — think of these as success metrics for the work
Ownership
Who: The person or team who will complete the work
What: At a high-level, the kind of work that will need to be done (by the who); this should not be discrete task list, but rather a bulleted list of work breeds (e.g., discovery research, workflows, visual design)
Completed and Future++ are two additional time horizons (think pre and post roadmap scope). Completed shows UX work that was just previously delivered, while Future++ is UX work that can potentially be placed in the Future column.
Product areas is the area of the product the UX work will touch. Product areas are included when the product, experience, or service is complex and has many different components (e.g.,touchpoints). The naming system for product areas should align to the language of the audience using the roadmap. For example, for a product like Facebook Marketplace, product areas could include Groups, Stores, Buying, or Selling. In the above NN/g UX roadmap, product areas include Virtual Conferences, Online Seminars, UX Certification, and Reports.
Subthemes are specifics added to a larger theme: multiple subgoals that the theme encompasses, a specific user segment or persona, predetermined solutions from past work, or discrete features already tested and validated. Subthemes are most often included within themes in the Now column, where themes tend to be discrete and tangible because they are already in progress.
Confidence estimates are informal assessments of likely impact and demonstrated need for the different themes. Low-confidence estimates are typically attached to items based on assumptions or open questions, while high-confidence estimates are assigned to work validated by research or other data. Thus, if the item is supported with previous research and insights, consider giving it a high score on a confidence grading scale (e.g., 6/7). If the item is highly exploratory and lacking previous research, consider assigning it a low-to-moderate score of 4/7. Confidence estimates allow stakeholders to understand what items in the roadmap build on previous work and what items are a bigger bet (but have potential to differentiate your user’s experience from others).
Disclaimers state requirements or risks associated with a theme or component of the roadmap. They can be included within a theme or applied to the roadmap as a whole. The number of disclaimers is often directly proportional to the number of people who will be see the roadmap — the more public the roadmap, the more disclaimers.
Differences in UX Roadmapping vs. Release Plans, Product Backlogs, PM Plans and Customer Journey Maps can be seen here.
Establish goals: Determine the purpose of your roadmap and who should be involved.
Gather inputs: Collect problems that need to be solved from stakeholders and existing research.
Create themes: Cluster problems into themes.
Prioritize themes: Establish criteria and create a scoring framework to rank themes.
Visualize and share: Plot themes into a timeline and distribute the resulting visualization (your roadmap).
Revisit and update: Routinely return to your roadmap and make adjustments as necessary.
Before Workshop
A) Identify a primary purpose for road mapping.
Identify a single, primary purpose for your road mapping initiative. A clear goal will keep it focused and will establish clear priorities as you move through the process. Common roadmap purposes include:
Increasing team awareness
Enabling crossdisciplinary visibility and alignment
Educating others on the UX process
Managing bandwidth and resource allocation
Choose a scope and establish a core team.
Roadmaps that include UX work can have 3 scopes: product, field, and specialty. Identify which scope is best for your objective. Based on your primary purpose and chosen scope, establish a crossdisciplinary core team made of people who have insight, expertise, or responsibility over the future work’s completion and secure their time to participate in the key workshop.
Gather inputs from existing research. Collect existing information that could help identify and prioritize potential problems to solve within your chosen scope:
Previous roadmaps (including higher-level product roadmaps (or any higher-level roadmaps)
Qualitative or quantitative user research
Customer- or employee-support logs
Market-research surveys or brand audits
Plan the workshop logistics. Make key logistical decisions and communications prior the workshop:
Determine your tools and materials. We recommend using sticky-notes (either physical or digital) which lend themselves well to the clustering required in the workshop.
Assign roles. Heading into the workshop, assign responsibilities to participants: notetaker, timekeeper, and scribe. Delegating work enables you to participate, builds buy-in and accountability, and motivates people.
Finalize the agenda. Identify what sequence of activities you will be doing and the time needed to complete each. Don’t forget to factor in time for icebreakers, transitions between activities, and wrap-up.
Set expectations. Make sure all participants know what to expect (for example, what you will ask of them). Distribute the high-level agenda and clearly communicate the workshop goal and its expected outcome (for example, a low-fidelity roadmap, not a high-fidelity roadmap).
UX Maturity Mapping
A team mission statement is a concise articulation of the core purpose of a team and the value that the team provides to the rest of the organization. A mission statement answers the question: What collective value do we generate now? What do we do as a group that helps realize that aspirational vision?
Step 1: Introduce Mission Statements and Their Value
Don’t assume everyone is familiar with mission statements, even if the team is on board with creating one. (As previously discussed, this concept is often misunderstood.) Before jumping into the activity, align everybody on the definition and value of team mission statements.
You can start by sharing example mission statements from other teams to help everyone envision the desired outcome of the activity as clearly as possible.
If there are current challenges that led the team to this process, allow team members to express them and capture them in one place. One widely utilized, simple activity that can generate discussion is Start, Stop, Continue. In this activity, team members individually brainstorm things the team should stop doing on red sticky notes, things the team should start doing on green sticky notes, and things to continue doing on yellow sticky notes. You can follow this individual brainstorming step with a group postup, an affinity-diagramming exercise to cluster items into themes, and even a dot-voting exercise to understand which items are most important to the team.
Step 2: Share Stories of Value
Grounded by a shared understanding of mission statements and having built alignment around activities on which the team wants to focus, the next step is to create and share stories of value. A story of value is a clear yet concise narrative that describes specific incidents when the team felt its value was realized.
To generate stories of value, provide the following brainstorming prompt to the group: What does it look like when we deliver our full value? Small groups then break out to discuss and brainstorm responses. The responses can be real stories from the past or hypothetical stories if the group is nascent enough to not have a rich history yet. (The slight reframing of the prompt in this case would be: What would it look like when we deliver our full value?)
The more specific the responses, the better. It can help to provide some examples of responses. For example:
A potential story of value for a UX team: Last month, we held a research-engagement workshop with engineering and saw recommendations that met real user needs to be included in the next sprint.
A potential story of value for a DesignOps team: We conducted a survey to understand where our designers face roadblocks and were able to use the results to obtain a company-wide license for UserZoom to better support them.
Step 3: Identify Critical Elements in the Stories of Value
After larger-group sharing, the group goes back to their smaller teams to identify critical elements within the stories of value they’ve captured. Instruct the teams to reread their individual stories and look for 3 components within the narratives:
People or groups the team supported (These could be users, clients, or internal teams.)
Actions they took and activities they did to provide that support
Changes and results that happened because of their actions
Step 4: Cluster the Identified Critical Elements
Finally, these identified elements can be abstracted. They are essentially the potential building blocks for creating a team mission statement. Teams pull out the identified words and phrases and house them on 3 separate boards (one per group/round). A nice approach is to break the team into 3 groups; each group has ownership over their respective category, creates the compiled board, and identifies and shares themes back with the larger group.
Step 5: Create Draft Mission Statements
After a larger-group discussion of the themes within the 3 categories of critical elements, individuals generate potential mission statements. Set a time limit and allow individuals to create as many draft mission statements as they can or desire to within that timeframe. The team then shares individual mission statements and discusses their strengths and patterns among them.
When writing a final mission statement, keep these guidelines in mind:
Be concise: Between 10-15 words is ideal.
Keep it simple: Avoid overly verbose language.
Be specific: It should not apply to any other team or organization.
Say it out loud: Does it sound awkward? (Revise it.) Memorable? (Good.) Like a human would say it in a normal conversation? (Great.)
Samples:
https://airbnb.design/designops-airbnb/
https://medium.com/salesforce-ux/scaling-the-designops-summit-10e805bbdf2b
https://www.invisionapp.com/inside-design/scaling-design-teams-att-hd/
https://amazon.design/stories
Stakeholder analysis involves assessing each stakeholder’s potential to impact your project — negatively and positively! Some of your stakeholders will have more impact than others, and different stakeholder-management strategies need to be applied to those influential stakeholders, compared to those that wield little influence.
Manage closely: Stakeholders that fall in the top right quadrant are the most important; they are key stakeholders who are directly interested in your project and exert great influence over the outcome. For example, maybe they make resourcing decisions. Or, your CEO is interested in a redesign and would like to contribute with personal ideas. These stakeholders need to be managed closely; without doing so, they can advertently or inadvertently stop, hinder, or block your project. When managed well, these stakeholders can become promoters of your project, making success a likely outcome.
Keep satisfied: Stakeholders found in the top-left quadrant are referred to as latent; they currently aren’t interested in your project, but they have the power to impact your project greatly. It’s important to ensure these stakeholders are happy. If they find that your work impacts their own, they may get involved. You may want to consult with them to make sure their interests are observed.
Keep informed: Stakeholders who are interested in your project but have little power over it should be kept informed. They should be invited to research, copied into debriefing emails, and invited to design critiques.
Monitor: It’s not worth spending a lot of time engaging or managing stakeholders that fall into the bottom left quadrant because they have little interest in your work or power over it. However, circumstances could change, and they could move into one of the other quadrants, and so you should monitor them regularly.
DesignOps is a collective term for a range of design-related challenges that designers and design managers must solve on an ongoing basis, such as: growing and evolving design-team structure, finding and hiring people with the necessary skills for the team, creating efficient workflows, and improving the quality of design outputs. DesignOps refers to the orchestration and optimization of people, processes, and craft in order to amplify design’s value and impact at scale.
When there are roles or processes in place to help design staff solve these challenges effectively and efficiently, designers can focus on their core contributions: design and user research.
The specifics of DesignOps (i.e., the particular practices and initiatives put in place to support designers) can differ greatly from one organization to the next, and therefore DesignOps might have a different meaning or represent a different set of activities across different design teams.
The goal of DesignOps is to establish processes and measures that support scalable solutions for these challenges, so that designers can focus on designing and researching.
In mature practices, common DesignOps roles are:
Design producers or UX producers: These roles are concerned with project-level Design Operations and work alongside the design team to manage delivery. They are typically concerned with driving day-to-day design work and processes forward.
Design program managers or UX program managers: Program managers are tasked with program- or organization-level Design Operations. They work to optimize their team’s overall approach by managing and improving global design or UX processes, programs, and toolsets.
ResearchOps specialists: ResearchOps practitioners are responsible for owning the operational aspects of user research, such as sourcing and screening participants, overseeing the research-request pipeline, maintaining a research repository, and managing research tools, spaces, and equipment.
Design Thinking
Design thinking is an ideology supported by an accompanying process. A complete definition requires an understanding of both.
https://www.nngroup.com/articles/design-thinking/
UX Workshops
Hiring
https://www.nngroup.com/articles/ux-workshop-agendas/
Building a Team