Sponsored Link •
I believe that it is important when designing any machine, including objects, to think about the user. Your job as designer is to provide value for users—to give the user a machine that is effective, reliable, efficient, and easy to use.
Perhaps the most important goal for your machine is that it should effectively solve the user's actual problem at hand. If I need to pound a nail into wood, and you hand me a screw driver, I'm liable to either put my eye out trying to pound the nail with the handle of the screwdriver, or just not use your tool. If a user is getting their problem solved, they will put up with a lot of unreliability and poor usability. If you don't solve their problem, they won't use your machine. The first challenge of design, therefore, is in figuring out what the user really needs and providing that.
Reliability is also important. If stamp machine users insert coins and push the button next to an Elvis Presley stamp, they want an Elvis Presley stamp to come out. If sometimes when a user pushes the Elvis Presley button, a Tiny Tim stamp comes out instead, users will be frustrated. Users also care about performance. If pushing the button next to a Elvis Presley stamp does indeed always make an Elvis Presley stamp come out, but it takes 30 minutes for each Elvis Presley stamp to make its way out, users will be frustrated.
But in addition to providing the user with a machine that is effective, reliabile, and efficient, your users want you to provide a machine that is easy to learn and a joy to use. Users want to intuit semantics from shape. Users want supplemental documentation from which they can quickly get answers to their questions. Users want machines to be unsurprising, to fit with their previous experience with similar machines. Users want common tasks to be easy and obvious, rare tasks to be possible. Users want doing the right thing to be effortless, making mistakes to be difficult. Users want machines to be usable.
For many years now I have been observing the API design processes in which I've participated in an effort to gain insights into the ways in which people come up with good designs. And although the teams I've designed with have certainly spent time and energy worrying about effectiveness, reliability and efficiency, I have found that ultimately most design conversations are about usability. We ask, "Which types best communicate the concepts of this API? Which methods pay for their complexity by providing sufficiently valuable functionality or convenience for the user? Are tasks we expect users to commonly perform with our API easy to do via our interface? Are mistakes difficult to make? Can the public interface be made simpler, even if that makes the implementation more complex?" These are all usability questions.
I have found it useful to think of objects as machines, the classes and interfaces of APIs as blueprints for those machines, and client programmers as users. Good API designs happen when designers have a user-oriented focus and a philosophy that values both the functionality and the usability of the resulting API.
This article is taken from a design book that I've been working on—and not working on—for almost five years. The book has had at least six titles, including Better Java, Flexible Java, the Precise Object, Object Design, API Design, and it's current title: People-Oriented API Design. The project had been on indefinite hold for quite a while, but this morning awoke with a new vision for the book. So once again, at least for now, the project continues. From time to time, I plan to publish more articles on Artima.com based on material from this book project.
Table of contents with links to some material of People-Oriented API Design:
Interview with Ken Arnold Perfection and Simplicity:
Are Programmer's People? And if So, What to do About it., a post in Ken Arnold's weblog:
Donald Norman's book, The Design of Everyday Things, a excellent book about people-oriented design in general, is available on Amazon.com at: