Joshua Marinacci's Blog

Please: think of the users!

Usability is the number one concern when designing software. And I don't mean "today with modern computing and the lack of new types of software usability is easier and growing in importance". I mean computers have no other purpose than to serve humans, and a better computer serves humans better. End of story. Software that doesn't conform to the way humans do things is bad software. (bad!) I don't care how cool and awesome your software is, if it's not understandable then it's useless.

A long time ago I thought that computers were hard to understand. This also made them cool. Then I worked as a lab assistant for a few semesters and saw plenty of smart students having incredible problems using computer software, often for tasks I deemed trivial. Suddenly I was hit by a revelation: computers are here to serve people. If a human can't use it, then the problem is in the software, not in the human. This kicked off a change in my mind and I switched my specialization to usability.

In the ten years since I started writing software professionally virtually every core problem I have found with software, be it commercial or open source, big or small, 3rd party or something I wrote myself; has been a usability issue. Not always a User Interface issue, but Usability nonetheless. I once wrote an entire language and toolkit for building wireless applications. I designed an elegant system that handled every task on my features list presented by management and my own ideas of how it should work, yet I never considered how a third party developer would use it. Once I got real users I ended up reimplementing a entire programming language to fit their requirements instead of doing the obvious: embed and existing and debugged language inside of my toolset. I wasn't thinking about the usability: the big picture.

This is my request of all software developers out there, especially the open source ones. I implore you: think of your users first, not how you would want to do it. Your UI will be subconciously molded to fit your own algorithm if you don't think of your users first. We Java developers should be familiar with concept since we often separate interface from implementation. When you design that new widget, first think of what the user wants to do with it, not how you want to implement it. Implementation is secondary. (at best!)

Here are some easy things you can do to make your software more usable.

• Walk away. Seriously. Work on something else for a day. Then come back and run it. Did you have problems getting it to start because you forgot the exact incantation required? Did you click the wrong button because it wasn't where you subconciously expected it to be? Did it look ugly? Did it take longer to run than you remembered? You have to get some distance from your program to accurately evaluate it.
• Draw it. Literally draw the interface on a piece of paper. Make some notes. Does it look good? Does it look too big or small? Could you imagine doing everything in the program from what you see on this paper? What's missing? If you can't draw the interface then you certainly can't code it.
• Get a second opinion. You wrote the software so you are too close it to it be objective. Get someone else to look at it. Show them a screen and ask them to tell you what it does. Ask them to explain how they would do something. If they can't then you need to redesign the screen. They say that programmers can't be interface designers. That's not true. A single person can program and design interfaces, just not at the same time. You need distance.
• Practice uninstalling. If you can uninstall your software easily, then installation must already be a snap. There are plenty of tools out there to make managing your software easy. JNLP. EXE builders. Prefab installers. Pick one. Don't use a commandline with custom options.
• One paragraph description. Describe your software in one paragraph. If you can't then it's doing too many things or you don't understand the problem well. Cut it back.
• Remove features. We often judge a program to be the most elegant if it can do as much as possible in the fewest lines of code. Instead I ask you do judge if the user can do the most possible work with the fewest features. Think of it as the Zen of UI Design.
• Don't reinvent the wheel. Your job is to get a program to your users that lets them do as much work as possible as quickly as possible. Shipping it soon is even better. This quickest way to do this is to not reimplement existing code if you can possibly avoid it. Sometimes you find an open source library that sort of does what you want but not quite. Don't reimplement it. Email the developers and ask for an extension point. You'd be surprised of often they will change the code just for you. And when you write your own reusable software, provide extension points. Then document them. If someone emails you for help, help them.
• Don't invent the wheel either. The quickest way to do this is to not invent new interfaces. I know that your sticky slider widget is cool, but would a simple drop-down box be better? Unless your widget is replacing at least three others you should leave it out.

I'd like to add that is applies not just to software but to the documentation and websites as well. SourceForge, for example, has to be one of the hardest to use websites ever. Each project should have a single paragraph that says: "This is what I do, this is my current status, and this is what to download". Please: think of the users.

Comments

• amen.

  Posted by: clamprecht on October 18, 2004 at 01:52 PM

• You should really read:
  The Inmates are Running the Asylum.
  I thinks it

  Posted by: gary_kephart on October 18, 2004 at 06:47 PM

• Yeah, I read it a few years ago. an
  excellent book. (amazon link)

  Posted by: joshy on October 18, 2004 at 11:08 PM

• Another related book is The Design of Everyday Things by Donald A. Norman. His treatment of door and knob designs are very much applicable to user interface design as well.

  Posted by: karakfa on October 19, 2004 at 09:29 AM

• I just can add, that observer technic works fine to.
  Basically, after the product been deployed, I am coming and observing how it been used, for a few hours.
  It gives me a picture of what to improve ir, or what feature needs to be implemented.

  Posted by: ivanlatysh on October 19, 2004 at 11:46 AM

• I love it! Now if I can just get management to buy into it...

  Posted by: howlerzz on October 20, 2004 at 06:55 AM

• thanks josh for the very good information.
  

  Posted by: marke on October 21, 2004 at 10:38 AM

• "Software that doesn't conform to the way humans do things is bad software"

  Uhmm.. humans do with new software things they have never ever done before, so how can you use that as a criteria? How can you say, for example, than a GUI and not a CLI is "the way humans do things"? That only depends on the metaphore you are using.

  Posted by: sergiogarcia on November 03, 2004 at 01:31 AM

• Cars let humans do new things too, but cars still had to be designed with humans in mind. There used to be several ways to steer a car (pedals, ropes, etc) before the wheel became standard. Even then it wasn't until the automatic transmission that most people learned to drive. Cars are subservient to humans, not the other way around. I'm not saying that they couldn't be better, but clearly a lot of thought was put into the design of cars to fit what humans need. Software interfaces should do the same.

  Posted by: joshy on November 03, 2004 at 07:26 AM

• I agree with most of that, and I like the cars analogy. My point is that you can't say that some interface is not good until you find an option that fits human needs better. Also, at some point you have to stop thinking in the abstract and actually using the software to see what is like to use it. (pedals and ropes are not obviously a bad idea, in the abstract. I guess once you use them, you see they suck compared to the way cars are done today).

  Believing in a platonic abstract perfection for user interfaces (or anything else :) for that matter) tend to make people dogmatic.
  

  Posted by: sergiogarcia on November 03, 2004 at 07:38 AM

• I think the point isn't that you can't have a good interface without humans, its that thinking of the humans makes it better. We need to separate look from function, interface from implementation. Don't make the interface reflect what's going on underneath the hood. Pedals and ropes were tried early on because the were familiar and easy/cheap to implement. But eventually people started to consider how real humans used the cars and built something better, even if it was harder to design.

  There is, of course, no platonic idea for interfaces. The world is messy and the interfaces reflect that. My best analogy is the old example of a college campus that didn't build any sidewalks. Instead they let the students walk over the grass for a few years and then built the sidewalks where the grass had been worn down.

  Posted by: joshy on November 03, 2004 at 07:46 AM

This work is licensed under a Creative Commons License.