Fitzgerald Steele

I’ve struggled to communicate exactly what a User Experience Designer does.  User Experience is a relatively new field.  It borrows a lot of techniques from various long-established disciplines, but I don’t think there is any strong consensus on what a User Experience professional does, how they interact with other established parts of an organization and how to know if you’re a good one.  In this post, I synthesize some of the current thinking on what UX Designers are supposed to do (UXMatters.com), how they go about doing it (userfocus.co.uk), how they might be evaluated (Jared Spool, uie.com) , and present a framework for thinking about your User Experience practice.

The Bottom Line:  UX Designers/Developers need skills in 3 areas: Core UX Skills (User Research, Visual Design, Interaction Design, Implementation, Evaluation), Enterprise/Business Skills, and Foundational Skills.

UX Designer/Developer Core Competencies

User Experience Definition

Search for ‘user experience definition’ and you’ll get a lot of different answers.  You could do worse than the ISO 9241-11 definition:

‘…we define [user experience] as all aspects of the user’s experience when interacting with the product, service, environment or facility’ and we point out that ‘it is a consequence of the presentation, functionality, system performance, interactive behaviour, and assistive capabilities of the interactive system.

It includes all aspects of usability and desirability of a product, system or service from the user’s perspective’.

That’s a tall order for one person to fill.  In a company of any size, it is unlikely that one UX Designer will have complete influence over all aspects of the user experience.

UX Honeycomb. Peter Morville

So while I hold this definition as an ideal, and try to communicate it to others in my organization, I tend to focus my view and efforts to the electronic, web systems that I design and have direct influence over.

There are a couple pictures that I think sum up this view rather well.  The UX Honeycomb describes 7 facets of a good web user experience.

Dan’s visualization of UX at KickerStudio encapsulates the notion that UX is the space/cytoplasm that connects the various disciplines into a single organism.

User Experience Artifacts/Deliverables

What are user experience designers supposed to do?  I like the idea that UX designers bring compassion and empathy into product design.  They use structured methods to turn empathy into a design process that result in improved user experience.  David Travis breaks UX work into four categories: Analyze the Opportunity, Build the Context for Use, Create the User Experience, and Track Real-World Usage and Continuously Improve the Product (graphic).

A Model for User Experience. David Travis

What deliverables they bring to the table?  We use tools like stories, wireframes, tasks analysis, and prototypes Peter Morville gives a nice overivew of the UX Deliverables (along with an excellent graphical UX Deliverables Treasure Map).

With Agile development methods leading to shorter and shorter developmet cycles, some have suggested that UX Designers also need some development skills.  Being able to express designs with the same language and tools as used by the ‘backend’ development team certainly makes easier for the UX designer to integrate their work with the development team.  I agree with this view, to a certain extent.  I started my career as a developer, and I still do some coding.  I think this helps me communicate with my full-time developer colleagues.  But I also think that focusing on development can taint your design thinking.  When you’re in the weeds of writing code, and under a delivery deadline, it’s easy to cut corners on the design and say “this works…this is good enough.”

User Experience Core Competencies

In his Agile2009 Keynote, Jared Spool had a nice graphic of all the different disciplines the UX Designer/Developer dabbles in (I’m surprised the slides from this aren’t available anywhere).  I combined some of these ideas, some from Steve Psomas in UX Matters (linked above), and my own thoughts/experiences.

I would tend to group UX Competencies into three categories.  Let’s look at the picture again:

UX Designer/Developer Core Competencies

CORE UX SKILLS

This is your ability to turn your compassion and empathy into design artifacts and deliverables.  This is what people hire you to do.  I think this breaks down into 5 areas:

• User Research
• Visual Design
• Interaction Design
• Implementation
• Evaluation and Testing

The graphic gives some examples of the types of artifacts deliver and skills required in each of these areas.  These are obviously not complete lists.  In particular, take a look at the Implementation box.  To be a UX developer these days, you need to know something about the front end presentation (HTML, CSS), the ability to make the screens sing and dance (javascript, AJAX, or maybe Flash, Flex, or Silverlight).  You need to be able to persist the data, whether in a local database, key-value store or remote system.  You need to be able to glue those two together, either through some lower level server side programming with straight PHP, or some framework like Ruby on Rails, Django, or CodeIgniter.

ENTERPRISE/BUSINESS SKILLS

Enterprise and Business skills enable you to map your Core UX Skills onto the needs of your organization in order to deliver business value.  As Jared Spool explains:

User experience extends beyond the on-screen interactions to all touch points with the user. Special skills are needed to ensure the team interacts with the rest of the organization in a productive manner. While the teams don’t need to know how to do the jobs of others in the organizations, they need to know how those other roles will influence the design.

I organized some of these Enterprise/Business skills differently than Jared…more in a way that fits my experience I guess.  Where the Core UX Skills live almost exclusively in the UX World, the Enterprise/Business skills are about the connections, interfaces, and links between the UX practitioner and the organization.

FOUNDATIONAL SKILLS

The Foundational Skills are the theory, tools, and practices that help you critically evaluate new technologies, tools, or methodologies.  Design and Development practices seem to come and go almost daily.  Today we’re all talking about guerilla usability testing, paper prototyping, user stories.  A few years ago talking about Usability Engineering, Outside In Design and looking at UI UML modeling.  Before that, we were talking about User Centered Design and the need for full blown usability labs.  Tomorrow, we’ll be talking about something else.  It’s your Foundational Skills that help you step back and see the relationships between all these things.  Foundational Skills enhance your ability to ‘pick up’ the latest thing because you can relate it to something you already know.

Foundational Skills would grow both through formal academic training in fields like Ethnography, Psychology, Human Factors, Computer Science, Engineering.  Foundational Skills would also grow through real-world experience with people, organizations, technology, and systems.

User Experience Core Competencies Use Cases

Assessing Your Own Strengths/Weaknesses

A designer/developer might rate themselves on some scale, say 1-5, in each of the 7 areas, to clearly communicate the skills they bring to the team.  I could imagine some color coded version of this graphic, or even a treemap that emphasizes where one’s skillset lies.

Assessing Your Teams Strengths/Weaknesses

A UX team manager might assess their teams strengths along these dimensions, in order to identify team strengths, weaknesses, opportunities to pair people and do cross-traning, and guide hiring decisions.  This leads to…

Evaluating Job Candidates

Given that you’ve identified areas where you need additional skills, you can rate prospective hires in the 7 areas (or ask them to rate themselves).  You can give each area a weight in order to emphasize the balance of skills you’re looking for, and build a table that calculates a weighted score for each of the candidates.

Conclusion

There are many misconceptions about UX.  In many organizations I’ve worked or consulted for, UX design is treated like some magical black box — sprinkle some pixie dust on our servers and *poof* out comes a great UX.  Maybe this type of framework can help remove some of the mystery, and help us communicate generally what we do and how we do it.  It may also help you communicate your own strengths, skills, and contributions to the product team.

I showed this visualization to my boss at my performance evaluation this year, and said, “this is how I think about UX and the types of things I should be doing…here are the areas where I’m strong, and here are the areas where I’m looking to grow.”  I noticed he only marked up the areas where I’m weak.  =)  That’s ok, because 1) we have others on our team that are really good in areas that I’m weak, 2) we agreed on where I need to get more practice, and 3) it lets me be proactive in defining the UX world, and the value a UX Designer/Developer in general (and me specifically) brings to the team, and what things I should be doing.

I certainly welcome thoughts from the community.  Is this helpful?

I enjoyed reading  Sway: The Irresitable Pull of Irrational Behavior (Amazon , nice review).  There are many cognitive biases that affect how we think.  The authors did a nice job of distilling the research on cognitive bias into an accessible popular science book.  The book made me think about how I approach web design and evaluation.

Traditional usability testing has its roots in psychology research methods.  You spend lots of time designing the study — randomizing participants into experimental groups, ensuring you don’t ask leading or prompting questions, calculating statistical significance or confidence intervals of findings, etc — so that these cognitive biases are minimized or factored out.

Agile development typically feature 1-3 week sprints, forcing UX designers to shorten traditional evaluation methods, use guerrilla usability testing, or do whatever they can to get SOME user feedback in the time allotted.  UX designers have been actively discussing how to integrate UX design into agile development teams (or search for “agile ux“). But in speeding up design testing/evaluation, we may become more susceptible to allowing cognitive biases to creep into and taint our study results.

There are two biases in particular I think we need to watch out for.

Confirmation Bias

Confirmation bias is the tendency is a tendency to search for or interpret information in a way that confirms one’s preconceptions (Sciencedaily, or Nickerson 1998 if you’re more psychology-paper inclined).

Give me an example!

You’ve spent the last couple days iterating on an information architecture for a new site.  You’re doing a quick evaluation of a paper prototype with three users in three separate sessions, to determine if the latest iteration is the best.  You’re watching the users interact with the prototype, asking them to think out loud and asking open-ended questions to encourage them to talk.  However, you’ve invested time and effort in this latest prototype: the stakeholders have approved it, and you either really like it or are sick of it and want to move on to the next thing.  Confirmation bias might lead you to focus your questioning on behaviors that you expected to see, that confirm or validate your design, or discount some of the negative comments you hear.

Diagnosis Bias

Diagnosis bias is the tendency to label things based on our initial impressions, and our difficulty or inability to change our minds after that initial impression is made.

Give me an example!

You’re got some ideas for the next web2.0/cloud/service/mashup/[buzzword]*, and you’re doing user research to prioritize new feature development.  A study participant comes in and says, “I don’t know what browser I use…I just fire up AOL to get on the internet.”  Ouch, you think to yourself, how am I going to get any useful info from this yokel?  This diagnosis bias might make you miss that while they don’t do much at home, their online activity at work makes them a perfect candidate.

How do we avoid biases in Agile UX?

The Sway authors take a small stab at answering this question in the Epilogue of their book, but their answers are a bit simplistic.  I guess this is understandable.  Humans developed these biases because they help us solve problems related to surviving in an unstable outdoor environment, and to do so in nearly constant motion (Brain Rules).  Sometimes you need to make quick, simplifying judgments in order to survive or gain an advantage.  So clearly there is no turnkey, 3-step process for overcoming them.

Obviously there is a need to find an appropriate balance between experimental design rigor and doing the least amount of work to get the most value.

1. Be Aware of Cognitive Biases.
   You can’t do anything about it if you don’t know about them.  And you just read this post, so check this one off your list.
2. Make a List of Your Assumptions; Reevaluate Assumptions Across Sprints
   This is basically just trying to externalize your assumptions and biases.  If you can put them out there, and make plans to revisit them over time, it might be easier to catch when they have clouded your judgment.  Also, if you publicize your working assumptions it gives others a chance to critique them, or see if many people would draw the same conclusions.
3. Think About How to Disprove Your Assumptions, Rather Than How to Prove Them
   This goes back to your Research Methods class…it is difficult to objectively critique something if it is not falsifiable.  I’m not saying you have to set up your null hypothesis tests.  But you can change you design evaluation thinking from “how would I know this is good” to “how would I know if this is bad.”  Try to identify 3-4 ways that would indicate something is wrong.  If none of those things are evident, you’re more confident that you’re on the right track.