March 03, 2004
Tips for designing task based interaction flow
We often get asked for advice based on stuff we've done. I get asked about designing online registration and authentication systems, because I spent a good chunk of my time at 'The Corporation' designing an equivalent to Microsoft's 'Passport'. This log entry captures some general pointers I mailed someone the other day.
- Always remember, nobody wants to do this. It’s nothing but a pain in the backside they’d rather avoid. Forms are boring. Make sure the tone is polite and not overblown nor curt.
- Do not use jargon or insider terminology, this just adds frustration to the experience of the unenlightened majority participating.
- People don’t trust this interweb thingy with their personal data. They’re sure big brother can infiltrate it and come kidnap their kids. So, be transparent about how you’re going to use the data and ensure that the system is secure and solid in behaviour (if it behaves "all flakey", you’re not going to engender a sense of trust in the user). The Corporation's Single Sign On ensures users can get at and delete their data held by the The Corporation at any time after they sign in.
- Show progress (how much have I done, where am I now, how far have I got to go).
- Make the process visible in the interface (so you can see what’s involved at a glance and it doesn’t feel like you’re going into a black hole never knowing when the end is nigh).
- Break the task into chunks (the perception of complexity is augmented by long forms and you can make long forms seem short if you break it into pages of bite-size sections... It’s all psychological).
- Validate for correct data entry at the end of every chunk, not at the end of the process.
- Wherever possible make the process navigable back and forward so people can fill it out in whatever order they choose and explore what’s coming up. This isn’t always possible, but it’s an ideal to strive for.
- Provide lots of contextual help in the interface (any ambiguous terms should be accompanied by a ‘What’s this?’ link)
- Be consistent in layout. People don’t want to miss anything. If you have every widget in a consistent place, they’re less likely to miss something and get more frustrated when an error message appears.
- Wherever possible, break errors out onto a new page, so that it does not look like you’ve just come back to the same page after pressing ‘next’.
- Errors are usually not the fault of the user, but the fault of the system for not understanding the user or allowing them to input how they would naturally. Make error messages sound that way. “This system is stupid and only understands one way of entering calendar dates... Sorry. Could you do it like this please: DDMMYYYY.”
- Make the system forgiving. Allow people to enter info, play with widgets etc to work out what they do without forcing them to pay the consequences for their actions with irreversible process steps. This is about allowing learning through trial and error.
- Use widgets consistently and don’t be weird with the interface. This is sensitive stuff. Make it predictable and safe feeling.
- Indicate direction of the task flow within or around buttons. Next should point to the right. Back to the left. Cancel shouldn’t point anywhere but rather have a feeling of finality to it.
- Confirm when the process is complete with a closure page telling them what they can expect to happen next, or what they can do now they’ve endured this painful process.
Posted by Ant at March 3, 2004 10:07 AM
| TrackBack
Comments
If a teacher just want to design a task before class to help students obtain the goal of this lesson, what will she do? I mean if there are some theoeies or procedures to design a task.
Posted by: yueyaoyao at March 25, 2004 12:51 AMPost a comment
