User Experienced @user-experienced - Tumblr Blog

Web Teams Should be More Like Volvo

Volvo has less faith in drivers than most companies do. Since the seventies, it has kept a full-time forensics team on call at its Swedish headquarters, in Gothenburg. Whenever a Volvo gets into an accident within a sixty-mile radius, the team races to the scene with local police to assess the wreckage and injuries.

This is an excerpt from a recent New Yorker article on the "self-driving car", (Auto Correct, November 25, 2013). Smashing idea, I thought...

What if web teams could be more like the Volvo Cars Safety Center response team? In some ways, it should be easier:

There are no geographic limitations. We can reach out across the internet to a user in distress anywhere in the world.

It doesn't necessarily take a team. Just a single person (or when done well, even a program) can collect information when something goes wrong.

Consequences are less dire. In general, a web transaction gone wrong will not result in injury or death.

In other ways, though, the job is harder:

The moment is fleeting. When a car accident occurs, for those involved time almost stops: the evidence remains in place, the people don't instantly move on with their lives. On the web, users may give you a second chance, posssibly try to contact you, but probably they will just leave, frustrated, and all the circumstances surrounding their issue are gone.

The creepy factor. People in a car crash are probably more than willing to assist investigators. But if a company livechats you or phones you, having noticed you're having difficulty on their website, that would be...super creepy.

Of course, you can piece a lot together from your web analytics, and have your website report errors and mishaps. However, this doesn't tell you much about the user or what she expected or was trying to accomplish when things went pear-shaped.

"Our vision is that no one is killed or injured in a Volvo by 2020...Ultimately, that means designing cars that do not crash."

"Our vision is that no one is frustrated or flummoxed by our website...Ultimately, that means designing a website that does not crash (in the broadest sense of the word)."

#usability

Information vs. Understanding

If you are a bike commuter, you may be more interested than your Average Joe in one aspect of the forecast -- the wind. How strong is it going to be, and from which direction? (Or maybe it's only wimpy bike commuters like myself that bother with such things).

When checking yesterday's forecast I noticed a perfect example of something Stephen Anderson talked about in "Help Users Decide" at UI18: information vs. understanding. I look at the weather forecast to help me decide whether to bike to work and what to wear if I do.

Weather.com has all the information I need:

But Google's presentation helps me quickly understand:

"SSW at 18mph" from weather.com's app carries (causes?) extraneous cognitive load:

SSW = south south west

what direction is that?

is that to the south southwest, or from the south southwest?

what direction will I be traveling in?

Google's display bypasses all of this. It uses simple arrows to show wind direction, and emphasizes wind strength by varying the arrows' sizes. Show, don't tell. Provide understanding, not just information.

NB. Wind direction is the direction the wind is coming from.

#user experience #information design

UX Questionnaire

I am embarking on my first real UX project -- revamping an internal website used in my company. I'm lucky to have just finished the book, "The User Experience Team of One" by Leah Buley, which is full of useful methods for each stage in the UX design process.

I'm starting with the very first in the "Planning and Discovery Methods" (Chapter 5): The UX Questionnaire. This seems like a tool to just let you take stock of what you know, what you don't know, who will be involved...basically just a formal way to make you take some time to look before you leap.

Buley lists several things you might include. For my project, I made a simple template with:

Team

Users

Goals

Success Metrics

Tasks & Scenarios

Everything up to Tasks & Scenarios was fairly easy to fill out on my own...given the entirely internal scope of the project. For that last portion, I had to talk to a couple of key users to get some example tasks.

Here's a shot of what my completed UX Questionnaire.

And if you like, here's the blank template I came up with.

#UX #UX Questionnaire #UX Methods

The "KJ Method"

At Christine Perfetti's workshop at UI18, I learned an interesting method for prioritizing development tasks, user feedback, etc.

The method goes by a couple of names: "KJ method" (or KJ session, using the initials of its inventor, Jiro Kawakita), and "affinity diagramming."

I think the method could be helpful when you have a list of feature requests and bug fixes, and limited resources or time. You've got to prioritize, and if you ask 4 different people you'll get 4 different priority lists. So it seems a good way to come to quite an objective consensus.

The Process

Put ideas on post-its In the case of a list of dev tasks, you probably already have them in some kind of ticket system. Ask each participant to bring the 5-10 tasks they think are most important. Put all the stickies on the left side of a wall, randomly.

Gather the troops Get together a few (probably 10 or fewer to keep from overcrowding) key people (developers, marketers, customer service people, other folks coming up with the tickets). Give people a chance to peruse the posted notes.

Group stuff Without talking, people then start to group the tickets, by taking pairs they feel belong together and moving them to the right side of the wall, in a column. This continues until all the sticky notes have moved to the right side of the wall. There may be single-sticky groups. Keep plenty of space between the columns.

Combine and regroup At this point people are free to combine columns, move things they think are misplaced, and so on, but no discussion is allowed.

Name the groups Everyone provides a "header" sticky at the top of each column, giving each group a name.

Pick three Have each person write down the names of the 3 groups she feels is most important. Then, ask everyone to rank their 3 in order of importance.

Vote and tally Each person marks 3 X's on the header for their top group, 2 on their second priority, and 1 on their third priority. The X's are counted up, and there you have your democratically achieved ranking.

Results

We went through this exercise in Christine's workshop using the question: "What are the worst parts of the air travel experience?". It was a surprisingly tidy, efficient way to both categorize and prioritize issues.

I hope to try it out with our company's ever-growing dev priority list soon.

Further reading

Much of Dan's talk condensed into a blog post

An interview with Dan

A range of what I would call proto-microinteractions for inspiration

#microinteractions #ui18 #user experience

EyeQuant Review

I'm always interested in new tools to analyze websites and better understand website users' behavior. Once such tool I learned of recently is EyeQuant.com, which claims to be "an artificial intelligence that instantly predicts how users will see your website so that you can create landing pages that sell."

A Fast Company article on EyeQuant piqued my curiosity, and my skepticism. The article includes a few examples of EyeQuant's "Perception" maps ("content users' eyes will gravitate towards within three seconds of loading a page," and "Attention" maps ("content users will find the most and least visually appealing." Which I suppose means where there eyes will linger?) I had to take the descriptions of each map from the article, as they really are not explained on the EyeQuant website.

Doubts about EyeQuant in particular

My main concern is: the two maps do not appear to be distinct. The difference between where users eyes will simply alight in the first 3 seconds of viewing a page, and where they will focus thereafter is important. For example, many users will fixate on Amazon's logo, but few will spend more than a fraction of a second looking at it -- just a glance to confirm they are where they think they are. The maps given in the article, though, as well ones from the website I work on (see below), appear to show the same data for Perception and Attention in a different format.

Secondly, the Attention Map of Google's homepage raises an important question. Which users' Attention are we talking about? People who have never looked at Google? People who are taking an eye tracking test? People who use it multiple times a day and are using it now to actually perform a search?

Doubts about the usefulness of this type of tool

The Fast Company article offers examples from Amazon, Google, and a classic example of poor web design, amongst others. None reveals anything that a competent designer (or perhaps, any average web user) couldn't have concluded in a minute. Oh, people looking at the Google homepage look at...the only stuff that's on the page?! Wow. And people who look at a website cluttered to the max look all over somewhat randomly?! Shocking.

It is not hard to get people's eyes to look at what you want them to look at: follow a few basic principles such as clear hierarchy, uncluttered layout, avoiding reversed-out text, and plenty of whitespace. (See, I nailed it in the screenshots above without eyetracking a single user!) 5-second tests or just pulling aside coworkers and watching as they scan the page can validate your design.

The far more difficult task is to figure out what you want people to look at (what message or image is the right one?), and no amount or quality of eyetracking data will reveal that.

#eye tracking #usability #conversion

Think About What You Link

I discovered a couple of interesting things recently using UsabilityHub's Click Test.

Don't click there!

In a usertesting.com test, when asked to start using a particular tool, one participant hesitated -- first hovering over a link at the top of the page, and saying "Well first I was going to click here, but now I'm confused...".

Having built the page, and knowing that link was definitely not where to start, I thought "Why the heck would you click there lady? That makes no sense!". But, I wanted to see if it was just this one person, or if the link was really throwing people off. To get some quantitative data, I set up two variations of a click test on UsabilityHub: one with the link, one without.

As you can see four people (out of 20) clicked on that link.

For the second variation, I removed the link and also added a headline, showing (I thought) exactly where the tool begins on the page. So, while only one person clicked near the area where the link had been, 4 people now clicked on the headline I'd added.

I guessed that maybe this looked a bit link-y or button-y because of its blue background, so I set up one last variation in my click test. This time I gave the headline a very subtle, neutral gray background. Sure enough, this reduced clicks on the headline.

Conclusions

Don't put any extraneous links on the page, even if they seem logical. Links should be relegated to navigation, or directly support the task at hand.

Be careful you don't make something that's not a link look like a link or button.

Don't Ask Your Designer to "Make it Red"

I was recently asked to make a small element on one of my company's web pages red. Now, we already use red on that page, for a very specific purpose -- sale messaging. So I felt red was inappropriate for this element, as it had nothing to do with sales at all.

Moreover, this type of request is not what designers -- UI, web, graphic, or otherwise -- are for. "Make it red", "Make it bigger","Put it in caps", "Use a gradient" -- these types of requests, while sure to annoy any designer, don't benefit the end product. "Make it red" is a proposed solution. That means there must be a problem, and that is what designers want to know: "What is the problem you are trying to solve?"

Something a little closer to a proper design request would be "we need to make this element more prominent". Ok, I can work with that. But again, why? Do users not see it? How do you know? Are you just guessing? Designers cannot be afraid to ask "why?" until they get to the root of the request.

So, even better than -- "we need to make this element more prominent" would be something like "customers are calling with questions about this product, how can we make the explanation clearer on the website?" That is a real problem, and from there a designer can propose effective solutions.

#design

The User is Not a Designer

As freelance graphic and web designer, I quickly learned that my clients were not designers. After all, that's what they were paying me for. As difficult as I sometimes found it to decide amongst subtly different logo variations I'd created, I knew that throwing them all at my client and asking "which one do you prefer" wouldn't turn out well for anyone.

The same applies even more strongly user interface design. The role of the designer is NOT to mock up 3 different layouts and then ask someone else, be it her boss, the CMO, or her end users, which one they "prefer." It's just...irrelevant. Now the good news is, unlike with a logo, there are ways to put a UI design to the test.

What not to do

I have been using usabilityhub.com a lot recently, experimenting with click tests and five-second tests. You can earn responses to your tests by taking others' tests (awesome), and I always find it interesting to see what other people are testing. I have noticed that a lot of people create click tests containing multiple variations of a design in a single image. The instructions are usually something along the lines of "click the one you prefer".

Instead, see which actually performs better

A better approach would be to focus on one function the design has to serve or piece of information it has to convey, and set up a test with each design as a separate variation. (Luckily, UsabilityHub has this functionality built in quite brilliantly).

For example, in a list of products, users have to be able to add the quantity they want to the cart. So you could set up a click test with multiple variations, and ask testers where they would click to add 2 widgets to the cart. After the results are in, you can compare them side-by-side to see where people clicked, and which was most successful.

Exceptions to the rule

There are certainly contexts where "preference" is valid. As Jakob Nielsen points out, if users have had a chance to really try out two different interfaces, and thus truly know which one works better for them, their preference is important. More specific questions than "Which do you like better?" could also provide good feedback, such as "Which logo says 'eco-friendly'?"

But, to paraphrase George Bush: "I'm the designer, and I decide what's best (based on careful observation and study of user behavior, as well as years of experience and schooling. Also, I'm willing to change my mind based on evidence. That is all.)"

Related reading

First Rule of Usability? Don't Listen to Users

Three Questions You Shouldn't Ask During User Research

The Homer

#user research #usability testing #usabilityhub

A Few Discoveries About Remote Usability Testing

I just completed some remote usability testing (3 on usertesting.com, 3 on youeye.com) for a new tool I am working on at my company, Smart Destinations. Sure, I learned about some flaws in the interface, but I also learned a few things about setting up remote usability testing:

1. Be explicit in your instructions; avoid pronouns.

My first task read:

"What can you do on this page? How do you expect it to work?"

In normal writing or speech, "it" would clearly refer to "this page." However, almost all participants assumed "it" referred to the product discussed on the page, the Go Chicago Card. This led to some confusion and frustration for them, and little useful feedback for me.

2. Provide enough information

It's hard to strike the right balance between giving testers sufficient context and bogging them down with details or worse, providing them information you actually want them to get from the page(s) you're testing. However, if your test is focused, especially on a subpage or specific feature, it's better to err on the side of too much information, so the tester doesn't get distracted and veer off course.

3. Make clear what portion of the site the person will be testing.

Most people assume they are starting on (what they refer to as) the "homepage." This struck me as odd, given how few of our site's visitors actually do start on the homepage. Do they assume this only in the context of usability testing? Or whenever people click through to a website from a search engine result page, do they generally assume they're landing on the "homepage"? Perhaps people misunderstand what a homepage is? I'm not sure, but the upshot is you may want to make clear in the introduction where in the overall site hierarchy the tested page sits.

4. Steve Krug is right, 3 is enough.

Obviously, this is not my own discovery. I chose 6 participants for this test, but learned 95% of what I learned overall after the first three participants. It would far more productive to do frequent tests with fewer participants.

5. Seeing people's faces may not be all that helpful

So, when I first tried youeye.com, I thought actually seeing the participants in their webcams was pretty compelling. However, having run this second test on both usability.com (no webcam), and youeye.com, I wonder how much more you learn from their facial expressions than just their tone of voice. In Rocket Surgery Made Easy, Steve Krug says don't worry about recording user's faces. He may be right.

#usability testing #usertesting.com #youeye

Explain Yourself! The Challenge of Explaining a Novel Product

Some products don't need much explanation...a pair of shoes or a notebook or a can of tennis balls are products people generally understand. But if you're selling a product or service people may not have encountered before, such as multi-attraction passes (just to pick one out of the blue), part of selling it is conveying the very concept of it. Communicating this concept succinctly and clearly is important, and can be a real challenge, for a few reasons:

There are a lot of competing voices: the marketing team, the customer service team, the user experience team.

The reading level of the folks writing the copy may not match up with the target audience, whether it's due to education level or a language barrier.

Anyone inside the organization is already familiar with the product/service, so something that seems obvious to them may not be to the customer.

Lastly, it's really hard to test. Contrary to what some services would like you to believe, it's not going to be easy to A/B test a few words or phrases and get significant results, even though it may be impacting your conversion rate or customer satisfaction. Unlike with user interface testing, you may have to test with a lot of people to get significant results, and you may get more accurate results testing with people in your target audience.

A couple random ideas I have to help with this quandary are:

Listen in on customer service calls. See what words customers are using, what questions they are asking, and how the customer service reps answer them effectively.

Try introducing your product to complete strangers. Just go out and talk to people face to face, and see what works.

I can imagine a testing tool that could help with this as well. A reading comprehension test of sorts, for marketing and post-purchase copy.

Hire a really good copywriter.

#copywriting #marketing

UsabilityHub's Five-Second Split Tests

I recently discovered that UsabilityHub allows you to test multiple variations of a page in a single 5-second test. After I set one up (please take the test if you like), I sent them some feedback about being able to share a single url, and have users see one of the variations at random. Not two days later, I got this email in reply:

This feature is now live. Next time you're running variations of a test, you'll find that there's a link to share that will divide your participants as evenly as possible between the variations (image below). You can still link to each test individually too, but users will only be able to complete one variation. Would love to hear your thoughts!

Well, my thoughts are: "Kick ass!". Not only is this feature useful and nicely implemented, the responsiveness of UsabilityHub, and more generally the modern web app development environment is incredible.

So, try it out. Take my test, or create your own.

You may be surprised at what you discover. I found that my pages are utterly failing to communicate much of anything in 5 seconds, but that's for another post.

#five-second test #usabilityhub #usability testing

Better Websites through Conversation

In a podcast interview from UIE, Stephanie Hay takes a question from a listener (skip to minute 16:45 or so) on how to avoid overloading users with too much information up front. Part of her answer:

"What is, at this level...what are the core questions that the user has that we need to answer. What are the keywords that the user needs to see to feel like he or she can keep scrolling...or whatever the next step is."

Since hearing this, I've been thinking about "testing the conversation."

Your website is a conversation

Ginny Redish has an excellent post on this in UXMag. She encourages us to "think of your website or app as replacing not file cabinets but phones."

Your website is in essence a conversation with your users, and it should reveal information progressively. You don't normally tell someone you just met that your favorite movie is Bottle Rocket and you hate country music, or blast them with your entire life story. You probably start by telling her your name, and let things progress naturally from there. Each of you asks questions and gains more information as the conversation goes along.

Talk offline

How can we translate this conversational process to a website? Redish suggests basically, using your imagination:

Select a persona. Be that persona. Get into the persona’s mind and life. Then go to the site or app as that persona with the persona’s attitude, motivation, knowledge, vocabulary, and task or question.

But I think another, maybe complementary, approach would be to have real, offline conversations, while sort of playing the role of your website.

Here's my proposed process:

If you already have a website, write it out the copy as a conversation.

Figure out how you're going to introduce yourself. What few words about your product or service will make someone want to stay and chat?

Find someone who could reasonably be your site visitor -- don't worry about demographics too much. If you can, get their permission to record.

Introduce yourself, and let the conversation proceed from there.

Hopefully, patterns will emerge, with people asking for similar details or levels of detail at the same points in your conversations. Determine if the information hierarchy and copy you have on your site adhere to these patterns and successfully engage them in a "conversation."

Or, if you're lucky enough to be starting from scratch, let these conversation patterns inform the information hierarchy and even the language of your pages.

NB. I haven't actually tried any of this. I hope to, but for now it's just a proposal. It's probably a much messier process than I'm imagining, and if I do work up the courage to go out and talk to strangers, I'll write about it.

#usability testing #conversation

Trending Blogs

Recently Viewed Blogs

User Experienced