Author Archive

The following is a guest post by Jaffer Haider, who will hopefully be building this into a series of articles on Usability and better user experience design

Usability is something that ISV’s in Pakistan don’t pay enough attention to. In my experience as an engineer I’ve never witnessed any usability activity take place in teams, whether it be usability design work, user experience review or usability analysis by specialists.

I think the Ok/Cancel comic below perfectly captures the absence of attention given to the user interface in our industry.

A typical medium sized team working on a web application in Pakistan would probably consist of about half a dozen developers with 1 QA resource. If they’re lucky, they’ll have a designer assigned to the project as well. In most cases a designer is synonymous to a graphics artist, who provides flashy images, rather than an actual UI designer. There is no member of the team that is dedicated to usability work. In some cases, teams will outsource their graphics work and get complete wire frames, but that introduces an even wider gap between mapping requirements to the user interface in a way that is efficient, easy to use and learn, satisfying for the user and without errors, the crux of web usability.

In essence, a usability resource is the only representative of the end user’s needs on the team. The customer cares only about the features they want. Even when customers themselves are end-users, they still can not be counted on to know exactly how they’d want to go about using a certain feature. Developers take the path of least resistance, and UI design is not a priority. This is what happens when you let developers create UI.

But why bother with something that is essentially non-functional? Usability doesn’t provide us with any new features. And after all, making a new web site these days is all about cramming it with features, right? Desktop applications might have that luxury, but this can’t be more untrue for web sites. Jakob Nielsen sums it up beautifully;

On the Web, usability is a necessary condition for survival. If a website is difficult to use, people leave. If the homepage fails to clearly state what a company offers and what users can do on the site, people leave. If users get lost on a website, they leave. If a website’s information is hard to read or doesn’t answer users’ key questions, they leave.

Studies have also shown that users form their initial impression of your website within the first 50 milliseconds of viewing. Users are also likely to base their perception about a company based solely on their experience on the company’s website.

In the case of Intranet applications, enhancing usability translates into less training time, better employee productivity and faster acceptance of new processes. How many times have you shunned away from filling out that time sheet simply because its too hard to find in the IT governance software that your employer is using? How much time have you wasted in trying to print out a list of open issues assigned to you between dates X and Y in your bug tracking software? Now imagine the same problems being faced by a customer on an e-commerce site. Web usability is a key factor in determining sales, but sadly that isn’t always enough to stop your product manager from chipping away at the budget and time allocated to usability on your employer’s next big product.

So what can you, as a developer, designer or manager do to convince your team to think about the users’ perspective and allocate time and resources for usability design and testing?

1. The first thing to do is to recognize the fact, and make your team realize, that the UI of your application is not something you slather on after you’ve developed and integrated all its features. It’s an activity that should be present in all stages of a project’s development cycle, from analysis and design to development, testing and tweaking. Pat yourself on the back if you’ve managed to convince your team. The next step should be to incorporate a process in your development cycle that caters for all usability needs.
   1. Start with small and meaningful changes. Don’t look to revamp the entire system. Identify high traffic and critical areas of the application and work on those.
   2. Numbers will always be more cogent in convincing your team about the importance of usability. Track your changes against business metrics and how they impact them.
   3. Actively participate in the scheduling of the project and make sure that usability activities are scheduled and are not relegated to the ‘if we have time’ section.

   These are some of the main points highlighted in Pioneering a User Experience Process. I highly recommend a read if you’re looking for a good stepping stone.

2. Design for the user, not for your business logic object. Developers usually work their way up from the Data Access level, through the Business Models and Business Logic and finally to the UI, so it is natural for them to think of the UI in terms of the plumbing that they’ve spent so much time on (the fact that I instinctively capitalized the names of all those layers is proof enough of their stature :p). The best way to do this is to get your hands on a representative set of end users, and make them go through a prototype of your application. By far the fastest and cheapest way to do this is paper prototyping. It is important to realize that your role in these tests should be that of an observer. Let the user do the talking.
   To effectively design for the user, you must first know how the user actually sees your site. A page you painstakingly forge from links, images and carefully thought out text is nothing more than a fancy billboard for a user. We don’t read pages, we scan them.
   
   (reference – Steve Krug’s Don’t Make me Think!. Buy here, it comes highly recommended)
3. This point is in essence related to the 2nd one, but is important and doable enough to be mentioned separately. It is simply to minimize the hurdles between the user’s starting point and destination (the reason they came to your website in the first place).
   This alleviation of obstacles can be done by keeping the following points in mind:
   1. Reduce the number of steps (usually measured in the pages and/or mouse clicks) between the user and their goal. This applies both at the macro level (across pages) and micro level (within a page).
      • Macro example: Say you’re a photo gifts and sharing site and a user hits your homepage. If you require a user to signup + create an album + upload pictures into it + customize a product using a picture in that album, then you will always lose out to the site that allows a user to anonymously customize and order a product using a single or set of pictures.
      • Micro example: A transaction entry page on a finance tracking application will fare better if it intelligently extracts the category and amount from a transaction description (categorizes “200 ruppees on a Subway sandwich for lunch” as ‘food’) instead of making the user enter these items individually in different text fields.
   2. Provide meaningful instructions. Give the user a map that they can rely on. If a user is on an intermediate page, then they must be told what to do, how to do it, and what to expect as the result.

Usability is a huge and vastly misunderstood field. I hope I’ve given you a small glimpse into what benefits it can bring to your project and how you can go about improving the usability of your software. I’ll hopefully be covering more detailed techniques, studies and concepts in future posts.

So how much attention do you pay to the user experience when building your projects? What processes, if any, do you or your employer have in place to incorporate user related activities in a project’s life cycle? What do you think is the reason for lack of quality user experience people in our IT industry?