Go behind the scenes in this two-part Masters In Conversation series with Alan Cooper, exploring the origins and applications of Goal-Directed Design (GDD). In Part 1 we rewind to the early 1970s when Alan was just starting out and the climate of programming and design was changing rapidly, forging the insights that led to the techniques of GDD. Part 2 brings us up to date with GDD as Cooper designers and teachers apply it today.
Last week I shared a number of trends, tech, and tips discussed at SxSW for harnessing physical objects and space within our digitally mastered world. But you might be wondering: “Patrick, why are you advocating making more crap we don’t need? Doesn’t that add to the complexity?” Clever you are. One of the most interesting trends we’re seeing in design is a move to not only smart defaults, but to intelligent ones that can manage that complexity.
The digital master of intelligence
Two talks convinced me that automation will play an increasing role in our lives. From an engineering perspective, Amit Kapur and Jeff Bonforte explained the powerful robot applications that run within our phones, our cars, and our houses. From a design perspective, former Cooperista Golden Krishna shared the design principles that might throttle us toward more interfaces-less interactions. Now three scenarios to highlight the difference between the human, the machine, and the automaton:
Yesterday we brought you designing strategy through a nonprofits eyes, ethical robots (depending on who you ask) and of course, the kegel organ. Here’s what we have in store for you today.
By Sara Cantor Aye (Greater Good Studio)
This year, in partnership with SAIC, Greater Good Studio designed a built a new public school cafeteria. Although that sounds like an architecture project, it really meant looking at the interactions between kids and food, staff, space, and other kids.
Kids will be kids
Sara Cantor Aye walked us through the process of researching elementary school cafeteria design in order to help schools serve healthier food, reduce waste and educate. Along the way, her team discovered some interesting things. For instance, kids want to eat what their friends eat and don’t deal with forced choices well (who knew?)
Making cafeteria food fun?
Their constraints were tough, but the breakthrough was going from a cafeteria line to serving courses to the table. The magic was in the discovery of unanticipated benefits; kids were finally eating their lunches! Cafeteria lunches were fun again, for students and staff.
The shared eating experience wins over all
By focusing on the kid’s experience, using head cams, interviews inside family homes, and observing the cafeteria, they discovered that kids waste food because they don’t deal well with many choices on their plate. They were able to have a shared experience by having one item served to everyone at the same time. Just like a restaurant.
Where do you start when you’re approaching a complex software design problem? If you work on a large development team, you know that software engineers and UX designers will often approach the same design problem from radically different perspectives. The term “software design” itself can mean very different things to software architects, system programmers, and user experience designers. Software engineers typically focus on the architectural patterns and programmatic algorithms required to get the system working, while UX designers often start from the goals and needs of the users.
In the spring of 2009, I participated in a research study that looked at the ways in which professional software designers approach complex design problems. The research study, sponsored by the National Science Foundation, was led by researchers from the Department of Infomatics at the University of California, Irvine. The researchers traveled to multiple software companies, trying to better understand how professional software designers collaborate on complex problems. At each company, they asked to observe two software designers in a design session. At my company, AmberPoint, where I worked at the time as an interaction designer, I was paired with my colleague Ania Dilmaghani, the programming lead of the UI development team. In a conference room with a whiteboard, the researchers set up a video camera, and handed us a design prompt describing the requirements for a traffic control simulation system for undergraduate civil engineering students. We were allotted two hours to design both the user interaction and the code structure for the system.
Jim Dibble and Ania Dilmaghani at the whiteboard in their research design session
Theory and Practice began the interview with two large questions.
Igor Gladkoborodov: In your blog you write a lot about the specifics of the post-industrial era. The new economy heavily influences all aspects of human life, and now we are entering an era of post-everything. I am most interested in the aspect of education, what can you say about the post-education era?
Anton Gladkoborodov: In the industrialized world, education was reduced mainly to the technology of working with a tool or a machine. Similarly, mental activity was usually reduced to a set of algorithms. Today, we need to raise another kind of worker, one that is more flexible and dynamic. However, modern education does not meet the requirements of modern times; it is still based on the principle of factories. What, in your opinion, needs to be done to education?
It’s a good, long conversation, and if you’re down with the Russian you can read the original at the Theory and Practice website. (Special thanks to our friends at Innova for providing the source translation for us.) Below we’ve excerpted some of the most interesting stuff, and arranged it so we don’t sound as jetlagged and meandering as we actually were.
Microsoft’s upcoming OS release, Windows 8, will finally replace a vital component that has remained largely unchanged for the last 30 years. It is the BIOS, and it has faithfully performed a simple but vital function: isolating the operating system from its underlying hardware. It quarantines all hardware-dependent code in one location with a publicly defined interface available to the rest of the operating system. BIOS is an acronym for “Basic Input Output System.” It was invented way back in the 1970s by the brilliant computer scientist Gary Kildall, and was one of the more important conceptual breakthroughs that led to the success of the personal computer. Bill Gates copied the BIOS idea in MSDOS and built his company on its strength.
Thirty years is a long time even for brilliant software, and the Windows BIOS has become both a security liability and a performance limiter. It is past time for a replacement, and the upcoming Windows 8 will ship with a UEFI instead of a BIOS.
The Unified Extensible Firmware Interface, or UEFI, is much smarter than the old BIOS and, in particular, it can detect boot-time malware. Of course, one way to define “malware” is “any other vendor’s product.” Microsoft has said that it will not use the UEFI to block legitimate software from other companies, but fears are rising in the industry that it will do just that.
Because most of the UEFI needs to be implemented by hardware vendors, it will be written and deployed by third-party developers, not Microsoft itself. If these third-parties want to earn Microsoft’s compliance certification, they must follow stringent guidelines. If these guidelines are followed, operating systems other than Windows 8 will not be allowed to boot up. In other words, if your computer, pad, or mobile is running the Microsoft OS, it will not run Linux or any other vendor’s OS.
This is not a particularly onerous limitation for about 99% of the human race. Very few people want to mess around with their computer at the operating system level. It’s complicated, dangerous, and unnecessary to do so unless you are a programmer. Ah, but if you are a programmer, it raises a significant question.
Programmers may not be large in number, but they are certainly large in influence. In the 1990s Microsoft rose to overwhelming dominance of the industry for the simple reason that it catered to the needs of programmers. What programmers believe is true affects what other people in the software industry believe, and they, in turn, influence everyone else. If programmers didn’t believe in Microsoft, then Windows would rapidly lose its hegemony as a platform.
In the last few years I’ve seen a remarkable thing: development shops using Linux hosted on Apple computers instead of Windows machines. I wrote about this almost a year ago on my personal blog. If I were Microsoft, I’d be very worried about losing influence in the developer community. Yet, with UEFI, it seems Microsoft is making it problematic to run Linux on Windows, and this may alienate even those programmers loyal to the Windows platform.
I’m sure that executives within Microsoft look warmly on the UEFI as a powerful mechanism for combatting what they view as competition. Too bad for Microsoft that the programming community doesn’t see it that way. This move could be Microsoft self-administering their own coup de grâce, sending their remaining stalwarts into the arms of Apple, and accelerating Microsoft’s descent into the irrelevant.
(Thanks to @BobMacNeal for technical editing)
The World Series is barely over, which means most of my thoughts this time of year get colored by baseball. Events in game five got me thinking about design exploration, of all things. I’ll try not stretch the metaphor too much.
I work throughout the year with product managers, technologists, and executives at companies ranging from small startups to Fortune 100 megaliths. Many of these companies have a vision for creating a game-changing product within their industry, “the iPhone of the xyz market.” They mean it, too. But as conversations progress and a project plan begins to take shape, many of the project owners start piling on technology constraints before any design work has even begun.
“We need to use these off-the-shelf components.”
“Don’t explore any solutions that won’t let us use our current technology platform.”
“Actually, what we really need is just a facelift of the presentation layer.”
Not exactly the words I imagine Steve Jobs used to drive the creation of the iPod and iPhone.
Sometimes this slow degradation of vision is a result of poor or conflicting communication…which brings me back to last night’s baseball game. St. Louis Cardinals manager Tony LaRussa, already a two-time World Series winner and owner of the most wins by an active manager, had a vision for which pitchers he wanted to be warmed up in the late innings of a tight ballgame. He called the bullpen coach (using a land-line telephone in the dugout), and, amazingly, not once but twice, the bullpen coach misheard LaRussa’s instructions and warmed up the wrong pitcher.
I don’t know if that’s happened before in a World Series game, but in the corporate world, we see the wrong product get sent into the game all the time. Executives have a vision for the future, but don’t clearly articulate it to the product owners (other than specifying a deadline which is often arbitrary and not tied to actual work milestones), so what gets built isn’t visionary at all but driven by the calendar…which means introducing lots of constraints from the beginning. The result may be an incrementally better product, but not a game changer.
We like the saying “reality bats last,” one of Alan Cooper’s original design principles. For us that means for any design we create to actually be a solution, it needs to be buildable by our client. It has to live within their unique technology, price, deadline, and resource constraints. However, we have been pushing more and more for the opportunity with our clients to do at least some unfettered, unconstrained design exploration on every project, even ones that have a narrow scope. We don’t completely ignore constraints (especially things like regulations which are out of our client’s control), and we won’t explore designs that rely on telekinesis or nuclear fission, of course. That said, we will definitely push the envelope on what’s possible—for a few days or even up to a week—so we can begin with the mindset of the absolute best experience for the user. Over the course of the project we’ll push to achieve as much of this game-changing vision as we can.
Allow some your design team to let their imaginations run wild before they get saddled with constraints. (photo by Peter Duyan)
Typically, the output of this design exploration is a collection of hand-drawn sketches that target key plot points in the most important scenarios, and signature interactions (parts of the system fundamental to the experience). The sketches often explore a range of ideas, some that can be implemented within all known constraints, but also others which may bend (or break) constraints. After that, it’s really a business decision our clients need to make about how to proceed. Sometimes it makes sense to restructure deadlines, add resource, buy a technology, or abandon a legacy infrastructure to get that “killer app.” Other times it doesn’t make sense…but as designers it’s our job to imagine the future and enable business decision makers to make the most informed decision they can.
Which brings me back to baseball. You are the manager of your company: what’s your strategy? Reality is a heavy hitter, but it shouldn’t bat in every slot in your lineup. Can you really afford to play it safe every game? Even if your competition is miles behind, spending time to imagine a better future for your product will position your company to more nimbly take your offering to the next level when constraints go away.
And while you are at it, I would recommend upgrading those bullpen phones. Read More
Franklin Delano Roosevelt, in his inaugural address as the 32th President of the United States, uttered his now famous phrase “The only thing we have to fear is fear itself.” How right he was.
He further identified his target as “nameless, unreasoning, unjustified terror.” He spoke early in 1933, during the darkest days of the American depression, when millions were out of work, no safety nets existed to help them, and there was no recovery in sight. What’s more, the specter of European Nazism, with its saber rattling, and strident, irrational racism, was waxing. In the face of these actual reasons to be afraid, Roosevelt fingered the real danger: irrational fear; fear for its own sake; being afraid simply because it’s easier than not being afraid.
Largely, the nation heeded Roosevelt’s admonition. We refused to succumb to fear, the economy recovered, we vanquished our foes, and emerged as the world leader for the rest of the 20th century.
Unfortunately, in the 21st century, we have quite failed Roosevelt. We have become a terrified nation and live in a culture of fear. We act afraid and we let baseless fear drive our choices. Mutual trust is the basis of civilization, and our nameless, unreasoning, unjustified terror is unraveling the fabric of our society.
Startups don’t have capital to burn or luxurious schedules for big-design-up-front. But unless your idea is by-and-for-engineers, design isn’t something you want to skip on your way to market. For a startup, design may mean the difference between simply shipping, and taking the market by storm. But with tight budgets, and aggressive timelines, how to include design and get the best value for the investment?
Eric Ries proposes a cyclical model for development in a startup: Build > Measure > Learn (repeat). Lots of smart people think he’s onto something. While Ries coined this model to explain how developers work in a lean way, the same model can be applied to design, only our “build” uses different tools, and the work products are at a different fidelity, but it’s still build. Our hypothesis is made manifest and testable.
In a recent Lean UX workshop hosted by the fantastic Janice Fraser (Luxr) and Cooper’s own Tim McCoy and Suzy Thompson (also of Cooper) suggested that the cycle was right, but that it begins in the wrong place. She suggested Learn > Build > Measure (repeat).
I buy it. After years of starting projects off with research (as little as a couple of hours in some cases) I’ve seen the power of starting off informed. Framing the problem before you start solving it is not only wise, but major opportunities for innovation often arise before anyone proposes a design solution.
So we have a cycle of Learn > Build > Measure (repeat). For a startup we can’t afford weeks of research, with the developers on the bench waiting for the voice of the user with thoughtful diagrams and artful persona back-stories. We need full-speed-ahead; design can’t afford to be the slow kid or the bottleneck.
How fast can we run the cycle? I’d suggest that design can run at a sustained pace of 3 days for a complete cycle. I don’t think you could do useful design faster. We often take 5 days for a cycle where we have time and budget, but 3 days is about the fastest you’d productively move. It bears noting that it takes a remarkably agile client to keep up with a 3 day cycle. Early stage startups with focused stakeholders and unlimited access to users for testing are the most likely to keep up with this pace. Larger enterprises benefit from a slower 5 day cycle.
Once we get the upfront work of personas and high-level scenarios done, cycles take on a regular pattern.
What do we get? Speed and low waste. We iterate quickly, with a 3 day cycle time we get moving quickly, we get rapid insights up front, ideas almost immediately up on the board, and pixel proofs within 24 hours. Sure they’re rough, but we don’t need high fidelity to test if the direction works, if users and stakeholders are getting what they need. All we need is something that gets the idea across. We’ll refine as we get deeper. And because we’re not letting design get too far out before getting it in front of users we’re keeping waste to a minimum. Our ideas will be tested early and often. We can throw out what isn’t working after a low amount of investment and focus our time on what is.
At this point the major win for startups is speed; design is incorporated without slowing things down. We also reap huge benefits from operating with such a low waste level. Days and dollars are spent building and refining the solutions that are most promising. But speed has a downside, we have little time to solve more complex problems. This may result in grabbing for obvious or standard patterns where a more thoughtful innovative approach might ultimately yield a better product. Also, design is an iterative process, the rapid cycles may seem like iteration, but the speed leaves little opportunity to revisit or reject and rework something. The first solution may easily end up the final solution. This may be acceptable for some projects, but when a startup is striving to innovate, it’s not enough to be first, you really need to deliver better.
There’s a way to supercharge this process in a way that produces predictably better solutions, and more of them. Add a second interaction designer. Pair design transforms the equation, from pure speed, into rapid insight that one designer with twice the time couldn’t produce. It’s not a case of twice as much in the same amount of time, speed isn’t increased, we’ve already maximized that. What we’re maximizing now is the quality. Two designers working together, paired in the right way delivers more, and better design.
The way we do pair design it’s not just any two designers locked in a room, struggling to wrestle the marker away from one another to prove how much better their idea is. We pair two interaction designers to maximize on the energy in polarity. We divide and conquer. One takes takes on the assertive role, the other the reflective. One takes on the drawings and interface, the other the patterns and words. One dives into details, the other keeps the big picture. One presents, the other captures. Through pairing and focusing on polarized responsibilities, we increase the value of the thinking and the product.
Let’s start with the first cycle:
While interviewing users and stakeholders we’ve got two observers, two sets of ears, two perspectives on what was learned. Our understanding is richer, fuller and more complex than any single practitioner could bring.
Build (personas/scenarios/early sketches)
One of our pair takes on the role of generating ideas, proposing solutions, getting something onto the board. The other is a dedicated thought partner. They hold back, poke holes, prompt, help evolve the ideas while they’re still forming. It’s a period of intense, rapid iteration. Roles can and do swap. We go wide, exploring much more quickly than a single designer could. Bad ideas are killed earlier. We develop clarity more quickly. We’re more confident of our decisions and more articulate about our reasons because they already went through the crucible of our partner.
Build (pixels and patterns)
Our pair differentiates further. One jumps into putting the ideas into pixels, the other into articulating the patterns that underlie the design decisions. Each works from the earlier design work, but refines it in very different ways. As we push our design though increasingly detailed scenarios it evolves. The two different approaches helps us triangulate on places where the design fails, and helps to identify fresh new opportunities. Two brains churning on the material coming from different directions, forces us to see more objectively, we can’t remain blind to the ideas we love that should be thrown out. The paired design team acts as an editorial cross-check on the thinking of the other. A single designer would be forced to choose between pixels or patterns, or struggle to articulate both poorly.
Measure (stakeholder/user feedback)
Pair designers divide up the work, focusing on a single aspect, presenting or capturing. One walks users through the flow, the other observes and captures notes. It doesn’t matter who’s doing what but each role is dedicated and focused. One designer would struggle to demo the design and really notice how users’ actions diverged from their verbal feedback, often critical distinctions which when noticed strongly inform future design decisions. With a pair of designers we capture the feedback accurately. We also have two perspectives on each test. We are less prone to fall into our own bias because we’ve got someone to check us.
More, better, faster is an investment
By pairing designers, we gain tremendous advantages. You’re running a startup and it’s easy to buy the process of a speedy cycle. It’s simple math and it maximizes cash, with quick early results. At first the idea of pair design may seem like a hard thing to sell to your board or investors. “Twice the designers, huh? Can’t we just get one and do more cycles?” Sure, people do it every day. But one designer doesn’t make more, better. Even a rock-star designer can’t generate enough polarity to come close to the “more, better” brought by two damn good designers who know how to work together as a pair. You buy a pair, you get more design; not twice the volume, but twice the quality. This isn’t that fine-china sense of quality, but the kind of quality defined by pure raw goodness. It’s the quality of solutions that people fall in love with. It’s the ephemeral but very real sense when you first make contact with the product that someone really truly understands you. Not all problems need or deserve this level of attention. There’s many times when one designer may perfectly address the need.But when your startup wants to design more, better, faster, go all the way, invest in it. Expect faster, and demand more, better. Your investors will want it too.
- Take the Design Leadership class
- Lean UX workshop recap
- Lean UX, Product Stewardship, and Integrated Teams
- Integrating solve and do
- Explaining pair design (metaphorically)
(This was originally published on Playwell, Alan’s personal blog.)
Elisabeth Hendrickson has recently opened a new test-and-development training facility in Pleasanton CA called Agilistry. It’s bright and airy, well-lit and well-stocked, and it feels like home the minute you walk in. In order to publicize her new facility, she very generously hosted a week-long intensive learning exercise.
She invited eleven different people with widely varied skill sets, backgrounds, and interests. She challenged them to build a website in five days using the best practices of interaction design, agile programming, and test-driven-development. We christened it “AgileUpToHere” (#au2h) and it exceeded everyone’s expectations (you can see our results here).
Since it was my 15-year-old homophone web site that was being rebuilt, I nominally played the role of product owner, but I was an observer, an instigator, a goad, and a participant. It’s hard to remember when I had so much fun or learned so much. If you want to learn to be great, I strongly recommend Elisabeth and Agilistry.
Things I learned:
- After 25 years, it’s time to lose the Windows computer and get a Mac.
- Good agile developers are self confident; confident enough to trust interaction designers to do interaction design without distrustful oversight.
- There are lots of programmers who understand that relational databases are not the only approach to solving problems.
- It is time to build software.
- Test-driven-development isn’t fully understood. In fact, software testing isn’t fully understood.
- When even the leanest developer in the room sees really high quality BDUF (big design up front) for the first time, they get all woo-woo and want some for themselves.
- Getting good software built demands the contributions of many different personalities, competencies, and roles, most of which are new and as-yet ill-defined.
- Two programmers pairing can create more and better code in less time than one programmer can (I already knew this, but it’s always good to see it in action).
- Even this jaded old fart can still get excited about changing the world.
- There are many undiscovered and unfilled product niches on the Web, and one of them is “quality”.
- People want a leader with a vision.
- Elisabeth Hendrickson (@testobsessed) is a magical woman. To paraphrase Tom Robbins, “she’s been around the world eight times and met everybody twice.” Like a great chef or symphony conductor, Elisabeth knows how to combine the unexpected to create the sublime. She brought together a dozen people from all over the country, each with different skills, background, desires, and expectations, and then she blended them together into a cohesive, happy, effective team.
- The pre-written code I arrived with was called “legacy” with a grimace, and was quarantined until discarded. Moral: Non-TDD (test-driven development) code is properly regarded like a ticking time bomb.
- For interaction design, you can’t have too many white boards, made from porcelain-coated steel, firmly mounted to the wall. For agile development, that isn’t such a big deal.
- Story-mapping is a major component of the bridge between interaction design and agile development.
- Story-tracking software isn’t quite there yet.
- Agile (24)
- Architecture (10)
- Automotive (5)
- Awards (4)
- Books (17)
- Branding (17)
- Business (55)
- Classes (40)
- Clients (14)
- Communicating design (50)
- Cooper (61)
- Cooper U (65)
- Critiques (47)
- Culture (4)
- Design & engineering (31)
- Design disciplines (15)
- Design in organizations (58)
- Design principles (49)
- Design the Future (12)
- Drawing Board (9)
- Education (40)
- Events (79)
- Experience design (54)
- Features (101)
- Financial services (13)
- Games (4)
- Humor (21)
- Industrial design (16)
- Information design (26)
- Innovation (71)
- Interaction design (160)
- Interaction patterns (20)
- Interface Design (19)
- Journalism (5)
- Leadership (6)
- Media (14)
- Medical (25)
- Methods (33)
- Mobile (34)
- News (32)
- Newsletters (34)
- Personas (37)
- Platforms & technology (22)
- Presentations (19)
- Product definition (16)
- Prototyping (7)
- Requirements (8)
- Research (37)
- Service design (30)
- Startup (9)
- Strategy (33)
- Sustainability (13)
- Tablet (13)
- Techniques (70)
- Travel (12)
- Trends (40)
- TV (6)
- Typography (7)
- User experience (28)
- Video (11)
- Visual design (50)
- Web (34)