Friday, May 18, 2007

Do The Heavy Lifting For Them...

Every time you design some new functionality for an application, you have the opportunity to delight your users by focusing on making the task easier or you can frustrate them by making things more difficult. Obviously, most of us want to achieve the former, but sometimes in our rush to simplify OUR lives (shorter development time, easier maintenance, etc.), we tend to gravitate toward the latter. Especially when we are building something that we've done 100 times before, our inspiration may be low and it's difficult to overcome the inertia of "let's just get this finished as fast as possible". One way I've found that helps me overcome this feeling is to take a step back and look at the functionality through the eyes of the user. I try to imagine what scenarios might be playing through the user's head as they sit down and see the screen I've designed. Is the layout clean and simple? Are elements labeled appropriately or is the form laid out in such a way that the purpose of each element is intuitive? Does the new functionality I've just designed make their lives easier or do they need to exert more effort to get what they want. In other words, am I doing the heavy lifting or are they?

The answers to these questions can sometimes be very enlightening and can help you frame the context of your work in a more user-friendly way. Here's a recent example from my own experience:

I'm putting the finishing touches on a simple workflow application. It actually has a few neat and unique features, but most of it is the standard stuff. It happens to be a sister process to another application that is already in production, so it made sense to design the look and feel of the app to match the existing one. All of this makes for fairly tedious design work. Once most of the application was complete, I took a step back to review some of the functionality. One of the first things that struck me was that I had a really great feature on the main screen but I fell into the trap of making the user do the heavy lifting.

Sticking with my common theme of getting the user to their data as quickly as possible, I have a data entry field on the main screen that allows the user to input the unique identifier for the document, which takes them right to the form in question (assuming it's found).

For this particular application, documents are numbered according to the last two digits of the current year, followed by a "-" and then a three-digit sequential number (e.g 07-006). In my initial incarnation of this functionality, I just took the value the user entered into this field and did a lookup by key. If I found a match, I opened the doc, otherwise I told them there was no such document in the database. After spending a little time reflecting on this, I did some research into how users actually use these numbers. When communicating about a particular EWR, did they say "O seven dash O O six" or just "six"?

Turns out (not surprisingly) that there's a lot of variation about how people remember these numbers and communicate about them. This fact made me go back and rethink how to write the code so that it would simplify the act of finding a document for most of the users. With just a little extra effort, I was able to modify the code so that users can type in a variety of different formats and the document will be found. Using the example above, they can now type in:


If the user leaves off the year designation, then I assume it's the current year. They can choose to enter just the significant digits of the EWR number and in the code I simply manipulate the string they enter to use as my key in the lookup. I even check for ambiguous entries, so if they enter something like "06-", I then bring up a dialog box showing all of the 06-xxx documents. Overall, I tried to address the main ways a user might enter a number so I don't have to bring up a nasty error message telling them their document couldn't be found. I know it's really frustrating for me when I use an application and I am sure something is out there, but I just don't have the correct syntax to find it. It's empathizing with this frustration that inspired me to go back and work on the lookup functionality. Fairly trivial? Yes, it is, but add up the small gains like this and you end up with a much better user experience. With the new functionality, the user doesn't have to spend time thinking "what is the format I need to use to find a document?". Instead, they can just enter the number in the format that they are used to and they'll be whisked away to the document.

I encourage you to try this the next time you are building something new or tweaking an existing design. Try to find those places where you are asking the users to do more work than is necessary and then use your skills to make it easier for them. After all, as the developer, you've got all the muscle.


Keil Wilson said...

Chris is making an important point here (once again). But to make the impact of this more obvious, the change here makes the users of Chris' application more productive. It's difficult to measure exactly how much more productive this one little change makes, but when this attitude is applied to an entire application, application suite, or all of the development in the enterprise, the productivity improvements for employees really start to add up. It's not just about saving a few seconds of typing, but keeping the users on task and thinking more about what they intended to work on instead of thinking about how to use your application. Thanks Chris for keeping us all thinking not just about the functionality of our applications, but also about how to make them more usable. It doesn't matter if your application does exactly what the user needs it to do if they can't figure out how to make it work.

Brian Green said...

Nice article Chris. May I suggest...
Text Field. Default value is a "field hint" for "YY-nnn". Light-grey text. When you enter this field the "field hint" disappears.
To the right of the field is a real button. It is labeled "Open EWR".

Discard the other text "open ewr by ewr number".

I've always found in usability studies that real buttons are always easier to find. What do you think?
Of course, we can only see a small snippet of your form. My suggestion may by out of context.

Anonymous said...

were you able to get rid of "Go" button (hotspot) and allow users just to hit enter?
I was trying to do that (in combination with mentioned "guessing technique") many times, but no luck.

Chris Blatnick said...

@Keil...thank you! Glad to know I am getting my point across. Sometimes, I'm not sure if my babbling is coherent or not! :-D

Chris Blatnick said...

@Brian...great points! To be honest, I never used field hints until just recently. They are a great construct for providing unobtrusive help and I've really embraced them where appropriate. However, in this case I don't want to use a field hint, since I don't want to force the user into entering the number they are looking for in my format. Instead, I really want them to have the flexibility to enter the number in the format that works best for them. So far they are quite happy with it.

Your comment regarding using real buttons is exactly right. Usability studies do show that real buttons are generally better. Why did I use a link this way? Well, one was to maintain consistency with the sister application, but really it was because that's what users signed off on in the low-fi prototype phase! :-) Since we now have better options to format buttons, I could go either way.

That said, check out my next post, because based on your comment and the anonymous poster on this thread, I've added some new functionality that required making the link a button. So...thanks for the inspiration! :-)