I just read Jakob Nielsen’s “Top-10 Application Design Mistakes” and thought I’d post some notes on it here and encourage everyone to read it since it is a great summary/categorization of the common issues. Why am I qualified to comment on this list? Well, I’ve made a lot of these mistakes in my own work and had to figure out how to avoid them the hard way! Nielsen does a great job of saving you the pain and re-working of things to make sure your next project comes out, and your client, want!
Rather than rewrite or summarize a summary article that is already well written I’ll instead focus on Nielsen’s three categories of mistakes.
- Solving the wrong problem: This is incredibly perceptive because in my experience designers and developers bring their own interpretation of the problem to the application. Often this is a result of an incomplete understanding of the client’s requirements, or of the end-user’s understanding of how the application should be used
- Having the wrong features for the right problem: Even if you successfully identify a problem, you must still provide the right suite of tools to empower users to address the problem the application solves. For example, if you’re designing an e-commerce application for a small store, you might think that putting their catalog online, with a well integrated cart is enough. You have, however, ignored how people will both interact with that catalog, find products in the catalog, and handle the workflow that your catalog might require. The only way to ensure you’re giving people the right tools for the problem is to actually sit down with your customers and watch them use it.
- Making the right features too complicated for users to understand: Sometimes the right problem, and the right tools aren’t enough. I’ve seen a ton of great web applications that fail because of how complex they are for users. dotProject is a perfect example. dotProject is a small team project management online tool that has a ton of great features, and has just about everything including the kitchen sink in it in terms of how to interact with this tool. Unfortunately, the learning curve for end users is incredibly high. For many, this learning curve will discourage use of what, at its heart, is a fine tool. Compare it to 37signals’ Basecamp and you’ll quickly discover why Basecamp is so well received and why dotProject, though older and with more features, remains largely unpopular.
For me the solutions to these issues boil down to a few questions:
- Have I identified a problem? Not just, “does this application do something useful?” While the two questions might seem similar at first they are, in fact, quite different. A problem is something that drives people to want to use an application. An application that does something, is a fun diversion. Consider some of the most widely used web applications like facebook, salesforce, or web based e-mail clients like hotmail. These tools all solve a very specific problem, or use the internet to solve a specific problem that requires solving on the web. Sometimes knowing what is an appropriate problem to solve on the web is as important as knowing how to write the code to create the solution.
- Am I following well established models for my UI? You don’t have to be a UI designer to know these models. For example, providing a checkbox vs. providing a radio button means very different things in web forms. Being a consumer of websites is the first step to being a good UI designer. It won’t make your work perfect, but it will at least demonstrate to you the way that people will expect things to be done in your application. Remember that your users are also web consumers!
- Have I watched actual users using my site? Test. Test. Test again. Starting with paper prototypes, static mockups, and then moving into the development will save you an incredible amount of grief. Once you’ve seen someone talk their way through your design you will quickly pick up on where you’ve both succeeded and failed. Sometimes the results can be very surprising. Remember that you want critique and problems to be found before they become hard to fix! Once you’ve coded and built an application is no time to have to rethink or rebuild large sections of how the site works. Testing with real users will always be the best way to find out if your tool solves the problem that you are intending to resolve.
I hope you’ll take some of these ideas into consideration the next time you start a web application project. The mistakes that this information could have saved me when I first started building web applications is incredible. After doing a few Usability Tests I found that the information I was getting as feedback about both how people perceived my work, and how they used it has had an immediate positive impact on the quality of my decision making and ultimately my design work.
Leave a Reply