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:
- The code gets ugly and risks leaving remnants of old styles when it changes. Have a look at our CSS, for example. :(
- 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.
- 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.
- 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.
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.