Practical .NET

Finding the Problems in Your UI and Listening to Users Effectively

While there are several tools available to monitor your application's performance, when it comes to improving your UI, it's your understanding of your users that's critical to finding problems.

• By Peter Vogel
• 06/04/2013

You should always monitor your applications to determine what problems they have. Without monitoring, bad things never get better. When it comes to determining if you have problems with your UI, this doesn't have to be a terrifically complicated process.

For instance, part of monitoring your UI is simply providing a place where users can register complaints and requests. Obviously, a screen that's getting lots of requests and complaint reports is worth looking at for problems.

The primary criteria for a successful UI is: "The user always knows what to do next," which suggests another set of simple measures. You can, for instance, ask whoever is training your users (often, it's other users) which parts of your application require the most time to explain. A related symptom is the number of pages in the user manual or on the help system devoted to a screen. Similarly, asking whoever's manning your help desk which screens generate the most calls for help will point you to where you have UI problems. With these measures, if no screen stands out then you either have no problems or all of your screens are equally awful.

Another easy monitoring tool: Bad UIs generate bad results. Where do you have bad data regularly getting into the system? Where do business errors typically originate? Both of these measures will often point you to misleading UI designs.

How to Listen to Users
There are two caveats to keep in mind. First: When listening to your users, you can't argue with them, defend your interface or explain how it "really works." It doesn't do any good, and interferes with hearing what the user is saying. Second: You can't assume whatever the user says is the problem is actually the problem.

The reality is that users often don't report the problem they're having. Instead, users report what they perceive as the solution to their problem. Unfortunately, users don't know as much about what can be done in a UI as you do, so their solutions probably aren't as good as your solutions. You have to drill down to the real problem.

For instance, I once got a request from the head of my company's Quality Assurance department to reduce the font size in a textbox to 8 point (the existing font size was 12 point). I was younger than I am now, but even then 12-point font was about the limit of screen legibility for me. I asked the department head why they wanted this change. The answer was that the textbox users couldn't fit all the information they needed into the space available. I asked if allowing the textbox to scroll would also solve the problem. The department head liked that idea better and that's what we implemented.

Technical Monitoring
I'm not opposed to monitoring your application electronically. In some ways, the various tools that you can use to record how users interact with your UI are more satisfying than the measures I've discussed here because they provide you with objective numbers about how users are actually using your system. However, those technical measures don't come with a user who can explain the problem, the way that my department head did.

In this area, ASP.NET developers have all the advantages -- there are any number of tools that will track and report how users interact with your Web-based applications. For instance, it's relatively easy to track the number of visits to a page and average time spent on a page.

The key issue here is to correlate this information with how you expect users to interact with your application. For example, a page that supports an infrequently used option shouldn't be visited very often. If that page is being visited frequently, it's a sign that users are being misled by the UI and selecting something they don't want. Similarly, if people spend very little time on a page, it's a good sign that users are visiting the page accidentally, realizing their mistake and backing out. If users are spending a long time on a page, that may also be an indication that it's taking users too much time to figure out how to use the UI.

However, in all of these cases, without some measure of how many visits or how much time is "right" for the page, you can't tell if there's actually a problem. To make matters worse, for frequently used screens, you also need a mechanism to factor out new users from experienced users. With sufficient motivation and experience, users will figure out any UI no matter how badly designed it is, so experienced users will hide the problems in your UI that technical measurements are supposed to highlight.

You do need to monitor your applications' performance, not only to spot performance problems but also to spot UI problems. However, it's your understanding of your users and how they interact with the application -- based on your personas and user stories -- that will tell you where your problems are.