Interaction Design from Thinking and Making

Fantastic case study on ATM design

Austin Govella — Thu, 05 Jun 2008 17:30:09 GMT

Michael Beavers has started a new site called Physical Interface "about the messy middle between computer-human interaction, physical products, urban design, architecture, urban planning—and a great user experience".

The first article, by Holger Struppek, is a fantastic case study on the new interface design for Wells Fargo ATMs. Holger reveals some of the behind-closed-door design thinking and constraints that drove the new design.

It's a really interesting insight into how other teams and organizations work. Go read it!

(As a side note, Physical Interface runs on the wonderful PublicSquare content-management system developed for Boxes and Arrows. That's the same system I'm using to power Thinking and Making. It's probably the best CMS I've ever used.)

A common language for interaction design

Austin Govella — Wed, 28 May 2008 20:28:32 GMT

Working on a way to get a group of people to annotate simple and complex web interactions in a similar/common way. There would seem to be two parts to this kind of Sisyphanic exercise.

The group would need to communicate using a similar format. The medium constrains the message so there would be fewer ways to be different. More of the same.
The group would need to communicate using a common vocabulary.

This is a quick sketch at a common vocabulary for talking about interaction design on the web. It assumes several pieces are required to talk about most interactions.

You have an object,
A user or system triggers something,
The system has a response,
That response has a target, and
Transitions usually make it better.

So, for each of those five steps, I've collected a common vocabulary.

Common triggers for web interfaces

A trigger happens when a user or system does something that is noticed by another user or system. Web interfaces have a collection of common triggers.

On mouseover (and/or on focus)
On mouseout (and on blur)
On (left) click
After a time interval

Common triggers for form elements

On focus
On blur
On submit
On reset

Page level events (more rare)

On page load
On page unload (when we leave this page, but before we see the next one)

Special interaction events

On resize
On scroll
On mousedown or mouseup
On right click
On double click

Interface responses

When a trigger is, uh... triggered, the interface really only has a few responses.

Show something
Hide something
Change/update something
Go somewhere else (change the page)

Response targets

When the interface responds, it does so via an object on the page, its target. We have several possible targets.

An element (displays in the page)
An overlay (displays over the page)
A lightbox (displays over the page, modal)
A popup (displays in a new browser window)
An alert (alert display in browser, modal)

Transitions

If users need to know the interface has responded, it's often important to highlight interface response. (Norman and Cooper have frameworks for when and what you should communicate to users.)

On the web, a common set of transitions has emerged.

Fade in or fade out
Slide in or slide out
Enlarge (from something or nothing)
Shrink (to something to nothing)
Highlight
Play sound
Shake

It's often good to combine transitions. For example, if an autosave is successful, you might fade in a highlighted confirmatin message. Similarly, 37 Signals popularized the "Yellow Fade" technique where a highlighted confirmation message appears before the highlight fades away.

Using the vocabulary

Use is pretty easy. Annotate as usual.

Let's say you have a header. You would annotate interactions for each applicable trigger (much as you probably do already), but you make sure to use the above, approved list of words.

So, for our header, on mouseover change the header to a highlighted state. For our header (element), on mouseover (trigger) change (response) the header (response target) to a highlighted state.

So, there's no rocket science here. The benefit would be everyone communicates the same way about the same things. Not tested. The next bit is about a common format.

Agile + UX: six strategies for more agile user experience

Austin Govella — Wed, 07 May 2008 04:30:19 GMT

There's a secret lie lurking behind agile methods. 'Agile' suggests fast. At Comcast, we're using a scrum process that throws around terms like "team velocity". And the agile literature does promise better, faster. It's no wonder that when organizations hear this, all they hear is faster. Of course, the secret lie is that agile isn't necessarily faster. It's driving tenets are to help people stay happy and create better software. The namesake agility is meant to allow teams to change product direction every few weeks instead of every six months. How do you make these kinds of agile changes? You test: Build, push, evaluate, tweak (rebuild). Unfortunately, the iteration cycle, "agile", and phrases like "team velocity" were confused with "fast". The biggest problem with lots of user experience methods is that they're not necessarily fast. They're not necessarily slow, but they do take time. At Comcast, even though user experience work is seen as valuable and important, its also seen as a slow point in the process. How do you handle this? You have six options.

1. Synchronize UX with development

My previous post on parallel workstreams touches on this. You run a UX sprint ahead of the development sprint. You figure out what dev will work on next sprint, and you work on that stuff this sprint.

In the parallel workstreams post, I go over some of the problems and realities you see with this approach: parallel workstreams, more UX than fits in a dev sprint, etc. (Check out that post for more detail.)

2. Separate modeling from design

Design doesn't really take that long. Most of us are cranking on problems we've seen before and solving them in ways they've been solved. Most of the design is using documentation and discussion to -- virtually -- walk through the product and make sure it works the way users, developers, and the organization expect.

With a good team of smart, happy people (i.e. an agile team), the design is easy. Modeling -- not design -- is the part that requires thinking and synthesis and time. You need a good model for your users, for your business, and for your interface. Don't confuse models with requirements, because they're not the same. For Fancast, the user model includes information like people think of TV shows more than they think of episodes. (You're more likely to search for 'Seinfeld' than you are for 'soup Nazi'.) These kinds of models frame how the team thinks about how to solve its various problems. Models suggest requirements because they suggest how you should think about the problem. If you can do your modeling up front, then you don't have to do it during the sprints, you can spend your small time on the fast bit, the design.

3. Design literacy

If there's not enough of you to go around, but you still need going, then you need more you.

Every team has a certain design literacy, a certain level of experience and maturity designing stuff. (Jess McMullin covers this really well.) Essentially, user experience practitioners are really, really, design literate. If you don't know an answer, then you know a method or where to look to find it. The more your team knows about user experience and design, the less they need you. This is a good thing. Leave good books laying around. When you make a recommendation explain why. With a good team of smart, happy people (i.e. an agile team), they'll pick the basics up really quickly. After all, it's not rocket surgery. Once the rest of your team can handle most things by themselves, it's like there's more you, and you can focus your expertise on the more wicked problems.

4. Collaborative Design

Agile is all about build, push, evaluate, tweak. Oddly enough, design is all about build, push, evaluate, tweak, except we do it in our heads before we bother coding it.

Everyone digs this, so take advantage. There's no reason to do your virtual build, push, evaluate, tweak by yourself. In fact, it's better for the team's design literacy and easier to share your models if you don't. Get in the same room and sketch, point, talk, and iterate. By the time you're done with the conversation, every one has a good, consensual idea of what you're building. In the end, a consensual idea is why you document. If everyone leaves with the same idea in their heads, then the last reason you have for documenting is recording details that might fall out of people's heads. Things like how a list is ordered, or what happens if there's an error. As above, you can spend less time on basic documentation and focus on what documentation is good at: remembering things you won't.

5. Lower fidelity

Documentation is still a good thing, but the more details you have, the longer your document takes to produce. Wireframes are the best example of this. A well-annotated, high-fidelity wireframe for one page can take a day, easy.

If you need to spend less time, use fewer details. If you've collaborated on the design, and you've helped improve their design literacy, then your team won't need all the detail. Strip your documents down to the basics and only deliver what people need. Make your wireframes more like page description diagrams or block layouts.

6. Book your time

Agile developers don't really pretend to code faster. That's silly. But they're fanatical about estimating how long something will take and exactly how much time they have. They're clear about their limits.

In fact, that's a clear benefit of agile methods. The extreme focus on a small sprint's worth of work means its easier to estimate, track, and communicate changes to your timeline. If it's going to take you 10 hours to work on one feature, then be clear about that. Book your time the way the development team does. Use their systems and their language. Use story points, tickets, and time tracking. Only commit to what your estimates say you can commit to. If something starts to take longer, communicate the change in the timeline. The agile system manages this (by bumping lower-priority items off the sprint).

Become agile

Obviously, these six strategies are not mutually exclusive. In fact, they work best when pursued in parallel. The crazy thing is, in retrospect, they're kind of the obvious application of agile principles to user experience design. They don't necessarily make you work faster, as much as they let you work in a more agile way.

There's one more strategy for working better with agile development teams, and it involves reframing the way the product and development teams perceive product development: have agile become UX. But that kind of design mumbo-jumbo requires a separate post. Maybe later :-P

Practical prototyping: 2008 IA Summit Panel

Austin Govella — Thu, 10 Apr 2008 06:57:06 GMT

Sunday April 13th, I'll be moderating a panel on Practical Prototyping featuring Chris Conley, Anders Ramsey, Todd Zaki Warfel, and Jed Wood. They plan to show and talk about a range of actual prototypes, and it looks like it will be really interesting.

Presentation Info

Panel: Practical prototypingSunday April 13 2008, 1:30 - 3:00PM

Presentation description

Prototypes are a great way to involve customers early in the design and development process. With the decreasing barrier to entry and an increasing availability of tools today, like Flash, Fireworks, iRise, Expression, and an endless supply of JS/AJAX libraries prototyping should be in every interaction designers’ toolbox. So, why isn’t prototyping as common place in software development as it is in industrial design and architecture? The failure to include prototyping is rarely due to lack of skills with the tools, but instead naiveté about the kinds of prototypes to make and how to use them productively with colleagues and users.

This panel brings together a seasoned group of practitioners to discuss various methods for prototyping with a focus on why we don't prototype in software as much as we should and why we should be doing it more. We'll also discuss what's available today that makes it more accessible and easier today than it was a few years ago (e.g. JS/AJAX libraries, tools like Expression, Flash, Fireworks, iRise) and how to make better decisions about picking the right kind of prototype for the job.

Who Should Attend

Information architects of all levels will benefit from this panel discussion, especially those who are currently dealing with, or planning to deal with Rich Internet Applications or DHTML heavy applications of any kind.

What You Will Learn

When you leave this session, you’ll be equipped with a broader understanding of some of the more commonly used toolkits, reasons why you should be prototyping, how to prototype better, and a greater understanding of some of the pitfalls of prototyping.

“...quite delighted by small gorillas...”

Austin Govella — Mon, 17 Mar 2008 15:09:03 GMT

About a year ago, violin virtuoso, Joshua Bell, played the street musician, occupied a Washington, D.C. subway station, and gave brilliant performances of classical music.

The Washington Post asked about the "moral mathematics of the moment"?

Each passerby had a quick choice to make, one familiar to commuters in any urban area where the occasional street performer is part of the cityscape: Do you stop and listen? Do you hurry past with a blend of guilt and irritation, aware of your cupidity but annoyed by the unbidden demand on your time and your wallet? Do you throw in a buck, just to be polite? Does your decision change if he's really bad? What if he's really good? Do you have time for beauty? Shouldn't you?

Gene Weingarten, "Pearls before breakfast", The Washington Post, April 7, 2007. Everyone seemed to ask or answer the same question: why didn't anyone notice the virtuoso? The Washington Post nails the prevalent assumption: "He is the one who is real. They are the ghosts." Art has been deified so that we expect the entire world to stop and listen. I'm not sure that's the purpose of a street musician. Seems like they're only supposed to make our time more pleasant.

Design, Art, and Performance

We think because "Design" has a significant impact, it should receive a significant response. People should notice. But that's not the case. And there's no logical reason why anyone should.

A photo from Alexis Lloyd's 'Concrete Jungle' street art project.

Alexis Lloyd glues miniature animals in odd places around the city. Anne Galloway calls Lloyd's work a street art installation. And then she describes it as interaction design:

First, unlike most work in [interaction design], it doesn't cater just to the technological elite. In fact, I imagine all sorts of gadget-less people quite delighted by small gorillas swinging from fences, and rhinos storming over parking meters. Secondly, it does not require any direct interaction. While walking down a busy urban street, to simply catch a glimpse of a tiny lion stalking a tiny herd of antelope is enough to change one's frame of mind without demanding immediate action.

Anne Galloway, "Reimagining the everyday", Purse Lip Square Jaw, March 13, 2008. The real question about Joshua Bell's performance, or any performance, isn't about whether anyone notices. The real question is whether anyone's day is better. That's the first question: Are you leaving people better off than you found them? The next question: does your audience want to notice? There are two take-aways. First, anything you design should be as unobtrusive as possible, unless your audience wants it to be. Second, next time you whinge about business or development not "noticing" the experience, stop. Why should they? That's your job. They care about something else. Do your job, and make their job easier. Always leave people better off than you found them.

Designing with patterns: Lessons from Yahoo! and Comcast

Austin Govella — Mon, 17 Mar 2008 11:00:00 GMT

Christian Crumlish and I will share design pattern lessons learned at this year's IA Summit in Miami. Christian will talk about his experience with Yahoo's design pattern library while I'll share what we've done at Comcast Interactive Media.

Presentation info

Designing with patterns in the real world: Lessons from Yahoo! and Comcast

Monday, April 14 2008, 11:45 - 12:30PM

Presentation description

Can you streamline web design and development with design patterns? Really? How?
Do patterns help or hinder agile user-centered design?
Do design patterns stifle innovation?

We’ll share what we’ve learned about bootstrapping pattern libraries from scratch and how to “extract” patterns from existing products. We’ll share stories (er, I mean real-world case studies) to illustrate ways pattern libraries can both aid and stifle innovation, how they help solve real-world web design problems, and how they support rapid production of common IA deliverables. We’ll bask in the glow of the “magic triangle” of patterns + code modules + wireframe templates that enable rapid prototyping and agile development, and then cower in the miserly shadow of the “iron triangle” of fast, cheap, or good. How to structure and maintain a pattern library? Check. We’ve got you covered. How do you trick… er… get people to adopt patterns and help improve them? What tools help you do this? Are wikis the answer? How far can you get with an open-source CMS, a boatload of other people’s mistakes, spit, baling wire, and wing and a prayer? To find out, come to Austin and Christian’s presentation where we’ll share what we’ve learned, what works, and what we will never ever do again at Comcast and Yahoo!

More information

You can find more information about the 2008 IA Summit at the conference website.

Fancast officially launches

Austin Govella — Thu, 10 Jan 2008 16:11:00 GMT

Tuesday at CES, Comcast officially launched Fancast, a next-generation, personalized, cross-channel entertainment website.

So far, work on the project has run everywhere from ecstatic to calamitous, but it's definitely been one of the most interesting sites I've worked on.

But Wired rewards all the sweat and tears in one sentence: "Fancast turns out to be surprisingly well-designed -- and useful enough that the biggest complaint is likely to be, what took so long?"

Personal information spaces, diagram by Dan Brown

Austin Govella — Tue, 22 Feb 2005 17:53:00 GMT

Personal info space diagram analagous to commmunication/interaction model: the users mental model (personal information space) interacts via an interface (the task) with external actors (the external information supply):

http://www.greenonions.com/index.php?p=80