Friday, July 10, 2009

On Creating Effective Web Interfaces

At EOL, we've been asked to implement some new features that we (the developers) didn't like. They didn't seem to adhere to web-standards, didn't look particularly good, and didn't really seem to capture the problem (caveat: as we see it) elegantly.

This sparked a discussion (healthy, not heated) about how we could best approach design and web usability as we add features. Another developer wrote a blog-post about it.  (...internal-only; sorry, no link for you!)  I felt compelled to talk about the same subject myself and field some ideas.  His post was all well-formatted, edited, and technical.  Mine is casual and sloppy.  So it goes.  ; )

So what's the problem?

We're using Agile methods, so the proximal problem--which we are already trying to address--is that the temptation is strong to just "get something out there".  Users can respond to it, and we can quickly adjust our approach to build something they will like better.

This has a few negative consequences:
  1. The code gets ugly and risks leaving remnants of old styles when it changes.  Have a look at our CSS, for example.  :(
  2. I think users can get scared away.  At least for me, I know I've tried to use some feature of, say, Yahoo! Mail, hated it, and never looked at it again.  ...They may very well have cleaned things up later, but I don't care to look.
  3. User feedback tends to... well... suck.  In my experience, they'll ask for things that actually result in clutter.  Also, it's only the squeaky wheels that get heard, and their needs may be vastly different from the majority.
  4. There is a big but poorly-understood difference between a feature that's easy to use and one that is "intuitive".  The latter implies that a newcomer can step in and use the tool... well... intuitively.  This is great!  But it often creates an interface that wears on your quickly, or ends up something you hate over time.  Photoshop's clone tool is a good example of a tool that's easy to use, but not at all intuitive.  It's important to know which is better for your problem. I think that user-generated feedback generally comes from users who have tinkered with an interface for something on the order of minutes.  They're talking about intuitive use, not easy use.
...There are probably others, but I'm getting bored.  ; )

The core problem, I think, is that we really need someone skilled at web interfaces.  But we don't have the money to add someone to the team to do this, and everyone currently on the team is too busy to pick up the skill and/or apply it at the expense of their current duties.

In short, we are left with only one option: establish some guidelines by which we can do the best we can, on our own.

To that end, I like the idea that my associate mentioned (interestingly enough, by quoting yet another associate of mine): a list of usability questions that can be asked to gauge whether an interface works or not.

...I think this is a reasonable start.  That said:
  • I don't know who we should ask these questions.
  • I worry that we'll end up with design-by-committee interfaces, which usually suck.  Ideally, I hope that design can be limited to two people on any given feature.  ...Ideally-ideally, the same two people on every feature, to maintain consistency.
  • Nothing in the questions mentions web standards/best-practices.
  • I worry that this is going to take up more time than we have, and breed frustration at the slow implementation of new features.
  • I think the questions are good for measuring usability, but there are other concerns, such as intuitive-vs-easy, elegance, and the "message" conveyed by each feature.  I hope we can add questions into the mix so that these things are considered.
  • I think it's worth investing two or three people's time over a day or two (each) to research usability, and contribute to the "checklist" that we're building.  This could include best-practices, design methodology, questions to ask, and the like.
I could go on.  This is a fascinating subject with many different possible solutions.  ...Sadly, I don't think any of them are even remotely as good as "hire an expert".  : (

2 comments:

Anthony Goddard said...

Well, at leas you guys can rest assured you're not the only ones in web developer land with this problem ;)

I think one area that has been looked over is the willingness of the community at large to chip in what they can for EOL. I am sure there are designers out there who would love to give you their professional input, ex gratia. If they can be engaged, it might delay (though probably not negate) the need to hire a full time designer.

dimus said...

There are two questions here, attractiveness of design and usability of it. Attractiveness is more about underlying html and css, usability is more about underlying logic.

I wish we at MBL could establish usability testing environment sooner than later, and consider its results as seriously as we should consider results of code testing.

I will bet a dollar that the first round of testing with be shocking for each and every project we work on (EOL, Life Desks, GNI etc.)