Summa

A few weekends ago my father and I were installing a shower valve in my soon-to-be new bathroom in my soon-to-be remodeled basement. This isn’t your father’s shower valve though; no, this is a new-fangled shower valve. You are all familiar with shower valves (I hope), they come in two varieties mostly: 1. two knobs…one hot, one cold. 2. One lever/knob that gradually goes from cold to hot. I could go into much more detail on how this works now that I am a plumbing master, but that’s for another blog and another time.

So on with the story. We are installing this valve I bought without really inspecting at the store (I figured a shower valve is a shower valve right? The most important thing is that my wife likes the color), and it is the lever type that mixes hot and cold as you move it left to right. However, we notice that while this controls the temperature mix of the water it does not actually allow water to flow through the valve. That is controlled by another lever attached to the valve.

So the theory is that a user can set the temperature they like and then each day just turns the water on and off. This way they don’t have to spend a few seconds each morning getting the temperature just right again. I think this is a great idea. My dad’s reaction is confusion. Not confusion in how this works, but that people “your age” over-think the simplest tasks in an effort to make something already very easy just slightly easier. His thinking is: everyone knows how to use a shower valve! This is something we use every day without problem and it is already very simple, why would you waste time making it “more” simple? What would really have helped us is if you spent more time making the thing easier to install!! (a task most of us have to do once or twice in our lives, if ever)

Well, while turning on the water in my shower today this all came back to me and it got me thinking about what we do in user interface design. Specifically I started thinking about how even if a system is not designed to be the most usable system on Earth but instead is just reasonably usable, if users interact with it regularly enough it becomes very usable. This isn’t really groundbreaking stuff. What really intrigued me though is that we probably should spend more time on making the less-used parts of our system more intuitive than the commonly used areas we typically worry about.

Think about this: There are almost countless organizations, schools, military bases, etc around the country right now being run by a few people who have been in that office for years. They are using a cobbled together Access database, three Excel spreadsheets and a couple of filing cabinets. This is possibly the least-intuitive interface you could design, but they are very efficient at using it if only because they use it every day. So you are thinking, Adam are you saying if I am designing a system for every day use I should make it as unintuitive as possible? Should I spend no time at all thinking about the usability of what I am designing for common use? Of course not. We should always strive for usability. My argument here is that if we are budgeting limited time to make interfaces more usable we could help our users by allocating more of that time to parts of the system they rarely use, once the commonly used areas are reasonably usable.

Screens used only at year-end, data entry forms only seen at tax time, reports only run when auditors show up. My argument is these are the areas where we need to spend extra time making the interfaces so intuitive that someone could walk off the street and use them. Sure, we could spend another week making the screens users see every day a little extra intuitive and the users will love you for it…the first week they use it. After that the extra time you spent will have almost no impact on their daily use. They will memorize the system to the point where they can use it with their eyes closed, until April 15. On that day they have to do a few simple tasks for the tax man that they haven’t done since last April 15. This should take a short amount of time, but since you spent all of your interface-improving budgeted time deciding where the submit button is on the screen they see in their sleep, they can’t figure out how to do this simple task! Now they spend hours trying to figure out where to find the correct entry screens, searching through manuals or calling for help. Something they would never do no matter where that submit button on the screen they use every day was located.

The graphic below shows how I believe we should think about allocating our time to improving usability of certain interfaces in systems. You will notice that while cost (or time) and usability move left to right as they increase, frequency of use moves right to left as it increases. So when you are deciding how much time to spend making something more usable, figure out where this interface lies on the frequency of use arrow and then budget accordingly. Disclaimer: This applies only AFTER you have interfaces that are already at an acceptable usability level for the users who are paying for the system. Disclaimer 2: I drew these on a notepad after I got out of the shower but before I had coffee, so take them with a grain of salt.

To make this all seem more scientific and thought out, instead of something that came to me in the shower, these graphs attempt to show the additional usability and how it affects a user’s efficiency over time.* Again, making the most common tasks that little bit more usable helps with a new employee off the street for the first few days or weeks but once they have memorized how to use the system this extra effort has almost no effect on them. Efficiency for the uncommon tasks increases with time because you come across more uncommon tasks with time, and efficiency is increased every time.

Remember, this is just something to think about as we design interfaces and make decisions on where to expend the most energy on the usability side of a project. This is not meant to be a hard and fast solution for every design situation you come across. However, I think we can all agree that usability gets shortchanged in most projects anyways, so maybe we can start getting the most out of what little time is allocated to user interface design on our future projects.