Touring the Continent
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!
Encore Presentation: Learning Interaction Design from Las Vegas
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.
Review: Managing the Design Factory
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
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.
SXSW 2007: The Death of the Desktop
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.
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?
When designing, always return to these fundamental building blocks.
Raskin's Rules of Interfaces:
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?
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.
SXSW 2007: Mobile Application Design Challenges and Tips
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...| Link | Comments (0) | Trackback (0)
Learning Interaction Design from Las Vegas
Update: My talk was reviewed by The Guardian.Link | Comments (3) | Trackback (1)
Judge's Pick: Zimmertwins.com
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.
How to Be Taken Seriously in Blog Comments or Mailing Lists
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:
So there you have it. Feel free to comment. :)
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.
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!| Link | Comments (0) | Trackback (0)
Happy 6th Anniversary, Adaptive Path
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!
My 2007 SXSW Schedule
Once again, I am headed to SXSW Interactive (I'm
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...