I'm pleased to be headed to Europe in June for two speaking engagements: Talking about Playful Interaction Design at Business to Buttons in Malmö, Sweden, and then on to Amsterdam for the Advanced Interaction Design Workshop as part of UXI Amsterdam.

Playful Interaction Designs, although I am talking about games, is not the same talk we've all heard in the past about how to make your application more like a computer game. Ugh. Instead, I'm looking at the deeper structure of games and figuring out how those structures can inform our own work. I think it will be very interesting.

At UXI Amsterdam (use my code of FODS and get 15% off!) I will be teaching the Interaction Design Day, which I am really excited about. It's a, well, intense day that goes way beyond things like wireframes and delves into everything from turning research into design concepts through getting those concepts built.

Hope to see you there!

Originally posted on Wednesday, March 28, 2007 | Link | Comments (1) | Trackback (0)

For those of you who missed it at SXSW, I was asked to do an encore presentation of Learning Interaction Design from Las Vegas at BayCHI on April 10, 2007 at 8:30. (Kelly Goto is presenting from 7:30-8:30.) It's a short presentation (about a half hour), but supposedly interesting.

Originally posted on Monday, March 26, 2007 | Link | Comments (0) | Trackback (0)

Donald G. Reinertsen's Managing the Design Factory: A Product Developer's Toolkit isn't the type of book I typically read or review. But that's fine; sometimes you need to look at the same thing through a different lens, and Reinertsen provides that: taking a cold, hard look at the design process and its outcomes. Despite the subtitle, I would say this more a book for product managers than for designers, but it contains plenty for designers to chew on and at least try to swallow.

Reinertsen's first point: there are no best practices.

[T]he idea of best practices is a seductive but dangerous trap. Best practices are only "best" in certain contexts and to achieve certain objectives. A change in either the context or the objective can quickly transform a "best practice" into a stupid approach.

Instead of best practices, Reinertsen suggests we utilize "tools, not rules" and sets out to show and demonstrate some of them.

But first, he tackles some of the big questions, like what is the objective of the design process (what he calls "The Design Factory")? Simple: to make a profit. Sales are the measure of how much users appreciate the value of our product, and we should be efficient in "converting time and resources into things people value." (I told you it was a cold, hard look!)

[T]he only measure of the value of a design is its economic value. Our designs are not important because they are beautiful or because they are innovative; they are important because they make money. Our designs will only make money if we create recipes to turn material, labor, and overhead into valuable functionality better than our competitors do.

For Reinertsen, the purpose of the design process is to generate information (the "recipes" mentioned in the quote above). These recipes lose value over time (a recipe for a great 8-Track tape player wouldn't be as valuable now as it would have been in 1974, say), so they must be managed and delivered in a timely manner. These recipes are also usually one-time processes. "There is no value," Reinertsen writes, in creating the same recipe twice...we can only add value when we do something differently. If we change nothing, then we add no value."

To make good recipes also requires good information, and the sooner the better. As most designers know well, making changes late in a product is far more costly than making them earlier on, so we need good information as soon as possible in the process to make the correct decisions throughout.

Information is a key theme throughout. One nugget of wisdom I found instructive was Reinertsen noting that "events that are less probable contain more information" and thus we should balance our risk/success rate to obtain more information. "When success is likely, the message of success contains little information, whereas if success is unlikely, the message of success contains a lot of information. Likewise, a message of failure contains more information if the failure is highly improbable." We maximize the amount of information we can get by "approaching a 50 percent failure rate." We need failure and risk. "When a design fails because we try something new that does not work, we generate useful information," Reinertsen says. In fact, expert knowledge only comes from "being exposed to and remembering low-probability events." What a great way to think about failure.

Risk isn't to be avoided, but embraced. Reinertsen says we can make risk more attractive by

• decreasing the magnitude of the downside
• reducing the probability of the downside
• increasing the magnitude of the upside.

Easier said than done of course. He goes on to note that "most product failures are caused by market risk" which is "a much tougher problem than technical risk." Market risk is "determiend by how well the product specification meets customer requirements...Two factors that increase this risk are that customers often do not know what they want and that their requirements may change during the development process." He then goes on to offer suggestions for managing this risk, including using a substitute product, simulating the risky attribute, and making the design flexible enough to accommodate changes.

Another thing that rings true is about deadlines in the design process:

[W]e rarely stop when we achieve a satisfactory solution, because this will simply result in a satisfactory product. Instead, we stop when we run out of time...activities are completed on-time or late. They are never completed early.

Interfaces are another key point throughout, but not interfaces how interaction designers typically think of them (as UI, say). Instead, these interfaces are the connections between different modules of a design--where one component of a system connects and communicates with another. An organization, too, is one such system, and Reinertsen looks at the various types of organizational structures and the communications between the different parts of a company. "The key driver of good communication is the amount of usable information communicated compared to what is needed to make good decisions." In other words, you don't necessarily have to increase the information flow to solve communication problems.

When designing products, Reinertsen says, it's not enough to just find out what the customer wants. You need to find out "why they want it, and how they know they have gotten it." This should be spelled out in what he calls a Product Mission, which outlines the product's value proposition.

Why should a customer buy this product instead of a competitor's? If this question cannot be answered in a compelling way in twenty-five words, then there is a fundamental problem with the design of the product...Most successful products have a clear and simple value proposition. Buyers typically make their choice between competing products on the basis of three or four factors."

These factors should drive the design above all else. The Product Mission becomes "a compass for the design team, always pointing them towards true north." One trick to do that, Reinertsen says, is to "write the advertisement for the product as one of the first team activities." Another is to ask "what the mission statement excludes." If it doesn't exclude anything (the product is targeted to everyone, everywhere, at all times), it is useless.

Once you start having documentation ("specifications"), it is best, Reinertsen says, yto treat it as a flawed, living document, not something that is a fixed target. It's a moving target and should be treated as such.

If you are a product manager or into the business side of design, I recommend this book for its clear-eyed view of the design process. Its economic perspective on our often-fuzzy art ("make the design resonate with more emotion!") is a much needed tonic to design's gin.

Originally posted on Monday, March 19, 2007 | Link | Comments (0) | Trackback (0)

Aza Raskin (Humanized)

Not using his computer with the desktop running. So then how do I actually get to applications?

There are certain fundamental truths about how people work: it's called cognetics. And they apply to interfaces. If you design against human frailties, your interface won't work very well.

Cognetics: the ergonomics of the brain. Magical number 7 rule. Can't actively think about more than one thing at a time. Etc.

If you don't do this, you are asking users to push two buttons ten feet apart.

Forgotten Tools:
GOMs modeling: how long it takes the average user to use an interface.
Information efficiency: how much information you put in vs. what is minimally needed.

The death of the desktop is near. Why? Is this a good thing?

What is an interface? The way that you accomplish tasks with a product--what you do and how it responds. The interface is the product (to the user). A beautiful back-end isn't useful for people without the interface. Don't focus on the technology, not the user.

Keep simple things simple. A litmus test: how long the manual is. If it is difficult to explain how to use your interface, there is something wrong. When you set out to make an interface, write the manual first.

The problem is that applications are like isolated cities. Computing models could be different. There is a lot of overlap (waste) between applications. We get a lot of system bloat this way. You have to keep learning basic applications again and again. This is a fundamental problem with applications--they want to hoard functionality.

What does an interface do?
Create content (typing)
Navigate content
Select content
Transform content
(Share content?)

When designing, always return to these fundamental building blocks.

Raskin's Rules of Interfaces:
1. An interface shall not harm your content or through inaction allow your content to come to harm.
2. An interface shall not waste your time or require you to do more work than is strictly necessary.
3. An interface shall not allow itself to get into a state where it cannot manipulate content.

Content is Everything. You always acting upon some content.

What dooms the desktop? It's not about content. The desktop is a flawed metaphor to start with.

What does a desktop do?
Let's you get your computer into state where you can enter content. Let's you categorize your content. Let's you navigate your content.

There are better, faster, more humane ways. The web is treasure trove of examples.

Language has an untapped power. This is the future. It lets you describe things very quickly and very succinctly. If you can just type what you want, it works better.

Command line interfaces: great way to enter commands. URL bar can be a form of a command line.

The death of forced hierarchy. Tags don't force a hierarchy on users. Desktop needs to learn this lesson. We don't need to think the way our hard drive does. Going up and down trees isn't good. You also just need a really good search.

Navigation: Let content be content. Let search be search. Let 2D content be 2D content. Let the user's structure be.

The web as a maze: you go through a door and you can't see where you came from.

People don't work well in 3D, so don't force them too.

The desktop of the future is a zooming interface where you could put content wherever you want (not forced). Things are related geographically. It's visceral. Easy to navigate.

The desktop is doomed. Why the stagnation? The toolkit straightjacket. Programmers are writing for users, but don't want to interact with users. The people who write toolkits are one step removed from that. The system makes making mediocre interfaces easy. This is why the web matters. But it is dangerous to make the web like the desktop. We're free to make something better. And you cannot be better without being different. We have a unique opportunity to step away from the desktop. We can invent new paradigms.

How can we overcome applications? Services and Universal Access Interface. How do we get all these Ajax apps to work together?

Design the big picture: think above the apps.

Originally posted on Monday, March 12, 2007 | Link | Comments (2) | Trackback (0)

Panel: Kevin Cheng (Yahoo!), Matt Jones (Nokia), Simon King (Yahoo! Research Berkeley), John Poisson (Tiny Pictures Inc/RADAR.NET), Anita Wilhelm (Caterpillar Mobile).

MJ: User research and prototyping for mobile is incredibly important and difficult. The mobile experience is difference when it is in your hand. The sooner you can get a sketch on a block of wood or something in people's hands is the most important. Post-it notes on blocks of wood. Some Flash Lite code: XML representation of screen flow. People react very differently when it is in their hand.

AW: The most successful method I've had is paper. In some cases with foamcore so people could push buttons. Diary study with a brick to see what they would want to do with that brick.

KC: How is mobile design different than web design?

SK: Much more fragmented and divided attention situations. 20 seconds at time.

KC: What sort of metrics do you use?

JP: Clicks are gold in mobile space. Saving clicks makes sense. We even used .net because it was easier than .com

SK: We do a lot with click tracking too. Number of clicks are used to fine tune. It is harder to maintain state: no deeply nested menus or breadcrumbs.

AW: Session time is important: 3-5 seconds is successful. Designing for mobile is about breaking up an application into small steps. Keep minds available for whatever else they are doing.

KC: How do you deal with interruptions?

AW: Graceful failure. Design for interruptions so they can be resumed.

JP: Very different than designing for desktop. Very discreet tasks. Never going to go through a long string of actions.

MJ: Always know where your default cursor position is. Don't put anything complicated in a dialog! Always give people a positive path through the application using the defaults.

Q: Who is actually using mobile applications? I don't believe many people know you can send a text message via email.

JP: That's true. But time and again, even people who have a minimal exposure to phone functionality can learn it easily. Needs to be explained to users in the right orders and the right sequence. And once they learn the pattern they can do it.

Q: You have all these given inputs and outputs on mobile. If you are thinking about solving a user goal, what makes you choose one or the other?

SK: Depends on what you need to do. SMS can be limiting. It depends on the problem you have to solve. One issue is integrating with the other applications on the phone. Need to consider target platform.

JP: Need to solve a particular problem.

AW: Need to consider the experience. You can customize outputs for that application. If you can put it all into one centralized location, it makes it more of one experience.

SK: This also makes it faster.

MJ: Look at a service design approach to it. Magic tablets and magic clouds that follow them around. Need to look in a human-centered way about the service.

KC: At Nokia, how much of your time is spent designing the entire experience around the phone?

MJ: More and more. Particularly in the area I work in. The interaction between the cloud and the little mobile thing. Not just about going through this tiny post-it note. How we decide what to expose when. Two most exciting things is mobile version of Apache server--makes the relationship different. Python for S60 is also very interesting for rapidly making new web services. A wonderful pattern is emerging as mobile as stubmaker. "This is very interesting to me" then going back later and filling in that stub. You can do that with SMS or whatever.

Q: Flash Lite isn't supported on most phones. Emulators aren't great. How do you test an app on a million different phones?

SK: Excellent prototyping tool, but not good for actual applications.

JK: It simply isn't the case you can write one and use anywhere. Alternative is put it out there.

SK: Pay someone to test it for you.

AW: Number of companies that will test online.

MJ: If you test the edge cases, you are 70% good.

AW: Certain groups of devices you can test one or two from a group.

JP: Make it work on one or two categories very well.

Q: What is your strategy for getting your applications used and on people's handsets? Do you go on the carrier on-deck or off-deck?

AW: Have both off-deck and on-deck distribution for scannr. Decision is in the business deals and monitesation. On-deck has more distribution channels and easier billing for services. But it is a pain. Off-deck is much easier and lets you control the experience better.

JP: Some different strategies for distribution. We used the WAP experience, especially for outside the US. Distributing the app via WAP site.

KC: Off-deck means you also don't have to negotiate with all these carriers, right?

JP: Yes. Put it out there and build demand.

AW: Ecosystem of mobile is much harder than web. You need a tiered system: give users what they can use. Multiple versions: free version, deck version, etc.

Q: What do think about browser development in the phones?

SK: Opera browser rules. Makes WAP much less cool.

JP: Drinking the ocean with a spoon.

MJ: Need to think about the partial attention.

KC: Need two different designs?

MJ: Need a sweet spot between the two. Most websites are pairing themselves down anyway.

Q: Do you have any favorite resources for design patterns? Books, etc.

MJ: Sound and haptic feedback are also important, by the way.

SK: There aren't any.

Q: Strategies for open access to things on the phone?

MJ: We're actually trying to open up more. It's becoming baked in to things like the S60.

SK: Another company is to keep an eye on is Open Moko an open hardware and software platform.

JP: Fair amount of pushback from carriers against openness.

MJ: Carriers in Europe and Asia are understanding more open = more money. Becoming "The Proud Pipe" with only a little added value.

Q: Is there a standard email SMS back-end?

AW: Can't send an SMS to an email in the states.

JP: Can't programatically send out SMSs to the phone. And the answer to the question is no. It's a never-ending battle.

AW: Startups are trying to go around the carriers, but carriers are pushing back.

KC: We're out of time...

My SXSW 2007 presentation (6mb pdf). People seemed to like it. Sam Felder's transcription of the talk. Here's the Podcast.

Update: My talk was reviewed by The Guardian.

| View | Upload your own

Last fall, I was one of the judges for How Magazine's Design Competition. The issue with the winners is now on stands. I tried to inject a little more interaction design perspective into the competition, so that it wasn't only focused on the shiny-shiny. (Decide for yourself how successful that was...)

My judge's pick was a really fun site for a Canadian animated TV Show that I've never seen: zimmertwins.com. I really enjoyed the Make a Movie application, which was one of the best uses of Flash I've seen in a long time. Fiona really enjoyed it too, and since she is more of the target audience than I am, I thought it was a real success.

Originally posted on Thursday, March 8, 2007 | Link | Comments (0) | Trackback (0)

I moderate a handful of blogs and sit on a number of mailing lists. Occasionally, people will post to a list and get no response or leave a blog comment that gets ignored or deleted. Here's why.

You won't be taken seriously by me or anyone else unless you:

• Use reasonable English grammar. Even if you don't speak English as your first language, you can at least obey some basic English conventions, like capitalization and punctuation. Amazingly, it is usually English-speakers who are the worst at this.
• If you have a lot to say, break it up into paragraphs. One giant paragraph is annoying.
• Actually read what you've responded to. It's amazing how much misreading or skimming of a post people do before responding. Closely read the post to see if your criticism or concern has already been addressed.
• Be reasonable when what you are responding to is reasonable. Respond to reasonable discussions reasonably. Ignore unreasonable discussions. (This is hard.)
• Participate in the discussion. If you only post with problems or to complain and never contribute solutions or interesting commentary, you don't have much credibility.
• Don't comment anonymously. If you believe what you are saying, be an adult and put your name on it. If you are too cowardly to leave your name, you probably shouldn't be commenting.

So there you have it. Feel free to comment. :)

Originally posted on Sunday, March 4, 2007 | Link | Comments (5) | Trackback (0)

Adaptive Path has put together a new conference that should be of interest to intermediate and advanced practitioners of interaction design (and any sort of UX design, really): UX Intensive, which will debut in Chicago in April.

Along with my colleague Kim Lenox, I'm teaching the Interaction Design Day, which has some awesome topics that have been really interesting (and challenging) to put together, namely:

• Turning research findings into interaction design concepts
• Making better interaction design decisions
• Improving your ability to design suites of applications and extend interaction design languages across platforms
• Fixing inherited (and broken) products
• Communicating your designs throughout an organization
• Better tools for productive team-building and collaboration

The first workshop is in Chi-town on April 25th. Hope to see some of you there! Oh, and don't forget to use my discount code FODS for 15% off!

Seven people started Adaptive Path on the auspicious date of 3-2-01. Now, six years and 20-some-odd employees later, we're celebrating our 6th anniversary. Join us tonight for the infamous taco truck and a selection of our greatest prom pictures (you can get one taken too!). RSVP on Upcoming. I'm flying from Helsinki to be there (fresh off the plane no less!), so you have no excuse!

Originally posted on Friday, March 2, 2007 | Link | Comments (0) | Trackback (0)

Once again, I am headed to SXSW Interactive (I'm not cool enough too busy to stick around for Music). I hope to hang out with old friends and new, so please come find me (and go to my session):

Saturday
I'll arrive just in time for Opening Night Happy Hour. I will probably have to attend the frog design opening party from 8-10. Hopefully it will be better than last year, but I doubt it. The real event of the night will be 8-Bit starting at 10 hosted by our upstairs pals Satisfaction.

Sunday
I'm probably going to start the day (hungover) with Designing for Convergent Devices although I might be tempted by the pissing match that will be Why We Should Ignore Users. I'll probably take a break after that to get some BBQ and prep for my session Learning Interaction Design from Las Vegas. After which I'll be signing some books at the SXSW Bookstore. That night, I will definitely be catching DJ Mel again at the Web Awards After Party at one of my favorite Austin bars, Club DeVille. But not at the expense of missing What Made Milwaukee Famous at Ben Brown's shindig from 10-2. If I'm cool enough I might once again make it back to Ben's house for the after party.

Monday
Let's be honest: after Sunday, there is no way I am getting up early or will be functioning Monday morning. I'll probably get there in time for what I hope is a great mobile panel: Mobile Application Design Tips and Tricks. I'll probably head out for Tex Mex lunch and some Mexican Vanilla ice cream, then return in the late afternoon for The Death of the Desktop. I'll go drink some of Yahoo's purple booze at Yahoo's Bar Tab before crashing the The Great British Booze Up to hang with my Limey friends. My last scheduled event before my liver finally gives out is South by Northwest.

Tuesday
Return home. Recover.

My guess is this will be my last SXSW for a while, as my career and interests slowly drift away from (at least pure) web properties. But you never know...

Originally posted on Thursday, March 1, 2007 | Link | Comments (2) | Trackback (0)

« February 2007 | Main | April 2007 »