Carlo Pescio - blog

How do we move away from corporate thinking and toward users? The question is quite broad and would (will?:-) require several postings. Here are a few suggestions, straight from my everyday experience:
- Stop thinking "features" and "information", think "goals". If you design your application asking yourself "what set of functionality do we need" or "what is the information architecture here", you're doomed. You'll begin thinking like a developer, or like your company, or both. Instead, ask yourself "a user just started my application. He wants something, right now. What's that?".
- Use cases may help [a little]. Use cases help as long as you focus on why would a user go through that use case, that is, what is the real, ultimate goal. Thinking in use case format brings up some issues too early for my taste, but it's generally better than thinking about "information" and slightly better than "feature". For the record: a toolbar like "banking, credit, trading, ..." is not about goals and is not about services. Is about information architecture.
- Involve the user - but be careful! Although some approaches recommend a strong user involvement, and although we must certainly talk to users a lot, having a user dictating the interaction is just plain wrong. Unless, of course, he's the only user of your application. This goes in pair with a longstanding debate on requirements (see, for instance, "Eureka! Why Analysts Should Invent Requirements" by James Robinson, IEEE Software, July/August 2002, also available online from the author's website). I'm strongly on the side that we should take the time to learn the real problem from the users and then invent the requirements.
- Read at least some classics on HCI. You should at least be familiar with Schneiderman's Eight Golden Rules, like "Design dialogs to yield closure". Of course, you'll have mastered the concept when you'll learn when closure is desirable (most times) and when is not!
- Understand the difference between short-lived corporate applications and long-lived, large-market applications. The dynamics are totally different. Short-lived applications can be created from "user's requirements", that is, by having the users asking for a [quick] solution to his perceived problems. Users stories, or use cases, can be fine here. Long-lived, large-market, possibly embedded applications can't be built on the basis of a few users asking to solve what they believe it's their problem. It's our job to understand the real problem and to see how technology can actually go and solve that problem. You can't expect your users to innovate your products.
- Don't optimize the interaction for the worst case. The most frequent reason to make 99.9% of your users unhappy is that the interface is optimized for the 0.1% extreme users. An easy criticism to my simplified interface for internet banking is: what if I have more than one account on the same bank? So the programmer starts with one more page where you have a list of accounts, or a list of credit cards, or a list of whatever. Don't. Optimize for the 99.9%. The 0.1% must be able to work with your product (that is, your application must handle the worst case), but don't make the extremes drive the interaction. Of course, in some cases the extremes are a valuable niche, in which case they probably deserve a different application!
- Stop thinking "User Interface"! I've got the idea from an interesting (although somewhat conventional) paper, "The obstacles and myths of usability and software engineering", from Ahmed Seffah and Eduard Metzker, Communications of the ACM, December 2004. They say that talking about "user interface" gives the impression that user-centered design and usability engineering are "only for decorating a thin component sitting on top of the software", and I largely agree. While I understand the importance of building business objects detached from the (I'm gonna say it! :-) user interface, those business objects must be discovered by designing the user interaction, not the other way around!
- Learn the personas approach. It's still the best game in town. If you find you can't play that game, please leave interaction design to someone else in your team. Quick self-check: if you can easily program your VCR to record your favorite show next week, and you either believe anybody can do that, or that they should simply read the manual and learn how to do it, you have a long road in front of you before you can be an effective interaction designer (sorry :-).