Entrepreneur, executive, and investor; octo-dad; former Googler, now VP Product at

Posts from the Interaction08 Category

[The intro informs us that Antenna Design is a boutique firm–five people–that’s been around for many years and has won a large number of awards. Note: this session was more of a slideshow of Sigi’s firm’s accomplishments and doesn’t really come across well as a blog entry. I only had my iPhone camera and it didn’t work well in the lights.]

Interaction and Intervention

We have been working on a number of very different projects, a number of them in the public world. I want to talk about our work from the perspective of interaction design, which isa ctually a very broad definition. I want to show you some of our work across both public and private sectors.

I want to talk about the notion of intervention and interaction.

Design is a form of intervention. Whenever a new device is introduced in our lives, design has to intervene between existing context, people and the new devices.

In consumer spaces, you can refuse a new product by refusing to buy it, but in the pbulic space you often have no choice. For us, the essence of design is interaction.

Interaction design is about guiding people’s behavior twoard what the “program” calls for. Many times, the product can be very pragmatic, and other times it can be more open-ended, such as the case with our exploratory products which I’ll show you.

So how do interaction and intervention relate? Design is an intervention that creates and new interaction.

I want to show you the ticket vending machines in the New York subways. We didn’t design the cards themselves, but we designed the machine interfaces:
– appropriate conceptual mdoel
– hardware-softwarte coordination
– familiarity
– fast transaction
– vandal resistance
– universal access

After the machines were manufactured, they did studies that showed that people had a real problem with them. The machines were already built, so we couldn’t change that, but we could start from scratch with the software.

We had to choose between the “soda machine” model where you add your money and then pick your product, or the “store model”, where you pick your product and then give your money. We choose the store model based on user preference–people are skeptical by nature.

We simulated a dialog: the machine asks one question per screen and everything is very clear. One of our challenges was that people wanted us to put more information on the screens so that people could complete a transaction with fewer screens. But given the broad audience, having more screens with fewer information on the screens made it easier for people to use the system.

To overcome the challenges of having to deal with existing machines with a somewhat random layout, we came up with a primary color scheme: the colors of the machines relate to the colors of the interface. The machine has been in use for eight years now and has been doing very well.

We learned that 50% of our users don’t have a bank account; they are purely in the cash economy. That means that the concept of the touch screen was very alien to them. We did some studies that showed that a lot of people didn’t understand the concept of touching the screen. So we introduced a smaller start button as a target. (You can actually touch anywhere on the screen to get started.)

You can never make assumptions about things that are so obvious that you don’t need to deal with them.

We also did a series of Subway Cars.
– change people’s attitude through design (make people behave more civilized by giving them a better environment)
– physical design affects psychological comfort
– physical “instruction”
[didn’t catch the rest oft he bullets]

[Showed some subtle touches in the design of the cars. They made a full-scale mock-up of the trains.]

We are always in the situation of creating things for situations that we don’t know, so you need to do research, build prototypes, and study how people react to them.

[Showed a dynamic map of where the train is as a way of reassuring people.]

We did the Help Point intercom, which has two buttons: Information and Emergency. The Help Point intercom looks more like a light fixture; it’s very visible, sends out a soothing blue color.

Designing the Taxi/Taxi 07
– taxi as iterface
– easy to spot available cab
– getting in quickly
– customer in control – back seat driver
– exit safely

Some people were proposing an entirely new infrastructure for taxis; we believe in incremental improvements that might actually be implementable. We addressed all the different touch points and tried to address them.

We designed an improvement to the availability signs with ultra-bright signs that make it clear when the taxi is available. We designed a way to get into the cab that is easy to press because you sometimes have your hands full. We also designed a control environment for passengers to control climate, power, light, pay, see a map, and other info all from inside the cab. We also added a warning light to the back of the cab to tell other people when passengers are exiting the cab.

We built a prototype of the availability display on a real cab, and proposed the idea of a rideshare sign that lets other people know they can share a ride.

JetBlue Self-service Check-in Kiosk [wow, I love those kiosks; great to meet the designer]

Most companies buy a kiosk off the shelf; JetBlue made theirs from scratch. We designed it to look friendly but to have a privacy design so its hard for people to look in. [The UI design is beautiful.]

Civic Exchange for the Van Alen Institute
– a public information exchange for downtown NYC

NYC Streetlife–some explorations of ideas:

[Showed a concept where the Dont Walk sign on streets shows exercises you can do while you wait; a way to use the time without wasting it and prevent jaywalking as well as a way to encourage people to strike up a conversation.]

[Showed a concept for built-in signs that people can sit underneath and write their own messages, to encourage better behavior for people who want to get their message out.]

[Showed an elevated platform on the street, accessible by stairs, for people to smoke above the level of normal people.]

[Showed bars for people to get a hug in parks.]

[Showed a plastic man near subway platforms for people to stick their gum on.]

[Showed a sort of bench that looks like a psychologists couch configuration, so people can lay down and talk, and another person can sit and listen.]

Bloomberg Displays

– Tried to create a soothly, “reductive” version of the device to try and calm down the frenzied atmosphere of the trading floor

– We created a second version with a flexible arm and adjustable display orientations to reflect Bloombergs expanding market penetration into other industries

– A slick-looking fingerprint device that attempts to be desirable and precious to help people overcome their desire to not give their fingerprint

The Door — Walker Art Center, Minneapolis

– To try and make websites appealing in the context of a mueseum with a bunch of other physical, real objects, we made this beautiful transparent door that you push. Every 15 degrees, a new website shows up on the display


– made an engaging display on the storefront of Bloomingdales all controlled by motion sensors. When you walk closely to the window, you turn on one flower after another, and you play a melody.

Whenever people see behavior in result to their actions, they attribute more intelligence than there really is. We made sure the sensors were very narrowly triggered to show people they had control over the flowers.

[She showed some kind of tower of cherry blossoms in the Carnegie mansion that also responds to movement]

Nosy Parker

– [chairs that people sit on that take pictures of the person sitting and then the pitures interact with other pictures from other chairs, trying to encourage interactions between people]

Look at the definition of Interaction Design in Wikipedia (“WIKI”); it’s great.

Three essentially elements:
– Human
– Technical
– Aesthetic

Gurus from the Past
– usability experts (Jakob Nielsen)
– tacticians
– creative geniuses
– web consultants (marchFIRST)

– Tim Brown
– Robert Greenberg
– Alex Bogusky

Teams past:
– designer
– developer
– IA
– planner
– analyst
– project manager

– [those roles blurred together]

How long is your “fuzzy tail”? I think a lot of people confuse rigor with rigid. Organizations that are rigid in process–that’s not the future. Organizations need to move towards “fuzziness”; towards being willing to fly fast and loose with process.

Websites: The Way It Was
– Usability-driven
– Creative-driven
– Tech-driven

Websites are moving towards “People-Driven” experiences now, which is where it needs to be.

[Showed a NIKE website from 1999 then some pictures of NIKE plus, the whole iPod shoe thing. He talked about how this is an entire ecosystem that involves marketing and other disciplines as well.]

Product + Experience Design: The Essence of Rich Internet Applications; this is a great paper you should look up.

What’s the role of the modern agency?
– Crispin had the idea to bring back the Rabbit, and it’s done very well
– XBOX 360 interface was developed by AKQA, a digital marketing firm
– GE/health had a creative campaign that took over times square; it was developed by frog, a design firm
– Hersheys has a theme store in NYC; Ogilvy & Mather did it, which is a tradition ad firm
– Dominoes Pizza’s new pizza builder UI is amazing; you can build pizza, track its progress, share pizza designs with other. This is a holistic experience; Crispin was behind it.

T-shaped thinking [showed a quote for 5 seconds; didn’t get a chance to write it down; talked about merging creativity and usability research]

4 Dimension Minds: I don’t consider myself an Interaction Designer, I look for people that are:
– curious
– analytical
– expressive
– sensual

I’m not concerned about having people play individual roles; I want people who think holistically.

T-shaped Team (individuals with overlapping skills), covering customer experience, open source marketing, digital experience marketing, awareness and buzz, brand design

– Redesigned NASA website and matching iPhone application.
– Vegas website for creating a Vegas social network.

[The point of the examples was that these products represented more than just a single product in a single medium yet they were created by an interaction design firm.]

Be like Leonardo Da Vinci; do a bunch of stuff in all kinds of disciplines. Also, be:
– thinkers and doers
– fuzzy agencies
– cleaner and measurable results

[Bill handed out a four page paper to accompany the talk; the slides are available at Room is *packed*, lots of people standing.]

The article I handed out is the theory; we’re going to spend most of our time talking about practice here in the talk.

People are surrounded by technology, everywhere they look, in their homes, cars, watches; people are increasingly surrounded by interfaces.

The totally cool thing about this is that these are things we are creating right now. We’re making all this stuff that people use. It puts us in an interesting spot between people and technology.

The problem is that we don’t get to go home with people and tell them how to use it. People just look for visual cues; nobody reads the manual anymore. How do people figure it all out?

[He’s showing great slides with each of these paragraphs.]

People look for visual cues that help them relate the past and things they already know with the interface. As an example, here’s an oven. My brother moved into a new house two days before entertaining the whole family for Christmas. I got to watch them figure out how to use the oven. They were looking for a “start” button. I was thinking, “How stupid it doesn’t have a start button?” I went home and looked at my oven, and there was no oven there either. They were subconsciously trying to apply their past experience to the current oven.

Language is always evolving and spreading. For example, there’s a mouse pointer and a button painted on the back of a UHaul truck. The language that we are creating is spreading out into overall language. The mouse pointer is becoming an icon in advertising, like the yellow “sale” burst.

Symbols will start with one meaning [shows 0 and I for power on a power switch]. When we know what it means, you can tweak it. [shows another switch with a 0, I, and II]. There’s no effort involved here to see that the I means low and the II means high.

[Picture of a washer with a play/pause button]. You don’t need any explanation, you know exactly what this does.

Meaning can survive a long time. [Shows a table of contents from a 500 year old book against the nav bar in GMail.] The table of contents is a stacked list of short words; you know the nav bar is navigation in GMail not because of the colors of the words or the underlines; its because of that heritage of the table of contents.

We need to see what people see and we need to seek inspiration. What do painters do? They look at a lot of paintings. What do writers do? They read a bunch of books. We need to look at what other people are doing. It’s everywhere. Like the phones, cameras, etc. in your pockets.

It can come from ATM machines, kiosks at airports, alarm clocks, and so forth. [Duh]. Inspiration from what guides us [shows Apple power cords green/orange glow]. I love the Apple power cord.

[Shows a gas pump with confusing labels]

Inspiration from what intimidates us [shows an amazingly bad Washington DC train fare machine]

Inspiration from hacking it [shows a fax machine where someone put a sticky note over a button label that says “Start” because it was confusing]

Inspiration from mixing it [shows clip of football game with the first down line superimposed]

Inspiration from seeing the language [a good dryer interface]

We create and curate this language. Hopefully we’re learning what people like and dislike and changing our designs appropriately.

The language of interaction:

– words
– icons
– colors
– shapes
– sounds
– motion
– gesture
– size
– countour

– layout
– isolation
– priority
– proximity
– repetition
– alignment
– sequence

– clarity
– perspective
– appropriateness
– purpose
– delight

[Dan goes through his slides to show examples of these above points.]

I’m here to give somewhat of an exploratory talk–these are brand-new ideas for me (hopefully for you as well). I want you to help me think through some of the issues I’m going to foist on you. Hopefully, it’s a little provocative and I want it to be collaborative. But I don’t want to get into an argument, especially between yourselves.

[Chris shows a video of two guys talking in a car. They are arguing about some banal point in a conversation, and then they suddenly get in a car wreck.] The punchline, which he cut out, was “Safe Happens” [it related to the conversation between the two guys]. This is a dramatic feature that grabs you [the video really did grab the audience with the suddenness of the wreck].

Dramatic Features in Interaction Design

[Slide of the BlackBerry.]

This is the BlackBerry, introduced the email phone. Very usable, very great device.

[Slide of the iPhone. Shows a movie of the iPhone being used by someone.]

How many people smiled when you first used Google Maps on the iPhone? [1/2 – 1/3 of the group]. If you go to an Apple Store, people aren’t neutral when they use the iPhone. They’re smiling! They’re enjoying it! There’s something different than, “Hey, this is easy to use.”

Drama — an exciting, emotional or unexpected series of events or set of circumstances.

Drama — a composition intended to exhibit a picture of human life tending toward some striking result.

The key principle here is that it resonates with people. You don’t need to explain it to them. It makes sense, it’s natural, and somehow representative of everyday life.

[Showing a video of Bill Moggriges Interaction Design video from the 80s–before personal computers ever existed. Pretty wild how far in advance Bill M. was thinking. The video is showing sketches of a system organized in a book and a video system mocking up a prototype for study. The end of the video talks about how moving images will become normal elements of the computer world thanks to future technologies like CDs, and how you will create interactions in the future that rival TV and movies and things.]

Pretty interesting to see that 20-25 years ago. [Its predictions were dead on.]

CEO of Samsung said: “Why is the iPhone so popular? We have phones with those functions…” I said, “Well, it’s because of how those functions are implemented.” Apple’s working at a very advanced stage of interaction design that I believe involves drama.

Stages of Interaction Design:
– function: does it work?
– usability: can people use it?
– aesthetics: is it nice?
– drama: is it meaningful?

Right now, we talk more about usability than anything else in this community, but should we be talking more about drama? Is this why Apple is pulling away from some of the other players?

[Slide of Pixar’s The Incredibles]

I spend a lot of time looking behind the scene behind so-called creative industries. They do things in a completely different way than business create things. He talked about how some people in “serious” industries dismiss the creative industries and their way of doing business, even though they have extremely successful businesses.

By looking at Pixar, they don’t have all the email and other business stuff we do, they all just work on the movie for like 6 years, just working with people. And each time they do this, they’re building a billion-dollar business. And they’ve done this 8 out of 8 times.

I try to get companies to work more like Pixar and less like big business.

[He shows a slide of Brad Bird of Pixar working with storyboards, etc.] These people spend years working with storyboards before they even start animating. They have arguments and enjoy them, something I think we’ve lost.

I advocate that we spend as much time on the creative / tangible as we do on the analytical / verbal (i.e., doing something versus studies, research, etc.) We forget what people care about and what people value. Drama–this notion of resonating with people–is something Pixar knows how to do and something we ought to consider doing.

[A slide of a Google App as an example of bad design.]

[A video of the wiggling iPhone icons and someone explaining how it works.]

What do you see there? What’s going on? They’re using humor with wiggling.

Audience: “It looks like they’re restless; they want you to move them.” “It’s intuitive; it behaves how you expect it to.” “The wiggling state makes it feel like it’s not a permanent state.” “It’s also reminiscent of those puzzles you had when you were a child.” “The wiggle is unexpected and you get some sort of pleasure out of that.” “It’s not obvious but memorable. It makes the device alive.”

This is not simple animation of “I’m going to animate what’s going on.” There’s something else going on. The interaction is in some sense choreographed.

Choreography is the art of planning movements and steps. Emphasis on *planning*.

Arranging home screen
– new state – wiggling (i.e., we would have said mode many years ago, or last week at some companies)
– moving
– getting out of the way
– extra space
– flicking

[Shows slide with a technical breakdown, and then another slide: WIGGLING and FLICKING]

State and transition is embodied in behavior of elements.

Identify dramatic aspects of the following sequence: [shows a clip from WALL-E where we runs over the pet cockroach and then tells him to go back inside]

What are some of the dramatic elements?

– “Eyes focus the emotion.”
– “Rolling over the bug”
– “Conflicting emotions: fear of having killed the bug, then happiness” (is the website going to accept my registration? YAY!)
– “Soundtrack with the Brazil riff is great; every program should have that.”
– “Without violating the mechanics of the devices, they still make them human.”

Dimensions of drama:
– context or staging
– character (icons on Apple’s phone wiggle and you start to refer to them as “they”)
– goal or purpose (protagonist is always trying to make something happen)
– action/reaction/behavior
– emotion (humor/irony/surprise/fear/joy/relief)
– what happens in real world

[Chris talked about how traditionally we refer to actions on elements in states of a system and how we can replace that with actions on characters with behaviors in the system, where a “goal” is replaced with a “story” and “result” is replaced with “meaningfulness”.]

How should one write requirements if we start doing things this way? I was recently meeting with a software company that has a hard time going through this process of identifying the requirements and then building system. Companies like Pixar don’t do that; they shape the real thing as they determine the requirements.

Story boarding is a way of working that you should look into. How many people have done this? [Nearly half the room raised their hands.] In storyboarding you’re balancing many different methods at once. It’s a good technique for starting to do this.

[Showed a five minute clip of storyboarding from Disc 2 of Pixar.]

These artists at Pixar are the best in the world. They argue over and over again to improve it, and we’ve lost that, the ability for people to be critical in the workplace. We need that.

Does any of that apply to Interaction Design?

Audience: “They had a room full of experts. We have a room full of…” [Laughter.]

Pixar respects all disciplines! Even marketing people. Let feedback come! You don’t need to respond to it. If a marketer says, “I think it should be blue” say, “Yes thank you, why do you think it should be blue? Great.” There’s no expectation that you’re actually going to act on their feedback. Go make it better, come back and show them. They don’t have to see their ideas used.

Audience: “We need our users to care about our applications [they way they do about the movie.]”

Audience: “If your co-workers will laugh at it, there’s something to it.”

Thank you for letting me foist these new ideas on you.

I missed the first minute or two of introduction from Gretchen; she talked a bit about the idea of “commander’s intent” and how in the military a lot of decisions are made by looking at the commanding officer’s intent.

She then talked about how boxes and arrows don’t tell a story to a lot of people, especially the business decision makers and industrial designers. She’s saying that a lot of success from comes knowing the forest, not the trees. “I looked at industrial designers and noticed they were sketching people and things and I was sketching boxes and arrows.”

Before you’ve got a prototype, you don’t have a demo, but you can sell them on a concept. She talked about how a colleague had 8 minutes with the CEO, and turned it into a big success by talking about people for 6 minutes, and then spending 2 minutes on the prototype. The CEO extended the meeting by 7 minutes, which was viewed as a coup.

When you have a narrative, you can hook people in, but if you have a bunch of interaction design cobbled together, you get big disconnects.

Create a big vision for your project and inspire people.

Harness the power of stories. On the one hand a story is “Here’s Jamie, she’s got some bowls, and at the end of the day, she uses her bowls.” This isn’t much of a story. You need to make it exciting.

To make stories, you need to “have character.” Your characters–your product–is not the lead of a story, it’s the supporting character. Don’t be afraid of being wrong–be afraid of not making a statement.

You also need curiosity and a crisis. You might have to exaggerate things to make the story interesting.

[Gretchen ended the presentation with an story composed of a collage of photographs that told a story of how a product worked timed to music.]

Cinematic Interaction Design by Sarah Allen (Laszlo)

[This isn’t a good sign; the laptop/projector link isn’t working, and given the highly visual nature of the talk, hmm…]

Who in the room has heard the term “Cinematic Interaction Design”? [A smattering of hands is raised.] This term was coined by the founder of Laszlo Systems [ugh] and we’re seeing it emerge across the industry. [Maybe I should have sat somewhere where I could make an easy exit; I hope this isn’t a Laszlo ad or vendor pitch.]

I don’t like the term “user”; it reminds me of the drug industry. I like the term cinematic interaction design. [Poor Sarah is trying to march on with the talk despite the lack of projector.]

[Sarah’s talking about how websites are based on pages and links and how that doesn’t really map into a lot of applications and causes confusion when overlaid on transactional systems. Finally, the projector is working.]

I started writing desktop apps in 1990 back in the Mac II and Windows 3.1 days. GUIs were pretty established back then; they’d been happening for a long time and were taking over personal computing. It was all about putting power back in the hands of the user; in the 80s you had to be a programmer to use them.

[Slides up now. She’s showing a video of various displays and interfaces, making the point that graphical displays are everywhere.]

All of this technology gives us opportunity:
– high-fi graphics
– animation
– personalized data
– smarter applications

“If you don’t have a story, no amount of graph trickery will make it interesting” – Harry Marks

Story = task + context
– interactivity does not preclude a storyline
– developing a story helps people to successfully accomplish a task

Optimal state of mind for expanding knowledge:
– relaxed alertness: moderate to high challenge, low threat, and sense of well-being

This enables learning
– allow people to access what they already know
– think creatively
– tolerate ambiguity
– delay gratification

From Making Connections: Teaching and the Human Brain

[Sarah talked a lot about the importance of avoiding gratuitous animation effects.]

How does animation help?

“By offloading interpretation of changes to the perceptual system, animation allows the user to continue thinking about the task domain, with no need to shift contexts to the interface domain” – Animation: From Cartoons to the User Interface, Bay-Wei Chang, David Ungar, 1995

By the way, this is not about how to make applications for the visually impaired.

[Sarah’s now going through various examples to showcase some of these techniques.]

IBM’s website:
– various sections of the website expand and collapse when you click on a “plus” button, allowing users to get more information without losing the context of the whole page

– shows how sliding helps the user keep context in the system. [While I like the transitions, I wonder if they are material in preserving context in this case; would love a demo without the transitions; maybe I should do that.]

– clicking on the move-to-top-of-queue button moves things to the top of the queue visually; you might not realize that otherwise.

– a Laszlo picture viewer. Show points out that when you click on a photo amongst a group of photos, the whole set of photos appear at the bottom. [iPhoto does the same thing but without the animations; could be a good comparison.]

– lists of items visually show the new sort when you resort the list or add items. This is helpful because you don’t have to manually track where things have gone. [This is definitely a great example of how motion helps.]

[Sarah is talking about Casablanca and introducing the roulette scene, which differs from the rest of the movie in style; rather than the traditional long cuts, it has a series of quickly edited short cuts.]

This is an example of “invisible style”: when there’s importance in a scene, there’s more attention, a lot of cuts, etc.

I’m going to show you some examples of how storyline, emotion, and visual transitions are put in practice.

– storyline: you create a personal radio station and listen to it
– emotion: conversational voice
– visual transitions: establish a sense of place

The storyline when you create a radio station shows how Pandora is not some geeky technology that has this machine that creates custom music for you; it’s more like your musicologist friend who makes recommendations for you.

“Pandora doesn’t have users, it has fans.”

I’m short on time, but other examples:

– Behr. Storyline: I want to paint my bathroom. They tripled their sales with their new site.
– H&R Block. Tango is this cool tax creation program. They introduced emotion with a personal voice with confidence and humor. They also have trust with delayed save and summary data. They have create visual cues with an overview, single page, and smooth transitions.

[Sarah had to end abruptly; the organizers kept the show moving on-time.]

Concept Models by Dan Brown

[I missed Dan’s introduction and story-telling. The room is packed.]

Let’s start talking about Concept Models with a mock assignment of building an expense report. He shows some hideous screenshot of an expense report and talks about our desire to make things better. You might have requirements and personas; now what do you do?

Someone shouts, “What’s the big idea?” It’s an expense report, there is no big idea. You’ve got a stack of requirements on your desk, you’ve got personas; what do you do now?

You could:

– do a flowchart. But the problem is that flowcharts preserve that screen-based approach to applications

– start wireframes; just sketch different ideas. (He shows an example of his wireframes with annotations.)

– brainstorm; all stand up at a whiteboard and sketch up. The problem here is that many of us don’t have people to collaborate with. Also, you might not fully understand the problem and its underlying concepts.

Underlying concepts? What are you talking about? Let’s go back to the requirements. I circle the interesting nouns. What do you do with this information? Well, you can create what I call a concept model (he displays a bunch of nouns–concepts–linked together). Circles connected by lines.

Dan’s showing a few example concept modules. The most interesting is a Flickr concept model, which takes a central theme (a user takes a photo of a subject) and builds on it.

[While I’m sure this was interesting to loads of people, I switched sessions mid-stream.]

Intuitive Designs by Jared Spool

Jared is showing some examples of bad designs by showing connection settings dialog. He showed negative examples from Google and Skype, amusingly saying that “you can tell Google employs Ph.D.s because you have to be one to understand their software” and “Skype was designed by high school drop-outs”.

He showed an example from Yahoo! Messenger which has very verbose descriptions in their connection settings area. He’s showing that they explain to normal users when they might consider using certain options (as compared to Google and Skype which are very geeky and require advanced knowledge to even understand the help). Jared shows how many of the Yahoo! screens have similarly excellent information.

AOL Instant Messenger one-ups Yahoo! with an “Auto Configure” button that automatically figures it all out, which is of course the best option, if it works. It’s what we call a wizard, which does things for us without having to train us. The wizard brings target knowledge down to current knowledge, whereas Yahoo! brought current knowledge up to target knowledge.

I now want to apply this to intuitive design. A design is intuitive when current knowledge equals target knowledge: the user already knows what to do. Or, the Knowledge Gap is very small. The user doesn’t perceive that they are learning.

I’ll offer an example from this hotel. I pick up the phone. What’s the first digit I’m supposed to press: 9. Everyone knows this. Well, let’s check. Jared shows examples from three examples.

Hotel 1 and Hotel 2 are both nine. But at another hotel, it’s 8. What idiot would make it 8? Don’t they know it’s non-intuitive? Who thought of that? That person should be sacked. And, if you’re suffering from some sort of emergency, you have to dial 8-911. Whose idea was that? What happens when you dial 911? Does it ring someone’s room? “Oh honey, just leave it be, they’ve been calling all night.”

This notion of what’s intuitive has to do with the knowledge we bring. 9 is no more special than 8. It was originally chosen because it was the one number after 0 you couldn’t dial by accident on a rotary phone. It’s been around since the 50’s. What’s amazing is that we all know to dial 9, and we know when not to dial 9. We know this instinctively.

There are two types of knowledge:
– tool knowledge–knowledge specific to one particular tool
– domain knowledge–knowledge about a particular domain that is portable across domains

[Jared is a very entertaining and engaging speaker; I was laughing almost non-stop since entering the room; sorry, I didn’t capture most of the jokes.]

Jared is deconstructing the website. My laptop is shaking from all the laughter. His points are actually pretty general: he’s showing how a simple bit of information about what school someone should attend is very difficult to clean from a poorly designed webpage and information. It’s a very thought-provoking exercise, including such points as:

– a long table with headers that scroll off the page and is therefore hard to read
– domain terms that aren’t defined that lead to confusion. For example, a column said “Handles Hazardous Waste” and he wondered, “Why would you want to attend a school that handles hazardous waste?” He drilled into the page and we only got more confused. It turns out that the school has staff that are trained to handle hazardous waste, etc. There’s a lot more negative examples I didn’t get–he moves fast.

It’s a business decision as to whether it makes sense to invest in intuitive design. Some techniques:

– Field studies (users in the mist): get users current knowledge
– Usability studies: test out target knowledge against current knowledge and the gap
– Personas: who users are and what their goals are, great for communicating to engineering team
– Patterns: package up the target knowledge and how to design for the gaps

What makes a design intuitive?
– Intuitive is personal to the user, based on their current knowledge and the required target knowledge
– Intuitive happens when the gap is minimized
– Just because something seems intuitive to you doesn’t mean it will seem intuitive to your user because of your knowledge and experience; you have to get to know your users

We have a newsletter: UIEtips (free) and we have a website too ( We have vritual seminars, and conferences and reports.

Robert Reimann kicked off the first (full) day of Interaction08. He started with a charged introduction, telling us that this is the first-ever conference of the IxDA group and represented a major milestone in the emergence of “Interaction Design” as the pre-eminent discipline involved in the creation of digital products.

The energy level in the room is very high–it reminds me of the first Ajax Experience, though enthusiasm is higher here as the IxDA community has been around in various forms for so much longer.

Alan Cooper just took the stage. Alan co-authored “The Inmates are Running the Asylum” (a difficult word to spell, by the way) and has long been an authority in the space. I’ve read much of his work over the years.

Both Robert and now Alan talked about the self-identification of Interaction Designers (Alan: “We’re not prototypers, testers, or eyeball-tracking wonks”); some of the rhetoric sounds like a social movement.

Alan’s first point is that “Best-to-market trumps first-to-market”, offering as examples:

– an ergonomic peeler versus a dinky metal peeler
– some clunky MP3 player versus the iPod
– AltaVista versus Google

Good design–innovative products–creates loyalty and enthusiasm in users that overcomes the advantages of first-movers.

If best-to-market is so important, why is “first-to-market” deemed so important by business people?

I don’t think we ought to be emphasizing innovation; in our industry, it will happen. Innovation means invention, but in the minds of business people, I believe it has come to mean “success”. But innovation doesn’t mean success (holds up that original clunky MP3 player that failed–“this was innovative, but was never successful”).

It’s design that leads to success, not first-to-market. Business people accept the need for design, but don’t understand its importance. Business people who rush to market and then innovative in subsequent versions–that’s hellishly expensive.

Business people don’t often do best-to-market because they don’t know how–we need to show them. Many have industrial age skills. They view software as mass production. Best-to-market only happens through craftsmanship. It’s all about quality–it’s all about getting it right, not to get it fast. It’s measured by quality, not speed. It’s a pure measurement, and a delightful one. Craftsmen do it over and over again until they get it right. In their training, they building things over and over so they get the experience they need to get it right.

Craftsmanship predates the industrial revolution. Only the wealthy could afford such finely crafted good. With the industrial revolution, goods came to the masses. We made the trade-off between quality and economy. We can’t all have a high-end piece of furniture, but we can all have a sofa.

Programming is not an industrial activity. It is a unique activity that has a lot in common with pre-industrial craft, and yet has a lot of unique characteristics that I call “post-industrial craft”. Programs are made one at a time, and each piece is different. It’s not scalable and it’s not formulaic. There’s no magic bullet in pre-industrial craft. We can’t say we’re all going agile and everything will come up roses. It’s incredibly nuanced and takes years of study to get right.

Post-industrial craft is similar but different. It is filled with innovation, unlike pre-industrial craft. Post-industrial craft software has massive interaction between parts and its abstracted notions presented in an abstracted notations. It’s in a perfectly brittle environment–all it takes is one bad instruction and the higher edifice comes crashing down. Software is intangible and inscrutable, as are the people that build it.

Programmers are draftsmen. However, they are different than pre-industrial workers. They are self-directed and know better than managers what to do. They respect intelligence, not authority. You can’t tell them what to do, you can only coerce them. Their satisfaction comes from the quality of their work. Unlike pre-industrial craftsmen, post-industrial craftsmen are smarter and more highly trained, even in the higher levels of management where they work.

This creates a conflict because management is industrial. It’s based on command-and-control. It’s tracked quantitatively through cost accounting, based on the idea that you purchase raw materials and you purchase labor that transforms those materials into offerings, and you scale up with factories, and that’s how you profit. That simply doesn’t exist in the world of software.

The well-tempered executive of the industrial age achieved cost reduction through efficiency, but there’s very little notion of that in craftsmanship when your objective is quality.

Building software is not some little detail of how many companies goods are produced–it is the core of the company.

In the industrial age, behavior was a by-product of functionality; in the post-industrial age functionality is a by-product of behavior.

Quote from a third-party: “Programmers cannot be managed, only facilitated.” But industrial-age management is based on control, not facilitation. Paul Glenn, the source of the quote, talks at length about how emasculating this is to programmers. According to Paul, geeks approach their job as a problem/solution scenario. They break it down into problems that can be solved. But facilitation doesn’t involve problems that can be solved, it’s a process (like, “How can I get along with my wife?”). Industrial age managers have a hard time with facilitation, and so do programmers for that matter.

When you have a clash of cultures, it gives rise to zero-sum tactics–fighting for resources. Time and money are not scare, but we are confronted with the scarcity of time and money. It’s just the apportion and it creates an apparent scarcity.

When you put people under extreme pressure, you get a wasteful culture of fighting and racing to market because of some false scarcity of time. The iPhone took plenty of time and come into a mature marketplace. I think of it as the South American dirt farmer who sets fire to hundreds aces of old-growth forest who clears soil for his crops for a few seasons, makes the soil barren, and then repeats it.

Business people often rush to market with crap, and when it fails, they walk away saying, “Well there wasn’t a market for that.”

With the slash-and-burn business culture, there’s this search for innovation, for some magic bullet. Innovation simply does not get it for you. The question is, “Why can’t business people work with post-industrial craftsmen?” It’s because management science simply lacks post-industrial tools. We have cost accounting for managing factories, and so management starts to wonder how they can reduce the cost of programmers.

But there are no economies of scale is software production, all you can do is reduce the quality that emerges. There are simply no good management tools for software construction. There are no appropriate tools for accounting for the creation of software. There’s no way to track any given feature, functionality, or behavior to the amount of money coming.

You hear all this talk about ROI; when a business person talks to me about ROI, I say, “I’m happy to do an ROI calculation if you tell me how to do it.” No one has ever given me a useful answer; there are no good tools for directing or facilitating programmers from the management side. So management tends to find a product manager or vice president who speaks business but can hang with the programming guys and delegates to them, not realizing by the way that they’ve delegated the heart of the business to someone whose goals are not the same as theirs.

So we have this industrial age managers and this culture of builders that are trying to achieve goals that may not be relevant to the goals of business. It’s time for us to fix this problem. We need to create an insurgency–a bottom-up solution to this problem.

Both of these constituencies need our help. We need to stop asking for permission and resources and show them how to achieve to seek success. We are an insurgent cadre of revolution.

Why us? Because programmers don’t respect authority, they respect competence. We are competent! We are just as rigorous as programmers, and we understand the technology as well as they do. We understand business as well. We are the ones who can faciltiate software engineering and construction as crafts.

We can facilitate programmers to practice the joy of craft. They can try over and over again to get it right.

To assume the facilitation role we need three things:

– a plan
– visibility
– confidence

We produce the plan from our work that we do on a daily basis: a written plan based on real research based on personas. When asked by management, “Why did you make this decision?” We need to track all decisions back to real research. Take it back to some kind of rigorous objective thinking, which is what those programmers will respect.

The thing about the plan is that it provides visibility. It provides a plan of “What Done Is”. The only way to track the progress of a construction progress is to track how the building is going against a plan. A list of features and a deadline simply don’t do that. You can’t take a list of features and call it a product description, just as you can’t take a collection of organs and limbs and create life.

With a complete and rigorous definition of behavior, you have something that can be understood and committed to by programmers. They understand narratives, and they can see your personas and buy into it, saying, “I get it.” Business people can see this and get visibility into the process.

Confidence comes from having done it before. This part of the job of programmers is hopelessly confused and confounded.

Frederick Brooks, the great sage of building high-tech systems, wrote in the Mythical Man-Month about how you build one to throw it away. I think it’s a very important concept; it’s come to be accepted in the programming community that you need to build a first to throw it away.

I’d like to recast that–you should *plan* to throw it away. Instead, you should write smaller pieces that you throw away, but you don’t throw the overall system away. You test your work on smaller pieces of disposable material. This is bringing pre-industrial techniques to our post-industrial technologies.

The dominant paradigm in modern shops is:

– Requirements
– Programming (Do it all)

The emerging two phases of production creation:

– Requirements
– Interaction Design (What?)
– Programming (Do)

This doesn’t work because we throw our pearls before deadline-constrained swine and you can guess what happens.

This is where we need to go:

– Requirements
– Interaction Design (What?)
– Design Engineers (How?)
– Programmers (Build)

[While Cooper uses different terms, he’s really describing the Right role of architects versus developers].

Designers collaborate when they iterate:

– Interaction Design (Goal: correctness; iterate, collaborate)
– Design Engineering (Goal: correctness; iterate, collaborate)
– Production Engineering: (Goal: efficiency; clear plan, skilled execution)

All of these are crafts; they are just different types of crafts. The first two are all about achieving correctness.

Design Engineering looks a lot like agile methods. Agile methods as production design and production are troubled and problematic. But for designers, they are excellent.

Production engineering happens to follow processes like RUP. You want to have everything set out on paper before you go off and do it. The place where agile runs into trouble is where it’s applied to the production side, and RUP runs into trouble when it’s applied to the engineering side.

So, how do we do this? How do we create this insurgency?

The key is to start small. Pick a project that is easy to define, small in scope, and something that you can describe in significant detail before you begin work, so the boundaries of the product are well-known. Something that is not a bet-the-company strategy; someplace where you can work without people constantly pulling the rug out from under you.

Then you enlist programmers: you tell them you will fight for quality if they implement your designs. You can say to them, “I will go to management and fight to get you the resources to determine how much its going to cost and how you are going to accomplish these problems, if when you build it, you will follow my specifications.” I believe programmers have been waiting for someone to make this deal, and I’m convinced management won’t make this deal. You’re giving them what they want: the ability to be great craftsmen.

You need to document your success: failure is an orphan, but success has many fathers. It’s imperative that you describe the status quo so you can demonstrate your success. Management will start coming to you and asking you to repeat your success on other projects.

Managers of course will say, “How much does this cost?” This boggles my mind. I know that this is a question that gets asked a lot, but it just seems absurd to me that someone would think that rushing a bad product to market will somehow be more successful than bringing a quality product to market. I always say, “Well, how much did it cost to build [crap MP3 player] versus the iPod?” I doubt there was a significant difference.

All of the increased cost will come to you from savings in the production stage, even though there’s a different allocation of resources. What you’ll wind up with is a successful product you can build on for the long term, such as the iPod versus the Archos Jukebox. You don’t find yourself with a commitment to an ill-conceived strategy.

The most expensive thing in business is opportunity cost, which is the cost of what you didn’t do while you were busy doing whatever you did do. Thus, it’s double or triple as expensive to rush a crap product to market. There’s no group of consumers waiting for you to ship your bad product to market.

We need to step forward and create this insurgency. Don’t ask for permission; let’s build this insurgency in partnership with the programming community. Let’s tell them that we’ll give them the freedom to create what they want, and they’ll sense the value, and join with us.

We’re the ones who can do this. Business people keep retreating into their industrial-age thinking, of cutting costs and outsourcing. When should we do this? Now.


Q: A lot of your examples deal with the commercial marketplace: products sold to consumers. A lot of us are stuck in an IT department building products for internal use. How do you reposition that message so that it works well for IT?

Coop: That is an artificial distinction. The issue here is that there are human beings who are using our products. Some of those human beings pay for the privilege of using our products, and some are paid to use our products. IT has chosen to work in an arena where people are paid to use our products, and its amazing how that covers up a lot of interaction design sin. There’s no doubt in my mind that every single org. out there that is selling IT products–the Oracles and SAPs of the world–if they could, they would be selling into a consumer marketplace.

The other thing is that while real people will use your really bad product because they are paid to use it, if it is a good product with decent behavior, productivity will climb. You can walk into any org and spot the SAP users–they are crying in a corner. You can’t tell me that that’s good for business. I don’t buy that. It’s a classic example of an industrial age retreat away from the acceptance that we are in a post-industrial age.

Q: In your different schema of the current paradigm and the where we need to be paradigm, you talk about the Why and the How. Can you talk more about the “Why?” of a product design?

Coop: “We are not very important because we don’t cut code.” (A boo and hiss from the audience.) In the world of high-technology, if you cut code, you control things. It’s the power to destroy the spice, it’s the power to control the spice. It’s not a fine kind of control: it’s bruce-force kind of things. We’re largely marginalized. We’re constantly asking for permission from the folks who shouldn’t be in a position to grant permission. We should be working with business folks and marshaling the technology to meet the solutions to business problems.

But when it comes time to marshal the solution to the problems, we find ourselves slamming into this kind of Stay-Puff Marshmallow Man of software development. I don’t call it development because programmers never ship things on time! I believe in blueprint-based construction. Developers say you can’t do that because requirements always change. I say if you don’t plan you can’t measure how the requirements are changing!

That’s why I believe in the Design Engineering phase: they go through the iterations to figure out how it’s going to be built. The difference is the in the industrial era, the construction workers were in a different caste that those who figured out how to build the bridge. But in the post-industrial world, programmers are in the same caste. But that doesn’t mean that their goals and responsibilities go out the door.

We don’t need to change interaction design; we need to re-orient organizations to build things right. When we come to programmers and say, “Look at the people I’ve talked to; look at the personas I’ve created” and present them with research, programmers understand that, and that’s how we will influence.

Q: I noticed that your requirements bubble disappeared. What do you think about requirements being replaced by prototypes?

Coop: Bad idea. Prototypes are software. I believe that there’s a role for prototypes in interaction design, but I believe it’s a very small and limited role. It’s primarily done as a narrative, not as software. The risk of doing interaction design in a medium of code is much greater than the benefits yield for you. We as competent craftspeople should be able to communicate with great precision and clarity what we intend the software to do without resorting to code.

Code is a sledgehammer here. Prototypes are code that has not achieved released. Snippets of disposable code are great tools for design engineers, but they don’t play a large role for interaction designers.

Arrived in Savannah last night for Interaction08, the first conference of IxDA, the Interaction Design Association. I’ll be blogging the sessions I attend for as long as I have battery life. 🙂

The biggest difference between this and the legion of technical conferences I’ve attended in my career is the male:female ratio, which much closer to 1:1 than any other event I’ve attended. For example, I’m sitting in a random row in the session room, and of the seven people in it, I’m the only guy. So I guess the ratio might actually be closer to 1:2 than >2:1.