In Valid Logic

Endlessly expanding technology

Usability is design

Today, both Rob and Scott blogged about designing for usability compared to designing for scalability/performance.  I I completely agree with Scott's opinion, that developers are too concerned about the code instead of the usability.

Scott talked about how in the Programming Manifesto, there is no mention of usability.  In my opinion, usability design and architectural design are often seen as two separate things.  That is way off base.  Usability is a part of all design.  Usability should always influence architecture.  Usability should always impact your coding.

One place where I would make this point is with something like error handling.  Error handling is likely in anyone's list of "best practices".  However, it is also very important for usability design.  Say you are connecting to a remote web service with user supplied credentials.  There are variety of types of errors, that should be handled in different ways.  Errors should always be caught, but where?  What kind of error logging do you use, what types of errors do you log?  For God's safe, avoid empty catch { }  blocks unless you know for certain it is what is best.  What are system errors and user errors?  Say you are able to connect to the web service, where is that caught?  How is it logged?  What does the user see?  Say the credentials are wrong, how is that handled?  Say there is a serialization error in the transaction, how is that logged?  Can it be recovered from?  What is the user told?

Your code should always be designed around providing a solid user experience.  That means error handling, checking for null variables or empty strings, and all aspects.

Another distinction to make is what is "simple to use"?  Who is it "simple to use" to?  For starters, common sense does not exist.  Jason Jennings quoted it best in Think Big, Act Small.

"Remember, the most common thing about common sense is how uncommon it is."

What makes sense to one person does not apply to another.  What makes sense to one group of users will not apply to another.  Usability should be thought of as far as designing for your grandmother, mother, or some other non-techie user.  Usability should be designed to the context of your target audience.  If you target user is non-techie, design for a non-techie user.  If your audience is a group of experienced project managers, design for them.  What would make sense to them?  That is "simple" or "easy" for them?  I used to work on a legislative cost estimating database.  This was pre-Web 2.0, but post-Web 1.0.  The application was no golden gem of usability, however while designing the actual pages, we spent literally a full two weeks in all day usability meetings.  We'd focus on:

  • Who is going to see this page?
  • What read-only data is most important to them?
  • What editable data is most pertinent?
  • How should pieces of information be grouped?
  • How should the various groups be arranged?

We milled over all of those aspects for each and every page in the application.  The people using the application were going to be living it.  Non-techie users aren't going to be using it, so designing for them would be counter productive.  We would go over the pages in the morning session, then after lunch I would scamble to make the changes we'd discussed, and then go back for the afternoon session with the revised screens to continue going over them.

I don't remember where I read it (couldn't find it), but someone had said that coders make for bad testers because coders will cope with the bugs.  They can figure "ohh, I'll get to that later" or find some workaround to it that works for them, but no one else.  The same is true for usability.  Your common developer is not necessarily the best for usability design.  If your audience is a non-technical user, then a technical user developing it won't exactly know the best way.  How can you work around this?

First, a usability conscious developer should be able to step outside of their context to find the flaws in their design.  Use the software!  Sit back and take a second to think about what makes sense, and what doesn't make sense.  Second, get it out to multiple people, technical and non-technical.  The more eyes the better.  One key to look for is people who can look at it critically and make some suggestions as far as what is wrong, or what might be better.  Finally, give it time.  It will take many iterations.  Sound usability does not happen overnight or on the first iteration.

A final point is that usability design fits in perfectly with agile development.  Usability takes time.  Come up with something, send it out to a few people to try out and solicit suggestions.  Discuss them.  Try it out.  You may accept it, you may go back, or you may try something else.  The point is, get something up early and as you develop, continue to address the usability.

Both Scott and Rob make totally valid points.  At Telligent, we are guilty of many usability sins.  We used to be all about the code, however as Rob says, designing for usability is much harder.  It is difficult to change your mindset and turn things around, however it gets progressively better over time.

.NET world very big about the code and methodology.  Why is the iPod a golden gem?  Why is everyone talking about 37signals?  They focus on the user experience, and they don't necessarily neglect the background technology, but they recognize what is most important to their customer, the target audience.

(In case you were wondering, I have been starting to make my main points bold.  I am a huge fan of Jeff Atwood's blog, and I like how he does it.)

Thursday, November 02, 2006

 
blog comments powered by Disqus