Wait...What? - Fail! A User Interface Design Experience

Recently a client responded to a mockup of a potential user interface for managing certain kinds of data and the linkages among the data. I had created the mockup after we had spent significant time understanding the client’s needs and I had run it by my colleagues. It seemed to all of us like a decent UI: easy to use, easy to understand, addressed the needs, etc. – the usual things you would want for a UI.

I sent the client a screenshot of the mockup for feedback. The client responded (I’m paraphrasing here) that she thought she saw what I was trying to do, but was having a little bit of difficulty following it and apologized for just being a simple user. I responded with “If you are having difficulty following the intent of the mockup, then it’s clearly not intuitive.”

Fundamentally, the design failed – completely. This was not the “simple user’s” fault.

In my somewhat lengthy career in software development, covering well over a dozen different problem domains from medical devices to aerospace, oil & gas, construction, GPS tracking systems, wireless data acquisition, among many others, I have felt strongly that “the User Interface is the product.” It doesn’t matter how well the software works behind the scenes if the user interface is not intuitive and easy to use.

My goal in user interface design for an application is for the user to be able within 15 minutes, without any training, without a user guide, no online help – any assistance at all, to be able to understand the fundamentals of the application and be comfortable navigating through it. Not necessarily with the more sophisticated aspects, but the fundamental features of the application. After all, that’s what I expect in a product. If I purchase software and it takes me longer than 15 minutes to figure it out, I move on to some other product or approach. I don’t have time to read a manual or help screens just to get started.

Mind you, I’m talking about getting familiar with a new product in no more than 15 minutes. I had sent a mockup of a design for a single screen. It should have taken around 30 seconds or less for the user to understand the design and how it worked.

This philosophy has been very successful for me over the years in building useful applications. One time, a new version of a product I had developed for the construction industry was released and there had been a production error in the manufacture of the packaged software. We didn’t discover the problem for six months. It turned out that the contents of the entire product’s help system had been left out. We found out on our own – none of our customers, new or old, ever discovered the missing help system. I asked several of our customers how they never noticed and all of them simply stated that they never needed the help system.

The reason the mockup I mentioned earlier didn’t work for the client is that we hadn’t managed to get inside the heads of our client well enough (yet) to understand exactly how they think about this particular need. We did understand their needs, but we needed to get a better handle on their mental model. Fortunately, we received the input early in the sprint, so we had time to iterate on the proverbial drawing board and get a new mockup back to the client quickly.

Paul Inman

Paul Inman

CLM Engineer

s2Member®
Skip to toolbar