an unfair characterization of user experience professionals

1/3/2007

Three personalities in the user experience community

three_personalitiesThis article is about how I stereotype people in the user experience community. It’s not very nice to stereotype or categorize people. But, Ux people are in the business of it. Most of our user models like personas, roles, and profiles help to generalize our understanding of our users. It’s only fair to turn that back in on ourselves.

I generally use three categorizations – before-people, during-people, and after-people.

Before-people worry about problem understanding and the response to that understanding

Within the Ux community you’ll find people who spend lots of time thinking about the users, the way they think, work, and what their problems are. The before-people will spend time talking with them, observing them, and studying the users. They’ll use nifty models like personas or affinity diagrams to capture and communicate the results of their research.

Given that researched understanding of users, their problems and goals, before-people will then seek to describe the type of software or other tool that might be valuable to those users. They might describe that solution with scenarios, storyboards, UI wireframes – usually low fidelity visualizations of the software or tool.

These folks have sort of a scientist’s and inventor’s personality combined. But not in a bad way. They’re often outgoing and energetic. They’re very observant about what’s going on around them. They’ll notice all the scraps of paper on your desk and ask you what you use them for.

Interaction designers often fit into this space. Sometimes information architects will as well. Sometimes we might call them general user-centered designers.

You’ll want these sorts of people involved long before you decide what software to build. They’ll help you understand what that software should be – assuming you should be building software at all. You want them involved before.

There’s an assertion hidden in here that the software requirements are a product of this research and design. But, I’ll confuse you with that discussion at another time.

During-people worry about the usability and aesthetic aspects of the solution

Given that we’ve agreed to build a piece of software or some other tool, how does that tool look and work specifically? What colors will we use? What shape will we use on buttons or controls? What aesthetics contribute to both the usability and experience of the user as they use the product to meet their goals? These are the concerns of a during-person.

You’ll find people within the Ux community that focus on specific aspects of user interface design such as visual design, detailed user interactions – that stuff that makes the software really sexy. And ultimately the stuff we really see and touch. Since this part of the design is the stuff we see and touch, this is the type of “UI person” a Ux professional is most likely to be mistaken for.

The Ux practitioners with their head in this place are often visual designers. They may also be hardcore software developers who focus on the design of specific UI widgets or user interactions – possibly things like cool scriptaculous effects.

They may not have to know much about the brand of breakfast cereal their users eat – they may not be that interested in all the user research a before-dude did to identify the software being designed. Consequently, when asked to suggest a software solution to a user’s problem, they might not be up to that task.

These are the creative types. The group referred to as the “ponytails” by some, but not in a bad way. They’re the ones peering at you over the lid of their MacBook while sipping a double espresso.

You want one of these types involved during the detailed design and development of your software. They’re tactical. They’ll make a big difference in the perceived quality of the software.

After-people worry about validating and improving the quality of a solution

Given some software solution, we need to understand if users really can use it to meet their goals. We’d figure this out by, you guessed it, watching users try to use it to reach their goals. This is usability testing.

You’ll find people in the Ux community who are excellent at observing people using a tool and identifying where their problems are and how the software or tool might be altered to better meet the users’ needs. Those who have observed many users using software have come up with ways to assess the usability of software without actually observing its use based on the most common usability problems encountered in the past.

These folks are critical and calculating, but not in a bad way. You’ll find them aware of and sensitive to the slightest details in a piece of software or some other tool. They’ll identify design issues in your car, calendar, or coffee mug. They may not be best at figuring out what the solution should be, or making it look sexy, but they can tell you if the solution is effective or not – and how to make it more effective.

Usability engineers fit the description of the after-person. You’ll want them involved after you’ve produced some sort of solution – either finished software or more preferably a prototype of what you intend to build. They’ll tell you if the software is really living up to its intentions.

bda_model

 

The personality pie chart

my_bda_compositionNo one fits squarely into just one of these categories. In fact, everyone has a bit of all these personalities, concerns, and skills. But I do find that different Ux people have a magnetic pull toward one of these three personalities.

Me, I’m about 55% before, 30% during and 15% after – so I’m mostly a before-dude. It’s just where my interest and concern is. I have a so-so attention to detail. My visual design skills are adequate. But, I feel very strong at identifying problems, goals, and potential solutions.

The right personality for the right time

When you’re in the throes of solving a design problem, you need to put the right personality to task. If you’re just one person tasked with assessing the usability of a piece of software, you’ll need to tap into your inner-after-person. If you’re a large organization with different people in different roles, make sure the personality types in your usability lab are best suited to the task at hand.

If all this stuff is new to you, and the idea of a UI person who doesn’t actually design UI seems crazy, knowing about these personalities should help. You may know a before- or after-person and have been puzzled in the past about how they do their job while completely lacking the ability to make cool buttons on PhotoShop.

Terminology pollution leads to responsibility confusion

There’s lots of language to describe what people do in the user experience space. I’ve been confused by it for years. Here’s a list of common Ux job titles – and not necessarily a comprehensive one.

  • User Experience Professional
  • User Centered Designer (UCD)
  • Human Computer Interaction Designer (HCI)
  • Computer Human Interaction Designer (CHI) – what’s with the HCI/CHI thing anyway?
  • Interaction Designer
  • Information Architect
  • Visual Designer
  • Usability Engineer
  • Human Factors Professional
  • UI people

You’ll find that often these people do different things, work differently, and think differently. I find that those who aren’t familiar with the definitions of all these roles and terms tend to roll all of them together into “UI people” and expect these sorts of folks to make bad software user interface look better.

I find that people within the user experience community are often inconsistent about what these terms refer to. It’s been over the past year that I’ve finally developed some working definitions for myself. (You can find them in the slides of this talk – starting on slide 19.) I’m sure these definitions aren’t accurate for everyone, but they help me keep my world straight.

When a term or job title fails me, I can usually classify a person as a before, during, or after. That helps me quickly guess at their skills and sensitivity – and quickly guess at where and when they’d be most interested in participating in our project.