I’m liveblogging the Pune OpenCoffee Club meeting on usability. About 30 people in the room now. These are quick-n-dirty notes, not really well structured. Hopefully in a couple of days, more coherent reports will emerge from me or other bloggers. For background on some of the speakers, see the meeting announcement page on punetech.
Jhumkee: This field started around World War-II. Aircraft accidents. Instead of saying that pilots are idiots, the engineers decided to change the design so that mistakes don’t happen. Instead of engineers designing a system by themselves, involve the users in the process. Don’t just think about what they want. Instead, ask them. Or watch them using the product.
Military, aerospace, and other fields really embraced this field. In India, this is a fairly new field. Especially in IT.
But it is common sense.
Shashank: In the era of electronics and IT, it is very easy to put in new features. This is a problem. In general, in most product companies, engineers first create a product, and then go around looking for users who are interested in that product.
But adding features, normally results in reducing usability. So, especially for small startups, there is a choice to make – add features or add usability?
Harrshada: How did you start your startup? Did you find a need and try to fill it, or did you have a cool technology/algorithm that you wanted to implement? Usability says that you should always have a target audience in mind, and work towards solving their problems. Your technology is not the important part. Constantly be in touch with users and keep observing them.
It’s rather trivial to say that we should keep users in mind when designing the product. But, how to actually go about this?
Jhumkee: You must get a real user, and then there are a number of techniques that are used to get information out of the user. First of all: You are not a user. Many designers of systems are under the impression that they are a user. Because, they are actually using their own product. In fact, Steve Yegge argues passionately that you should only build products that you yourself want. But, the problem is that as you are designing the system you become an expert. You know everything about the system. You are not a regular user. Hence, you must spend time with real users.
Shashank: There is a science behind this. There are a bunch of techniques for doing this. Some of them are obvious, and some hidden means by which you can get usability information out of users. You need to think through this process. But it doesn’t have to be anything very fancy. Interview your users. Ask open ended questions about what they were trying to achieve, what they felt, what made them happy, and what frustrated them. Use this to determine some broad areas of concern, and then start digging deeper.
Jhumkee: There is no silver-bullet here. Some of this comes from experience. A lot of this differs based on the But there are some broad guidelines. It must be an iterative process. Make changes. Test with real users. Repeat.
There are a lot of guidelines on individual things (e.g. font sizes, navigation architecture, accessibility factors) etc. But you can’t simply apply them without a deeper understanding. Because usability is a holistic thing. Even if the parts are all OK, the whole system might still not be very usable.
But, the guidelines are a good starting point. There are some good basic guidelines at Yale. And also at usability.gov.
RouteGuru: Usability is a huge issue for us. How to present information about an entire route in SMS form, and how to do this in a way that the route gets built up in their head. Another big hassle is the 80-20 problem. The last mile is significantly more complicated than the rest of the directions. Also, some users are only interested in the last mile, as they know how to get to the general vicinity. Others want all the directions. We are still grappling with this issue.
Somebody I don’t know: For usability, keep only one action per page. One page should be for one purpose only (except for the home page). If there is a form, there should be only one button. Use a tool from google that is used to serve two layouts of the same page to different users and then study their behavior. Use this information to decide what works and what doesn’t.
Shashank: This last technique is a very quantitative mechanism. Analytics, heat-maps, etc. give you a lot of data. You don’t always know how to use this data. The world is moving towards qualitative analysis.
Manas: Users don’t always know what they want. So how do you handle this?
Jhumkee: What you do is task-based analysis. Find out what the users want to do, and then figure out how long it takes them to do it, and whether they get frustrated doing it, and whether they are successful or not. This will give you good insights. So the real work is in figuring out what these tasks should be.
Unfortunately, I had to leave the meeting at this stage to get back to my kids. Hopefully I’ll be able to fill in the gaps with notes taken by someone else.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_b.png?x-id=436df85e-2ec9-4679-a46f-1510e297b7fc)
