12
The Challenge of Product Design
Abstract
Products—even simple products such as cell phone apps—exist in a larger ecosystem of tools, processes, habits, and technology. Any new product has to fit into this ecosystem while simultaneously transforming the users’ lives in desirable ways. Not only must design team think about the users’ lives as a coherent whole, they must design a product that is also coherent, having the appropriate structure to best support the user. In this chapter we lay out the challenges of detailed product design and introduce Contextual Design’s techniques for helping teams see and define product structure in a way that keeps the user practice coherent.
Keywords
Agile; Business analysis; Cool concepts; Design; Design thinking; Human–computer interaction (HCI); Human–machine interaction; Marketing; Mobile design; Product design; Project management; Requirements gathering; System design; Team-based design; Usability; User experience; User research; User-centered design; UX
In prior chapters we’ve collected field data describing the life of the user and we’ve generated a high-level idea of what to build. Now we’re ready to design a product that will transform that life. In this Part we describe the Contextual Design techniques used to define, design, and validate the new product concept.
Twenty-plus years ago no one talked much about design. There certainly were no Chief Design Officers. There were no specialties in interaction or visual design; information architects didn’t exist. There were no mobile devices, no Web, and no Cloud. There was no business information content, or things to buy, or pictures to share. There was no social media. There was only work-oriented function that needed to be laid out reasonably across a menu bar surrounding a central area where the work of the application happened—creating a spreadsheet, document, or slideshow, or filling out a form.
This did not mean there was no design. Those of us advocating for user-centered design were focused on making the right thing and making sure that the structure, function, and flow through a single product or system was best for use. And how did we make that happen? We started by understanding the context in which the users performed tasks and ended by iterating with the users to be sure that our product design actually made sense to people.
But as we have said, the very nature of what a product is has radically changed. With the emergence of mobile applications on multiple platforms, a simple focus on task will no longer serve us. Assigning a different product team to each mobile version and another to the main platform of a product, system, or website will confuse the user who moves from device to device throughout the day. Designers must reconceive the focus of product design away from a single task-oriented product on one platform to a whole constellation of products and apps offered by the company and by third parties, all working together to address the needs of this mobile life.
Therein lies the core challenge of product design: to ensure we really build a desirable, product that ensures the coherence of the user’s whole life as well as the target activity with a set of apps, function sets, and products—each of which is itself coherent within the product and across a suite of offerings. In other words, how do we ensure a total positive user experience no matter what platform or physical environment users are in? This large contextual view of the user demands that we understand and design for the bigger picture of the life, use of time, physical environment, and service context that our product offerings will be part of. A myopic view on a single product feature or app will potentially lead to a myriad of disconnected parts, not an integrated, smooth, delightful offering.
In Part 4 we present the Contextual Design techniques that will help you create life and product coherence. We have already primed the team to think widely about the context and larger ecosystem within which the product will reside, with our Experience Models and Cool Concept principles. Now we must design the next layer of details in the product without losing that bigger picture—without getting lost in the low-level details of specific interfaces and features. Here we focus on techniques that will help keep life and product coherence at the heart of your design. As always, for any successful product to be produced, user researchers and designers must work closely with product management and developers. And we assume that your team includes professionals trained and experienced in interaction, visual, information, and other forms of design and in all the tools and techniques needed to design a good modern interface. The dialogue between these individuals and business functions is at the heart of deciding what to build and how it is presented and rolled out. The team-based approach used in Contextual Design will help you bring these cross-functional professionals together to ensure a successful outcome.
Keeping life coherent
People act throughout their days out of multiple intents1. Life is made up of millions of home and work tasks, all of which have to be juggled throughout the day. Fitting all of the to-dos of all of the tasks into the day, and fitting them with each other so the day works, is the continual challenge of life. Any action can fill multiple intents and fit with the rest of life in precise but unarticulated ways. And now people expect their tools and technology—apps, cars, websites, etc.—to act in concert to help us do it all without slowing us down. The principles of design for life guide a designer in understanding all these life and work intents, how they interleave throughout the day, and how to design for them so a new product fits into the moments of life on the go.
A good design is a product or set of offerings structured to allow the user to move from intent to intent, focused only on what they are trying to get done or want to experience. A good product design lets people interleave the activities of work, life, and fun without stopping to figure, fiddle, or find. Design for life means design for time—for use in moments on the go, in the face of interruptions, and the users’ partial attention. Good product design keeps the activity coherent within the product while also keeping life coherent as users move through their day.
Keeping the activity coherent from the user’s point of view has always been the goal of good product design. The traditional challenge of design has been to keep work on a task coherent within the system. Task coherence isn’t just about consistency of the user interface—a coherent product keeps the user’s activities orderly and natural. When technology platforms were less flexible, task coherence sought to bring together all the function and information needed to support a target activity into one product interface. Customer Relationship Management systems, financial information applications, drawing tools, Amazon’s webpage, and websites such as TripAdvisor grew up when it simply wasn’t possible to do bits of a task anywhere in life—the car, the doctor’s waiting room, or in a hallway between meetings.
To manage multiple intents and functions, these products tended to have complex menus and submenus, hierarchical information navigated by category, many tool palettes, sliding panels, pop-out windows, and more such complexity. They made everything available to the user, who then had to figure out where the functions were and how to use them. However much we tried—and we did—the burden of using a tool in this monolithic application model is entirely upon the user.
And maybe this made sense, because at the time people sat in one place, usually at a desk, and they spent long periods of time learning a product, using it, and eventually becoming experts—or, too often, becoming frustrated:
Financial advisor: I rarely use my financial application—it’s way too complex. I call my administrator when I’m on the road for information I need. Now I use Yahoo Finance app to continuously keep touch with the state of stocks.
Employee of an ERP company to a consultant: Will you put in all the expenses for our lunch together and just bill us? Then we don’t have to use our expense application—it’s too hard. (This expense application was part of the suite the ERP company ships to the world.)
Customer taking to designers of a security tool: Listen to me! We don’t want any more function! If you can’t get our users up and running fast we will stop buying the product!
But today the Cool Concepts tell us that people will no longer tolerate highly complex applications that expect a lot of up-front learning. They want products that require no learning at all—that can be used instantly and that keep life going anytime, anywhere, in any amount of time.
How we design to support tasks and intents will continue to evolve. But no matter how it changes, as long as we’re designing for life we will have to keep the intents, the tasks, the whole of life, and all supporting tools coherent and connected.
But be careful. Part of the reason we can support so much more of life, in the flow of life, is because we are creating tiny tools—apps that are always present and instantly available on our mobile devices. They fill the gaps in larger applications and also deliver one small part of a larger ecosystem very well. For example, applications such as TripAdvisor coexist with a myriad of mobile apps that taken together support both travel planning and the trip itself; hotel, car, and airlines apps, Yelp, Ticketmaster, and so on.
But to support an overall task, they cannot exist on their own. They have to connect to all the data and tools people need to complete the whole activity, in any location, on the go. They must provide significant sharing with others, support identity elements, and deliver joy in use. This is why the Experience Models are so critical for design. They tell you what an activity looks like in its whole life context today, so you can design a set of products to transform it tomorrow.
The challenge of design is the challenge of keeping the overall life coherent—so we have to balance providing everything needed to support an intent against making the interface overly complex. Mobile apps work because they do one thing well. Focused function sets within larger applications can do the same when guided by the principles of modern design. But in larger systems, it’s much more tempting to design in every function you can think of to support every case that might possibly happen. This loads these focused areas with too much function, leading to a highly complex design—the very antithesis of cool.
Scenario versus structural reasoning
The fastest path to ensuring life coherence is to design a coherent “system of support” within and across multiple products. To do that, Contextual Design techniques continuously alternate between scenario-based reasoning and structural, systems-based reasoning. We introduced this concept in Part 3 when we talked about pulling product concepts out of a vision. Here we see how it continues to play out as we add detail to the design. Scenario-based reasoning comes easily to most team members—you just tell a story. But in our experience, structural reasoning does not. Yet both are needed to ensure the coherence of the system and the life.
A simple example shows the power of this alternation. Consider the design of the pathways in a university quad. Students cross over the central green, sometimes on the formal paths but often not. Their intent is to get from where they are to where they want to be, in the most direct way. Each student crossing wears out the grass a little at a time, eventually producing alternative pathways (“desire lines”) in addition to the pathways that were designed. Then a good groundskeeper might step back to look at the paths all together and redesign the space to fit the use. Here, where two paths run almost together, they might be merged and paved; there, where four cross, there might be a little courtyard with benches.
The people making the paths are following their everyday life activities without thinking particularly about where they walk, but following the best path for them. They are laying down a scenario of use driven by their intent. Then, having considered the set of scenarios passing through the green, the groundskeeper takes a step back to design the “system of support” for all these scenarios of use—taking good design principles and the materials of his trade into account. He then redesigns the space, thinking structurally about what makes a good space given the demands of the scenarios of use.
Once the groundskeeper puts new physical structures in place, people discover other possibilities and build on them—perhaps the courtyard becomes a favorite spot for street musicians. When anything—space, a product, a service—is structured well, it’s flexible enough to support additional scenarios of use, unforeseen by the designers.
Scenarios are the individual paths that people take to achieve a particular intent (use case)—they came in here, crossed to there, sat on the grass after that, and left over there. But each scenario can only follow a single thread. It is a view of activity over time. Each individual scenario hangs together for that person or that intent. The groundskeeper’s job is to produce a coherent design for the quad that works for everyone. He doesn’t look at one scenario in isolation and make structural changes for it and then look at the next scenario and make more changes. This will not lead to a nice design that works for the space as a whole. Instead the groundskeeper looks at all the patterns of use together (as recorded by worn grass) and redesigns the structure to better fit its use.
Similarly, product designers must consider all the possible scenarios relevant to our new product concepts at once—those revealed by our user data and important to make our vision real. Then they too step back and consider the best product and user interface structure to support the new practice. They too must think of the product structurally. Scenarios keep each activity coherent; structural reason keeps the product coherent. The best way to optimize both is to continuously alternate. This is what we do in Contextual Design.
In this Part we will introduce a set of design techniques that help team alternate systematically between these two types of design thinking:
Storyboards (Chapter 13): Storyboards describe how people will do their activities with the new product we invented. Storyboards are scenarios depicting step-by-step actions, including manual steps, interaction with multiple devices, access to function, and a very preliminary user interface to accomplish an activity within the real contexts of their life and work. Storyboards allow us to redesign the practice of the user to enhance it by introducing technology support, intent by intent, or use case by use case. Storyboard design is scenario-based thinking.
User Environment Design (Chapter 14): A User Environment Design represents the structure of the product. Hidden in the storyboards are requirements on what the system needs to support to enable those scenarios. To build a User Environment Design the team must think structurally about the places in the product and what device(s) will be used to deliver that place. A User Environment Design is made up of focus areas which define each place and the purpose of that place. A product is defined by the places it provides to support the storyboards, the purpose of each place, the functions and content in each place and the flow between places—within one product and across devices. The User Environment Design helps the team with this high-level structural reasoning so that they can determine what the product itself will look like.
User Environment Design Validation: Once the team starts to envision the places in the product—which will turn into windows, screens, or pages—it’s easy to overfocus on each space and start to “what if” into the interface. Having a specific place in the product invites the team to invent function, which usually complicates the scenarios of use we are trying to support. Checking that we don’t overdesign is critical to a good user experience. In Contextual Design we run the storyboard stories, sequences from the user data, and the Day-in-the-Life stories through the User Environment Design to ensure that they are still supported coherently. This is scenario-based reasoning again.
Interaction Patterns (Chapter 15): User interface design requires the same structural reasoning as the User Environment Design. An Interaction Pattern is a high-level structural view of the layout of function and content in the places—screen, page, window—defined in the User Environment Design. Once the places with their core function and content are designed at a high level, the team must think how to structure the places. The interaction has to work within the place to guide the user, be consistent across the product, and fit with the standards of the devices it runs on. Like the places in the User Environment Design, the Interaction Patterns also suggest new possible function. This is another opportunity to overcomplicate the design, so again we walk the new interface structure with scenarios of use to be sure that we did not lose the coherence of the practice.
Mock-up Testing and Validation (Chapter 17): User testing returns the team to scenario-based reasoning. This time, the user interacts with a paper mockup while pretending to do their own tasks or activities in the context of their own practice. We don’t ask them to do planned tasks; the scenario of use comes from them. If the overall product structure is strong, it should support any new scenario the user tries; if not it will break, and the team will have to revisit their design decisions. The mock-up interview tests and validates both the product concept as a whole and our design choices of how it will work.
Iterative Testing: With feedback in hand, we return to structural reasoning as we redesign both the places in the product shown in the User Environment Design and the interface layout shown in Interaction Patterns. After a few rounds of testing—alternating between usage during testing (scenario) and redesign of the product mockup (structural)—you will have a successful high-level structure for the product and the interface that is a strong enough backbone to integrate additional function and support more detailed design.
A great product or suite of products delivering a great user experience is built upon rich user data, the principles of the Cool Concepts, and team ideation practices when team members use the modern materials of design. But to make the right thing for the user requires keeping the life, the practice, and the product coherent. The best way to ensure this—and to figure out what to build—is to alternate between scenario and structural reasoning.
You need not do all the storyboards that might be relevant to a new offering before building the User Environment Design. Just focus on those that are core to the vision. With 6–10 key scenarios guided by data, you have enough to sketch out the bones of the product, define the high-level Interaction Patterns, and start testing the product concept. Let the details grow after the concept is validated; break up the validated product concept so it fits with Agile iterations (or whatever development methodology you use) and start development in parallel with working out the details. New scenarios and functional detail can follow in quick succession. Get continuous feedback from the user on how you are doing. After all, you are defining a new way of living or working—so get back to the user early and often.
Design in teams
Design thinking and design decisions are hard. Unlike user data, which just needs to be collected and organized, once real invention starts there is lot of room for differing opinions. There is no one perfect design—there are many possible good design choices. In the end, the team only needs one that works. Letting the user be the final arbitrator simplifies the conversations between team members. We remind the team while they are designing that they are on the way to test—not on the way to shipping. This makes it easier to let go of an argument about different approaches. Nothing is final yet; they will test and then choose. Also, we provide the team with a set of design principles for structuring the User Environment Design and the Interaction Pattern. And we use the principles from the Cool Concepts to inform design thinking. Having principles encourages the team to reference them when making an argument about the design instead of simply declaring that they do or don’t like a team member’s design. All of this depersonalizes design decisions and helps the team move toward a common goal.
Separating conversations
But many arguments during design occur because team members aren’t really in the same conversation. They are arguing about different aspects of the problem, and they don’t realize it. Contextual Design helps the team with this by making all design conversations more tangible. When discussing how a product supports an intent or task, the team produces a storyboard. When designing product structure, the User Environment Design diagram makes it visible. Interaction Patterns represent the next layer of design as tangible artifacts and drawings of page layout. And the paper mockup of the product represents a concrete user interface for the conversation with the user.
By providing a physical representation of each point of view on design, Contextual Design helps to separate the conversations about the product structure from the redesigned task process (represented in storyboards), the page layout (represented by design patterns), and lower-level controls and layout choices in the user interface (represented in increasing detail in the prototype). If developers get involved (which we recommend), this separation of conversations helps them see that we are not talking about the internal product structure (represented by the object model) or data structures.
When each conversation has its own physical representation, the design discussion is easier to have. Is the team arguing about how to change the users’ practice? Then they should be looking at a storyboard, changing it to reflect their thinking. Are they arguing about how to organize the product to support that practice? Then they should be modifying the User Environment design. Are they arguing about appearance and layout? Then they should be looking at the Interaction Pattern or mockups. Everyone can tell which issues to pay attention to, because that’s the representation the team is pointing to and updating. Confusions among conversations are easier to avoid. Over time, teams trained in the concept of separation of conversations become self-aware; they stop in the middle of an argument to ask: What conversation are we in? What conversation should we be in?
This kind of clarification of conversations is especially helpful after a mock-up interview because the data may be relevant to any level of design. You may get feedback on a button style, page layout, basic function on a page, or discover a whole new way of doing a task. For a team that has learned the idea of separation of conversations and how to use the different representations, the redesign conversation will be easier too.
Team size
We recommend that the team working on detailed design be kept small deliberately—four people are optimal. That might be one or two product managers, one or two interaction designers, and a user researcher. Other stakeholders and developers can participate in occasional interpretation sessions and reviews. Regular reviews should be scheduled when these stakeholders can participate, commenting on the feasibility of the functions the mockup represents, looking for inconsistencies, and introducing mandatory business goals. (“We must present what we are selling in the most prominent place on our home page, even if our users don’t care!”). It’s then up to the core team to respond to this feedback, with product changes or taking on additional test questions in future rounds. Too large a working team will require lots of time on facilitation, sharing, responding to differences of opinion, and bringing each other up to speed if they miss some sessions. A small team, trusted to do good work with a good process, is the best way to get design excellence. As we describe the techniques in Part 4, we will give strategies for getting the most out of small teams and subgroups throughout.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.