As a UX Manager, adding a new person to your team is one of the most difficult and critical things you’ll ever do. Adding the right person will dramatically increase the quantity and quality of the work your team produces. However, adding the wrong person can create morale issues and even decrease your effective throughput.

Who Do You Hire?

You want the new person to be an asset to the team. What type of person should they be?

Do you want someone who broadly understands many areas of UX? Or do you desire an individual who has a rich and deep experience in an important area, such as interaction design, information architecture, user research, or visual design?

The Specialist: If you see your team lacking in a particular area, it’s tempting to fix it with someone who brings those talents to the team. With the specialist’s unique experience and skills, they could blast through assignments in their area of specialty much faster than any other team member. This would enhance the team’s overall quality and expertise.

The Generalist: It would also be tempting to find someone with broad skills—someone who can switch between skill sets, as the projects demand. A generalist like this would have value regardless of the nature of the project, giving flexibility to the types of assignments the team could tackle.

Which do we hire, a specialist or a generalist? That’s the question we need to answer.

Avoiding the Compartmentalist

Make sure it's the right choice

Before we continue, there’s one point of common confusion I want to clear up: there’s a difference between a specialist and a compartmentalist.

A specialist brings a lot of skills and experience in one or more specialties. Maybe they’ve done a bundle of big and small information architectures projects. They’ve made a point of keeping up on the latest thinking and have perfected many new techniques. Their experience helps them assess problems quickly and pick a plan of attack that typically results in successful designs.

Some specialists are truly specialized. For example, you may find an interaction designer who has delved deep into institutional financial systems. They’ve accumulated thousands of hours of designing for the unique problems of this specific domain. Their knowledge of the challenges in institutional finance management and how to work past them would be exceptionally valuable to your team, if you were designing for that.

A great specialist, however, isn’t restricted to work in the areas of their specialties. They can adequately (or better) produce work and results in other areas. For example, an experienced user researcher could also have great wireframing and prototyping skills. More importantly, they understand how that work is performed and what makes it successful.

A compartmentalist, on the other hand, is a myopic breed of specialist—a person well versed in their specialty, but doesn’t know anything beyond that. Compartmentalists throw their hands up when the work goes beyond their area of expertise or produce poor results.

Of the three types of team members—generalists, specialists, and compartmentalists—the compartmentalists are the least valuable to your team. Unless your team has so much work in the specialty that you can afford someone who is occupied full time, a compartmentalist will frustrate your efforts to deliver great results. Even then, their lack of understanding of how other team members do their jobs will make any hand-offs inefficient.

For the harmony of your team, you want to look to specialists who have a solid understanding of all the areas of user experience. Think of a great orthopedic surgeon who, like most medical specialists, started with general medical training and residencies before they chose their specialty. The surgeon could deliver a baby if they had to, and understand what other doctors do and how they do it.

You want to avoid the compartmentalist, who only understands their one thing. But that brings us back to the question we started with: specialist or generalist?

Conditions Favorable To Specialization

Imagine an organization trying to blast through a flood of highly technical information architecture projects. Hiring a person who can tackle that work expertly and quickly would be really valuable. In simple economic terms, that organization would see more value (and thus pay more money) for an individual with those skills and talents than they’d see for a lesser skilled professional.

However, the increased value from specialization only happens when there is enough work that the organization realizes a productivity increase. If the team only needs information architecture skills on a few sporadic projects, having an expensive specialist doesn’t really pay off.

Specialists will pay off best in large organizations where there is high demand for the specialized work. The more specialized the work, the more valuable someone doing that work quickly and expertly will be.

As the hiring manager, you want to ask, “How busy can I keep this person with their specialized work skills?” If the answer is 100%, a specialized UX professional will be a great deal. Once the number gets lower, it becomes questionable. At this point, a generalist becomes more appealing.

Conditions Favorable to Generalists

When your project work is all over the board and requiring skills from many different disciplines, you’re better off with a generalist. The broad skill sets of generalists allow them to switch quickly.

The best generalists will tackle a complicated interaction design problem on Monday, conduct thorough user research on Tuesday and Wednesday, help another team with their information architecture on Thursday, and sketch out some new page layouts on Friday. Their skills are not just within the specific disciplines, but also in understanding how to switch gears quickly and take on new projects.

Generalists pay off in fast moving organizations with a high-pressure fire hose exuding out small, targeted projects. The fast pace and variety of the work will energize a talented generalist, who brings value by connecting the disparate projects together to create common threads and elements.

When you’re wearing your hiring manager hat, you’ll want to look at the history of your project work. It’s valuable to take an inventory of the skills that your team needed to complete each phase and deliverable. How much of each project was information architecture? How much was interaction design?

The Passion Factor

As you review any candidates applying for the job, you’ll want to look at their previous work experience to see whether they specialized or generalized. If the majority of their projects focused in the particular specialty you’re seeking, then they could be the specialist you’re hunting for. If you’re looking for a generalist, then you’ll want to seek out those folks whose previous work demonstrates a wide breadth of experience.

You’ll also want to see where the candidate’s passions lie. Is a specialist candidate in love with their specialty, craving to learn even more about it? Is a generalist candidate wild about the variety of work, eager to apply their wide range of skills? If you can’t find the passion in their choices, they may not be the best candidate for the job.

UX Generalist or Specialist? It Depends

If you discover your work requires a spread of skills that’s constantly shifting around, then you’re in better shape hiring a generalist. If there’s a core group of skills that’s in constant demand—enough to keep a full time person busy doing that one thing—then a specialist is likely a better bargain. Either way, you want to avoid the compartmentalist.

Midwest UX

Jared Spool will be speaking at Midwest UX, a two-day event combining inspiring talks with hands-on activities and presented by a mix of regional professionals and international experts. The conference will take place  April 9–10 in Colombus, Ohio.

This is part 2 of a two-part post. Read part 1.
In the last installment, we talked about the distinction between Hands contractors and Brains consultants. Hands are brought in by the team as an extra resource to complete work the team already knows how to do. Brains are brought in by the team to provide expertise and insight on the best way to do something the team is struggling with.

Hands and Brains require completely different skills, have different approaches, and run into different challenges. Knowing which you want to be is important.

The role of Hands

The UX professionals who make great Hands are passionate about producing stuff. Whether it’s a pile of wireframes or a boatload of usability test sessions, they can crank through them. More importantly, they tackle every single piece of the project joyfully and proudly.

The thing to remember is someone who signs up to be Hands typically doesn’t get to say how the project is done. The team decides that up front, often before the project is started. It’s up to the Hands to match the work exactly, making it impossible to know which elements came from the Hands and which came from other team members.

When it comes to how the work is done, creativity and previous experience aren’t playing big roles. In fact, they are frowned upon. While the team focuses on getting everything done by the end project, they don’t want to step back and take the time to rethink what they are doing.

The Hands will get management’s attention if they have tricks and techniques for speeding up production, while keeping the results indistinguishable from what’s been done so far. An experienced Hands contractor brings speed and agility, while playing the chameleon to match the work of their temporary teammates.

Bring in the Brains

This is a complete opposite to the Brains—who aren’t about production at all, but instead about strategy. The Brains, when at the top of their game, are the sheriffs, coming in to clean up the town. When a team is stuck and not making progress, and it feels like they’ve tried everything without results, they call in the Brains.

Unlike the Hands, the Brains doesn’t make a good producer. Their value is squandered if they spend the bulk of their project time churning out similar items. Of course, if the team is struggling with what to produce and how, the Brains can get them started, showing them the technique and coaching them through the work. But, in this scenario, the Brains quickly backs away, as soon as it’s clear the team members can produce their own results. (Some Brains will bring Hands into the project at this point, working jointly.)

Instead, the Brains’ real value is in strategic understanding of the situation. The Brains looks at the entire scope of the project, studies the goals, and assesses the team’s capabilities and flaws.

Then the Brains suggests a new plan. They get the team started on the plan. They train the team on the tricks and techniques that will get them through that plan. Then they leave town, just like the sheriff, to go off and clean up the next team’s mess.

Why The Difference Matters

Great Hands know how to produce. Great Brains know how to analyze and persuade. They are completely different sets of skills. Hands and Brains require different personalities. It’s very rare to find one person who does both.

Great Hands know how to produce. Great Brains know how to analyze and persuade. They are completely different sets of skills. Hands and Brains require different personalities. It’s very rare to find one person who does both.

The Brains aren’t challenged by production work. Once they’ve done one screen or conducted one test session, they’re ready to move on to something completely different. The Brains love the variety of the tasks—coming in to something new. The Brains love seeing problems and solutions nobody else seems to see. The Brains are energized when those problems are particularly gnarly and the solutions are deviously elegant.

The Hands struggle with strategy. They always feel they’re the wrong people to ask—that someone else should’ve figured this all out by now. They thrive on having a set of constraints, a schedule, and a near impossible pile of similar things to do. They love to crank through the work, seeing the Done Pile grow while watching the To Do Pile shrink. They don’t mind their work blending with the rest of the team’s—their contribution becoming invisible to anyone outside the team. They are energized by completion.

In other words, Hands thrive on walking into a project that’s well defined while the Brains thrive on walking into a project that’s poorly understood. That’s why it’s difficult to be both. It’s a very rare person who thrives on both definition and chaos. For everyone else, they need to choose one or the other.

I’ve seen managers who have tried to have one individual contributor play both the Hands and the Brains. Often this is because of resource constraints or not realizing there’s a difference. Unfortunately, this inevitably ends in disaster, because of the opposing strengths and weaknesses of Hands and Brains. Don’t fall into this trap.

What do you thrive on? What energizes you? Where do you get frustrated? Understanding this will help you figure out if you are suited for the Hands or if you ought to be the Brains.

Jared Spool is the keynote speaker at UX Australia 2010,  being held in Melbourne from the 25-27 August 2010. The conference has sold out, but Jared’s workshop and others are still available, or you can go on the waiting list. See  the site for details.

What’s the difference between contracting and consulting? One major difference comes down to whether the job is handwork or brainwork. Whether you’re an “innie” or an “outie,” this is applicable.

Innies are UX professionals who work inside an organization. Even though they are part of the company, they are still consultants. They are brought on to projects with the intent of lending their skills to move the project forward. Sometimes they stay with one project for its duration, or sometimes they juggle multiple projects at once. Either way, they aren’t really part of the long-term team in the same way others are—they move from team to team and are only there when their skills are in demand.

Handwork and Brainwork

Innies and outies have a lot in common. One thing they share is the need to distinguish whether a project is handwork or brainwork.

Handwork is when the hiring team knows what they want; they just lack the right number of hands to get it all done. Let’s say the team needs new screens designed. They know what the screens are and how they should work. They’ve built many screens before, quite successfully, so it’s not a problem of knowing what to do.

The problem is they don’t have enough hands to get the job done. All of their internal resources are otherwise occupied, thereby stalling the screen-production piece of the project. In this case, they hire a contractor—someone who will come in and help them crank out more screens. This is handwork.

But there’s another way the project could go down. What if our hypothetical team doesn’t know what the screens are or how they should work? What if they don’t have the experience of building screens before and lack the confidence and skills to get started efficiently?

In this case, they need someone to help them come up with a strategy for identifying which screens need work and how to tackle them. In fact, once that strategy is set and they understand what the project needs to be finished, they may have, internal to the team, all the resources necessary to complete it.

This is when they hire an outside consultant; someone who will bring in expertise and skills the team doesn’t otherwise have. This we call brainwork.

Hiring Hands and Brains

It’s quite critical, as a UX consultant (whether you’re an innie or outie), to distinguish between handwork and brainwork—yet the distinction is often not discussed. As I talk to people who are looking to expand their careers, what I discover is they are often trapped doing handwork when what they really want to do is brainwork. (Occasionally, I meet someone who prefers to do handwork to brainwork, but that is quite rare.)

Handwork, for the most part, is commodity work. Once you qualify the basic skills, it really doesn’t matter who does it. It doesn’t take imagination. Previous experience, for the most part, doesn’t play a role in the quality of the output.

If the team needs to produce 100 wireframes and they have a pool of 20 people who are capable of producing those wireframe to their specifications, then it doesn’t matter which of those people you hire. Hire the one who charges the lowest rate, has the nicest personality, and produces the cleanest deliverables.

Brainwork, on the other hand, is where your expertise and experience come into play. If the team doesn’t know what a wireframe is or how to decide what they should do, they’ll want someone who can give them solid advice. It they’re smart, they’ll be selective about who they hire, looking for someone with a track record of helping other teams in comparable situations, and they’ll pay top dollar for their help.

Maybe the team’s leadership is mistaken and they shouldn’t be doing wireframes at all? Well, someone hired to do brain work will have earned the respect and authority to say, “You know, there’s a better way to do this” and the team will listen. (Occasionally, they’ll even revise their plans, but that’s another column for another day.)

However, if that same person was hired to do handwork, there’s no way the leadership will pay attention. It’s wasted breath (or worse, seen as belligerence that may result in removal from the project). Handwork is hired for hands, not brains. Please keep your brains to yourself.

UX professionals who do handwork are what we call the Hands. They’re a rare and valuable breed. Find someone who loves being the Hands and you have a production machine.

The Brains are what we call folks who provide great brainwork. Prospective employers have to be more discriminating when hiring the Brains, because their advice will drive the results, either to success or to failure.

Hiring managers should know which they want. Get the right person for the job and you’ll have a successful project. You need to distinguish between Hands contractors and Brains consultants. In the next installment, I’ll talk about the qualities that separate a great Hands contractor from a great Brains consultant.

More thoughts on this topic: Should You Be Hands or Brains?

Want to meet Jared?

Jared Spool is the keynote speaker at UX Australia 2010, being held in Melbourne  from the 25-27 August 2010. To pick up one of the (less than 30 at time of going to print) tickets, register on their site.

Some days, I like to think I have a UX Flashlight. As I point its beam at a design, all the UX problems appear, bright as day, waiting to be fixed by a clever designer.

There are designs where, if I had such a magical device, it would just light up everything. The problems and fixes are obvious. It’s just too easy. Sometimes I’m embarrassed to take their money.

These designs are such UX disasters that I wonder how they got this far without their users raiding their castle with pitchforks and torches. Interestingly, once you meet the client team, it’s not hard to see how they’ve let their design get so out of whack.

They’ve been focused on making the technology just work, knocking off bugs, adding new features. These activities took their full attention. Only now, once things have settled a bit, could they begin to think about the experience of the design. And boy, does it need work.

As UX professionals, when we’re confronted by this type of design, it’s not hard to see the problems. There are tons of them, but most are simple to fix. Just change the visual priority of the interaction elements, add some better copy, and use common interaction patterns—in short, employ the professional’s bread-and-butter tools for this situation.

Bad UX is the Default Outcome

Designs that never receive any UX attention will have problems because the problems don’t go away by themselves. Creating a great experience is a deliberate act, one that takes careful thought and planning. When that thought and planning are absent, the odds of ending up with a great experience are practically nil.

Incorporating UX attention into the design process from the beginning is a nice ideal. It requires real maturity, however. Managers making their first endeavors in designing don’t have the experience to know that it’ll be needed, let alone understand the underlying practices. Add in the fartoocommon perception that anyone can design and you have a recipe for a bad user experience.

Then they patch and fix and tweak and patch, adding far more options and not realizing they are making it worse with every move. No wonder it’s easy to clean up the mess—just go in with a machete and start hacking away the slop. Voilà! Instant success.

The World Of Low Hanging Fruit

Here we are, called into yet another project, where it’s quick to find a ton of easy-to-fix issues. Which we do. Then we’re heroes. Hooray for the UX guys.

Then comes the dreaded plea: “Do it again! Do it again! You did that so quickly, so well. Do your magic again and make us even better.”

We might pull it off one or two more times. But suddenly, the magic wears off. The problems get harder to find. The challenges are tougher. The constraints are more rigid. Getting the same improvements takes much more effort and creativity.

We’ve picked all the low hanging fruit off the tree. There’s still fruit left, but it’s far out of reach. We’re going to need better tools than we have to get it. We’ll need to be far more clever, more versatile than ever before.

This is where a lot of UX professionals struggle. Once they’ve picked the low-hanging fruit—found all the easy problems to address—they need a different set of tools, new methods, new practices, and, most importantly, a different relationship with their client teams to find the more gnarly problems.

This is where a lot of UX professionals struggle. Once they’ve picked the low-hanging fruit—found all the easy problems to address—they need a different set of tools, new methods, new practices, and, most importantly, a different relationship with their client teams to find the more gnarly problems.

Problem discovery is only part of the issue, though. We also have to deal with the effort it takes to design and implement solutions. That’s where penny stocks come in.

Penny Stocks And Beyond

Penny-stock investors represent an investment subculture. They focus on stocks that are close to $1 per share or less—stocks you’d only pay pennies to buy. Penny-stock investors think differently than other types of investors.

Say you’ve bought a bunch of a stock worth 50 cents. If it goes up by another 25 cents, you’ve now seen a 50% increase in your investment. Woo hoo!

What if that stock was trading at $100 dollars? A 25-cent increase would be noise—certainly not cause for celebration. A quarter of a percent increase is nothing to write home about.

When we’re working on a UX project that hasn’t seen the talents of a solid designer, we’re dabbling in the world of penny stocks. We can attain 50% improvements with just small fluctuations in the design’s actual quality.

Dabbling in stocks that are much higher value than pennies requires more patience and a larger up-front investment. You need to sit out small fluctuations and have a long-term strategy. Large changes in valuations won’t happen quickly, not like they do on the penny-stock trading floor.
The same is true with our designs. With those quick fixes, we see huge returns. “Wow, you fixed that one button. Now orders have doubled! Thanks, Mr. Super UX Guy. Can you do it again?”

Yet once we’ve knocked all of the easy problems off the list, we’ve got only difficult stuff left. That takes patience and larger up-front investments to generate the same rate of returns.

Skills and Expectations

Now, knowing about the low-hanging-fruit and penny-stock effects, what do we do about it?
UX professionals who understand the low-hanging-fruit effect know they need to build out their toolbox of skills. A design review (or heuristic evaluation or inspection or whatever you want to call it) works just fine when the fruit is hanging low. However, we need techniques that are more rigorous when we’re grasping for the higher fruit. We need to have practiced them and know when to pull them out.

We also need to ensure we’re keeping our clients in the loop from the very beginning. The days of penny-stock improvements can set an expectation of quick and high returns that’ll become increasingly more difficult to meet. We need to, from the very start of the project, set the expectation of how it is likely to progress, being clear about what’ll be easy-and-cheap and where they’ll need to make more investment.

Sometimes, I like to think I have a UX Flashlight and sometimes I like to think I have a high-powered, broad spectrum UX Floodlight. The floodlight lets me see things I can’t see, once the flashlight power fades. It’s expensive to run and it takes a lot of work. But when I find and fix those problems, that is when I’m really earning my keep.

Top image: Colorado Luis / cc-attribution

In last month’s Johnny Holland column, I made the radical recommendation that UX professionals stop making recommendations to their clients. Nick Gould, CEO of Catalyst Group, commented that this wouldn’t work for him:

My clients would fire me if I didn’t come to them with ideas / recommendations for how to address problems identified in research. But we discuss the ideas and prioritize approaches together. We have a shared stake in the outcome. Maybe we’re already doing what you’re suggesting, but I don’t really see it as eschewing recommendations completely.

Chris Fahey, who runs the UX consultancy Behavior Design, thought we were talking about the wrong approach to the process:

This is why I think it’s silly that design research and design are ever done by different people. Or that strategy and implementation are done by different people.

This is why I run a design company – we don’t make recommendations, we make plans and execute them.

The Spectrum

We could plot these strategies on a spectrum.

On the one side is Chris’s approach of designing all the way to execution, delivering a detailed specification to the tech team, solving every design detail.

On the other side is my approach of letting the clients build and maintain the entire thing on their own, only providing coaching and guidance so they do it better. Nick seems to be right in the middle, providing recommendations to help them build it out. (Nick tells me some of Catalyst Group’s projects go all the way to execution—however, most go up to research deliverables.)

The Implementation Spectrum

This spectrum doesn’t only apply to UX consultancies, like Catalyst and Behavior. If you’re a UX professional working with an internal or external client, helping them create a better design, you’ll find yourself somewhere on this spectrum. Either you design the entire thing, teach the team to do it themselves, or are somewhere in the middle.

Should We Give Clients What They Ask For?

Clients, left to their own devices, will ask for all sorts of things. Some clients want the Behavior approach—to have the UX professional provide everything they need to implement the design—solving all the issues and providing exact instructions. These aren’t recommendations-—they are marching orders. This approach works best when the design, once built, will likely not change and the client shows no interest in developing their own design skillset.
For example, Behavior designed the award-winning site supporting HBO’s project for the TV series The Alzheimer’s Project. Once deployed and the final touches applied, this site probably won’t change much. Even if it does, it’ll be a discrete project that Behavior (or someone else) can rework, soup to nuts.

In contrast to Behavior Design’s approach, at UIE we assume the client team will make all the important decisions. We help them by giving them a process that informs their decisions. We look at the skills the team has and assess where they need help. Then we work closely with them on their techniques and process, giving them a way to tackle both their current and future projects.

Over at Catalyst Group, Nick’s team works with the client’s team while conducting their research. However, as Nick said, his clients ask for recommendations, so he gives them. The client is happy to get a great set of recommendations (and I’m sure that Nick’s group produces some of the best out there), so what’s the harm? He’s doing what they want.

Obligatory Ancient Philosophy Reference

I’m sure you’ve heard some variant of this wise ancient philosophy:

If you give a child a Nintendo, he’ll play all day long.
If you teach him to build his own Nintendo, he’ll become a millionaire, date hot chicks, and eventually start a foundation solving the world’s problems.

Is giving in to the clients’ desire to receive a list of solid recommendations the best for the clients?

What Happens When You’re Gone?

When Chris and the Behavior team are done with the HBO site, they move on. The HBO team doesn’t need to change the site, so they’ll move on to other projects too. The site keeps running as long as the servers are plugged in. Everyone is happy.

When we finish our engagement with our clients, they’ve learned how to do the work themselves. They can continue researching and enhancing their designs, using the techniques and tricks we’ve taught them. We’ve done our job and they’re happy continuing on their own.

When Nick and the Catalyst team have delivered their recommendations, their client goes off and makes changes. The question I have, however, is this: are they left in a situation where the only way they can make any further changes and enhancements is to call Nick’s team back?

Unfortunately, many projects aren’t like Chris’s HBO site. They need to evolve as the business, the technology, and the customers mature. They need new features, new enhancements, and new ways of thinking about the problems they’re solving.

Are we leaving our clients with the best possible experience? Are we considering that when we first pitch the project and its deliverables?

Preachy Professional Responsibility Section

Dumping a Jenga tower of recommendations in the client’s lap only delivers a short-term solution. It doesn’t give the client the tools to survive in the world for the long-term.

Yes, they asked for it. But clients ask for lots of things we tell them we won’t give them, like that really big fluorescent green blinking tagline. Just because they ask for it doesn’t mean we should give it to them.

This is where I get preachy:

In any new project, one of the first things we, as responsible professionals, need to consider is what will happen after we leave. Are we preparing our clients for their long-term best interest? Or, are we only shooting for the short-term deliverable, figuring if they wanted something more, they would’ve asked for it?

Once Again, Do We Need To Make Recommendations?

If we’re taking the entire thing through to execution, behavior-style, we don’t have to make recommendations.

If we’re helping the team learn how to make good decisions themselves, we still don’t have to make recommendations.

The need for recommendations may just be a placebo, to help a client think they are getting one thing when we are really doing something else. Or maybe recommendations are just a way for us to sell more project work.

What this comes down to is a philosophical approach to our work in general. Are we looking at the short term, or do we want to take a long-term view?

Where do you sit on the spectrum?

It’s easy to believe them when clients ask us, designers, to make recommendations. We want to believe they love us for our wisdom, knowledge, and experience. They want our advice. And we love giving them advice. It makes us feel smart—like they finally “get” what we’re about. They want to do the right thing and we know how to help them. So, why is it bad to make design recommendations? They want it. We want it. Why shouldn’t we make the recommendations they’re asking us to give?

Simple: The recommendations don’t work. We end up looking bad. Clients lose faith in our skills. And the design doesn’t get better. Interestingly, in our research, the best teams don’t use recommendations. Instead they use an experimentation approach.

Patient, flexing his arm: “Doctor, doctor! It hurts when I do this.”
Doctor, checking the patient: “Hmmm. Well, I recommend you stop doing that.”

The Easy Out

Making recommendations is an easy out. You say, “Do this. Change that.” then wipe your hands clean of it. If they don’t do it, they’re obviously idiots. If they do, you’re brilliant. The best case scenario is they follow your great recommendation and it improves the design. But it turns out, that only one out of four possible outcomes.

What happens if they follow your recommendations and it doesn’t improve the design? What happens when they choose to not follow your recommendations and the design improves anyways? In either case, your future attempts to work with them becomes more difficult.

Changes cost resources. If the design doesn’t improve, then the organization has spent energy, money, and time on something that didn’t pay off. Are we considering that when we put the recommendations on the table?

Playing “Bet Your Salary”

UX Researcher Extraordinaire, Meghan Ede, has a rule of thumb she applies to her research team’s recommendations. The team members can only submit a recommendation if they’d be ready to put a full year’s salary down as a guarantee that the design will show improvement.

Would you be willing to do what Meghan does with your next set of recommendations? Go ahead: take out your checkbook. Write out a check for your take-home salary, after taxes. Pass it in with your recommendations, while telling them that, if the design doesn’t improve, they can cash the check. How confident are you feeling about those recommendations?

The Experimentation Approach

What our preliminary research has found is a typical recommendation looks something like this: “Users had trouble seeing the field labels. I recommend you put the label on the top of each field, instead of on the left.”

However, some teams are using a different approach: “We’re seeing that our users have trouble with the field labels. We’d like to try an experiment and see if moving the labels to the top of each field makes an improvement.”

It’s a subtle difference. And it was the approach we saw most in use amongst those UX professionals who had a solid track record of consistently improving their designs. These professionals told us they refuse to make recommendations, but love to experiment.

Discussing the Meaning of the Observations

I found the process from these high-performance teams quite interesting. It starts with a team discussion of the underlying observations and what it means. The team explores all the different interpretations. “Is it possible the users didn’t see the labels because they are too far away? If the font hard to read? Are the users not recognizing the terms? Were we measuring the wrong tasks?”

Then the team guides the conversation to other research that may fill in any holes, group discussion of alternatives, and measures to signal when the users’ behaviors change in the right direction. Often, this is followed by further research, then more discussion.

This process is very different from the recommendation approach, where the local UX expert makes a pass at the design and puts together a list of things that need changing. Instead of putting the onus on someone to come up with winning solutions, the entire team pushes the design into improvement, one experiment at a time. Some changes will work as intended, others won’t, but with each change the team learns something.

The result is that the entire team becomes better informed about the design they are building. No one person carries the burden of improving the design. Nobody has to be in the position of being all-knowing, always right. Changes are not seen as final, but as an ongoing process of improvement.

A Change in Mindset

Making the move away from recommendations is very hard. As I said, making recommendations is the easy way out, so it feels like the best path. But, in the long run, it’s a trap. The house odds are against you and eventually, it will all come crumbling down.

Both experience and research are telling us that experimentation, where constant changing and measuring gives the team guidance and insight, is the approach that leads to long-term success and better designs.

That’s my recommendation. I’m sticking with it.