Last week, I joined entrepeneur Enrique Allen and designer Leslie Ziegler at Kaiser, where we spoke to doctors from their internal innovation program. We hoped to inspire them as well as to illustrate how design could be used inside Kaiser to improve processes and overall care.

I referred to two case studies—Cooper's work on the Practice Fusion iPad-based EMR, and a visioning project around the patient clinic experience. In these, I illustrated how we identify problems, generate ideas, and drive decision-making during detailed design.

Both case studies highlighted ways in which multidisciplinary teams can make progress by using cheap prototypes that are quickly iterated. In the case of the Practice Fusion app, we used paper prototypes to test and evolve everything from content organization to animation. We did not need to get permission of a hospital IT staff or work with an engineer; we simply needed a new piece of paper and a Sharpie. Prototyping a service starts in a similar manner. Using storyboards and cartoons, we were able to generate and evaluate myriad patient journeys without making costly process and staffing changes.

Many of the questions during the Q&A were symptomatic of a large organization that is beholden to fluctuating regulation. One attendee asked how to get front-line staff on board when they're already suffering from change fatigue. This will require both communication and empowerment. At Cooper U we teach the value of a radiator wall (a wall showing the progress and decisions of a project) in rallying a team and communicating with an organization; this kind of tool could help establish a sense of consistency and direction amid large-scale changes.

All of Kaiser's departments were represented at our talk, from general practitioners to specialists. All are charged with improve patient care and overall quality. I appreciated the opportunity to bring some lessons from my experience in healthcare and design, and I'm looking forward to seeing what they tackle next.

Here at Cooper, we find that looking at the world from the perspective of people and their goals causes us to notice a lot of bad interactions in our daily lives. We can’t help but pick up a whiteboard marker to scribble out a better idea. We put together "The Drawing Board", a series of narrated sideshows, to showcase some of this thinking.

Almost everyone enjoys a great meal out with friends, but splitting the bill can be unnecessarily complicated. In this Drawing Board, Cooper designers turn their attentions to the way groups of people pay the check while dining out.

Credits: Greg Schuler, Peter Duyan , Bo Ah Kwon , Suzy Thompson and Chris Noessel.

Related Reading

• Another design for social awkwardness The Drawing Board: Taking The Call
• More service design Economizer
• Another drawing board The Drawing Board: Feeding The Cats

When the New York Times activated its highly anticipated metering system this week, there was no shortage of opinions on the matter. As opinionated people, the designers here at Cooper started to feel a little left out, so we put our thoughts together on the user experience of the new service. Enjoy, and chime in with your own thoughts and opinions below.

Suzy Thompson

Overall, I think they've done several things right, like the fact that home subscribers (even those like me who now only get the Sunday edition) get an all-access pass to the online content. Also, they're not throwing up a paywall over all of their content — folks can access up to a certain amount of content a month before you're asked to become an online subscriber. And they've thought about how to ensure that folks can read articles that someone has shared via email, FB, etc. We'll see how it goes, but I think that the iTunes store has pretty effectively proven that if you make it easy to do so and provide demonstrable value, people are more than happy to pay - even for something they could get for free elsewhere.

I do worry, though. Because the NYTimes isn't just a business. Their journalism is a public service that everyone benefits from. And unlike a burger or a pair of jeans, where some folks are willing and able to pay for higher quality and some aren't, and the provider can scale back production to match demand, journalism can't be scaled back and still maintain its quality. The fact that I view it as a public service is part of why it's so important to me to contribute financially — just like giving $$ to PBS. Sure, there are some who use it and don't pay for it, and I probably don't use it enough to justify what I pay for it, but I want it to be there and available to everyone. That, above all else, is what worries me about the paid subscription model. Because the prospect of a world in which only Fox News or USA Today can profitably succeed in the news business terrifies me.

Jim Dibble

I understand why the NYTimes is putting this policy into place. They are my go-to place for US and international reporting. We only recently canceled our NYTimes paper delivery — since I no longer work in Pleasanton, I don't have the long BART commute to read the paper. (Thank you, Cooper!). And it just felt like a waste of resources (trees, ink, and gasoline) to deliver a paper that we typically recycled without reading.

However, I'm utterly confused why readers have to pay more to view content on multiple platforms. In the morning and on BART, I read the NYTimes on my iPhone. At work and at home at night, I read the paper on my laptop. I'm not sure why I need to pay twice as much just because I'm using two platforms. I'm surprised that they didn't follow the kindle sales model, where you purchase a book and own it in the cloud, regardless of which platform you use to access it.

It would be great if they provided a way to ask for articles of interest to you. For example, if I'm interested in reporting on the Middle East, it would be great to be able to have a special category for those articles. It would also be great to have articles that assume that I'm well-versed in a particular region. For example, if I'm familiar with what has already happened in Libya, many of the new articles will review the recent history of what has occurred, so that I have to wade through information that I already know, in order to find out about the most recent developments.

Peter Duyan

So, after reading the “letter to readers” and looking at the subscription breakdown, I feel a little deflated. Initially, I was actually excited to pay the NYTimes for their digital media, and to help support them as they find a way to continue doing what they do best. However, I don’t like their subscription models at all for a very specific reason. I only read (almost only) the NYTimes on my smartphone, and I feel like I should have the option to pay for mobile-only content. If and when I buy an iPad, I’m pretty sure I would be interested in smartphone and tablet use, but still have little or no interest in the “online” content. Basically, I want to be a mobile-only user and that option isn’t open. From my perspective, they are missing the point if they don’t let their users pay for content on whatever device they choose.

Doug LeMoine

I think journalists should get paid, and I think publishers should figure out a way to make digital journalism pay. I don’t understand people who talk about metering like it’s some violation of their civil rights, and yet I’m also a nerd, so I must admit that I did Google “nytimes metering hack” yesterday (out of curiosity, really), and I found some very interesting CSS (that I did not install).

Still, I do have a problem with the metering service as the NYTimes has implemented it: It seems both too complicated and too stupid at the same time. Why are there so many different options? Why are there different prices for iPads and iPhones? Why is the digital thrown in for free with print? Why is the NYTimes.com version a required baseline for all plans? And why the heck is the Dealbook blog exempted from metering? The investment bankers have been bailed out by the middle class yet again, it seems.

I would bet that these “tiers,” if you can call them tiers, were an effort to try to create “choices.” But the way they’re broken out makes me think that they’re simply the configurations of devices and content that were easier to track on the back end. I would argue that it gives the impression of "choice," without really making sense as a set of choices.

I'll go one step easier with a user-friendly model: How about one price for print + digital, and another for just digital? And how about charging the investment bankers double for Dealbook? That would help the NYTimes recover some of the $40M they supposedly spent installing the metering system.

Golden Krishna

Adding a paywall is like moving newspapers from the online street corner to the concert hall. Journalists shift from being free street entertainment to performers in a luxury experience that viewers will likely expect to work smoothly and look beautiful. I fear that paywalls will shut the doors on the common, limit access to the kind of information that should be freely available to all, but I am eager to see the good design that results as papers compete for online eyeballs that are willing to pay for their services.

Similar to many of the interaction designers here at Cooper, I come from a trans-disciplinary background. I went to Carnegie Mellon University’s School of Design for my masters, where I did not get a degree in Interaction Design, but rather in Communication Planning and Information Design. While there, I was fortunate enough to be able to study under Shelley Evenson, a major thinker and contributor to the emerging practice of service design. Service design captured my interest immediately. It was so interesting that I spent my thesis project (18+ months) on a service design project with Professor Evenson as an advisor, took all the classes offered on the subject, and ended up spending an extra year in Pittsburgh PA just to be able to co-teach a graduate service design studio course when she took her professional sabbatical. Since my start in design, I’ve worked on a number of projects, and done a fair amount of research and writing on the subject.

What has become very clear is that the emergent practice of service design is smack dab in the middle of adolescence, deeply embroiled in its teen angst. It was not so long ago that interaction designers were at a similar point in our own development, giving us an informed perspective. Child psychology also offers us some wisdom to start from:

"Identity does not begin in adolescence. The child has been formulating and reformulating identities throughout his life.... At adolescence, however, the commitment to an identity becomes critical."¹

There is a fierce debate about the relationship between service design (SD) and interaction design (IxD) here in the United States, particularly among interaction designers. The discussion often devolves into hostile crossfire between two camps: one that believes that the service design is a type of interaction design, and another that believes that the two disciplines are separate and distinct.

When a teenager is a smart, compelling, interesting, independent, charismatic, hardworking, analytical, talented, humorous, knock-kneed being, a parent would rightly feel a great sense of pride. Interaction designers — and those whose careers, and sources of income are indebted to that practice — have very good reasons to hold strongly to the idea that service design is indeed a chip off the old block.²

The Overbearing Parent

The camp that holds service design to be a type of interaction design defines IxD broadly, arguing that its focus is on behavior and experience.³ Interaction designers are trained to consider and design for the experience of people with objects, environments, systems and other people.⁴ They propose that the nature of the problems being solved by IxD and service design is the same. The methods and tools being applied are the same. The skills necessary to solving these problems are the same. Projects are structured and intended to support a user-centered design approach. Research facilitates an understanding of users’ motivations and provides moments of inspiration. Design projects focused on interaction design must gain an understanding of the context of use in order to design appropriate solutions.

The Petulant Teenager

Service designers tend to see their discipline as separate and distinct, yet they recognize the lasting influence that interaction design has had on their emerging practice.⁵ But they think of them as just that: influences, parallels, and similarities.⁶ They argue that the nature of service design problems is different, that service experiences have a context of use, are multi-faceted, co-produced, and unfold over time.⁷ They are comprised of a series of touch points, or points of contact between a provider and user, taking both party’s participation for the experience to transpire.⁸ Services are used, not owned. Design projects focused on services must gain a holistic understanding of both the provider and user’s experiences in order to design appropriate solutions.

The Crossfire

There is usually a direct mapping between a person’s definition of interaction design and their working definition of service design. Of course, there remains disagreement among interaction designers about what their practice does. There are those who still view themselves as the designers of digital products.⁹ They think of IxD’s next-of-kin as the likes of Human Computer Interaction, Graphic User Interface Design, and Software Engineering.¹⁰ Others hold that the practice of IxD has evolved past its original focus on pure functionality and usability, and onto issues pertaining to the quality of the experience of use. Yet it’s unmistakable that, quite often, interaction designers’ outputs are manifested in the form of digital products - software and hardware.

Service design projects deliver specifications for a variety of types of touch points, often spanning the entire arc of a service experience. These include visual communication, operation models and blueprints, process and information flows, roles, scripts, physical evidence and artifacts of the service experience, and, frequently, the interaction design of digital products.¹¹ However, an entire service can exist without a single piece of physical property exchanged, and sometimes, without any technology involved.¹²

There are other worthwhile distinctions to tease apart, such as the methodology, composition of teams, project scoping and process that are valuable differentiators to consider. But I’ll need to discuss these in future blog posts.

Getting On With It

I submit that service design is an autonomous, unique being, who was raised, in part, by interaction design. And that the more established practice is wise enough to know that for IxD to do good work, it too must look at the system of use, think of the providers, co-create, and comprise multidisciplinary teams. It is important to recognize that having undergone its own struggle to develop an independent identity, IxD’s conversation has (for the most part) been able to evolve past definition and onto what it means to do good interaction design.

This doesn’t need to be a tug-of-war. Interaction design as a practice should be self-assured enough in what we do to know that our teenager needs to grow out of its angst in order to become a respected adult. We’re not proposing that we elevate everyone to a service designer who has ever worked on a digital touch point for a service provider; neither should we remain willfully vague and conflate the practice of SD in order to capitalize on the growing interest in it. In fact, trying to identify a “right” answer in this debate is less important than identifying what good service design looks like.

It’s time for interaction design to offer its own developmental experience toward creating a supportive environment that is actively encouraging the emerging practice of service design to compose its own unique (but similar) self-identity. After all, the psychologists will tell you, “Who the child is to be is influenced (and in some cases determined) by what the environment permits and encourages.¹³

1. David L. Lehman , Current Thinking In Adolescent Psychology, 1966, p14
2. Richard Buchanan keynote, COINs & Design Ethos Conference, October 9, 2010 , http://designforservice.wordpress.com/buchanan-keynote-scad/
   http://www.ixda.org/about/ixda-mission
3. Jodi Forlizzi, All Look Same? A Comparison of Experience Design and service design service design service design, Interactions, http://interactions.acm.org/content/?p=1397
4. Mager, Birgit, service design service design service design basics, Cologne: Kçln International School of Design, 2006
5. Mager, Birgit, service design service design service design basics, Cologne: Kçln International School of Design, 2006
6. Shelley Evenson, Carnegie Mellon University Lectures 2007-2009; Dan Saffer, Designing for Interaction, 2006
7. Shelley Evenson, Carnegie Mellon University Lectures 2007-2009
8. Lowgren, Jonas, Encyclopedia entry on interaction design interaction design, http://www.interaction-design.org/encyclopedia/interaction_design.html, 2008
9. Mager, Birgit, service design service design service design basics, Cologne: Kçln International School of Design, 2006
10. Shelley Evenson, Carnegie Mellon University Lectures 2007-2009; Dan Saffer, Designing for Interaction, 2006; Mary Jo Bitner, Service Blueprinting: A Practical Tool for Service Innovation, 2007
11. Mary Jo Bitner, Service Blueprinting: A Practical Tool for Service Innovation, 2007
12. David L. Lehman , Current Thinking In Adolescent Psychology, 1966, p14

Last Thursday, designers at Cooper co-hosted San Francisco Service Design Drinks at our offices. We had a great time drinking and making stuff with local folks interested in the emerging practice of service design. Jamin Hegeman launched this city’s chapter a year ago, and the event was a testament to his efforts to expand the conversation.

Over 30 people joined us for an evening of service blueprinting, and drinking, of course. Cooper’s Susan Dybbs and myself led attendees through an exercise in which we focused on a recent dining experience. Each design team included someone who had worked in the food service industry, providing quick access to domain knowledge. Teams began the exercise by listing all the steps or actions of their experience. They then cataloged the restaurant’s staff and artifacts interacted with and the support systems that were less visible yet enabled the meal. Finally, each team presented their three most interesting reflections on the exercise.

Highlights included discussion of service recovery, and the ways in which experiences succeed or fail because of the staff’s ability to adjust in real-time. We talked about the seen qualities of a service supported by those unseen. We also discussed how services can go to great lengths to curate a certain experience yet come across as disingenuous when inconsistencies in execution emerge.

By deconstructing a single service into rough but simple terms and parsing all the pieces to co-create a visual model, we hope that the attendees left with a greater understanding of Service Design and blueprinting, and an appreciation for local brews. We’re all looking forward to attending next month’s event!

Have you ever used a public service that understood your needs? We all have horror stories of waiting in seemingly endless lines at the DMV or hunting forever to find the information we need on poorly designed city websites. Who is making sure that government uses effective design and technology to meet the needs of citizens in the 21st century?

Introducing Code for America

Code for America is a brand new non-profit that is taking on this challenge. And part of the challenge is understanding the target users of the technology. To help in that effort, Suzy Thompson and I taught a day-long workshop on Research for UX Design to the fellows at Code for America.

Code for America signage at their offices in San Francisco, autographed by the 2011 fellows

Code for America helps local city governments leverage the power of the web to become more efficient, transparent, and participatory. Built on a model similar to Teach for America, CfA encourages developers and designers to apply for a year-long fellowship, during which they will create open-source technology solutions for city governments. Out of over 300 applicants, CfA chose 20 fellows for their inaugural year, from a wide variety of backgrounds including Web 2.0 startup entrepreneurs, developers for local city governments and school districts, open source contributors, a researcher for the New York Times, a digital journalist, an intellectual property lawyer/programmer, and a museum exhibit designer.

Code for America 2011 fellows (image used by permission from Code for America)

Code for America Institute

The fellows are spending the month of January in San Francisco at the Code for America Institute, learning from guest speakers about a wide variety of topics, including treating government as a platform (Tim O'Reilly), building local communities (Danielle Morrill), being a change agent and nurturing social network communities (Caterina Fake), and taking an entrepreneurial view of their city projects (Eric Ries).

Host City Projects

Each of the fellows is assigned to one of four city teams, each with a target project:

The fellows will spend the month of February in their host cities, learning about the IT infrastructure and interviewing city stakeholders and users of their system. They will return to San Francisco in March to design and develop the open-source applications. They will present and hand-off the applications to their host cities in the fall.

Cooper Training

Because Cooper has extensive experience connecting user research to product design, Code for America asked us to come in and present a one-day workshop. From our courses on interaction design and design communication, we carved out a day's worth of materials on finding stakeholders and users, preparing an interview instrument, conducting interviews, debriefing interviews, and synthesizing and presenting research findings. We also gave them a look-ahead to personas, scenarios, and framework design.

The fellows got a chance to plan an interview instrument and conduct a 45-minute interview with members of the CfA staff. Conducting good ethnographic interviews takes practice -- I think the fellows came out of our workshop with a sense of confidence in talking to their city stakeholders and application users in February. I look forward to hearing about what they learn about their users, and to helping them create personas and scenarios from their findings. And I can't wait to see the amazing applications that result from their work.

Great Government Research and Design

A question to our readers: Where have you seen user experience design principles applied to government applications or services, to achieve an amazing outcome? At Cooper, we're currently working on a project with CalSTRS (California State Teachers' Retirement System), and in the past have done pro bono work with the SF Department of Health. I have also read about fellow Cooperista Renna Al-Yassini's service design work for the Roudha Center in Qatar. What user experience design work in the government or social service sectors has impressed or inspired you?

“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.

(This article was published in the November/December 2010 issue of interactions magazine.)

It seems likely that we find ourselves at an inflection point in the evolution of healthcare. While the situation has certainly been brought to a boil by recent American political events, the opportunities for change fit into a much larger context; they have the potential to truly transform the delivery of healthcare globally.

Unlike some, I don’t believe our current healthcare system is totally broken. I’ve conducted design research in quite a number of clinical settings and have consulted for businesses representing many different aspects of the healthcare industry, including provider networks, medical-device manufacturers, and even health insurance companies. I’ve seen magic worked on regular basis, and from a historical (and global) perspective, the standard of care in the developed world is astoundingly high. I am in awe of the abilities of doctors, nurses, techs, and other clinicians to consistently function at a very high level despite the fact they’re forced to work with archaic infrastructure in less than ideal environments. (As for the insurance companies, perhaps the best thing to say is that they function to make money but could be dramatically more successful as businesses if they changed their approach to things.)

It is at this level—the level of infrastructure—where these big opportunities for transformation exist. It isn’t that we don’t know what kinds of patient and clinician behaviors and medical interventions result in healthy outcomes; it’s that at a systemic level, we’re not doing a good job facilitating these behaviors and driving appropriate interventions. The right changes here will provide a conduit for evolutionary change to cascade throughout the system to achieve dramatic improvements in the quality and cost of healthcare. Which isn’t to say that it also isn’t incredibly important for medical knowledge to continue to evolve; it’s just that we already know enough to dramatically drive up quality and drive down costs.

Many of the opportunities to improve our healthcare system can fit into three big categories: proactively engaging individuals to take better care of themselves; providing better interventional care beyond the walls of the hospital; and improving care delivery inside hospitals through standardization and better collaboration between clinicians, patients, and families. All three of these strategies require new infrastructure and perhaps a shift in the definition, role, and activities that characterize the hospital.

The first two ideas are mostly about what happens outside the hospital. These are things that architects wouldn’t traditionally worry about when designing hospitals. But that kind of thinking has gotten us into our current predicament, where the current built “environment” for providing healthcare is sometimes an impediment to necessary change. If we step back and define a hospital as the nexus for healthcare in a community, we have a platform on which we can imagine the ideal infrastructure for keeping people healthy as possible in a cost-effective way.

In the May+June 2010 issue of interactions, Hugh Dubberly suggested designers ought to help reframe what healthcare is and how it is delivered, as well as to reframe what it means for design to help. I couldn’t agree more, and in this spirit, propose reconsidering what healthcare infrastructure is necessary to better care for people, how design should address this new notion of infrastructure, and what this all means for the institution of the hospital.

I’ve been struggling for days to put into words my reaction to the launch of Google Buzz. But the phrase I can’t get out of my head is “HOW could they screw up THIS MUCH?”

Well here’s how: Google took Gmail, one of the most widely used web services on the planet, and modeled a quantum change in its behavior with an insulated, private, corporate, top 1% tech-savvy user base.

Google Buzz creates an instant social network based on your email history. Google engineers wrote an algorithm to analyze years of correspondence in users’ Gmail accounts. At launch, by default, these associations were automatically linked and shared with everyone else in your "network." [Google has already modified the default behavior twice in response to criticism].

Apparently, Google tested Buzz internally for months prior to public launch last week. Unfortunately, the controlled conditions of corporate email are a poor stand-in for conditions “in the wild” of a public email service.

You could imagine that the post-launch backlash could have been anticipated with a bit of forethought, even an afternoon meeting that went something like this:

AGENDA
1. What types of people use Gmail?
2. What do they use it for? Who do they communicate with and why?
3. Does our internal beta account for those types of uses?
4. If not, how do we introduce this service to people who aren’t like us?

At a bare minimum, identify a set of people who represent a cross section of users: A grandparent who switched from AOL; a high school junior with an active and evolving social circle; a struggling factory worker in a hostile political environment; a professional with a secretive private life.

Then, just as a sanity check, ask “Is there anything problematic with mining the history of their person-to-person emails and creating a single transparent group from that list?”

For many things, Google’s approach—develop, internal beta, release, measure, adjust—is an adequate way to stumble towards a better experience. That approach takes good ideas, puts them in play, then sands down the rough edges and suggests enhancements. For something as significant as combining email and social networking, it’s toxic.

I'm a frequent Costco shopper—buying things in bulk just makes sense for a growing family. Every trip has the same ritual to it; find the things we need, avoid the things we don't, try lots of samples (a.k.a. lunch) and then... wait in the enormous lines. Many people dread going to Costco solely because of the long lines. I would hazard to guess that this is one of the biggest friction points in their customer experience.

So, what's the problem? While there are lots of small factors that slow things down, one stands out in my mind—I like to call it 'the barcode hunt'.

To illustrate: By the end of my Costco trip I'm ready to be done, and the toddler that's usually with me is WAY ready to be done. So, while waiting in line I try to organize my cart so the checker can scan the large items in the cart and get us on our way quickly. But invariably there are a few things—always heavy and bulky on the bottom of the cart—that need to be moved to find the barcode. By my guesstimation, this box dance burns about 30 seconds per transaction. Multiply that by all the shoppers Costco sees in a day, and you can see why the lines are always so long.

But what could Costco do to speed things up?

Yeah, in a future world of RFID and spimes this problem will wondrously disappear—or so we've been told (I'm still waiting for my jetpack). But in the short term, there's lots of time being wasted.

My modest proposal could save those 30 seconds: Print the barcode on all 6 sides of as many products as possible.

Every item in the cart would be scannable in any position, speeding the checker's task and getting me on my way faster.

A change like this could work wonders for checkout lines everywhere, including self-checkout kiosks. (for some fun ethnography: go watch people using self-checkout kiosks find the barcodes on products—it's an eye opening experience). But I focus on Costco for two specific reasons: motivation and muscle.

Motivation

Costco has one of the highest customer satisfaction ratings in the country. They sell good products at good prices, stand behind all the goods they sell and go out of their way to treat their employees well. They have crafted a customer experience that, with the exception of the lines, is top notch. Having proven that they 'get' customer experience, it seems that a relatively small change like this could take hold.

Muscle

Costco is an 800lb retail gorilla that uses their market muscle to get better pricing and quality from their suppliers. If they choose to, they could dictate barcode location rules to their suppliers. Costco also has a huge house brand, 'Kirkland Signature', where they have complete control of the final form of their packaging and could easily shift to a 6 barcode design.

How about it Costco, will you make my next lunch visit, err I mean, shopping trip a bit more streamlined?