Wednesday, April 08, 2009

Why Designing Products and Services is a Team Sport

It takes a team to produce a product - even at Apple ...
"A few years ago, I conducted a study for a high-end musical keyboard company.The study involved watching users take a new keyboard out of the box and try and set it up. This particular keyboard had the capability of connecting directly to the Internet, but no participants in the study could set up this connection.

The problem, I realized, was that this feature had been tacked on late in the development process and the display and input hardware were not modified to accommodate it. So you ended up accessing the internet using an old-school ATM-style interface (buttons on the side of the screen referring to options within the screen) and typing with a jog dial, one letter at a time. Watching someone spend 6 minutes entering their email address is an excruciating experience.

While it was certainly a painful thing to observe, I wasn't surpised by the product's design shortcomings. Most consumer electronics products tumble through a dizzying process that introduces several opportunities for such mistakes: Business owners assemble requirements, designers specify the system, another group engineers the hardware (distinct from the group writing the onboard software), outside manufacturers produce the product, and a team of marketers figure out promotional details. This lack of cohesion leads to confounding products that perpetually blink "12:00."

It's not just product companies, either. Service firms are just as susceptible. For another project, I conducted field research to inform the design of a Website for a financial services firm. We found out that customers were having challenges not just with the online experience, but with the monthly paper statements and the call center experience as well. When broaching this to our client, their response was that they had no interaction with the teams responsible for those components of the service. You had to go all the way up to the CMO before you had a holistic view of the offering.

Most of today's design products and services are so complex they require input across silos. This leads to scattered departments where efforts are stitched together by a product manager. What's worse, each department has different measures of success. Marketing works to increase leads and brand perception; product managers strive to be on time and on budget; engineers want to meet requirements; manufacturers focus on minimizing defects; designers aim for useful, usable, and desirable products.

Ideally, these measures would balance to create a superior product. Realistically, all of those disparate objectives often conflict, leading to one of three results:

1. "Design by committee," where, in an effort to achieve consensus, innovative impulses are dampened

2. "Design by accretion," where products are cobbled together in a serial fashion, each department contributing without regard to what the other groups are doing (what happened with they keyboard), or

3. "Design by gauntlet," where projects are subject to so many approval processes that they are often stalled before shipping.

So how can you avoid the blinking "12:00" products and the fragmented efforts that produce them? In the world of products, we see that focused, multidisciplinary teams deliver the best experiences. I interviewed Margaret Schmidt, Vice President of User Experience and Research for TiVo, for our recent MX Conference, and she stressed how the engineering, product management, and user experience teams eschew departmental hand-offs and reviews. Instead, product managers, marketers, designers, engineers, and user advocates work closely on a single project.

In his book Inside Steve's Brain, Leander Kahney explains Apple's design and development process: "Under Jobs' guidance, products are developed through nearly endless rounds of mockups and prototypes that are constantly edited and revised. This is true for both hardware and software [and their retail stores, it turns out]. Products are passed back and forth among designers, programmers, engineers, managers, and then back again. It's not serial."    (Continued via, Peter Merholz)    [Usability Resources]


Post a Comment

<< Home

<< Home