Click to add text © 2013 IBM Corporation EclipseCon 2013… Are you user friendly? April de Vries,...

© 2013 IBM Corporation

EclipseCon 2013… Are you user friendly?

April de Vries, Are you user friendly?IBM Software, Rational27 March 2013

© 2013 IBM Corporation2 IBM Confidential

Enabling Product and Service Innovation | Rational

DISCLAIMER

IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision.

The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

© Copyright IBM Corporation 2013. All rights reserved.



Agenda

A little about me, a little about you

Usability research: evaluations vs tests

Before you start

During your session

When you’re done

Demo

Closing thoughts



A little about me, a little about you

About me

– I’m a User Experience Engineer at IBM.

– My goal for this presentation is to ‘demystify’ usability testing and enable you to immediately conduct your own usability research.

– This session does not cover design principles.

About you

– Who has familiarity with usability/user experience/user centered design?

– Who works with usability people?

– Who has, or is currently conducting usability research as part of your work?

– Any goals for this presentation?



Usability research – evaluations vs tests

Usability evaluations (not the focus of this presentation)

– Do not involve a participant working directly with a UI.

– Research includes surveys, interviews, expert evaluations, walkthroughs, diagramming.

– Results are predictions; attitude doesn’t always drive behaviors.

– Strong recommendation to embark on usability evaluations with assistance from a user research expert! Like Corrie!

If you decide to give evaluations a try…

– Survey design is very important, and harder than it looks.

– Use clear language. Be as unambiguous as humanly possible.

– Keep questions grounded in experience, not speculation.

– In an interview, avoid yes/no questions. Bad: Would you like it if… Better: Would this feature be valuable in your current work? Why? Best: Which aspects of this would be valuable? How would you use this aspect/feature? Why? (Keep asking why!)



Usability research – evaluations vs tests

Usability tests

– (Has anyone here participated in a usability test, in any capacity?)

– Focus on a participant interacting with a UI.

– Based in observation.

– Allow for demonstrated issues with a UI, not just what we think will be issues with the UI.

The rest of this presentation is a crash course on usability testing. Ready?



Usability tests: before you start

Know your audience

– Who uses your product? Who do you want to use your product?

– Consider a screener (a short questionnaire to ensure your participants are in your audience.)

CYA

– Check with your manager, legal team, etc to make sure you can solicit feedback from customers and potential users of your product. Also, check about compensation.

– In your session, don’t make any promises about future features, unless perhaps you own your company and can actually guarantee these things.

Find participants

– Remember, fitting participants might be in the next cube.

– Leverage sales, support, user groups and communities.

– Consider remote usability tests.

– Consider a proxy (more later.)



Usability tests: before you start

Determine what to test

– Can you map usability test efforts to high value product goals? Can you address business goals with your test tasks?

– Consider the maturity of your product. Would you test incremental UI changes? Entire workflow designs?

– Consider the state and needs of the product, as well as constraints (time, resources.)

– What is getting worked on this release?

You don’t need to have fully functioning code for a usability test

– Feel free to show the bare bones to potential users to get ‘ground level’ validation, or areas for improvement. You can even test paper sketches- consider sketching the basic workflows.

High impact, low effort, valuable, actionable



Usability tests: during the session

Start by introducing yourself and the purpose of the meeting

– Give the participant a brief idea of what to expect. Thank them for their time.

You don’t have to have a huge end to end script, but give a little context

– It’s okay to put something in front of someone and say, ‘Pretend you’ve done this. Now try doing <this>.’ We’ll demo this later.

For basic interactions, try a proxy for your exact audience role

– For instance, if you are building a new product, you can easily get feedback on the basics- like navigation, or user gestures- from your girlfriend, your boyfriend, your neighbor. Yes, I have done this and have gotten fantastic feedback.

Use the think-aloud protocol

– This is best conveyed with a demonstration. Watch me think aloud!

– Prompt participants if they get quiet. ‘What are you thinking?’ ‘Are you looking for something right now?’ etc.



Usability tests: during the session

Be a little positive, yet noncommittal

– Participants tend to get self disparaging. Don’t agree with them! Pick a one-liner and repeat it. ‘There is no such thing as user error.’ or ‘This is all great feedback.’

Remain unbiased, cool and collected

– Remember, the participant doesn’t have your experience and expertise behind the scenes. Neither do your paying customers. You are not testing the user!

Don’t jump in

– If your participant gets stuck on a task, don’t immediately jump in. Let them continue for a reasonable amount of time, say 2 minutes (it will seem long!). If they don’t succeed, move on nonchalantly. Perhaps leave time at the end of the session to answer questions.

Get to the root of the issue

– Keep asking questions. What were you expecting to see? Were you expecting something in particular there? Why? (You can learn a lot about prior experience and knowledge this way too.) A usability person’s favorite question: what were you expecting?



Usability tests: after the session

So now what? Priorities

– Consider your findings on a scale of severity vs. frequency, and rank them accordingly.

– Severe issues include those which prevent successful task completion, or issues which require a workaround. Worst case: issues which result in data loss and issues which prevent task completion.

– Small, frequent issues may seem innocuous, but consider them holistically. For instance: an annoying issue that is not a big deal, but occurring many times over the course of a task, or workday. To the user, this issue may seem nearly as significant as a severe issue (the power of SSO!).

Communicate your findings

– Remember those stakeholders you identified before you started?

Circle back to the participants

– It is very important to make participants feel their time with you was not wasted. At the least, send them a thank you note. Better, include an anecdote about their session so they can be sure they’ve made an impact.



Demo

Any volunteers from the audience (who did not create a personalized schedule)?



Closing thoughts

Consider your research goals and do your best to make sure the participant represents your target audience.

You don’t need to have perfect implementation to run some usability research. In fact, the earlier, the better.

Use the think-aloud protocol. This may take some getting used to, particularly in a remote session.

Don’t fix problems or give solutions during the session.

Keep asking why.

Prioritize your findings and think of them holistically.

As with anything, facilitating a usability test gets easier with practice.



© Copyright IBM Corporation 2013. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

www.ibm.com/software/rational

Click to add text © 2013 IBM Corporation EclipseCon 2013… Are you user friendly? April de Vries,...

Documents

Transcript of Click to add text © 2013 IBM Corporation EclipseCon 2013… Are you user friendly? April de Vries,...