Learning the Long, Hard Slog of Product

Students love blue-sky design. They envision beautiful new products and services, and delight in conceiving high-level visualizations of great ideas. They produce a sketch, several high-fidelity comps, and a stunning narrative of a vision of the future. The vision is believable, and as it's presented, observers offer the warm encouragement: "That's a great idea!"

These concept designs provoke thinking and reflection, and drive conversation—which is a big part of design education. Students learn a huge amount from both negative and positive criticism; they grow as designers and individuals by making design fiction and by generating ideas.

But in the larger context of design, these ideas are free. Treating a design concept as an end is provocative in the context of discursive design, but it's a tiny, tiny part of the larger product or service development effort. Students probably can't learn this full development story in school, because it takes years of experience to gain comfort in the hard and arduous process of engineering or production. But it's a disservice if a practitioner program doesn't give students the foundation of thorough, specific, detailed design work.

We use several techniques to help students gain comfort and skill in this form of nuanced design. These aren't methods—they are pedagogical ways of engraining a rigorous process of detail. And like any other part of the academic journey, there are specific challenges to overcome in working through this learning experience.

Do it again

Initial design concepts lack fidelity. That means that design gestures are made to interactions—the user may click this, talk to that person, or touch that control—but students gloss over details. Often, that's on purpose. Instructors may push students to refine the story, value, or backdrop of their product in order to make it more succinct or engaging, and this story happens at a high level. It may take 20 or 30 iterations to get to the succinct value story.

It's the next 30 iterations that begin to evolve the details, rather than the story. We have students learn this iterative process by literally doing the same assignment over and over. In one project, they do eight iterations over eight weeks. Students are assigned the task of redesigning a digital product with mid-level complexity (a thermostat or a mobile application for travel). Their task is simple: Each week, redesign the software and conduct think-aloud testing with five users. Then do it again.

Students typically encounter and need to resolve two issues with this technique. The first is exhaustion. Students hit a creative wall around iteration four and feel like they've done all the design work they can. It's obviously not true, and so the faculty often works next to them to show how their design can be further refined. The next issue is misunderstanding what detail actually means. In a piece of software, it's not enough to show a dropdown box; the student needs to show what's in the box. It's not enough to explain that some data shows up; they need to describe where the data comes from. These details are uncovered through constant questioning, both by the professor and the other students.

Do it all

During early iterations, we have students pursue hero flows, which show perfect interactions. These visualize how a person will use a product or service in an ideal context, which helps create a scaffold for the system and to reinforce the vision of value. But the perfect story is rare, and a part of design is identifying, understanding, and rationalizing the "other 20 percent"—edge cases, first-time use, non-goal-directed use, and other parts of what a user will experience. We help students identify these flows by building diagrammatic system representations—concept maps and flow diagrams—and then circling or calling out aspects of the system that the student hasn't considered yet.

Students often find this process tedious, and because they've spent so much time looking at optimistic use cases, it's hard to shift and think about less ideal usage models. But the idealized case of product use is misleading. People use products in strange ways, and their experience is always unique. In a product-development environment, these same students will spend the vast majority of their time working through these details. This is the long slog of bringing a product to market.

Build it for real

When you build a real version of the product—an interactive, usable prototype—you are forced to attend to details, because if you don't, people can't use it. We encourage students to build working versions of their work as quickly as possible, so they can test it in a comprehensive way. This testing identifies usability issues, but it also identifies gaps in thinking. The interactive prototype doesn't need to be digital—it can be smoke and mirrors, duct tape, and hot glue—but it needs to represent a full story of use, which means the student needs to make decisions about small interaction details.

This process is particularly hard for students, because they don't have the confidence to build things at a usable level of fidelity, and they don't view a crude prototype as sufficient. The perceived jump from marks on a piece of paper to something usable is too large to understand without experience. Often, the way to bridge that gap is to role-play the entire situation in class, over and over, until the usage testing becomes somewhat engrained.

Even though students find it difficult to move from concept innovation to detailed design, it's a critical part of gaining professional confidence and ability. This level of detail—the hard slog of product—is the majority of the work these students will engage with in their jobs or entrepreneurial ventures. To get there, they need to learn to iterate, build a comprehensive set of details, and build their ideas for real.