The Most Important Questions to Ask When Building A Web Application UI.

You didn’t think I was going to reveal it so quickly did you? Of course not, I like everyone to learn a little bit before they get the answer. There is nothing wrong with being forced to think a bit.

Let me back up a little and begin there. The other day I was driving home from work and recently started  on a new UI project. I was going through my normal routines  when presented with a  project.
I start to ruminate over all the things I can do and how all the various functions of this new application would tie together. As I pondered this in between paying attention to traffic and driving, one core question popped into my head. A light bulb snapped and thus this article was born. I realized just how many designers, and developers, forget to ask one magic question.
Maybe they are strapped for time, burned out, or whatever the reason might be. You need to ask yourself this question!

Would I use my own application?

Would  I use this application. At first glance it is such a simple question but extremely valuable and woven with complexity. By knowing the answer you begin to discover unknown paths, problems, and practical answers to otherwise obtuse solutions.

Frequently, when I’m working on a new application with a development team I have to stop them a minute and get them to think about what we are trying to build. Not from a developer, QA, BA, Interaction Designer, UI Designer, System Architect, SQL Developer, perspective but from the person using the tool.

Walk A Mile In My Application

I like to think of it this way. It’s easy to make a pair of shoes, especially if you don’t have to wear them. Nails can stick out of the heel and the fabric may be torn. I still get an A for effort right? WRONG!

Another comparison would be just like the athlete who advertises how great a product is then turns around and uses another instead. Wouldn’t you as a user / consumer feel cheated in some way?

A true life example recently involved a function and feature for inter-application navigation. The feature was supposed to allow the USER to quickly change between editing different individuals’ information.

“A user could quickly change between various people and edit them rapidly.”

It sounded like a safe idea on the surface, but here is where the problem existed. We started by examining all types of ways to make this feature work and be non-confusing to a USER. I tried chunking the information, grouping it in different ways, larger titles, more prominent text. No matter what was tried in the current framework it was still extremely likely for the USER to get lost and more importantly loose the context of the initial task they were trying to complete.

Should We Design for the Sake of Design?

So I sat back a while and thought about the problem. That is when the answer hit me. Why? Why are we trying to let the user do this? Why were we trying so hard to fit a square peg into a round hole? Of course, every group had their own answers:

• Developers – “It would be great if a USER could manipulate the data quickly.”
• QA – “It works and does not break functionality. What is the problem?”
• Business Analysts – “The user should be able to do this function (but why?)
• Interaction Designer – “There must be a solution to this to make it highly usable and fit into the requirements.”

Now let’s back up a second. What about the task itself? Why would a user care about editing multiple individuals quickly? The quick untested assessment was “Users sit down and want to edit multiple people at once.” That was the expected reality but taking a step back and analyzing the task step by step the team discovered that there was absolutely no need for 99% of the users to do this task. They just would not use this system or this feature in the way it was envisioned. If I was editing an individuals information it was because I was either:

A. Talking with a customer recently and discovered changes to this information
B. Made a mistake when entering information and wanted to correct the information.

In either case we had other methods to handle these scenarios. What we didn’t have is a way to mass edit a single individuals information (usability and focus group testing should be conducted to figure out if that is needed). No matter how much everyone wanted this feature we really had no need for it. It was cool but as you read in previous articles that is not enough to justify its importance in an application.

So when you are developing or building a new UI. Ask yourself these questions:

1. Would I use this application (feature)? If not why?
2. What are the tasks the user is trying to complete?
3. Are there too many tasks complicating a single workflow?
4. Does my UI or application framework have enough flexibility to support these new functions?
5. Have I been consistent in my UI framework?

So ask the question and challenge the team to give the “why”. Why are we building this application? Why should we build this application? Will our customers or more importantly will I use this application?

Related articles:

1. Corporate Conflicts A Cantakerous Cacophany of Confusion.
2. UI Design Lessons: A UI Designer in an Agile World, Get Me Out of Hell! – Part 1
3. Agile UI Design: A Fundamental Miscalculation in UI Design Excellence?
4. How Can I Speed up Proto-typing & Visual Design Mocks with Hybrid Design Proto-typing?
5. Why Did My Design Fail Miserably and Other Not Nice Things?