From time to time, we revive our in-house book club to catch up on new themes, practices, or ideas out there in the design world. This month, we're reading Lean UX: Applying Lean Principles to Improve User Experience, written by Jeff Gothelf and ex-Cooperista Josh Seiden. Inspired by Eric Ries's The Lean Startup, Lean UX takes aim at waterfall design and development processes and outlines a set of ways that UX designers can more deeply and helpfully engage in product development. The intent is to foster more open, collaborative, and iterative processes, and to break through the organizational red tape that can stifle creativity. The end goals: More trust, more clarity, more fun, and better products delivered quickly by a highly-functioning team. Managing Director Doug LeMoine caught up with Jeff and Josh to discuss the ways in which lean practices can superpower our (and your) UX work.
Doug: UX, as it is commonly practiced, is all about establishing a coherent vision for a product or service. Oftentimes, in striving for coherence, designers can slam the brakes on development, since no one wants to waste effort in developing something that's not part of that coherent vision. What is to be done with this state of affairs? How does Lean UX help here?
Josh: I do think establishing a vision up front is important. But I think that we often mistake how much work we need to do to establish and articulate that vision. If you’re working in deep collaboration with a cross-functional team, you can establish, test, and validate a vision very quickly. So, instead of “slamming the brakes on developers,” we advocating including them and other team members in the visioning activities early in the project.
From time to time, we revive our in-house book club to catch up on new themes, practices, or ideas out there in the design world. This month, we're reading Lean UX: Applying Lean Principles to Improve User Experience, written by Jeff Gothelf and ex-Cooperista Josh Seiden. Inspired by Eric Ries's The Lean Startup, Lean UX takes aim at waterfall design [...]
I love teaching our Interaction Design fundamentals class. I meet designers from all over, and for 8 hours a day, we talk about design, problem-solving, planning, strategy, big ideas. Then, at the end of class, we tackle a real-world problem near and dear to all Bay Area residents -- redesigning the ticket vending machines for our regional rail transit system (called "BART"). And oh boy, do these BART kiosks need to be redesigned.
When I started teaching Cooper's Interaction Design class in 2007, the most common conversation was, "How do I get people in my company to recognize design as something more than icons and wireframes?" Our materials focused on how to get beyond the notion that design is a rearranged set of tabs, and how to establish UX design as a key partner in the product development process. These conversations often felt existential: Who are we, really? How do we demonstrate our value? What do we do if we're socked away in the IT (or marketing) department? I always felt a little like I was giving a pep talk to troops who would soon go back to the battlefield. "Have fun storming the castle!"
In the past few years, this conversation has changed, and the Interaction Design course materials have changed with it. The pep talk has turned into a more strategic discussion about what to do with the recognition and responsibility that UX has been given. The conversation has also become more practical: What are the best ways to partner up with a development team that has gone agile? How do I scope a user research project? How do I make the case for user research? How do I sell my ideas to all the different audiences in the product development process? ... And the million dollar question: How do designers best contribute to getting the best possible thing built?
So we spend the first couple of days in step-by-step instruction on tools and techniques, and then we spend an entire day applying them to the BART problem and presenting the work. Our students come from all parts of the organization -- design, product management, development, marketing -- and their solutions for the BART kiosk are all over the map. In a good way! Many contain interesting notions and ideas; some are totally wacky; a few are actually pretty awesome. It's a wild four days, and everyone (including me) always learns a lot.
Interested in taking the class? More details and registration here.
I love teaching our Interaction Design fundamentals class. I meet designers from all over, and for 8 hours a day, we talk about design, problem-solving, planning, strategy, big ideas. Then, at the end of class, we tackle a real-world problem near and dear to all Bay Area residents -- redesigning the ticket vending machines for our regional rail transit system [...]
If you want to build great software, you can go it alone. You can design and build your product, make infrastructure decisions, manage releases, get the word out. Yet soon enough, if things are going well, you'll start to get traction, you'll want to scale, and your solo run will be over: You're going to need to work with others. You're going to need to create a team.
You'll find books and blog posts that will tell you how to create and manage a team, and they will include all sorts of helpful generalities. But I'll suggest a simpler framework for keeping the right things in mind: Think about your product team like a baseball team.
Nick Myers (Cooper) and David Bairstow (Thomson Reuters) are moderating a discussion on this subject at South by Southwest! Details here: Building Team Chemistry in Baseball & Technology.
Why baseball? Because both business and baseball are highly competitive, and baseball provides simple, clear object lessons for just about anything that you might confront in assembling a team -- how to spend money, how to evaluate talent, how to measure success. It's filled with vivid illustrations about teams that vastly underperform, teams that outperform, teams with rigid philosophies, teams that are fluid and flexible in their function. Most of all, baseball lays bare the fact that it is damnably difficult to create a highly functioning team. It's really easy to assemble a bunch of individuals who don't give a shit about anything but their own achievements; it's a lot harder to assemble people who are willing to learn, willing to work with others, and willing to do whatever it takes to win. A highly functioning team is not only about talent, not only about payroll, not only about organizational support, not only about leadership ... And yet it includes each of these things.
Find the right players
In baseball and technology, success starts starts with assembling good people. There's no way around this. If you don't have the right people, you're not going to compete. Ask the Kansas City Royals. They haven't had a perennial All-Star player since the 1990s, and they've only had one winning season since the mid-80s. (Disclosure: I am from Kansas City).
The challenge is not only to find great people, but to define who the right players are for your team. As longtime Baltimore Orioles manager Earl Weaver put it, "A manager's job is simple. Just pick the 25 best players for what he wants done" (emphasis mine). For Weaver, finding the right players meant finding players who could play a variety of positions in the field, which allowed him to employ a more situational, opportunistic style of baseball. It's not the only style of baseball, but Weaver worked it on the way to a World Series championship with a decade's worth of very competitive teams.
Fear conventional wisdom
If you're looking for someone to take the lead on a product, it's only natural to see the words "Product Lead, Apple" in a LinkedIn resume and say to yourself, "Let's give this one a call." Baseball executives used to do this kind of stuff all the time. They identified a conventional need -- "we need a big bat" or "we need a left-handed starter" -- and they go after a guy with that particular trait or great numbers.
Today's baseball executives evaluate players and positions with much more sophistication. They look for players who perform well in situations and environments that match their needs. If you're looking for a lead designer who can work across multiple product managers and scrum teams, you're going to need someone who can consult, cajole, and sell as well as they can design. The point is: Don't go after a big bat if what you really need is someone who gets on base. Get real about what's going to be needed to be successful in the role, and beware conventions and role names.
If you saw the movie Moneyball, you saw that the Oakland A's experimented with new methods of evaluating talent and performance. In the film, the team's scouts were portrayed as a group of grumpy old dudes who evaluated prospects with their guts, while the young guys in the corner uses "sabermetrics," baseball-ese for advanced statistics.
If you've ever tried to hire someone, you know how tempting it can be to use your gut: "Hey, she went to Stanford, so that must mean ..." Unfortunately, this method is doomed to failure, no offense to Stanford. Even more unfortunately, there's no sabermetric version of a person's career performance on LinkedIn. But the real lesson here is that the A's took the lingua franca of baseball performance -- player stats -- and applied it in a very different way to cut through the noise. So: What is the lingua franca of your category? What can you do to get beyond the traditional ways of evaluating talent?
Stay in your lane
Ever hired a dev manager who thinks he knows your business better than you do? Or a design director who can't stay out of the details? ... It's easy hire great people who don't know the boundaries of their greatness. Baseball is littered with cautionary tales of high-performing (and expensive) individuals who detract from the team because they're in the wrong lane, playing the wrong role. Conversely, the best baseball teams are characterized by players who know exactly what their role is, and who are employed by their managers in the right way.
Of course, people are often rewarded for ignoring the boundaries of his or her lanes. Steve Jobs never met a boundary he didn't ignore, which was part of what attracted great people to him. But how many Steve Jobses come around in a generation? You want team members with ambition and drive, but if you end up with people who are more driven by individual success or gratification than by the success of the team, you're going to have a harder time succeeding. Seek folks who want to be part of creating the Apple organization of your industry, rather than people who want to be the next Steve Jobs.
Identify your World Series
In baseball, the ultimate goal is clear: Win the World Series. Everyone knows this -- fans, players, coaches -- and it provides a very simple benchmark for evaluating overall performance. Your World Series should be a big goal, not simply increasing revenue 10% or landing a big account. It's a monumental achievement: an IPO; the millionth download of your app; becoming the market leader in your category.
It's okay if your World Series is unattainable today. In baseball and in technology, there are teams with no realistic shot at a World Series this year, or next. The task for teams like this is to establish a path to that ultimate prize. Most teams should be asking themselves: What's the first milestone on our way to the World Series? You need to win your division first.
Let's face it, there's no champion in the history of any sport that hasn't benefited from some moment of luck. The 2010 San Francisco Giants were on the verge of losing a critical game in the playoffs when the opposing second baseman experienced an utter meltdown in the field, making three catastrophic mistakes that allowed the Giants to escape with a win and go on to the World Series. Diehard Giants fans will recall the 2003 playoffs, when a critical error swung momentum toward the Florida Marlins, who ended up winning that game, and then went on to win the World Series.
So you could say that it all works out, but that's probably one of the areas in which technology and baseball are very different. If you're waiting around for your luck to change in product development, you won't be around for long.
If you want to build great software, you can go it alone. You can design and build your product, make infrastructure decisions, manage releases, get the word out. Yet soon enough, if things are going well, you'll start to get traction, you'll want to scale, and your solo run will be over: You're going to need to work with others. [...]
Millions of us use these annoying robo-responses. Why? Because email is the primary communication channel for business, and because we want to appear attentive to customers and colleagues. We figure that it's better to hackily and immediately "respond" than to leave important people hanging. The makers of PIM tools (Outlook, IBM Notes, Entourage) obviously don't care why we use auto-replies; if they did care, we'd have tools that actually support what we want to do.
Let's end this little charadeOur primary business tools can do better than asynchronous notes telling us that we've failed. Many of us set a variety of statuses during the course of a day, and good tools bring critical contextual information to us.
Let's say that someone wants to send me email. (It happens from time to time).
Once the sender's PIM tool recognizes who I am, it could quickly ping the address.
Let's pretend at this point that I have told my PIM tool that I will be out of the office. This is immediately reflected in the sender's tool.
That's not good enough, though, because the sender needs to know that there is some kind of recourse. What if the tool could politely indicate where the message was going?
Even better, what if I could create a special VIP list who would immediately be forwarded to me?
Google Wave may make this argument irrelevant over the next few months, but until then, I offer the above, inspired in parts by Facebook, the real-time elements of the Google Wave demo, and a conversation with Jared Goralnick. Jared's service, AwayFind, provides a nice way to get around Outlook's blunt, siloed approach to business communication. Check it out.
Millions of us use these annoying robo-responses. Why? Because email is the primary communication channel for business, and because we want to appear attentive to customers and colleagues. We figure that it's better to hackily and immediately "respond" than to leave important people hanging. The makers of PIM tools (Outlook, IBM Notes, Entourage) obviously don't care why we use auto-replies; [...]
I was recently involved in a project that involved the creation of a "status economy" on the web, i.e. a system in which businesses reward loyal users with stuff — a representation of increased status, better service, cash, etc. The parallel in the real world is the loyalty program, but the word "loyalty" seemed to imply a sort of exclusivity that is inconsistent with fluid and flexible world of web commerce and relationships. The web already has a variety of ways of displaying status, and the word "economy" more appropriately spoke to the web's transactional nature.
I was recently involved in a project that involved the creation of a "status economy" on the web, i.e. a system in which businesses reward loyal users with stuff — a representation of increased status, better service, cash, etc. The parallel in the real world is the loyalty program, but the word "loyalty" seemed to imply a sort of exclusivity [...]
On Wednesday, we celebrated the release of Designing for the Digital Age, a comprehensive how-to for getting great products built. The release party was hosted by Autodesk in their amazing new Gallery at One Market in San Francisco. The Gallery is filled with cool toys and overlooks the Bay, so it was a pretty ideal setting in which to host a couple hundred of our closest interaction design friends. Big thanks to our friends at Autodesk for a memorable night!
Scenes from Wednesday night's party at the Autodesk Gallery. More on Flickr.
Download the chapter here.
Check it out, and let us know what you think. It's entitled "Designing the Form Factor and Interaction Framework," and it contains a discussion of the tools and techniques for generating and iterating design directions. If you're wondering what you're getting into, here's an excerpt from the Introduction.
[PDF, 1.4MB, requires Acrobat 7 or higher]
On Wednesday, we celebrated the release of Designing for the Digital Age, a comprehensive how-to for getting great products built. The release party was hosted by Autodesk in their amazing new Gallery at One Market in San Francisco. The Gallery is filled with cool toys and overlooks the Bay, so it was a pretty ideal setting in which to host [...]
Clarification: We've posted only the slides and notes on Slideshare. We'll post a link to the video of the presentation when it is available on the IxDA website.
The title of the presentation is "Each One, Teach One," and it discusses the future direction of interaction design as a profession. We've seen demand for our services increase dramatically over the past few years, and, in order to continue to respond to this demand, we need to make more of us. Part of the solution involves creating academic programs to provide the foundation for learning the craft of interaction design; another part is to create a culture of mentorship. This means that all of us need to learn to teach what we do.
As Kim says, "[Being a good mentor] takes good listening, observation, and collaboration skills. It takes imagination, because you have to see the potential in someone who isn’t yet able to demonstrate everything they’re capable of. It takes a willingness to explore and wander a bit instead of going down the path of least resistance."
Check it out, and tell us what you think.
Kim Goodwin delivered the closing keynote at interaction 09 on Sunday, and it's now available on Slideshare. Clarification: We've posted only the slides and notes on Slideshare. We'll post a link to the video of the presentation when it is available on the IxDA website. The title of the presentation is "Each One, Teach One," and it discusses the future [...]
Taking on big problemsTalk 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].
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 [...]
At Cooper, I find that I'm often looking for new ways to activate design thinking, or to clearly and directly represent ideas. It can be easy to think too literally, to work over the same terrain again and again, and this is why I'm inspired by work like Niemann's — it gets back to basics. It speaks clearly, but also invites interpretation. It reminds me of Bill Buxton's discussion of "storytelling with found objects" in Sketching User Experiences:
As a child, when your parents got a new refrigerator, did you not take the box and transform it into a fort or spaceship? We have all seen and done such things — made free associations between objects and their meaning and purpose. The key observation here is that such transformations are as fundamental to design thinking as they are to childhood imagination and discovery.
I'm curious to hear from the design community: Are there techniques that you've used to radically reconsider familiar concepts? Or to vastly simplify the communication of your ideas?
When I saw Christoph Niemann's recent piece in the New York Times, I LEGO N.Y., I was struck by the way that simple physical objects, accompanied by text, can beautifully illustrate ideas. Both images are from Christoph Niemann's I LEGO N.Y.. He has a blog called Abstract City on nytimes.com. At Cooper, I find that I'm often looking for new [...]
Clippy came to mind when I was in Japan, a nation and culture richly populated with animated characters. On every surface, there are characters — talking penguins, inflatable dogs, instructive manga characters — and their cumulative presence seems to make the environment more engaging and friendly.
I saw this little guy in the UI of a Nintendo DS when I toured ATR, the Advanced Telecommunications Research Institute in Kyoto.
I don't know what he's saying, but he sure is cute.
So, after my trip to Japan, I'm worried that we've taken the wrong lesson from the shortcomings of Clippy. There must be an appropriate a place for characters in interactive systems that are not simply games — not all interactive systems, but some, maybe?
My question: Can anyone point me to some good implementations of characters in non-game software? Or recommend some best practices?
Remember Clippy, the Microsoft Office Assistant? If you're like me, you remember Clippy because you hated his guts. Figuring out how to do basic stuff in Microsoft products is (often) frustrating and difficult, but being patronized by a grinning cartoon paperclip while doing so was infuriating. The fact that Clippy seemed to offer help at all the wrong times — [...]