October 2006
Chapter Business
November 14th is World Usability Day, and we're still moving ahead with activities. We're crazy enough to still be accepting ideas, and Chris may end up in a superhero costume! We also have a website at www.upaboston.org/wud that contains descriptions and materials for all our local WUD activities. Anyone who is interested (e.g. educators or other folks planning WUD activities around the world) can use these.
Job List:
- Raytheon is looking for a HF engineer.
- Autodesk is looking for interaction designers to work on their Revit product.
- Bill Barnet, a jack of all usability trades, is looking for a position ideally "somewhere along the red line".
- John Dozier has a strong testing background but is looking to broaden his experience in his next role.
Presentation
As a former UI designer and user experience professional at Microsoft, Greg was able to identify the differences between users and developers, and some ways that we as designers might bridge that gap.
Users are concerned with one thing: getting the task done (or what they will do with the final product). Developers are concerned with computer science, abstractions, and objects (i.e. the ingredients of getting the task done). These are naturally opposites.
Greg suggested that one start by having a developer find and know how an actual user interacts with their product. He thought that's sometimes more effective than personas.
Developers tend to abstract too early. User's tasks are not abstract. They want the duct tape to get it done (i.e. the practical solution to a specific problem).
In creating XP, the idea was to use goal/task centric design, or designing with the high level, "what does the user want to accomplish" question in mind. Its intent is to make the mental map of tasks to objects optional for users.
An object is a tangible thing (a noun). We want to create inductive rather than deductive (where users have to "connect the dots") UI designs. Icons are objects and they only communicate so much. There are few limitations on screen real estate (on a regular PC) nowadays, so we can be clearer.
Developers understand inputs/outputs. When talking to users, they need to ask users questions to which they know the answers, and don't ask them what they don't know or what they don't care about. If there is no input in a design, we're presenting information but not asking for anything. IF there's no output, we're not telling users what the widgets are for or what they should do with them.
Greg gave us 9 tips for developers creating UIs-common mistakes if you will (see the slides), ranging from "users don't understand a difference between single/double clicks" to "don't use acronyms".
We should design for the 80%, but note that the 20% are often really loud. One should use a safety valve to ensure the 20% can do things the "old way". The cost for doing this is low; the cost for not doing it may be high.
We need to move away from database oriented thinking to task centric thinking, even if most or all of the information comes from a database. At PC connection for example, the goal might be finding a good deal on a laptop. Users probably care about comparisons, recommendations, etc.
Windows and Web designs are converging. We should be sure to use "feed forward" (like "feedback", only give the person what to expect before they get there).
Questions
Q: Can you go too far towards task-centric design for novices and annoy power users?
A: Of course. Everything requires balance.
Q: What is a good rule of thumb for handling novices/experts?
A: Use the safety valves for people who have gotten used to your old interface. Note that only some people seek ways to become more efficient. So have shortcuts, favorites, customization to optimize for these users.
Q: What can you say about the transition from novice to expert?
A: Just because a user progresses from novice to expert with one feature doesn't mean they're an expert everywhere. There's no magic cliff where this happens.
Q: How can you convince developers and the business that this is important, given schedules, etc.?
A: Let developers do it the short way and then have them observe a user interacting with it. They'll take it personally (it's their work after all) and want to make users successful. For the business, if 10 features are there but no one uses them who cares. You'll save money on smaller, appreciated features.
Q: Any advice on consistency?
A: Users don't notice consistency or consistency errors, but it's important from a design aesthetic standpoint. It also depends in cases where it creates muscle memory (e.g. flipping location of OK / Cancel buttons probably is bad). Be consistent when you can.
Q: How would task driven design work with an application like Photoshop?
A: The model doesn't always apply but can make sense in some places. For example, limit what is shown to a task of "selection" or "filling in" or "applying affects". Tool based applications are more difficult.
Q: In PowerPoint a wizard gets you to a template but then it doesn't provide any guidance on how to proceed. Can you extend this model to further guide a user?
A: Again, PPT is a tool-centric application. In Office 2007, there's more of a task/goal centric model. You can't apply this model to everything, but it's useful to try to change your way of thinking.
Q: What can you do for people in the 20% who'd rather the application adjust to the way they want to do something (rather than the way the designers of the application want them to do it)?
A: You need to ensure you really have the 80%, based on project management and user testing. You want to make sure you're not really 50/50. For the 20%, depends on how vocal they are. You can parameterize rather than hard code, so that people can plug in or plug out. Command lines are good for highly advanced users. You can encapsulate for third parties to extend your application for specific domains.
Q: How do you extract the high level tasks?
A: Based on the product goals and talking to users. You need to identify the core of the application, or what's valued. There's no specific methodology, though you can encapsulate smaller tasks or use card sorts.