World of Usability

Imagine you’re working on a web project that has high visibility. Lots of stakeholders at high levels are involved, and they’re getting impatient. They want to see results, and they want it now. You’ve thrown together a quick design, but you haven’t started coding yet and time is getting tight.

Now might be the time when you want to throw in the towel and scrap your planned usability efforts. The design is good, in your eyes, and the customer likes it. But is it a good idea to skip the usability?

Even if you’re fairly sure you’ve got a good design, if you’ve not had a real user try to use it, how can you be sure? The best designers in the world can’t pre-guess what a user will do–there are always gotchas that are obvious after the fact, when it’s incredibly expensive to fix. It’s better to be safe and get that user feedback BEFORE you’ve set it in stone. Would a scientist who’s in a hurry skip the data collection and start writing the paper? A little data collection here could go a long way towards improving the user experience.

But when you’re in a time crunch, how do you fit it in?

There is a technique called paper prototyping that’s incredibly valuable, especially if applied before you start coding. Why not take a few days (or weeks, if you have it) and discover what those gotchas are before you start coding? The test doesn’t have to be big and complicated, with a formal test plan. You will gain incredibly valuable input just by showing your design to a few users, asking them a few questions, and having them pretend it’s a real screen and try to do a few tasks (”clicking” or “typing” on the paper)–while you pretend you’re a computer and feed them the next screen design. (Paper prototyping is even more valuable at the wireframing stage, before you have a design, but the same concept works after you’ve sketched out something in Photoshop.)

Jakob Nielsen, usability guru, says “the biggest improvements in user experience come from gathering usability data as early as possible in a design project. Measured usability can increase by an order of magnitude when you can change the project’s basic approach to the problem, change the feature set, and change the user interface architecture.”

Resources:

• See Jakob Nielsen’s articles on Usability Misconceptions and Paper Protyping.
• A List Apart also has an article on paper prototyping.
• Paperprototyping.com has some useful templates and scripts for download.

Recommendations for success:

1. If you need to skip something, skip the formality and the committee, not the test. Usability testing designed by committee takes a long time–and all the formal plans and reports are time consuming. When you’re in a hurry, be open to a more informal approach–and explain to your leadership why it’s necessary (to meet the timelines they want).
2. Remember your goals for the project. Let those goals guide the tasks for the test. Select just a few key tasks (based on the goals) and use the same tasks for all the users.
3. Don’t let naysayers get in the way. Whatever you do almost anywhere, there will be a few people who will question what you did or how you did it. Yes, you should listen to what they say because some of their feedback may be relevant and useful, but it shouldn’t keep you from getting real user feedback.
4. Don’t set the design in stone too soon. Remember to be open to feedback and don’t get too attached to that design–and make sure the customer knows you may have to change it, but if you do, you’ll have real evidence to back it up.
5. Remain flexible and be open to new ideas. If the user has issues with the design somewhere, open your mind and think of a new, better way to make things work. Good design is hard because sometimes you have to break your own misconceptions and habits. Don’t be afraid to step outside the box.

 I encourage paper prototyping in every environment–no matter what the political or time constraints. As Walt Disney says,

“It’s kind of fun to do the impossible.”

Architecture 2030 has published a document with a simple concept for solving global warming, which also would save consumers money and boost the economy. It’s based on the principle of phasing out coal, boosting energy efficiency in buildings, then slowly replacing fossil fuel-based energy with renewable sources.

It sounds so simple … and is already being adopted by several organizations.

Here’s their Blueprint.

I took a moment to look at my blog and realized that it’s been since March that I posted anything–and here it is May already. Wow. I can’t believe I neglected my blog that long! But then considering what was going on in our lives, it makes sense. We’ve moved into a new home and not had even a moment for anything extraneous. Things are finally starting to slow down a bit, but still our garage is full of boxes and there are so many things that need setting up. Still we can cook, we can find our clothes, and we can take a shower, so life has almost resumed a sense of normalcy. It’s still crazy, but then soccer season always is …

I’ve also not done much with usability lately other than arguing with my boss and a couple of the engineers about how things should be implemented. Why is it so hard to get the usability message across to some people, while others just seem to “get it”? I hate the arguing and want to find a more productive way to communicate. 

That’s, I guess, where Morae would really come in handy. I’ve asked for it, but am still waiting on it. The thing that makes Morae so very handy is the fact that you can capture video, screen, and voice, and really show the engineers what the user experience is like.  I had it at my previous job and just wish I could have brought it with me!

Some reviews of Morae, for those of you who aren’t familiar with it:

• Morae review from Web Usability
• Usability Testing with Morae 2 from e-consultancy
• Usability Testing Lab-in-a-Box from Robin Good

One of the usability rules that you might have heard is “provide the user information where and when they need it.” Sounds like a no-brainer, right?

It sounds so simple … but it’s harder than you might think.

It goes hand in hand with another usability principle that goes something like this–”don’t take a user to another room unless it’s really necessary and justified“. What does that mean? Well, every time you move to another page or bring up a dialog box, think of that as having taken the user into another room. Let’s say you’re on a USGS web site that has information about each of the U.S. states. Think of the page you start on as the living room–do you really need to take the user into the kitchen to ask him which state he wants to look at or give him the information he requested? There are times when it’s good to switch rooms, such as when you’re switching topics, but I would caution you to consider that decision carefully.

Hyperlinks on the web enable a lot of room-switching and it’s very easy to fall into the trap of hyperlinking to new pages, when you could provide the information right there and then–when and where the user needs it, without the hassle of moving to another room.

I am going to pick on the USGS earthquake center for an example. They have a lot of fantastic information on their site and I love that they are using many of the new technologies available. Some simple modifications that reduce room-switching would really improve the usability of the site.

1. Let’s start at the worldwide earthquake page on their web site.
   • Click on one of the more isolated earthquakes. You are taken to another page (a new room) listing the details of the earthquake. Now the user has lost the visual of where the earthquake they clicked on was located. There is a “Maps” tab that even includes a Google Earth KML file and a Google map, along with lots of other useful-looking maps, but still the user can’t see the earthquake details and the map at the same time.
   • It would be very simple to replace the original world map with an interactive map with placemarkers for each earthquake. (Google Maps does this very well–and it’s free and easy to implement. Tim Mentele has done a lot of work with them already.) When you click on an earthquake placemark, the placemarker balloon could give you all the detailed information right there within the balloon. Voila! Information right where and when the user needs it–without leaving the room!
2. Similarly, open their KML file in Google Earth.
   • Click on any of the dots. An information balloon comes up with a link to their web site for the earthquake details.
   • Now imagine that information from the web site right inside the KML info balloon. It would provide the information in the geographic context the user requested it in and eliminate the uncomfortable and unnecessary room-shifting.
   • You do have to moderate the use of this because you don’t want to overwhelm the user with too much information, but there are ways of segmenting information to control that. (Tabs work well … like the USGS Earthquake Center has employed on their web site.)

There are many other examples where this simple usability principle could be employed. Where could you use it?

So a little while ago I posted a few entries on prototyping tools for software or web applications. I decided to try Axure (vs. iRise) for one simple reason: I wanted to be able to draw a box on the screen. It’s really important to be able to group things on a screen.  iRise, the enterprise wireframe and collaboration tool (that goes for $6000 for a 5-user license) couldn’t do that one simple thing, so I decided to try out the $599 Axure instead.  I really love the iRise blog and the way their people think, but that one little feature was the deciding factor for me. I can find other ways to collaborate (there are all kinds of collaboration tools out there–we simply hosted the pages and walked through them one by one on a conference call), but I can’t do without the ability to group things on the screen. I’m down to 9 days on my trial of Axure and it’s become such a part of my daily work routine I can’t imagine life without it anymore. Before we buy, though, I wanted to see if there’s anything else out there. Anybody know of anything that compares with Axure? (besides iRise?) 

So here’s what I think of Axure.

What I like about Axure

Overall, it’s a fantastic tool for quickly mocking up screens and working out the basic layout and functionality of a web site or application. It’s a simple drag-and-drop interface that allows you to drag widgets onto the screen and define some simple interactions–and it even gives you some simple tools for mocking up web 2.0 interactive functionality. The great thing about it is it’s quick. You can show your customer (and the software engineers) an interface they can relate to, get feedback from your customer, make changes, and turn it all around in a matter of minutes or hours (instead of days or weeks). What a fantastic way to communicate and work! The time saved in getting that done is way worth the price tag. You have to think about it in terms of labor hours instead of the cost of the tool–is it worth it to be able to turn around changes in a few minutes or hours vs. days? How much is your time worth? It doesn’t take long to add up to $600 of labor time.

My boss also looks at it this way: he can hire a designer who understands how to design layouts and interactions, but is not necessarily an XHTML/CSS guru. They don’t have to know diddly squat about the technical side of this to make a usable(and even beautiful) design. Then once we have the design figured out, we can pass the design off to someone who does know how to code. This type of tool gives us flexibility in hiring as well as design.

 Other things I love about Axure:

• It allows for dynamic interaction in an AJAX world. You’re no longer stuck with static screenshots for wireframes. You can actually interact with a page, have panels show and hide based on some actual conditions (like “if this box is checked, show this panel”)
• You can make notes about how a page should work as you design it. Sometimes you don’t have time to sit down and put in all the interactions. Axure handles that situation beautifully: with page notes. When you generate the prototype, Axure shows a list of all the pages in a frame on the left, the page notes in a small frame on the bottom, and the main page. You can close those extra frames if you want to, but I found them to be a lifesaver.
• You can generate interaction flows that show the logic as well as specifications from your designs. The specs show all your page notes along with the screens.

The best part is just being able to mock up a screen quickly and beautifully and really illustrate how the web site or application will work. Most users don’t know what they want–they need to see it in action first to really understand.

What I don’t like about Axure

1. It makes really messy, heavy HTML code. Every graphic on the page, even if re-used, is saved as a different graphic. Every page in the mockup comes with a folder full of “stuff”. They take forever to load on a real web server. You really have to throw away the code and create your own HTML (assuming you don’t want heavy, grossly awful HTML behind your site).
2. It has styles, but doesn’t make use of CSS. You can define styles in Axure and apply them to text, but those styles then get hard-coded in the HTML separately. Every line of text has it’s own style.
3. You can only put text in a table. On “real” web pages, you can put ANYTHING in a table cell, a graphic, a form element, anything. Axure lets you do that only by putting a div placed in a certain place on the page. The form element or image is not actually “in” the table cell, so if the table cell gets resized, you have to move all your images or form elements back into the right places.
4. When I draw a box, it always wants to snap to the grid instead of the right edge of the header graphic. To get them to line up, I have to set the zoom level to 200%, line them up, then zoom out again. I haven’t found a way to turn off the snap to grid “feature”

 Other reviews of Axure:

• Wireframing in a Web 2.0 World
• Is Axure the Answer?
• Software Review: Axure
• Review of Axure RP Pro

So how do you do this elusive thing called a usability test? ClickZ and Digital Web Magazine have writeups on it,  and User Interface Engineering has an article on the Common Usability Testing Mistakes.  

There are different approaches, depending on what stage of development you’re in, but the basic premise stays the same:

1. Develop a test plan. The “meat” of the plan is the tasks you’ll have the users attempt. 4 to 6 tasks is a reasonable number. Don’t try to include too many, or your test gets too long. Too few, and you don’t cover enough ground. Here’s a Usability Test Plan Template you can use.
2. Find some representative users. They can be friends or relatives, but they need to be from your target user group. Some people have temp agencies hire people for testing, but I find it easier to just start asking around. (Make sure you have lots!) Most people are very willing to participate–all you have to do is ask. Dana Chiswell provides some useful tips on choosing participants.
3. Perform the test. Sit down with the users, one at at time, and have them attempt the tasks in your test plan. Ask them to think out loud as they go, so you can understand what they’re thinking. You may be tempted to show them how it works–don’t! It’s critical that you let them struggle through it on their own so you can see where the software doesn’t make sense for them. According to Jakob Nielsen, you only need 5 users–I find you need anywhere from 3 up to 10–once you start hearing the same story from each user, you can quit.
4. Observe, ask questions, and learn. Some people aren’t very talkative, so you have to ask a few probing questions to get their thoughts. It’s helpful to record the session using something like Morae or WebEx. Use a webcam to capture facial expressions, if you can. Little video clips from the test can be an invaluable (and extremely convincing) communication tool!
5. Give the participant a gift. It’s important to thank your participants. Some people pay them. I think it’s nice to give them a gift. Make the gift proportional to the value of their time.
6. Analyze the results. Look for common ground amongst participants. Where did they struggle? What frustrated them? What did they like about it?
7. Present the results. Always, always, always start the presentation with “the good stuff”, but warn your audience that you’re going to give them the bad news next. They to know your intent is to help build a better product, not to cut them down. It’s important that they know there will be some bad news, though, and when it’s coming. Use video clips from the test to underscore your findings. The clips are often painful for developers to watch, but they get the point across.

I really like what John M says about Usability testing:

“Whilst planning for Usability Testing, its easy to constrain it to be more of a “Validation” type technique. Usability testing & the information gathered from the exercise, should serve to make informed design & development decisions right from the outset, thereby acting in more of a “preventative” role.   The idea in the case of Usability testing is to test early & test often. Usability testing lets the design and development teams identify problems before they are deeply entrenched. The earlier those problems are found and fixed, the less expensive the fixes are. As the project progresses, it becomes more and more difficult and expensive to make major design changes. The more you test and change based on what you learn, the more confident you can be that your application will meet your objectives and your users’ needs when it is released.”

 So, with a little usability testing, you can avoid situations like this:

What development process should we use to ensure the product (or web site or software) is usable? When should you start usability? I think I’ve said before that you should start usability right at the beginning of the process. It should be integrated right into the systems engineering process or any other development process you’re using. Bringing a usability person on at the end to “bless” your project is NOT going to work. I wouldn’t want my name on any project that approaches usability this way–yet this seems to be how most projects want to do usability. Bringing usability in late is, admittedly, better than never, but to really benefit from usability practices, you have to use it throughout the entire development process, right from the start of the project.

There are established processes for usability and many different tools you can use along the way. Usability.gov and NASA both have process models. James Williams Helms of Virginia Tech wrote a paper on the LUCID/Star Usability process model.

Here is the process in a nutshell:

1. Research and Planning: this part involves researching your user community, gathering statistics, usability testing the existing site/product/software, performing surveys, interviewing users, developing personas, and determining the requirements and goals for the site/product/software. Make sure you understand your users’ goals, motivations, and work flows. Know what they come to your site for, what tasks they are trying to complete, what information they seek. This is critical.
2. Conceptual Design & UI Structure: Use card sorts to help you with your UI structure. Sketch out pages, show them to users and see if they understand them. Modify as appropriate. Remember what Frank Lloyd Wright said:
   

   “You can use an eraser on the drafting table or a sledge hammer on the construction site.”

   Now is the time when changes are cheap, so take full advantage of it. Don’t try to lock down your design too soon. Iterate your design with feedback from real users. Present the feedback from your tests to management and explain the logic behind your design. Don’t be afraid to push back if management asks for something that doesn’t make sense, or if they want to change something on a whim. They expect us to deliver the best solution–we have to tell them what approach we should use, and why, to get the best possible product.

3. Detailed Design & Usability Test: For a web site, you might start to mock up some pages now, and develop the flow of the site, but don’t start programming too soon. Use simple HTML hyperlinks or even Powerpoint to show the flow. Let users hack away at your prototype (via usability tests) and revise the design appropriately. Be open to change, if it’s needed. This is the time to change, before you’ve started programming. Programming is expensive. Making changes later will cost much more. Make sure management understands that. Talk a lot about the user experience, use statistics, show user feedback. Our management wants our end users to be happy, and most of the people on the leadership team have said to me (in interviews) that their opinion doesn’t count–it’s the users’ opinions that count. Make sure you make it count by giving the users plenty of opportunity to express their opinion along the way.
4. Develop & Usability Test: Now that you’ve iterated the UI design, you can start making it work. Hopefully your usability tests to this point have uncovered a lot of the gotchas. But still, do more usability testing as you go, especially when you run into questions about how something should work. It’s best to just test it. Always include usability test results in your management meetings. They show very clearly the reasons for every design decision. Let management make the decisions, but give them enough information to make the decisions that make sense for the user.
5. QA test, etc. and Launch: Usability testing doesn’t ensure you’ve caught all the end cases, the bugs, etc. Make sure you test for bugs and handle errors with care. Treat the user with respect, and make sure all error messages are in user (not programmer) terminology, that they are kind and they blame the software, not the user, for the error (even when it is the user’s fault). Nobody likes a product, web site or software that makes them feel stupid.

That’s pretty much it in a nutshell. Notice usability isn’t just a usability blessing at the end–it’s involved from the very start, when you’re doing user research, developing personas, formulating your requirements. Don’t get stuck in “the way we’ve always done it.”

Projects that incorporate usability practices get meaningful results–I’ve seen metrics reported like improvements in sales of 100 to 700%. Notice there’s a wide range there. Projects that incorporate usability from the very beginning get much better results (closer to 700%). Projects that invite usability at the end aren’t going to see as much difference.

The same amount of effort, applied at the right time in the process, can have a huge impact.

Thanks to my good friend Carla, I was drawn to a LinkedIn Answer today that helped me answer the predicament I’m finding myself in. I need a good tool for mocking up my UI screens, quickly. I could use something like PowerPoint, but I’d like something that helps me work faster, with pre-built widgets I can drag and drop onto the screen. I’d been looking at iRise, but I was frustrated that there weren’t any simple drawing tools in there. I want to be able to draw a box!

So I’m downloading the free trial of Axure today to try it out. It’s got the drawing tools I was looking for, at a fraction of the price of iRise. I’ve got a set of screens to mock up in lightning speed and this looks like it will do the trick!

Anybody out there got experience with it?

 Thanks, Carla! You’re awesome!

Okay, this is way off the topic of usability, but I am so angry about this I just have to blog about it. Wells Fargo is my bank and for the most part, I love them. Their online banking system is very usable (which I love, except I wish they’d give me a more direct way to get to my billpay) and overall I’m really happy with them. Their staff is really friendly when I walk into the bank and they really go the extra mile to get me the information I need, even if it’s the details on a deposit that happened over a year ago.

But their auto finance department needs to take bank account security 101. If I’m even a few days late on my car payment, they have a rude person call me and harrass me to do my payment over the phone. I don’t really doubt that it’s Wells Fargo calling me, but I have no way of actually confirming that, so I always tell them I don’t want to do my payment over the phone and I will take care of it online. They get really angry about that. Today the lady on the phone actually called me “weird”. Would she give her account information to anyone who happened to call and say they were from Wells Fargo?

Banks have been trying to educate consumers to NOT give your account information out to callers. You should never, never, never give out your bank account number to someone who calls you, no matter who they say they are. Only if you initiated the call is it okay to do that. It just blows me away that Wells Fargo, one of the largest banks out there, would knowingly ask consumers to do this, perpetuating the problems with account fraud we have. And the fact that this woman thought I was “weird” because I wouldn’t give her my personal information and bank account number means that the message is not getting across to consumers, either. People are willingly giving them their account information over the phone when they have no way of confirming that it actually IS Wells Fargo calling.

 I tried to walk into a Wells Fargo bank to complain about it, but they told me they don’t have anything to do with auto financing and I would have to call their auto finance department. There is a problem there, but I don’t blame the innocent bank staff. I blame the idiot managers in the account finance department who are:

1. Hiring rude people to harrass people about their car payments. If my account was months overdue, yeah, it’s okay to call, but not after a couple days. If you’re going to call me when my payment is a couple days late, you should be really, really nice about it.
2. Asking people to give out personal information over the phone with no verification that they are who they say they are. By doing this, they are teaching consumers habits that only increases banking risk and makes it easier for fraudsters to hijack people’s bank accounts and steal identities.

It’s maddening and it’s got to stop!

Back to the subject of Americans and our overabundance of Stuff, I ran across an article about Chris Jordan’s photography on EcoGeek.com. I think I’d seen some of his photography before, but Chris takes statistics about our consumer-istic lifestyle and turns them into giant, visual works of art that convey the scale of our overabundant consumeristic nature. It’s another well-done, impactful view of the Story of Stuff.

As Shea on Ecogeek says:

 Chris thinks that the green movement is happening, but is stalling out. He used the analogy of the finish of a bike race - everyone is waiting for the other person to make the first move toward the finish line. He also believes that the green movement is hampered by the lack of cool. Michael Jordan changed the face of basketball fashion overnight when he showed up to the game wearing baggy shorts. Although people like Al Gore and Paul Hawkin are necessary to the environmental movement, they lack the cool factor of a green Michael Jordan.

I’ve experienced this first-hand when I go to the store and use my reusable shopping bags. Everyone looks at me like I’m a little crazy. A few comment on how cool my bags are, but for them it’s all in the design of the bag, not the concept of reducing our consumerism and saving the environment. When I use my flourescent “Live Green” bags with the cool design, everyone thinks I’m cool. When I pull out the bunched up, plain-jane eco-sack from my purse, they look at me like I’ve grown a third head or something (but it’s so much more convenient for a forgetful, busy mom!)

I guess I’ll try to use the “cool” bags more often, to get the message across to other shoppers to consider reducing their use. I wish we weren’t so shallow, though.