The User Experience of Building a Bear

I can’t remember a more jarring lapse in a customer experience than that which my family experienced this morning.  It all started with a fuzzy blue bear.

The Setup

My wife and I took my daughter to a build-your-own-teddy-bear establishment.  To a father resigned to spending coin on a toy that will be loved intensely and then put in a toybox, the teddy-bear building process is amusing:

1. select a skinned bear, rabbit or other animal carcass
2. stick a blower into it’s rear orifice and fill with cotton,
3. complain about all the ridiculous clothes, furniture, and other accessories your child will want to buy,
4. suck it up and pay,
5. receive hugs and kisses from daughter.

The company, of course, has a much friendlier description of the process.

From buildabear.com: The process for building your own bear.

While the bear was being stuffed in a very uncomfortable place, I thought to myself what a great job the company had done making customer experience into a profitable business.  They’re giving my daughter more than a bear; they create an engaging process to build a bear, but also to have the child establish a relationship with the bear before they even leave the store!  The employees are critical to this.  At every step they help the child personalize the bear, bring it to life in their eyes, and make the bear-building experience unique and memorable.  It works.  My daughter has dozens of stuffed animals, but she knows which ones are Build-A-Bears, and she remembers where, when, and with whom she got each of them.  Because they had put together a fun, well designed experience, I kept my fatherly grumbling and immature comments on bear stuffing to a minimum.

The UX Fail

The experience started to break down when we got to the ‘Name Me’ step, where you create a personalized Birth Certificate.  You’re supposed to scan the bear’s bar code, but of course the scanner didn’t work so we had to type in the numbers.  I quietly laughed at the obviously 20-30 year old PC they had hidden inside a decorative wooden box, and sighed when my daughter tried to touch the icons on the screen, or reach for a nonexistent mouse.

I really started to get upset when I realized that this step was designed to get marketing information…name, dob, sign up for a newsletter including email address!  We’re trying to have fun family activity, and here comes the marketers in the middle of our family fun!  My four year old is sitting at the keyboard, painstakingly trying to enter all the information, trying to get her bear’s Birth Certificate.  Everything up to this point she’s been able to do completely on her own…and the build-a-bear board room broke the illusion right here.

To be fair, every business needs to have accurate, detailed information about their customers.  And as a user experience designer, I understand the need to balance customer-focused experiences with business needs.  I can almost hear the meeting in which someone presented the flowchart and said, “we’ll ask for marketing information HERE…”  They generally did a good job of  balancing the customer experience with opportunities to upgrade, upsell, buy add-ons.  But everything, except for the Name Me marketing survey, focused on the core activity; it centered on the experience of building and personalizing a stuffed animal.

Think Outside the Beige Box

As user experience designers, it is our job to help businesses think outside their own needs and goals.  It is not realistic to say, “get rid of the marketing survey.”  But the information could be captured without hijacking the core experience.  Here are a couple things they might think about doing to make the Name Me step more engaging:

Use a graphical, touchscreen interface.

This is a no brainer.  I know those beige boxes are super cheap, and you paid someone good money to write that Birth Certificate program for you 12 years ago.  But today’s kids don’t understand your huge computer and clicky-clackety keyboard.  They are daily iPhone or iPad users.  They are inundated with extremely responsive multi-touch interfaces, and high resolution graphics.  You can make this process easier and faster (or, increase customer satisfaction and loyalty, and increase customer throughput and sales rates) with a modern, touch user interface.  Do you really need the standard web month-date-year dropdowns?  Give her a bunch of big buttons with big numbers to press.

If that’s too expensive, just get a decent computer — remove the decorative box

The problem here is that you’ve now made the customer have to learn a completely new and foreign user-interface, which is much more restrictive that what they already use daily.  My daughter is 4.  She has a complete working knowledge of how to use the family laptop: she can log into her account, fire up a web browser, turn on Netflix to watch her favorite shows.  She knows she can type words into the ‘G’ and get the answers she wants.  She knows that if she can’t touch the screen, she can use the mouse to move the cursor, and click on things to make them do something.  All of this knowledge and accumulated experience was useless on your computers because you tried to create a ‘simpler’ interface.  If you can’t go touch, just give her a web browser and a mouse and be done with it.

Make the process conditional

I’m sort of ok with asking my daughter for her name — it is printed on the bear’s birth certificate (this bear belongs to…) so at least it’s part of the experience.  Do you really need my daughter’s exact birthdate?  Just ask her how old she is (she’ll tell you to 2 significant figures).  If the respondent says they’re under 13, don’t ask them for an email address, or to sign up for a newsletter.  Instead, ask me for my information when I get up to the checkout counter (after all, I have the checkbook).  Give me a reason to friend you on Facebook, where you can get all this information and more.

Make the process part of your mobile app

Nice to see you have a mobile app.  Why don’t you do some of this marketing stuff there.  Connect my account with all my bear purchases.  Give me Bear Bills for providing my real world identity information.

They have job openings for both an interactive user experience designer and a senior database marketer positions.  Clearly, they know they need to improve in these areas.  I wish you luck in filling these positions, and making things better!

Agile, Lean UX — What’s New is Old

I’ve been interested in recent twitters, posts, and presentations about the emerging and changing role of user experience.    Yet we’ve seen some resistance to the new terms or methodologies.  I’d like to suggest the current transition in the UX field is similar to revolutions in scientific fields.  Science historian Thomas Kuhn would say we’re in a period of crisis or revolution. (Don’t worry, it’s not as bad as it sounds).  It’s normal,  healthy.

Our field is going through change.  Change is normal.  I think this change is analagous to the changes and evolution of scientific fields described by Thomas Kuhn in 1962.  He showed that scientific fields go through cycles:

• Pre-paradigm—Sort of a bright, green, new field of inquiry.  There are no established rules, theories, practices, or  paradigms.  There might be a number of competing ideas.
• Normal —The field sort of settles on a general worldview (what problems are worth investigating, what tools are techniques are correct, etc).  An elite group of guardians usually emerges to lead the field, and determine what ideas are shared or published widely to the field.  If processes or findings occur that don’t agree with the established canon of the field, they’re regarded as anomalies.
• Revolutionary—As the anomalies pile up, it becomes harder and harder to reconcile them with the old ways.  For awhile, the field is in crisis you have competing theories and processes again.  Finally, there is a paradigm shift (the new ideas explain more things more elegantly, or are more useful than old ideas, the old elite guard retires or dies, etc) and the revolution becomes normal.  Think of the Copernicus declaring that the Earth revoles around the Sun, or the beginnings of the atomic model of chemistry.

This phased evolution model neatly describes what we’ve been seeing in the user experience field.

Evolution of the UX field

Pre-paradigm UX

Twenty years ago we were talking about interaction design, usability, and user centered design.  Computers were for work, graphics were bad, networks were bad, and building and deploying new systems was hard.  I remember hating Windows 3.1 because it made me use a mouse…I could do things so much faster in DOS!  As usability engineers, if we could improve task completion rates and reduce errors, we were pretty happy.

Normal UX

During the dot com boom and bust of the late 90′s and early 00′s, we talked about User Engineering, and Outside-In Design.  I know it was around this time that I stopped being lumped in with the technical, programming team, and started working more with business users and stakeholders.  We all agreed to stop using <blink> and <marquee>, and started to focus on not just building software that optimizes performance on a work task, but designing things that people will actually want to use.  As we approached the late 00′s, we started building design patterns, and interaction frameworks.  We more or less agreed on a set of UX deliverables.  In the last two years there has been an explosion of user experience tools, templates, companies, techniques, andservices available. (Those are just a few that I use, that I could think of at the moment…there are hundreds more).  In essence, we all now have a robust set of tools and techniques to address our client’s needs.

¡Viva La Revolución!

Today’s new challenges and assumptions that make us reconsider how we approach user experience.

• Networks are fast and ubiquitous (except when they’re not).
• Users are not only generally familiar with standard computing metaphors, but are innundated.
• Websites, webapps, mobiapps are all relatively quick and cheap to stand up and deploy to millions.
• Screen size is variable, and tasks may span screens.
• Apps are social — they know you and help you interact with your friends.  Storage is cheap, data is abundant, and is available from the cloud.
• Location and context are unknown, and may not take place behind a desk.

While we’re still responsible for creating usable experiences (time on task, error rates, mental models, Fitt’s law, etc) the bigger challenge today is figure out exactly what provides value and delight to users.  Developers need designs before the end of a 2 week sprint, it now may be as fast or faster to build experiences in an integrated team than to do visual comps.  So we’re talking about UX in new ways, using new terms: Agile UX, Lean UX.  We’re doing more more lo-fi prototyping.  We’re doing lots of design workshops, story mapping, ethnography.  We’re doing more of everything, however we can, so that our products and designs are things people will actually want to use.

At the end of the day,  practitioners are looking for ways to redefine the field, and exploring new ideas to address today’s realities and assumptions.  I don’t think we should disparage these efforts.  It’s a normal cycle that one sees in healthy, evolving fields.

I’m seeing people on the leading edge of the User Experience field are having some success truly integrating user experience methodology into corporate culture and product development cycles.  I don’t work for a startup.  I’m not a consultant (anymore).  But I’m excited because history tells me the current UX revolution will eventually become normal UX.  It will eventually get to my  UX team of one, nestled within an excellent team of web designers, in a conservative company, in the midwest.

In a follow up post, we’ll apply some systems thinking to find a way to bridge the old UX and the new.—

Is Mobile Design Really That Different?

I’ll be honest.  I’ve only dabbled in the mobile app design and development space: one app for fun, one app for work (hopefully to be released in the next couple months).  At today’s iPhone Design Conference, Brian Fling argued that mobile design is totally different that web.  But I still don’t see how mobile app design and development is that different from traditional software or web development.  Mobile devices offer new capabilities and require learning new tools, but the fundamental design and development tasks remain the same.

Mobile design reminds me of designing desktop apps in the late 90s.  Multiple platforms, small screen real estate, limited computing resources (although an iPhone would probably

Back in the day, VisualAge for Java provided a way for designers and developers to jointly build "cross-platform apps." It used a drag/drop GUI editor to generate java code. In other news, I'm old.

run circles around my 486).  Each application was an island, with little or no way to share information or task flows between them. Users probably didn’t have that much experience with computers.  Your job as a designer was to understand the users key tasks and success criteria, and  iteratively perform design and development to reduce time on task or errors.  You differentiated your product by closely aligning the user interface metaphor with the users’ mental model of the task or process.  Back in the day, we called this User Centered Design, and later Usability Engineering.  Over the next decade, hard drives got bigger, screens got bigger, processors got faster, and networks and application mashups were everywhere.  Users learned what to expect on websites.  We designers stopped talking about usability — how well do people get through the task flows we have created — and started talking more about a more holistic User Experience.

Mobile application design exploded with the iPhone.  Again, we find ourselves designing around constraints of small screens, multiple platforms, and limited computing resources.  This time around, however, we’ve got some additional capabilities.  Geolocation, gesture and multitouch interfaces, photo and video streams, anytime/anywhere network availability.  We have cloud processing and data storage that we can use to offset device limitations.  Even better, we have a generation of millions of users that are eager to embrace new technologies, pretty much willing to pay for and try out whatever we can think up.

But some things haven’t changed.

The basic cognitive and physiological capabilities of people haven’t changed.  We’re still resource constrained people, who can only focus on one thing at a time, have relatively shoddy memories.  We can only get our fingers to click on something so fast.

We all have the same basic needs.

Because of these basic human traits, designers still have to take care of the same basic interaction design requirements:

• Visibility (also called perceived affordances or signifiers)
• Feedback
• Consistency (also known as standards)
• Non-destructive operations (hence the importance of undo)
• Discoverability: All operations can be discovered by systematic exploration of menus.
• Scalability: The operation should work on all screen sizes, small and large.
• Reliability: Operations should work. Period. And events should not happen randomly.

As Don Norman recently pointed out, we’re not doing a great job with this on gesture interface devices

When we build these interactions, we’re still not doing it by ourselves.  We want to continually align our designs with users expectations and developer feedback.

We still need to understand users’ mental model of the task domain first and foremost.

Mobile gives us some new tools in our design toolbox, and we lose the assumption that the user is sitting at a desk, working on a single task by themselves.  New device capabilities…natural voice control, natural human gestures, thought controlled interfaces, semantic or linked data…are in active research and will make even more things possible.  But the basic job of the UX designer is still the same…to use the resources available to make our users more efficient, effective, safe, and if we’re lucky happier.  We still need to work iteratively with developers, business stakeholders to make that happen.

Am I missing something?  Am I thinking about it at the wrong level of abstraction?

On a side note, I’ve previously discussed that UX Designer/Developers should have a strong foundation in human factors, psychology, and computer science.  I think that (and experience) gives you the background to see beyond the new shiny toys and identify the real trends and innovations.  Jared Spool seems to agree.

UX, Psychology, Black Friday and You

One of the problems of working in the field of User Experience is that you start to see everything through that lens.   For example, Black Friday shopping. Black Friday is the biggest shopping day of the season, as retailers and Wikipedia tell us.  But that’s not accidental.  A lot of people, in a lot of companies, spend a lot of time and effort to get you to come out, and spend a lot of money.  As mentioned in a Live Science article today, retailers pull out all the psychology and human nature tricks to make that happen.

Retailers use psychology to convince people to wake up early and part with their hard earned cash.

Retailers use psychology to get you to spend money.  UX designers use psychology to design engaging experiences.  Whatever your motivation, it helps to know some psychology.  Stephen Anderson’s Mental Notes cards are like psychology flash-cards.  They beautifully present 50 psychology concepts that you can use to help engage your users in the experience you are designing. Here are some examples.

(Implied) Scarcity

People are attracted and energized to go after things they believe are limited.  The sense of scarcity instills a sense of urgency in the person.  The whole concept of ‘Doorbuster’ deals — extra deep discounts that expire by 10am — are an example of scarcity.  Scarcity is a very powerful.  The Dollar Stretcher Community noticed that retailers create a sense of scarcity using splashy displays of HUGE SAVINGS, even though they have actually increased the price.

Sensory Appeal

People are wired to pay more attention to things that stimulate multiple senses — sight and sound.  If you’ve been watching commercials for the last week, you’ve got a sense for that.  Once you’re in the stores, they play music, and have attractive displays to get you to pay attention.  If you’ve ever been inside a casino, you will have experiences the same thing.  This probably goes back to when humans first lived on the savannah…you had to pay attention to the moving, loud thing because it might be something you could eat, or something that could eat you.

Delighters

Delighters are unexpected surprises designed to give the person warm fuzzies about the experience.  One store we were at today advertised the end of the ‘Doorbuster’ specials at 1pm.  At 12:45, they came on the intercom and said, “Good news!  We’re extending our doorbuster sales for another hour!”  I’ve also heard of stores giving away special coupons or deals to people there before 5am.

On a side note, one might also argue that making the best deals very early in the morning encourages people to shop when they are tired, and probably hungry.  It is more difficult for people to think objectively and rationally when they are tired and hungry.

I’ve had the pleasure of listening to Stephen Anderson speak at this year’s Web App Masters tour.  His ideas for designing play into our experiences are really interesting.  If you can’t find him speaking at an event, I’d recommending you Get Mental Notes.

What can you do?

Make a List; Check it Twice

If you go into the store with a written shopping list…what you’re going to buy, who you’re going to by for…you’ve got a better chance of combating the impulse buys the retailers are counting on you for.  Remember, the good deals are really just a way to get you in the shop.  You’re tired, hungry, you’ve conquered and gotten the best deals, and the store has given you a couple Delighters to make you feel good — now you’re ripe to buy some of the full priced merchandise that you REALLY want.

Think about the 50,000 foot view

According to The Story of Stuff, most of the stuff we buy ends up in a landfill within 6 months of purchase.  Having stuff is fun, buying and giving gifts is nice, but rarely gives long term happiness or fullfillment.  Maybe we can do Christmas without tons of presents? Bill McKibbern wrote a book promoting The Hundred Dollar Holidays, deemphasizing presents and focusing on family, friends…slowing down.

Shop Locally

I don’t know that this really addresses the psychology of Black Friday; just my own personal opinion.  At the very least, small local merchants are less likely to be able to sell merchandise at very low margins to get you in the door, so they probably can’t play the same scarcity games as larger stores.  I know in my community, local banks are encouraging people to support local, homegrown businesses, touting local employment, quality products, and personal service.

 

jQuery Quickie: User Feedback with Fade Out/In

Here’s a little jQuery idiom I’ve come to use on a few web design projects that I thought might be nice to share.  Let’s say you want to update a region of the page or widget based on some user action.  For example, you might be building a screen with a list of orders on one side, and an details panel on another.  Clicking on one of the orders replaces the data that shows up in the details panel.

I use this snippet when I want to visually reinforce an on-screen change that happens when the user takes some action.

$('#link').click(function(
  $('#content_container').fadeOut("fast",function() {
     updateContainer();
     //other code here
   }).fadeIn();
);

(view as Gist)

Pretty simple jQuery, really.  When the user clicks on the link, we want to swap out the information in the content_container with the new data.  This simply chains together a nice set of animations to:

1. Quickly fade out the #content_container,
2. Do something to update the #content_container.  Or whatever you want really.
3. Fade in the #content_container after all the updates are complete

I personally like the fast fade out, normal speed fade in.  I feel like it gives the user a nice visual indication that something in this area changed, without drawing out the animation or drawing attention to the fading effect itself.

On a side note, this builds on some things I learned from Bill Scott at this year’s Web App Master’s Tour.  He presented a nice framework for thinking about all the small ways designers can provide useful user feedback without drawing attention to the animation or UI itself.

Online vs. Offline Social Networks

The Real Life Social Network is a great presentation by Paul Adams, UX Reseacher at Google, on the differences between online and offline social networks, and how those differences cause user confusion and even pain.  One of the main reasons for this disconnect, he claims, is that online social networking sites tend to put all your connections in one big bucket (Friends on Facebook, Connections on linkedIn, etc), where in real life, across cultures, people tend to have 4-6 relatively independent groups of connections, with 2-10 people in each group.

This sounds about right to me, but I wanted to see if I could see this in my own social network.  I used the excellent gephi network visualization and analysis tool, along with these instructions to generate a network graph of my facebook friends.

Graphed and clustered visualization of my Facebook friends. Just as Google predicts, I've got about 6 real world groups that I interact with separately, not one big bucket of 'Friends.' Click the image to see more details about these groups.

It looks like I’ve got about 7 discrete social networks (click the image to see more details, labels, etc):

• College friends (mostly from the Hawkeye Marching Band)
• Graduate School colleagues (fellow grad students and professors)
• Current Work Colleagues
• Church friends
• High School classmates
• Family
• Former Job Colleagues (mostly from when I worked and lived in England)

I learned a few things in doing this exercise:

• Facebook turns out to be a pretty decent proxy for my offline social network.  If someone were to ask me, as Google did in their social network user research, to identify my people, place them in groups, and name the groups, this is pretty much the list I would’ve come up with.
• I’ve got more than 10 people in most of my groups.  However, this graph doesn’t really take into account the strength of the connections.  If I were to apply a filter to this graph that only showed people who posted on my wall, or who’s wall I posted on recently, I bet the number would be much closer to 10 per group.  And some of those groups would disappear.  Which leads to…
• These groups and connections are dynamic.  My groups, and my attention to them, wax and wane over time.
• I didn’t need Betweenness Centrality to know that my wife is the center of my world.  =)

Adams goes on to describe that the web is fundamentally changing because it is becoming a web not just of documents and data, but also of people and relationships.  He argues that designers must learn to build systems with these new constructs.  The desktop model of one person, dealing with one system, in a cozy office environment is broken.  Relationships, influence, identify, and privacy must be built into next-generation systems. from the ground up.

That’s a huge mandate for designers and engineers.  It means that your system model has to be extended beyond the HTML, Javascript, and SQL statements; beyond the server configuration and network bandwidth.  Beyond a single user.  When you think about your system, you have to  include and account for the collection of users — their goals, needs, desires.  You have to understand how they influence one another.  You have to understand how they want to segment bits of information into different social circles.

The User Experience of Public Restrooms and Websites

A couple days ago, I accidentally entered the women’s restroom at our local coffee shop.  The signage failure that led to this incident is a topic for another discussion.  But as soon as I walked into the ladies, something felt wrong.  Unconsciously, I noticed the lighting was really bright white.  I noticed it smelled kind of nice…some kind of poppouri.   A few moments later, conscious thought kicked in and I saw 3 stalls with doors, no urinals, and a baby changing table*.  I beat a hasty retreat across the hall into the mens room.  What a stark contrast!  It was smaller, darker, and it smelled…like a men’s room.

In the next few moments, I contemplated this contrast.  This coffee shop has great coffee, reliable wifi, comfortable seating, and an area where my daughter can read books and play.  Yet now I’ve seen clearly that they’ve skimped when it comes to maintaining the men’s room.  Oh, it was clean enough, but it definitely wasn’t as inviting as the ladies.  My estimation of this establishment took a little ding because now I felt like they were skimping in an area that…let’s face it…is pretty important to the coffee drinking experience.

Ok, I’m a UX Designer/Developer…I try to be empathetic.  Maybe it’s harder to keep the gents smelling clean.  Maybe most of their customers are ladies, so they focus maintenance efforts there.  Maybe nice restrooms don’t make men buy more coffee.  I don’t know about that.  But I do know about how my experience with the shop changed, and it made me think about how we, as UX designers, approach our projects.

UX is about more than your product.

I still like the ISO definition of user experience:

…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.

By definition, as UX Designers our job is to look holistically at the system of interactions a user might have with our designs.  This is hard to do in a company over a certain size, where organizational politics, mistrust, and agendas may detract from optimizing the user experience.  While you may not ‘own’ the entire user experience, you can be the watchdog of the experience.  As various teams, factions, or tribes within your company make decisions about their part of the product — particularly decisions that may diverge or contradict each other —  you can help to make clear to everyone the consequences those decisions have on the end users.

Is designing for the 80/20 rule really ok?

I did a quick scan around the shop when I returned to the main area.  Sure enough, lots more women than men.  So I understand why, given limited resources, you need to focus on satisfying the majority of your customers.  Still, that sucks when you’re in the 20%.  I mean, would another light bulb in the men’s room broken the bank?  As online and web designers, maybe we can do more to provide consistently provide good experiences throughout our apps.  I think personas are a key tool to help achieve this.  Personas help you 1) identify different types of system users, 2) design to solve specific problems for a specific person, rather than trying to address lots of problems for everybody.

We’ve all been using the nasty bathroom

I’ve been so accustomed to the low standards of male restrooms, I didn’t really realize that bathrooms could be better.  I think something similar is happening in computing today.  For most of my life, computers were expensive, beige boxes that took up 3/4 of my desk.  Programming an application was a slow, methodical process.  How much things have changed!  Companies like Apple are showing us that computers can be sexy, chic, desirable.  Google is showing us that the web can be fast.  Web development frameworks abstract away the details of javascript or HTTP.  Cloud services allow little old me to build internet-scale applications quickly and cheaply.  The world was accustomed to the men’s room, but they’ve been tastes of how good things might be.

The Challenge and Opportunity

That puts huge pressure on us as UX designers.  Everyone uses technology.  Everyone that uses Facebook knows that a website can push notifications down to you in real time, without refreshes, even if they don’t know about long polling.  Why do they have to refresh the page on your website?  Everyone that uses Feedly knows that a webpage can know when you get to the bottom of a page and automatically load the next entries in the list.  Why do they have to press a more button on your website?   Everyone that uses Alice knows that a company can provide free shipping, be cheaper than my local stores, and actively help me manage and budget my spending.  Why is shipping on your website so expensive?  Why doesn’t your site know what I want, rather than just force me down your fulfillment process?

The exciting part is that the constant change means that UX practitioners must be constant, lifelong learners.  We need to know about the current best design practices, information architecture practices.  We need to understand the business and operational constraints.  We need to understand the market.  We need to understand when we can apply an existing UX design pattern, or when to create new ones.  It means that our jobs are not easily automatible, repeatable, transferrable (at least for now).

* Note to coffee shop owners: This is 2010.  Men drink espresso, and care for their infant children.  We’d also appreciate a changing table in the gents.  It’s been 2 years since my daughter was in diapers, yet I can still tell you all the businesses in town with a changing table in the men’s room.  I’ve spend hundreds of dollars at Capanna Coffee after running across downtown to find a business with a changing table.  If you don’t have a changing table in the men’s room, you’re losing money.

How Not to Sell Your Work…Talk Technology Not Pain Relief

We recently had a contractor come to our house to give us an estimate on replacing an old, metal, drafty patio door.  My impression was that he was extremely knowledgeable and capable contractor.  But after an hour, I didn’t feel like I had enough information to confidently make a good decision about which option to take, and we’ll probably not buy from him in the near term.

As I thought about the episode, I realized the contractor failed to sell me on his services in the same way that technology developers/designers fail to sell their clients on their work:

He did not ask us what problems we wanted to solve, or what goals we wanted to address.  Instead, he came in spouting off meaningless specifications about specific products.  I didn’t know anything about R factors or UV specs or double vs triple pane glass, so the fact that this product has a .2 or a .07 means nothing to me.  Is that good?  What’s the typical range?  How does that compare to what I have now?  And most importantly, how much might we expect to save on our energy bills going with the super-awesome door vs the middle-of-the-road door?

This is similar to software developers…I know we tend to get caught up in, “we should use this tool because it supports this new web standard” or “we should buy this because it has 1.21 gigawatts of power.”  Clients don’t care about any of these things.  They have a problem they want to fix, or an opportunity they want to attack.  All they care about is can you help them solve their problems.

Sell your work by focusing on the clients’ problems

• Understand your clients, their pain and their goals. What’s hurting them or prompting them to make the change. What do they want to achieve as the result of the change (these two aren’t always the same).  The core of the discussion should be that you can alleviate some of their pain.  Once a client is on board with that, you can get into the details.
• You may want to avoid, or at least postpone, discussing the quantitative specs of the tools or systems you’re proposing.  At best, your customer will gloss over this ‘irrelevant’ information and you will have wasted their time, and your opportunity to speak to them meaningfully.  At worst, you’ll have a customer like me that wants to make sense of the numbers, and you get stuck discussing minuscule details?  You want a 8 core processor?  What do people normally use?  Is that high end or low end?  Why can’t we make it work with 2 processors?  I read that Google uses lots of really cheap single processors in Wired…can we do that instead?  This leads to…
• If you do need to get into the details, provide a frame of reference for your discussions. Instead of providing raw numbers like “the error rate on this page is 29%” give it a frame of reference, eg “On pages like this, we see error rates from 25-30%. The current page has an error rate of 33%; the suggested changes should reduce it to 27%”.

UX Designer/Developer Core Competencies

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?

Avoiding Bias in Agile UX

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.