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

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

When is design done?

“We don’t finish the movies, we just release them.”
– John Lasseter of Pixar

It’s easy to think of design as an ongoing iterative process, a constant refining that never reaches an objective “end.” It is especially easy to think of software in this way. Because code isn’t static, design of software is relatively dynamic, able in many situations to alter direction or incorporate new functionality without overturning initial design-framework decisions. While this can be true, it is also possible for design to reach a state which is done. Not simply done for the next release, but where design reaches finality. The design no longer carries the evolution of the product forward.


Once design reaches a stage in which the difference between versions is more window-dressing, or a change in interaction approach, rather than a realization of deeper functional improvements, design is done. When the ideas on how to improve a design no longer come, when the designers can no longer see a way to improve the idea, it is done. It isn’t that someone else couldn’t take the idea and evolve it, but that the stewards of the design reach a point where their collective imagination can’t move the product forward.

Design which is not done

It’s easy to find examples of design which isn’t done. Lots of first generation software is released delivering basic functionality. Later versions fill out with functionality, growing to meet the latent potential in the first version. This design isn’t done.

Early designs of Evernote promised much more than was delivered. Successive versions cast and recast the design until the initial flaws could be worked out. Early versions provided little more than a limited word processor that stored stuff in the cloud. The interaction paradigm was a little strange and frustrating. Evernote continues to be a design in process. Functionality continues to evolve and improve with each release; the design isn’t done.

Mature software may not be done either. Photoshop versions 5, 7 and 8 delivered significant design shifts. Paradigms for working with text, the inclusion of vector images and interface for handling of RAW images marked major departures from previous versions. As an 11-year old product the design of Photoshop accomplished remarkable adaptation and revealed the “incompleteness” of prior designs. Of course the design leveraged advances in technology which were not available for earlier versions, but that’s the point. The design wasn’t done, design could still be used to improve the program, to advance what it did and how it did it.

Design of non-software products may also reveal a level of “not done.” A baby stroller from BumbleRide is “done” in the sense that you can purchase one and it works. The design is largely coherent and shows evidence of finish. But even here the design isn’t finished. A comparison of the 2008 and 2009 versions shows significant advancement of the design even though each of the versions was sold as a completed design. Wheels gained quick-release, the safety harness adopted a single button release, and the sun hood extended for more coverage. So is the design done now? I’d argue no. Improvements in ergonomics, materials, and signage all provide ripe areas for the design to continue to evolve.

When it reaches “perfection”

Design isn’t done when it reaches a pinnacle of efficiency or goodness. Done isn’t really a measure of quality or perfection. Many products never reach any level of quality or refinement. They represent evolutionary dead ends, still-born ideas with no potential in which to grow. They are poorly conceived, even if executed well. Crappy products may arguably be done before they are ever built or coded. The lack of vision from the start dooms the product to an evolutionary dead-end before it’s even born. If perfection is the measure of done we don’t have any way to agree on what is perfect or good. Perfect doesn’t give us a way to evaluate done.

When it feels done

Subjective evaluations by the creator may be acceptable in the realm of art. Artists work until the piece is “done;” till they feel the idea has been expressed. Design of products whether software or hardware need more objective measures than feelings. In part, designers need this because the act of creation relies on a whole team, not just an individual. We also need measures because products exist in a marketplace; there are deadlines, ship dates, feature sets, marketing and sales efforts, which require more clarity around when the design will be done.

When the time or money runs out

For consultants, work is “done” when the contract (time) is up. Projects are scoped to meet specific deadlines and requirements which fit those timelines. Design deliverables are iterative, each pass we give moves a level deeper and we work out more of the design details. We give great value for our time, but design is “done” when we run out of time. Our design is rarely done in the sense that every detail has not been worked out, all the possible problems have not solved. We work down from larger more fundamental patterns and frameworks, iteratively filling in the details. The big picture may be done when we deliver, but often it is internal product owners or developers who will actually “finish” the design.

When the requirements are met

It could be argued that design is “done” when the initial requirements have been met. It’s done enough to release a version, but it’s not really done. After the product ships the design team refines the design, adding in features or fixing issues which shipped in the previous version. The designers work to fulfill the full potential of the product. As long as their work produces advancements the design isn’t done.

When innovation plateaus

Design is done when its evolution plateaus. A couple of versions are released with little more than rearranging the deck chairs. Rework or changes to the interface reflect passing fashions rather than fundamental shifts in direction or functionality. Innovations in the marketplace or in technological breakthroughs are not incorporated or addressed in the design. Evolution grinds to a halt, the product ceases to advance in meaningful ways.

Design continues on many products long after the design is done. Design effort is wasted in chasing a market rather than leading one. Products become bloated with features which compromise the clarity achieved when the design reached “done.” Features are designed which don’t evolve the product; they complicate the vision reaching to be all things to all people, ultimately hobbling the product. The design of Microsoft Word has delivered little beyond version 5.1. It is a quite usable word processor, but the design for word processing was solid in 1991, in the subsequent releases little was advanced. Features where added that did little to improve the word processing experience. The design also failed to take advantage of shifts in the marketplace or technology. Five versions later Word is still largely a pretty good word processor. While much has changed in the interface switching interaction paradigms from menus to the ribbon can hardly be thought of as a fundamental shift in functionality. Word hasn’t evolved so much as changed it’s wardrobe.

Some products manage to react to changes in technology or marketplace. The design accommodates changing needs and opportunities. The product evolves through design to include new functionality, utility and continues to add life to the product. While Adobe Acrobat Pro has struggled with its share of bloating and incessant updates, the design of the program has continued to evolve. From humble beginnings of a reader/writer for portable documents, Acrobat has incorporated new functionality unimaginable when the product was initially designed; OCR of text, automatic creation of interactive forms, document markup, digital signing and distributed workflows. The integration of this new functionality has stumbled at times, but Acrobat X delivers a coherent, usable evolution of a product that is more than 17 years old. What was just latent potential in the embryonic design of the first versions of the product has been realized.

Some products are so deeply bound to a specific paradigm that the only reasonable evolution is an entirely different approach. The original design is done. A new product, with a different design, is created to address new technology, and a new marketplace. The original iPod‘s design is done. The scroll-wheel/menu design of an mp3s player was groundbreaking and brilliant, and it was well-executed. At some point it became clear that this design was done; it couldn’t evolve while maintaining the same core design. The only road forward was to abandon this “done” design, and adopt a new paradigm. The result was the iPod Touch. The shift was more than simply adding a bigger screen with touch input; what the product could do radically shifted.

Why does it matter?

It is important to acknowledge that design can reach a place of “done.” If we don’t, we may end up fooling ourselves that we are moving products forward when we are really just treading water. If we can’t step back and evaluate whether a design is done, we may continue to put effort into a product which we can’t improve. We will continue to release products that don’t help people achieve their goals, or worse–damage great products by bloating them with features no one needs. Knowing when the design is done allows us to recognize when our efforts will be productive and when our efforts will be wasted. When design is done it’s time to move on, to take up new challenges or products and start designing again. 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

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. Read More

Predictably Irrational

Behavioral economist, Dan Ariely’s delightful first book, Predictably Irrational, heaps yet one more shovel of dirt onto the fresh but deep grave of traditional, rationalist assumptions about human behavior. The book is a simple, personal, easy-to-read account of Ariely’s research conducted over the past 15 or so years. This research was conducted at his various host universities; all of them paragons of ivy-covered scientific rigor, including MIT, Stanford, The University of Virginia, and The University of California at Berkeley.

The clear and inevitable conclusion of his dozens of research papers summarized in this book is simple: humans don’t make rational decisions. What’s more, the irrationality of their choices isn’t random, but can be predicted and measured. While many of the experiments deal with choices regarding cash, several of them cleverly divorce themselves from money to clearly demonstrate that the goofy human behavior is human-related, not cash-related.

He identifies several predictable forces that act upon humans during decision making, causing them to make irrational choices. These include the distorting effect of similar, but slightly inferior, products offered for sale; the distorting effect of simply thinking about numbers; the distorting effect of items offered for free; the distorting effect of sexual arousal; social norms, ownership, procrastination, self-control, clinging to options, expectations, and being observed. Read More

Bridging the gap with requirements definition

Developing a new product or service is tricky. When everything goes well, the product can redefine a market or even create an entirely new one, to the benefit of its manufacturer and its consumers. When the product doesn’t click with its audience, though, the costs—development, employee, manufacturing—can be staggering. How do you ensure that your new product doesn’t flop? One effective method is to conduct a requirements definition phase before developing a new product.

Requirements definition simply means "figuring out what to make before you make it." This process is not unique to software products. Architects, for instance, go through a requirements definition phase before they start construction on a home. They talk to the future home owner and determine how many floors and rooms will be in the house, where the bedroom should be, if there’s a deck, and so on. Similarly, in the product development world, requirements definition enables you to make appropriate decisions about the functionality and design of a product before you invest time and money developing it. By bridging the gap between the needs of the market and those of your organization, requirements definition significantly reduces guesswork in technology product planning, and helps ensure that business and engineering are working on the same product.

Read More