Sign up to get our featured articles delivered straight to your inbox every month or two.
RSS feed of all articles
Follow us on Twitter
Architecture (3)
Automotive (2)
Books (13)
Branding (3)
Business (28)
Communicating design (10)
Cooper (13)
Critiques (20)
Design & engineering (20)
Design disciplines (1)
Design in organizations (23)
Design principles (16)
Events (13)
Experience Design (11)
Features (82)
Financial (1)
Industrial design (7)
Information design (7)
Innovation (24)
Interaction design (41)
Interaction Patterns (5)
Medical (4)
Methods (5)
Mobile (10)
Personas (13)
Platforms & technology (2)
Presentations (4)
Product definition (6)
Prototyping (1)
Requirements (4)
Research (17)
Service design (8)
Strategy (9)
Sustainability (10)
Techniques (32)
Travel (3)
Trends (12)
TV (5)
Typography (4)
Visual design (19)
Web (14)
Interaction design
Each One, Teach One: Get Involved in Mentoring!
In my closing keynote at Interactions 09, I spoke about some of the challenges facing interaction design as a profession, perhaps the most important of which is a shortage of designers just when the world is starting to demand what we do. Increasing numbers of college and university programs will help, but the fact is that interaction design—or any kind of design, really—is a craft that takes time to master regardless of one’s educational background. If you believe the 10,000 hour rule recently popularized by Malcolm Gladwell, that mastery should take something along the lines of five years doing nothing but design.
In my experience, people get more out of those hours when they’re not working in isolation, but are surrounded by more experienced people who can challenge, support, and advise them. Consultancies and large in-house design organizations often have some kind of coaching built into their structures and processes, and good managers are often good coaches. However, it can be hard to see your manager as approachable because, regardless of his personal qualities, he controls your career track and compensation. Sometimes, a senior person who isn’t responsible for your career is easier to get advice from. This is why everyone at Cooper with “senior” in her job title is explicitly expected to mentor others.
Unfortunately, not all companies have this kind of mentoring built in, and many young designers (or not-so-young PMs and engineers who want to be designers) work in environments without experienced design leaders. This is one reason the Interaction Design Association (IxDA) has decided to create a mentorship program to hook up people who’d like a little career coaching with those experienced practitioners who are willing to coach. As you might expect, so far the program has attracted more people looking for mentors than people willing to mentor.
So here’s my pitch to all of you potential mentors out there. First, mentoring isn’t a one-way transaction. As a friend of mine who recently earned his black belt in Aikido told me, a black belt isn’t a sign that you’re a master; instead, it’s a sign that you’re ready to become a true student. Teaching others will make you far more conscious of your own craft. Also, consider this: you, yourself, can only design so many products and services that make the world better. The people you mentor will go on to design many more. Finally, mentoring doesn’t need to be a huge time commitment; just an hour or two here and there can make a big difference.
So, what are you waiting for? Sign up to get a mentor or become a mentor today!
What do you think? Join the conversation in Comments
Blending Agile and UCD at CHIFOO
The Computer-Human Interaction Forum of Oregon (CHIFOO) hosted Lane Halley and Jeff Patton for a talk and workshop on blending agile practices and user-centered design. On Wednesday night, May 6th, Lane and Jeff presented a talk titled “Making Sense of User-Centered Design and Agile.” Thursday, May 7th, Lane and Jeff taught a full-day workshop titled “All Together Now: Blending Interaction Design and Agile Development Techniques.”
The slides from the May 6th talk are available on SlideShare. Pictures of the May 7th workshop are available on Flickr.
Is Interaction Design a dead-end job?
IDEO’s Bill Moggridge made a comment last week after a screening of Objectified that hit close to home. To paraphrase, he said interaction design has become pervasive, that anyone and everyone can be an interaction designer, and so the role of professional interaction designer is (or is becoming) unnecessary.
So, is Interaction Design a dead-end job?
As an expertise, no. But as a discrete service offering or a career path, I say absolutely.
This position has not made me any new friends around the office, but to be clear, I'm not suggesting our profession is akin to flipping burgers at the mall. Instead, it's that interaction design has reached a point of maturity where growth is constrained. I see three major factors behind this and hope that by acknowledging them we can find a way forward.
Video of Kim Goodwin speaking about how to integrate interaction, visual and industrial design at IxDA NYC
Last night, our own Kim Goodwin presented her talk "Designing a Unified Experience" at the IxDA NYC, generously hosted by our friends at LiquidNet.
(Click the button on the bottom right of the "screen" for a fullscreen view.)
About the talk
Interaction design, visual design, and industrial design are distinct disciplines for good reason: Each excels in different ways. Interaction designers must be good at imagining structure and flow, which requires strong analytical skills and a high degree of rigor, especially for complex systems. Visual designers and industrial designers are masters of visual and physical usability but are also masters of emotion: They know how to evoke caution, attract attention, and instill desire for a product at first glance. Users have just one experience of a product, though. All three aspects of the design must work in concert, or the product will fail to satisfy. Integration of the three disciplines is a central theme of Kim’s new book, Designing for the Digital Age.
What do you think? Join the conversation in Comments
You're only a first-time user once
We’ve all got our own personal benchmarks for what makes a good user experience. My personal list includes a few: Does it delight me? Will I recommend it to my friends and colleagues? Would I have used the same approach if I had designed the product? I’ve found among some product executives one particular pattern for this subjective evaluation criteria that is both humorous and troublesome: “Would my mother/grandmother/Luddite Uncle Bill be able to use this product on the first try?”
While there is a sort of noble aspirational quality to this kind of thinking—let’s make everything so dead simple that any person can use every product—it also sets the bar for the experience rather low. I imagine a sea of step-by-step wizard dialogs that target the lowest common denominator and force everyone else to step through the same predefined (and very explicit) experience. If I’m designing a product for people who have specialized knowledge, I want to leverage that knowledge in the product. Why force people to walk when they can run? I’ll want to provide these people with clear, appropriate pathways through the product, but I also want these specialized users to be able to forge a variety of their own pathways through the interface, dependent on the specifics of their situation or how they want to do things.
I once worked with a client to design an intravenous medication delivery device called an infusion pump. This is a machine that nurses in hospitals use to administer drugs to patients by attaching a bag of medication to the device and specifying delivery parameters such as how long and how fast to dispense the medicine. This is critical stuff; the consequences of a mistake could be catastrophic.
To test, or not to test? You have more than two options
Just as every author needs an editor and every engineer's code needs QA, every designer's work can benefit from evaluation. Does it surprise you that I'm saying this? As UIE's Christine Perfetti once pointed out to me in an interview, Cooper is better known for advocating up-front research, effective process, and skilled designers than for promoting the value of usability testing and other evaluation techniques. It's true that given a limited budget-which most people have, these days-we think investing in these early-stage activities yields greater value. That said, evaluation is so important that every design project at Cooper has evaluation techniques built in. When, how, and how often we evaluate depends on the nature of the project.
Software is a movie, not a building
In a previous post I suggested that film making is a good analogue for discussing software design and development, that lessons learned there could help us think about better ways to approach our own projects. I established the similarities like this:
Much beer has been spilled over comparisons of software to physical architecture, and while the analogy is interesting it is inherently flawed. For the industrial-age activities of designing and constructing a physical building are vastly different than the post-industrial process of designing and building a digital artifact of conceptual ideas, where cost is measured by time rather than materials and success measured by consumption and desirability.
What does sustainable interaction look like?
In the past few years the design community has taken sustainability from a mere buzzword into a call for action. Eli Belvis, Tony Fry and Cooper's own David Fore have all championed the idea that the practice of interaction design must promote and encourage sustainable decision-making. The Designer's Accord has emerged as a mandate to turn the the goodwill into commitment and a plan of action, improving the role of design in sustainability.
This is all good, it's all needed, but we also need to get down to brass tacks. A cursory survey of the internets reveals a hunger for actionable discourse about sustainable interaction design. What does sustainable interaction design look like in the wild? What does sustainable mean when it comes to designing software? What are practical design choices that encourage sustainable behavior on the part of the end user of software?
Goals! Prototypes! Action!
A thread in comments on a post from Michal Migurski got me thinking about the analogy of film making to software design and development. The more I explored the idea, the more multi-faceted the analogy became.Movies and software are both very creative and very custom-craft intensive. They are both extremely collaborative — moreso than almost any other endeavor. Both encompass a wide range of styles, audiences, scale, and budget. For each there is a relatively subjective determination of completeness, that point at which the product is ready for release. And history is littered with spectacular successes, and failures, both within and outside the formal "system."
We can learn a lot by looking at parallels between film making and software, if only to recognize the issues we face around budgets, timelines, clarity of direction, conceptual and tactical authority are not unique. We can recognize that there are numerous models to adopt or avoid as the situation demands. It allows us to examine the interplay of money, talent, ego, authority, collaborative energy, role specialization, and market forces at a comfortable distance while learning lessons applicable to our own work.
To begin, let's establish a basic model that compares the film making process to the software making process. In a loosely time-based perspective, consider these parallels:
Naturally, there are countless variations to this flow, with more or fewer steps, multiple feedback loops, things happening in parallel, and so on.
Moreover, countless questions that fall out from this comparison:
- Is there a parallel in the world of software to a screenplay?
- How do the roles in film making relate to the roles of software?
- Which types of movie productions are similar to the various types of software projects?
- How are feedback, iteration, and evolution handled in film vs software?
- Who exerts creative control, assesses market viability, predicts audience acceptance?
- How is technology changing established ways of working?
What do you think? Join the conversation in Comments
Prototyping article on Adobe.com
Industry Trends in Prototyping, a whitepaper I wrote about prototyping for interaction design, recently went live on the Adobe Developer Center. Of course, they were interested in what I had to say about using Adobe software (which conveniently, we have no small amount of experience with), but I also tried to take a step back to look at the reasons why designers should prototype and different ways of thinking about and building prototypes. Check it out. Let me know what you think.
What do you think? Join the conversation in Comments
Interaction design for startups: A conversation with Andrew Hoag, founder of inviteme.to
inviteme.to is an early stage startup that allows people to coordinate offline social activities with their friends. Founder Andrew Hoag, tired of organizing the "goat rodeo" preceding any event with his friends, found a niche desperately in need of attention, and decided to do something about it. He approached Cooper in April 2008 to work on the design and user interaction for his web-based product.
The people behind inviteme.to
Andrew: We got started 8 months ago and have two full time people and a couple of contractors and outside staff helping us. As for background, I come from the business side, working in enterprise, security and software for 7 years. Most recently I’ve been advising consumer internet startups before launching inviteme.to. My technical co-founder is a developer that came from a large travel site, Sidestep, which you may have heard of. For now it’s just the two of us working full time with a bunch of people helping us out.IxDA interaction 09
Kim, Suzy and I just got back from the annual conference of the Interaction Design Association (IxDA), interaction 09 in Vancouver, BC. Four days packed with ideas, insight, meeting new friends, and catching up with old friends; the program offered some intriguing speakers and provocative topics, and I'll highlight a couple here.
The keynote speakers played to packed houses.
Taking on big problems
Talk of sustainability often came up during the keynotes and the smaller sessions, and it seemed to be on the minds of many in attendance. Like other disciplines, interaction design is wrestling with the ways in which we, as a profession and as individuals, can do more than simply design more disposable crap. How can we design stuff that lasts, stuff that helps, stuff that addresses real problems? [Cooper took a shot at approaching these questions recently].One free interaction
"One free interaction" is a prospective design pattern that gives software and hardware a more humane feel. It exists outside of task flows and the concept of users as task-doers. Instead it sits in the "in between" spaces, suiting users as fidgeters, communicators, and people who play with things.
Snapback pages
When I got my iPhone, I spent time opening up all the applications and playing around. I was keeping an eye open for what new facets of the touchscreen interaction design were fun and useful. When using the Safari web browser, I noticed the funny stretchy-edge pages. Meaning, when you use your finger to scroll above the top of a page or below the bottom of a page, it pulls away from the edge of the browser, revealing a small blank area that sits “behind” the page. When you lift your finger up, the page snaps back into place. It’s kind of hard to describe, so this little video should help.
It was pretty cool, since it provided some visual confirmation of the edges of the page. But honestly I thought it was just a coding oversight. Then I saw it again in the text message page. And again in email menus, and the emails themselves. Nope, I realized, it’s baked into the OS.
I put the feature out of my mind until I found myself fiddling with it. Mulling over an email, or waiting for a text response from someone, I’d sit and idly flick the pages away from the edge just to watch them snap back. Flick-snap. Flick-snap. It was so satisfying, even if it was sort of useless.
Then I started seeing this same pattern in other things.
Remembering to remember
You are shopping on Amazon. You add something to your cart, and you decide to checkout. Amazon asks you for your account information. "Enter your e-mail address," it says. You do. Underneath that are two radio buttons. One says "I am a new customer." The other says "I am a returning customer," and offers a field for your password. You click, or tab, to the next field and enter your password. You hit enter, or click the sign in button — it makes no difference to Amazon because this is what it replies:
You clicked on the button indicating you're a new customer, but you also provided a password. If you're a new customer, please do not enter a password yet (we'll ask you to create one later). If you're a returning customer, please click on the button indicating that you already have a password, then type in your password.
You are confused and dismayed. You did NOT click on the button indicating you are a new customer! (What button?! The only button in the page says "Sign in!") You realize the default on this login page is set to "new customer." You wonder why it does not understand your intentions. It could see that you have entered a password, yet it did not bother to query the database; or, why did it not simply toggle the radio button as you tabbed or clicked into the password field?
You get the feeling Amazon holds some kind of institutional animosity towards you, like being sent to the back of the line at the DMV because you made a slight error on one of their forms.
But you forget about this, until the next time, and the time after that...
What do you think? Join the conversation in Comments
You've got to hear it to believe it
Art house movies always seem to reveal new possibilities. Last week I watched Zidane, un portrait du 21e siècle, a deep dive into one of the world's most fascinating athletes &mdash French football god and legendary hothead Zinedine Zidane.
The film spans a single game, and dozens of cameras are trained on Zidane for the game's 90 minutes. Throughout, you're connected to Zidane &mdash pressed up against his face, attached to his hip as he glides through the defense, drifting around him as he scans the field. You're also immersed in the sound of the event &mdash chatter between players, the sound of cleats cutting into the ground, the distant crowd roar, and strange periods of silence.
Zinedine Zidane, from the film Zidane, un portrait du 21e siècle, (translation: Zidane, a 21st century portrait)
It's the sound that really did it for me. The gasps for breath, the immediate shifts in the pace of footsteps, the ka-chunk of the foot hitting the ball, the zzzzzip of the ball on top of the grass. If you applied this super hi-fi sound to sports I watch all the time &mdash NBA basketball, for instance &mdash the end result would be incredibly compelling.
Nothing is special
Numbers abound in interfaces, hopefully delivering a great deal of information. Bigger numbers usually indicate more activity (like when you're looking at comment threads), or more work to do (like when you're looking at your inbox); smaller numbers generally indicate low activity. However, when the number zero must be represented in an interface, it should be treated differently than other values. Why? As I'll show below, "zero" can actually imply a variety of things, depending on its context.
Search results
Zero results can mean either that the term isn’t represented in the searched data set, or that the user mis-keyed the term. Each possibility would suggest a different recourse.- Correct term, but no results? You need to find another term or look elsewhere.
- Bad term mis-keyed? You need to supply the correct term.
When the search results are zero, help the user notice the error with attention getting graphic design, and provide options about alternate terms or places to look.
Designing time to think
I was busy with production work last week, and in the background I listened to the Google TechTalk by David Levy, "No time to think." In spite of the title (and my partial attention), it really got me thinking. Levy suggests that we are in an information environmental crisis, that we need silence and sanctuary for creative reflection and engagement. He explains that Nobel Laureate Barbara McKlintock was able to see further and deeper into genetics than anyone had before because she took the time to look and to hear what the material had to say to her. At Harvard, students asked her "where does one get the time to look and think?" They argued that the pace of current research seems to preclude such a contemplative stance.
This is a pressure we can all relate to. I struggle to find the time to think deep thoughts. Every time I try, I interrupt myself to check my email or text messages, or track the latest news headlines. Randall Munroe over at xkcd.com seems to have the same problem. It seems that my attention span is inversely proportional to the number of "productivity" tools and toys I have. As much as I love it, my iPhone has been the worst thing I could have done for my ability to focus.
These days we rarely focus clearly on one thing at a time, multi-tasking from the moment we read the paper on the bus with headphones and coffee en route to work, until we get home and check email in front of the TV while eating dinner. We are constantly interacting with technology devices and information.
Vannevar Bush's 1945 article, As We May Think, expressed the hope that more powerful tools will automate the routine aspects of information processing, and would thereby leave researchers and other professionals more time for creative thought. But as Levy points out, more than sixty years later, it seems clear that the opposite has happened, that the use of the new technologies has contributed to an accelerated mode of working and living that leaves us less time to think, not more. Levy asks where in our culture we are making time to think, since thinking takes time.
At the end of the talk an interesting comment came from fellow who observed that, in contrast to Sweden, San Francisco has very few public benches where one can just sit down and observe what is. One has to keep moving, and according to the laws if you stay in one place too long, you may be considered to be "loitering." In our culture, there are few opportunities to be calm and sit down in a public space, unless one is consuming something at a coffee shop or a café. This is something that has been built into the culture and the architecture. We need to rediscover the places that will encourage this kind of thinking and reflection - not only in our physical but also in our digital spaces. Creative thought can't be rushed, but it can be nurtured.
So how can we nurture creative thought?
Much of the work we do at Cooper involves designing tools to increase productivity and efficiency; to help people to do more, faster, and keep them moving. But are we in danger of making things too fast and efficient, preventing people from spending enough time with the information they need to consider carefully? There are things that computers are really good at — memory work and calculations, for example. There are also things that they are really bad at — cognitive work, subjective decisions and judgment calls. The latter should be left to people, and as designers we need to ensure they have the right information, as well as the time, to come to a thoughtful decision or judgment.
For example, when designing software for tax professionals, we should ensure that the preparer is enabled to spend most of their time interpreting tax laws, rather than filling in line items one by one. Make the easy stuff easy — let computers do what computers are good at — and allow preparers to focus on what they are good at, and what they actually enjoy about their jobs.
Designing with time
We use scenarios to tell stories of ideal experiences for our users. Any storyteller will tell you that timing is an important part of telling a good story and as designers we need to think carefully about time as a design element — it's just as important as color, type and layout. Dan Boyarski has been thinking about time as a design element for many years. He has been teaching his students to use time for emphasis, clarity or to create new meaning. You can see some examples of the work from his classes here.
Most of these pieces are experimental and entertaining, based on poetry or film dialogs, but the principles at work can be applied to designing enterprise software too. Rather than just making everything faster and more efficient, we need to think about how to get people to focus on the important stuff, without letting minor tasks and busy-work get in the way. We need to design environments where people have the time and space to focus on important decisions. One way to do this is through progressive disclosure; only revealing information when it's relevant to the decision at hand. Other ways to achieve this would involve presenting information in the right sequence, or placing related information in close proximity to help people to see the big picture. All of this is in service of nurturing the balance between ratio (searching and re-searching, abstracting refining and concluding) and intellectus (thinking; reflection; assimilation and contemplation) — which is Levy's concluding slide of the talk.
Photo from Flickr by timparkinson.
It's really important to take the time to look and to think. Let's think about how we can design metaphorical benches in our products to encourage people to stop and reflect where necessary.
What do you think? Join the conversation in Comments
Making people think
Software makes us think. Sometimes, it aids productive thinking by pointing us toward the right things to think about. Other times, it gets in our way, poses confusing choices, and generally frustrates us; this unproductive thinking can be seen as the cost of doing business with an ineffective interface.Christof van Nimwegen's doctoral thesis focuses on the ways in which software can be used as an aid in creative thinking, and it specifically discusses the trade-offs between requiring users to construct an internal understanding of the system, and externalizing that system in the interface, via menus, dialogs, or wizards.
Bill Thompson, a regular commentator on the BBC World Service program Digital Planet, enthusiastically responded to the paper with the following:
It is also the sort of basic psychological research that we desperately need in the Web 2.0 world where major sites like Facebook are constantly being redesigned on the basis of little real understanding of how people engage with their computers.I was interested to see someone addressing interface design from a strictly psychological perspective, rather than one rooted in interaction design:
We concluded that relieving a user’s memory and making interactions assisted by externalizing information does not have beneficial effects. It makes users count on the interface and gives them (unrightfully so) the feeling that the task and thinking-work is partly done for them, which seduces users in more shallow cognitive behavior.Wizards can have the effect of seducing users into shallow cognitive behavior. When users are guided through a simple process, they are often shielded from an underlying complexity. While saving the user time and effort in the short term, the wizard may also make them less capable in the long term because they haven't had to deeply consider their actions.
Nimwegen continues:
... Interaction should facilitate or even persuade users to learn what underlies the task they are doing. The same is true in situations where interruptions are commonplace and where in the meanwhile mastery of what is underlying a task or domain is desired, or when operations come with a cost and direct solutions without deviations are the aim. In designing our interfaces we have to be careful with providing interface cues that give away too much, and must design in such a manner that the way users (should) think is optimally supported, which in turn could help the software to achieve its specific goal.Not every task is important enough to teach users the mechanisms that support it. Many interfaces benefit from a level of abstraction or decoupling from the underlying processes. The spirit of this research is to point out that the effort to dumb down can go too far. Removing some of the obstacles to learning complicated or deep domain applications may actually do more harm than good for a user.
For example, a beginner may struggle to through the myriad complexities of 3D modeling software, and this struggle may in the end produce more competent users. The software shouldn't erect unnecessary obstacles, but a learning curve that is too shallow may actually hinder their ability to really develop competence in program in the long run.
(Via BoingBoing)
What do you think? Join the conversation in Comments
Agile interaction design for startups: A conversation with Cameron Koczon, Co-founder, Border Stylo
Recently I’ve been trying to figure out how interaction design can be blended with Agile development techniques. William Pietri and I have been working closely with Border Stylo, a web-based startup located in Beverly Hills. Through a series of short workshops, we’ve been helping them find the appropriate blend of Agile and interaction design techniques for their team, and evolve those methods as their needs change.
Cameron Koczon and Eduardo Prats were at Cooper October 27-29, 2008 for a series of collaborative design sessions. I took the opportunity to chat with Cameron about his experiences working with a design consultancy as his small startup interleaves product definition, development and interaction design in a nimble fashion, without losing ownership if the vision and end results. Lane: Please introduce us to your company, Border Stylo.
Cameron: Border Stylo is about five months old. Our founding team is a group of very good friends from way back. Myself, Diego and Oscar went to high school together, Eduardo is Diego’s little brother, and Evan and I were college roommates. We raised a little money to build a proof of concept of a Firefox extension. Based on our proof of concept, we raised some series A funding and that took us to where we are now, constructing our Alpha release.
Lane: What is the composition of your team? How many people and what are their skill sets?
Cameron: We all wear a lot of hats. Diego, our CEO does investor relations and makes sure we stay the course in terms of our vision. We’re going to do a lot of data mining and analysis and his educational background will help us with that.
Oscar, our COO, is in charge of developing and implementing our marketing strategy. Because many of our investors are international, we plan on conducting an international release of our product. He also does a lot of the work that has to get done at a startup but is not very glamorous. He makes sure the rent and bills are paid. He handles legal, accounting and is involved in hiring. I actually don’t know how he keeps track of it all.
Eduardo and I do visual design, UI design, product definition and some of the implementation associated with that. That’s not sustainable, so we have to bring on some more people to do that.
We have a development team of three people. One, our CTO Ian, is a badass Rails developer and does a great job of keeping our team on track. Another, Evan, does all our front-end/plug in development. The third guy, Thomas is focused on the back end, making our product scalable. Again, we are in the process of expanding the team to a more sustainable size, but for now that is the full dev team.
A unified approach to visual and interaction design
During my seven years as a visual designer at Cooper, I’ve learned that designing for complex digital products and services requires input from a number of unique perspectives to be truly effective. Furthermore, each of those perspectives must be effectively integrated throughout the lifecycle of the design process to achieve results that are consistently and predictably usable, useful and desirable.
In the course of managing, consulting and teaching, I have not only had the opportunity to define and discuss design process with my colleagues here at Cooper, but with countless practicing designers from organizations all over the world as well. Unfortunately, my observation has been that even when all of the right people are involved, more often than not, the various design disciplines opt to compartmentalize the problem. In other words, they divide the project into an interaction design problem, a visual design problem, and an industrial design problem. Each of these problems is then tackled separately, and the resulting individual design solutions get bolted together at the end. It’s a Tower of Babel situation, where huge opportunities are lost because the team fails to work together to come up with an innovative product solution and to employ a single, unified design language.
A fractured process makes for a fractured user experience
In practice, people view their experience with a product in a unified way. For example, when a user interacts with a cell phone, she doesn’t experience the phone’s behavior separately from the visual and tactile presentation of that behavior on screen and through the physical form factor. Why, then, don’t product teams consider these aspects of the experience in a unified way when designing solutions?
Of course, we know that many digital products and services represent extraordinarily complex, large-scale design challenges. A significant degree of rigor and a rational approach to methodology is required to bring together the diverse perspectives of the different design disciplines in a way that results in optimal creative abrasion, rather than destructive friction that threatens to bring the entire process to a grinding halt(1).To this end, let me share with you a few of the insights that we’ve gleaned from practicing a truly convergent approach to design.
(I should note that in an attempt to keep the length under control, I've focused this article on the convergence of interaction and visual design for products with defined hardware, like PC's or handsets. We're looking forward to sharing our experiences with integrating these two disciplines with industrial design in a future article.)
A conversation about voice interactions
A while back, several of us in the studio had a little spontaneous discussion about voice user interfaces over email. We thought we'd share some highlights. Please pile on in the comments section.
Steve Calde: What are people’s experiences with voice user interfaces? [A client] is interested in learning more about how to document voice-activated systems, and wondered if we had any experience to share.
Alan Cooper: You could also suggest to them that voice interfaces are inherently bad and will never work very well.
Dave Cronin: Why are they inherently bad?
I agree that they often are bad, but it seems to be more an implementation issue than something intrinsic about voice commands.
Stefan Klocek: The reason they are inherently flawed is that we use our voice for other more important things in addition to the system level input we would like to give to our DVD player. There is no way for the voice interface to understand that the context has changed and that I am no longer giving it a command, rather I am now giving my child a command or am simply muttering to myself. Of course we could imagine a system in which we indicate context by saying “DVD player - pause”, but this is adjusting my input to the deficiencies of the system.
The missing piece: How interaction design can add to Agile
Since Alan and I attended Agile 08 last August, I’ve had conversations with a lot of people about their impressions of Agile. I’ve talked with people working in a variety of settings, from scrappy startups who are iteratively defining their product and market to large companies with complex business problems working with internationally distributed teams. In each of these settings, some folks are strong advocates of Agile, some are still skeptics. It’s a broad field, and I’m still very much formulating my opinions, but I’d like to share some thoughts and observations I’ve had along the way. I also have a few ideas about how Agile and interaction design might be able to work in concert.
Whimsical interaction design
Let's face it: Most interactive experiences are pretty darn serious. Of course, there are those that are appropriately so. We don't want people having a laugh in the operating room or on the trading floor — though, who knows, the latter might have been just the thing to stop the fear-driven capitulation in the markets last week. Still, even most consumer user experiences end up feeling very straight-laced.
As what must be a bit of an escape from the general heaviness of past few weeks, I've found myself pondering the idea of whimsy in interaction design. Now, there are the kind of experiences that are primarily playful, like games and other kinds of entertainment (for example, around here, we're all really loving Brian Eno and Peter Chilvers' Bloom, a generative music toy for the iPhone), but I'm thinking more about ways to add a touch of playfulness to the everyday.
It must have been Droog, the famed Dutch industrial designers that first inspired me with how just the right touch of whimsy can bring a modern functionalist design to life without reducing its utility. (Ironically, "droog" means "dry" in Dutch — a term often used to characterized the deadpan lowlands sense of humor. As they say in their faq: "The droog mentality could be summarized as ‘dry’. ‘Dry’ as in dry wit, unadorned informality, ascetic irony. ‘Dry’ as that essentially Dutch inclination to ‘do normal’ and at the same time critically investigate what you’re doing and the way you do it.")
©Droog
The Come a Little Bit Closer Bench by Nina Farkache for Droog is both attractive and fancifully inventive — it allows people sitting on it to move closer and further away from each other as the seats glide over marbles.
So that's certainly one kind of interaction design. What about software?
Playing well with others: How to create effective design teams
Tolstoy said it about families, but it's true of teams as well: Every happy team is alike, but each unhappy team is unhappy in its own way. Where Tolstoy and I differ is that I think that there is much to be said for happiness.In the design world, the idea of working in a "team" often provokes dread. Teams introduce overhead; they require communication; members often battle to see their ideas implemented. The end result of teamwork is often seen as compromise, i.e. as a "taco pizza," i.e. a situation in which everyone (including the customer) loses.
On the other hand, there are many examples of highly functioning creative teams, and my own experience tells me that a team approach can be vastly more efficient and effective than working solo. Who doesn't want a well-matched partner to ensure that the ideas flow, the problem is considered from all angles, and dead-ends are avoided? And lets face it — some of the most interesting and important problems are too big to solve alone.
At Cooper, we've spent a lot of time noodling on this problem, and we've got some ideas.
A command I could really use
Ctl+Z works when you've done something inadvertently bad, but what about those rare occasions when you do something inadvertently good?
What do you think? Join the conversation in Comments
Why I hate the substitute spinning instructor, and what the heck that has to do with design
As interaction designers, it’s natural for us to pick apart the failings or successes of every website and electronic device we see and apply that knowledge to our work. But every day, we’re faced with countless products, services, and even people that provide us with positive or negative experiences. Gaining an understanding of what makes each of those non-digital experiences good or bad also exposes patterns and commonalities that we can draw upon when it’s time to design.
Not long ago I found myself growing increasingly annoyed and frustrated with a substitute instructor for my regular spinning class at the gym. To keep myself from leaping off my bicycle and strangling her, I spent the class analyzing what worked so well with my regular instructor’s approach, and what made me so crazy with the substitute’s.
Setting aside the fact that the regular instructor is a Brazilian Adonis and the sub was a perky size 0 cheerleader type, I identified that the substantive distinctions in their styles were tone and frequency of communication. My Adonis is the strong silent type; he speaks only as much as is necessary to guide our action on the bikes, using a tone that conveys respect: You have shown up for class, and are therefore self-motivated, driven, and capable of pushing yourselves to your appropriate limits. He lays out the plan for the training, cranks up the music, and lets us get in the zone. The sub, on the other hand, yammered over the music non-stop throughout the class, reminding us to breathe (gee, thanks!), stressing that we came here for a workout, and regularly demanding that we give her 10% more. Excuse me? I don’t even like you - I’m not giving YOU 10% more of anything!
As luck would have it, back here at the studio, I’m working on a business application that will be used primarily by workers who are relatively new to the job. (Advancement at my client’s company happens quickly, so just as users get good at what they’re doing, they get promoted and no longer have to perform the work that the software supports.) Knowing that the application we’re designing will need to guide users through their work, and keeping in mind my recent experiences at the gym, I made sure to ask users about the qualities they appreciated most in their human mentors. My design partners and I then took care to embody those personality traits in the visual and interaction design of the application. (For a nice list of factors that affect the perceived personality of an application, see Martijn van Welie's blog post Brand behavior in interaction.)
So the next time you find yourself particularly delighted or disgruntled as you move about your daily life, challenge yourself to figure out why — it just might help you hone your design skills.
What do you think? Join the conversation in Comments
Discoverability
Hey iPhone users, did you know that you have access to special diacritical characters? Neither did I. The bloggers at iSmashphone had to point it out to me in their entry 12 iPhone Tricks You Might Not Have Known.
The way you do it is to press and hold the base character, and the line of diacritical characters appears above. Slide your finger to the correct one and lift up, and now you can properly spell the word háček.
Crappy interface embarrasses Sulu on national television—not cool
Wanna Bet is a new show on ABC wherein celebrities bet on whether “ordinary” people can accomplish extraordinary things. Whichever celebrity has the most money at the end of the program gets to donate it to the charity of his or her choice. The way it works is that the show introduces the ordinary person, describes the (usually very odd) action this person is going to attempt, and the celebrities write down their prediction and bet amount. The attempt is made, the person succeeds or fails, and then the celebrities reveal their bets to much fanfare.
So far so good, right? The trouble is that there is some kind of disconnect in the betting process. On the first episode George Takei (better known as Sulu from Star Trek) excitedly revealed that he had guessed correctly and had bet $20,000. The show’s hosts, however, informed him he had only bet $2,000. For anyone not employed as a designer of interactive systems, it looked like George Takei was having a senior moment. It was embarrassing. The other celebrities on the show spent the rest of the episode pretending to have flubbed their bets to make up for it.
So where’s the failure here? George Takei is getting on in years; maybe he’s just not very comfortable with technology. Leaving off a zero is an easy mistake, right? Maybe, except that in the very next episode of the show, the same thing happened to comedian Melissa Peterman who thought she bet $5,000 but “really” bet $6,000. She’s only 37 and sharp as a whip. The show is now two for two, and I would argue there is a failure in the system.
Countdown to a spanking
XP: Are you SURE you don't want to restart now?
A constant thorn in my side from our use of Windows XP as our primary workstations is the Automatic Updates feature. In explaining my frustration to others, I've inevitably compared it to very similar behavior in Mac OS X, which for some reason does not drive me insane. I've been unable to put my finger on the difference until just this morning. Where OS X also presents a modal (non-closeable) dialog that requires an action, Windows floats that dialog above everything else, forcing the issue. With OS X, I can happily continue about my day, and decide to restart only when it is convenient for me. XP on the other hand, requires a 'Restart Now' or a 'Restart Later' before it gets out of my way, and choosing 'Restart Later' begins a Sisyphean cycle of misery until finally the computer has had enough of your sandbagging and counts down an automatic restart, like a mother counting down the time you have left before you get a spanking.
What a difference being able to click away makes.
What do you think? Join the conversation in Comments
Beautiful Monsters: Check your assumptions at the door
Every product, service, or business model is defined in large measure by what designers take for granted. These assumptions can be held so deeply as to be invisible to the designers themselves. And yet their acknowledgment, and negotiation, are key to industrial evolution, profit, and harmonious relationships to various ecosystems.
In the early days, for instance, you could assume that those with access to computers were backed by organizations willing to invest the funds necessary to acquire or build the complex infrastructure required by computational behemoths. But with the advent of microprocessors and other such developments, that all changed. Now the intrusion of computers into every corner of our lives is nearly complete, with 11 percent of the people recently polled saying they’d like their email deliver directly into their brains in the ultimate post-media consumer fad.
The Drawing Board: Episode One
Here at Cooper, we find that looking at the world from the perspective of users and their goals makes us notice a lot of bad interactions in our daily lives. Being solution-minded designers, we can’t help but pick up a whiteboard marker to scribble out a better idea. (Just ask our partners and friends—we really can’t help ourselves).
This sort of thing makes a fun thought exercise, so we thought we’d share it with you as a series of narrated slide shows we’ve called “The Drawing Board.” These aren’t meant to be slick, highly-produced demos—just some ideas we’ve thrown up on the board to stimulate thought and discussion. So…enjoy. Discuss. Design.
Taking the Call on Vimeo
What do you think? Join the conversation in Comments
Alan's keynote at Agile 2008
I was asked by the leadership of the Agile 2008 Conference to give the closing keynote address at their annual conference in Toronto. The audience at Agile08 consisted of about 1500 programmers, engineers, product managers, and others involved in the creation and deployment of software primarily using Agile methods.
My belief in the value of detailed written design has often led enthusiasts of Agile to assume that I am an adherent of the obsolete, and justly maligned, waterfall method of software construction. I was pleased to have this opportunity to state my position with clarity and precision, not to mention making the case for effective collaboration between interaction designers and Agile programmers.
Here are the slides and accompanying speaker's notes for my talk. Some in the audience noticed that I was reading from my notes during the presentation. If you're interested in why I chose to do this, read this Journal entry.
If you would like to discuss this presentation with me, either post a comment to the Cooper Journal blog or email me directly at alan@cooper.com.
What do you think? Join the conversation in Comments
The power of rich visual modeless feedback
One of my favorite aspects of product design is the feedback mechanism. When I think of feedback, I think fundamentally about the car dashboard. Nearly every action that a driver makes in a car is responded to with one or more forms of feedback whether audible, tactile or visual.
When turning into a left lane, the driver will (hopefully) use the turn signal lever to indicate the change of lanes. Pulling the lever anti-clockwise will activate the turn signal on the exterior of the car, but will also offer the following feedback:
- Audible: The dashboard will emit a clicking sound
- Visual: A green arrow will flash on and off in the dashboard
- Tactile: The lever will click or nudge over
All of these feedback mechanisms work in tandem to communicate with the driver that the turn signal is active and working. As a side note, if you’ve ever activated your turn signal and it emitted a clicking sound at double the normal rate, it usually means that one of your lights is dead (this is considered negative audible feedback). That’s great design when you consider how impossible it would be to turn on your signal indicator, get out of the car, run around it to check all the lights are working and then jump back in again, all at 30 miles an hour!
Beautiful Monsters: Be the change
The Market Street grid, Courtesy: bricoleurbanism.
This week, San Francisco started choosing sides for another Market Street Mêlée, which we fight once every ten years or so. On one side of the double-yellow line are arrayed various assorted starry-eyed, bipedal dreamers who propose closing down the main artery of our fair city to most carbon-emitting traffic so as to give pedestrians and bicyclists a break, reduce pollution, and increase the beauty and overall mellow vibe of the grid. On the other side stand the self-styled hard-nosed rationalists who see in this as a pedal-powered economic and moral calamity in the making.
The next step for community design
Community design centers are non-profit organizations that provide high quality design to underfunded and underserved areas of a community. They're usually established as extensions of colleges and universities, and they're intended to positively impact the surrounding community though design — usually through the physical build.
Back when I was pursuing my degree at the University of Cincinnati’s college of Design, Art, Architecture and Planning, I worked for one, with the intention of helping to revitalize one of the more depressed parts of Cincinnati. The focus was the design of a farmers market, an initiative that included contributions from Architecture, Planning, Industrial Design, and my own discipline of study, Graphic Design. The end result of our work is a vibrant, exciting environment, and this experience got me thinking about ways in which my current discipline could take part.
Does your persona eat twinkies?
I recently stumbled across an article about personas written by Andrea Wiggins late last year in Boxes and Arrows. Wiggins does a nice job talking about how personas can help the design and development process, and some approaches for creating a good persona set. But what really gave me pause was the title: “Building a Data-Backed Persona.” Data-backed? Wait a minute…is there any other kind?
Algorithm Ink: Learning by doing
Aza Raskin has released a wonderful new toy, Algorithm Ink. As he states in his introduction, it really lowers the bar to exploring the creative mathematical beauty of fractals. Aside from the images themselves, there are two things I love about this site.
First, the less-is-more UI design really lets the canvas be the focus of attention by keeping tools out of your way until you need them. Second, and more fundamentally, is the “view source” ethos and the direct manipulation of the visualization-generating code that really makes the experience compelling (if not addictive).
Here’s what happens to me: select an interesting image and watch it play out. Click open the “edit” panel to expose the surprisingly few lines of code that make it tick. See all the pretty numbers. Change one. Click “draw” and see the effects of your change. Repeat about a thousand times.
Before I realize it, I’m copy-pasting functions from other drawings, following the logic in code to reverse-engineer how an effect is generated, musing on the power of weighting the randomness of my results. Like writing HTML on the Web 1.0, I’m learning by example and trial-and-error. Sure, there’s a manual for the syntax somewhere, but the experience of seeing and affecting the code in action is so much more fun.
What do you think? Join the conversation in Comments
Let the walls do the talking
Many of the Cooperistas were out traveling today, so I had the opportunity to snoop undisturbed. I thought it would be fun to find out a little more about what goes on in the office and to practice an aspect of our research approach while I was at it.
Observation of the environment in which people work is important to gain a well-rounded understanding of the people we design for. The objects and information that people surround themselves with, the character of their workspaces, and the way in which people interact with each other in those spaces all provide important clues about needs, priorities, preferences, and goals. When we talk in someone's personal workspace, we often intuitively pick up on facets that would not come up in conversation.
I snapped some photos of a few curiosities, and wrote down my initial thoughts about what these artifacts say about their owners. I also recorded the questions I would have asked of them if they were around to answer.
I discovered that there are a variety of computer mice around here. At first glance, it looks like people have chosen their mouse setup based on form, control type, and the feel that they prefer.
Questions:
What do you use your computer for? Did you specifically choose this mouse? Why or why not? What other digital products or peripherals do you own? Tell me about your favorite one, and why you like it. Any that you don’t like? Why?
How we use Fireworks
In our training courses, we're frequently asked what tools we use. The answer is pretty simple. While we might use Photoshop for heavy photo manipulation or break out Illustrator for the odd diagram or visualization, we've come to love Adobe Fireworks for designing screen-based interfaces and illustrating scenarios.
Recently, Adobe asked us to share some of our Fireworks techniques with the user community. As a result, we worked with them to create this short video about how our interaction designers and visual designers worked together on a recent project for GoldMail.
If you want to get more in depth with Fireworks, you can read a more thorough article about specific techniques that I recently wrote on Adobe's developer center.
What do you think? Join the conversation in Comments
Welcome to the new Cooper Journal
Like most design agencies, Cooper crackles with conversations on a variety of topics. Unlike lots of other agencies, we've mostly conducted these conversations in primitive channels — over email and in person around the large, U-shaped couch where we eat lunch.
We call it "The Departure Lounge"
Up to now, private has been easy. Publicizing our conversation means work — to set up, to moderate, and to keep current. When you also factor in the unknown amount of Alan-wrangling, you're talking about a lot of time away from design, problem-solving, and the stuff we all love.
So why take it public now? Because we want to be part of the bigger conversation, and to bring people into our conversations. Up to now, we've participated in formal, somewhat old-fashioned ways — at conferences, and through our newsletter. We'll still do these things, but we'd also like to talk about stuff happening like, now, and the logical place to do that is via a web-based publishing platform more commonly known as a "weblog."
Our mission is to communicate deep and clarifying insights, to kick around sparky and elegant ideas, and to discuss design methods and processes. And we're excited to bring you, the Internet, into it.
So, without further ado: Welcome to the Cooper Journal!
What do you think? Join the conversation in Comments
Content Management Systems: Don´t automate the Misery
Organizations of every size are attempting to get a handle on their content generation, management, and publishing systems. This trend toward business process re-engineering (BPR) of content management is largely the result of an outsized proliferation of Web pages, intranet sites, and electronic communications strategies adopted by organizations, their partners, and customers.
Sadly, few organizations have seen much good come of content-management BPR initiatives so far. Of the many reasons for these failures, one stands out: these BPR initiatives—and the systems they spawn—are focused on realizing organizational objectives without sufficient regard for the context, habits, and goals of the people who will actually use the system. These new technology solutions are intended to create efficiencies, but they actually prevent people from achieving their objectives, which generally have to do with reducing hassle and ensuring their own personal effectiveness.