I’m the boss, need the info. – Dr. Evil

Believe it or not I spent a bit pondering user-driven-design while I was laying in my hospital bed being bombarded with bad TV.  My visit to the hospital (and my prior one) showed me that, in the UI department anyway, hospitals fail miserably.  People like you and I, we thrive on information.  We need feedback when we take action.  It’s ingrained in us from birth.  We get grades on papers and tests and anxiously await their return when we do school work.  We seek verbal and nonverbal feedback when we interact with other people.  We get feedback on the roads when driving, from signs and signals to the bumps on the side of the road that tell us we may be drifting too far and should correct course.  We get feedback in our jobs in the form of raises, promotions, reviews, reprimands, and even being fired.  We go through our life expecting information to process and feedback to guide our actions in every system we interact with, technological and human alike.

So the hospital UI fails, and in a critical way in my opinion.  I spent the entirety of last Monday almost completely in the dark as to what was going on with me.  I knew I was taking tests, but I was not receiving any grades so to speak.  I spoke to the doctor once Monday morning, he asked me several questions, he left, and I never saw him again.  The nurses that came regularly to take my vitals were the only people that spoke to me, and they had no information for me either.  I was fortunate that someone close to me works in a related hospital and had access to my electronic charts.  This person called me every few hours to let me know how my tests were going and what was going on, and to answer medical questions I had.  HIPAA be damned, I’m glad this person was there for me.  In a case as critical as me coming to the hospital and laying there worrying over what may or may not be wrong with me, I need information to process and feedback on progress to not go insane.  Were it not for my private information giver, I would have been in there all day stressing out over nothing, and since I was there for stress, that wouldn’t have been very good I don’t think.  Therefore, the UI of the hospital is broken.

We don’t really think of our outside-the-magic-box interactions as UI, but maybe we should, because there are parallels to be drawn and lessons to be learned.  For example:  Say you are at McDonald’s.  Someone ahead of you just placed a large order and unexpectedly cleaned them out of fries and McNuggets.  You’re sitting in your car, and you had already ordered the 12 piece McNugget meal.  In systematic terms, the processes CookFryBatch() and CookMcNuggetBatch() are going to kick off and run, and they’re relatively long-running processes.  You are going to have to wait for them to complete if you want your food.  You can’t do anything about the long-running processes.  Now, one of two things can happen when you are at the drive-through window.  You can sit there, in full view of the window agent, and have her not say a word to you while you wait.  This causes confusion and anger because you don’t know what the hold up is, and you can’t do anything but wait and get more frustrated as the seconds pass, because when you are *waiting* you can feel every second pass as if it were a minute, and goddamnit when you worked in fast food we always greeted the customer and let them know what’s going on and what the hell is wrong with kids these days!  Sorry, tangent.  Anyway, that’s bad UI, and it’s happened to all of us.  This is basically the Mickey D’s version of unresponsive window while long-running process completes.  The other scenario is that the window girl passes you your coke, says “I’m sorry sir it will just be 2 minutes while we finish preparing a fresh, hot batch of fries and nuggets for your order.”  You sit there, drink your drink, listen to the radio, appreciate the service, are nice to the girl when your food does finally come, and don’t bear any ill-will toward that restaraunt, possibly preventing you from returning as a customer.  This is good UI.  Sometimes the long-running process is unavoidable, however, you want to provide feedback to the user (tell them what’s going on, and how long, approximately, it will take), make the window responsive to the user and let the user perform actions that do not interfere with or rely on the long-running process (give the user his Diet Coke so he can drink it while he waits), and then provide notification that the long-running process is complete (hand out that bag and a cheery platitude!).  This is a UI that the user will not hate, and will use again.

I don’t know if I’ve finally gone mental, but more and more I see almost every non-computer interaction that I have as a classic UI issue of some sort.  Standing in line or waiting for something is a long running process.  Financial transactions are…well, transactions, providing user interaction at every step.  Thinking about this made me think more and more about software.  In my current project, I’m doing a lot of UI, which is outside of my comfort zone.  Let’s be honest with ourselves…9 out of 10 of you reading this would, if you could, automate the user function and just write code on the domain logic layer and below.  Don’t front.  It’s true.  But most of us can’t do that, and, especially in the corporate IT development world, end up doing a lot of UI.  Sadly, most of us end up doing it badly.  I’m not talking about the aesthetic issues surrounding UI…that’s what designers are for.  I am talking about the interactive parts.  The things the user touches.  The stuff that will make a user hate even the most beautifully designed software.  Let’s talk about a few of the common pitfalls, and how to avoid them.

The Long-Running Process

Everyone has dealt with this one in some form or another.  For my definitions, especially as it pertains to UI, the long running process is anything that takes a perceptible amount of time to complete.  Almost everything that happens at the UI level happens near-instantly, so anything that takes a measurable amount of time is “long” in a user’s estimation.  Now it is for you to determine acceptable durations of long, but suffice it to say that if the user notices, and it prevents or seems to prevent productivity, the user will hate it.

There are a lot of fixes for the long-running process problem, and you have to decide which to use in order to best accomplish the task.  First of all, anything that will take a significant amount of time should be moved out of the UI to some backend system if possible.  Barring that, you will want to at least take the long process out of the UI thread and let it happen asynchronously with the process that started it.  For instance, if the end result of some user-driven process is to process a large quantity of data, possibly for printing or exporting to file, don’t make the user sit there and stare at a “frozen” screen for the entirety of the process just because he had the unhappy duty of filling in the textboxes and clicking the button that initiated it.  Move that long process to a separate thread and let the user go about his day, providing, if necessary, some sort of feedback as to the state of the process.

Likewise, if the loading of a form requires the loading of a large amount of data, do what you can to page that data into smaller, more manageable chunks.  Or try to “pre-load” the data as much as possible before the user is at the point of needing to interact with it.  Obviously there are lines to be walked here, and every situation merits its own careful consideration as to the right solution, but one thing is constant:  leave the UI unresponsive for any period of time that causes the user pain and they will hate your software and spit on you in the halls.  Maybe burn you in effigy.

Input Dissonance

I have seen a lot of (and, sadly, created some) software that causes “input dissonance” (I just made it up.  Big whoop.  Wanna fight about it?).  Developers by nature are information-mongers, and we like to cram as much stuff into as little space as possible.  This leads to a lot of bad UI.  Too many textboxen on one form.  One form with 50 tabs (and too many textboxen on each tab).  Mixed purpose interfaces, leaving the user confused or overloaded, as to the actual point of a given form.  Poorly grouped inputs that are a burden and are out of sync with the way the user performs his work.  Hell, even bad tab orders can cause the input dissonance.

I’ll start with tab orders, as this one is a no brainer.  Your form should flow logically.  It should feel right.  If I am filling out my address, I expect to tab from address line 1 —> address line 2 —> city —> state —> zip code.  Even if there is other information on the form, the tab orders should follow logical groupings.  A lot of developers try to do strictly left-to-right/top-to-bottom tab ordering, and while that makes sense from a purely logical standpoint, that kind of rigidity can lead to a confusing form (see even when we think we are doing it right, we may still be doing it wrong!).  So pay attention to the logical groupings of inputs, put yourself in the user’s head, and fix your tab orders accordingly.

If you are like me at all, you hate the idea of a “wizard”.  The mere thought conjures visions of hapless, clueless users that couldn’t find the “Any” key with both hands and a flashlight.  But, the simple fact is, a properly created wizard can do wonders for your software.  Wizards break input into small, manageable, logical chunks.  They guide the user, step-by-step, and greatly reduce the incidence of input error.  What do you think is less painful for the user:  a 3 form guided wizard with 5–10 inputs each screen, broken into logical groupings?  Or a single large form with 30 inputs laid out…well, pretty much however they will fit on the form?  Don’t be so quick to discount the effectiveness and impact of well-designed wizards and single-purpose pop-up forms.  I don’t know why we feel the need to cram so much information onto single screens, but let’s try to curb that habit mmkay?

Deviant Behavior

This one is an app-killer like no other.  I see it so often, and I’m just astonished by it, because it’s the easiest thing to get right in UI design.  Users expect your software to function similarly to all of the other software they use.  As developers of software, we clearly use software too.  So this should be so hard.  We know what the common behaviors of applications in our platform are, so why deviate?  Why intentionally do something different?  You think you are a unique and beautiful snowflake.  You aren’t.  Here are some rules that, if you are going to deviate from them, you had better damn well have a good reason (Windows version…I don’t develop for or use a Mac, or Linux…someone else can make those lists):

• If your application can be minimized, it must be acceptable by one or more of the following:  system tray, task bar, alt+tab.  Don’t hide it from the user.
• Your application should support standard keyboard shortcuts that are common everywhere:  cut/copy/paste.  F1 for help.  Tab/Shift+Tab.  Whatever.  Support the shortcuts the users expect.
• If your application has menus, they should follow, as applicable, the standards.  File|Save, File|Open, File|Exit, Tools|Options, Help|About, and so on.  Fill your application-unique menus in around the staples.
• Cancel buttons should return the user and his data to the state prior to the form on which the cancel button appeared.  They should also prompt for confirmation.
• Wizard-type systems should allow navigation forward and backward in the process, saving state and data along the way.
• Hitting “Enter” should trigger a default action on the form, usually the same action as the next/save/finish-type button.
• Button graphics for general functions should match expectations as applicable:  save=floppy disk, close=x, spell check = check, new=blank sheet, you get the idea.

I’m sure there’s others I’m forgetting…I’ve seen some bad stuff.  For most of us this is a no-brainer too…our modern UI toolkits support this kind of stuff out of the box, and you actually have to try to not fit in.  If you are using a non-native development tool, like say, Java on Windows, then maybe you have to do a little more work to make your app function like a native windows app.  It’s worth the trouble if you want users to adopt your software.

Action Feedback

This one is simple.  When a user performs an action, he may want some feedback to let him know.  This is why echo was invented back in the command-line days.  (Ever try to do any significant terminal work with echo off?  What a trip.)  When a user clicks “save” let him know his stuff was saved by a message, or closing the screen, or something other than just…leaving the data there as is.  If an error condition occurs, trap it, inform the user, and let him know how to fix it when appropriate.  Don’t just make some default action happen and leave the user wondering why.

We tend to overthink feedback and presenting information to the user.  It doesn’t have to be complicated or overly sophisticated.  This is an area where hardware developers routinely kick our ass.  Just from where I am sitting I can quickly ascertain the current state and condition of my router, my cable modem, my tv, xbox, dvd player, stereo receiver, monitor, mouse, computer, microwave, coffeemaker, and cell phone.  Just with a simple combination of lights, sounds, or simple visual cues I can tell what each of these devices is doing.  In software, we should take lessons from the simplicity of the feedback of these hardware devices.  I’m not saying reduce your software feedback to lights and beeps, but I am saying don’t overthink feedback, and don’t overlook it.  Simple things like message boxes, blinky error icons, and changed text will go a long way in keeping your user engaged and happy with your software.

Flawed Assumptions

Flawed assumptions happen all the time.  Depending on what kind of software you are writing, these can be more or less common, and more or less daunting to the user.  We don’t develop in a vacuum (as much as we would like to sometimes) and we need to interface with the users early and often before we can hope to build an interface for the users.  Whether you are developing boxed software or in-house systems, know thy user.  I spend time before developing any system just sitting with the user, watching her do her job, asking questions, taking notes.  Sometimes I will even do the job for a brief time, go through training, and perform the duties for a day or two if time allows.  If I don’t know what my users do, how can I be so bold as to think I can provide them with software to help them do it?

Time and again, I have seen software fail because it did not mesh with the mindset or workflow of its users.  The reality is that business processes aren’t always as logical as a geek like me thinks they should be, and it drives me crazy, but I have to write software to support the real process, not the ideal one that I dreamed up in my head.  Granted, you would be remiss if you didn’t thoroughly evaluate the human processes and make suggestions on glaring problems, or show ways that software + change could improve processes, but at the end of the day, your software is there to support how the user works, and if you haven’t done your homework you may just be getting in her way when she tries to do her job.

When all is said and done, the goal of any piece of software should be to augment the user’s workday, not alter it.  It should stay out of the way and help them be more efficient.  If your software makes your user think about it instead of the job it is facilitating, then in some way you have failed when you created the user experience.  How often do you think about Word when writing a document?  Exactly.  Good UI stays out of the way, and lets the user do what the user does.