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.

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.

Opinion wars can get messy. They can stop a team in its tracks. And the worst thing about them is they can’t be won. There is never a winner in an opinion war.

The problem with opinion wars is their foundation. Let’s say you and I are in an opinion war. You strongly think that we should do some thing and I strongly think that thing absolutely the wrong thing to do.

For you to swing me over to agreeing with you that we should do that thing, you’d need to sway my opinion. And, if I’m going to convince you it’s wrong, I’ll need to sway yours.

However, swaying opinions is practically impossible. I’d like to think I’m a smart dude and my opinion is not just some random, unconsidered thought. Instead, I’ve based my opinion on my life’s experiences, which you haven’t had. Similarly, you’re a smart dude or dudette and your opinion is based on your life’s experiences, which I haven’t had.

To sway my opinion, you’d have to convince me to put aside everything my life’s experiences are telling me about this situation and take, completely on faith, your opinions. These are based on your life’s experiences, which I didn’t have. That’s really, really hard for me to do. It’s hard for anyone to do.

Opinion wars can’t be won. The only way to move past them is to subvert them.

Using Data to Subvert Opinion Wars

One way to subvert an opinion war is with data. In a design process, the data usually comes from user research.

If I believe there a right way to design something and your experience tells you that would be a sucky design, we have an opinion war. However, if we can get a prototype of that design in front of users, we’ll get real data to make the decision. We’ll no longer be working off our own opinions and experiences.

In almost every case where I’ve seen an opinion war, data about the users has completely dissipated it. Quite frequently, the data proves that neither side was completely right and that there was a completely different way to think about the problem.

All Hail The Arbitrator

Another approach to solving opinion wars is to appoint an final arbitrator. This person is chartered by the team to make decisions and every decision they make is final, no matter what others think about it.

We use this at UIE a lot. Each project has an owner. The owner makes all the final decisions for their project.

Often the project owner isn’t senior in the organization. In fact, they can be the person with the least seniority. They are not expected to ask permission. However, when they aren’t sure, they should ask advice.

Often the advice is conflicting and, occasionally, it’s strongly held. It’s this arbitrator’s responsibility to listen to all the advice and give it serious consideration. More importantly, it’s their responsibility to make the decision.

We’ve established a culture that says it’s the right thing to do make a decision, even if that decision turns out not to go the way people wanted. Even if that decision turns out, in the long run, to have not been the best approach. This is because a decision that moves us forward is better than getting stalled.

Opinion wars can kill a great project. Care needs to be taken to ensure they don’t get in the way.

That doesn’t mean co-located teams will always succeed – they don’t. It doesn’t mean that remote teams will always fail – they don’t either. In fact, we’ve met some awesome teams where team members are remote. (The folks at EightShapes immediately come to mind!)

Design is hard. Great design is really hard.

Teams need to rally every bit of energy they have to work together to produce great designs. They need to talk with each other. They need to see each other’s work.

We’ve observed that teams that work closely together create a common vocabulary. That vocabulary creates words and phrases that separate good design decisions from not-so-good ones. It helps the team discuss what’s on track for their design, versus what’s a distraction.

It’s also critical that teams is regularly discuss their emerging vision. This vision gives team members direction when making tough decisions. As things tiptoe up the borders of that vision, the teams needs a channel for expressing their thoughts.

Teams working remotely limit their communication channels. (This is even worse when the time zones are skewed, especially for those teams that span across oceans.) Establishing the common vocabulary and reinforcing the vision becomes increasingly difficult with remote teams. It’s not impossible, but the amount of extra effort is formidable.

We’re still collecting and analyzing our data on this, but our early results seem very clear. You’re more likely to produce a great design when you’re all in the same space, talking to each other. (War rooms are great for this, especially if you have lots of wall space to hang work-in-progress and have impromptu discussions.)

The next best thing is to have everyone be remote, but in the same (or a very close) time zone. Physically getting together at regular intervals can help quite a bit. (It’s even more helpful if your first project can be co-located.)

Teams talk about using remote conferencing tools, but they aren’t the same. The weird delays that come make simple things like telling a joke more difficult. These meetings adopt a false sense of formality because the changes in how the group interacts. It’s an expensive substitute that doesn’t really live up to its promise.

From our data, the worst case scenario seems to be when some people co-located and some remote. The remote people, not privy to the local conversations, become a type of second-class citizen. These teams seem to have the most trouble producing great results.

If you have any say in the matter, you want to aim for a co-located design team. If you can’t do that, then forcing everyone to be remote might be the next best option.

This is really hard for organizations that aren’t located where all the good talent is, or for those designers who are in places where they can’t be near the rest of their teams. Unfortunately, we’re not seeing any good options here for those folks.

It sucks, but those teams face a much harder challenge that teams that have the luxury of co-location. Great design is hard enough when we’re all in one place.

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.

[Don't forget to read part 2. After this article was originally published, there was a little confusion. I try to clear it up here.]

In our research on personas, we’ve found this works best when the personas are based on real people doing real things. We regularly take teams into the field to meet their users and watch them interact in their own environments. We then capture the interesting bits to assemble our personas. We know we’ve done a great job when we can point to any element of the persona description and talk about the different real users we observed, doing and saying the same things.

What happens when we can’t do the research with the real users? Tamara Adlin does something she calls Ad-Hoc Personas, where the team gathers all the information they already know without doing any new research. Kim Goodwin does something similar that she calls Provisional Personas.

Because we often already know a lot about the people we’ve been selling our product to and supporting, we can build a decent picture of what they are like and what they need. If we combine different viewpoints, like those from sales, training, and support, it’s possible to surface a lot of interesting details to design with.

However, these aren’t as rich as the fully-researched personas we started with. It’s hard to separate out the mythology that forms around users from the reality. The advantage of going into the field is we can see where that mythology breaks down.

It’s possible we could go even farther away from the research by creating personas that are complete fiction. The team could ask, “What do imagine users might be like?” and “What do we think those users might do?” I guess it’s possible personas crafted from complete fiction like this can inspire the team to innovation, but it’s likely not better than self design, which would at a minimum have checks and balances of contact with someone using it.

The “persona purists” argue that completely fictional personas aren’t real personas at all. Their argument is that when we dilute the research component that goes behind the persona, we take risks that a design built from those personas won’t fit the needs of real users as well.

At UIE, we’ve seen multiple teams go down this fictional road, then end up with descriptions that nobody believed in. The team didn’t rally around it and the personas turned out to be a wasted effort. Because they were labeled “personas”, it was impossible to get those teams to buy into a subsequent well-researched persona project. They were completely turned off by the idea of personas and were against any future investment in them.

Should we come up with a different name for those things we create from pure fiction, like “user caricatures” or “fictional users”? (When I asked Kim Goodwin if she had a name for completely fictional personas, she called them “creative writing class exercise.” That sums it up pretty well, I think.) Should we go to efforts to explain that things without research aren’t personas?

What about the Ad-hoc Personas or Provisional Personas? Should we stop calling them personas too?

We don’t want personas to become diluted so much that the term doesn’t have meaning. How do we protect the value of these tools without getting lost in semantic mumbo-jumbo?

She’s been a designer for a long while now, having worked on some impressive projects and developed real skills. As she described the different projects, I could tell, however, that something was missing: how would she grow?

Don’t get me wrong. Each project was pretty neat and jam-packed full of cool challenges that every talented designer would want to sink their teeth into.

I suggested she direct her search in a different direction. I told her to focus on who her next manager should be.

In my job, I get to meet a lot of great designers, some of whom are working on projects that, to an outsider, might be considered dull: accounting applications, chemical analysis equipment, and even tax forms. Yet, they love their work, not because of the subject matter of the project, but because they have a great manager that makes every day fun and challenging (in the good way).

I’ve also met designers who are working on some of today’s sexiest design problems — working with the latest technologies on cutting edge, high visibility, society-changing designs. And they’re miserable because they have a manager that makes each day hard and frustrating.

When you have a great manager, the project barely matters. And when you have a crappy manager, the project barely matters.

The advice I’m giving to senior, more experienced folks is not to think about their next project as much as they think about their next manager. What traits should that manager have? How do they support their team? When things get rough, how do they deliver guidance? Do they regularly give out praise? Do they take a deep interest in the work and in their employee’s future?

I recommend folks interview the entire team and learn what it’s like to work for that manager. What happens when the going gets tough? What examples are there of team members growing, learning, and getting encouragement? Do team members talk about how the manager exhibits the desired traits?

My good friend, Amy Jackson, who works as a talent agent for wünderkind UX designers, suggests you take it a step further and ask the hiring manager for his or her references. Amy says to tell them you want to make the right decision and you need to check them out. Her thinking is that if the hiring manager isn’t secure enough give out sound references, they may be sending a signal. I think there’s something to that.

Great managers are what make a job great. Are you thinking about what you’d like to see in your next manager?

I’ve seen my share of really great designs. However, I’ve also seen many bad designs.

Yet, interestingly enough, I’ve never met anyone who wanted to make a bad design. Nobody said to me, “I’m trying to build the suckiest design out there. Something people will really hate.”

Behind every bad design was a team that wanted to do the right thing. They wanted to make their designs a success. It just didn’t work out that way.

Almost always, it was because something was missing. The designers didn’t know what it would take to get a great design.

Often, they thought they knew. They thought they had the right mix of savvy and intuition to make it work.

Good design, it turns out, is harder than just being a smart guy. You have to know who your users are. You have to know what your users need. You have to know what your technology can and can’t do. You have to know what will truly delight the people you’re designing for.

It goes beyond just knowing stuff. You also need to do stuff and do it well. You have to draw on the language of interaction. You have to experiment and prototype. You have to interpret the feedback you receive and adjust your thinking.

What the folks creating bad designs are missing is good knowledge and skills. Without these, they produce crappy designs.

The good news is we now know, thanks to a ton of research in recent years, what much of the knowledge and skills are. We know how to take designers who regularly produce bad designs and turn them into designers who produce good designs, and eventually, great designs.

It’s a great era to be a designer. There’s so much to learn. There’s so much to do.

So much of a project’s success is determined at its start. If the team comes together and sets the stage properly, everything works out smoothly. People end up with a great vision and solid understanding of how the design should turn out.

Yet, a project that doesn’t get off to the right start will often struggle. The team will find themselves in conflict, important requirements often emerge too late, and good ideas get left on the cutting room floor. Unfortunately, in my work, I see too many projects that have gone down this road and find themselves trying hard to get back on track.

A few years back, I was lucky enough to see Kevin Hoffman present his workshop technique for kicking off projects. It was a completely different approach than any I’d seen before. He showed us how interactive exercises, brainstorming games, and collaborative sketching techniques surfaced important details about the project, while elliciting innovative ideas from everyone on the team.

Since then, he’s had the opportunity to refine his methods in his projects at Happy Cog, a leading web design firm. Happy Cog’s clients have been so impressed, they’ve asked him to teach them his techniques so they can kickoff their other projects successfully.

I’m really pleased that we can have Kevin as part of the User Interface 16 Conference program. As we’ve been working on the plans for his full-day workshop, I’ve gotten a glimpse of just how much fun this day will be. Kevin knows his stuff and has packed the day full of both solid theory and practical exercises. It’s almost criminal that something this fun is a critical work skill.

See the other UI16 Spotlights:

You can catch the sneak preview of UI16 at uiconf.com. (And there’s still a few of the sneak preview $1,349 registrations left. Snag one while they are still available.)

These experts will dive deep and get to the nitty-gritty details that make any designer a UX pro. Look at the intensive full-day workshops we’re putting together for you.

• Brandon Schauer: Immerse your team in an innovative design process that produces refined design ideas in record time.
• Kevin Hoffman: Facilitate productive and insightful kickoff workshops to start your projects with everything you need.
• Hagan Rivers: Employ best practices to simplify your most complex applications with state-of-the-art UI techniques.
• Steve Portigal: Drive your design with effective field research to deliver innovative results.
• Bill Scott: Discover the latest rich interaction techniques for engaging user experiences.
• Kim Goodwin: Compose compelling stories that drive a realistic design process from start to finish.
• Stephanie Sullivan Rewis and Greg Rewis: Enhance your designs with HTML5 and CSS3 without sacrificing your design goals.
• Luke Wroblewski: Integrate mobile design’s best practices and techniques into your process.

Get more information on the workshop topics and speakers at UICONF.com.

Details on the Sneak Preview Site

In the next few weeks, more details about the agenda and workshop will emerge. However, you can get a view into our special sneak preview site now.

And because the site is in the sneak preview mode, we’re offering a sneak preview price – our lowest price, of $1,349.

On Wednesday, July 27 at 1:00 pm, registration will open.

There are 100 spots available at the special low price of $1,349. Once they are gone, they are gone and you’ll have to buy one of the more expensive spots.

There is a way to get a jump start on registration, and learn about exclusive offers and the latest UI16 news. Add your email to the UI16 list at UICONF.com and you’ll automatically get added to the priority group.

Now go see the 8 different design workshops we have in store for you at UICONF.com.

“Hi. I’m a designer at [a big deal company] and I’m considering leaving. The problem I have is my employer has made it very clear I can’t use anything I’ve done here in my portfolio. What should I do?”

The work product lockdown is something many designers face, as they grow their careers and try out new opportunities. It’s natural that prospective future employers will want to see what you’ve done. It’s hard to show them when your designs, sketches, and deliverables are locked up behind a corporate non-disclosure agreement.

In future posts, I’m planning on talking about what people can show in their portfolio if they don’t have work products available (or even if they do), and what the best hiring managers look for when reviewing a portfolio.

However, today I want to talk about this from a different angle: Making it part of the hiring agreement.

I think every designer (especially every experienced, senior designer) considering a job at a new organization should ask explicitly about the hiring organization’s policy on including the work in future portfolios. Their answer should be on the table and negotiated, just like salary and benefits.

When should you ask?

In any hiring process, there’s two stages: The first stage is when you, as the candidate, get the hiring manager and company to fall in love with you. It’s all about showing what you can do and how you’ll help them achieve their goals for the position. You’re goal in this stage is to get the company to think you’re the most awesome person ever for their position and they should jump through every hoop to get you on board.

The second stage is when the company gets you to fall in love with them. Their goal in this stage is to prove to you that they are the best place ever.

It’s in the second stage that we can talk about the portfolio, between when they fall in love with you and when you are deciding the job is the right next step. It’s quite within the rules to say, “What’s your policy on employees including screen shots, sketches, and other work deliverables in their portfolio?”

The hiring manager may not know. It may be something they’ll have to ask HR or even the legal office about. At small companies, they have never even considered the question because you’re the first to ask.

However, it’s a really fair question. And, frankly, any answer is a fair answer.

They might say they want to protect their designs from getting in the hands of the competitors. Therefore their policy is to refuse permission to publish work (especially unreleased design work).

Public companies, who have trouble when future plans are leaked, thereby creating a possibility of “insider information” getting out, are very likely to refuse this without including a Safe Harbor statement. (A safe harbor statement basically says that investors shouldn’t use the information as any indication that the company intends to do anything with it.)

Or they might say they have no problem with you putting the documents into your portfolio, but they’d prefer that you don’t put it in a publicly accessible place, like a web site that anyone can get to. They might like you to only show it to people on an as needed basis, asking those individuals to not share it beyond their own team.

Ideally, they come back and say it’s perfectly fine. There’s not reason you can’t take your work with you as you grown your career. (After all, they benefited from your previous employer’s generosity in this matter. Pay it forward.)

Any of these answers are ok. The point isn’t that you badger them into heading in a direction that they aren’t comfortable with. The point is they tell you, up front, before you take the job.

Once you know, you can decide if this is a deal breaker or not. The fact that you asked tells the hiring manager that it’s an important detail to you. That you’re thinking about your long-term career.

(Of course, one argument is that it sends a message that you’re thinking about leaving the company even before you got the job. Personally, I think that’s ok. In this day and age, we don’t expect life time employees. Any company in denial of that fact may not be the kind of place we want to work. It’s good for an employer to realize that each employee has a choice to stay or go.)

As a discipline, our goal is to bring awareness to the hiring companies. To let them know that this issue is an important one for many professionals.

We’ll know we’ve succeeded when hiring companies start putting their openness to including work products in portfolios into their recruiting ads. When they cite unlocked work products as a benefit of choosing them to work there, we’ve arrived.

Then, someday, this will disappear as an issue, as it becomes part of the standard way we all do business.

He was a seasoned consultant himself and I had asked him what I should know, just starting out. He told me his First Rule of Consulting:

No matter how much you try, you can’t stop people from sticking beans up their nose.

That was it. Beans up the nose. Really.

At the time, I thought he was nuts. Now, I’ve come to realize those are words to live by.

The idea is blindingly simple, actually. Every so often, you’ll run into someone with beans who has, for no good reason, decided to put them up their own nose. Way up there. In a place where beans should not go.

Now, there is no logical explanation for this. There is no way to say, “Yes, I can see exactly why you’d want to do that.” They came to this decision all on their own. The way they got to this decision defies logic.

Yet, here they are. Waiting for the moment when the bean goes up the nose.

And here’s the thing: As an observer of this decision’s outcome, all we can do is cringe. We can try to argue. We can explain in the utmost rational terms why this is a bad idea. We can physically grab their arm and shake the bean from it.

Yet, if they are intent on sticking the bean up the nose, up the nose it will go. There’s nothing you can do to stop it. Pure and simple.

I’m sure you run into them all the time. You’re in a room and someone with power has decided to do something that just doesn’t make sense. You’ve tried logic. You’ve tried rational discourse. Yet, they are intent.

Beans and noses. We have beans. We have a nose. They must be united.

Time and time again, I come across situations where I think, “OMG! They are trying to stick beans up their nose!” It explains what’s happening and what I should do next.

The only thing I can do in a beans-and-noses situation (notice my clever use of flight-attendant grammar forms?) is wait. Wait until the bean is in its final resting place. Then, with a calmness only seen in yoga instructors, I can turn the nose owner and ask, “So, how is that working for you? Did it do everything you’d hoped?”

Of course, if they answer they enjoyed it and it was wonderful, then they are not someone I can relate to or help in any way.

However, if sticking a bean deep into their nostril doesn’t meet the very high expectations they’d had, I can now start talking alternative approaches to reaching those expectations.

Often, when I see an oncoming beans-and-noses scenario unfolding before me, I’ll ask about those expectations. How will they know if it’s successful? What will life be like once the bean is firmly implanted?

Maybe, by talking about the outcome, they might see alternative ways of achieving it that won’t result in the misery that comes from a nasal-based legume implantation experience. They might realize they have choices before they commit the act.

That only works half the time. The other half, the bean starts its wayward journey.

That’s when I move on. I decide I can’t be of further help and go take my skills, experience, and knowledge to others. Others that aren’t about to stick beans up their noses. There are plenty of those. And it’s much less frustrating for everyone involved.

• Ways to tailor your UX design process to the culture of your organization
• How to conduct research with minimal time and budget
• Techniques to get useful design feedback from stakeholders
• How to make your case in organizations that don’t prioritize design

You’ll be able to put UX principles into practice in any organization, and learn how to make the case for user experience design with results, not theory.

Register with the code UNDERCOVER and add lifetime access
to the recording of this seminar for no extra cost.

The details for you:
UX Design when Time, Money, and Support is Limited with Cennydd Bowles
Thursday, July 21 at 1:30pm ET
1:30pm ET / 12:30pm CT / 11:30am MT / 10:30am PT
90 minute online seminar
Learn more about Cennydd’s seminar or save your spot now!

And one last piece of good news! Thanks to New Riders, we’re giving away copies of Cennydd’s book, UNDERCOVER User Experience Design, to random attendees. Winners will be notified within 24 hours of the live seminar. Join us!

It’s definitely something I said. In fact, I can tell you exactly what I said.

However, to do that, we need to revisit some research we’ve conducted over the last few years. We’ve been looking at the process of making design decisions and realized there are five distinct styles. (If you haven’t read or seen me talk about these, go read about them now. Otherwise this won’t make a lot of sense.)

If you’re a designer, any of these styles can produce great results that delights customers. However, for many, the most advanced styles, activity-focused and experience-focused design, are the more desirable projects. That’s where the really cool stuff happens and where the biggest challenges are found.

And this is where I get in trouble with the agency folks. As we’ve been researching these five styles, we found an interesting finding: agencies can’t do activity-focused or experience-focused design.

Many do self design. Some very successful agencies make a lot of money with genius design. (And there are many that do unintentional design, but they probably shouldn’t brag about that.) However, it seems activity-focused and experience-focused design is out of reach of the agency world.

Now, many agencies try to sell themselves as doing this work. And many agencies get clients to hire them to do this work. That’s not what I’m talking about.

I’m talking about creating successful designs using these decision styles. That doesn’t happen with an agency. It can only happen in-house.

Activity-focused design takes a long time. It requires making an investment. The team accrues knowledge over a long period, studying users and their activities, implementing solutions, and seeing how those solutions work. It takes many iterations to do well.

Most agencies aren’t brought in for long-term iterative work. Eventually, all agencies leave. When they leave, the knowledge the team has gained walks out the door with them. Then the client is left with something they don’t know how to maintain or improve. The project fails.

Experience-focused design is even more difficult. The designs often require changes at touch points all over the organization. For example, for a retail business to create a seamless experience, they’ll have to change things on the web site, in the stores, at the call center, in the distribution centers, and in the merchandizing department.

Agencies can’t have this kind of reach. It takes commitment at all levels. It’s too expensive to teach an agency how your business works. They don’t have the political clout to make the hard decisions.

Sure, a company can hire an agency to give them ideas. Agencies have really smart folks with lots of great ideas. But the long-term, in-depth execution has to come from within. The company has to make the commitment to investing on their own.

Needless to say, statements like this don’t make me popular with agencies. Recently, I’ve found myself sitting in front of agency owners, defending this position. They don’t like it at all.

I could be wrong. (It’s happened before.) It could be that an agency could take over the management and operations of a business and build a fabulous design using activity-focused or experience-focused design. I haven’t found one yet, but it could happen.

I just hope that agency’s contract never ends, because then their (now former) client is screwed.

To understand what it takes to create great designs, we’ve spent time with dozens of teams, some of whom are great at getting creative engaging designs out the door. And some that, well, could use a little more practice. Or something.

And we now have a handle on what that something is. In today’s UIEtips, I talk about an important difference between the best and not-so-best teams. Read the article to find out who should be on your team.

What are you doing to keep your team as productive as possible? How are you embracing your extended design team members? Leave your ideas and thoughts below.

Interestingly, it isn’t the designers who get to decide if coding is a valuable skill. It’s the hiring managers. And right now, based on today’s jobs market, it’s pretty clear where they stand. Many want to hire super designers—designers who can also code.

While hiring super designers has always been floating around, the real demand has come recently out of Silicon Valley startups. With a couple of high-profile design successes, like Apple and Mint.com, the investors and entrepreneurs in the Valley now have a new appreciation for the work of designers.

Startups, however, try to run as lean as possible, so they look for talent with a broad set of skills. The thinking among the Valley folk is, if they can get someone who does both, they can get their product from concept to ship with an ideal set of resources. Otherwise they’d have to hire two people. Or do without one.

We’ve proven for years that you can ship a product without a designer. Many companies have done that, and while it doesn’t make for a great result, it does ship. However, it’s much harder to ship a software product without a coder, if not near impossible.

That’s why, right now, there are dozens of startups looking to pay big bucks to find the coding super designer. The demand is high and those designers who have proven, practiced coding skills can demand a higher salary than those who don’t.

What about the non-startup portion of the hiring world? Right now, the established organizations find it easier to have larger teams with separate developers and designers.

Yet, that doesn’t make the designer that can code any less valuable to them. A team with two coding designers is more flexible and capable than a team with one non-coding designer and a non-designing developer. The flexible team can produce well-designed results better and faster.

Coding and designing are collections of skills. What we’ve learned is teams with a better distribution of skills, not segmented by roles, produce better results. Having a team filled with individuals who can both code and design will be more effective in the long run than a team where the skills are divided up.

If you’re a designer, you don’t have to learn to code. But if you do, and you get good at it, you’ll find more opportunities as time goes on.

The Most Valuable UX Person In The World

She builds her wireframes with real wire from ancient hand-smelted Ukranian steel.
Her worst personas could kick the ass of your best personas.
His pattern library is now in the Library of Congress.
When she explains good design visuals, the only thing Edward Tufte can add is “What she said.”
He’s organized his wine cellar in order of awesome.
Wikileaks is ready to release her sketchbooks just because they’re cool.
He only sketches on the front of the napkin.
He built the world’s biggest web site, using only his left hand.
Last season’s American Idol featured her concept maps.
His research finds customers desire to research his behavior.
He is the only person Don Norman agrees with.
She makes her own icons out of straw.
Software bugs specifically ask for her to fix them.
He defined the damn thing, then moved on.
Her study participants screen themselves. Out.
Her interactions are the basis for everyone else’s designs.
Scalpers sell tickets to his project kickoff meetings.
He is already coding in HTML6. And has been for a decade.

They are the most valuable UX person in the world.
“Design well, my friend.”

What would you add to this list? Leave your own ideas of the Most Valuable UX Person In The World in the comments. I’ll be sprinkling your best suggestions through out my presentation, giving you full credit.

Oh, by the way, the early bird price for the Summit ends this Friday, February 18. Sign up here. I’d love to see you there.

The goal is to get great ideas on the table and to get everyone excited by the potential of this new undertaking. We want everyone to be heard and have a chance to get their thinking out.

In today’s UIEtips, I explore two techniques I often use to help me get team ideas out and on the table. They are simple to execute and powerful when done well. I wanted you to have a chance to try them yourselves.

Read the article, Equalizing Opinions – Two Simple Tricks for Meeting Facilitators.

When it comes to Kickoff meetings, we’re in love with what Kevin Hoffman has to say. He’s been exploring how folks bring their projects into being and has put together a collection of masterful techniques. You’ll want to tune in to Kevin’s UIE Virtual Seminar on Kickoff Meetings, this Thursday, February 3 at 1:30pm ET. See all the details.

What tricks do you use for getting everyone’s opinions out during your meetings? Share your techniques below.

On Monday, we published part 1 of an article by Kevin Hoffman, Kick Ass Kickoff Meetings. In the article, Kevin explains the advance work that should take place prior to the kickoff meeting, and the type of questions you should ask your stakeholders. You may want to read part 1 before reading part 2.

In part 2, Kevin dives deep into a plethora of exercises to use in kickoff meetings including a design studio activity. He also gives a list of suggestions on how a virtual participant can feel more present at the meeting.

Read the conclusion of Kick Ass Kickoff Meetings.

After reading part 1 and 2, you’re well on your way to producing kick ass kickoff meetings. But there’s one more resource that can help you. Kevin will be delivering our next virtual seminar on this very topic. He’ll share lots of great examples and the lessons the team at Happy Cog learned from one too many expensive and unproductive kickoffs. Learn more about Kevin’s seminar.

What do you do to jump-start the kickoff meetings and prevent them from being a ho-hum meetings? Share your thoughts with us below.

My thinking about Hands and Brains have come from a distinction between, in my mind, contracting and consulting work. We get a ton of calls at UIE to help people with usability and design work, but it’s clear after a few moments of discussion with the prospective client that they’re looking for contracting—someone to do the work for them and not for consulting—someone to show them how to get them to the next level.

UIE doesn’t do contracting, but lots of folks do, so I’m always on the lookout for people who are great contractors. Understanding the distinction is really important and I wrote the Johnny Holland essays to help create a language around the two types.

Apparently, I hit a nerve, because a lot of folks have been reacting to the piece in ways I didn’t expect. I wanted to take a moment and discuss some of those reactions.

What If I Do Both?

This seems to be the biggest reaction, by far. Someone who is an information architect, for example, says they are quite capable of doing both the Hands work and the Brains work. So, why should they have to choose one?

It’s true that you can be quite capable of doing both. However, most projects don’t want or need both. They either want Hands, because they don’t have enough resources and need the work completed. Or they want Brains, because they are stuck and can’t figure out how to bring their designs to a new level.

So, it’s important, when talking about a potential project to discover which one it requires, then decide, do I want to do that? Doing one basically traps you for that client—once they see you as Hands, you’l always be Hands to them. Same for Brains. It’s important to make your choice carefully.

Strategy Is Good, But Without Execution, It Fails

100% Correct. But that doesn’t mean the people who do strategy are the ones doing the execution. In fact, almost always, it’s the wrong thing to do.

The strategy has to include how the job will get done. The strategist has to know who will do the execution work.

Many Brains consultants will help find the Hands contractors/employees to get the job done. They’ll help build the team with those who are the most capable.

Execution is key but being the one doing the execution isn’t.

To Be Great At Brains, I Have To Master Hands

Absolutely. Brains have to know how to do the work of Hands. It’s gotta be second nature. They’ve got to understand how it’s done and what excellent work looks like.

However, once you start doing Brains work, it’s rare you’ll do that work again. You need to know what to expect from the Hands who will be working for you, but you won’t do it yourself.

Think of the executive chef in a restaurant. They have to know how to prep and cook every recipe. But that doesn’t mean they do that for every meal. In fact, it’s a bad use of resources and talent.

This is All About the Economics

Doing Hands work takes a long time, because it’s rigorous production work. Brains work doesn’t take as long, to deliver the same value to the team.

Hands work, because it takes longer, charges a smaller hourly rate. Brains work, because it’s shorter, charges more. Often two to three times as much (or more). Where Hands work might charge $50 to $75 per hour, Brains will charge $150 to $300 per hour. (Many really good Brains consultants charge a *lot* more.) A Hand’s engagement could last months or even years. Brain’s engagements rarely go beyond weeks and are sometimes only a few days or hours.

This is why, at the client, you can’t do both. If you try to do both Brains and Hands work on a project, you’ve got a rate mismatch. You’re either charging too little or too much for part of the work you’re doing. (And explaining to the client why you’re changing rates in the middle won’t be easy.)

Even if you love doing both, you need to decide where you’re want to focus. Go for the joy of seeing your work produced by delivering great Hands work. Have the excitement of creative big-picture problem solving with awesome Brains work. Pick your pleasure and go for it.

For the past 10 years, Jared Spool and our research team at User Interface Engineering studied the secrets behind successful teams and the factors driving their results. In late March, Jared kicked off the Web App Masters Tour in San Diego sharing this research with attendees.

Once again, Luke Wroblewski did a great job capturing Jared’s presentation. We’re reprinting Luke’s blog post from LukeW Ideation and Design.

Here is Luke’s take on Jared’s presentation.

In his opening presentation at the Web App Masters Tour in San Diego, CA, Jared Spool outlined how design organizations can deliver the holistic experiences Web applications users increasingly expect.

• It’s no longer about the application—its about the experience. When done well, good design is invisible. To illustrate, you only think about the air conditioning when it is not working.
• Web applications are at the intersection of user needs, business goals, and what the technology allows us to do. The design process is about compromise. We need to constantly make decisions that balance these objectives.
• Jared’s team researched 60 different organizations that created good user experiences. They found that size, organizational structure, process, management, etc. did not determine what drove great product design.
• Vision, Feedback, and Culture were the three elements that were consistently present in teams that delivered good experiences.
• Vision: can everyone on the team describe the experience of using your product five years from now? What is the design you are working towards?
• Feedback: in the last six weeks, have you spent at least two hours watching someone use your design or a competitor’s design? You need team members to have first-hand exposure to people using your product. Many teams don’t use the products they design.
• Two hours gives you enough time to see the subtleties and nuances of how people use products. It has to be recent (last six weeks) or else it is forgotten. Once you start to see the same problems over and over again, you focus and fix them. The best organizations do this weekly.
• You can gather feedback with usability testing, field studies, and first-hand persona development. But the key part is exposure. Try to increase hours and frequency. Don’t think in terms of number of participants—think in terms of exposure (hours and frequency).
• Design agents to impact experience: core team (makes the bulk of the decisions) and secondary agents (impact the total experience customers have).
• Culture: in the last six weeks, have you rewarded someone for a major design failure? Every failure is an opportunity to learn. When you celebrate failure, you get to ask some questions—what did we learn about our users, ourselves, our product?
• As the number of things people need to consider for Web applications has increased, the size of the teams has actually decreased.
• The best organizations thought in terms of people’s skills not roles. They worked on building everyone’s skills by giving people opportunities to learn.
• Curation and editing are key skills for Web application design. Need to be vigilant about removing what is not necessary. Curation is as much about what isn’t included as what is.
• Designing for embraceable change: when people learn to use something, it’s hard to change existing behaviors.
• The kitchen cabinet problem: people know what is in their kitchen cabinets. If we change where things are—people’s existing routines are disrupted.
• User assistance can help people through change.

You can hear more about the research Jared and the UIE team did, along with another presentation from Jared, Turning Back to the Future, at the Web App Masters Tour. The Tour continues in Minneapolis, April 27-28, Philadelphia, June 7-8, and Seattle on July 12-13. Learn more about the program at www.UIETour.com

Until April 29, register for any of the Tour cities for $795 when you use the promotion code TOURBLOG. Learn more about the tour at www.UIETour.com

(Oh, and by the way, our last event sold out, so you’ll want to Register your team early!)

When you spend time with your customers, it’s an opportunity to learn how to move your design forward. You don’t want to leave important information “on the table”—information that can give you a more complete understanding of how to move your vision forward. You might act on incomplete detail that creates risk when it forces you to guess what the users need. Worse, the partial insight you have may take your design team in the wrong direction.

User research is an expensive endeavor. Make sure you’re prepared to get the most out of every minute that you’re with your users. Come home with a deep insight into their thinking, their lives, and how you can change their experience for the better.

Steve Portigal will show your team the art of asking the question. You might visit the user in their office or home, have them come to you for a usability test, or even have a chance encounter at a trade show or while waiting for an airplane. Do you know what to ask? Do you know what to listen for, to extract the critical detail of what they can tell you about your design?

Steve will help you prepare your team for any opportunity, be it formal user research or less structured, ad-hoc research. He’ll also give you tips on how to work with your stakeholders and executives, who may also be meeting potential customers and users, so they know what to ask and how to listen—integrating their efforts into the research team. (Wouldn’t it be great if they understood why you’re doing what you’re doing?)

Get your team asking good questions, the right questions, with this fantastic seminar. Honing this skill will be a great addition to their Toolbox. Register your team before January 19, with the promotion code TOOLBOX, and I’ll also send you the link to a fabulous webinar Kate Gomoll did for us, Field Studies: The Ultimate Tool in Your Usability Toolbox.

Are you prepared for meeting someone who could be using your next design? How do you make sure you get into their head, learn what their life is all about, and get the information you need to build something truly innovative and delightful? We’d love to hear your ideas and about your experiences below.

On January 7 Peter Morville will discuss Search Design Patterns, and in the same session, Mark Burrell will tell you how to then use them.

Later in the month, on January 28, Steve Portigal will present to you his thoughts on studying your users in their own context, Ethnography.

During last year’s UIE Roadshow, our audiences couldn’t get enough on the topic of personas. So, on February 18, we’ve asked Tamara Adlin to talk about The Power of Ad-hoc Personas. Personas can be your ticket to lasting organizational clarity… and it doesn’t take a ton of costly research.

With his book, Prototyping: A Practitioner’s Guide just hitting the bookstore shelves, Todd Zaki Warfel will help you flesh out your design ideas, test your assumptions, and gather real-time feedback from users on March 29.

In the Spring, look for Kristina Halvorson to help you with your content strategy and Louis Rosenfeld to dive deep on Search Analytics. And there is much more in the works.

Until December 3, you can still sign your team up for the UIE Virtual Seminar Subscription programs . Not only is it a tremendous savings, but you get the benefit of lifetime access to each recording and the ease of registering and paying just one time.

We also plan to unveil our plan for our User Experience Training Library. Believe it or not, there is a method to our madness.

Have you ever attended a UIE Virtual Seminar? What do you like best about them? How has your team maximized what it gets out of these learning events? Share your thoughts and experiences below.

Subscribe to our podcast via

How many IBM or General Electric television ads do we need to see before we are groaning at the mention of the word “innovation”? It’s too late for me, personally. But that doesn’t mean real innovation is dead. Steve Jobs has been quoted saying Apple will innovate their way through tight times. This past week Apple announced record revenues for the past quarter on impressive sales of premium products that aren’t supposed to sell well during down times. How are they flourishing while their competition is not?

How can you bring real innovation into your projects? That’s what I asked Scott Berkun when we spoke earlier this month. Scott is one of our favorite speakers on the topic of innovation and project management. He tells us you have to be opportunistic and start small. High-priority challenges may be a tempting place to start, but he suggested to first look at low-hanging fruit. You can build momentum for positive change by racking up a number of small wins that together move the project in the right direction. Having these small successes under your belt gives you more influence when attempting larger changes later on.

True innovation starts with you allowing yourself to be creative and recording your ideas religiously in a safe place like a notebook or sketchpad. Don’t self-censor, either. Initial precision and “getting it right” are the antithesis of creativity. It’s essential to let the ideas flow, and your ideas will improve as you continue to record them. Your journal is an incubator of ideas. Not every idea will be a success, and some will be terrible! But Scott says that’s OK. When an opportunity for change arises, you’ll have a treasure trove of ideas to pick though.

Once you have an idea, you need to involve other people to make it happen. The key differentiator in successful, innovative environments is group trust. People need to feel they are safe to share ideas with their team. If you work in an environment where you’re fearful of this, find one person on your team who is the most enthusiastic and try sharing with them. Once you have other people on board with your idea, you’ll have an easier time sharing it with others.

A common difficulty is honest and constructive critique among teams and individuals. This is an area where the most successful teams have excelled. Good critiques take practice and trust within your team. This usually requires time and commitment.

What experiences have you had trying to introduce new ideas? Politics and “we’ve tried that before” getting in the way? Let us hear about it in the comments.

In this popular presentation, Ethan Marcotte teaches about the collaborative process through four detailed case studies. The case studies demonstrate important before and after detail of the lesson to be learned. They also happen to be major sites you know of and can visit today: The Today Show, The 2008 Sundance Film Festival, W3C, and New York Magazine.

If you’re a designer, a developer, or manage a team, you’ll want to see this presentation. Ethan will show you ways to be successful in critical project transitions. There’s no better person to see both sides of the designer/developer relationship than Ethan Marcotte. Many in our industry greatly respect him and consider him to be someone who does groundbreaking work. Ethan has worked with New York Magazine, Harvard University, Disney, and State Street Bank, just to name a few.

UIE Virtual Seminar
Comps vs. Code: Case Studies on Collaboration Between Site Designers & Developers
with Ethan Marcotte
Thursday July 30, 2009, 1:30pm ET
90-minute online presentation

Read more about Comps vs. Code, or see the 3-minute preview Ethan put together, to help you understand what to expect out of this seminar.

You may have noticed that the last two UIEtips articles concentrated on UX teams. The first article was on Building and Managing a Successful UX Team. The second article was Five Techniques for Getting Buy-In for Usability Testing. Following the rule of three principal, I’m focusing this next article, once again, on the UX team. Today’s article goes back to December 2007 and concentrates on various skills required for a successful UX team.

Over the last 9 years, we’ve been looking carefully at how to put a user experience team together. We’ve studied dozens of teams, some that are very good at production great designs, while others regularly struggle to produce anything that makes users happy. As we’ve looked at the differences between the teams, we’ve started to notice some patterns.

One emerging pattern focuses on the skills found in the team. While it’s a no-brainer to say that the more skilled the team, the better the results, it’s more difficult to hone in on the specific skills that make a difference.

Our research has isolated eighteen skills that the best teams all master. We’ve divided these into two groups: Core UX Skills that are unique to the user experience process and Enterprise UX Skills that the team shares with other parts of the organization, such as marketing, IT, and product management.

In this issue of UIEtips, I describe these skills and a simple method for assessing where a team is at. Managers can use this assessment to identify areas of improvements for the team as a whole and individual members.

Read today’s article.

Have you assessed your team’s capabilities? What techniques have you used? Are there skills you think are important that aren’t on the list? We’d love to hear from you. Leave your thoughts below.

[If you manage a UX team, or you're part of a UX team, I think you'll find our next UIE Virtual Seminar of great interest. This Wednesday, June 17, Sarah Bloomer will present Upgrading Your UX Team. Some of the topics Sarah will touch on in this Virtual Seminar include: the key ingredients of developing a successful UX team, how to setup your team, and where it fits within the organization. Learn more about the next UIE Virtual Seminar.]

Knowing how to identify and communicate the value of a User Experience project will gain you design strategy approval and support throughout the organization. Most organizations we work with understand the need for UX efforts, yet they still struggle with how to best incorporate the team into the development process.

Back in 2006, former UIE staff member, Christine Perfetti interviewed Sarah Bloomer and Susan Wolfe, two premier User Experience experts, to discuss how organizations can make their UX practices a success. I find this interview is still dead-on three years later.

One of the most frequent questions we’re asked is how do you go about setting up a UX team. What criteria should I use in the hiring processes, and how do I get executive buy-in on the UX vision?  To answer these questions, and many others, we’ve asked Sarah Bloomer to present our next UIE Virtual Seminar, Upgrading Your UX Team. We’re offering the recording of this presentation at no additional cost when you register with the promotion code MYARCHIVE.

Are you challenged with building a UX team within your organization? Is your team struggling to get support and buy-in from your organization? How have you gotten your organization onboard? Join the discussion below.

Want help in developing that solid strategy? We’ve asked Sarah Bloomer, a User Experience professional who’s helped several companies set up internal UX teams, to help you do exactly that. You’ll learn 4 strategies to deal with resistance to your team’s efforts. If management has difficulty understanding how the vision and strategy are shared throughout the organization, then you’ll definitely want them to attend this UIE Virtual Seminar. And don’t forget, if you have team members that can’t attend the live date, register with the promotion code MYARCHIVE to get lifetime access to the recording. Register today!

UIE Virtual Seminar
Upgrading your UX Team
with Sarah Bloomer
Wednesday, June 17, 2009, 1:30pm ET
90-minute online presentation

Sarah put together a great preview for you, to help you understand what to expect out of this seminar.
Click here to visit the site page with the preview.

In advance of the presentation, we’d love to hear from you. As a team member or team leader, what are your biggest challenges? What sort of resistance do you meet, and how do you overcome it? What is your organization’s culture like, and what opportunities exist there? We’d love to hear your thoughts, questions, and concerns. Please share your thoughts below.

To help you understand what you can expect out of this seminar, Scott has put together a preview for you:

Don’t miss this presentation! Register with the promotion code THREEPOINTS and get both our lowest rate of $99, and lifetime access to the recording of this talk at no additional cost. Share it with others in your organization to watch whenever they want, as often as they want.

In advance of the presentation, we’d love to hear from you. How is failure perceived in your organization? When is the last time you celebrated a failure? Or do you think failure should be avoided at all costs? When failure does happen, how does your team address it, or is it the “white elephant in the room?” Share your thoughts below.

Determine if this seminar is right for you and your team by reviewing  Jared’s preview, just press the green “play” arrow.

As an added incentive to attend, use the Promotion Code MYARCHIVE to receive free lifetime access to the recorded presentation. You or anyone in your organization can watch it whenever you want, as often as you want!

Register Today!

In advance of the presentation, we’d love to hear from you. How does your team currently come to consensus, and how can you be sure the right decision has been made?  What criteria is used for your decision making?  How do you get everyone on board, and how do you overcome objections?  Share your thoughts below.

While the successful team needs all of these disciplines, there are more of them than most teams have members. This creates a challenge as teams need to spread the experience, knowledge, and skills across multiple team members, turning them from specialists into generalists.

In today’s UIEtips article, I share some of our recent findings in how teams make the call: when should they hire a specialist and when will a generalist work better? Whether you’re a team manager or someone looking to direct their career choices, I think our findings will interest you.

Read the article – Ideal UX Team Makeup: Specialists, Generalists, or Compartmentalists.

What does your organization do to embrace its failures? We’d love to hear from you. Share your thoughts below.

• Because of the economic downturn (due to the rising fuel costs and mortgage market crisis), some companies are laying off and some are disappearing outright.
• Because executives understand the competitive value of creating great experiences, user experience professionals are in great demand.

This convergence means you should have your resume and references up to date. Even if you’re likely only to change jobs within your current organization, having these prepared can make the difference between having a choice and missing an opportunity.

As a hiring manager, I often find people don’t really know how to prepare their references well. This podcast, from the fine folks at Manager Tools, does a great job of explaining how to recruit, prepare, and share your references. It should be a must for anyone who thinks they’d like to grow into a new job, either in the near or far future.

The podcast blurb:

This cast tells you how to handle requests for your references when engaged in a job search.

Even though “References Available Upon Request” is no longer a good idea, reference CHECKING is on the rise and will only increase in the coming years. It seems like since resumes don’t include the age-old line — the why of which we’ll share — somehow far too many job seekers are caught off-guard by reference requests. Ahh, Horstman’s Christmas Rule!

We’ll tell you how to manage and share your references in this cast. And hey, if you’re maintaining your network, this one is EASY!

Sharing Your References at Manager-Tools.com

Testing Your Critiquing Skills: Site Navigation
Date: Wednesday, September 24th, 2008
Time: 1pm ET / Noon CT / 11am MT / 10am PT

When looking over someone else’s design, how do you ensure you’re delivering valuable insights that bring new perspectives to the table?

The best critique not only delivers value to the original designer, but to everyone involved, because it raises the discourse to the underlying fundamentals and goals, not just the specifics of color and font size. Learning to critique well is like many other skills: the more you practice, the better you get.

You’ll know you’ve delivered a great critique when:

* The designer is receptive and engaged in the discussion, instead of being defensive and argumentative
* The designer becomes introspective and talks about how they want to revisit some of the underlying precepts of the design
* Other team members use the critique to look at other on-going work

You can read the full seminar details here.

What many people don’t know is that Flickr wasn’t originally a site for sharing photos. It was originally conceived as an online game, “The Game Neverending.” But when the design team started facing business obstacles with the game, they quickly shifted their priorities and recognized the value of the photosharing application. As a result, Flickr fundamentally changed the way we look at web applications.

At UIE, we hear all the time from clients working to build products and sites that capture the market, hoping to duplicate the success of sites such as Flickr. If you’re challenged with creating innovative designs, you’ll really want to read Scott Berkun’s writings on the subject. Scott is the author of the book, “The Myths of Innovation,” and an expert when it comes to the history of innovation.

Also, in this week’s article for our email newsletter, we’re republishing a great interview UIE’s Christine Perfetti conducted with Scott last year about his research in the area of innovation. This is one of our most popular articles. If you missed it, I think you’ll really enjoy it.

You can check out Christine’s interview with Scott here.

How does your design team go about developing innovative designs? Please share your thoughts below.

That’s exactly the situation that our friend and second-time Web App Summit presenter, Sean Kane, now finds himself in. Sean recently left Netflix to be the founder of a new company, GetListed, where he is constructing his UX team from the ground up.

At Netflix, Sean had resources most of us could only dream of: a top-notch team, a wealth of user data, and a management team that truly understands how UX can play an important role. Under his watch, the site grew 14-fold, so he knows what he’s doing.

Yet, as many of us know, there are challenges to being in a small organization with limited resources and only a sliver of real data about who the users will be. So, we’re watching closely as Sean brings his talents, skills, and experience to his new venture.

In this issue of UIEtips, Sean shares with us his initial efforts to bootstrapping his user experience team. He talks about how he’s building the GetListed team and his initial strategy for creating a world-class design, much like he did at Netflix.

Read today’s article.

Have you assessed your team’s capabilities? What techniques have you used? Are there skills you think are important that aren’t on the list? We’d love to hear from you. Leave your thoughts below.

[Sean will be updating us on his adventure at the Web App Summit 2008, in San Diego, CA, March 26-28. We've already started to fill up, but there's a few seats left. You'll want to register soon because this event will sell out.You can see the entire program, and find out how to get your free limited-edition red iPod nano by registering by December 18th, by visiting the the Summit site.]

Jen wrote:

I enjoyed your December 10th article, on assessing UX skills, so I sent it around to my colleagues. It was favorably received, but the folks on the alias found that one core skill was missing: the creation of UI mockups, particularly interactive mockups.

The places where I saw the creation of mockups implied were: under Interaction design, “creating design deliverables such as wireframes and design priority descriptions.” and in the methods section, “Team members need to understand how to integrate their work with development approaches, such as Agile techniques.”

However, you never come right out and say it’s a skill …

It is indeed a skill. Actually, several, I think.

You need to work with the tools available, whether it be HTML, Flash, paper, or any new tools coming down the pike, like Adobe Thermo. Knowing which tools is best for the situation your in is an important skill.

You also need to know what makes a good prototype and how to get the most from it. Prototypes should be smoke and mirrors — not full running versions. Knowing what functionality to omit from the prototype is a skill.

Another critical skill is knowing how to collect usability data from a prototype. Prototypes that users can actually use (versus just look at and say, “Yah, I don’t like the fonts”) is an important technique during design.

I’d bundle all of these skills under Interaction Design.

We don’t use personas. We use ourselves. I believe personas lead to a false sense of understanding at the deepest, most critical levels.

Every product we build is a product we build for ourselves to solve our own problems. We recognize our problems aren’t unique. In fact, our problems are probably a lot like your problems. So we bundle up the solutions to our problems in the form of web-based software and offer them for sale.

We recognize not everyone shares our problems, our point of view, or our opinions, but that verdict’s the same if you use personas. Making decisions based on real opinions trumps making decisions based on imaginary opinions.

I’ve never been a big believer in personas. They’re artificial, abstract, and fictitious. I don’t think you can build a great product for a person that doesn’t exist.

There was a lot of discussion on Jason’s blog, with many sentiments similar to this one from Mimo:

I never heard of Personas before. Now I read it on wikipedia. The idea sounds interesting. But I think at the end of the day it is crap. The product is always shaped by two things. YOUR experience (your present ego and YOUR idea (your future ego).

So, to add into the fray, here’s my thoughts on using personas:

It takes virtually no skill to build something crappy

No one is going to make you use personas. If you create a design without using personas, I’ll promise you the sun will continue to rise on schedule, without variation. The universe will remain intact.

However, how do you know you’re actually meeting the needs of your users? After all, that is why you were designing in the first place, right?

Some products, like the tools built by 37Signals, don’t need personas. Not because the folks at 37Signals have any special powers, but because they themselves are the personas they want to build for. They build tools they like to use themselves. For them, that will work great.

Not all teams have that luxury. A hospital IT team, building software systems used by critical care nurses in the hospital’s pediatric intensitve care unit, are not building tools they will use themselves. They are building tools used by others whose education, experience, goals, contexts, and tasks are extremely different.

A well-built, robust persona set can help educate the IT design team on what it’s like to be a critical care pediatric ICU nurse and the things they need to deal with. This information will inform their designs. And good personas help inform the design process.

Oh My God! They’re Made of People!

In his post, Jason says:

Personas don’t
Personas don’t talk back. Personas can’t answer questions. Personas don’t have opinions. Personas can’t tell you when something just doesn’t feel right. Personas can’t tell you when a sentence doesn’t make sense. Personas don’t get frustrated. Personas aren’t pressed for time. Personas aren’t moody. Personas can’t click things. Personas can’t make mistakes. Personas can’t make value judgements. Personas don’t use products. Personas aren’t real.

People do
People talk back. People answer questions. People have opinions. People can tell you when something just doesn’t feel right. People can tell you when a sentence doesn’t make sense. People get frustrated. People are pressed for time. People are moody. People click things. People make mistakes. People make value judgements. People use products. People are real.

It’s clear that Jason hasn’t used robust personas, because, when designed well, they do all these things. Jason hasn’t had the Soylent Green moment to realize that well-designed and researched personas are made of real people — real people who you can ask questions of, observe their frustrations, and discover their true goals.

I can see where Jason’s coming from. Recently we conducted a study of several dozen organizations who claimed to use personas. Less than 5% actually conducted field research to inform their personas. The remaining 95% just made up the descriptions from internal guesswork.

If you’re just going to guess on the personas, why bother? Just design for yourself, like the 37Signals team does.

However, when you do the field studies, you create relationships with the people in your research. You can return to those people and ask them questions. You can learn about the things they do.

The persona becomes a package for containing what you’ve learned from your field research. A package that is transportable to everyone on the team, so they can have the same benefits of knowing the users as you have.

Once you have well-designed, robust personas, you can take advantage of the benefits that come from them:

• Preventing Grounding
• Using the Oral Tradition
• Role Playing

In our research, teams that utilize robust personas find they create better designs, especially for things they wouldn’t normally use themselves.

I’m going to talk in great length today about building robust personas in our latest virtual seminar. See the description for more information. (It’s available live today and there’s still plenty of room. There will be a recording available shortly.)

Recently, Cheryl got back to me about her company’s reaction:

A few months back you kindly responded to my inquiry about facilitating a KJ Analysis session. The team did a great job and I was relieved as a couple of the team’s members could have easily hijacked the agenda. As you pointed out, by not allowing any discussion until the end of the process, the team — the entire team — was able to talk about the important stuff.

Within a week of facilitating that exercise, I was contacted by a several colleagues who were going to be leading a similar team exercise and had heard through the grapevine how well our activity went using the KJ Technique. I shared what I had learned from your presentation and my own facilitator notes (basically index cards with keywords so I would remember what to do next). I didn’t think to much about until yesterday, my Senior Manger made a comment about the KJ technique sweeping the company. I guess a lot of teams have adopted it as a means to brainstorm and prioritize without spiralling into the black hole of fruitless discussion.

So, thanks Jared! You get another (because I must assume you receive so many) pat on the back. Once again I was able to take something from one of your virtual seminars and put it to work!

Thanks, Cheryl!

Have you had good (or not-so-good) results from something you’ve learned from us? We’d love to hear about it.

In the method, teams brainstorm on potential answers to the focus question, group the answers, name each group, then vote on the group names that best answer the question. The method, in less than 45-minutes, allows teams to come to a democratic consensus on an answer, avoiding endless discussion for elements that turn out to be unimportant.

Our friend Cheryl recently decided to try the technique with her team and ran into a little confusion. Here’s what she wrote us:

After taking your “Making Sense of Usability Test and Field Study Data” webinar, I decided to try out the KJ Analysis with a team. I went t the UIE website and read the paper you published in May 2004. I ran a pilot with a group and ran into some problems.

I stumbled when it came to [the "Naming each group"] step and [the "Voting on the most important groups"] step in the technique. Folks had used different names for each of the groups of post-its. When I asked them to rank the groups, folks recorded their stars on their on group post-it — so a group may have had 9 stars, but it appeared as 3 stars on each of the three group post-its.

How do you resolve different names for groups? I’m a bit desperate — I need to figure things out by then end of the week. The “real” KJ process will occur early next week.

The problem Cheryl had is common for people trying this for the first time. The reason for these two steps is to work out the problems she encountered, so let me share some guidelines:

• When people are naming each group, they should be reading through the stickies and looking for a “theme”. The name will represent what they think the theme will be.


Naming Each Group: Group names are on the smaller orange and green stickies.

• Sometimes, groups form with multiple themes. If this is the case, you want to split the groups up. (You don’t want to discuss this — just instruct anyone who discovers this to go ahead and do it.)
• Similarly, you may discover, in the course of identifying the themes and naming the groups that more than one existing group share the same theme. In that case, you can merge them. (Again, no discussion necessary — just do it.)
• Two people, reading the same group, may see different themes and give them different names. Perfectly natural and it works out just fine. In fact, we instruct the team that they should attempt to give their own name to every group. The only reason they can skip naming a group is if someone else has “already used exactly the same words” they would’ve used to describe it. This will often encourage 2-3 names on many groups.
• When it comes time to vote for their personal “top groups” — the ones they think are most important to addressing the focus question (the focus question is the question being answered by the exercise) — it’s ok if team members put votes on different names within the same group. They should put the votes on the group name that best represents their thinking of the focus question.


Voting on Groups: Each team member chooses the group names that best address the focus question.

• When you collect up the groups to rank overall, you collect up all the group names with votes on them. Don’t worry about keeping group names from the same group together at this point. Just rank them as if they were from different groups.
• During the “Combining Like Categories” step, you’ll ask the question, “Are these two groups the same?” While they may have come from the same initial groups, they may actually mean different things. Only if you can easily substitute one for the other, do you combine their votes. So, if the group has complete consensus they mean the same thing, the fact they started with separate names will come out in the wash. If someone believes they mean something different, you’ll have an important discussion as to why they are different and then let them stand on their own in the final ranking.


Ranking Top Groups: Team combines the votes of groups names that are true synonyms.

The result of this is that group names that are true synonyms get resolved and their votes are combined. Group names that turn out to be different perspectives on the same results end up standing on their own. You’ve allowed these different perspectives to emerge with just the right amount of discussion based on their importance to the task (it doesn’t matter if they don’t get anyone’s vote) and the team is still spending the most “discussion time” talking about the most important outcomes of the exercise — not discussing the un-important edge conditions (which is where many teams get trapped).

Flickr, the online photosharing web site, changed everything for web applications. For one of the first times, the developers of Flickr combined elements of Flash and AJAX in a seamless form, along with the HTML page.

What many people don’t know is that Flickr wasn’t originally a site for sharing photos. It was originally conceived as an online game, “The Game Neverending.” But when the design team started facing business obstacles with the game, they quickly shifted their priorities and recognized the value of the photosharing application. As a result, Flickr fundamentally changed the way we look at web applications.

At UIE, we hear all the time from clients working to build products and sites that capture the market, hoping to duplicate the success of sites such as Flickr. If you’re challenged with creating innovative designs, I think you’ll really want to read Scott Berkun’s writings on the subject. Scott is the author of the new book, “The Myths of Innovation,” and an expert when it comes to the history of innovation.

In this week’s article, UIE’s Christine Perfetti sat down with Scott to talk about his new book and his research in the area of innovation. I think you’ll really enjoy it.

Read today’s UIEtips article.

How does your design team go about developing innovative designs? Join the discussion below about this week’s topic below.

[If you find this article interesting, you'll definitely want to attend this year's UI12 Conference, where Scott Berkun present his full-day seminar: The Myths of Innovation -- How to Lead Breakthrough Projects. In this seminar, you'll gain the essential skills and core concepts needed to lead innovative projects within your organization.]

Improvements happen when the design truly eliminates frustration. Organizations benefit from those improvements when the eliminated frustration increases sales (due to a better user experience) or reduces expenses (due to decreased support or development costs).

One problem we often see, however, is when the user researchers get overzealous in their improvement suggestions. They start to make recommendations in cases where there may not be any clear evidence the change will eliminate frustration or improve the design in a measurable way.

The worst case scenario is when someone issues a poorly thought out recommendation, which turns out to make the design more frustrating. When this happens, it hurts the reputation of the user research effort and puts into question other recommendations.

At the recent CHI conference, our good friend Meghan Ede, who runs the user research effort at Symantec, told us she’s instructed her team of researchers to ask the following of every recommendation they write: “Would you bet your life savings on this recommendation improving the design?” They remove any recommendation which doesn’t meet this criteria from the final presentation.

Meghan reports, since she’s instituted the policy of asking this question for every recommendation, the number of recommendations has dramatically decreased, but the quality of their results have substantially improved. The researchers are now more confident when they report their results and the teams are less argumentative.

What do you think of Meghan’s approach?

His initial solution was to hire a consultant to run some usability tests, gather the essential information, write a report, and present it back to the team.

I had a different idea: I suggested we train the development team to do their own testing. In my 28 years of experience of doing this work, I’ve found there is no single experience more educational than conducting usability tests.

Sitting next to a real user while they do real work is always an enlightening experience. I have yet to sit in on a test where I don’t learn something, even if what I learn is we’ve done a good job at nailing the design to meet the user’s needs. I learn the words the user’s like to use, the way they like to approach the problem, and where the design succeeds and fails at helping them.

Watching 10 real users is always an eye opener. Seeing patterns become enlightening. Seeing what doesn’t happen is just as useful. (“Look, none of the 10 users showed any interest in that fancy widget we spent so much time on!”)

Once you have a little training, conducting tests are fairly simple and straight forward. (As I say often, usability testing is not rocket science. We know this because NASA is one of our clients and they are very specific as to what they call rocket science. This is not it.)

Plus, once testing is embedded into the team’s regular process, it becomes a great way to try out new ideas and collect some actual data, instead of the usual opinion wars. There’s nothing like having a test scheduled and closing off an endless design debate with “Let’s see what the users say on Wednesday.”

I’ve seen a lot written about usability testing over the years, but I can’t recall seeing anyone talk specifically about it’s value as a training tool, to bring the entire team on the same page about who the users are and what they are trying to accomplish. Stretch your thinking of usability testing as a design validation tool or an idea generator into a team education technique. You won’t regret it.

The folks over at Manager-tools.com have published an excellent podcast on “Jump Starting Internal Customer Relationships.”

Part one of the Podcast
Part two of the Podcast

Joel doesn’t think too highly of the process, saying

Software organizations tend to reward programmers who (a) write lots of code and (b) fix lots of bugs. The best way to get ahead in an organization like this is to check in lots of buggy code and fix it all, rather than taking the extra time to get it right in the first place. When you try to fix this problem by penalizing programmers for creating bugs, you create a perverse incentive for them to hide their bugs or not tell the testers about new code they wrote in hopes that fewer bugs will be found. You can’t win.

Joel’s point, a good one, is when you measure the productivity of individuals, you have to be careful of gaming. He implies that you can’t build a measurement system for programmers that can’t be gamed.

That may be true, however, I’m not sure gaming is always a bad thing.

Part of the problem with the measures Joel spoke of was they ignored any valuation on quality. They focused on function points and lines of code, two easy-to-measure quantities. Code quality is not so easy to quantify, so we tend to not try to measure them. (After all, who wants to get into arguments on whether something is quality or not.)

Someone really smart (not me and I don’t remember who) once said, “Once you remove ‘quality’ as a requirement, everything gets a lot easier to build.” Well, once you remove ‘quality’ as a measure of success, then the measures become a lot easier, but they don’t necessarily measure what you’re looking for.

In Ziya’s post, he posited the same problem would occur when designers try to measure their own productivity. After all, what do we measure our design team on?

Maybe I’m an optimist, but I believe it’s possible we can arrive at productivity measures that work (meaning, when gamed, they produce the results we were hoping for) for design teams. These measures would quantify the results the team produced and compare them to the effort it took to produce it.

From there, we could determine what practices and skills are most efficient at gaining the best results. We can also use these measures to help us make budgets and predict timelines.

Right now, we probably don’t know enough to put these measures together. But, just because we can’t effectively measure it right now doesn’t mean it’s impossible. History has shown many examples of things which took a long time to learn how to measure, but someone eventually does.

How would you measure the productivity of your designers?

The legend of how eBay got started is a quaint one: Pierre Omidyar created eBay so that his wife could buy and sell her favorite collectibles: Pez Dispensers. The story has been told thousands of times, and most people like to think that the site is a labor of love. Unfortunately, the story turns out to be a little bending of the truth: apparently Omidyar realized the site’s potential before pursuing it.

It is true, however, that Omidyar used the site to help sell his wife’s collectibles. He was one of the first users, as well as the first developer, of eBay. That may sound like an unusual combination: to be both the user and the developer. Our conceptions of both tend to be very different. Users are those people who use stuff. Developers are those who build it.

But what happens when they’re one in the same? What happens when the user is the developer, and vice versa? It turns out to be a powerful combination that leads to unseen advantages that those building for others don’t have (and might not be able to duplicate).

Scratching Your Own Itch

The web application Basecamp was created by a team of web developers at 37signals who had a project management problem.

“Basecamp originated in a problem: As a design firm we needed a simple way to communicate with our clients about projects. We started out doing this via client extranets which we would update manually. But changing the html by hand every time a project needed to be updated just wasn’t working. These project sites always seemed to go stale and eventually were abandoned. It was frustrating because it left us disorganized and left clients in the dark.”

“So we started looking at other options. Yet every tool we found either 1) didn’t do what we needed or 2) was bloated with features we didn’t need — like billing, strict access controls, charts, graphs, etc. We knew there had to be a better way so we decided to build our own.”

Other People Have the Itch, Too

What happens next is the same: after you scratch your own itch someone realizes that others have the itch, too. It might be the developer who notices, or another user. Mike McDerment, who co-founded Freshbooks, a web-based accounting application, describes this:

“(We) founded the company in January 2003. We were doing web design and development projects for various clients. We built FreshBooks for ourselves and very quickly realized that other businesses needed a painless billing solution. We put our heads down and got to work.”

Eating Your Own Dogfood

After you realize that others have the same problem, the next step isn’t to start building for all of those other people and assume you know everything. No, it’s to continue to design for yourself, and then use the product for an extended period of time. Play with it, push it, pull it, make sure that the features there are the right ones, not the nice-to-haves.

Christina Wodtke (who spoke at our User Interface 9 Conference), is working on a new web app: Public Square. She’s testing it out in a small way before releasing it as a service, using it to run one of our favorite sites, the online magazine Boxes and Arrows. She’s effectively killing two birds with one stone…using it herself as well as testing it with others to get real feedback.

Increased Passion for the Work

This users-as-developers cycle may be more virtuous than others. Dan Cederholm, who co-built a wine-sharing site called Corkd, describes how much more passionate he is when working on his own project.

“There’s a real difference between being a hired hand on a project for a specific amount of time and someone who has ownership as well as passion for what they’re working on (ownership and passion can be exclusive as well, but combined, they pack quite a punch). The short-term, part-time attention of a freelance designer or developer can often lead to clunky, duct-taped solutions after the contract is over and the site is actually being used by real people. Cork’d has been the complete opposite situation, where we’ve been able to launch a product that would be considered “done” under most circumstances and then react to member feedback using the same attention to detail that went into the initial construction.”

A New Model

At first, it can be quaint to say that building for yourself is a nice perk of your situation. Increasingly, however, starting with eBay and now with firms like these four (and countless others as well), this new model is becoming the de facto way to develop, a critical part of success. If you compare a piece of software created by its users vs. one that’s not, it’s pretty easy to tell the difference. The designers understand the problem better, they’ve worked through most of the issues, and they’re more passionate about it after all is said and done.

However, I think that would be a narrow interpretation of how specialties work. To explain, let me turn again to a much more mature practice area, medicine.

Specialties in medicine can be singular, such as orthopedic surgery or podiatry. However, the practice of medicine is now seeing new specialties pop up which are combinations of these singularities.

One such new one is the new discipline of Physiatry. Physiatry deals with restoring function for a person who has been disabled as a result of disease, disorder, or injury. It combines the disciplines of neurology, physical medicine, rehabilitation science, and electromyography.

Physiatry started in the 1920′s, but only came into serious play after WWII when people became concerned with the growing number of war injuries and disabilities. Even then, it’s only really started blossoming as a profession in the last 20 or so years. So, in the entire history of western medicine (going back to the Greeks), it’s a very young branch.

Physiatry is interesting to me because it takes four previously-unrelated disciplines and combines them in a holistic way. This combination allows the physiatrist to diagnose and treat issues that no one branch of medicine could work with.

A physiatrist is not a generalist. They aren’t delivering babies and dealing with rashes, per se. Like other specialties, physiatry is very specific about what it talks about. It just happens to be the intersection of other specialties.

Comparing this to the practice of user experience, I think we already see physiatry-like combos happening. As I mentioned earlier this summer, the artwork from the Mayo Clinic site demonstrates they have people who straddle multiple disciplines: illustration, anatomy, and medical science. I’ve met usability specialists who focus on telephone/interactive voice systems (which have different approaches and problems, due to the non-visual components). I’ve met information architects who specialize in news topics and others who specialize in legal topics. I’ve met visual designers experienced in designing for Eclipse environments.

I expect we’ll more of this as we integrate ourselves into teams. A team will find someone who has skills and experience related to their products domain and to their tools and environments to be very valuable.

I think it’s going to be fascinating to see how people specialize and where that will take us going forward.

Specialists are professionals who have the time, experience, and projects to allow them to go deep into a discipline, such as information architecture. Because they can concentrate on the one discipline, they become very knowledgeable and experienced at solving the problems that crop up. Having a specialist on board is often very valuable, since they’ll know how to tackle the many subtleties that can make or break a project.

Generalists are professionals whose time and projects demand they learn a broad variety of disciplines. It’s not unusual to find a generalist who daily switches between information architecture, usability research, interaction design, visual design, and even coding. Because they are constantly switching, they don’t have the advantage specialists have at gaining knowledge in a specific discipline. However, they do have the advantage that they often better understand the intersection between these disciplines. They are extremely valuable because they can see issues and details from multiple perspectives, bringing a broad view to the project.

Specialists and generalists are not new. They’ve been in other fields for years, such as medicine. For example, at the Lahey Clinic, here in Burlington, MA, there is a Dr. Margles who is an orthopedic surgeon specializing in hands and wrists. People come from all over the world to see him. Manufacturers of surgical products seek out his advice. He’s one of the best hands and wrists guys in the world. He’s definitely a specialist.

11 miles to the west is Emerson Hospital, in Concord, MA. There we find an orthopedic staff of 6 doctors, all of whom are very capable. But none of them specialize in hands or wrists. They work on whatever body parts you bring to them. They are just as good as Dr. Margles and the other specialists at the Lahey Clinic, they just have different experience.

Now, don’t make the mistake a lot of folks make and confuse specialization with compartmentalization. While the former is about having the majority of your experience in a single discipline, the latter is about only having experience in that discipline. While Dr. Margles prefers to work on hands and wrists, he could, if the need arose work on other areas. In fact, if he was the only doctor on the island, you’d want him to be the one to deliver the baby. And his medical training and experience would ensure he does it successfully.

A compartmentalist isolates themselves from the other discipline around them, not really learning what they do or how they do it. Compartmentalism is bad for teams, because it means you have to have enough work to keep that individual busy within that discipline, and if needs shift or emergencies crop up, their value is dramatically diminished.

So, that leaves generalists and specialists to staff the team. Which should you hire?

From our research into what makes successful teams, we’ve learned the answer will depend on the economics of your situation. Some organizations will have the demand necessary to support group of specialists.

That’s they way it is at the Lahey Clinic. They have enough traffic and work to support multiple surgeons who specialize in only certain parts. Dr. Margles usually has a six-week waiting list to see him. He has no trouble staying busy. And, because there are more than 20 doctors in their orthopedic department, patients with problems with shoulders or ankles can find either another specialist or a generalist to help them.

However, Emerson is more of a regional hospital, servicing the area commonly known as Boston West. The hospital isn’t busy enough to have specialists, so all of the surgeons there have to be generalists. There just aren’t enough wrist or hand cases to support a specialist in that area.

While we don’t have exact numbers yet, our early findings suggest that fewer than 15% of the organizations we’ve studied have the economic conditions that could support user experience specialists. These organizations have enough workload to keep a usability professional just doing research, day in and day out, or an information architect just working on IA issues, etc.

This means the other 85% of the organizations should be looking for people with a broader set of skills. They should look for people who understand the different disciplines and can move between them quickly.

Again, the implications of all this are interesting:

• Do we know how to modify our tools, techniques, and practices, based on whether we’re in a specialist environment or a generalist environment?
• Do we know how to guide potential employees into one area or the other? If someone is expecting to be a specialist, will they be happy in an generalist position, or vice versa?
• Do organizations have the tools to assess their own economic conditions? What happens if they hire a specialist when a generalist was really what they required? How do they know when they are ripe for a specialist? What do they have to work towards to get the demand necessary?

Like yesterday, I think the professional organizations need to play a big role in this. To date, they seem to be content only acknowledging specialization (and in many cases, encouraging compartmentalization). However, I believe they need to realize generalists are an important part of our community. (UXnet could be in a position to make this happen, but, to date, they haven’t seemed to contribute much to the conversation, as far as I can tell.)

Our research will continue to delve into these areas. And, of course, we’ll share what we learn.

Last week, we sent out the first part of our interview with Luke Wroblewski, author of Site-Seeing: A Visual Approach to Web Usability and UI11 speaker, on the topic of where usability meets visual design. (You can read the first part of the interview here. ) This week, we continued the conversation with Luke.

Are you seeing benefits when you combine visual design with usability in your designs? What challenges are you facing trying to make that happen? Join the discussion below.

Luke Wroblewski will be presenting his full-day seminar, Site Seeing: Communicating Successfully with Visual Design, at the upcoming User Interface 11 Conference in Cambridge, MA on October 11. You can read about Luke’s session, along with the other great full-day seminars, here.

Read the article here.

Enjoy your holiday weekend!

Last night, in a phone conversation between David Malouf (the interaction designer formerly known as Heller), Bill Scott and myself, David shared he took a page out of Yahoo’s book and has been using something similar to Yahoo’s new home page tour.

Yahoo! just launched their new home page and with it created a tour.

Click to see the Yahoo! Home Page Tour.

The tour shows the new home page with various new elements annotated with callout bubbles. Mousing over one of the bubbles provides a larger callout with more information.

The Page Options callout from the Yahoo! Home Page Tour

David’s idea was to use a similar mechanism to annotate new designs his team was conceiving. Creating a static page, with mouse-over callouts gives a quick and easy way for people to understand the new design.

That David guy is pretty smart, I thought.

Somewhere along the line, usability professionals became branded as people who don’t “get” visual design. Their reputation has become one of only thinking about the functional, usage-oriented aspects of design, without considering how something looks.

Maybe it’s because many usability people don’t have training in visual arts and design. Heck, the only thing I can draw is blood. A quick survey of usability web sites shows many of them are not at the high-end of the artistic scale. (Of course, too many of them aren’t very usable, either.)

Similarly, within the usability community there’s a similar perception that many visual designers don’t understand how things are used. There are those who believe the visual designers know how to make things pretty, but at the expense of usability.

From these perceptions comes the belief that the two communities are in contention with each other. That you have to “find a balance” between usability and visual design to produce a great design.

But is this belief correct? Is it about finding a balance between two opposites? Or is it about finding the synergies between two disparate skillsets? Could it be a combination of usability and visual design would produce an effect better than either can do on their own?

UIE’s Josh Porter interviewed Luke Wroblewski, author of Site-Seeing: A Visual Approach to Web Usability and UI11 speaker, on the topic of where usability meets visual design. Luke’s answers were so thorough, we had to break the interview into two sections. In this issue of UIEtips, we present Part I of the interview.

Are you seeing benefits when you combine visual design with usability in your designs? What challenges are you facing trying to make that happen? Join the discussion below.

Luke Wroblewski will be presenting his full-day seminar, Site Seeing: Communicating Successfully with Visual Design, at the upcoming User Interface 11 Conference in Cambridge, MA on October 11. You can read about Luke’s session, along with the other great full-day seminars, here.

Read the article here.

It’s impressive to me on two levels:

First, it does an excellent job of communicating something that would be very difficult to communicate with words. This is what we call a content graphic. Content graphics communicate useful information to the user.

Informing a friend, family member, or someone with a potential brain aneurysm what is happening and the potential outcome is something that would be hard to do verbally. This image does it cleanly and with style. The artist needs to be commended. If only we could all have content graphics this well done on our sites.

On the second level, it shows the skills necessary to pull something like this off. The artist creating this image wasn’t only skilled in Illustrator or Corel. They also had skills in anatomy and medical science.

The layers of images — the outside of the woman’s head; the features of the jaw bones, cranial cavity, and spinal cord; and the image of the arteries with the budding aneurysm (plus the inset of it bursting) — show this artist knew their stuff and how to effectively communicate it.

Creating excellent content graphics, whether showing important medical information, demonstrating financial transactions, or representing how information flows through complex networks, requires more than good artistic skills. It also requires extensive domain knowledge and the skills to clearly communicate it.

As we continue our research into what makes excellent design teams, we’re seeing the best teams are more likely comprised of people with many different areas of expertise, not just a single, refined skills set. On your team, is each team member growing their areas of expertise? Are they becoming knowledgeable in various domains? If so, you’re marching in the right direction, or so our current research is suggesting.

That’s why I perked up at the recent CHI Conference in Montreal when Yahoo!’s Aviva Rosenstein, Manager of Design Research for the Yahoo Media Group, shared her thoughts on getting development teams to adopt personas into their process.

Aviva talked about a recent project, where she had a laminated 3-fold card made up to describe the key attributes of the six personas the team was using.

Click here to see a larger rendition of the Yahoo 3-fold Persona card. (Details are obscured to protect proprietary info.)

Aviva described a “party” she threw, where she invited all of the team members to introduce them to the personas. Instead of a regular presentation, she gave each team member the 3-fold card and placed a sticker on their back containing the name of one of the persona identities. The team then played a game of having to guess their new identity by asking yes-or-no questions to other team members. The idea was to find someone else in the room with the same identity as they had.

Aviva said it was a real treat to watch all the team members as they studied their laminated cheat-sheets and asked each other pertinent questions.

The result? Aviva said she was pleased to find the team continuing to use the personas. It was not uncommon to see them bring their laminated cards to meetings and refer to them throughout the process.

A scene from a Yahoo! team meeting. Note the persona on the whiteboard and the 3-fold cards on the table.

What have you done to keep personas alive with your development teams?

So, you want to reward bad behavior in such a way that it further promotes it? Taken to a slight extreme, I can envision a handful of developers all trying to earn the greatest number of “Monkeys” by helping the company “learn” more.

Positive reward of a negative behavior just seems really wrong.

Since I believe that developers really want to produce great designs, I don’t think this is the scenario that would play out in most organizations.

Someone once said “Good judgement comes from experience. And experience comes from bad judgements.”

If you don’t create a safe environment for people to “fail” and, subsequently, learn from those failures, then people are going to be risk adverse. However, if you give team members a chance to learn in a positive and creative way, I believe they’ll quickly rise to the challenge and exceed your wildest expectations. Every environment where I’ve managed to swing things in that direction has proven this to be true.

Teams often are rewarded for things that work against building great user experiences: being on budget or shipping on time. Designing for great experiences takes time and resources. Coming up with ways to reward developers for exploring what it takes to make great experiences work sounds like a winning idea to me.