UsabiliTeam

Differences between revisions 6 and 7
Revision 6 as of 2009-11-08 17:16:24
Size: 5299
Editor: 73
Comment:
Revision 7 as of 2009-11-08 17:18:42
Size: 5298
Editor: 73
Comment:
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
See: [[Usability]] and [[http://brainstorm.ubuntu.com/idea/3001/ Brainstorm]] See: [[Usability]] and [[http://brainstorm.ubuntu.com/idea/3001|Brainstorm]]

UsabiliTeam or Usability Team is formed by all the people willing to detect and discuss usability issues on Ubuntu.

Our targets are to detect, report and sometimes repare this issues.

See: Usability and Brainstorm

Testing with human beings

Our mission

1. Measure the service capacity of the current version of Ubuntu (mainly, which activities are achievable by normal users). {It has to be done activity by activity.}

Note that normally users have no computer knowledge. They know how to use an interface if it have sense, but most have no clue of what happens in the system.

2. Identify some of its issues and its importance. {It has to be done activity by activity.}

How can we make this (activity by activity)

A manner of qualifying the Ubuntu usability for each activity can be done by representing in a table which elements Ubuntu have got yet in green and the issues in red, for example:

  • The activity named foo_good is achievable by all users, including those using a computer for the first time.

  • The activity named foo_bad is achievable by many users. To make it achievable for users with less computer knowledge would be essential requirements E and F. And evaluate this requirements with two factors: Users who will achieve this activity with this requirement revolved (named USERS) and Units of work to be done (WORK). The importance of the issue or requirement is USERS/WORK.

Activity name

Requirements to advanced users

to normal users

to novice users

foo_good

-

-

A and B

foo_bad

C

D

E and F

Requirement E

  • Importance: Users: 40% - Work: 20 units of work (hour per people): 40/20 = 2
    Explanation: Improvement of the button foo.

Goals

The design is great when the users say it is.

  • Our goal fo the test is to take normal people and try to prove if the current *Ubuntu distribution is useful for their diary/weekly/monthly activities.
    Prove this formats or protocols that the users use assiduously. Ask what they are, maybe:

  • office: M$ office
  • web: what webpages
  • im: msn
  • music: mp3
  • video: divx, quicktime...
  • ...

The results may indicate why Ubuntu is not popular for every people.

Who to test

One user is infinitely more than zero.
Why You Only Need to Test with 5 Users

We have to test representative users that (brainstorm):

  1. Any age
  2. Have little or less computer knowledge
  3. Ofter use the computer
  4. Don't really use Ubuntu (Ubuntu first impressions of people) We have to take this information and add it to our test results: age, computer knowledge, use of the computer and first impressions.

How to test

First of all we have to know for every user what this user does regularly. This table may help:

Use of an activity

more than once a day

+ once a week

+ once a month

+ once a year

never

Docs, spreadsheets and slides

X

Web surfing

X

Instant messaging

X

Photo editing

X

...

After studying that we can start taking notes of the impressions and make him/her to test some of the most used activities: for example, create a text document and include an image. Things that this user do regularly. This table may help:

Activity

Where fails?

Why?

Succeeds?

Create a text document and include an image

...

When a user fails, we have to try to make him succeed with the less help but making the user finish the test.

After doing that we can extract some conclusions

Conclusions and test results

  • After extracting and taking notes of this conclusions in a children of this wiki page we can make with them some things:
  • Report a bug or blueprint in launchpad

  • Report a brainstorm


After that:

  1. After reporting it, make mock-ups or develop a patch to repair the issue and send it upstream.
  2. Put the link to the report in your conclusions page.

Important note: Search if the bug, blueprint or brainstorm exists before reporting it. If it exists, adds a comment to it with your conclusions.

Extracted conclusions

UsabiliTeam (last edited 2009-11-09 09:21:42 by 81)