5 Ways To Get More “Usability” In Your Project
Yes, everyone wants this usability thing! (Well, almost everyone). “Usability” is the buzz word everyone recognizes to mean a quality of an easy to use or learn interface usually through the practice of user-centered interface and interaction design. I try when I can to substitute design for “usability”, because that is really what it is — good design.
Here are 5 suggestions on how developers can get more usability (i.e. better design) in to their project without having to rely on one of the very few designers involved in open source. They are ordered in what I think is from easiest to hardest to achieve.
1. Read a good book (or blog). There are tons of design and usability related books out there, but only some of them are any good, and even fewer are good and suitable for someone who doesn’t design for a living. Designing Interfaces by Jenifer Tidwell is a good primer on interface and interaction design patterns. Try taking some of the principles you learn from the book and think about how you can make changes to one of your UIs. Blogs are a good place to discuss changes you are thinking about, and provides a resource for other developers.
2. Peer review interfaces. Have a new UI design or an idea for an improvement? Show a sketch or mockup to a friend or three to get their input. To get more out of this exercise, start a small group of developers who are interested in learning more about good design and review each other’s UI work. For every comment for or against a specific interface element, try to come up with a justification beyond a checklist or guideline. It is not quite as good as having someone with more design experience reviewing it, but one more pair of eyes is better than none at all.
3. Use a heuristics-based or guidelines-based checklist. Checklists offer a list of high-level considerations to make when creating a user interface. The classic 10 Usability Heuristics is a good place to start, and topical guidelines-based checklists are also available for KDE (wiki.openusability.org seems to be down at the moment). The problem with checklists is that they are often too general to catch anything serious, but they will help you catch the “easy” mistakes and think more critically about your UI. You might even want to create your own customized checklist for the type of software you usually develop, based from a larger and more general list.
4. Make friends with a designer. I don’t speak for all designers out there, but I can tell you that I am more likely to provide feedback or do design for a project or developer I have a working relationship with than someone I don’t. If you don’t know any designers, try soliciting the kde-usability mailing list for someone who may be interested in your project or UI. Offer to implement some UI changes or fix a bug they submitted in exchange for some expert advice. If you have a designer friend who isn’t yet involved in open source, try sending them screenshots and asking them questions. Maybe you will get them interested enough to get more involved in your project.
5. Observe a few user-based testing sessions. Nothing is more humbling than watching user-based testing on an interface you designed (or coded) for the first time. (I can’t tell you how many developers have tried to yell “Click the button!” through the mirror). After you get over the initial shock, watching users stumble over poorly designed parts of an interface helps drive home a lot of the UI guidelines and best practices you have been studying. There are not many user-based testing studies conducted for open source software, so finding one to sit in on may be a bit difficult.
seele :: Nov.06.2007 :: General, Open Source, Usability :: 3 Comments »
Since you are so experienced in design and usability, you should really redesign your blog: fonts are way too small, the page width is fixed in pixels which not good at high resolutions, there is a useless single tab named “Blog”.
Another point could be to question why the things are what they are, especially for the rarely used features.
For example, what can we say about the “whatsthis” features in KDE windows? The newer version shows what elements have a “whatsthis” tip or not on mouse over which is quite an improvement (for developers it is pretty tedious to tag everything with help strings), yet browsing the tips is still impossible for it requires a click each time. The system is supposed to help understanding how it works, yet it does not guide the user into the common steps either (numbering?)
A long time problem was found in ktip recently (showing the hints on application startup was broken).
The easiest method is to prepare a tool for the use of your IT-illiterate grandpa and show it to him. You will run into the typical show effect troubles. All these troubles are killers for your grandpa working on it on his own.