How We Failed

I had a chance to sit down and walk through a list of higher-priority items with several of the key stakeholders for the existing enterprise management application today.  We made some great progress and I was able to diagram out some of the NextMostImportantThing items that users are looking for.

It wasn’t the features they were asking for that shocked me, however, when we spoke; rather, it was the way they described them.

Generally speaking we as software developers have failed our users.  Perhaps, better said, we have failed ourselves because of what the users have come to expect, and what they perceive a ‘good’ user interface might look like.

For a long time I have been in the camp that claims, “Users don’t really know what they’re asking for.”  In a lot of cases I could argue that still might be true, though I would suggest a rephrase on that take to say “We haven’t equipped users with the vocabulary they need to best express the functionality they would like.”

Why is it important to put the blame on developers, analysts and architects?  Because it is not likely our end users who will come up with the next innovation in user interface and in order for us, as a community, to do that very same thing we must first admit that our processes are broken.

Take, for instance, some of North America’s leading applications in the CRM category.  I was recently contracted to a company to help them decide from the myriad of options out there what platform and package best suited their needs.  Vendor after vendor I became increasingly frustrated as I helped the company survive demos and walkthroughs that confused users and presented over complicated user interfaces for very basic tasks.

I later returned to that company – after their employees completed the three week training program for the selected package – to help a lady who was in tears because she couldn’t remember how to print labels.

I remember the epoch of the trainer’s failure who, when asked about how to print labels, replied very confidently, “Oh, that’s easy! All you have to do is pull up a query of the customers that you want the labels for, flip over to this tab, look for the tree node appropriate for the label size and type you’re looking for, then drill into the options to begin the merge.”

To you and I, that might sound easy, but lately I’ve been seeing the stunned look on those users’ faces when he said that over and over in my mind.

Our users are people, not computers. Data and queries and tree nodes and tabs and asynchronous operations mean nothing to the 45 year-old office worker, and quite frankly, to most 15 year-old so-called “computer whizzes” too.  We have polluted the user experience with elements of what makes our lives – as developers – easier to digest.  I love using a tree to walk through a class hierarchy or browse a project, but is that how people – note that I didn’t say “users” – think of their customers?  Is it fair of us to group everything not part of the application framework or the user interface into a bucket called “data” and then blame the users for not getting it?

I’m starting to wonder if great design begins not with understanding what the user wants, but rather with equipping the users with the vocabulary needed to express their requirements.  When they start thinking and telling us about the kinds of things they would like the computer to show them – and I’m not talking about endless grid after grid after table after filtered list – then we will be able to empower them to do the human side of work and start letting the computers express the data in more meaningful ways.