The Usability Approach

Yes!  The creative juices are flowing.  You feel the rush; the euphoria that comes along with new insight!  A new thought, a creative, inspired moment – a Eureka! moment – in which you’ve come up with a new idea.  A new way to solve an old problem; an old way to solve a new problem.  Lo, it matters not!  What matters is that you’re going to create something.  (Okay, yes, the “Lo,” may have been a little dramatic, but I came riding out of the uterus singing Flight of the Bumblebee, on a bicycle decked out with streamers — my poor mother.)

The creative process takes on generally the same shape regardless of what it is that you’re creating. You identify a need, come up with an idea, and then you implement it… right?

No! This is not right. Unfortunately though, this is what happens far too often in practice. This post is all about process; having the right approach is they key to creating something usable (be it a hammer, a cell phone, or, in our example, a website). A good approach is worth many, many genius programmers.

Common Approaches

Let’s examine a few very real, commonly occurring scenarios.  For simplicity’s sake, we’ll assume that you’re involved in the creation of a website (though, it could be anything). You’ve got the idea, and now you’re itching to get cracking and turn dreams into reality. Here are three possible scenarios to move forward from the idea to the implementation:

Bad (the Lone Ranger Approach): You take your idea to some programmers and web designers in the form of a written specification, and get them to implement it.  They do it; the nuts and bolts are in place and you’re ready to roll it out to customers. Now, for the first time, you show it to your users.

Better (the Talk to Tonto Approach): You take your idea, make some sketches, draw up some designs, write a requirements document, and take it to your web development team.  Part of the way through the website implementation (let’s say, after the home page and the primary functionality are implemented) you meet with the group and run through some possible things that your customers will typically want to do on the site (“use cases”).  Based on your interaction with the site, you make some modifications, and then continue the development.

Best (The Usability Approach): You take your idea, and create sketches of a handful of the most important screens in the site as you envision them.  Maybe you even mock up a prototype in Excel, PowerPoint, or HTML.  You take these artifacts to some people that you consider potential users of your site-to-be and have them run through a few use cases.  Because the sketches/prototype are not functional, the users simply tell you what they’d expect to happen when they clicked on things, and you’d take them to the next “screen” manually.  You collect as much feedback as you can on their reactions.  You then modify the sketches/prototype based on their feedback, and then repeat this process numerous times until you have a design that users interact with without much trouble.  Then you take it to the web development team.

Up-front Usability Work = Better Long Term Results

It’s this simple:  the more you integrate usability testing in an iterative design process before you write any code (as outlined in #3 above), the better the end result will be.

Re-read the sentence above.  It is a one sentence paragraph (and this is not an accident; it’s that important).  Take one minute, close your eyes, and really think about it.

Identify flaws early

By integrating potential users into the design process, you identify flaws in your design that you or your team members cannot recognize yourselves.  This is because you’re too close to the ideas and too attached to the design.  You’re so deep inside the ideas and design that because you know exactly how to achieve your goals, you assume that your solutions are clear to other people too.  Having just a few users look at the proposed interface during each iteration will bring many of the key issues in the design to your attention.

Reduce resistance to change

People are attached to their work.  My work.  Mine.  When somebody suggests that your work is not perfect, by extension, it is suggesting that you are not perfect.  And almost nobody wants to admit that.  But it’s the cold, hard truth.  We are not all-seeing beings, and having other people point this out can hurt.  The more we are attached to our work, the more it hurts.

So how can we avoid this attachment?

First, don’t expect yourself to be flawless – you are human.  Do your best work, but don’t expect it to be perfect.  Be open to the fact that your design is probably not perfect, and be looking to improve.

Second, get feedback early:  the more time and energy you put into your work, the more you have invested emotionally in the results.  If you are heavily invested in a design, you will not want to change it.  You will be resistant to hearing criticism of your design.  Your ego will protect you (and all the work you’ve done) by telling you to that the others are fools and don’t understand; that they are mistaken, and that you are great (and your design is superior).  But this is a fool’s path.  The foolish thing to do is invest yourself heavily without getting feedback before you’re resistant to hearing it.  Wisdom is the ability to see things from many angles — the more perspective you get through feedback with your users, the better your design will be.  A fool stands alone.

Believing without using is like smelling good food without tasting it

Just like everything else in usability, the Usability Approach seems so straightforward after it’s pointed out.  “Of course this is the best approach to designing usable things, silly.”  Yet, time and time again, I see people underestimating the value of including users in the design process.  They simply go charging blindly ahead down the implementation path without consulting with the people that will actually use the site.  Don’t be one of these people.

Undoubtedly there will be people who read this post, nodding in agreement the whole way through, that immediately go back and disregard the advice.  This post is not intended to be a neck exercise.  It’s great if you have found some truth in this, but don’t just believe me; go and try it out.  Judge it based on your own experience.

Resisting the Usability Approach

Why do people resist?  Here are three of the most common reasons I hear:

1. We don’t have time.

Reading this post has taken you as much time as it will to run a few users through some basic tasks with your preliminary sketches.  You made time to read this post; make the time to really make use of it.  Notice that I said “made time” instead of “took time”?  It’s all about priorities.  When somebody says they don’t have time to do something, they really are saying “it’s not a high enough priority for me to invest my time doing that.”  Which leads to the next common reason…

2. It’s hard to calculate the return on investment (ROI) of usability work.

I could quote Nielson’s study on how usability continues to have a very positive ROI.  But I don’t need to.  Why?  Because if you allow yourself a few minutes to do a very simple test of this process with even one user the next time you are creating a website (or anything), you will see such substantial improvements in your design that you will understand the value in this process through your own experience.  And as we all know, seeing is believing.

3. We don’t have the resources.

What resources don’t you have?  Is it the two or three people that are required to give you some feedback?  Or is it the few minutes, or *gasp* hours (if you want to be really thorough) that it would take to do this?

Ideally you’ll be able to get potential users of your site to do the testing, but if you can’t, anybody will do.  One thing that people love to do, is give their opinion.  It should not be hard to find a few people willing to give you a few minutes of their time in exchange for having an opportunity to give their (obviously highly valuable) opinions.

No, it can’t be that.  It must be the time required to actually do the testing.  Collecting feedback from users can be done in a matter of hours (from start to finish).  How many hours do you waste every day doing things like checking Facebook, reading tweets, reading the news, etc.?  And what is the potential return on those?  Do you do these activities during your “work time?”  Need I say more?

Seeing is Believing

I can’t be more straightforward than this:  it’s easy, do it.  If it works for you (and I’m confident it will), keep doing it.  If not, consider it a science experiment, and a valuable educational experience that cost you very little.  Be your own judge.  You’ll see the results.

About Jonathan

Following an undergraduate degree in computer science, some worldly adventures, and years in the software industry, I find myself back at school getting a masters degree in Human Computer Interaction. And I love it.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *