Usability Research and Real Software
While researching for a course project this semester I've taken off my usual programming hat and been wearing my HCI/design/usability cap. The two are complete opposites and the modern programmer is required to wear both.
This is a collection of papers, notes, and thoughts from my construction of a related works section for my paper. If you've wanted some exposure to usability research then you'll find this interesting.
This is absolutely not an exhaustive list, and I am by no means an expert.
Jakob Nielsen
Jakob Nielsen is one of the best known academic authors for software usability. He (along with Rolf Molich) created a set of 10 Usability Heuristics for evaluating software. A large portion of software usability evaluations use these heuristics, and they provide a rather good generic framework for analysis.
These two papers are very related, and they demonstrate how his heuristic evaluation can be used in practice. If you keep a watchful eye, you'll see his name appear in many citation lists.
Designing for usability: key principles and what designers think
Note: I consider this to be a must-read (at least the first half). Stick with it and try to keep it in mind next time you are writing something that will be used by someone else.
This is one of my favorites in the list, mostly because it keeps things simple and is squarely aimed at helping real world development teams. It is also one of the older papers, published in 1985.
The paper outlines three general principles and tries to answer why developers don't follow them. They are early focus on users and tasks, empirical measurement, and iterative design. Essentially, designers should be prototyping with users and iterating on feedback before and during the software's creation.
In contrast to Nielsen's heuristics, these three principles are applied to the development process, not the final product. This is extremely different from the rest of the papers I read, which try to explain what makes something usable. The authors of this paper argue that usability is in the eye of the beholder, and you must organically grow your interfaces based on the user's impressions.
The Usability Methods Toolbox
This book is a collection of evaluation methods to test usability. It is a great reference, and even just skimming through it can help point you in the right direction.
It outlines different ways of collecting data and feedback from users, how to evaluate an interface, and frameworks for testing application usability. Although it is a book it is still fairly short, and is deserving of a weekend read if you are starting a project.
A Usability Evaluation of Let’s Encrypt and Certbot
Certbot is a tool that helps automate the process of setting up a free HTTPS certificate from Let's Encrypt. It tries to empirically judge whether or not Certbot is effective, and if a similar approach can be used to automate security configuration in other domains.
This paper is where it "clicked" for me when I was constructing a research idea. Their motivations on making high-level security more accessible resonated with me as I have very similar opinions about desktop security.
CMU's Usable Privacy and Security course readings
By far the best reading list I found on the subject. If you want more you should poke around through their links. All kinds of subjects, both security and non-security, are represented.
The list begins with some of the more generic usability focused papers and gets progressively more focused on security/privacy. Security is one of the most important usability fields, as an incorrect or uninformed action can have very severe consequences.
My thoughts
There are only two things I find overwhelmingly true regarding usability:
- The usefulness of an application and its attractiveness is solely determined by the user's opinion.
- Users are hopelessly uninformed about technical details.
This means that it is your job as the author of a tool to provide your users with comprehensible primitives that they can use to accomplish their goal. This is dependent on you actually understanding what their goal is in the first place.
If someone knows all of the technical details of an application, and can perform its actions themselves, they do not qualify as a user. If you design an application, such that it requires this level of knowledge to use, then the only person who can operate it is you. Anyone who knows just as much as you (or more) will simply rewrite your code out of spite so that real humans can use it.
Real humans do not have the time (and usually the ability) to learn technical details. They are using your tool for the explicit reason that they do not know how to perform the task.
Rule 1 explains why you hate that app on your phone that makes you click
through 12 menus before you can change a setting. They didn't sit
down with their users during development and learn what frustrates
them. Rule 2 explains why so much free software is painful to
use. The author wrongly assumed that all users are able to modify 45
config files scattered in /etc/, /usr/local/etc,
/usr/local/share, ... just like they enjoy doing.
Additionally, anyone involved in a project needs to be thinking about this. Authors need to design their applications this way, build tool creators need to make their tools easy to learn, package maintainers need the installation/upgrade procedure to go smoothly. Usability is a concept so broad that it applies to all of us and most of us still can't get it right.
Maybe you like designing interfaces and maybe you like writing code, at the end of the day masters of both will create the best software.