I made it yesterday though it was late into the midnight, attending Kubuntu Tutorials Day at #kubuntu-devel. The session I was interested to catch up was the second one by Celeste Lyn Paul aka seele on Usability. I have heard about her, her work, KDE-HIG and openusability.org a few months ago after I attended the HCI workshop at IIT Bombay. The following are the brief notes from my scratch pad on what seele said during her session. Official logs from the Kubuntu Tutorials Day should be available soon (or am not yet aware of the link yet..) and will update when I get it.
( Questions from seele are in italics, with related links I managed to get by Googling and my own comments. A little bit of editing to make it look a bit “blog formal” and readable. Comments are welcome, especially if you find something wrong 🙂 )
In 20 words or less, what do you guys think usability is? (and no cheating on wikipedia)
If we take this from an ISO standard, usability means that a product must be,
1.learnable
2. efficient
3. memorable
4. prevent errors, and
5. be satisfactory to users
Learnable
This is the one no one usually picks when i ask the “what is usability” question. A product (in our case software) doesn’t have to be so easy that you don’t have to learn it. For a simple task, then you expect it to be simple but for a complex task, it is OK to expect learning.
Efficiency
This probably shouldn’t be #2 even though it is listed in the ISO spec this way, because it is related to learnability and memorability. But it is exactly what the word means, an appropriate use of time and resources in relation to the complexity of the system. Even if you made a simple printing function an easy to use 10 step wizard, it isn’t very efficient if you need to do that every time you print. Clicking one button will get the same amount of work done than stepping the user through all the options and clicking 10.
Memorability
This is what I think should be #2 because it is closely related to learnability.
Have you guys ever heard of the term Information Scent? It is an Information Science Theory
Information scent is a search behavior theory. Information scientists believe we search using the “gathering” skills of our “hunter-gatherer” basic instincts. What it turns in to from a UI perspective is how easy it is to find information (functionality or options) from it’s surface presentation. So, what options you expect to be under menu X before you open menu X? By having good information scent (good labels, structure, etc.), you can use the UI more efficiently because you can stack layers of information.
Basically you are leaving hints to the user to find the information on their own, they don’t need to Remember where options are, but only follow a logical path. This saves the user’s cognitive resources to go on and solve more complex problems instead of using them on the UI. Remember that a UI is a tool to solve a problem, the UI shouldn’t be the problem.
Error Prevention
Have any of you guys heard of Jef Raskin?
He was a famous designer who worked at apple (i think he was employee #12 or something close). He was a true user advocate in the sense that he believed no matter what the circumstance, the computer should do no harm. Also, many of you are probably familiar with the practice of confirming actions, particularly destructive ones, yes? Error prevention is more than just confirming a destructive action. It is preventing the user from having to make that decision to start with.
We dont see this too much in the desktop environment because we model a lot of our work-flows off of existing software, but i see this a lot in other expert systems. “Are you really sure you want to do that? It will cripple the system and you will lose all of your data” (Well then, the user should have never been able to choose that option from the top level of a UI). Even so, there are a lot of confirmations we do in the desktop environment which could be prevented if we shaped the work-flow differently; the user should never have to select Cancel.
Satisfaction (keeping it consistent 😉
Satisfaction is the quality many people tend to identify with usability. But it is also the last dimension in the spec (and i believe the least important of all we’ve talk about). Satisfaction is important. If a user finds a system pretty or cool, they will want to use it more than the other system that is not. Users will sacrifice ALL of the other parts of usability (learnability, efficiency, memorability, error prevention) for satisfaction. our goal is to help them not make sacrifices.
I’ve seen users in usability tests take 3, 4, 10 times longer to complete a task in a terrible UI that looked pretty, and complete the same task in a different not-as-pretty UI much much faster and they still like the pretty UI.This is an advantage and disadvantage: it gives us room to experiment because users will be forgiving if we give them options they want or other cool toys; but at the same time, we should use eye candy as a crutch to solve problems. We should solve problems and make our solutions beautiful.
Have you guys ever heard of a one-time learning event?
Often when you are reviewing a new UI or work-flow, one of the questions you may ask yourself is “will the user figure this out”; and the first time around, sometime the user doesn’t. they can’t find the options, they don’t know the label, they can’t figure it out. But,if they have someone show them how to do it, they find the solution on a webpage, or painfully figure it out, it makes sense to them and they remember it for next time. We call this type of experience a one time learning event
They won’t figure it out the first time, but if they can do it once, they will remember how to do it. This is something that is often forgotten in UI design. You can break users out in to different dimensions – one of them being problem solving skills and related motivation, some users are not afraid to try something and fail, other users will not try new things in fear of failing and the users who do not explore are at risk of never exploring options hidden behind a single-learning event.
That’s why doing user research on your product and understanding who your users are, their motivations, environment, and their skill (it’s not JUST about their skills) is important. This leads me in to a discussion about universal usability.
Has anyone heard this term “Universal Usability” before?
Universal Usability is the belief that any user, no matter their skill, background, motivation, experience, etc. should be able to pick up and use a product. In cases where products must serve the general public (such as e-voting machines), this could be a valid argument, but there are very few products that focus on EVERYONE. Even so, the concept of universal usability would be extremely difficult to achieve, especially in expert systems or systems which knowledge workers use
The ipod, why does everyone use that as an example of universal usability? The ipod is an excellent example of very sexy tech that people forgive its shortcomings for. It doesn’t do everything everyone wants, and not everyone can use it or figure it out, but because it is so damn beautiful, most people don’t care.
Universal usability forces designers to lower the bar of the average user to accommodate more people. This is why it hurts expert systems. If there is a pocket of experience or information that a certain group of users may not have or be able to attain, it must be removed.
[ To a question about apple and the point mentioned above…]
Yes, but apple traditionally does not follow a user-centered design approach. they believe that designers know better. It’s only been recently that they’ve done usability testing.. everything before was market research (which is very different).
[ We seemed to digress a bit, so I tried bringing it back on track with question :P]
There are three domains of usability i work in: User Research, Design, and User Testing. Together, these are part of the user-centered design process (UCD). It is a design philosophy which keeps users in mind while creating a system for them.
User Research is often linked to the Requirements stage of software development. So when you developers are thinking of new features to integrate in to a software, or a new software to develop from scratch. Here are some things you should be thinking of in addition to your functionality spec and other things,
Who are your users?
Try to come up with some example users who you are building the software for. Even if you are a user, try to keep yourself out of the list, it makes it too easy to do what you want instead of what they need.
What will you users be doing too many times?
Not all of the functionality is documented or fully planned. A single function might be discussed and mapped, but the other functions of a system aren’t thought of until afterwards. What happens is you don’t have a complete picture of how your users are using the system, and if the functions are integrated properly mapping out screen flows before you begin coding will help document your functionality (so you aren’t trying to squeeze or force options in later) and give you a reference for when you code.
What problem are you trying to solve?
This is the big one, your Vision Statement. Having an idea of your goals before you start will help development. It is related to the “What are my users doing?” question. If you don’t know what problem you are trying to solve with your software, you can’t know what to provide users or what they will expect? Plus, in larger projects, it is a good idea that all the developers are on the same page. It prevents a lot of road map issues later on
Being able to answer those three questions will give you a head start. On KDE Techbase there are user research templates to help guide you.
I guess we will get in to Open Source Usability 101 now,
First step: Contact the project you want to work with and express interest in working with them.
You dont want to surprise developers by dropping a usability report in their inbox. It will just make them angry, even if the work was good.
Second step: Start small. Open source is a community based on commitment and trust (after the getting work done thing).
Start with a small activity such as interviewing users, conducting a survey, or doing a small UI review. This will help developers get used to your methods, get used to you, and know what to expect from your work.
Third step: Maintain your relationship with the project.
Design is an iterative process, just as open source is iterative development. Developers are wary of seagull designers: designers who fly in, poop on their software, then fly away. Developers are in for the long hull, they are committed to their project and want to see it succeed. They don’t want to work with a designer who will ask them to change a bunch of things, then disappear and not be able to comment on the results.
Obviously I don’t want to see any unhealthy marriages, but keep in mind that you will make a bigger difference in one project than doing a bunch of little activities for a bunch of projects. Design is a VERY iterative process; it is important for both you the designer and the developer you work with to understand this.
[ To my question whether we have something similar like KDE-HIG in Ubuntu/Kubuntu to which we can contribute.. ]
For Ubuntu designers, you will want to look at the GNOME HIG. It might be a little out of date, but one way to get started with contributing would be updating it!
For Kubuntu designers, you will want to look at the KDE4 HIG and the KDE3 User Interface Guidelines.
These are under active development, and so if you have any questions it would be best to ask me or Ellen Reitmayr who sometimes lurks in #openusability.
Other Resources:
Look at other interfaces that do similar things, not just in your own environment but in windows, KDE/GNOME, Mac OSX. You’ll find similar and very different solutions. You will want to look closely at the context of the solutions and make sure it is a good fit before you use it as a mode. Copying a solution will not solve a problem, the goal of reviewing other software is to get inspiration when you have no other better ideas.
[ The End – Applauds!! ]
coding tiger 