One of the problems I have seen UX teams and entire UX practices struggle with again and again is getting their capacity accounted for when creating roadmaps or committing to work.

Often, UX is an afterthought or informed by how much time they have for deadlines. Usually, it’s calculated by looking at when engineering needs to start work to deliver by their deadline and then backing into how much time is left for UX.

This sets up the entire team—not just UX—up for failure. It causes burnout, MVPs that are more “minimum” than “valuable”, decisions based on poor (or no) research, and a reputation with customers for delivering poor quality, which sometimes you can never recover.

It’s not uncommon for UX to be thrown under the bus for “subpar experiences” being delivered, or the throughput being too low, but the team struggles to be set up for success.

I think we would all agree that accountability and enablement have to go hand in hand.

How can senior leaders and product/engineering parters better enable their UX teams? How can UX leaders better set up their UXers up for success?

There are 3 ways I’ve found that make a significant dent in this problem: Establishing a shared UX effort framework, tracking & estimating UX work, and incorporating UX estimates into capacity planning.

1. Establish a shared framework for determining level of UX Effort.

One problem is that UXers and their partners often don’t have a shared language or criteria to use to evaluate the level of UX work needed (design and research) to be done in a given set of circumstances. Like with engineering, there is some flexibility but there also needs to be a certain amount of work that is required based on criteria like complexity, risk, and existing knowledge of the problem space.

My article How to Estimate and Prioritize UX Work describes at length a framework I created to solve this problem. It gives a common language to speak detailing, general t-shirt sizing, and common activities done at each level of effort, and which level is appropriate in which set of circumstances. For more details, give it a read.

2. Tracking UX work

It’s common when I start working with a new team to discover that they are not tracking work in a tool like Jira or Linear. Sometimes the work isn’t being tracked at all, and other times it’s being tracked at a really general/high level in a spreadsheet or similar. “That’s for engineers”, “Our work is more ambiguous”, or “We don’t always know what needs to be done at the beginning” are all common things I hear from these teams.

I get it. Engineering tasks are far more concrete. There’s a definite set of requirements. Their work is also the last step in the process and delivers “something real” to customers.

But, tracking UX work in a structured tool like Jira transforms design from an opaque, siloed activity into a predictable, integrated function. Moving away from ad-hoc task management provides distinct advantages, particularly for scaling design operations and proving the team’s strategic value.

Here are the top 10 advantages of migrating a UX team’s workflow into a tool like Jira:

1. Seamless cross-functional alignment

Jira operates as a shared source of truth, bridging the gap between product management, design, and engineering. By living in the same ecosystem as developers, UX teams ensure that design tickets are directly linked to product epics and development stories, reducing friction during handoff and ensuring nothing gets lost in translation.

2. High-level visibility and stakeholder reporting

Stakeholders rarely need to see the minutiae of a Figma file, but they do need to know the status of an initiative. Dashboards and automated reports provide executive visibility into project health, mitigating the need for constant status-update meetings and proving the team’s continuous output.

3. Standardized and repeatable workflows

A structured tool enforces consistency. By defining custom statuses (e.g., Intake, Discovery, Wireframing, Review, Ready for Dev), the team establishes a standardized operational rhythm. This consistency makes onboarding new designers easier and ensures every project goes through the necessary quality gates.

4. Centralized documentation and audit trails

Conversations happening in Slack or email often disappear. A ticketing tool centralizes the “why” behind design decisions. Attachments, comments, and linked Confluence pages create a durable audit trail of iterations, feedback, and approvals that anyone can reference months later.

5. Streamlined intake for ad-hoc requests

Unplanned requests are a major source of scope creep. Routing all requests through a standardized intake process or service desk within the tool forces requesters to provide necessary context upfront and allows design leadership to triage, accept, or reject work systematically.

6. Data-driven continuous improvement

Agile ceremonies like retrospectives are much more effective when grounded in data. Looking at sprint reports, bottleneck stages, or cycle times allows the team to pinpoint operational inefficiencies and iteratively refine how they work together.

7. Ruthless prioritization

A centralized backlog makes it easier to visually stack-rank work against business objectives. It prevents the team from operating on a “first-in, first-out” basis and ensures that high-impact strategic work takes precedence over low-priority tweaks.

8. Clear dependency management

Design work is rarely done in a vacuum. A UX task might be blocked by pending user research, missing product requirements, a technical limitation, or work by another team. Linking issues highlights these dependencies immediately, surfacing blockers before they derail the sprint.

9. Strategic resource allocation and capacity planning

For leadership, understanding team bandwidth is critical. Tracking work allows for an accurate view of who is over-allocated and who has capacity. This visibility makes it easier to assign the right designers to the right initiatives and protects the team from burnout by pushing back on unreasonable timelines with hard data.

10. Quantifiable throughput tracking, resource management, and capacity planning

When design tasks are broken down and estimated, it becomes possible to measure the team’s throughput and calculate the team’s capacity. Over time, this historical data enables much more accurate forecasting for future projects, enables teams to ensure they only take on the work they realistically can handle, and provides them with a data-informed way of demonstrating resource needs.

3. Capacity Planning

Capacity Planning is the process of right-sizing the “Total Project Demand” with the forecasted Team Capacity. Most UX teams have no idea what their capacity is. Fewer still have a process for calculating it and using it during quarterly planning activities with their counterparts in Product Management & Engineering to ensure teams don’t commit to more work than they can handle.

Of course, there’s a lot more that goes into a quarterly planning cycle than just calculating capacity. Strategy & OKRs have to be aligned on. Work has to be prioritized & estimated. The executive team needs an opportunity to provide input. Etc.

UX team structure to ensure success

In this article, I will avoid getting too technical on specific tools and how the process I will go over is implemented. It’s the process that is important, not which tool you implement it in. Plus, there is a lot of variation from company to company, and I don’t want to be overly prescriptive.

That said, there is a point worth considering regarding team structure and how UX fits in to the wider organization.

Historically, the prevailing wisdom has been the “Embedded Model” where each UXer is embedded into an engineering squad. It usually looks something like this:

Over the years of operating in this way, I have found some problems with this approach.

• There’s almost never enough UXers to staff 1 per engineering team.
• It creates siloes within the UX org that require a lot of effort (and meetings) to overcome.
• It results in early career UXers being thrust into projects they’re not ready for and Lead UXers doing low level mockup work. (Since whatever work the squad needs is their responsibility).
• Most relevant to our discussion here: Capacity planning, dependency management, and throughput tracking gets extremely messy.

Instead, I recommend treating a UX team as an individual squad, separate from Engineering, assigned to an STO (sub domain) rather than embedded on the Engineering squad.

This allows:

• Clear Dependency Management
• Independent Capacity Tracking
• Better throughput tracking and transparency to partners
• Flexibility to assign the right UXer to the right project based on skill, level, and domain knowledge.
• More cross-pollination, and much fewer silos.

One objection many UX teams have to this idea is: “We like working hand in hand with Engineering. We’re 1 team, not 2.” I very much agree. However, you don’t need to be part of the same squad to operate as a unified team. In fact, I have found that by setting your UX team up as a separate squad, you actually improve the partnership, not limit it. Each squad has clear capacity, date, commitments, and dependencies on each other. When everything is mixed together, it’s harder to see. This often results in UX getting thrown under the bus or given insufficient time to get work done.

If you ARE able to work this way, this structure should be reflected in your Jira/Linear/etc setup. (You should have a separate “squad” for each UX Design & Research team). My current UX org of 25 is currently set up with the following UX Squads by “experience” (Product) :

• UX Ordering (Buyer, Marketplace product)
• UX Post Order (Buyer, Marketplace product)
• UX Partner (Partner, Marketplace product)
• UX Supplier Services (Ad Tech product)
• UX Design Systems
• UX Research
• UX Content

For the first 4, those correlate to our STOs. (1 UX squad per STO).

For the last 3, they operate with an additional layer of abstraction. Research and Content operate as distinct squads with their own capacity, commitments, etc. Some of them are embedded into an STO while others work on projects that span STOs. So there is some flexibility in this model.

If your company won’t support separate UX squads for now, you can still apply these concepts, but it might be a lot messier.

Ok. Let’s move onto the actual Capacity Planning process.

The 6 steps of proper capacity planning

There are 6 key parts of a healthy planning process needed to set cross-functional teams (including UX) up for success:

1. Align on strategy & OKRs
2. Prioritize work & determine capacity
3. Executive team feedback
4. Identify milestones & dependencies
5. Estimate work & align on scope
6. Final alignment & commitment

Let’s consider each one in more detail.

1. Align on strategy & objectives

The first step is to align on the goals and metrics for the quarter. This should be done at least 6 weeks before the start of the quarter to allow sufficient time for all the steps.

Many companies use a goal-setting framework called OKRs (or Objectives and Key Results). The framework is built on two fundamental components:

• Objective: What you want to achieve. This is a qualitative, inspiring, and clear statement of intent.
• Key Results: How you will measure progress toward that objective. These must be quantitative, specific, and easily trackable (usually 3 to 5 key results per objective).

There are many books, courses, and articles about OKRs. One of my favorites is Who Does What By How Much: A Practical Guide To Customer-Centric OKRs by Jeff Gothelf and Josh Seiden

There are many goal-setting & strategic objective setting frameworks. If your company uses something else, that’s fine. The most important point is that before initiatives or projects can be determined, strategic objectives & north star metrics are needed. While these are likely set on an annual or even 3-year plan basis, it is important they are revisited each quarter.

2. Prioritize work & determine capacity

Propose projects

About 5 weeks before the start of the next quarter, teams should start creating a proposed list of of projects for the quarter and determining their capacity.

With the project list, the key is that the projects are seen as only the proposed list. Before we can do proper capacity planning, we need to have a prioritized list of project candidates. Unless you work at a small company, this likely will be multiple lists, one done by each team or domain. Exactly who or how this gets done will vary with the company, but it will probably look something like the PM or Product Director crafting the list with input from UX and Engineering.

It is very important that this list be rooted in the OKRs and be prioritized.

This part is pretty straightforward, so let’s move on to Determining Capacity.

Determine capacity

It’s important before you get too far in the planning cycle to determine the capacity of each team (or squad). Knowing team capacity helps you to have an idea early on how much work each team (UX & Engineering) can handle to help guide your roadmap commitments for the quarter.

To help with that process, I have created a worksheet (which you can download here) that makes it easy to calculate capacity and compare with project demand.

Let me walk through how to use it.

STEP 1: Enter start date and end date of your cycle (quarter for many companies, but could also be month or another cadence). This will help calculate the number of available working days in the cycle.

STEP 2: Navigate to the “Days Off” tab and enter in all your company holidays and other days you don’t want to count toward your capacity (like hackathons or company offsites). These days will automatically be filtered out of the Total Working Days calculation.

STEP 3: Now, head back to the team sheet and fill in the Individual Capacity table with the Name, Role & Level, # of PTO days planned for the quarter, Overhead, Work Hours per Week, and the Focus Rate.

NOTES:

• The purpose of PTO has nothing to do with approving PTO. It doesn’t need to be exact and this sheet isn’t intended to be the source of truth for PTO. The only intent is to filter out any days each person already knows they won’t be available during the quarter.
• Overhead time includes admin or management tasks that are necessary but not directly focused on delivering roadmap projects (and as a result should not be counted as available capacity). . You might think about this as “management” time. How I normally determine what to put is I think about what % of my time is spend with management tasks across the entire quarter and then enter the corresponding amount of days. For a Manager that often translates to 5%-10% or around 3–6 days per quarter. Lead/Staff level individual contributors often have some overhead, but not as much as a Manager. Senior and below usually don’t have Overhead.
• “Focus Rate” (or “Utilization Rate” at some companies) is entered as a percentage and is key to forecasting realistic capacity numbers. The idea is that even subtracting PTO and Overhead days, there is a cost to context switching, team meetings, miscellaneous unanticipated asks, etc that result in lost productivity. These are things that take up some time but for which we don’t put a task in the backlog. To allow for this we enter a “Focus Rate” which is the amount of time we will be working on (focused) on backlog work. (Or deducting a % of time to account for the things listed above). A good starting place for Focus Rate is 70%. It should be a little higher for independent team members with less distractions, and lower for those needing more guidance or who have more distractions, are newer to the team, etc. Think of Focus Rate as “what % of their time should they be spending on backlog work”.

Once you’ve entered all this in, the sheet will calculate your Team Capacity. This is the number you should plan work against.

NOTE: these are “person days”, not calendar days. The fact that 1 person day of work usually take multiple Calendar Days is why we adjust for Overhead, Focus Rate, etc.

3. Check in with the executive team

Between 4–5 weeks before the quarter starts, there should be a check in with leadership. Who this is will vary with the company, but it should be whichever cross-functional senior leaders have a stake in the roadmap and your commitments. If you’ve written your OKRs well and set them based on company strategy, there shouldn’t be too many surprises here. Usually the feedback amounts to changes in priority, rather than complete changes in direction. If there are changes in direction, though, it’s best to discover them early.

4. Identify milestones & dependencies

Identify dependencies

Around 4 weeks before the next quarter, after you have received feedback from the executive team and have made any adjustments to projects & priority ranking, the next step is to identify what teams need to contribute to the project to make it successful. If you’re organized into business units or Single Threaded Organizations (STOs), that might be the teams within the STO. It could be dependencies on other teams in other STOs. At the very minimum it should be 1 UX team and 1 Engineering team.

Determine milestones

Once you have your dependencies created & mapped, the next step is for each squad to identify milestones or “deliverables” that captures their part of the work. The way I recommend to track those dependencies is to create a team-specific (placeholder) epic under the initiative and assign it to the lead of that team.

That way, each UX squad will have an idea of which projects are requesting UX support. It is important to create separate milestones for design and research work. (If you have a separate UX Research squad, they will have their own

NOTE: One other advantage of the Dual Track UX Resourcing model is that it clearly signals your independence to commit to and maintain your own capacity separate from engineering. You’re not inventing your own priorities, but you do have the right to only commit to a doable workload. This becomes easier in the Dual Track model.

For each milestone, it is important to use the UX Effort framework to align with Product Management on which level of effort (LOE) each design and research milestone falls into. You don’t need to make detailed scope decisions here, but you do need to align on the high level LOE.

5. Align on scope & estimate work

Align on scope

At least 3 weeks before the next quarter, we should already have aligned on the UX LOE for each project. Now we need partner with Product Managers to understand what is in scope and out of scope so we can add estimates.

We don’t need full-blown multi-page Product Requirements Documents (PRDs), but there is some information we do need from PMs before we can break down work.

The type of information and where it is documented will vary company-to-company. I highly recommend aligning with partners on a template and where you will document this. I advocate for something like this:

• Background info (what does someone need to know to understand what we are doing)
• Problem to solve (what are we doing and why does it matter)
• Business outcome / Value (how will this enable our strategic goals / OKRs)
• User outcome (how this will improve someone’s life)
• Success criteria (how we will know if/when we have been successful at solving the problem)
• Design level of effort
• Research level of effort

It is not all on the PM to provide all this information in a silo, but they should come with a plan on at least the first 3, and then partner with UX on the rest. Whenever possible, I try to include what is In Scope and Out of Scope under the Problem To Solve. How exactly you arrive at this information is up to you and your partners, but you do need to have it aligned on at least 1–2 weeks before the next quarter starts. A good rule of thumb when determining what information you need is to consider: “What information do I need to be able to provide a realistic estimate?”

Add estimates

Once you have all the scope alignment complete, you need to estimate the work. The level of fidelity will vary, but at a minimum you need to estimate the work at the Epic (milestone) level. If you have time, I recommend breaking your epics into backlog items (stories or tasks) and estimating each smaller chunk. You will need these prior to the quarter starting anyway, but if you’re in a time crunch estimating at the epic level can work too. I strongly recommend estimating in Days rather that Story Points. It is far easier to compare with capacity that way. If your org uses story points, though, that can work. You just might need to do a translation.

Once you have all your estimates entered, add them all up and enter that value in the “Total Project Demand” field on the spreadsheet.

NOTE: I have seen teams record their projects on a spreadsheet like this as well. I have avoided that since I prefer to have Jira/Linear be the source of truth. If you’d like, it is possible to write a script to for this spreadsheet to pull in Total Project Demand from Jira/Linear.

Now will all the info entered, you can compare your Team Capacity against your Total Project Demand. The sheet shows you whether you’re Under Capacity, Over Capacity, or At Capacity and by how much. Being within 5% of Total Working days over or under is reflected as “At Capacity”.

In addition to +/- Days there is also how many People you are over/under. This takes your Capacity Deficiency or Surplus and divides by your Average Capacity. This can help the conversation of what action to take to resolve the capacity discrepancy.

6. Final alignment & commitment

At least 1–2 weeks before the start of the next quarter, it’s vital to have conversations with your partners (and especially Product/Engineering leaders) about the discrepancy (over or under) in your capacity, align how to resolve them, and finalize commitments.

How to resolve capacity discrepancy

Being Under Capacity means that the Total Project Demand (your project estimates) are higher than your projected capacity. To resolve this, you have 4 choices:

1. Add additional resources (hiring or moving a resource in from another team)
2. Push project(s) out (move project(s) out to another quarter)
3. Reduce project scope (if that’s possible while still delivering something valuable).
4. Proceed without UX involvement (but make sure expectations are set on the ramifications. UX can’t be held accountable for quality on this initiative if they’re not involved. Avoid this when possible.)

The first 2 choices are preferable, but the others can be used in extenuating circumstances. After all, the point of using the UX Effort Framework was to right-size the level of effort needed for the circumstances. If a project falls off the available capacity based on priority, it probably should be move out of the quarter. If it can’t be moved out of the quarter, secure additional resources somehow.

Being over capacity means your projected Team Capacity is higher than Total Project Demand. To resolve this, you have 3 choices:

1. Increase project scope (include more than you were planning to have time to do).
2. Reduce resources (send a squad member to help another squad who is Under Capacity, either full-time or part-time)
3. Take on more projects (remember, it is OK to do UX work in a different quarter than the engineering team will be able to implement it)

Deciding how to proceed will likely take some back and forth with your partners and leadership. To help keep track of it all, I’ve provided a notes section on the sheet.

When you have decided which resolution to take, update the Select Action field.

Final commitment & unplanned additions

There are other inputs that product teams often use to determine final commitment such as Business Value, # of Customers Impacted, Revenue Impact, etc. I am intentionally not bringing those into this framework since they tend to vary from company to company.

After resolving the Capacity Surplus or Deficiency, you will have a final commitment for the quarter. It’s vital that all work be accounted for in this plan. If you haven’t already done so, this is now the time to break epics into stories/tasks and assign them out to team members. It’s also important to take into account individual capacity. If you have 149 points of estimates of Lead-level work, but you only have 1 Lead, that’s probably not going to work out well.

Conclusion & tips

During the quarter new projects will need to get added or removed (it always happens). In those situations, estimate the work that needs to be brought in, then look at your capacity sheet to figure out what work can be pushed out to make room for the new work. You don’t have unlimited capacity, and pretending you do will end up in burnout, increased turnover, and low quality work.

Whenever someone comes to me and says “we need to do X” (unplanned work), my answer is always: “Absolutely! What project would you like to de-prioritize to make room for the extra [# of days] of capacity?”

Another way I often use this Capacity Planning sheet is to break work into sprints. I take a look at an individual’s net capacity divided by 6 (2-week sprints in a quarter), and that gives me about how many person days of work I should assign to an individual per sprint. If they consistently deliver more than that, I know I need to look at how I’m estimating or at the Focus Rate for that individual. As you have more historical data to look at, you will be able to fine tune this resulting in fewer discrepancies and more accurate estimating.

Also, this 6-step process will need to be customized to fit into your existing process. The important parts are 4 things:

1. Calculate your capacity in a realistic way (feel free to use this spreadsheet to help if you’d like)
2. Estimate your work
3. Compare your Total Project Demand with your Team Capacity
4. Align with partners on how to resolve discrepancies between the 2.

I hope you can see how working this way can set your UX team up for success and will solve so many challenges UX teams often face. It requires a little extra work (what some designers call “busy work”), but the ROI of that extra work is extremely high.

Got a question about this topic? Need a UX, Product Design, or Research leader to help improve your UX operations? Looking for 1:1 mentoring services? Connect with me on LinkedIn, check out my portfolio, or send me an email.

Integrating UX into capacity planning was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’re struggling with critique, you’re not alone.

Ineffective critiques are extremely common. I’ve seen them at Fortune 25 companies. I’ve seen them at mid-size scale-up companies. I’ve seen them (or a complete lack of critique at all) at startups. In the last 15 years, I’ve never joined a UX team where critique was already running smoothly. In fact, I counted it a blessing if critique was running at all.

UXers are constantly inundated with requests to review their work. Their partners want to weigh in. Managers expect to stay up-to-date. Executives want a stake in the work. Designers often want feedback from other designers (or want to provide feedback to other designers). Etc.

There really is no other role quite like being a designer. (Imagine an engineer’s code being scrutinized to the same degree and by as wide a variety of audience as a UXer’s designs are. Crazy, right?)

If you can relate to these feelings, you’re not alone. It’s something nearly all designers and design teams struggle with.

The good news is that there is hope. There are some specific things I’ve seen work well to improve the effectiveness of “crit”.

Understand different design feedback meeting purposes

One of the first things I’ve observed with critique when joining a new team is that they often mix meeting purposes of the meeting they refer to as “Critique” or “Review”. I have found that the broader bucket of ‘provide design feedback’, can actually be broken down in to 4 sub-goals or problems to solve.

1. Level-up Craft and Product Experience over time.

We all need practice giving context, practicing storytelling, identifying business value and user outcomes as well as hearing others’ perspectives on if/how our ideas are solving the actual user problems you’re targeting. Exercising these muscles regularly without pressure to implement every piece of feedback levels each other up over time, helps us see out of the box, and builds trust / understanding.

2. Gain alignment with working team

At the same time, we need feedback to move the work forward. We need alignment with Product Managers and Engineers. These types of conversations often are more focused on which direction should we go, what is in scope and feasible to build right now vs later vs never. Gaining alignment is the main goal here.

3. Ensure design quality, craft, and consistency standards are met.

Teams also have a need to ensure design quality, craft, and consistency across different areas of the product. This need is similar to Peer Reviews (PRs) or Code Reviews (CRs) that are common for software engineers. For example, recently I saw a designer include a select component for a quantity field. After the Quality Review, we changed the component to an input. This is a small example. There are much larger and important quality and craft considerations as well. The key is getting another set of (designer) eyes on designs before they get shipped.

4. Keep stakeholders up-to-date & report out progress

Finally, we of course need to keep stakeholders up-to-date, democratize learnings, evangelize UX impact, and gather information on other company initiatives that might have some overlap with what we’re doing here. These are often more readouts and reaction gathering than a list of changes to go implement.

In fact, we can actually map each of these feedback types or purposes with unique feedback meetings: Design Critique, Design Review, Quality Review, and Design Shareout.

When we do, we actually find that the variance between them actually spans more than just “main purpose”. In fact, there are key differences in purpose, type of feedback, and approach that can make trying to mix them impossible and confusing.

Align on design meeting criteria

I have found there are 7 main factors that can help guide the scope and focus of each type of feedback meeting. They are:

1. Main Purpose
2. Type of Feedback (that should be solicited & given)
3. Focus
4. Who Should Be Invited
5. Percentage of Work Completeness
6. Required to Implement Feedback?
7. Frequency

Mapping these out per meeting type has offered much needed clarity for many teams I’ve supported over the years.

In fact, the last 3 companies I’ve joined have all had the same problem. They were all mixing Design Critiques, Design Reviews, and Quality Reviews up in the same meeting. Often this resulted in variances in focus, the type of feedback that was offered, and left designers unsure if they needed to implement the feedback or not. Then they’d go and do a Design Review with their triad team and get another set of notes. This often left designers feeling like they were between a rock and a hard place.

The first thing I did was to help clarify the meeting purposes and ground us in what purpose we were solving in which context.

Design Critique

MAIN PURPOSE

The ultimate goal of a design critique is not to judge a design but support a designer in improving a design.

— Ben Maclaren,

The main purpose of Design Critique is to level each other up and level up the product experience over time. The main focus should be on Objectives. Does the design solve the objective / goal / or problem it set out to solve? If so, why? If not, why not?

FOCUS & TYPE OF FEEDBACK
As such, feedback should be focused on Questions to Consider, Unsolved Problems, and be laser focused on the objective. It’s not terrible to note inconsistencies if you see them, but that should not be the main focus of a critique.

In fact, in their book “Discussing Design: Improving Communication and Collaboration through Critique”, authors adam connor & Aaron "Ron" Irizarry detail 4 main questions that are at the heart of a well-done critique:

Notice how all of the questions are rooted in the objective? For more details, I’d highly encourage you to check out their book. It’s fantastic.

REQUIRED TO IMPLEMENT FEEDBACK?
Another extremely important characteristic of a well-done critique is that the presenter should not feel compelled to implement feedback. Again, the purpose is not on moving the work forward. It’s on leveling up craft and improving the user experience of the platform over time.

EXAMPLE
Jared M. Spool nailed these ideas home when he said:

“The seasoned critic knows the harsh truth: nothing they say will directly change the design in any way. The only way the design can change is if the design owner does it.

In the best critiques we’ve seen, the critics never made a single recommendation. Instead, they asked questions and guided discussion. They talked about the significance of design rationale as it pertained to a bigger philosophy and vision for the design.

For example, instead of saying, ‘While I think those flyout menus are slick, I recommend you nuke them and put the links in the center of the page,’ the critic might ask, ‘What alternatives did you consider for the flyout menus?’ By moving the conversation to talk about the bigger picture, everyone can discuss how this element (the flyout menus) is contributing to the total experience.

— Jared Spool, “What Goes Into a Well-Done Critique”

In Jared’s example, I might even go farther & suggest, “Can you help me understand your perspective on how flyout menus solve the objective of…?” Or, “we’re using flyout menus on this same page in a different place. Have you considered what the experience would be if they’re both open at the same time?”

WHO SHOULD BE INVITED?
Since a critique should be focused on UX craft, invitees should only include UXers. Product Designers, Content Designers, User Researchers, etc. While we very much value the perspectives of Product, Engineering, Marketing, and Sales partners, this should not be the venue for that feedback.

PERCENTAGE OF WORK COMPLETENESS
While the focus of critique is on leveling up craft, and implementing feedback is optional, there is a sweet spot of work completeness for a critique. It comes when you understand enough of the idea to be able to explain it to others, but it isn’t so far along that you don’t have time to implement any feedback you might find helpful. There is diminishing value of critiquing work that is already mostly baked and not maleable.

FREQUENCY OF CRITIQUE
It can vary, but the sweet spot I’ve landed on over the last 5 years or so is for each crit participant to present at least every other week. On my teams, that usually looks like critique groups of 4–6 with sessions held weekly and each participant presenting every other week. I’ve found that the power of critique magnifies when a designer brings the same project to crit multiple times along its lifecycle. That way the feedback and conversation can evolve with the project.

Design Review

Unlike with a Design Critique, the main purpose with a Design Review is to move the work forward. As such, this meeting should be cross-functional with a high focus on securing alignment and on implementation of the solutions. As such, the work should be a little farther along, and there is an expectation to either implement feedback or provide justification why not. The end of the conversation should result in alignment (different than consensus) and the feedback should be solution-oriented and be include considerations around business impact and technical feasibility.

If you’d like additional info on holding effective Design Reviews, I’d highly recommend checking out Tom Greever’s book “Articulating Design Decisions: Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience”.

Quality Review

A Quality Review is also about moving the work forward, but its focus is more on design craft & quality over alignment and technical feasibility. Much like a engineering PR, the focus is on quality, standards, and consistency.

Just like you would never have a designer conduct an engineering PR, a Design Quality Review should only be conducted by an experienced (on my teams I require Lead or above) designer.

Different from Critique, the feedback given here is more direction than feedback. Often it’s rooted in design patterns, correct component usage, and UX best practices. While we should always respect the unique process, approach, and individuality of the designer, we also need to maintain craft standards and consistency. This could be done by a single designer asynchronously, or by a small group of designers within the domain. (If doing with a group, it should be clear who has the final say).

Design Shareout

Finally, we have Design Shareout. The main purpose here is more 1-directional than the others. Often this is keeping stakeholders up-to-date and a time for UX to demonstrate storytelling skills. It can be a time for a manager to showcase the great work of their team, or a time for IC designers to get exposure to executives or other leaders.

Considering the audience, this usually is the time to focus on business value of the work and how this improved someone’s life (along with results to back it up).

The feedback at Shareouts should be focused on clarifying questions & connections with broader initiatives or company strategies. If you find that Shareouts turn into Design Reviews, that may be a clue that you might need to involve certain stakeholders earlier in your actual reviews.

Often these meetings can get quite big. Involve not only Product, UX, and Tech stakeholders, but keep other functions informed as well such as Marketing, Sales, Operations, Customer Service, and Onboarding teams.

Pre-work to set critique up for success

Now that we are all clear on what critique is and isn’t, now let’s talk about preparations you can make to increase its effectiveness.

Group Size & Organization

In order to have meaningful discussions and allowing everyone to participate, group sizes should be limited. At my most recent company, we had ≈ 20 Critique attendees when I joined. That made it very difficult to have a meaningful critique session. So I set out to break that big group into 3 smaller groups, each led by a “Critique Captain”.

If your UX team is bigger than 4–6 designers, you will need more than 1 critique group. If that’s the case, there are a couple ways you can arrange the groups each with their own pros and cons.

EMBEDDED MODEL
The default way many managers think to organize critique groups is by domain. This makes sense. UXers who already work closely together or on inter-related projects don’t need as much context setting. They likely are already familiar with the problems at hand, report to the same manager, have rapport built up, and work closely together. The groups in this scenario resemble the org structure. For us, this would have meant creating critique groups for each of our 4 domains:

The down side to this way of organizing the groups is that group size doesn’t always load balance well and it maintains a semi-silo between teams. Which for our particular needs led us to explore other options.

CROSS-DOMAIN MODEL
With the Cross-Domain model, we sought to load balance group sizes while having as many domains represented as possible. We are a big enough team that it wasn’t possible to have all domains represented and still keep groups small, but it did work out for each group to only be missing 1 domain/function. We went with 3 groups.

In our case, the decision was to made to include researchers as participants but not as presenters. So that meant each group was comprised of 4–5 designers.

One other benefit of the Cross-Domain model is that it makes it possible to not be stuck in the same group for months or years. I like to switch up groups & critique captains every 6 months or so. This allows multiple people to gain experience running critique groups and allows group members to get to know the work of different designers and domains.

Critique Roles

It’s vital to clearly define the distinct roles in critique. For each session, identify who will fill what role. It’s not required (nor even advisable) for the same person to always fill the same role. In fact, everyone in a group should rotate filling each role. On my teams, I identify 5main roles:

1. Critique Captain—the person responsible for overseeing critique, making sure it happens, managing the calendar invites, ensuring roles are rotated among the group, etc.
2. Facilitator — moderate the process and keep everyone on track (within the session)
3. Presenter—the one presenting work for critique
4. Critics—those giving feedback
5. Notetaker—someone responsible for documenting any conversation points not represented via sticky notes

Critique Captains rotate every 6 months. Facilitators & Note Takers rotate every week. Presenter and Critics rotate from slot to slot within a critique session.

Making sure the person who will be fulfilling each role is clearly documented can help align expectations and be a useful reference after the fact.

Presenter Schedule

Many teams run critique slots on a sign-up or opt-in basis. When I first started running critiques I did as well. I really wanted it to work. I value autonomy and trust. I loved the idea of letting people sign up when they needed feedback. My experience has been that sharing in-progress work doesn’t come naturally for the majority of designers. Critique can feel like judgement—especially after joining a new company or team. Most designers tend to want to wait until designs are polished before sharing work. This results in a lack of sign ups, or in the same 2 people presenting over and over.

In order to ensure that everyone presents regularly, I’ve found it necessary to create a rotation schedule. Each designer is required to present at least every other week. We meet each week for 60–90 minutes (depending on group size) and each slot is 30 minutes long. Designers are welcome to trade slots if they’d like.

Presenters send the Critique Captain their topic 24–48 hours prior to the critique session so the calendar invite instance can get updated. Each calendar invite instance includes the following in the description:

1. Facilitator [Name]
2. Presenter 1 [Name] — [Topic]
3. Presenter 2 [Name]—[Topic]
4. Notetaker [Name]

Create a template for consistency

Too much structure and formality can get in the way of effective critique conversations, but what I’ve found is that teams often go to the opposite extreme. It is extremely common for there to be little consistency in process for setting the stage, providing feedback, and what happens afterward. It’s left up to the individual. Even on the rare occasions there is consistency, there’s no record for later recollection. This inconsistency and variability often limit effectiveness. Finding a happy medium between rigidity and flexibility is vital to the success of critiques.

In order to help put some structure around the process, and keep all critique feedback in one place (separate from the working files that non-designers have access to), I created a template that serves as the basis for critique sessions. Presenters fill it out in Figma and then copy/paste to FigJam where we hold the actual critiques. Each presenter fills out their own template. (So there are 2 per session).

If you would like to download this template for your own use, you can find it (along with all the other resources described in this article) in the Figma Community Resources as a free download.

The template has 4 main sections:

1. Title / Overview
2. Set the Stage
3. Work to be Critiqued
4. During Critique

Title / Overview

The title / overview section keeps a record of:

• Domain
• Project
• Presenter
• Facilitator
• Note Taker
• Date

These are useful pieces of information when going back and reviewing the feedback after the fact. It keeps us grounded in where the work that we’re reviewing fits in.

Set the Stage

This section is filled out prior to critique starting. It documents the Objective and serves as the basis for the context setting the presenter does at the beginning of the session.

1. BACKGROUND

In this section the presenter adds information needed to understand the objective, including what motivated the project, who the users are, what journey stage the project applies in, etc. In our case being a 2-sided manufacturing marketplace, background info included what stage of the order lifecycle it applied to.

2. PROBLEM / OBJECTIVE

This is maybe the most important pre-fill section. This is the objective or problem the project is trying to solve. This should form the basis of the critique, and all feedback should relate to it. What are the pain points? Why is this problem worth solving at this time?

3. LEVEL OF EFFORT (Optional)

Here, presenters specify what the level of design and research effort are. This is helpful context to understand why the designer may have taken the approach they did. It’s intended to be a high-level t-shirt size of effort based on criteria such as Complexity and Risk (for design) and Problem Clarity and Risk (for research). The LoE identified could be a point of feedback in and of itself!

For more information, please see my Medium article A framework for better UX capacity planning.

Variants are set up in the Figma file so you can choose the appropriate level for Design effort and Research effort. This section is optional, but highly recommended.

4. PROJECT STAGE (Optional)

I’ve found it helpful when introducing work for critique to identify where you’re at in the process. Is this work early, mid, or late in the process? This info can help guide the kind of feedback given.

This section is optional but recommended. There is a component set up in the Figma file so you just choose which stage you’re at.

5. FEEDBACK REQUESTS

This section is 100% optional, but sometimes it’s helpful to call out if there are specific focus areas of feedback. (Remember to keep requests grounded in design elements related to the objective). It can also be helpful to call out here what is already decided.

Work to be Critiqued

Next, in the middle section titled “Work to be Critiqued”, the presenter places the work to be critiqued. The template has placeholder containers for mockup / prototype screens, but it could be anything. The important part is that this is the main section where the focus of the critique will be. Copy / Paste artboards, screenshots, text (such as a research plan), whatever it is you want to be critiqued.

Copy / Paste into FigJam

Once work has been added to the “Work to be Critiqued” section, copy & paste the entire template into FigJam, Miro, or whatever tool you plan to use for the actual critique. I created the template in Figma to speed up filling out certain sections, take advantage of auto layout, etc.

I typically create 1 page per critique group in the same Figma file and then lay out the pasted templates by date. (So you would have 2–3 templates per date depending on how many presenters you have per session). That way we have everything in one place.

Design a structured critique process

As I’ve mentioned a few times, adding some rigor and structure around how you run a critique session is vital to its success and keeping everyone on track. So, on the template I also have an outline to remind the team of the process we follow. The process that has worked well for me is explained below.

1. Give Background (2 min)

The presenter reviews Background Info, Problem / Objective, Level of Effort, and Project Stage briefly with the group. If you find that this is taking longer than just a couple minutes, the facilitator could consider having everyone read the Set the Stage content. I prefer to have the presenter summarize when possible, though, because setting the stage succinctly is a skill needed far beyond just critiques. (It’s a good excuse to practice).

2. Walk Through the Work (3 min)

The presenter then quickly tells the story of the work so far including challenges they have faced and decision points they have made so far.

3. Ask Clarifying Questions (2 min)

Critics ask any clarifying questions needed before offering feedback.

Tip for facilitators: watch out for feedback masked as a clarifying question. If it happens, ask the critic to capture it in the feedback. At this stage of the process, we just want questions that clarify what the objective is, who the intended users are, etc.

4. Silent Feedback (7–10 min)

Now it’s time for the actual feedback. I’ve found that adding feedback silently first ends up resulting in more feedback and allows everyone to share their thoughts. (Sometimes if you jump right into discussion, the loudest voices can take over the conversation).

Critics use sticky notes, markers, and stamps to comment. Notetaker uses “comments” to take notes on the conversation about specific pieces of feedback.

STICKY NOTES (S)
The default way for leaving feedback. Place them wherever. Leave as much feedback as possible. Keep feedback grounded in objectives.

MARKER (M)
Where needed, point to specific elements in the design, or draw a quick doodle. Hold shift to make a straight line. Good practice to also include a sticky note explaining misalignments, etc.

STAMP (E)
Use stamps to dot vote, leave a +1, or just show some love.

COMMENT (C)
Use comments to add additional perspectives or conversation on feedback given via Sticky Notes.

5. Conversation (10–13 min)

Feedback is then discussed on a round robin basis as called upon by the facilitator.

Each critic chooses 1 (and only 1) piece of written feedback to discuss. This is to ensure everyone gets a turn.

The order should be as follows:

1. Designers in other domains (from the presenter)
2. Designers in same domain.
3. Leads / Managers

As a general rule, I try to always let lower level designers go first to ensure everyone gets to participate. Seniors, Leads, and Managers often have a wider variety of feedback and can discuss something no one else has mentioned.

6. Wrap Up & Reflection (3 min)

Presenter then summarizes their main takeaways and thanks the group for the feedback. They don’t need to summarize what everyone said (that’s what the documentation and notes are for), but it is helpful to reflect and communicate what were the most interesting and helpful pieces of feedback. This should be captured in the template by the note taker.

Set Clear Expectations

Even with all these resources & structure, sometimes it is a lot to take in for the team and over time expectations can start to fade. Having a clear, written set of instructions can be very helpful for reference and clarification later. Here are the written expectations we came up with at Xometry. Shout out to Jeremy Miler who wrote the initial draft, Addison Kavish whose brilliant content background helped us refine it, and Talia Malkin for her invaluable perspective as well. They are the best critique captains a manager could ask for.

1. Critique is not optional. It’s part of the work.

In the past, critique has sometimes felt like a drop-in. Going forward, it’s a core part of our design process. Tom and Jeremy Bird want to reinforce that showing up matters. Unless you’re on PTO or handling something critical, you’re expected to attend and engage.

2. We’re operating on a rotation. Everyone presents every other week.

Instead of a sign-up model, we’re running on a set rotation. That way, everyone gets equal time and knows when to prepare. You’ll be expected to present every other week, and knowing your scheduled week gives you time to pull together something thoughtful (not perfect).

3. Use the template — but don’t feel boxed in.

The critique template is a tool to help you frame your work, clarify what kind of feedback you’re looking for, and give the team context. It’s meant to support your thinking, not add red tape. Use it as a guide.

4. There should always be something to share.

We’re all working full-time, so there’s always something to bring, even if it’s rough. You might share early concepts, flows, IA, copy, or just something you’re stuck on. In a pinch, you can bring in outside inspiration (e.g., a competitor workflow or real-world UX moment) to spark discussion. That should be the exception, not the norm, but it’s better than canceling.

5. Presence matters.

This only works if we’re fully in it. Please show up with cameras on ready to engage, not just observe. Ask questions, offer feedback, and help your teammates push their thinking. Multitasking is tempting, but critique deserves your full attention. If you’re attending, be attending.

Tips & skills to level up design critique

Finally, to wrap it all together, I’d like to share some best practices I’ve compiled over the years that can help us all continually grow and become better at both presenting and critiquing work.

I’ve shared some specific examples and frameworks of how I have approached increasing the effectiveness of critiques. At it’s core, however, all the above tactics, frameworks, expectations and templates all roll up into a few key principles. If you take nothing else away from this article, look for ways you can apply these principles on your own team.

Tips for Facilitating Critique

• Ensure context is provided. Require presenters to frame their work: the challenge they’re solving, key insights, and measures of success.
• Promote equal participation. Don’t let the conversation get taken over by the vocal minority. Design a process that encourages all to participate and share their perspective.
• Keep it focused. Don’t let the group get lost in adjacent challenges or insignificant details. Keep track of time and ensure the group stays centered on the key objective.
• Pause brainstorming. It’s natural to start problem-solving, but brainstorming requires a different mindset at a different time. Let participants know that will come later.
• Capture notes and open questions. Ensure the critique is captured for the recipient to review & share with cross-functional teammates later.

Tips for Giving Critique

• Lead with questions. Don’t make any assumptions; expore what you don’t understand.
• Filter reactions. Write down your initial reactions as a filter to get more diliberate dialogue, rather than just chatter.
• Acknowledge what works. Critique is about strengths of the design decisions, too. By calling out things that are working well based on the objectives, we’re able to repeat our successes as a team and eventually inform our design systems.
• Speak from the objectives. Remove opinions by grounding your critique in the project goals and user’s perspective.
• Save feedback for later. If you have opinion-based feedback or ideas, make note of them, but don’t base the discussion around them. We want to take into account everyone’s ideas in our work, but critique should be rooted in the objective. (Remember, craft and consistency fall in the realm of Quality Reviews.)

Tips for Receiving Critique

• Frame your work. Use a written brief (such as a template) to define problem & success metrics. Every time.
• Set the focus. Come to critique with a specific objective in mind to help the group stay focused. If you want feedback on a particular aspect or the whole design, make it clear.
• Listen, then respond. Internalize the question or feedback before responding reactively. The team is critiquing the work, not your worth as a designer.
• Stay open. It’s not hard to react negatively to feedback. Capture the critique and reconsider it when you feel more comfortable.
• Participate in the critique of your own work. Participating in the critique of your own work and taking a look at it anew from someone else’s perspective inspires the switching from creative to analytical thinking. It separates us from the work, making it easier for others to engage without hurting feelings.
• Take careful notes on the discussion. Processing critique may take some time. Capture notes for later, or have someone do it on your behalf.

Additional Reading

• Discussing Design: Improving Communication and Collaboration through Critique” by Adam Connor & Aaron Irizarry.
• Articulating Design Decisions: Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience by Tom Greever.
• A Framework for Better UX Capacity Planning by Jeremy Bird.
• What Goes into a Well-Done Critique by Jared Spool.
• Design Critique Culture by Boris Müller
• Why your design critique sucked by Ben Maclaren.
• Derailed Design Critiques: Tactics for Getting Back on Track by Rachel Krause

Got a question about this content? Need a UX, Product Design, or Research leader to help evolve your organization’s UX maturity? Looking for 1:1 mentoring services? Connect with me on LinkedIn, check out my portfolio, or send me an email.

Improving design critiques was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

If there’s one pain point I’ve seen designers and researchers at every company I’ve ever worked at, consulted with, or advised struggle with, it’s lack of alignment on the capacity & priority of UX Design & Research work.

Some of the struggles come from designers who expect to do the “full UX process” (whatever that means) on every project. Other designers have anxiety letting developers implement anything they’ve designed without first usability testing their work.

Even more common is a lack of alignment with Product Management on the level of research & design effort a particular project should justify. Often, this is because no actual capacity planning for UX work takes place. Effort, Estimates, Roadmaps, and Capacity are all terms most commonly assigned to engineering work. Commitments are made, and planning is done for the delivery phase only.

To be fair, I’ve also observed that it’s not so much that teams don’t want to include UX in their estimates. They often just don’t know how. There’s no standard framework for level setting across the board around Design & Research Effort. Until now.

Problems to solve

There were 4 main problems I set out to solve:

1. Improve UX Capacity planning and improve alignment between UX, Product, & Engineering on level of UX effort needed in varied circumstances.
2. Set realistic expectations on the kind of UX activities that can realistically be expected in the timeframe
3. Help UX team determine level of discovery, iteration, and execution
4. Empower UX team to spend more time on projects where they can add the most value.

Pendo Research Effort Framework

Others have taken a stab at similar problems. In August of 2021, Jeanette Fuccella published a research prioritization framework on the Pendo blog attempting to solve the problem of determining how much research to do.

She created a quadrant across two dimensions: Problem Clarity & Risk.

• Problem Clarity: High and Risk: Low was “Ship it and Measure”.
• Problem Clarity: High and Risk: High was “Design Heavy”.
• Problem Clarity: Low and Risk: Low was “Research Light”.
• Problem Clarity: Low and Risk: High was “Research: Heavy”.

While very useful at a conceptual level, there were some practical obstacles to overcome:

1. It provided little context on what Research Light vs Research Heavy meant. It illustrated when to do which level of research, but not what that research entailed.
2. Most companies don’t have the luxury of having a big enough research team to do all the project-level research. So the question came up of when should a designer do the research and when should it be left to a full time researcher?
3. Attempting to combine both research and design into 1 matrix was overly simplistic. It helped some with determining research effort, but I saw a big opportunity to do a similar thing for Design effort.

UX Effort Framework 2.0

My new framework splits out research effort from design effort, included t-shirt level effort guides, a description on what each level of effort is (and when to use it), as well as common activities or attributes per level.

For Research Effort, I stayed with Problem Clarity vs Risk. Risk also makes sense for Design work, but I replaced “Problem Clarity” with “Complexity” (as complexity is often what determines how much iteration we need for design work).

PROBLEM CLARITY: HIGH

This is a problem we’ve worked on before, have extensive existing qualitative & quantitative research we can leverage, and/or shared understanding of across the team.

PROBLEM CLARITY: LOW

This is a largely new or unknown problem. Lots of assumptions exist. The problem is not well defined and significant alignment needs to happen. This work is likely at the strategic / initiative level.

RISK: HIGH

Work that is not easily “undoable”, affects a large % of users’ key workflows, and/or has a large amount of risk to the business or user experience.

RISK: LOW

Work that is easily undoable, affects a small % of users, does not affect mission-critical workflows, and where “getting it wrong” would have only a small impact to the business or user experience.

COMPLEXITY: HIGH

Involves many systems/APIs, external dependencies, stakeholders across multiple teams, or is technically complex (in ways that affect design decisions).

This is a problem space with many questions or in which the designer has little existing knowledge.

COMPLEXITY: LOW

Is mostly self-contained in terms of systems and stakeholders, has few if any dependencies, and is straight-forward.

Often these are simple usability improvements or additional use cases in well-understood workflows.

Research Effort Quadrants

To help understand each effort level better, let’s take a closer look at each of the Research Effort levels.

SHIP & MEASURE

Sometimes we need to prioritize speed over research rigor. This is best done when the problem clarity is high and risk is low. Often this step entails partnering on a post-release strategy and can be done by a designer.

RESEARCH LIGHT

Even when risk is low, if we have low clarity around the problem we’re trying to solve it is wise to do some research. Yet, we don’t need to spend weeks starting from scratch. Research Light also usually focuses on follow up discovery research. Since the risk is low, usability testing is not usually needed at this level.

Research Light is most often appropriate when we have prior quantitative or qualitative research we can leverage but still have unanswered questions. This research is typically done by the design team. Freeing dedicated research teams up from doing Research Light projects is a key element of improving the value created by research teams.

RESEARCH MEDIUM

When risk is high, even if problem clarity is high it is important to invest in research. The key difference between Research Medium and Research Light is that since the risk is high we do need to invest in evaluative testing since it’s not easily undoable or the cost to the business if we get it wrong is high.

It is also worth noting that this is the most common level of research that a designer will conduct if a dedicated research team is established.

RESEARCH HEAVY

For larger projects spanning multiple projects, teams, or journeys, more rigorous research is needed. Often these projects will require multiple research methods spanning generative & evaluative, qualitative & quantitative, and attitudinal & behavioral.

This kind of research typically is more strategic in nature and should be completed by a trained and experienced researcher. It often requires more time than a designer often has to run on their own.

Design Effort Levels

The level of design effort needed between quadrants detemines:

1. Level of fidelity needed
2. Leveraging existing patterns vs creating new patterns
3. Amount of iteration required
4. What stages of UX work are needed (modeling/mapping, wireframes, mockups, prototypes, etc)

The intention here isn’t to restrict the designer to a particular deliverable, but instead to communicate to partners the type and amount of work needed depending on risk vs complexity.

CONSULT ONLY

Not every project needs direct UX “hands-on” work. When the risk and complexity are low, it is 100% acceptable for UX to be consulted rather than assigned work (mockups) to do. This will enable the design team to spend their time on work where they can have the most impact.

Doing more consultations when risk is low, complexity is low, and we are leveraging existing design patterns is a key to unlocking UX’s potential to contribute more strategically to building the business. Too many designers spend far too much time being mockup monkeys for pre-determined solutions.

In those cases, it is extremely helpful to set the expectation with your product team that you’d love to just have a quick connect to align on the right component to use, flow, etc but that then the engineeering team should be empowered to do that work. This is one of the biggest benefits of having a design system in place.

I’ve even worked places where a front end engineer would spin something up quickly with a mocked up back end and then just show it to me. We’d discuss a minor tweak or two and then it would be ready to connect to the real back end and be released.

Letting go of needing to do a mockup on every little UI change is a key tactic in being able to spend more of your time on the more complex and risky (and impactful) work for which you are uniquely suited.

DESIGN LIGHT

Even if the complexity is high, if the change you’re contemplating would be easy to undue if it went awry, there’s often no need for a high level of iteration, low fidelity pre-work, etc. Just get it out there and test in the wild.

This is work where due to the complexity, we’re not comfortable just consulting, but we also don’t need a month of design work. Another key component here is where the cost to the business or user experience would be low if you’re wrong.

HINT: work related to personal info, financial transactions, government regulations, or mission critical systems should never fall within “Design Light”.

One of the biggest mistakes I see teams make is wanting designers to do UX Light work on every project. One of the big value-adds of using a framework like this is to help illustrate that we absolutely can do UX Light work, but only when Risk is low.

DESIGN MEDIUM

When Risk is high, it’s important to do more iteration and start problem solving at a lower fidelity. If the complexity is low not as much of this is needed, but it still makes sense to spend some time iterating to avoid costly rework and negative business impact.

Another common reason for Design Medium rather than Design Light has to do with situations where a new pattern / component needs to be introduced. Extra validation and testing are needed and it’s important to allow capacity for that.

DESIGN HEAVY

Finally, we arrive at Design Heavy. These are complex, risky projects where getting it right is essential. Often Design Heavy is paired with Research Medium or Heavy as well unless extensive prior research has been done.

This level is what many designers think of when they talk about the “Full UX Process”. Modeling, Information Architecture work, Low Fidelity, Mockups, etc. Although deep functional prototyping is not always needed, it is important here.

The work needs to be more thorough because the cost of getting it wrong would be significant to the customer and/or business.

How to use this framework

“This sounds great, Jeremy”, you say, “but how do I actually use this?” That’s a great question. Let me share an example.

1. PROJECT PLANNING

When a project get’s prioritized (and often before), we populate the Project description with the following:

1. Background Info (any context needed to understand the problem)
2. Problem to Solve (and why this is worth prioritizing now)
3. Business Impact (or “value”)
4. User Outcome (how will someone’s life improve)
5. Success Criteria (what do we need to observe to know we were successful)

Usually these are populated by the Product Manager, but it definitely can and often is a joint effort.

Then, the assigned UX Designer on the team will take a stab at populating:

6. Design Effort level (based on the framework criteria)

7. Research Effort level (based on the framework criteria)

2. PROJECT KICKOFF

We then hold a kickoff with the balanced team and any key stakeholders (such as UX, Product, and Engineering leaders). We align on on the Project Description (including UX effort) before designers start work. Tweaks or additions are often made.

3. DESIGNER ADDS UX STORIES TO JIRA

One thing that I’ve found invaluable is to ensure UX tracks their work in a project management tool such as Jira. This helps provide clarity & transparency to partners, and allows us to hold ourselves accountable.

Once we’re all aligned on all the above, the designer will break up the project into individual work items (stories, tasks, product backlog items whatever flavor the org prefers). Guideline for level of fidelity is that each backlog item should be tied to some sort of deliverable (research plan, wireframes, mockups v1, research readout, etc). The Effort Framework operates as a guide on what backlog items should be done.

Each backlog item gets a specific estimate and is prioritized according to PM’s direction on which project should be worked on first, etc. Backlog items then get dragged into Sprints based on the designers capacity.

4. PLANNING

At this point, UX stories are reviewed with Product & Engineering and adjustments are made according to priority, business needs, etc. Our goal is to do this for all projects on the roadmap for a particular quarter. We recognize changes will happen but having something written up and prioritized for all projects in a given quarter enables UX Capacity to be taken into account when doing Quarterly Planning which results in more realistic expectations being communicated to executive leaders.

NOTE: I’m a firm believer in prioritizing problems & outcomes rather than features. That’s an ideal state I always work towards. I have found, however, that isn’t the way most teams realistically work. So ensuring a problem and outcome is defined for projects being prioritized and letting UX Effort and capacity guide release schedules (instead of the other way around) has been a useful & realistic compromise.

I’m Jeremy. I help orgs build better design teams and designers build better careers. Need help? Just ask.

Works Cited / Further Reading:

• A Tried and True Framework for Prioritizing User Research - Pendo Blog
• When to Use Which User-Experience Research Methods

How to Estimate and Prioritize UX Work was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

There is an almost universal desire shared by designers the world over: “gain a seat at the table”. Naturally, we don’t just want a seat at the table, we want to be viewed as a trusted strategic partner with the other key functional areas of the business. We want to have impact and we want to deliver outcomes. In essence we want an increased capacity to improve customer lives, but feel powerless to change it. It doesn’t need to be that way. You can ship better experiences and have a bigger impact on the business, but you can’t do it alone. Neither can I. Neither can anybody you’ve ever met. Many call it ‘political capital’. I like to call it “influential power”.

The tactic of developing and using influential power is one all successful leaders use, yet many designers and new design leaders are unfamiliar with it. That is what I’m here to change today.

Influence is everyone’s job

The first step to having more influential power is to truly view influence as your job. Too many User Experience Designers prefer to leave influence, business decisions, financials, OKR setting, and the like to others. Either because they view “business politics” in a completely negative light or because they feel powerless to impact it.

The truth is, however, that we DO have the power to impact it. Many of us just don’t know it yet. Anything that harms the user experience is a UXer’s job. If not us, then who?

Mike Monteiro illustrated this point well when he said:

“Walt Disney created user experiences. You create user interfaces.”

—Mike Monteiro

But how? Structure & culture often feel like they prevent us from putting the user first. Each department has its own goals and objectives. Objectives that can seem to have little to do with crafting a great user experience. Objectives driven by their own targets and how management assessed their effectiveness.

Paul Boag described this problem in his book User Experience Revolution well when he said:

“If your company is to survive in the modern world, things have to change.

Gone are the days when companies could get away with offering a substandard experience, where pumping money into advertising could cover a multitude of sins. The world has changed and there is a new generation of empowered, connected consumers—consumers with higher expectations than ever before. If your company does not meet those expectations customers will go elsewhere. In fact, according to Customer Think, 89% of customers will stop doing business with a company after a single poor customer experience.

At its heart, that is what user experience design is all about. It is not about designing pretty interfaces or creating compelling brands. It is about better serving today’s connected consumers. It is about recognizing the power they now wield and ensuring you offer them outstanding service. It is about serving and not selling.”

—Paul Boag

I would add that to do that, we as user experience designers need to reinvent our thinking when it comes to what we view our job to be. We need to do the hard work to unify objectives and rally the company around what level of experience is possible—but first we have to view influence as our job.

Understand your partners & stakeholders

We in the UX field should be the best in the world at understanding others’ circumstances, motivations, goals, and pain points. We do a great job at this with customers, but often fail to do this with our partners and stakeholders.

Before we can influence or help anyone, we need to understand them. You already know how to do user research, so I’m not going to re-hash that aspect today. Just take those skills and translate them into understanding your partners.

What I do want to bring to light is that there are 2 ways of influencing others: manipulation and inspiration. Manipulation is the act of “handling or controlling” others. When we’re attempting manipulation we view others as objects to be overcome, to be handled, to be controlled.

Inspiration—on the other hand—is focused on the individual needs, wants, and desires of people. Unlike manipulative leaders, inspirational leaders—those that have the most influence on others—view those around them as people with wants and needs as valid as their own.

In their book The Anatomy of Peace, The Arbinger Institute shows how when we view others as objects we have a Heart at War, and when we view others as people we have a Heart at Peace.

One of my favorite passages from the book illustrates this point well:

There is a question I have learned to ask of myself when I am feeling bothered about others: am I holding myself to the same standard I am demanding of them? In other words, if I am worried that others are getting a “pass”, am I also worried about whether I am giving myself one? Am I as vigilant in demanding the eradication of my own mistreatment of others as I am in demanding the eradication of their mistreatment of me?

If I’m not, I will be living in a kind of fog that obscures all the reality around and within me. Like a pilot in a cloud bank whose senses are telling him just the opposite of what his instrument panel is saying, my senses will be systematically lying to me — about myself, about others, and about my circumstances. My ’opposition’ may not be as prejudiced as I think they are.

When I see others as objects, I dwell on the injustices I have suffered in order to justify myself, keeping my mistreatments suffering alive within me. When I see others as people, on the other hand, then I free myself from the need for justification. I therefore free myself from the need to focus unduly on the bad that has been done to me. I am free to leave the worst behind me, and to see not only the bad but the mixed and good in others as well.

But none of that is possible if my heart is at war. A heart at war needs enemies to justify its warring. It needs enemies and mistreatment more than it wants peace.

The Arbinger Institute, “The Anatomy of Peace”

In other words, if we are upset that others “don’t get UX”, are we just as worried that we don’t get their goals, aspirations, and responsibilities? If not, then we might be seeing the world as if through a fog. On the other hand, if we view others as people and consider their wants/needs as valid as our own, we will see the world clearly. We will have a heart at peace. This enables us to wield tremendous influential power.

Jared M. Spool described this concept masterfully in his article Why I can’t convince executives to invest in UX (and neither can you):

Neither I, you, nor anybody else can convince an executive to invest in user experience.

Sure, there may be a few execs that are somehow still unaware of how a delightful, useful, easy-to-use product is better than a frustrating, useless, difficult-to-work product. I haven’t met one in all my years, but they could exist. Even so, I don’t believe a presentation will change their views.

What can you do instead of a presentation?

You can find out what your executives are already convinced of. If they are any good at what they do, they likely have something they want to improve. It’s likely to be related to improving revenues, reducing costs, increasing the number of new customers, increasing the sales from existing customers, or increasing shareholder value.

Once you start talking about what the executives are already convinced of, it becomes easier to get them to make investments. You’re no longer trying to get them to change their focus. You’re playing directly into their main field of attention.

This is the secret to influence. Do Stakeholder Research. Empathize with them. Stop trying to convince them of what you need. Show how you can help them achieve what they’re already concerned about.

The Concept of Influential Capital

Even when we view influence as our job, view others as people, and take time to really understand them, we only have so much capacity to influence others. This concept is called “Political Capital” by many business leaders. If the term ‘Political’ carries too negative of a connotation for you, you can think of this as ‘Influential Capital’.

The important idea is that Influential Capital is a finite resource. No one has an infinite supply. We all need others to help us achieve our goals. This is the true meaning of business politics. (Toxic cultures often come about when employees & managers see others as objects and attempt to manipulate instead of inspire. Thus the negative connotation many associate with the term.)

We all have our own sphere of influence. There are multiple factors that determine our sphere of influence—and it can grow over time—but is never infinite.

The 7 types of Influential Capital

So now you’re probably wondering, “Ok, Jeremy, great, but what is influential capital in practical terms, how do I gain more of it, and how do I move forward if I don’t have much of it? While the exact kind of political capital that is valued most at your company, and which kind you will need in your specific circumstance will vary, it helps to understand the 7 main types of political capital and how they’re acquired. Those types according to Northwestern University Professor William Ocasio include:

• Symbolic Capital
• Human Capital
• Reputational Capital
• Social Capital
• Economic Capital
• Organizational Capital
• Cultural Capital

It is extremely important to understand which type of influential capital is most valued at your organization, to invest in developing it before you need it, and to diversify the types of political capital you acquire.

Let’s dive a little deeper in each of the types of influence capital.

SYMBOLIC CAPITAL

Symbolic influence is how your title, background, or degree perceived in your organization. At some companies, title carries a lot of weight. Others dramatically prioritize hiring those with degrees from prestigious universities. This can be frustrating if you don’t have the “right” background, elevated title, or degree, but there are ways of getting things done even in orgs where symbolic influence is prevalent that we’ll go over a little later. However, just being aware if symbolic capital matters at your company can already be a big step forward.

Also, remember that how “high” your title might be is not the only type of symbolic capital. Software Engineers or Product Managers can also wield more influential power than designers at some organizations.

HUMAN CAPITAL

Human Capital is determined by the skills, expertise, and knowledge you posses that you can use for others’ benefit. You were likely hired because you posses a unique blend of these needed in your role and for your team. That is a good place to start. You will want to keep an eye open, though, for skills that are widely respected throughout your entire organization. For example, I know companies that really value Storytelling. Those that are great using narrative to set a vision and communicate results tend to gain a lot of respect across the organization. At others it might be data analysis, financial literacy, or flexibility. Pinpointing which skills or knowledge is highly valued at your organization can help you both now and as you look to grow your influential power.

REPUTATIONAL CAPITAL

Reputational Capital refers to your track record, reliability, and ability to perform—or in other words, your reputation. This is often built up over time as your colleagues gain more experience and history with you. It is important to note, though, that Reputational Capital outside of your company is often just as valued and effective. Referrals, recommendations, and references are a great example of this type of influential capital. When you are well respected in your industry for great craft, helping others, thought-leadership, or a host of other skills, that carries weight within your current company as well. If you have a track record of building great teams in the past (as an example), you are more likely to build a great team in a new assignment. This is why many leaders are shuffled from one team to another (even overseeing domains they’ve never worked in before). They have built up a lot of Reputational Capital and have Senior Leadership’s trust that they can achieve great results again.

SOCIAL CAPITAL

Social Capital is the network you have to tap into and the personal connections do you have to tap into (either directly and indirectly). It is the result of personal branding & networking efforts.

It is vital to note that Social Capital is not just for when you need to find a new job (though it does, as Jeff Gothelf puts it, make you “Forever Employable). This can allow you to gain respect of coworkers and grow your track record as someone who achieves results. This is why most companies would rather hire referrals than someone random who applied online without any connection to the company.

Someone who has a lot of Social Capital outside their company often can get outside perspectives that can help their company significantly. Often these types of insights are extremely valuable and nearly impossible to gain for those without a high degree of Social Capital.

This is often why so many of us (myself included) spend so much time trying to help and influence those outside our immediate company. It helps others and it helps us as well.

ECONOMIC CAPITAL

Economic Capital mean the financial resources (profits, revenues, investments, etc) you bring to the organization. The perspectives of those who bring a high amount of Economic Capital carry weight at most organizations. It makes sense. If you bring a lot of revenue or reduce costs significantly, you get others’ attention. They are much more likely to take your advice and view you as a partner rather than a resource. As respected design leader Stephen Gates often says: “The work is the truth!”

The great news is that we UXers are great at providing economic value to companies. What we are not as great at is quantifying and communicating the value we bring. If you want to gain more Economic Capital, most likely all you need to get better at is show the value you are bringing to the company in terminology that the rest of the business can understand.

Sales reps are NOT the only ones who can wield enormous Economic Capital.

ORGANIZATIONAL CAPITAL

The authority to make formal decisions and to control the organizational agenda is called Organizational Capital. Companies with top-heavy Organizational Influence culture can be frustrating to work in, but it is important to acknowledge that this type of influential capital exists.

A way I discuss this type of influence with my team is that this is the ability to “direct” rather than just provide “feedback”. It is my aim to use any Organizational influence I may posses sparingly.

Since even UX Leaders often don’t posses as much Organizational Capital as many other leaders, it is important to use other types of influential capital to achieve results and to partner with and “sell” other leaders with more organizational capital.

It is also helpful to note that other types of capital can influence Organizational Capital. For example: if you bring in a lot of revenue, have a storied history of delivering great work, or have a great reputation in the industry, your perspective on company decisions will be greater.

CULTURAL CAPITAL

How effectively you represent and communicate the history and culture of the organization is called Cultural Capital. Those who are seen to influence and embody the desired culture of the company can wield influence. This can be everything from how you embody the cultural values of the company to how involved you were in the history of the company.

For example, I’ve worked at companies that have existed for decades. At these companies, the opinions & ideas of team members who have been around since the beginning are highly valued. They have the benefit of hindsight and know the ‘why’ behind foundational decisions.

How to increase your influence beyond your own capital through internal promoters.

So what do you do when you have identified the types of Influential Capital most valued by your organization and you find yourself falling short? You are hitting a wall. You need to improve collaboration, increase UX maturity, or stop your designs from getting watered down? How do you proceed when you’ve tried everything you can think of without much success?

When we run out of our ‘own’ influential capital, we can of course work on acquiring more—but that takes time. What happens when you need to make progress in the near term?

The best way I have found is to seek out internal “promoters”. These are people who have more Influential Capital than you do that you can “get on board” with what you are trying to do. It works best if you both are already aligned on solving the same problem or achieving the same results. Once you have gotten them on board, they can help you sell your idea or evangelize the value of your product to any other stakeholders or customers needed to achieve the needed impact.

It is also important to note that these are not always those with higher titles than you. (Remember, Symbolic Capital is only 1 of the 7 types of influential capital).

Let me provide 3 examples from my own experience.

SYMBOLIC CAPITAL

I once was working on a project where we were trying to revolutionize the user experience & code stability of a legacy platform. Both were atrocious. It took days (sometimes weeks at larger orgs) for users to complete their jobs to be done. As we dove into understanding users better we realized that the problems were deep rooted in the way the data model was architected, the technology used to write the code, and various other technical limitations. It simply wouldn’t have been possible to make more than minor usability enhancements without solving those fundamental issues.

I involved my PM partner in the user research I did. We brainstormed various solutions and evaluated various user workflows. From a business standpoint, we were losing customers due to this problem. It was the main entry point into our ecosystem and it was having a significant business impact. He prioritized solving this problem, but I was able to help him see that a quick fix just wasn’t going to be possible.

He was very technically savvy and knew our database schemas and data model well. He also had a high degree of Cultural capital and had more Organizational capital than I did. He was able to help illustrate the problems with the architecture. (Problems the engineers already cared about). At first we got pushback from some of the engineers, but we found a Lead Engineer with both the right Symbolic Capital and Cultural Capital that caught the vision (both from a technical and user perspective). He helped us convince the rest of engineering leadership. He was able to use language and arguments that resonated more effectively with engineers than I could have. The PM helped translate the feedback we received from users and the vision I had for what the experience could be into actionable data architecture ideas.

The result was an improved product that had dramatic impact for both the business and users. In fact, some of the customers that had previously quit using our product came back.

ORGANIZATIONAL & REPUTATIONAL CAPITAL

One time at a different company we were introducing new functionality that needed cooperation & collaboration from another department. It was not a priority for them because they perceived it to be unrelated to what was a priority for them and some even felt threatened by the new functionality we were building. They were worried that it would make their work obsolete. Both my manager and I were hitting a wall and being blocked. Our deadline was at risk of being missed, which in this particular case would have had significant business ramifications. One other wall we were coming up against was that we were a satellite office and were perceived to be less important than HQ. (Another type of Reputational Capital).

We sought to understand where the objections were coming from and why they felt our work was a threat to them. We pitched the idea to a few people from the HQ office who had larger titles than we did and had more history with the company. Eventually, we found someone who really caught the vision and could see how our work would ENABLE this other team, not threaten them. He was able to help them see how much more they would be able to get done, and how much more effective the work they were currently doing would be with the two products integrated more. He was able to get the attention of teams and leaders we never could have by ourselves. He had brought significant revenue to the company and helped avoid more than 1 catastrophe so he carried a lot of Reputational and Economic capital in addition to having an elevated title.

As a result, we earned a little more Reputational capital ourselves. We were viewed a little more as partners rather than resources.

SOCIAL CAPITAL

Anyone who has reached out to someone in their network asking them to share a role with their network or let them know if an open role comes available, already has experience with this principle.

We need others’ help and we can always help someone. Any time we tap into our professional network we are employing the concept of influential promoters.

Sales reps know well that “it is all about relationships”. You can achieve better results selling to people you have past relationships with than with cold calling.

Maybe the most poignant example I can recite is a very personal one. A few years back, I felt stuck in my career. It was essentially the same position many new to the UX field find themselves in. I wanted leadership experience at a Fortune 100 company to achieve my future career goals. I made it to the final round with Google, IBM, Amazon, The Home Depot (twice), Honeywell, and others. I was flown out to these companies’ headquarters, but I always failed to get the job.

I needed experience managing larger teams, but all the companies that had larger teams to manage wanted me to have experience managing larger teams.

Through a combination of personal branding (growing my social capital) and seeking out the help of someone in my network with larger Symbolic & Reputational capital, I was able to get hired at Target.

That has opened so many doors, but I couldn’t have done it alone.

Investing your political capital to help others

Much like in governmental politics, you can’t expect to ask for promoters’ help in overcoming your lack of influential power without giving help in return. This isn’t just true in politics, it’s true in networking and life in general. I prefer to just think of it as helping each other.

No one likes someone who just takes, takes, takes, without giving sometimes too. The same is true with influence.

As mentioned earlier, Influential Power is a finite resource. Each of the types of Influential Power are like buckets. They need to be filled to be able to be used, and when used, they empty a little. This is helpful to keep in mind when you see others’ struggling.

Part of why it is so important to “see others as people with wants/needs as valid as our own” is so that we’re not blinded to when others need help. An interesting aspect of helping others is that when you use a little of your Influential Power to help others, you earn a little extra yourself. Anyone who has spent any time serving others knows this. It’s not 1:1 and should be the reason you help them, but it is true just the same.

For example, if a developer approaches you with an alternate solution that might not be quite as user friendly but is WAY easier to develop, if you always push back you won’t have built up the influential capital to be able to push back when it REALLY matters. Give and take.

One framework I’ve used in these situations is to use the “F’s Scale”. Basically this means that there is a scale from 1–10 on “how many F’s do you give?” on a particular topic. (10 being highest and 1 being lowest). When a conflict comes up, I will ask the other person: “How many F’s do you give on this one?” If I am a 3 and they are a 7, then I let them win. The reverse is also true. Sometimes just realizing how strongly someone feels about it can help surface the way forward.

Just like with any investment, choose your ROI carefully. When you make wise decisions in where to invest your influential capital in others, you will gain so much more than you ever could have keeping it all to yourself.

Conclusion

So if you feel stuck and are having trouble influencing others at your org (or even finding a new job that matches your career goals), remember:

1. See Influence (doing whatever is necessary to ship great experiences) as your job.
2. Make an effort to understand your teammates and stakeholders like you do your users.
3. View others as people with wants/needs as valid as your own instead of objects to overcome.
4. Identify which of the 7 types of influential capital are most valued at your company (or dream company)
5. Do an inventory of what capital you have and what you still need.
6. Seek out an internal “Promoter” who can help you expand your circle of influence.
7. Don’t forget to help others expand their circles and give during conflict as well as taking.

Have something to add? Please leave a comment on the article, hit me up on LinkedIn / Twitter, check out my portfolio, or contact me.

Expanding your influential power as a designer was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

It may surprise some who know me professionally to learn that I identify as an introvert. It similarly almost certainly would surprise most of my neighbors & friends who know me well outside of work to learn that I work in what is often perceived to be a very extroverted profession. Yet, I hope to show today how this is a significant misconception. Introverts not only can succeed in design & leadership but can do so with flying colors. In fact, many of the same qualities that make between 35 - 50% of the world’s population introverted, are the exact same qualities that can make introverts excellent designers.

Why the misconception that designers should be extroverts?

To do UX right, you have to talk to and build relationships with people every single day. You have to negotiate. You have to sell your ideas to ensure they actually get built and shipped. You have to persuade product managers why spending that extra few days speaking with users will benefit the business. You have to convince engineers why fixing that styling or adding in that micro-interaction or animation will actually make the user experience better. Most importantly, you have to show everyone why learning about and from users together will result in better outcomes for the business.

Then there’s the actual user research. Speaking for hours to people who you don’t yet know and who will likely be struggling with your work. Then you have to turn all that insight into great experiences.

On paper, it seems like a job no self-respecting introvert would want. So why are there so many successful UX Designers and Leaders who squarely identify on the introvert side of the spectrum?

That is precisely what I want to discuss today.

What is an ‘introvert’?

It might help for us to define what an ‘introvert’ even is. You see, introverts are very often misunderstood. Most extroverts (and even many introverts) view introverts as “socially awkward”, “anti-social”, and “lacking people skills”. While those traits can be true of some introverts, I have found that definition to not only be unhelpful, but completely false.

I still remember where I was and what I was doing when I first learned the true difference between introverted and extroverted people. It actually has nothing to do with skills, it has to do with where you expend and gain energy:

For a long time, I had a certain idea about what makes an introvert or an extrovert. I had always thought that it works something like this:

- Extroversion relates to how outgoing someone is.
- Introversion is the same as being shy.

That was kind of my general perception. Doing just a little bit of reading made it clear very quickly that my thinking was way off!

Introversion and extroversion actually relate to where we get our energy from.

Introverts (or those of us with introverted tendencies) tend to recharge by spending time alone. They lose energy from being around people for long periods of time, particularly large crowds.

Extroverts, on the other hand, gain energy from other people. Extroverts actually find their energy is sapped when they spend too much time alone. They recharge by being social.

— Belle Beth Cooper, “Are You An Introvert Or An Extrovert? What It Means For Your Career”

When I first encountered this definition, it was like a light bulb went on. I’d never felt quite right about the idea that because I often prefer to stay home as opposed to go out around lots of people that I had a social weakness. When I need to be social I can. I even often enjoy it. I even enjoy being the center of attention sometimes (I have participated in many choirs, musical stage productions, I continue to speak publicly, and love to teach others).

Yet in many situations where there isn’t a definite purpose for my being the center of attention, I do slink to the outskirts or just avoid the large crowds to begin with.

It’s All About Energy

What we all need to normalize about introverts or extroverts has nothing to do with skills and everything to do with energy. Extroverts GAIN energy from being the center of attention, and Introverts EXPEND energy from being the center of attention.

The reverse is also true. Introverts GAIN (or recharge) energy by spending time alone or in small groups. Extroverts actually EXPEND energy when they spend too much time alone. Both types of people can be excellent or awkward in social situations depending on skills.

Introversion vs Extroversion is a Scale

It is also very important to understand that like many psychological constructs, introversion vs extroversion is a continuum scale. It’s not one extreme or the other. In fact, being 100% introverted or 100% extroverted is very rare. So don’t be surprised if there is a mix of both.

Characteristics of Introverts

The key idea here is that:

For introverts, to be alone is as restorative as sleeping, as nourishing as eating.

—Jonathan Rauch, Caring for Your Introvert

We as a society need to eradicate the idea that being an introvert means you don’t have social skills (or research or design skills). It just means that introverts have to approach design differently, and allow ourselves to recharge.

It means we love quiet conversations about feelings or ideas.

It means we’re very passionate.

It means we prefer individual or small group conversations.

It means we are deep thinkers.

It means we are good listeners.

It means we’re very self-aware.

It means we prefer observation.

It means we prefer exploring multiple ideas alone before syncing back with the team.

It means we are less likely to fall into “design by committee”.

It means we are often very detail oriented.

It means we form deep relationships (quality) rather than quantity.

In fact, if you think about it, these are all characteristics of great UX Designers.

Here are just some of the ways these introverted characteristics can actually be an advantage in UX Design rather than a disadvantage.

1. UX often happens in small groups.

The good news is that most of the UX process happens in small groups (teams) of people that frequently see each other and work together. The most effective research is conducted individually. All of this works to an introvert’s advantage because of their tendency to invest deeply in relationships and the fact that they gain energy from interacting in small groups.

2. Introverts are excellent user researchers.

Because introverts are naturally good listeners and excel at observation, they often make great user researchers. They enjoy silence and are less prone to “lead the witness” during a research session. They can let pauses drag on, which often prompts extroverted research participants to provide more detail. Since they don’t like the spotlight, they are always looking to put the user in the spotlight. This leads to fantastic research findings.

3. Introverts often form deep relationships which make them excellent at working with stakeholders

Since introverts gain energy from 1 on 1 or small group interactions, they usually develop deep relationships with those they interact with regularly. 1 on 1 conversations feel energizing so they tend to seek them out more. I’ve observed that since introverts tend to spend more time “recharging” in their own thoughts, self-awareness tends to be one of their strengths. This leads to a genuine appreciation of others and vast desire for & concern with people. This often results in genuine, deep relationships.

This skill translates extremely well in design when it comes to building relationships with team members and stakeholders. In the words of Carl W. Buehner:

“I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.”
 — Carl W. Buehner (1971)

People that make others feel important, valued, or respected tend to accomplish more impressive results. Why? Because they end up inspiring them. Author, speaker, and optimist Simon Sinek has said:

There are only two ways to influence human behavior: you can manipulate it or inspire it.
—Simon Sinek

All of us—I’m certain—have experience those who attempt to influence human behavior through manipulation. Those around them usually resent them and unless under their direct authority, usually push back on them.

Inspiration on the other hand often results from feeling great around others. We want to follow them or help them out because of the way we feel when we interact with them. It is by far the more effective way of influencing others—and introverts excel at it. It is by far the biggest reason so many effective leaders (and designers) self-identify as introverts.

Don’t believe me? Here are just some of the world’s most successful leaders who self-identify as introverts:

• Tim Cook, CEO of Apple’
• Bill Gates, Co-founder of Microsoft
• Jeff Bezos, Co-founder of Amazon
• Elon Musk, Founder of Tesla & Space-X
• Sergey Brin, Co-founder of Google
• Marissa Mayer, Former CEO of Yahoo!
• Warren Buffet, CEO Berkshire Hathaway
• Peter Thiel, Co-founder PayPal
• Steve Wozniak, Co-founder Apple
• Mark Zuckerberg, Founder & CEO Facebook

4. An introvert’s need for processing feedback alone is a strength when receiving feature requests & make them less likely to fall into “design by committee”.

One characteristic of introverts is their need for processing feedback on their own. This can actually be a strength, though, when receiving feature requests from users, stakeholders, or management. It can help them understand the issue better, and place the request in context of the greater problem space & user outcome the team is going for.

Introverts are often less prone to immediately implementing something just because someone surfaced an idea. Or if they do, they do so intentionally after thoughtful review. Processing feedback alone, also helps introverts make connections that would never have come to light without their thoughtful consideration.

Maybe most importantly, introverts are far less likely to fall into “design by committee”. They thoughtfully consider multiple angles and due to their need to process alone, usually give in less to peer pressure of trying to satisfy everyone. They consider everyone’s point of view, and then return with their reasons for the direction they’re proposing.

5. Their tendency to think things through before they speak make them great at working with engineers.

Because many engineers are often also introverted, introverted designers are often excellent at working with engineers. They think before they speak which can result in much more thorough thinking around edge cases and how the UI should react in situations that vary from the ‘happy path’. Engineers greatly appreciate this thinking. This type of edge case anticipation often increases speed, trust, and quality of the final outcome delivery.

How to care for Introverts if you’re their extroverted leader

If you have team members that lean toward the introvert side of the scale, but lean extrovert yourself, it is very important that you are mindful of the differences and avoid Affinity or Similarity bias. Why? The reason is that very likely that you’re making incorrect assumptions about them and are not ‘caring for [them] properly’:

Do you know someone who needs hours alone every day? Who loves quiet conversations about feelings or ideas, and can give a dynamite presentation to a big audience, but seems awkward in groups and maladroit at small talk? Who has to be dragged to parties and then needs the rest of the day to recuperate? Who growls or scowls or grunts or winces when accosted with pleasantries by people who are just trying to be nice?

If so, do you tell this person he is “too serious,” or ask if he is okay? Regard him as aloof, arrogant, rude? Redouble your efforts to draw him out?

If you answered yes to these questions, chances are that you have an introvert on your hands — and that you aren’t caring for him properly.

— Jonathan Rauch, Caring for Your Introvert

Ok. So you want to do better. How do you start? First, it will help to understand where on the continuum each team member is. This can give you ideas on how you can best support & enable them. The best way is to have a conversation with each direct report on the topic. If you need further assistance, there is a great personality quiz on lonerwolf.com that has some great questions that can help provide some conversation starters.

Once you have identified those on your team who lean more toward the introvert side of the scale, here are some suggestions on how you can work with & support those team members better:

1. RESPECT THEIR NEED FOR PRIVACY
   Allow them time & space for privacy when needed. If they don’t turn their camera on in a Zoom meeting this might not mean they aren’t engaged. It might just mean they’re feeling a little overwhelmed.
2. NEVER EMBARRASS THEM IN PUBLIC
   Embarrassment in public is a fear of many introverts. It has a much greater impact on them than you might realize. Even positive feedback can be viewed as a negative experience when done in public for some introverts. Get to know them & how they like feedback/recognition.
3. LET THEM OBSERVE FIRST IN NEW SITUATIONS
   Introverts are expert observers. They also can get nervous being put on the spot. When introducing an introvert to a new team or giving them a new assignment, make sure to allow time and space to observe and get the lay of the land before expecting significant contribution in a group setting. This helps them learn, think, and form their own perspectives they can later bring to the table.
4. GIVE THEM TIME TO THINK. DON’T DEMAND IMMEDIATE ANSWERS.
   Even after becoming accustomed to the team or space, allow them time to think. When asking for feedback or an answer for them, give them a chance to consider their response first. You will likely want to jump right in, make decisions in the meeting, and get going with the solution. Recognize that introverts need time for processing and that this is actually a great thing.
5. DON’T INTERRUPT THEM.
   Getting interrupted isn’t a positive experience for anyone, but it can especially affect introverts negatively. Do your best to to listen and thoughtfully consider their ideas before moving on. (Even when you’re going in a different direction from their ideas). This is especially important in big group settings. Remember, your introverted team member is expending energy in a large group setting rather than gaining it.
6. GIVE THEM ADVANCED NOTICE OF EXPECTED CHANGES.
   Introverts greatly appreciate knowing in advance when a big change is coming (and learning about it 1:1). Giving advanced notice on when they’re being moved to a different project, ample time to prepare for a presentation or group facilitation session can go a long way.
7. GIVE THEM 15 MINUTES NOTICE TO FINISH WHATEVER THEY’RE DOING.
   If you need to speak with them, or need to grab them urgently for something, introverts appreciate giving them at least 15 minutes to wrap up what they’re doing. Being thrust urgently into a new situation can feel especially jarring to an introvert. Whenever possible, allow them time to wrap up & prepare for something new.
8. GIVE THEM FEEDBACK ON HOW TO IMPROVE PRIVATELY.
   No matter how you provide positive feedback, never provide feedback on growth to your introverted teammate in public. They will take feedback, direction, and criticism much better in private. After delivering your message, also make sure they have some time to consider it in private and then get back to you later on next steps when needed.
9. TEACH THEM NEW SKILLS PRIVATELY OR IN A SMALL GROUP
   Whenever possible, it’s also best to do training, coaching, & skill development privately or in a small group. They will retain more, will participate more, and the time spent will result in a much bigger return. Also, incorporate both individual “homework” learning activities into any training courses in addition to breakout groups.
10. HELP THEM FIND ONE ‘BEST FRIEND’ AT WORK WHO HAS SIMILAR INTERESTS & HOBBIES.
    When considering community development, cultural initiatives, & onboarding programs, consider how these can resonate with introverts as well as extroverts. One suggestion is to help connect them with a mentor or onboarding buddy who shares similar interests, backgrounds, or hobbies as they do. Allowing them to develop 1 on 1 connections from the start will be much more meaningful than large group resources. (Both are important of course).
11. DON’T PUSH THEM TO MAKE LOTS OF FRIENDS.
    Let them ease into networking and relationship building. Pushing them into making lots of friends or connections at the company in a short amount of time can feel very overwhelming.
12. RESPECT THEIR INTROVERSION. DON’T TRY TO MAKE THEM INTO EXTROVERTS.
    This may be the single most important thing a leader can do. It, of course, goes both ways, but please recognize that your introverted teammate is an extremely capable, effective addition to your team. Create a space and a path for introverts to succeed in your org. Don’t assume just because they get energy from alone time that they are incapable of presenting to large groups or leading large teams. They bring a lot to the table, but trying to treat them the same as you would an extrovert will result in burn out, frustration, decrease in work quality, and overall mental health struggles.

Conclusion

I hope that if you are an introverted designer this has given you hope, confidence, and the knowledge that there ABSOLUTELY is a place for you in this industry. Not only is there a place for you, but you add a lot to our discipline. I also hope that this has given you some ideas on how you can recharge more, set some limits, and be more meaningful in how you care for yourself going forward.

If you are a design leader caring for an introverted designer, I hope this has created awareness of how you might care for your team a little more effectively.

Here’s to the hope that we all can do just a little better at supporting the introverts in our lives and that we introverts can do just a little better in supporting and recognizing value in ourselves.

Have something to add? Please leave a comment on the article, hit me up on LinkedIn / Twitter, check out my portfolio, or contact me.

Why introverts make exceptional designers & how leaders can support them was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

They say “hindsight is 20/20”. It’s very true. 10 years ago I made the switch from graphic design to user experience after a 10 year stint working for print shops & manufacturing environments. It has been an incredible journey so far, but there are many things I wished I had learned earlier than I did. These are the top 30. I share them with you in the hope that you can avoid many pitfalls I encountered along the way and become even more effective at improving users’ lives than I am. For when any one of us improves, we all win.

I have broken these lessons into 3 categories: Craft, Working With Stakeholders, and Job Searching. There are 10 lessons in each category. In this article, I will focus on Job Searching.

LESSON #21: Everyone struggles with job searching.

I remember being super frustrated looking for my first UX job. I sent in dozens of applications (over a hundred), had an application rejection rate approaching 95% and bombed every interview I got—and that was with 10 years of graphic design experience and formal training in UX at a time when UX training was rare. When I finally got hired for my first UX job, I was studying for the GRE & GMAT to continue on to Business school instead. I get it. It’s painful.

BUT…

One mistaken idea many new designers have is a variation on the “grass is greener on the other side” idea. They think that “If I can just get some experience under my belt…” or “If I can just make Senior…”, then job searching will be easier. While it can get a little easier the more you interview and as you build up experience, the simple fact of life is that job searching sucks…for everyone.

That said, there are ways I’ve learned that can help it suck less. That’s what all the lessons to follow are about, but if there is a silver bullet that can allow you to lose a job 1 day and start a new dream job 2 weeks later, I haven’t found it.

A lot of the key here is to realize that it simply takes time. Just like UX Design work itself. You wouldn’t expect to design an entire complex software application in 1 day and have it accomplish any meaningful results. The same is true of job searching.

While we’re on this topic, I’d also like to say a word about the other side of the table. We hiring managers are just as nervous as candidates going into interviews. We get frustrated that our roles take longer to fill than we’d like. We want to find someone great. We want candidates to like our company. We want them to have a good experience. We want to come across as human, empathetic, and real. We worry if the questions we ask are the best way to find the best candidates. Sometimes we interviewers pretend like we have all the answers and are judging the candidates worthiness to work at our company…but that is just a façade. We really just want to have a 2-way conversation and find the best mutual fit. Not all hiring managers would admit but most of us feel that way. So relax a bit and know that you’re not the only one who is nervous or frustrated.

That said, there are things you can do to make your job search more effective (even if it still ends up taking longer than you’d like). To learn more about the lessons I’ve learned in my 20+ years of job searching on making it as effective as possible, keep reading.

LESSON #22: Personal branding is vital.

If you want to lessen the pain of job searching, you have to put your branding hat on. Personal branding is nothing more than being intentional about what you want people to understand about what makes you unique. What is your ‘brand promise’? What is your ‘anti-brand’?

As Jeff Gothelf puts it in his book Forever Employable: How to Stop Looking for Work and Let Your Next Job Find You:

“Luck happens when opportunity meets preparation.”

Personal branding is the regular, ongoing effort of doing the preparation so you attract the right opportunities & companies and drive the wrong ones away. Yes, you read that right. You actually want to drive the wrong companies & opportunities away.

A couple quick examples. One of my most valued connections & friends (the very talented Mike Curtis) I met because of personal branding. He was teaching at the UX bootcamp Dev Mountain at the time and was looking for some experience designers and design leaders to come to answer questions during a special Q&A event. He posted on a Slack channel we both happened to be a part of, & I replied that I would be willing to come if he still needed people. The way he tells it, before replying to me he checked out my LinkedIn, he read a couple articles I had written, etc. He could immediately tell that I would be a good fit for the questions many of the students had. Because I had been working on my personal branding and getting my ideas out in the open, he was able to tell that I was a fit.

P.S. If you want a fantastic example of personal branding, go check out Mike’s own work at https://mikewcurtis.medium.com/.

Let me share one other example. Over a period of 3 years, I had been searching for a UX leadership role at a Fortune 500 company. I interviewed at Facebook, Google (twice), Dropbox, Intuit, Honeywell, The Home Depot (twice), USAA, Adobe, LinkedIn, Philips, Amazon, Dell, IBM, and American Airlines. At many of these companies I made it to the last round only to have it not work out in the end. I was becoming quite frustrated.

Then one day, a friend I had known when I lived in Brazil 20 years ago (who was a Director of UX at Target) messaged me telling me that he had read my article “Business for Designers” and had used it as the material of a session with his team only to realize after the fact that he knew the author! He then reached out to me to let me know that he had shared my profile with one of his counterparts who was looking to hire a Sr. UX Manager and asked if I’d be open to having a conversation. I was, and the rest is history. I have a job I love at Target & as of the writing of this article, I am the only Sr. UX Manager to ever be hired externally. I say that not to boast, but to show the power of personal branding. I sincerely doubt, that had I simply applied for the role out of the blue, that I would have been selected for an interview.

Now, I want to be careful that you don’t misunderstand. I have been working on personal branding for years (and there are admittedly others who are much better at it than I). Just like networking, it doesn’t work overnight. You have to continually iterate, get feedback, and continue to build your voice. However, if you will dedicate yourself to it, I can promise you that somehow, someday you will see results from it, and the fantastic thing is that it’s not just about getting a new job. It can help you immensely at your current job as well. (I recently had a couple candidates tell me they applied for a job I’m hiring for simply because some of my content really resonated with them.) It can help you get promotions, can help you be viewed as a leader within your organization, it can open doors for speaking engagements and much, much more.

If you’re like I was when I first became enamored with the idea of personal branding, you’re excited to get started but might not know how. Here are a few resources I would highly recommend to give you a boost:

• The Crazy One podcast by Stephen Gates (especially episodes 6 & 7)
• Forever Employable: How to Stop Looking for Work and Let Your Next Job Find You by Jeff Gothelf (book)
• 10 Golden Rules of Personal Branding by Goldie Chan (article)
• The Definitive Guide to Personal Branding (article & website)

LESSON #23: Use the UX process on your resume & portfolio.

I went far too long without using the UX process on my own resume and portfolio. You would be shocked at how many of us designers make that mistake. It is by far the biggest and most common mistake I see with both portfolios and resumes when hiring for UX roles.

I still remember watching a talk (way later in my UX career than I’d like to admit) on the topic and it hitting me like a ton of bricks. I wasn’t doing discovery & research. I wasn’t considering who the target audience of my resume and portfolio were. I wasn’t learning about their circumstances. I wasn’t iterating. I wasn’t testing. I wasn’t problem solving. I had no idea what the difference was between what a sourcer, recruiter, & hiring manager look for. I didn’t know how their motivations differed. I do now, and it’s made all the difference in the world.

If you aren’t using the UX process on your resume and portfolio, you are shooting yourself in the foot before you even begin the race. We know how to effectively solve problems. We know how to research. We know how to iterate and test and iterate some more, but often we don’t use those skills on our own portfolio — and even less of us do it with our resume.

If you fall into this bucket, stop what you’re doing and start using the UX process on the “product of you” today. This one thing alone will have enormous impact on your ability to get interviews at companies at which you want to work.

Why is this such a big deal? Most resumes & portfolios look identical. They read identical. Their creators “UX Process” is identical. You could literally swap one name for another and most portfolios and resumes would remain 90% accurate. When you take personal branding serious, however, your marketing becomes personal to you. It can’t be duplicated. When a hiring manager comes across a resume or portfolio like that, it’s an instant interview.

LESSON #24: Be strategic about case studies both in your portfolio & in interviews.

I struggled for a LONG time with portfolio reviews during interviews. I knew how UX hiring managers like to understand the how & why behind the what, but the problem I struggled with is how to take a 6–9 month project and summarize the what, how, & why into just a few minute summary. I almost always ended up sharing too much info and going over the allotted time. It not only was long, it was ineffective. Invariably, trying to cover too much resulted in running out of time to cover (or bring desired emphasis) to more important topics.

Through the kindness of trusted confidants, experimentation, and a tireless determination to become better at interviewing & job seeking, there are 3 key pieces of advice I’d share if you feel like you get interviews but are struggling to land the jobs you really want.

1. Be strategic & focus on what you want an interviewer’s or portfolio viewer’s key takeaways to be.

So many of us take a chronological approach to presenting case studies. Often we even try to teach the reader/interviewer about the UX process along the way. Nearly everyone writes or presents case studies this way. The problem is that this is like hunting a duck with a machine gun, yet the vast majority of designers still do it.

Go rewatch a presentation from your favorite UX leader. They have a specific agenda — specific takeaways — in mind. Yes, they do share some background information and because great presenters use storytelling to make their presentations so it can feel chronological, but if you analyze those presentations closely you will find that they follow the rule of 3.

“Divide your message into three chunks. What are the benefits of your service? What are the main things you want the audience to walk away remembering? Most people don’t have the memory (or attention) to remember five or six main points; however, three is a number we are uniquely attuned to recall.

Steve Jobs was famous for using the Rule of Three in his presentations. In 2011, he described the iPad 2 as “thinner, lighter, and faster” than the first. These three adjectives were massively effective; they said everything the audience needed to know. It was much more successful than if he had announced ‘20 ways the iPad 2 is different from its predecessor.’”

— Scott Schwertly, “The Rule of Three for Presentations”

One thing that dramatically helped me improve my case study effectiveness in interviews was to break up the main idea I wanted to convey to my audience from each case study into 3 main points. Often this consisted of three key results we achieved, or 3 main skills this case study highlighted (catered to skills I know from my research that the employer is looking for). Then, tell the story of the project from that point of view. If it doesn’t prove one of your main 3 points, don’t share it.

For example, if one of my points were focused on showing the value of discovery research and how my insistence on including engineers in the research saved our project, I might say something like the following:

“On one project I worked on, we were trying to improve the amount of jobs that could be done the same day they were assigned. From a prior user interview we learned that we didn’t know as much about the users circumstances as we previously thought, so it was clear we needed to do a little observation. I insisted on bringing one of our senior engineers with me. This was met with a little hesitation, but I was able to make it happen.

During one of our ride alongs with a service worker, we learned that a particular field we were basing our scheduling algorithm on was almost always wrong and could not be relied upon. This was a connection only the engineer (with his knowledge of the code base) could have made. We also learned many other things that day that ended up resulting in not only a better user experience, but in achieving the business goal much more completely.

Had we not done the research and had the engineer not been present, our project almost certainly would have failed to increase same day jobs. As a result of our taking time to research, we saw an increase of same-day jobs by 37%.”

Notice that I only told enough of the story for them to understand the problem we were solving, prove my point, and what the result ended up being. It was focused on what I wanted the takeaway to be. Not a travel log.

2. Use the Star Method.

I discovered the Star Method many years ago when I was interviewing with a couple Fortune 50 companies who recommended it as part of their interview coaching sessions. It has been a game changer for me. I used to really struggle with how to summarize case studies of my work. Hiring managers wanted to understand “the messy middle” but I found that when I went into the messy middle there was just too much to cover. I almost always took longer than the time allotted. I’m certain I also bored my interviewers to death.

If you find yourself in a similar boat, I’d highly encourage you to give the Star Method a try. It has drastically helped me focus and narrow in on the most relevant details without sacrificing details on “the messy middle”.

You can check out this article for more details, but the basic idea is that you summarize your project into a 4-point arc using only 1–2 sentences per section. The outline goes like this:

1. SITUATION — set the stage. Give any basic background information needed to understand the context.
2. TASK—describe the problem you set out to solve and what your goal was in the situation.
3. ACTION—what action you took to solve the problem. What are the most important takeaways from the “messy middle” for this audience to understand.
4. RESULT—what results came from this project? Quantifiable metrics are great here. This is also a great place to summarize cultural impacts your work had.

You will not get it perfect at first. In fact, you will likely find that even trying to summarize, you will likely have a difficult time distilling each section into 1–2 sentences. Keep at it, though, and you will get much better. I’d recommend when you first start using the STAR method, to first write it down and practice reading it out loud. Do NOT just wing it as tempting as that might be. You need this to be second nature.

For example, here is an example of one of my first attempts:

Situation
In my previous role, I was put in charge of working with a strategic partner to add support for a new kind of towing job to our web & mobile dispatching platform.

Task
The goal was to help them increase the number of “same day” tows so they could better deliver on their Service-Level Agreements. As part of the request, we were asked to include their 93-step inventory form in our mobile app for the drivers to fill out before picking up each vehicle.

Action
I was concerned by the user experience ramifications this would introduce into our app so I scheduled an onsite visit for myself and one of our Senior Technical Architects to ride along with a few tow truck drivers and observe the process from beginning to end.

On these ride alongs, we made 2 key observations:

1. The inventory being filled out by drivers accounted for about 60% of the total time at a job site.
2. The lot attendants filled out the exact same inventory after the vehicle was delivered that the tow truck driver had just filled out.

When I inquired of our partner as to why they were asking for the inventory to be filled out twice, they responded that they wanted to make sure vehicles didn’t get damaged during loading/transport to the tow yard.

Result
Armed with this knowledge, I proposed that we solve their problem through adding damage reporting onto our robust photo-taking which already had geo-tagging capability. This would allow them to determine if additional damage had been caused en route without requiring drivers to spend an extra 5–7 minutes filling out a duplicate inventory. They agreed, upon the condition that we add 5 inventory fields that were important to be collected at the scene. Naturally we agreed. 5 is much better than 93.

This not only improved the user-experience of the tow truck drivers, but also resulted in:

• 23% increase in same day tows.
• Reduction in average pickup time from 9 minutes to under 4.
• Improved data accuracy and reporting.

The key was to show how eliminating frustration of the mobile app users would also help the Company achieve the outcome the business was already focused on. This would not have been possible without user research.

As you notice, 2 of the sections are much longer than 1–2 sentences. Still, I could clearly describe the situation, task, action, and result in just a few short minutes. This was a MAJOR improvement over prior attempts. As you get used to describing projects in this way, it will get much easier.

3. Make the key takeaways really easy to find.

Once you have your key takeaways defined, make them REALLY easy to find. This includes your resume & portfolio in addition to interview answers.

One way I’ve found extremely valuable to do this is to summarize case studies using the STAR method on your portfolio. To see an example, check out my portfolio landing page. On my resume, I strip this down to a summary of “Task” & “Results” sections of key projects. An example of this can also be seen on my portfolio site.

Since I took that approach I have received LOTS of compliments from recruiters. Many don’t even click through to the detailed case studies. (They get all the information they need to want to interview me just from the landing page). My application to interview ratio has skyrocketed since I took this approach. Summarizing succinctly and calling out results you achieved makes recruiters and hiring managers want to speak with you (which is the one and only goal of a portfolio or resume.)

4. Choose the right length, for the right situation.

Recruiters and hiring managers are extremely busy people. They don’t have time to read a 10 to 20 minute case study. Accordingly you need to help them find the most relevant information in the least amount of time.

All use cases of a case study are not made equal, either. There are 3 main reasons someone would review your portfolio. It is important to understand and address each one.

1. IS THIS PERSON WORTH LEARNING ABOUT?
   When a sourcer, recruiter, or hiring manager is screening resumes and portfolios, they are essentially just scanning quickly to determine if you are a good enough fit to justify more than a 10-second glance. You need to grab their interest quickly and help them find the most relevant case study to review.
2. IS THIS PERSON WORTH INTERVIEWING?
   Once you have convinced them to actually read a case study, they likely are only going to skim it. At this stage their question revolves around whether you will be someone worth talking to and/or presenting to the hiring manager. Do you have relevant experience? Do you know how to solve problems? Do you understand before you solve, etc. Do you have relevant or comparable experience? If they can find the answer to these questions quickly by skimming, you are very likely to get an interview.
3. IS THIS PERSON WORTH HIRING?
   You have already proven yourself a good enough fit to interview. Most likely at this stage the hiring manager is taking a 2nd look at your portfolio to look for evidence of how great a fit you would be (almost certainly after having spoken with you). They are probably trying to decide between 2 great candidates and reviewing the case study you presented for a final time. This is where they DO care about details. Maybe something was unclear from the interviews and they are looking for evidence that you’re the right one to hire.

To be the most successful, you need to attract the right employers. To do that you need to provide a good experience for users of all 3 of these use cases. I have found that the best way to do that is to deliver a 10-second, 1-minute, and 10-minute experience.

Your 10 second experience should focus on grabbing their interest quickly and make them want to learn more. To do this, you need to answer the question: “Why should I care” or “How will this person help me solve my company’s problems.

Your 1 minute experience should focus on landing the interview. Here your goal is making your case study scannable. You can assume they’ve already decided which case study they want to review. If someone spends 60 seconds scanning your case study, will they get the takeaways you want them to? (Hint: this is worth user testing).

Your 10-minute experience is what most of us typically focus on when writing case studies. The key here is to focus on including ONLY the detail needed to convey the details of your KEY TAKEAWAYS. Think of this as a more in-depth, show-and-tell version of your 10 second “STAR Method” summary. Resist the temptation to make this a chronological diary of everything you did on the project. Your 10-minute case study experience should still revolve around 3–4 key takeaways from your project. Leave them wanting to learn more.

LESSON #25: Networking always trumps ‘apply and wait’.

The harsh reality is that you have less than a 2% chance of landing an interview, and less than a 0.1% chance of actually landing the job if all you do is apply online and wait. You need to do more.

This is why — at the bare minimum — you have to get your application in front of a human’s eyes via networking. If you can get someone at the company to follow up with a recruiter or hiring manager and ask them to check the system for a particular application, your chances go up dramatically. If you can actually secure a referral from someone at the company your chances go up even more.

NOTE: it should be noted, however, that blindly sending a message to someone you’ve never met or talked with is NOT networking and will not increase your chances much. If you want the reap the benefits networking can give, you have to be willing to put in the work to get to know others, have stimulating conversations, do what you can to help them along their journey, etc.

That said, you may not have a deep connection or have worked closely with someone who works at the company you are interested in. What do you do then?

One of my favorite approaches in this scenario is to find someone in the local design community or in your LinkedIn network who works at the company (or who knows someone who works at the company) you are interested in. Again, make sure they actually know who you are or at least have interacted with you enough to recognize you. (No cold contacts). Then you send them a message similar to this:

Hi __________,

I saw [company] is hiring for a [insert job req ID or URL to job posting]. I’m very interested in the role and sent in my application. I know that [company] likely gets hundreds of applications for jobs like this, so I was curious if you would be willing to reach out to the recruiting team or hiring manager to make them aware of my application?

I recognize that we haven’t worked together closely yet, so you probably can’t provide an actual referral, but would you at least be willing to help me get my resume & portfolio in front of a human?

If you wouldn’t mind, I would greatly appreciate your help.

I have had very, very few people turn down a request like this, and it makes a WORLD of difference. It could be the difference between your application getting screened out (or worse, never even reviewed), and being called in for an interview.

If you want to take your effectiveness to an even greater level, my recommendation is that you forget about optimizing your resume for computers altogether and optimize it for the user experience of reading a resume (then use the above process to get it in front of a human). Ever since I’ve taken this approach, my interview to application rate has been well over 60% (4X what it was before).

I have written about UX-centered resumes before so I won’t rehash all the points here, but if you’re interested to learn about my approach and why it is so effective, check out my article A Case for Human-Centered Resumes.

LESSON #26: When looking for a job, don’t settle. Period.

Probably the biggest mistake I’ve made in my career so far is settling for any job I can land. I get it. There are situations where you feel desperate for anything. I’ve been there, too. I’ve been burned out. I’ve been laid off and without work while my family depended on me to provide for them (twice). I’ve worked in toxic environments where my health, sanity, and even my family relationships were affected. I’ve worked for companies that I loved but where progression toward my career goals came to a complete halt.

I have settled for roles I knew would not be a fit (more than once) due to these circumstances. Yet, something I have learned through all of these experiences is that it is never worth it.

We talk a lot in this industry about “Personal Branding”. Sometimes we make it out to be this magic solution that will help you attract your dream companies…and it does have that potential. However, perhaps one of the biggest Job Seeking lessons I’ve learned the hard way is that if you want to attract your dream companies, you have to be willing to say “no” to the wrong ones. You have to have a Career Vision and drive towards it. You have to know what the milestones should be. Then you have to say NO to everything else.

“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas.”

— Steve Jobs

Over the last 20 years I’ve been a designer and design leader, I’ve learned that if you really want to be happy, fulfilled, successful (whatever that means to you), and progressing towards your goals, you have to be relentless in not settling.

I know I’m not the only one that has this problem. I talk to designers all the time who have no idea what their career goals even are. When they look for a job, it’s basically “whichever company will hire me first for a good salary”. If you take that approach for too long, it can actually destroy your career prospects.

If you’re too early in your career to know what you’re long term career goals are, that’s fine. But make a decision on something new you’d like to learn, industry you’d like to explore, or experience you’d like to gain and go after that. You can also focus on the kind of manager or company size or role you’d like and go after it.

As you gain more experience, be intentional about your career goals even if they’re currently out of reach. For example, my career vision is to join a vision-driven, mid-size software company with an already established UX team and help scale their design practice (and company). Until recently, I worked mainly for small companies. I had never worked anywhere with more designers than 5 and much of the time I was the sole designer. When I became a UX leader, I was mostly leading small teams.

Who would hire someone with experience leading only small teams to help scale their design practice? It would be tough. Anyone hiring a VP of UX to scale their design org would want someone who had worked at a large company. About a year ago, I was working with a company I loved but where I was unlikely to get the kind of experience I needed to achieve my career goals. I loved my boss. I loved my coworkers. I loved the problems we were solving. I love our executive team. But it would have been years before I started gaining the kind of experience I need to achieve my career goals.

So when the opportunity arose to join Target, I jumped on it. While I was casually looking for something more aligned with my career goals I had many opportunities come up. Some even were to join companies I had a lot of respect for. Yet none of them would put me in any better spot to achieve my career goals in the future. So I turned them down.

Now I’m working for an incredible company with an inspiring vision, and am learning from amazing fellow design practitioners and leaders. It took me quite a while to find the right opportunity, but I finally did because I stopped settling.

LESSON #27: Job rejections are not (usually) about you.

One of the major lessons I wish I had understood better earlier on in my career was that job rejections are most frequently NOT about you. When you’re on the receiving end of a rejection, it seems personal—especially when you feel like you were perfect for the role. If you’re like me, you can even start to feel a sense of Imposter Syndrome after a few rejections.

Yet, I’ve been on the other side of the table long enough now to realize that when they tell you there was a candidate that was a better fit, that’s usually not a lie. Even if you seem like a fantastic candidate, there might be someone who is a better fit. My experience has been that when we hear “better fit” most of us think “more talented” when that is almost always not the case (especially if you make it to the final round).

I get it. Rejection is hard and immensely frustrating. I made it to the final round (flew out of state to interview) with Fortune 100 companies 12 times before being hired by Target. In almost every case I thought I was a great candidate. My background seemed to be the perfect fit…but it wasn’t from their perspective.

Then came Target. I not only got the job, but I am the first (and as of the time of writing, the only) UX leader to ever be hired from the outside at Target. I’ve worked here for almost a year and am still humbled by that fact. Yet, after joining I could see exactly why my unique combination of experience and skills were perfect for this role and team. I don’t tell you this to boast (part of me still doesn’t believe it), but to show that the reason I was hired here and wasn’t hired at all those other great companies came down to the right combination of experience and passion.

So, yes, work on your interviewing skills, your portfolio, your craft, your soft skills, etc., but if you don’t get the job PLEASE don’t get down on yourself. Don’t question your worth. Don’t give up. Keep going. Keep searching and don’t settle. You will find the role for which you’re the ideal fit, too.

LESSON #28: Show how you learn, not only how you solve.

Jared M. Spool wrote a fantastic article on this here, but one huge mistake many of us make early in our careers is that we don’t showcase how we learn in our portfolios. We often want to come across as more knowledgable than we are, but this is a mistake. Here’s an excerpt from Jared’s great article on the topic:

A mistake I see folks make is when they focus on the designs they’ve created. For UX professionals just starting out, these are school or side projects. For folks looking for their next job, they are the work projects from their first or second position.

Don’t get me wrong. When I look at these things, they always look great. As far as I can tell, they work great. They are good, solid designs.

However, that’s not what smart hiring managers care about.

What’s preventing them from getting that gig or interview is that the hiring managers can’t see their vector of growth. The vector of growth tells a hiring manager how they’re progressing at growing into an amazing UX professional.

You see, these early-career folks are not telling their story right. The hiring manager doesn’t care about their designs, because, let’s face it, those designs aren’t that impressive.

If they won’t impress managers with their designs, what will impress them? The answer: How they learned to do those designs.

—Jared Spool

The reason for this is that when I’m interviewing someone, I am looking for evidence that they can and will solve the problems I and my team are facing (not the problems they solved at their previous company). In a senior-level designer I look for comparable experience of what they’ve done in the past. With someone early in their career, though, that’s harder to do. So I get that confidence that they can succeed through seeing how you approached a situation where you didn’t know what to do and how you got unstuck and what you learned from the experience.

Having the confidence that you can learn, progress, and grow both on your own and with mentoring is vital. Showing how you learn and what you would do better next time also shows humility and an eagerness to continually improve.

So if you aren’t already showcasing how you learn and what you would do differently next time, you are shooting yourself in the foot.

LESSON #29: ‘Making senior (or manager, etc)’ too soon can actually harm your career.

This is a tough one to hear. Your natural reaction will be to resist it. We all have career goals and aspirations. Getting promoted is a feeling of validation. It feels good. For many, having that “Senior” title feels like they’ve finally joined the ranks of “top talent”. This is a flavor of “Imposter Syndrome” that is opposite of what we normally think of. It’s the idea that you “deserve” a title or responsibilities you truly are not ready for.

Yet progressing too fast can actually harm you in the long term. This is especially true if you work at a small company. No matter how strong the temptation, do not take an inflated title. It takes time to muster the experience necessary to earn promotions.

So what is the harm? How does this actually hold you back? If someone is willing to give me a Senior or Director title, shouldn’t I take it?

The biggest problem with taking a title you haven’t yet earned is that if you are let go for whatever reason, it can make it hard to find another job. Based on your resume, people will think you perform at that same level, but when they interview you they will be able to tell that you’re not actually experienced enough for that level (so you won’t land the job). I’ve seen this happen countless times, and it’s very sad.

TO BE CLEAR: I am NOT saying you shouldn’t take a role that will cause you to stretch. That is how we all grow. What I AM saying is to forget about the title. Most promotions come when you have proven that you can do the work at the level. For example, if you are a mid-level designer and are influencing stakeholders, mentoring younger designers, taking on (and delivering great results) on very complex projects, and evangelizing UX across your company, then you are very likely to be promoted. You have earned that title.

On the flip side, it takes time to learn enough to be able to perform well at that level. Another quote from Jared Spool:

It takes years to learn how to produce impressive work. [Early career UXers] haven’t put in those years of hard work yet. They will. I have every confidence that they will. Just like I have every confidence you will. Someday.

— Jared Spool

It really isn’t about the # of years. Some progress faster than others. Not all “years of experience” are equal. Yet, you can’t progress from bootcamp-grad to UX Director in just a couple years. You need the experience of seeing different approaches, of experimenting and failing, and of succeeding to give you the experience to draw from to do the work of a Senior, Lead, Manager, or Director. Until you actually have that experience, taking one of those titles will do you more harm than good.

So what should you do instead?

I have 3 recommendations:

1. Focus on the work. Forget about the titles. Focus on the work and delivering exceptional outcomes. Too often, we UXers focus on titles or how impressive our portfolio will be instead of actually improving users’ lives. If you focus on delivering exceptional outcomes, and increasing the UX Maturity of your company, the titles and recognition will come.
2. Identify the Why. Challenge yourself to sit down and define why you want a higher title. Be honest with yourself. Is it really about the title? Or are there other reasons? Do you want more flexibility, scope, or autonomy than you now have? Do you want to mentor others more, or influence strategy? Is it more pay? Depending on the answer to those questions, there may actually be other ways to achieve those goals without waiting for a new title. Plus, the kind of self-awareness that comes from an exercise like this will only add to your experience and ability to perform the duties of higher level roles in the future.
3. Learn & Imitate. Learn what skills, experience, and responsibilities those at the next level typically have and seek out opportunities to develop those skills. Ask your leader. Review job descriptions of higher-level roles. Curate a list of things you can be doing now to become a Lead rather than just asking for the title. Ask to sit in as an observer on interviews for higher level roles. Then develop the skills you see demonstrated.

LESSON #30: Pay it forward

Probably one of the most important lessons I’ve learned in my career is to Pay It Forward. Everyone has something they can do to help others. Even if you’re in your first UX job you can help others looking to break into the field. Everyone has something to give and everyone has something to learn.

Sure Jeremy, you say, I get that’s important, but why is it a “Job Seeking” lesson? Great question. I’m glad you asked.

Call it Karma, blessings from a higher power, or what you will, but I have found that those who help others just naturally have good things come to them. People remember how you treated them, and when a need arises for which you could be a good fit they are more likely to remember you if you were kind & helped them along their path.

The irony of this concept is that if you help someone because you want something in return, you are almost certain to not receive any return, but if you develop a habit of paying it forward and helping others along their path to repay some small measure of those that helped you, someday somehow you will receive it back when you’re least expecting it. This is the purest essence of networking which as stated earlier is the most effective way to job seek.

Plus, it’s just the right thing to do. Be the kind of person that sends the elevator back down.

Have something to add? Please leave a comment on the article or hit me up on LinkedIn or Twitter. Need a UX Leader to help guide your company’s UX Maturity? Need a speaker for your event? Check out my portfolio or contact me.

UX lessons I wish I had learned earlier: Job Searching was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

They say “hindsight is 20/20”. It’s very true. 10 years ago I made the switch from graphic design to user experience after a 10 year stint working for print shops & manufacturing environments. It has been an incredible journey so far, but there are many things I wished I had learned earlier than I did. These are the top 30. I share them with you in the hope that you can avoid many pitfalls I encountered along the way and become even more effective at improving users’ lives than I am. For when any one of us improves, we all win.

I have broken these lessons into 3 categories: Craft, Working with Stakeholders, and Job Searching. This is Part 2 of a 3-part series. In this article, I will focus on Working with Stakeholders. If you missed Part 1 about UX Craft, you can find it here.

Working with Stakeholders

The fact that “working with stakeholders” is one of the main themes of lessons I’ve learned should speak volumes by itself. I observe many designers “staying in their own lane” so to speak. We spend a lot of time and energy on user research but forget that our stakeholders are our users too. I’ve lost track of how many times I’ve heard “________ just doesn’t ‘get’ UX”.

Many of us (myself included) are often guilty of preaching collaboration outwardly when our hearts are not really in it. Instead of viewing our stakeholders and senior leadership in a negative light, we should use our research and empathy skills to attempt to understand what is top of mind for them, and find ways we can alleviate their pain.

What you will find, is that when you have an outward mindset with stakeholders in addition to users, shipping great outcomes will get much easier. Believe me I know that it’s not always easy, but it’s absolutely worth the effort. This is probably the group of lessons that have made the most direct impact on my ability to be successful as a designer and design leader.

Here are the lessons I’ve learned that have made all the difference in the world in my ability to work better with stakeholders.

LESSON # 11: Your job is to SHIP outcomes that improve users’ lives not design them (stakeholders are your users too).

As I touched on lightly in Part 1, your job as a designer is to ship experiences not just design them. Changing your mental model to realize that working with stakeholders is not blocking your job—it IS your job—can be liberating. It puts (more) control in your own hands.

This was not something I always understood. Early in my career I experienced my fair share of executive ‘swoop and poop’. I didn’t know what to do about it. It seemed stakeholders and leaders would always come to a review, give me very detailed feedback of how to change the design (without much context), and then move on to go solve another problem elsewhere.

Over time I learned that this was just as much my fault as anyone else’s. Here are some of the reasons this type of micromanagement happens:

1. Designers are perceived to not understand the problem well enough
2. Executives don’t understand how solutions will solve THEIR (the company’s) problems. Too often, designers evangelize in terms of UX jargon, not the language of business (lack of shared understanding).
3. A problem to solve was not defined well enough to start with and does not contain clear success metrics.

At its core, this stems from lack of communication & trust. Most leaders have many things on their plate. They don’t WANT to be in designers business. Everyone wants a good outcome. Often, though, leaders become worried about the progress and whether the direction things are headed in will achieve the desired result. Thus, swoop and poop.

I wrote an entire article about this lesson you can check out here, but the core solution is helping stakeholders and leaders to view you and your fellow UXers as strategic partners rather than production workers. Many of the lessons that follow in this article can really help with this.

If we want to be user experience designers, we have to do more than just spend our days designing interfaces. We have to be willing to dig in and solve the bigger issues that affect the user experience. Designer Mike Monteiro summarized this lesson perfectly when he said:

“Walt Disney created user experiences. You create user interfaces.”

-Mike Monteiro

We have to start viewing it as our job to ship great experiences, doing whatever is necessary to improve users lives—and a huge part of that is working with stakeholders.

LESSON # 12: Exploring multiple design directions solves a myriad of ‘political’ problems.

One of the easiest, quickest, and most effective ways to help your business partners and stakeholders to start viewing you as a strategic partner rather than an order taker is to explore multiple design directions with everything you do.

Never, EVER, present only one idea to a team or group of stakeholders. Why? Because then the conversation becomes “Yes vs. No”. When you present 2 or 3 different directions for feedback, on the other hand, the conversation becomes “which parts of each of these options do we like best?”

It is flat out unbelievable how many problems this simple strategy alone can solve. In addition to shifting the conversation onto the work instead of permission to proceed, presenting multiple ideas also show stakeholders that you explore multiple angles of an idea. Over time, this instills trust that you will find the right solution and stakeholders start to step in to provide solutions less and less. It also has the alternate benefit of helping make your design better and fall in love with individual solutions more. Great designers fall in love with problems, not solutions. This strategy is a very big help with keeping you problem-focused.

The best news is that you can start doing this (and seeing results from this approach) today.

LESSON # 13: Evangelize your successes all the way to the top

To illustrate a lesson, let me share an experience I had.

I learned this lesson just after my transition into UX Management. had been tasked with establishing a UX practice at a startup that had been around for nearly 10 years but never had anyone with UX expertise. As part of that initiative, I was attempting to establish user research as a regular part of our process. The only problem was that most of our customers were not local. I and my team did phone interviews and Zoom meetings, but we needed more contextual knowledge of our users. We had done many things including shown value of the research we could do, make business cases, and use data in our pitches. We even had set up a “Design Trust” time when anyone in the company could come and see our in progress design work and offer feedback. The problem was that we were running into resource constraints and were having a hard time getting budget approved to go see customers out of state.

At this same time, one of my direct reports—who was a mid-level designer—took the initiative to schedule a meeting with our CEO. She asked him about his vision, how he got into this business, and how he wanted to improve our customers’ lives. She showcased her work and what she was doing to make sure her work translated into outcomes to help make lives better.

It REALLY resonated with him. He shared parts of his vision with her that he hadn’t shared with anyone. Directly after the meeting he sent me an email about how impressed he was.

Fast forward a few weeks and I was presenting about a recent user research project at our Design Trust. Because of this meeting with my team member, our CEO decided to come (first time he had made it). He even offered to buy lunch for anyone at the company who showed up. (We had a good showing that day as you might imagine.) The presentation went really well and immediately after our presentation about getting out of the building to observe customers and summarizing our learnings, the CEO got up and told the entire company he wanted EVERYONE to do this kind of thing and set up a budget specifically for the purpose. It was a huge win!

The funny thing is I had been doing similar things with some of the directors at the company for weeks. I hadn’t wanted to bother the CEO. He had been traveling a lot and I figured he had more important things to be dealing with.

What I learned from this team member of mine was that you shouldn’t ever be intimidated by anyone. Evangelize your work all the way up the chain if you need to. You never need permission to get to know people and do the right thing. Senior leaders love being exposed to those with “boots on the ground” interacting with users and enacting the visions they define. They might not have time to talk with EVERYONE in the company individually, but they love the opportunity. So if you take the initiative to keep them up to date and ask them how YOU can help THEM, they are usually very willing.

So if you’ve been evangelizing your work and not seeing much success so far, keep going. Sometimes it just takes some proactive empathy-building with a different leader—even if they’re the CEO.

LESSON # 14: Small batch improvements are for organization UX maturity, not just products.

One of the issues many of us face (similar to the one I described in lesson 13) is running into road blocks or resource constraints when trying to pitch a solution on how to improve users’ lives. As a result, most designers learn—eventually—that making improvements in small batches tends to make things much easier to get approved and to make it into users’ hands. It reduces risk, which makes it much easier for leaders to say “yes” and also easier for us to learn and make adjustments along the way.

Great. That makes sense. We got it. We embrace the small batch mindset.

The trouble is that when we start trying to make cultural improvements, we forget all about the small batch concept. We expect change to be immediate and when it’s not, we get discouraged.

No change happens overnight, and if you try to force it you’ll end up failing. There are 2 things I’ve learned to do when I find myself falling into this trap:

1. CREATE A ROADMAP OF CULTURAL IMPROVEMENTS
   Prioritize and create a plan of small batch cultural improvements you can make. You can think of these as milestones. Learn to design cultural shifts in smaller steps. For example, let’s say you’re trying to establish cross functional teams where previously UX, Product, and Engineering rarely collaborated. A couple small batches you could try include getting those with different roles to sit by each other, or establishing a Working Agreement / Team Charter. Once you achieve that, then move onto something else.
2. HAVE A RETROSPECTIVE WITH YOURSELF
   Many times progress seems slow because you wish it were faster. Yet, every so often (I recommend at least once a quarter), it’s extremely valuable either as a team or individually to take time to look back and appreciate how far you’ve come. What results have you achieved? How has that impacted the work? What is next? It can really help you appreciate the progress you HAVE made and keep you motivated to keep going.

LESSON # 15: UX evangelization isn’t about convincing anyone to do anything, it’s about showing people how your work can solve the problems they already care about.

Some years ago while I was dealing with some pretty tough resistance from difficult stakeholders, I ran across an article by Jared M. Spool called Why I can’t convince executives to invest in UX (and neither can you). It was one of those monumental moments and one that would forever shape the rest of my career. (Thank you Jared).

In the article, Jared talks about how even he can’t convince executives to invest in a problem (user experience pain points) they don’t already care about—and he’s spot on. I love this analogy he shares:

Have you ever met a smoker? Of course you have. Have you ever met a smoker who didn’t know the harmful effects of smoking? I bet not. Every smoker I know is well aware of what smoking does to their bodies, yet they continue to smoke. There are physical, cultural, and behavioral forces that make it hard to quit.

It’s the same with executives. Neither I, you, nor anybody else can convince an executive to invest in user experience.

A generic presentation about how Apple or some other company has a great user experience program (or worse, a presentation showing all the bad user experiences in the world), won’t convince anyone of doing anything different.

—Jared Spool, “Why I Can’t Convince Executives to Invest in UX (and neither can you”

Not even metrics are effective at “proving” to executives that they should invest more in UX. Why? They view the world through their own lens. We have a term for that in UX: Mental Model. People view their world through their own combination of experiences, views, & circumstances. That lens is difficult (sometimes even impossible) to change.

So what can you do, then?

If you want the aid of stakeholders (and especially executives) you have to start to see the world as they do. We call that ‘empathy’. Most UX Designers and Researchers are great at doing that with customers, but far too often we forget to apply those same skills with stakeholders.

There are ALREADY many problems & pain points that your stakeholders are focused on solving and that keep them up at night. The secret to getting stakeholders to support UX is to:

1. Learn what it is they are most focused on
2. Show them how UX can help solve their problem.

By understanding and helping them, you get their attention and a chance to demonstrate the value of UX. Once you open their eyes a bit by solving their problem, they become much more open to helping you solve other problems.

If there is 1 lesson I wish I could teach every single new designer, it is this one. Stop trying to convince stakeholders to invest in your problems. People feel invested in what they’re a part of. Most leaders are so busy that asking them to abandon their goals to help with yours is a waste of time, until you help them make your goals their goals as well.

One other resource I’d recommend if you’re interested in this topic is the book “User Experience Revolution: A practical battle plan for placing the user at the heart of your business.” by Paul Boag. It discusses many related ideas in depth and offers very practical advice.

LESSON # 16: UX Metrics are about much more than a score.

Many of us find ourselves in a dilemma. Our leaders are very focused on metrics and we want to help them focus more on user experience, but most usability metrics most leaders are familiar with (Net Promoter Score, System Usability Score, and all the rest) are completely ineffective at helping you actually improve your products—and they make horrible OKRs or annual goals. If this surprises you or would like to understand more about why this is the case, I invite you to read The Myth Of the Grand Unified UX Metric by Jared M. Spool and Is it time we move beyond the NPS to measure user experience? by Nikki Anderson. There are many, many other resources on the topic as well.

So if we can’t use the most predominant UX Metrics in the industry, what should we use?

To answer that question, it helps to understand that there are 2 different kinds of metrics. There are reporting metrics and persuasive ux metrics. Reporting Metrics are the kind of metrics cited above. They help us keep tabs on progress and remain the same month after month, year after year. They allow us to make month-over-month and year-over-year comparisons. These are the metrics on which most companies base their definitions of progress.

That is fine when you’re talking about new sales, total revenue, or profitability metrics such as EBITDA. The problem with using reporting metrics as usability metrics is that true usability is much more difficult to measure, and almost always depends on the individual circumstances of a project.

That is where Persuasive UX Metrics come in. Persuasive UX Metrics are things like UX Outcomes or Success Metrics that are unique to a particular problem a specific team is looking to solve. For example, let’s say you work on a product that schedules and manages the furniture delivery process. You’ve noticed that adding & managing inventory is extremely painful. Your support staff are getting tons of calls and your inventory counts are often off causing a large amount of “we’re sorry this product is no longer available” emails. A great experience metric for that might be # of support calls or # of refunds issued due to inventory management concerns. The drastic reduction in support calls and refunds would show a better experience (and give you an outcome to strive for), but that is unique to your product, your situation.

Another example are things like # of errors served up, or # of hours the team is spending monthly with customers, # of registrations completed without using help documentation, etc.

It’s not that we shouldn’t use reporting metrics. We should. They give us a pulse on our product, and more importantly, programs like NPS and SUS frequently come with qualitative responses that can give you opportunities to reach out to your customers to learn more. But if we truly want to evaluate —and improve—the experiences we deliver, we need to be willing to do the legwork to utilize circumstance-focused persuasive metrics as well.

The caveat in all of this is that it IS work. Many of the best persuasive metrics are not easily automated. You have to understand the circumstances of your customers to be able to choose the right metrics. Yet, when you do the work to develop truly persuasive and actionable metrics, the impact to your success is immense.

LESSON # 17: Inclusive design is a super power.

As discussed above, people support what they feel a part of. It is incredible what just bringing people along in your process can do. Don’t ask permission, try to convince anyone to do things inclusively, or wait for an official directive from management. Just start working more collaboratively and my experience has been that people will follow you. Do a brainstorming session with the entire group, invite engineers to offsite customer visits, move your desk next to the product owner and/or engineers, check in regularly with engineers that are implementing your designs. When it comes to working collaboratively, ask forgiveness not permission.

This lesson alone will solve SO MANY of your problems in working with stakeholders. When a designer sits next to an engineer and sees how hard they work to implement a design in a particular way or pull in data from 7 different sources then join it and format it to get it to display how you wanted, they will be much more understanding the next time an engineer asks if approaching the solution differently would be an option.

When an engineer sits through a usability test and sees the customer struggle and sweat through a task that seems easy to others, or sees how you approach a problem from 12 different angles before making a design decision, they will complain a lot less about having to go refactor the code they just built last month due to new learnings.

Collaboration leads to empathy. Empathy leads to understanding. Understanding leads to shared understanding. Share understanding leads to better relationships and delivering better user outcomes faster and with less stress. It may be a cliche, but teamwork truly does make ‘the dream work’. When shared understanding exists among all team members of user circumstances and pain points, teams truly can “sprint”.

One of my favorite teams I ever worked on wasn’t just “collaborative” in terms of joint brainstorming sessions, but was also collaborative in the sense that my front end engineering partner would often make proactive recommendations on my designs that almost always ended up being a better solution for our users problems. It truly was a ‘partnership’ and was only possible because we worked together, had mutual respect, and both thoroughly understood our users.

This kind of a relationship developed just because I took it as a given. I would bounce ideas off of him without asking permission first. It has absolutely amazed me how many companies aren’t more collaborative simply because everyone is so busy wondering if it’s ok to work that way that they never actually give it a try.

LESSON # 18: Avoid UX jargon & learn the language of business

Another problem I notice frequently (both in myself and others) is the tendency to use UX jargon with business partners and others. Terms like affordance, mental model, intuitive, gestural, UI, parallax, ideation, deliverable, synergy, IA, IxD, micro interactions, CX, VUI—and even ‘innovation’—don’t mean anything to your average VP or CEO. Or, if they do, they mean completely different things to everyone.

If you want to be more effective with stakeholders, stop describing your problems and successes using UX terminology. Use the language of business. Take a business class, go out of your way to attend product vision or financial results meetings. Know what OKRs or annual priorities are for the company and each major department in the company.

When I was 19, I lived in Brazil for 2 years and spent all day every day volunteering, teaching, and speaking with the people there. I still remember the early days of learning Portuguese. It was rough at first. I made a lot of mistakes. I once went to a grocery store and asked the associate if they had “shit milk” (leite de cocô) instead of “coconut milk” (leite de coco)! I can tell you I only made that particular mistake once!

Learning to understand & speak the language of business is no different. You will make mistakes. Your points might not come across right. But over time, you will get there, and once you can communicate with business leaders in language they can understand, your effectiveness will skyrocket.

Might I offer 2 pieces of practical advice to help you along your way if you struggle in working with stakeholders? It’s another tactic I learned in Brazil while learning Portuguese.

1. Make a list of all words and concepts you hear leaders using. If you don’t know what they are, write them down and look them up later. (Or ask them what they mean!)
   
   When you start to learn any new language, the hardest part is getting so you recognize the words that are coming out of people’s mouth. At first it can be tough to distinguish one word from another, but eventually you start to recognize the words—even if you don’t know the exact meaning.
2. Start trying to use the same words in the same way. One of the interesting things about foreign languages is that often words exist in one language that are difficult (or impossible) to translate. I found when I tried to translate words in my head as people were saying them, my brain had a hard time keeping up. My head hurt so bad when I got home at night! It was only after I gave up trying to translate and instead started imitating that I came to understand their meaning.
   
   My advice would be to do the same thing as you’re learning to speak Business. Start to use unfamiliar words and concepts the way you hear others using. Look them up. Ask people what they mean. Then start using them in your design pitches. (I’m sure someone on your Finance team would love to explain to you what EBITDA is!)

One final over-arching piece of advice before I leave this lesson. Find ways to quantify everything in your UX world to dollars and cents. If your company is like most, there are areas you are delivering a terrible experience to your customers. Rather than framing up your reports and pitches in business cases for proposed “investments”, show instead how the company is already paying costs for bad experiences.

Do the majority of support calls fall into a particular bucket? Are highly-paid employees performing tasks that someone with their education or background doesn’t really need to be doing? Can you tie attrition (customer’s leaving your company) to any particular usability flaw? Then calculate what the effect of that is on the bottom line. I find you get executives’ attention a lot more when you show how you could cut costs the company is already facing, rather than when you propose some future benefit if they approve an investment.

LESSON # 19: Solve customer needs in a way that improves users lives

I wrote about this one a little in Part 1, but it is so important—and so many designers struggle with it—that it bears repeating here. When customers and users are not the same person (as in SaaS environments), focus on taking your problem to solve from customers and do it in a way that benefits your users.

Let me share a quick example here that might help illustrate the concept.

I worked at a company that was trying to help a client get more service appointments done in a single day. They had requested we integrate our app with their APIs. The client had an app had an inventory that was done as part of the service. They requested that we support that inventory in our app—item for item. Our VP of Sales was adamant that we support that inventory. “Just do what the client is asking—after all they’re the ones writing the check” (it was a relationship valued in the millions which was huge for the small startup we were).

The problems that I had with the request, however, were:

1. It was super tedious for the users.
2. The exact same data was being re-entered elsewhere in the service journey.
3. We didn’t need all the fields entered because much of the data we already had.

So what I did was to go back to our VP and the senior leader at this client and say:

“Look. You’ve hired us to help you get more jobs done in a single day. Correct?”

“Correct.”

“Ok. Well the thing is, that this inventory form is super tedious for users and actually represents nearly 50% of the time spend at the service location. Plus this information is being re-entered elsewhere. By eliminating most or all of the inventory fields we’d be increasing retention of your service providers (another problem they were facing) & reduce the time per job which would increase jobs done in the same day.”

What ensued was a conversation on why they wanted the inventory to be filled out by service providers and a negotiation of other ways we could accomplish the same goal that would also improve the users’ lives. Both the business and the user were benefitted. We ended up not eliminating the inventory completely but reducing the total fields from 97 to 5.

A few important things about that story to highlight:

1. I had done the work to have a clear understanding of what the desire outcome was (rather than just the output).
2. I had done enough contextual research and knew the users’ circumstances well enough to bring an informed perspective to the table.
3. Having the above knowledge, I pushed back on 2 very senior leaders because I knew we could solve the problem in a better way.
4. That solution ended up solving the customer’s problem in a much better way than the original proposal while still improving the users’ lives.
5. I left the many, many other user pain points I observed which were irrelevant to the target outcome to be solved another day.

This last thing (#5) is key. Having the knowledge of those other pain points was super valuable, but I didn’t need to solve everything at once. That is a big mistake many designers make that is at the source of much of the conflict between UXers and their stakeholders. Sometimes—if it’s something I’m particularly passionate about or is particularly painful—I’ll create a key findings document and clearly label them as “in scope” or “out of scope”. I’ve also been known to create my own UX Roadmap and even add stories to the backlog just so I can give myself peace of mind that it’s been captured and won’t be lost.

LESSON # 20: UX Maturity is a journey

I have started UX practices for entire companies or teams 5 different times now. Needless to say, I’ve done my fair share of evangelizing UX and increasing UX Maturity. My purpose here is not to outline how that should be done (there are plenty of UX Maturity Models out there to read about if you’re interested in that topic). What I would like to discuss is that no matter what framework you use, you have to understand that cultural change takes time. It’s a journey.

Some of us designers get so frustrated with perceived lack of progress when we start trying to make cultural shifts, establishing user research, getting teams to collaborate more, helping people focus more on outcomes, and all the rest. It can feel overwhelming.

I have found that it helps to look at this as a long game—or as Simon Sinek calls it—an “infinite” game. We never will have “won”. We never will have “arrived”. Our company never will be completely “UX Mature”. So our strategies and behaviors need to reflect that.

One problem with many UX Maturity frameworks is that they take a “one size fits all” approach. Yet, I have found that each step in a ux maturity journey depends highly on dimensions such as company stage, team size, company culture, user circumstances, problems to solve, and many others. To quote one of my favorite UX leaders Joe Natoli: “There is no single correct way to do anything”.

As a result, no one can tell you exactly what will work for your team or company. Just like no one can tell you exactly which design pattern will work best in your product. The only way to learn is experimentation based on user research.

One thing that has helped me a lot in this process, though, is to create a culture roadmap. Identify milestones based on UX Maturity models that seem to resonate most with you. Then track your progress towards these milestones. For example, one of the first things I’ve found valuable in the past is getting discovery research to be a regular, integrated part of our process. So one metric I started to track was Customer Exposure Hours and the % of those hours that was “Cross-functional” (had more than just designers present in the session). Then I can look back over time and see progress. Which help me appreciate how far we’ve come.

Creating a roadmap also helps me realize that this is a journey, and keeps me focused on what is most important now, and what will come next.

Conclusion

I hope these lessons have been valuable to you. Many of these were hard won learnings and I’m still on the journey of getting better at most of them. Still, by focusing on working better with stakeholders, I am confident you can be even more effective at shipping great experiences and not just designing them.

Have something to add? Please leave a comment on the article or hit me up on LinkedIn or Twitter. Need a UX Leader to help guide your company’s UX Maturity? Need a speaker for your event? Check out my portfolio or contact me.

UX lessons I wish I had learned earlier: working with stakeholders was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

UX lessons I wish I had learned earlier: Craft

They say “hindsight is 20/20”. It’s very true. 10 years ago I made the switch from graphic design to user experience after a 10-year stint working for print shops & manufacturing environments. It has been an incredible journey so far, but there are many things I wished I had learned earlier than I did. These are the top 30. I share them with you in the hope that you can avoid many pitfalls I encountered along the way and become even more effective at improving users’ lives than I am. For when any one of us improves, we all win.

I have broken these lessons into 3 categories: Craft, Job Searching, and Working With Stakeholders. There are 10 lessons in each category. In this article, I will focus on Craft.

To craft is to exercise special skills in making something. “Craftsmen” often spend many years refining their craft. They put some of their soul into everything they do. In times past, often apprentices would work under “master craftsmen” to learn and practice their chose trade before venturing out on their own. This quote on craft I think captures the sentiment perfectly:

“I think ‘craft’ is a word that comes with some weight. All types of apprenticeships that existed before modernity show us that we should see our work as a reflection of ourself. If you work with special care toward detail, then you necessarily ought to see that work as craftsmanship. If the mix you’re describing in a margarita has a good portion of man hours, study, and consideration poured into it, then perhaps it should be recognized as a craft cocktail. However, it’s not just about whether the ingredients are all natural. I think ‘craft’ is a reference to the nature of the worker and the care put into it, not solely quality ingredients.”

—Kala Alaeye Danae Ellis

UX designers apply ‘craft’ to their work as well. We put many hours (sometimes hundreds of hours) attempting to understand users and improve their lives in specific ways that somehow will increase revenue, retention, profitability, or stickiness. We partner with many other people to do this. We work under many constraints. Every designer is distinct and puts their own unique mark on their work.

Here are the top 10 lessons relating to UX CRAFT I have learned in the last 2 decades.

LESSON #1: There is no single design process, only a UX toolbox

Everyone has to start somewhere, so when we teach UX we talk a lot about “the design process”. Many books outline steps as if design in the real world were still using the Waterfall framework. This causes many designers to struggle when they get into the real world and there isn’t time for some technique they learned in design school or used at their last company.

The truth, though, is that there is NO single ‘design process’. There are only tools & techniques. Great designers are familiar with dozens of different approaches and pull out the right tool for the right situation. If you stop viewing usability testing, or wireframes, or journey maps, or mental model diagrams, or user interviews, or affinity brainstorming, or high fidelity prototypes, etc as steps in a rigid process, your life, and effectiveness as a designer will dramatically improve.

Naturally, this is harder to teach which is why this approach is rarely taught in schools. Knowing which tool to pull out in which situation (and which to NOT pull out) takes some time, but you can start today. Look up a new technique with which you are unfamiliar and experiment with it. Then at the end of the project find another designer, stakeholder, or trusted confidant and do a post-mortem or retrospective. Identify what worked, what didn’t, and what you would change next time. Consider if the problem was with the tool or with the WAY you used the tool. (A hammer wouldn’t be very effective if you held it by the head instead of the hand — the same thing applies with UX tools).

You may not often use every single tool you learn. Yet, there ARE situations where certain tools are useful and others are not. Experimenting intentionally will help you learn the difference. If you need some suggestions of tools to get started with, here’s a great list of UX Method and Deliverables, User Research Methods, and Effective Brainstorming Techniques.

LESSON #2: Research is important, but it isn’t a big deal

So many new (and even seasoned) designers get stage fright on testing day. We work ourselves up into nervousness because we know that research is important. Yet most of us also present our work to our team members and other stakeholders frequently each week to get feedback. Research is no different. We’re just talking to people.

A lot of the shift needed is simply in the mental model. If you get nervous going into research sessions, just imagine that you’re talking to an old friend or a coworker over lunch. Prepare, but don’t make research into a ‘big deal’. It’s simply a conversation between friends. This is a simple concept, but its impact can’t be understated. It can impact how effectively and how often you conduct research. This lesson is particularly relevant if you—like me—consider yourself to be an introvert. (There are many introverted UX Designers and Researchers).

The other piece of advice I have to help with getting nervous before (or during) a research session is to do them on a regular basis. The less research is a ‘special occurrence’, the less of a big deal it will seem. Work up to having some interaction with customers weekly. Get people excited about coming to observe. Make it something to look forward to and be excited about.

LESSON #3: User Research is more about getting to know users than testing designs

When I first started out in UX (like most designers at the time), I thought that user research was about “testing” designs before putting them into production. I viewed Usability Testing as a kind of Quality Assurance to make sure we were solving user needs. There are a few problems with that:

1. You never are able to test a statistically significant portion of your users. (So it doesn’t serve as an effective ‘test’).
2. Even though we try to do research “early and often”, if we are viewing research as “testing”, it by very nature is reactive.
3. The true value of user research is about learning, not testing.

You’re probably going to want to push back against this idea. (I did at first, too). But if you remove your biases and look at it objectively, you’ll realize you already know it’s true.

Most of us UXers are always going on about developing shared understanding, learning from users, getting out of the building, the importance of observation and all the rest. Yet observing users purely within the frame of designs we just came up with causes us to miss the entire point.

Consider this quote by Jared M. Spool in his article A Fundamental Shift For Usability Testing:

“The real value of user research comes from increasing our understanding of who our users are. The product or service team should better understand our users with every study, every interview, and every interaction they have. They should constantly increase their understanding of what those users need and the contexts the users work within.

We can say that usability testing, at best, is a gateway drug. But if we focus on only finding problems and not learning more about our users, we’ll never get our teams hooked on the biggest value of user research.

Instead, we’ll lock them into this mindset that user research is just a variation of QA testing. That it’s about finding bugs, not about delivering better-designed products that truly meet users needs, whatever those needs are.

We need to move away from the problem-finding mindset. The teams that know everything possible about the users are the ones that deliver the best-designed products and services. That’s the mindset change we need.”

— Jared Spool, Founder of User Interface Engineering & Centre Center design school

I’ve found this to be true. The more you understand users, the better design decisions you can make and the less you need to ‘test’. That’s because you’re no longer making assumptions but making decisions on knowledge. That’s not to say you can ever stop doing user research because there’s always more to learn, but you can focus your research on being more and more proactive. It also dramatically improves cross-functional relationships because most usability problems get solved earlier and with more unity between cross-functional team members.

LESSON #4: You can’t (& don’t need to) research everything

One thing that causes a lot of us UXers stress when we first enter the workforce is the picture most colleges and bootcamps paint that research is vital. That IS true, research IS very important to delivering great experiences. We all have to understand the Jobs and Outcomes our customers are trying to achieve and the circumstances around them (as well as what is preventing them from achieving those outcomes).

The problem arises when we translate that to mean that we have to research everything. The idea that we can’t put any code into production without usability testing it, or start solving any problem without interviewing users is not compatible with the real business world. Not only that, but the cost of being wrong is not always the same. Some things can be tested in production. Others don’t even need to be tested because they’ve already been informed by existing data or research. As has already been stated, the true value of research is about proactively understanding customers anyways.

This results in situations where you start with a decently informed educated assumption of what will be impactful for customers. We should spend our time researching those things that, if we are wrong about, would cause our project to fail. Because of this, I have learned 2 important approaches whenever you have less time to do research than you would prefer.

Prioritize your research.

Rank each research goal by how certain/uncertain you already are about your assumptions AND/OR how big the impact would be if you turn out to be wrong. Reorder the list accordingly and decide what you have time for and what you don’t. If you don’t have time for something essential, then you have some talking points as to why you need more time. Most likely though, what falls off will be things you would like to research but that aren’t really critical at the end of the day. It has been my experience that if a tradeoff is needed, most often it’s the evaluative “testing” that ends up giving way to the discovery or “generative” research to inform your designs, (but I digress).

Create a Research Plan as the first step of any research project.

It always surprises me how many designers I meet that conduct their own research but have never actually sat down to create a formal research plan. A research plan has many benefits, including:

• Getting everyone on the team aligned on what you are setting out to learn, what are the questions you want to be answered, and what method will help you get there.
• Creates an objective you can compare against once your research is complete to show its value.
• Helps your research be much more focused which results in much deeper insights.
• Can even be a big help in securing financing for offsite research when needed.

The basic idea is to define the Objective, Assumptions/Questions, Method, Participants, Roles, Script, & Approach (and any budget needed if applicable). There are lots of resources available online about creating research plans, but if you would like an idea to get started, I describe the process I follow for creating user research plans and provide a 1-page Research Plan Template in my article here.

Contenting yourself with living in a world of time constraints with regard to research actually will unlock innovation rather than prohibit it. It will focus your research and make you much more effective. It also will help you make a good case to management in those situations where you really DO need more time for research. Maybe most importantly of all, it will help you be less stressed, happier, and more of a team player with your business partners.

LESSON #5: Balance business needs with user outcomes

Perhaps one of the biggest struggles many designers have is the apparent conflict between business needs and user outcomes. On one hand, business stakeholders (often sales, finance, or product leaders) bring up the perspective that we should focus on solving the needs of those paying the bills—our ‘customers’. The problem is that the approach they often take to this is just taking feature requests and signing an SOW (Statement Of Work) before anyone else is consulted. These are often very feature-focused rather than problem-focused.

On the other hand, we UXers usually take the perspective that we should be solving user pain points. That good UX is good business. We see hundreds of needed changes to make user lives better. The problem business leaders see with this is that often the users aren’t the ones paying the bills, so this approach doesn’t feel right to them.

So which perspective is most effective? In a word: both.

It IS absolutely possible to use customer needs to define the problems to solve, but do it in a way that improves user lives as well. This requires that business leaders define problems-to-solve (outcomes) for the team doing the work rather than feature-specific SOWs, and requires UXers to focus on improving user lives only so far as it will help achieve the desired outcome. (Everything else can wait for a future project.)

This is an entire article of its own—and I’ll be talking a little more about this in Part 2—but one other thing I’d like to mention here is that if you’re struggling with this problem, I’d encourage you to stop trying to convince stakeholders to help you solve your problems and start showing them how you can help them achieve their problems. Learn what they are most focused on right now and find a way to be a part of the solution.

LESSON #6: Pitching & ‘selling’ succinctly are critical DESIGN skills.

Like it or not, being able to ‘pitch’ and ‘sell’ your ideas is a critical part of being a designer. Something I didn’t understand well enough when I started out in design was that it was my job not only to design great experiences but to ship great experiences (or in other words deliver improved outcomes to my customers).

When you view your job as shipping, your whole outlook changes. You realize that every interaction with a team member, every design review, every demo is a chance to sell the value of what you’re trying to do. Through a LOT of trial and error, I’ve found the most value in selling the goal I was trying to achieve in a particular design iteration so if someone has a different idea for how I could solve that same goal that I might not have thought of, they can bring it up.

One other way you can get better at ‘selling’ and shipping great experiences is to become good at storytelling. People usually won’t remember facts and figures but they remember stories. Especially if they were told in a particularly meaningful way. Utilize a narrative structure with a story arc, and make the presentation memorable. If you’re presenting designs to a group of stakeholders, use the stories of real people from your research with their face, videos, and quotes where possible.

I had a professor in college who was teaching after a very successful career in the business world. She once told me that written communication, verbal communication, or both, played a major role in nearly every promotion she received or of which she was aware at every one of her employers. It’s one reason why I try to write as much as I can on professional topics. It takes practice to hone any skill. Selling and communication are no different.

LESSON #7: Focus on techniques, not software.

One of the biggest mistakes I see with designers—and it’s a very easy one to make—is that they confuse ‘tools’ with ‘software’. Part of this tendency I blame on schools and part of it I blame on recruiters. It’s so much easier to teach software over the myriad of design & research techniques, and many recruiters ask ‘what software packages’ candidates know because it is the logical equivalent of programming languages for a developer. This couldn’t be more misguided.

A great designer can solve design problems just as well on a napkin as in the latest software. I think I’ve learned a new software package (or more) at every company for which I’ve ever worked. This has affected my design approach very little. That’s because it’s the thinking that solves problems, not the tool you use to create the mockups.

I remember being surprised early in my career when I learned that roughly 80% of the effort of development work was ‘designing’ the code—or in other words figuring out how to approach a particular implementation problem. Once they have that figured out, actually writing the code is simple for all but the most junior software engineers.

Design is no different. Your time will be much better spent in experimenting with design & research techniques, understanding your users, and developing many of the other skills mentioned in this article, than by geeking out on the latest software package. Any good UX leader will assume you know or can learn software, but knowing how take a complex design problem with a list of constraints, lead the discovery work, rally your team around your research-informed vision, and make sure the desired outcome is delivered to customers, is much harder and much more important.

Just remember, success = outcomes, NOT mockups.

LESSON #8: There is no single ‘right way’ to do anything

I’ve wasted SO much time trying to fundamentally change the way companies do business. You hear a case study or presentation at a conference about Scrum, or Kanban, or Lean UX, or Design Thinking, or Design Sprints, or Jobs To Be Done, or the Spotify Model, or SAFe, or OKRs, etc etc and you immediately try to force your entire team or org to switch the way they’ve been doing things for years. When your experience in the real world falls short of the grandiose vision the conference presenter (or article author) painted, you get immensely frustrated and convince yourself your company just doesn’t ‘get it’. So then you move onto another company and the cycle repeats.

Why is this? Well at its core is the same reason why you can’t just blindly apply a design pattern you really like used by Apple, Google, Microsoft, or Facebook. Those were their answer to their problems, not yours. Joe Natoli once put it this way:

“Anyone that tells you that you’re going to radically change a company’s core processes — with convoluted, proprietary UX methodologies that require more time and more budget and complete authority—is flat out LYING to you.

Take the pieces from multiple approaches that work for YOUR situation, YOUR users, YOUR client, YOUR organization, and jettison everything else.

There is no single, correct way to do ANYTHING.“

— Joe Natoli, Give Good UX

LESSON #9: Design systems are about enablement, not enforcement

This is one so many of us get wrong the first time we design a Design System. It is very tempting to want to design a component library in a way that provides complete consistency, but that approach usually results in so much rigidity that other designers never really follow the patterns as much as you’d like. If it’s too rigid, they may not even use the system at all.

The argument over enablement vs enforcement in design systems is ongoing, but consider this: I’ve implemented 3 design systems myself and I’ve talked to design system designers at 10 of the Fortune 50—and they all have given me the same answer to the question “what would you do differently if you could do it over?” That answer without fail has been: “I would focus more on enablement over consistency”.

A design system is a product for other products, and like any product it has to work for its users and needs to be informed by research. Many design systems remind me of the old photo editing packages put out by Microsoft in the 1990s to try to compete with Adobe’s Photoshop which many found too complex to learn. So why are all those software programs obsolete and forgotten while Photoshop thrives? Because they were too rigid. In the name of simplicity they took away all effectiveness from the users’ hands. Many design systems today are no different.

The #1 thing that many design system designers forget is that there are many different ways to approach design and many different use cases (especially design systems for enterprise software). Consistency can be easy to maintain while the company or department using it is small, but once you try to scale it across multiple teams and tech stacks, it falls apart if it isn’t flexible. Designers and developers want to feel enabled, not constrained.

LESSON #10: Always question everything & be intentional.

This lesson is perhaps the most important lesson of all. The most powerful tool in a UX Designer’s arsenal is the question ‘why’? This is something many of us learn far too late after pulling out our hair in frustration. Just because someone asking you to do something outranks you by multiple levels, doesn’t mean you don’t have the authority to question them.

The core job of a UX Designer or leader is to comfort the afflicted and afflict the comfortable. One of my favorite phrases to use to soften the blow is “I’m just here to ask questions”. You can’t solve problems well that you don’t understand.

If an executive asks you to design a t-shirt, ask why. Is it to have something to give out at the next conference booth? Is it to say thank you to customers? Is it for employees to wear as free advertising? Is it to create employee pride & unity? Get to the bottom of what the purpose is, and then explore if that is the right medium to achieve the goal.

One of my favorite activities with senior leaders is to (politely) force them to sit down and frame their request in “How might we…” format. This does a couple things. First it gets them thinking in terms of a problem to solve, and second it carries with it a connotation that there are multiple solutions. I also like to use phrases like “we’ll get to the solution, but I’m just trying to understand the problem so I can solve it in the most effective way”.

As a design leader, whenever I get negative feedback about a designer by stakeholders or observe a lack of effectiveness in their ability to ship great experiences, almost always it’s at least in part because the designer has not done a good enough job at asking why.

Insatiable curiosity is one of the hallmark traits of great designers. One of my absolutely favorite techniques in working with stakeholders and in critiquing design work is ‘5 Whys’. Essentially the idea is to state a problem or idea and then ask ‘why?’ as many times as it takes to get to what you feel is the core cause of the problem. You can sound like a 5-year old child, but it is very effective.

Have something to add? Please leave a comment on the article or hit me up on LinkedIn or Twitter. Need a UX Leader to help guide your company’s UX Maturity? Need a speaker for your event? Check out my portfolio or contact me.

UX lessons I wish I had learned earlier was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the first steps I take when I come into an organization with low UX Maturity, is to establish user research as a regular part of the design & development process. At this stage, the goal is to start designing with user feedback in some form on a regular basis. Typically this involves creating a user research panel and introducing the team to the value created by observing and speaking with customers. This demonstrates the value of user-driven design and helps the entire company rally around customer needs.

However, at some point, organizations need to move past user interviews and usability testing. Yet many never do. It amazes me how difficult it is to find even UX Designers (even at a senior level) who have experience with more than just user interviews or usability testing. There are MANY different types of research. Some of these include:

• 5-second tests
• Analytics/Data Analysis
• A/B Testing
• Card Sorting (Open, Closed, Hybrid)
• Clickstream Analysis
• Contextual Inquiry
• Customer Feedback
• Data Mining/Analysis
• Diary/Camera Studies
• Ethnography Studies
• First click testing
• Focus Groups
• Paper Prototype Tests
• Participatory Design
• Stakeholder Interviews
• Surveys
• Tree Tests
• True Intent Studies
• Usability Testing (In lab, Moderated Remote, Unmoderated Remote)
• User Interviews
• Visual Analytics
• Etc.

As someone who is responsible for improving users’ lives and making their jobs easier, it is vital to evolve user interview and usability testing into a well-balanced user research approach. That is what I hope this article can help you accomplish.

UX Maturity Models

It is important to understand that not all “well-balanced” user research approaches look the same. UX Maturity is a journey, and depending on where you’re at on that journey (and other factors such as company size, industry, etc) your approach can and should differ.

To help you identify what a well-balance approach should look like for you, it’s useful to employ a UX Maturity Model. A UX Maturity Model is nothing more than a series of levels that evaluate UX Maturity and help you identify what your next steps should be.

One of my favorite UX maturity models, is the Keikendo Maturity Model developed by Juan Manuel Carraro. It lists 5 levels of UX maturity, their characteristics, as well as what can be done to progress to the next level.

Other popular UX Maturity Models include Jared Spool’s “Maturity Stages of Organizational UX Design:

And Invision’s “Design Maturity Model”:

There are also many others.

It is also important to note that UX maturity models take much more than just user research balance into account (such as company size, where UX falls in the organization, how embedded UX is on product development teams, how many UX roles an organization has, etc).

Whichever model you choose, being honest about where you’re at, and what your next step is, can be very helpful to help you craft your well balanced research approach.

Quantitative vs Qualitative

We all preach it, but yet so few companies actually practice a balance between Qualitative vs. Quantitative research.

The problem with Quantitative-only approach

Before UX Design and User Research became mainstream, companies mainly resorted to KPIs and data upon which to base their decisions. Naturally, this resulted in many companies making decisions based on incorrect assumptions. (After all if you work data over long enough, it will tell you whatever you want). Often, companies think they understand data, but the truth is we all have blinders on. We often see only what we want to see. We are not our users and so often the truth escapes our view. We don’t even possess the correct lens from which to view the data. This is because we often are missing context. The specific circumstances a user is facing can dramatically sway decisions they make. Until we understand the mental model and the circumstances someone is facing, the data can’t become true insight.

Problems with a Qualitative-only approach

The problem is that we now have swung to the opposite extreme of thinking that just because we talked to 5 or 10 users, we know the problems all of our customers are facing (and what solutions will resonate with them).

Many designers think that it isn’t “user research” if you’re not speaking with users. There are a few problems with this:

1. LIMITED ACCURACY
   Let’s say that you tested or interviewed 10 users. Let’s say 8 of them agreed or were able to accomplish the task. If you were to run a Confidence Interval calculation, you would end up with a confidence interval of 50%–90% with a 25% margin of error! That means potentially only 50% of your actual users would have the same experience as the 10 you interviewed or tested with. That’s a pretty big margin of error.
2. LIMITED TIME
   You can’t test everything. Even if you do the work to establish a User Research Panel and automate the recruitment process, recruiting users takes time. How much time depends on the UX maturity of your organization and willingness of your users to help, but it’s not quick. Also, the sessions themselves take time. You can easily spend the better part of a week just conducting qualitative research sessions, and that’s not including debriefing or aggregating the findings. Doing qualitative research with a large sample set of users is simply not practical.
3. BIAS
   Bias exists in quantitative data, but it is even more prevalent in qualitative research. How you moderate the sessions, what questions you ask, your tone of voice, the environment you’re in, the point of view of your note takers, preconceived preferences, and many other factors can bias or invalidate the accuracy of your findings altogether.
4. EXISTING KNOWLEDGE
   Not everything needs to be tested. There are many things that you just should know. Either from data or from past qualitative research. Testing anything qualitatively you already know or can easily discover via other means is a waste of time. You don’t need to ask someone what requirements someone puts on a Registration for a Football Official to complete to be eligible to officiate high school varsity games, for example, you should already know that. WHY they put those requirements on, however, might be a different story.
5. VARYING LEVELS OF RISK
   Even if you don’t know something, the risk or harm being wrong about that thing varies greatly. There are some things that simply would cause your project to fail outright if you were wrong. There are others that you might get wrong, but wouldn’t be a problem to tweak later on. You simply don’t need to test everything qualitatively. You should only test those things qualitatively which: A) You can’t learn any other way, and B) Would cause your project to fail if you turned out to be wrong.

Because of these 5 things, if qualitative research is your only approach, it’s very hard for many leaders to take seriously.

The true purpose of usability testing

There’s one more point I’d like to address about qualitative research before I move on to what a hybrid approach looks like.

I used to think that usability testing (and many other qualitative research methods) were about “validating” that we were solving the right problem, or “testing” the solution we came up with to solve that problem. It does do that, but that should not be its primary focus (for the reasons specified above).

Qualitative Research is much more about understanding your users on a holistic level. How do they complete their job? What are they responsible for? What circumstances influence their decisions? What are their mental models and how do they view the world? How does your product fit into their overall workflow?

You can’t do that in a few short sessions that are focused on very specific project-related tasks or questions. You do that by building a shared understanding over time of who they are and what they value. Over time, that results in an incredible user experience, not because you got the project-specific answer you came for, but because you now understand your user. This means over time there’s less you need to research. It doesn’t mean you ever “arrive” and stop needing to learn. It just means that you can spend your time on more risky assumptions and new aspects of their job you never had occasion to understand before.

It’s much like building a design system. Over time you’re building a library of knowledge you can refer back to and use. You still have to constantly add to it and tweak those “components” but you don’t have to relearn the same things over and over. This speeds up value delivery and allows you to solve many problems without going back to the drawing board.

What a balanced qualitative and quantitative approach actually looks like.

There are a couple ways you can approach achieving a balance of qualitative and quantitative user research data. Let me give a couple examples from my recent experience.

Example 1 (Quant informs Qual)

I work for a company that builds sports management software. We were setting out to improve our eligibility and registration system. One big pain points we had observed was that it took 100+ unique sets of Eligibility requirements for a single state high school sports association to register their officials for a single school year.

Instead of just jumping in and scheduling user interviews, we pulled a list of all organizations that had at least 5 Eligibilities set up for the previous school year. We wanted to verify how prevalent of an issue it was for dozens of registrations to be set up.

We discovered that around 80% of state associations that used our Eligibility product suffered from this problem.

I then wanted to understand what other commonalities and differences existed. So I started to look at the Eligibilities each of these groups was creating and I noticed that there was an overwhelming high correlation. Each group (with very few exceptions) was creating a unique Eligibility per sport per level.

Even more surprising was when I discovered that for a given level the eligibility requirements essentially remained consistent across sports. So the Varsity requirements were the same for Basketball as they were for Football, yet in the current system they all had to be created separately.

This led us to design a new data structure and UI that was able to handle these commonalities and cut set up from 50 hours to 25 minutes.

We were worried, however, that without talking with any users we would miss the boat on something critical, however. We did some 1:1 demos and usability testing of our ideas with 12 customers and discovered that:

1. The solution our data analysis led us to was spot on and customers LOVED it.
2. We had missed a vital use case. We had provided a way for admins to require an official to take an online course, and register for an in-person clinic, but we had NOT provided them to do either/or.

This insight led us to a critical insight we would have missed if we had relied on quant data alone. However, if we hadn’t solved some of the major usability issues we could through data first, we would probably never have dug deep enough to discover the “either/or” problem.

Example 2 (Qual informs Quant)

Another big pain point we had observed was that which Registration fee an official got charged varied quite wildly based upon different situations including: how many sports they registered for, which sports those were, whether the associate was the primary or secondary association they worked in, their age (minor vs adult), etc. Because of the complexity of all these situations as well as the fact that these fee requirements varied so wildly from one group to another, we were handling those with custom scripts on the back end. That meant at least once per year we had to go update those scripts manually. This was a huge problem. It was not scalable and resulted in a lot of volatility of our legacy code. It was frustrating for us, and also frustrating for our customers. Similarly, our customers were using a LOT of custom fields with registration. In fact, more than 65% of the total custom fields in use (on average) per account were only used in registration. There was some overlap between accounts, but nothing jumped out at us as obvious. We felt we had an opportunity here to dig deeper and understand our users’ better.

Unlike in the first example, though, we had no clear obvious answer by looking at the data. We had some theories, but didn’t not have a high enough level of confidence in any of them from prior experience.

So we scheduled some user interviews.

During the interviews we uncovered that in nearly every case the only reason for creating so many registrations AND the only reason for using most of the custom fields, was to ensure accurate fee calculations and be able to report on who fell into each group. We also came out of those discussions with a list of around 10 criteria that determined how much an official should be charged for registration.

With the knowledge of the problem, but not knowing how big of a problem it was for all our customers (how representative was the sample set we had interviewed), we decided to start looking through the data and poll the rest of our customer base.

When we knew which problem to look for, we found a high degree of agreement across our customer base. With this knowledge in tow, we designed a Fee Rule Builder that essentially put a custom query in the hands of our users. Because of our qual / quant data, we already knew which criteria we would need to add to cover the most important use cases. We had to add a couple criteria after doing the quant research, and we put a few others on hold for a subsequent release (this was just for a pilot program initially).

Additionally, we were able to identify some commonalities across custom fields that weren’t unique only to that group. By introducing those fields as standard fields we were able to eliminate a lot of the custom fields and increase our data integrity.

Hierarchy of User Needs

Once you’re at the level of UX maturity where you’re consistently using both qualitative and quantitative research, another set of criteria you might want to add in to the “well-balanced” equation are the elements of the Hierarchy of User Needs. In his book, “Designing for Emotion”, Aarron Walter, applies Maslow’s Hierarchy of Needs to User Experience.

The general idea of the hierarchy is that you have to make sure you have the bottom later before building the next, and so on. To quote Therese Fessenden’s fantastic article on the topic:

A beautiful application that is not functional, (that is, it has no useful purpose) will not satisfy users’ basic needs. Because it lacks a function, its aesthetic qualities will remain unappreciated. Thus, even though it might be gorgeous in its own right, the user will probably not remember anything good about the experience. A product must first, before anything else, satisfy a need and be useful.

On the next level, a functional interface that doesn’t always work as expected is unreliable and will still leave users mostly unsatisfied, no matter how beautiful it is. Finally, the interface must be usable: it should not require much effort to learn, discover, and utilize all its features. Only when a product is functional, reliable, and usable can users appreciate the delightful, pleasurable, or enjoyable aspects of the experience. What Walter’s theory tells us, in short, is that a product can be delightful only if it is usable.

-Therese Fessenden

What I have found is that each of the areas of the Hierarchy of User Needs can be measured Quantitatively or Qualitatively. Another truth is that most companies stop with Functional. To truly improve users’ lives you have to deliver all 4 levels of the period. That means in our user research, we need to include these in our research as well.

The other reason I love the concept of the pyramid is that it infers that it doesn’t necessarily need to be achieved all at once. A startup certainly wouldn’t want to try to do the research to measure all hierarchy levels across qual and quant before shipping anything. But, as your understanding of your customers grows, so can your approach. You can focus on measuring “Functional” qualitatively and quantitatively first. Then add in reliable, then usable, and finally pleasurable.

User Research Plans

One final component I would recommend if you are trying to create a well-balance user research approach is to be intentional in how you conduct research. The easiest way to ensure intention in research is by coming up with a User Research Plan. This is a new concept to a lot of designers I’ve worked with. However, what you’ll find is that it is liberating. Some benefits:

• It helps align all stakeholders on what you’re trying to learn and how you plan to learn it.
• It makes choosing research method(s) MUCH easier.
• If done consistently it can help you show the value of your research and get buy in and resources for more research in the future.

Here’s an overview of the User Research Plan process “DECISION” I developed and use with my team.

Decide on the main goal or objective of the research
Explore questions & assumptions (what is it you want to find out)
Choose a method (see above)
Identify participants (employees and clients)
Script or tasks
Identify schedule & budget (time, recruiting, & equipment)
Outline responsibilities
Nail the schedule down

I typically will run a short workshop with a cross-functional group of stakeholders and we go step by step until we’ve identified all the pieces. (I usually take notes on a whiteboard as we go). Often, the last 3 steps have to be completed after the workshop and that is ok. Lastly, I formalize the plan on a single page document that is easily shareable.

If you would like a little help getting started, you can download an editable pdf or Sketch file of my research plan template. It is meant to be a 1-page overview of a research plan that can then be sent to internal stakeholders, finance (for budget approval), and anyone else who needs to get an idea what you’re doing and why.

Conclusion

While what a well-balanced user research approach looks like for you will vary based on your unique needs, I hope you can see how balancing Qualitative data, Quantitative Data, the elements of the Hierarchy of User Needs, and formalizing it all into a unified User Research plan can all help you have a more well-rounded understanding of your users.

Use what you have to work with. Definitely talk to customers as often as you can, but don’t feel like if you can’t go on site visits or don’t have time to conduct user interviews that you’re stuck. There’s ALWAYS something you can do. There’s no 1 right way to do anything, but balancing a couple different approaches based on the circumstances and constraints you have to work with can definitely help.

Have something to add? Please leave a comment on the article or hit me up on LinkedIn or Twitter. Need a UX Leader to help guide your company’s UX Maturity? Need a speaker for your event? Check out my portfolio or contact me.

What a well-balanced user research approach looks like was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since my first job more than 25 years ago, I have been fascinated with resumes. It is one area in which there’s no shortage of opinions. It can be difficult to wade through all that advice. Here is just some of the advice I’ve been given over the years:

• Single-page (be succinct)
• Multi-page (be complete, don’t hide experience)
• No photo (avoid prejudice in the screening process)
• Add a photo (be more personal and memorable)
• Customize resume & cover letter before every application
• Optimize for “keywords” to get through Applicant Tracking Systems (ATS)
• Showcase your visual design skills (for designers)
• Don’t get creative, make it purely text-based
• Apply for as many jobs as you can (it’s just statistics)
• Network (quality over quantity)
• Don’t use a template
• Your resume is “too unique”
• It’s not unique enough
• Etc, etc, etc

Navigating all this advice can be extremely frustrating. I have experimented relentlessly over the years, trying to apply various advice I received. I constantly experimented, tweaked, and changed. Even when I wasn’t actively looking. Just in the hopes that I’d stumble upon the magic solution that would prove to be “THE” answer.

Here are just a few of my resume experimentations over the years:

Intentional Resume Design

This may seem obvious, but something I’ve learned is that THERE IS NO SINGLE CORRECT WAY that will work in all situations. Why all the disparate advice? Various recruiters, hiring managers, HR professionals, and job seekers have found things that have worked for them and their clients.

Blindly applying resume advice is just like mindlessly applying design patterns. Just because something worked for someone else doesn’t mean it will work for you. You have unique skills, strengths, weaknesses, and career goals. Resume design is difficult for many people because they don’t know how to cater their approach to their circumstances. Luckily, as UX Designers we have a lot of practice at making intentional, purpose-filled, research-informed design decisions. Yet, I see way too few designers actually using the UX process on their resume.

Not using the UX process on your resume (and portfolio) is like shooting yourself in the foot or trying out for a professional sports team blindfold with one hand tied behind your back.

I was also guilty of mindlessly following resume advice for far too long. I very clearly remember one day having a conversation with an experienced design recruiter who shared some statistics with me that, on average, if you apply for a job online, you have a 0.05% chance of actually landing the job! I knew I had to find a better way.

It is my desire here to share an approach that I have taken which has drastically improved my success. I share the principles and strategies that have worked for me in the hope that it might spark your own ideas and experimentation to enable you to find more success as well.

The problem with relying on optimizing for computers

One of the most important things to understand with traditional resume advice is that almost all of it focuses around optimizing for the computer rather than humans.

This might sound obvious, but it’s important. Why? The entire goal is to get through Applicant Tracking System auto-screening technology. It’s to make sure your resume gets in front of a human at all. So why is this bad?

1. Most companies don’t use ATS systems to screen their resumes. While it’s true that over 98% of the Fortune 500 use Applicant Tracking System (ATS) software, very few of them employ that software to screen resumes. The main goal of an ATS is to collect and organize the resumes and keep track of candidates through the hiring process. There are over 5.6 Million firms in the United States. Even if we extend ATS usage to 100% of the Fortune 1000, and even if 100% of those used ATS systems to screen their resumes that still is only 0.018% of companies that are screening resumes with technology.
2. Optimizing for computers often results in a poor experience for humans. Even if a company you apply to does use computer screening and you are one of the 25% that make it through the process, extremely often when you optimize for a computer, the experience of a human reading that resume is poor. This often results in the same end result as if your resume had been screened out. Humans don’t crawl the words of a resume looking for key words, we skim a resume looking for something interesting. If the most important content isn’t at the top, if there isn’t a visual hierarchy, if what we’re looking for doesn’t jump out at us within the first 5 seconds, that resume is rejected.
3. Many ATS systems have terrible search and/or recommendation engines. Even if a company isn’t screening your resume out with technology, many of the bigger technology companies do use them. However, it is no secret that the search and recommendation tools of the majority of ATS are very limited. It is very easy for your resume to be lost or never found, even if it isn’t being screened out. So even if you DO optimize your resume for key words, it is very easy for it to get lost.
4. Optimizing for computers can make your resume feel commonplace. One common piece of recruiting advice is to find a way to “stand out”. The problem of lack of individualism seen all day every day by recruiters and hiring managers is largely caused by the use of ATS technology and encouraging people to optimize resumes for it. Much of the individualism gets stripped out when you are optimizing for computers. You check the job description to look for key words, then update your resume with those key words. But so does everyone else. So if your resume does get through, it looks like everyone else’s.
5. Who has time for all that customization anyway? Let’s be honest, most of us that say we “optimize for computers” don’t really customize our resume for each application. Who has time for that? So the result is a really generic keyword-based resume that has all the pitfalls of computer-optimized resumes with none of the benefits. It’s a lose-lose scenario.

A better way

It has been proven that, on average, you are 53x more likely to get hired by using networking than you are to just apply online and wait. The same is true of hiring top talent. Why? Because we trust recommendations of people we work with. Even if we haven’t worked super close with the coworker. There’s an inherent trust there. In fact, at some very successful companies, it is nearly impossible to get hired without a referral.

Even more interestingly, I have found that your chance of getting the interview and ultimately of being hired, goes up even more if you build a user-centric resume. That shouldn’t be a surprise to us UXers. Doesn’t engagement go up with a better designed game? Don’t revenue & renewals increase with better B2B software experiences that are more in touch with their customers jobs to be done? This is no different.

Ok, so you want to give this a try. How do you actually go about creating a user-centered resume? It’s very similar to any UX process, but I’ve found that there are 6 keys to building a user-centered resume that have helped me drastically improve my Application to Interview ratio.

Step 1: Understand your target audience.

It is vital that you not take a “To Whom It May Concern” approach to your resume. Depending on the size of company you are applying to, there are at least 3 distinct personas you should keep in mind. I’m going to review those three, but before I do, it is vital to reiterate that you should absolutely do your own research. Your case could be different depending on the company size, culture, and position you’re going for. As a starting point, though, let’s start out with 3 very common ones.

SOURCER/HEADHUNTER
A sourcer is someone who is responsible for tracking down potential fits for open job postings. Often they are paid (or at least receive a bonus) per referral that gets interviewed or hired. They often source for many different kinds of roles. They are given general guidance but often don’t have formal briefing or insight into what makes an ideal UX candidate. As a result they tend to focus on looking at years of experience, prestige of the companies you’ve done work for, and the influence you’ve had on others. They want to be assured that if they refer you, it will work out. Your moving forward in the process reflects well on them as well as you.

RECRUITER
A recruiter is someone whose job is to find qualified individuals for the hiring manager to interview. They often are a “hiring partner” with the hiring manager. It is their job to make sure the role gets filled. They often have more context & knowledge of what to look for than a sourcer. They often are focused on reviewing your resume & portfolio for specific skills or experience the hiring manager is looking for. They are also often evaluating if you will be a fit for the culture of the company. The question always on a recruiter’s mind is “Is this candidate worth the hiring manager’s time to interview?”

HIRING MANAGER
The main question in a hiring manager’s mind when reviewing candidates sent from the recruiter, is around results and how they approach problem solving. Will this be a person that can quickly fill in the gaps or solve the pain points on my team right now? Do they know how to solve problems? Is this someone who can hit the ground running? Are they going to take pressure off of me? When a hiring manager reviews a resume, he/she is skimming the resume to see if the person is interesting enough to take the time to review their portfolio. The main goal of your resume should always be to get the hiring manager to review your portfolio. (And the goal of a portfolio should always be to get the interview, not the job…yet).

NOTE
Also a few notes before we leave this topic. You should always do your own research on personas. Please don’t just take my word for it. The ideal of course is to interview potential resume “users” at your target companies. If that isn’t possible, take a recruiter or hiring manager in your local community to lunch in exchange for picking their brain. Most will be more than happy to talk about their goals and pain points with you.

Step 2: Your resume should reflect your personal brand

There is no one just like you. You have individual strengths, weaknesses, skills, and unique background you bring to the table. It is vital that your resume reflect that brand. Your resume should shout loud and clear what you bring that no one else does. If you can swap the name on your resume out for another designer and the resume still holds true, your personal brand is not strong enough.

If you never have focused on personal branding before, and need a nudge to get you started, check out Stephen Gates’ The Crazy One podcast episodes #6: “The power of personal branding” and #7: “Bringing your personal brand to life”. Also, UX visionary Jeff Gothelf just wrote a fantastic book on the subject called “Forever Employable: How to Stop Looking for Work and Let Your Next Job Find You”.

Another part of personal branding that seems scary at first is that you actually WANT to drive some people away. You want to attract the right companies and drive others away. You have to draw a line in the sand and say “this is the kind of job I want or the kind of company where I do my best work”. Yes, this opens you up to missing opportunities and being judged, but it also attracts the right companies to you.

Some years ago I was given advice by an employee of one of the “big 5” technology companies to not just apply to every job I saw they had open. They said that’s a sure-fire way to get automatically rejected. They said to pick a team or product line I wanted to work on the most and to watch for an opening on that team. The idea was that would allow my passion to come through in the application. It is true. If there is one regret I have from early in my career it was that it took me too long to learn to never settle.

Step 3: Design an intentional visual hierarchy into your resume.

One of the keys to user-centered resumes is visual hierarchy. It is pointless when you are optimizing for key words, but when you are optimizing for humans, it is essential. Use font size, font weight, color, and proximity to direct the reader’s eye where you want it to go. Make sure the most important things are the most obvious. It isn’t a bad idea to do a 5-second test with a few people on your resume to see if the most important things are coming through.

One other concept that is important here is the 3-in-1 rule. That is, you should make sure the visual hierarchy supports 3 separate experiences.

5 SECOND EXPERIENCE
Your resume should communicate the most important points in under 5 seconds. If someone can look at your resume for 5 seconds and not get the most important “elevator pitch”, you have failed. (Remember personal branding and persona pain points here). I tend to cater my 5-second experience to Sourcers. For example, because I’ve never been employed by a Fortune 500 company, I tend to focus in my summary around clients who have used the work that I’ve done (which do include many of the Fortune 500 & 100). I bold these so they can be easily recognizable. A couple years ago, I also added some big and bold icons summarizing my experience in Graphic Design, UX Design, Leadership, and Project Management. These two things along with my headline are intended to be the most important takeaways. Also another approach I use is to add in a few visual elements (icons, a personal logo, and a little color in my case) to break up all the text.

1-MINUTE EXPERIENCE
You should also design a 1-minute experience into your resume. After you’ve captured attention with your 5-second experience, give them the next most important takeaways. These could include roles, companies, key skills (more on that below), and education. I’ve structured my 1-minute experience to resonate most with recruiters who are often focused on previous roles and skills.

If you notice, my roles, key skills, and degree name are bolded, font-size is larger, and I use color and a horizontal rule to help direct the eye to sections the user might be looking for.

3-MINUTE EXPERIENCE
Finally, I like to design the 3-minute experience into my resume. My goal at this point is to convince the recruiter/hiring manager to contact me for an interview. They probably aren’t going to spend more than 3 minutes on my resume — even if it IS interesting to them — so I try to keep it to 1 page. For years I had a 2–3 page resume, then one day I challenged myself to create a 1-page version and liked it so much, I ended up keeping it. (It’s made a lot of difference in landing interviews). For my additional content for my 3-page experience I have mainly focused on results I’ve achieved and specific techniques I’m experience with under each Key Skill. This is done to show versatility.

Step 4: Focus on results more than job duties and skills more than software.

One piece of traditional resume advice that is absolutely critical on user-centered resumes is to focus on results. Recruiters and hiring managers can be bored with “was responsible for designing software” descriptions. Get specific. Where possible quantify it.

Also, please don’t list software under “skills”. Everyone in this industry knows software. It is an expectation. That’s like a house framer or construction worker listing “ability to use a nail gun” on his resume. DO list the skills you have, though. Focus on skills you have that you want to keep using or gain more experience with. Again, attract the right companies.

Step 5: Research & Test

Don’t just assume everything is good. One essential element of the UX process is user research. This applies to resumes, too. I’ve already talked about the value of using “5-second tests” on resumes. Also, share your resume with some friends (ideally hiring managers or recruiters) and ask for feedback. One other way I like to test is to apply for a few jobs every now and again even if I’m not actively looking and track how often I get interviews. When I’m not successful at getting an interview, I reach back out to the recruiter or hiring manager (especially if I know them) and ask what experience other candidates seemed to have that I didn’t. Sometimes they answer and sometimes they don’t, but any feedback you get can be very helpful. It’s also reversed a decision of whether to interview me more than once when I actually DID have the experience they thought I didn’t have.

Step 6: Learn and adjust

Constantly experiment. Learn. Enhance. Repeat. One of the great paradoxes of personal branding (of which resumes are a part) is that if you wait to do it until you need it, it will be too late. I always keep my resume current. You never know when you’ll need it.

Get your resume in front of the hiring manager through networking

One very important corollary to all this talk about user-centered resumes. Remember all that discussion of ATS technology at the beginning? For a user-centered resume approach to work, you HAVE to do networking. You might see some improvement from this process if you happen to make it into the hands of a human. We don’t want to leave that to chance though.

This approach has been phenomenally successful for me as soon as I decided to stop just applying blindly and started working on my personal brand & networking. I’ll leave the discussion of what is networking and what isn’t for another day except to say that networking is NOT just adding a connection on LinkedIn and asking for a referral. You have to be adding value to others. You have to get your name out there. You have to be genuinely interested in others. You have to add more value to people than you take from them. This is a large part of why I write these articles. It is my attempt at giving back and helping others so when I need the help, my name is out there and I have the rapport to ask for something in return.

But I digress. Back to getting your resume in front of a hiring manager. It should always be your goal to get your resume/portfolio into the hands of a hiring manager. They know good UX best. They know when someone genuinely knows how to problem solve and can tell when they’re stretching the truth. I can’t tell you how many times I’ve been rejected by a recruiter only to be immediately interviewed when my profile got in front of the hiring manager.

If you can get your resume/portfolio in front of a hiring manager, often they’ll still have a recruiter contact you. The key, though, is that it is a very different conversation when the hiring manager says, “Hey, I came across this candidate who looks to be a good fit. Can you give them a call?”. The recruiter is still running the process but the guesswork is removed. They already know the hiring manager wants to speak with the person. That is much different than the recruiter searching through an ATS trying to weed out candidates that will be a good fit from those who will not.

Naturally, it is better if you have worked with someone in the past that works for the company who can give you a glowing referral. At least for me, that has been rare. So what do I do? I find someone that I know or have interacted with at the company (maybe it’s a neighbor, maybe someone I know from the local meetup community) and send them a quick request along the lines of:

“Hey. I saw you guys are hiring for X position and I’m really interested in it. I know we haven’t worked together before so you might not be able to give me a referral per se, but would you mind forwarding my resume/portfolio to the hiring manager so I at least know it got in front of a human?”

The vast majority of times the person has readily agreed. There’s very little commitment on their part. They’re not really even putting themselves out there saying I’d be a good employee. They’re just getting my profile in front of a human (ideally the hiring manager). My human-centered resume and portfolio do the rest. Plus, many companies offer referral bonuses if someone you refer is hired. So they might even end up making some extra money off of it. It’s a win-win.

What about personalization?

You might be thinking, but Jeremy, what about the overwhelmingly common advice to personalize your resume? Good question. As we have already discussed, if you do personal branding correctly, then you should NOT be personalizing your resume before applying to a particular company. That being said, sometimes I will personalize my resume for a particular role. For example, in the past I was thinking of giving Product Management a try. So I created a PM-specific resume that highlighted the skills important to a PM more than those important for a designer.

Also, there IS power in letting a hiring manager or recruiter know what specific skills on their job description you possess and why you’d be the best fit. I tend to leave that for a short, succinct cover letter. I’ll write a paragraph or two on the application form or in an email to a network contact who will be forwarding my resume addressing those things. That way my resume is still consistent with my personal brand, but I’m also addressing any company or role-specific skills they might be looking for.

It’s also becoming more and more common on job applications to have a section for “skills”. If they do it’s great to fill that out if you would like to. (Hint: in more modern ATS technology, that’s where they do their keyword matching from instead of parsing your resume).

Conclusion

I’m not saying this will work 100% of the time and I’m not saying it’s not hard work. (Networking can be very hard work). But ever since I started using this approach, my application to interview ratio has gone drastically up. I now get interviews from companies or positions I used to think were out of my league. I don’t always land those jobs, but I at least get the interview which often is the hardest part.

It is my desire that this approach will help you land more interviews or at least spark some ideas for something different that will help you land more interviews.

I’d also love to hear from you. What has worked well for you? What challenges have you faced? I’m always experimenting and trying new things. I’m still on my journey of learning how to find and be found. If you have any advice, I’d love to hear it.

Have something to add? Please leave a comment on the article or hit me up on LinkedIn or Twitter. Need a UX Leader to help guide your company’s UX Maturity? Need a speaker for your event? Check out my portfolio or contact me.

A case for human-centered resumes was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.