Thursday, April 30, 2009

How To Start Designing A Multitouch Interface

This morning, Bill Buxton published an interesting piece in Business Week that effectively said that it is incredibly difficult for engineers to become good designers (and vice versa), so you should budget for a really good, highly experienced designer (like myself) for a lot of money. While I obviously agree with this statement, it's a big business approach to software...and it's often inappropriate.

In the current economy, using a high end designer for small projects is frequently untenable. Recently, several engineering teams have asked me to teach them how to think through design problems for themselves, so that they can better utilize existing OPEX budgets.

Many of these engineers have found it useful to start by breaking the user experience down into three basic chunks: Graphics, Input and Feedback. It would be great to get your feedback on additions to this list.

Please, check out Bill Buxton's insightful response/rebuttal to this piece. As always, he has smart things to say.


Graphics

A graphics strategy for multitouch should make it easy for users to think through:
- What the computer is doing

- How to navigate from the current application state to all of the user’s goal

- How to navigate between the windows/content of an application


- How the controllers are conceptually grouped


- If content is highly freeform (like in a Surface Scatterview) how to organize it

into a recognizable structure, like a grid.

- How many views/windows are open and how users got to the current application state.


A good graphics strategy is made up of two components:

Layout:
How the interface hierarchizes and prioritizes the relative (and often changing) importance of content and controllers

Example: Time sensitive content may get larger and eventually take over the screen when it becomes critical.


Metaphor: How users predict what a controller will do. A good "universe of metaphors" should think through how the way each interface element looks and animates communicates what it does, what content effects and how to undo it.

Example: One of the most frequently cited metaphors is Apple’s trashcan.
It makes sense because it echoes a real-world experience. The more controllers and interactions mimic the realworld…through physics and meaning, the easier it will be to intuit how the device will respond.



Input
Inputs are sensor or other data that impact the interface. An effective input strategy has two components:

User Generated Events: How users control the device
Waving the device in the air, pressing a soft button, pressing a hard button

Examples:
• Input multiple predefined values – GUI equivalent:Radio buttons
• Choose predefined values – GUI equivalent:application icons, buttons
• Input highly customized values – GUI Equivalent:Command line searches
• Group content/Remove content – GUI Equivalent:Drag and Drop
• Choose values along a range – GUI Equivalent: a slider, a color picker


Contextually Generated Events: What the software understands about the outside world

Examples: Changes in user, mood, noise-level/mood in the environment



Feedback

An effective feedback strategy informs users that their task has been accomplished and that they are progressing toward a desired objective.


Examples: The color of a button might get brighter. There may be a noise. There may be a task path that progressively lights up.

Feedback can be broken up into two basic categories:


Device Behavior: How the software/Device responds to input, conditions and events
Examples: The devices rocks, shakes, flashes, etc.

Device Conditions: The state of the device and software
• Examples: Time, power, processor load, modes, users online, etc


Hope this is helpful. Courteous comment and additions are always appreciated.

3 comments:

  1. Ahhhhhh - actually, I didn't say, "engineers will never understand design." Just the opposite, in fact. What I did say was that it was just as hard for an engineer to become a competent designer as it was a designer to become a competent computer scientist. Your list is a great idea. But in the interest of balance, perhaps it would be a good idea to have some engineers start a parallel list of the fundamentals of computer science for designers. That will help develop better literacy on both sides. The main problems that will likely result will be due to one group confusing basic literacy with professional competence. The main benefit is that the two communities will be able to communicate all the better. All the best. Bill B.

    ReplyDelete
  2. @ Bill,

    Awesome post. I am flattered that you read this blog. It seems that we are in agreement that the mythical "devigner" is a rare beast indeed.

    If you can recommend a computer scientist partner for this exercise, I would be really excited to put this conversation in front of the multitouch community!

    All of us would also really appreciate your additions to the design list and thoughts about how to manage the fundamental power imbalance between designer and developer: it's a lot easier and cheaper for a developer to play designer than the other way around.

    Much Thanks.
    Jonathan

    ReplyDelete
  3. @Bill,

    I modified the blog post to link to your comment and adjusted my comments to more accurately reflect your intent.

    As mentioned, I agree with your viewpoint, though I question the economics of it for small projects.

    Always Inspired.
    Jonathan

    ReplyDelete