UX Boot Camp with Marketplace Money

Old School Radio Meets the Digital Age

Take a look inside Cooper’s June, 2013 UX Boot Camp with American Public Media’s Marketplace Money radio show, where students explored the next horizon of audio programming—a paradigm shift from broadcast to conversation-based platforms.

The Challenge
Students rolled up their sleeves to help the show respond to the trend away from traditional radio by finding the right mix of alternative distribution platforms. Marketplace Money came equally ready to take a radical departure from their current format in order to create a new model that redefines the roles of host, show, and audience in the digital age. To reach this goal, students focused on designing solutions that addressed three big challenges:

  1. Engage a new, younger audience that is tech savvy, and provide easy access to content via new platforms, such as podcasts, satellite radio shows, and the Internet.
  2. Inspire audience participation and contribution. Facilitate conversations and inspire people to share their personal stories so that listeners can learn from each other.
  3. Design ways for the host to carry an influential brand or style that extends beyond the limits of the show and engage with the audience around personal finance, connecting with listeners in ways that are likeable, useful, and trustworthy, making the topic of personal finance cool, fun and approachable.

At the end of the four-day Boot Camp, student teams presented final pitches to Marketplace Money, and a panel of experienced Cooper designers offered feedback on their ideas and presentations.In the following excerpts from each day, you can test your own sensory preferences for receiving content as you see, hear and read how design ideas evolved at the Boot Camp, inspiring new relationships between people and radio.

Marketplace Money Class

Read More

Interaction Design for Monsters

Whew. That was close. As every year, there’s a risk that we’ll be overrun with with zombies, werewolves, vampires, sasquatch(es), and mummies before the veil that separates the world seals tight for another year. But a quick tally around the Cooper offices shows that here, at least, we all made it. Hope all our readers are yet un-undead as well. While we’re taking this breather, we’re called to reflect a bit on this year’s interaction design for monsters.

Monsters are extreme personas

One of the power of personas is that they encourage designers to be more extrospective, to stop designing for themselves. Monsters as personas push this to an extreme. It’s rare that you’ll ever be designing technology for humans who can’t perceive anything, can’t speak any modern language, live nearly eternally, shape shift, etc. But each of these outrageous constraints challenges designers to create a design that could accommodate it, and often ends up driving what’s new or special about the design.

But then again…

Some of the constraints of the monsters are human constraints writ large (or writ strangely).

  • Juan wasn’t a useful person in and of himself, but his users exercised flash mob requirements of real-time activation and coordination. Are there flash mob lessons to learn?
  • Emily was fighting a zombie infection, but real-world humans are fighting infections all the time. Is there something we can use for medical interfaces?
  • Metanipsah has no modern language and a mechanical mental model, but most of us have mobile wayfinding needs at one time or another.
  • The Vampire Capitalists behind Genotone took the long view, reminding us of burgeoning post-growth business models.

So maybe they’re great personas after all, guiding us to great design because they’re extreme, just like the canonical OXO Good Grips story, where designing for people with arthritis led the design teams to create products with universal appeal.

Read More

Questions for new product inventors

As the creator of a new app or website, you are intimately familiar with its purpose and you believe deeply in the value it offers. But unlike you, when a new user arrives at your app or site for the first time, he will be neither familiar with it nor confident of its value and trustworthiness. It’s your program’s responsibility to make the new user comfortable, knowledgeable, and confident about its purpose in the first few moments they are together.

It’s very much like when two strangers meet on the street. Even if both parties have good intentions, it is imperative that these intentions be made abundantly clear and unequivocal before any significant interaction can take place. Eye contact, hand shaking, and smiling are the cues used in real life, and the web designer must provide equivalent cues on the screen.

When someone sees a website for the first time, several important questions come instantly to mind. The first, and most important, question is, “What the hell is this thing?” The program should answer that question using no more than a phrase. Sometimes the product name is sufficient, but typically a subtitle or image does the work, but if your program doesn’t make this clear in a glance, you have some significant design work to do. It is surprising to me how many websites fail to answer this most fundamental question.

The next questions that will occur to the user are, “What does it do?” and “Why would I want that?” At this point, some text can be used to provide answers. Lighten up the text with a diagram, drawing, or image. You don’t necessarily want to burden repeat visitors with this stuff, but your software can easily tell the difference between a first time user and a veteran.

Once the user knows what the website is, what it does, and why that would be a good thing, he or she can understand the advantage of having such a product. So now she will be more willing to pay closer attention to more granular questions, such as, “Wouldn’t it be easier to just use something else I already know?” Here’s where the site can offer comparisons to similar products and itemize its qualities. Any potential user will be weighing the benefits of your program against the burden of learning something new. Make your program easier to learn and use, then prove it.

At this point, the new user is likely asking himself, “Is this going to cost me money?” and, “Do I have to give it a credit card?” Be up front about this now. Don’t be coy by only telling the user that money is involved after they have pushed the “Yes, I Accept” button. Tell them now and disclose the full amount. Honesty now will result in more trust, which means more click-throughs and more happy users.

Everybody knows that money isn’t the only thing a website can cost. Experienced users will ask, “Will it steal my private data?” and “How long is this going to take?” Once again, take the time to honestly and completely answer these questions. Give the user the option to use the program without surrendering their private information. If they like your program and use it regularly, you can ask them for it again in a month and their answer might well be different.

Good user experience design will keep any user’s time overhead down to a minimum, so you should be able to give them good news in the beginning. Saying something like, “This takes the average user 43 seconds.” Big picture information like this goes a long way towards assuaging the user’s worries.

After your website and the new user have performed this little pas-de-deux of introduction, the human at the other end will be far more likely to end up being a satisfied, long-term user of your program.

Image source: Nightdeposits. Read More

Strategies for early-stage design: Observations of a design guinea pig

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-and-Ania-at-the-whiteboard.jpgJim Dibble and Ania Dilmaghani at the whiteboard in their research design session

Read More

If you want a game-changer, you need to change the game

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.

Design exploration
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

Platfora website debuts!

Platfora, a new startup in the Hadoop business intelligence space, is working with Cooper to design an elegant, intuitive interface to bring clarity to the chaos of big data.

After Platfora received 5.7 million in funding from Andreessen Horowitz; Cooper worked on a rapid, collaborative two-week timeline with a team of five designers to create their website, www.platfora.com. Platfora CEO Ben Werther said, “we wanted to convey the clarity and simplicity that we are striving for in our product experience — without showing actual screenshots. Cooper’s design work on our website conveyed this message perfectly.”

Credits: Jim Dibble, Golden Krishna, Martina Maleike, Doug LeMoine, Nick Myers

A clean sans-serif designed by Minneapolis type foundry Process combined with rich, vibrant visualizations designed by the Cooper team combine for a unique and beautiful site we’re proud to have been linked to in the Wall Street Journal, TechCrunch and New York Times.

Immediately after launch, the site received rave reviews on Twitter:

See the site at www.platfora.com.

Related Reading

Read More

Updated Cooper U Course: Design collaboration & communication

Cooper UAt Cooper, we have long stressed that designers should have a seat at the product development table, along with business people and technologists. Each member of this triad brings unique insights to product development: business people assess what is viable in the market, technologists address what is technologically feasible, and designers focus on making products that are useful and desirable to users:

Over the years, client organizations have taken this advice to heart, with more and more forming user experience teams that focus on assessing and meeting user needs. However, just having a seat at the table is not enough. As designers, we can help shape and facilitate the overall conversation.

To bring designs to fruition, designers need to collaborate effectively. While technologists and business executives value design, they often sense that design decisions are subjective and arbitrary. To get buy-in, designers need to help their partners understand design rationale and decision-making. Through collaboration and communication, designers can ensure that all team members have a shared understanding of the stakeholder objectives, the user needs, and the intent of the design.

Cooper now offers “Design collaboration & communication,” a course that sets the stage for collaborating on design and communicating design decisions. In two days students learn how to involve others throughout the design process, so that the design vision is agreed upon each step of the way. Communicating design throughout the process reduces the likelihood of other team members misinterpreting or altering the design during development.

The course covers the following topics:

  • Designing workshops to conduct with stakeholders to ensure a shared product vision
  • Choosing appropriate research methods
  • Involving others in research synthesis
  • Prioritizing what should be built based on business objectives, technical constraints, and user needs
  • Articulating the value and benefit of design decisions
  • Defending design without becoming defensive
  • Determining the right level of documentation for your development process
  • Moving the discussion from features and functionality to user goals and business goals

Whether you follow a traditional waterfall model or an agile development process, the communication and collaboration techniques in this course can help you gain buy-in for your design decisions.

This course provides great techniques for designers who want to create buy-in and build credibility within their organizations. The course is also great for cross-disciplinary teams of designers, product managers, and developers who want to communicate more effectively.

Our next public offering of this new course is July 25 & 26, 2011 in our San Francisco studio. A Cooper designer can also deliver the course at your office, and the content can be tailored to fit your particular needs around design planning and collaboration.

Read More

LeanUX workshop recap

In partnership with Janice Fraser of LUXr, Cooper hosted a two-day workshop to share our emerging thoughts around lean user experience and agile product stewardship with a group of designers, developers, and product strategists from Cooper, Adaptive Path, Hot Studio, 500 Startups, and several other organizations.

luxi day 1.jpg

We spent the first day exploring the intersecting arcs of lean startup, customer development, user centered design, and lean and agile development. Each of these approaches to making software look at the puzzle from a unique perspective: lean startup and customer development come from the world of business and entrepreneurship; lean and agile development practices strive to build healthy collaborative teams and coerce order and purpose from the sometimes chaotic world of programming; user centered design emphasizes understanding and empathy for people served by the software we create. Lean UX and product stewardship seeks to weave together best practices from all of these approaches.

Material from first day of the workshop is available on Slideshare.net at


luxi day 2.jpg

The next day, the group put their new thinking to work helping Change.org envision and clarify a new initiative. It was fascinating to see founders of early stage startups and consultants to Fortune 500 companies find common ground in their approaches. Some were learning to recognize the particular value of narrative to provide context around features, others identifying places where their existing processes could be more lightweight or robust. When we were done, the fine folks of Change.org had three promising approaches and everyone understood a little bit more about how to move our practice forward.

I’ll have much more to say about the ideas and practices behind lean UX and agile product stewardship and I’m excited about sharing our experiences and learning from yours. Read More

Things I learned at Agile Up To Here

(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:

  1. After 25 years, it’s time to lose the Windows computer and get a Mac.
  2. Good agile developers are self confident; confident enough to trust interaction designers to do interaction design without distrustful oversight.
  3. There are lots of programmers who understand that relational databases are not the only approach to solving problems.
  4. It is time to build software.
  5. Test-driven-development isn’t fully understood. In fact, software testing isn’t fully understood.
  6. 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.
  7. Getting good software built demands the contributions of many different personalities, competencies, and roles, most of which are new and as-yet ill-defined.
  8. 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).
  9. Even this jaded old fart can still get excited about changing the world.
  10. There are many undiscovered and unfilled product niches on the Web, and one of them is “quality”.
  11. People want a leader with a vision.
  12. 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.
  13. 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.
  14. 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.
  15. Story-mapping is a major component of the bridge between interaction design and agile development.
  16. Story-tracking software isn’t quite there yet.

Read More

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.

Read More