Friday, December 26, 2014

Usability project - week 3 (scenarios)

I encourage everyone to follow our progress in the GNOME Usability Project. I'm planning to post each "assignment" on my blog every week. I figure this will help others who might want to apply to the Outreach Program for Women in future years, so they can "follow along" with what we are doing. Or, if you have more experience in usability testing, feel free to leave a comment on our work.

In planning your usability test, after you understand and agree to the personas that represent your users, your next step is to document the scenarios under which these personas will use the program. This is key to performing a good usability test. The success of your usability test depends on how well you understand how the program will be used (and in turn, how well you understand this depends on the completeness of your personas).

This week, let's examine scenarios. Use these questions to guide you:
  • What is a scenario?
  • Can you identify scenarios for GNOME, for each of the personas you imagined last week? Do they overlap? In what ways are they similar or different?
  • What is the difference between a scenario and a scenario task?

These websites may provide more information as you consider this week's topic:

Scenarios inform the next part of our usability project: scenario tasks. Once you define the scenarios for your users, you can generate the scenario tasks. Consider these questions:
  • How do your scenarios break down into separate tasks?
  • What parts of GNOME will be exercised by your scenario tasks?

Of course, you may not be able to test all of your scenario tasks in a single usability test. Your testers may become weary of a usability test longer than about an hour. So as your final step for this week, consider what scenario tasks will help you most in your usability test. What features do you want to examine in GNOME? Reflect on how your scenario tasks expose features of GNOME, and compare that to the features you want to examine.
image: Outreach Program for Women

Wednesday, December 17, 2014

Usability project - week 2 (personas)

I encourage everyone to follow our progress in the GNOME Usability Project. I'm planning to post each "assignment" on my blog every week. I figure this will help others who might want to apply to the Outreach Program for Women in future years, so they can "follow along" with what we are doing. Or, if you have more experience in usability testing, feel free to leave a comment on our work.

In studying usability, we first need to understand who are the users. How you design the program may differ based on who uses it. Are your users mostly developers? Or are they mostly image experts? Or are they "general" users with "average" knowledge?

Good designers start with personas to define their users. By using personas that everyone agrees to, the designers and developers (and everyone else on the project) can discuss how changes to the product will affect each representative user. This avoids ambiguous discussion like "But what about the user who wants to do —?" or "But this works for me." With personas, the conversation becomes "How does this change benefit ‘Amanda’?" or "What can we do to make things easier for ‘Steve’?"

This week, let's research and discuss personas. Consider these aspects:
What is a persona?
Can you find (Google?) more information about personas and how they help in usability testing? At what point in a project would you create personas?

Can you identify personas for usability testing in GNOME?
What users does GNOME aim for? This is a different audience than the users for GNU Emacs, for example. What persona types would you propose for GNOME? Pick one, and create (write) a persona for that example.

I considered personas for my usability study, but decided not to include them in my capstone project. Why didn't I use personas? Can you find a reference or note in my capstone? (Hint: it's in an appendix.)
I think you'll find these topics are inter-related.

Some websites that might help you in discussing personas:
image: Outreach Program for Women

Wednesday, December 10, 2014

Usability project - week 1

I am proud to be part of the Outreach Program for Women ("OPW"). In this cycle of the program, I will be mentoring the GNOME Usability Project. I'll be working with Sanskriti Dawle, who will be sharing her experience via her blog.

I encourage everyone to follow our progress. I'm planning to post each "assignment" on my blog every week. I figure this will help others who might want to apply to OPW in future years, so they can "follow along" with what we are doing. Or, if you have more experience in usability testing, feel free to leave a comment on our work.

As we get started with week 1, discuss your initial thoughts on usability. Some questions that should help guide you:
  • What does "usability" mean to you?
  • Can you find (Google?) a definition of "usability"?
  • Some researchers in this area make a distinction between "big U" Usability and "small u" usability - why is that, and how are they different?
  • What are we trying to get out of "usability"?

These are great questions to start off our usability project. I find it's a good idea to create this "baseline" for first impressions about the topic, and you can expand on that as you go.

A few references that you might consider in discussing this topic:

You might also review "What is usability?" from my capstone "Usability Themes in Open Source Software" (Hall, 2014).

You are welcome to follow our usability project!
image: Outreach Program for Women

Saturday, December 6, 2014

Usability A/B testing

If you work in usability, you should be aware of A/B testing: presenting two versions of a product to a test participant, and asking which they prefer.

A/B testing is a popular and easy way to improve a system through iterative testing. By its nature, A/B testing requires some iteration to get it right: Think about when you visit the eye doctor, and you look through the sets of lenses: "Which looks better, number 1 or number 2? Now, number 2 or number 3?" And so on.

This style of testing can be extended to websites and web applications, by releasing one version of a site to a subset of visitors, and another version of the same site to a different subset of visitors. For example, a website might expose certain users to a different navigation sidebar, and compare how well those users can navigate the website versus those users who see the old navigation sidebar. With enough web users, the web designers can quickly determine (through traffic analysis) which navigation sidebar is more effective.

A recent article in Fast Company demonstrates another company using A/B testing, in an interesting way: the Adore Me lingerie company. From the article:
For each bra, Adore Me shoots multiple versions of images to run on its website. The distinctions between the pictures might include different models wearing the same set in the exact same position, or the same model in the same set in a different position, for example. Then, like any good tech company, it tests the options to find out which one sells better.

Through its research, Adore Me has found that the right model matters even more than price. If customers see a lacy pushup on a model they like, they'll buy it. Put the same thing on a model they don't, and even a $10 price cut won't compel them. Pose matters as well: the same product shot on the same model in a different posture can nudge sales a few percentage points in either direction. Another test found that a popular model can sell a more expensive version of the same garment.

The tinkering—which seems incremental—adds up, and has helped the company maximize sales. In four years, Adore Me has matched the sales of competitors like La Perla, bringing in $5.6 million in revenue, according to Inc.

Aside from model, A/B testing also revealed the model's pose can influence sales, too: "Hand on hip, a popular pose among Instagrammers trying to make their arms look skinny, doesn't resonate nearly as well as a hand on the head, for example. (That slight change can double sales, according to internal research.)"

This style of usability testing requires coordination between several groups: most importantly, the website must be geared to support traffic analysis in a way to help determine the best sellers: "For every thousand people that come on the site, 500 will see picture A, another 500 will see picture B and over time, one will sell better than the other."

As you plan your next usability tests, consider how A/B testing might be applied to examine how users interact with your system. If you crunch the numbers, you can discover interesting and useful results that will improve the next iteration of your product.
image: Adore Me

Wednesday, December 3, 2014

Usability in business

While my blog focuses on usability in open source software, it's important to note that usability is important everywhere. Cloud systems such as Gmail, Evernote, and Dropbox could not exist without good usability. In these systems, it's unrealistic to expect users to be trained before they can use the software. These applications need to be easy to use "out of the box," without any training. At most, the software needs to be "learn as you go," in a way that allows users to uncover and discover functionality in a natural way. People just want to use the software to get their work done, quickly and easily.

In business, most corporate applications have not been managed that way. In corporate culture, the desktop is highly controlled, including which applications you can use to do your job. And the software isn't always friendly. Before you can use the financial system to run reports, most users would expect to attend a training seminar. It's just that hard to use.

But that is all changing. I was glad to see this article in CIO Magazine from design consultant Harold Hambrose, about a new dawn for system design. In brief, Hambrose asks. "Are you building business apps that employees love to use and can pick up without training? If not, you need a different kind of design team."

Hambrose highlights one important difference between corporate software and consumer applications: "Technology outside the enterprise is strikingly different because people want to use it." (emphasis mine)

To answer this challenge, Hambrose introduces the design researcher. From the article:
Their perspective is different from a business analyst who will ask, “How do you do your job? What data do you need?” Instead, they may inquire, “Why do you do your job this way? Tell me about the decisions that you make. Why are these important? What is success for you? For your organization?”

If you are interested in usability, you can leverage your experience towards the new design researcher role. Forward-thinking CIOs will be looking to make their enterprise software easier to use—and something their employees want to use.