Exploring the Problem Space Through Prototyping

Here’s a suggestion: Let’s start using the terms ‘prototype’ and ‘mockup’ to mean different things. In my opinion, they talk about different ends of the problem.

A mockup shows us a possible solution. It asks the question, “What do you think of this direction for our design?” Whether the mockup is a sketch or a fully-rendered interactive experience, it’s looking at whether the ideas contained would be a good solution.

Prototypes are different from mockups. They don’t focus on the solution, but on understanding the problem. They ask the question, “What happens when we try this?” Maybe we learn it’s the right idea, but more likely we learn something about the problem we didn’t know before.

Great Designers Focus on Problems Before Solutions

In our research of what separates the great designers from good designers, we saw that the great designers spent a lot more time trying to understand the problem. They really dove in deep, focusing on all the aspects of how their design would be used and what the constraints and complications might be.

Design is all about tradeoffs. Learning how each tradeoff affects the outcome is core to great design.

One of the things we saw from the best designers is their use of prototypes to explore the problem. The prototype is the instrument they used to uncover previously hidden constraints and to see the shifts in the outcome of the design.

Four Phases: Plan, Implement, Measure, & Learn

Good prototypes are embedded into quick, four-phase iterations. Phase 1 of the iteration is the planning phase, where the designer thinks about what they want to learn about the problem and how they might go about it. These are usually pretty short (as short as 5 minutes in some instances), as it’s really just planning out the iteration.

Then there’s the second phase: implementation. The implementation phase looks at building the prototype instrument. This can be a quick sketch. Or it can be something built in HTML that looks and feels like a working app. The point is something that the design team can learn from.

Which brings us to the third phase: measurement. Here the design team collects useful information from the prototype instrument. It can be truly quantitative (Can the servers handle the load when everyone submits a request at the same time?) or it can be more qualitative (How will this workflow create problems for the accounting department, especially at the end of the quarter when everyone is trying to get their orders into the system?). Regardless of its quantitative or qualitative nature, the team is collecting information to help guide future decisions.

The final phase is learning. In this phase, the team takes a step back and asks, “What have we learned from this prototype?” It’s here that they talk about how the new information will guide what they do going forward. Again, this phase can be very short, but it’s too important to skip.

As Much Time on Measurement as Implementing

Many good designers build prototypes. But the great ones go through all four stages, spending as much time on measurement as they do on implementation. They are very clear about what they’ve learned.

One team was working on automating paper-based critical incident reports for clinical drug trials. They created a map of the administrative departments in their building, then overlaid how the existing critical incident paperwork flowed through the building, who touched it, and what they did with it before passing it off to the next person. Their map showed the average report was touched by 17 different people and 14 of them made a copy and put it in their own file cabinets before passing it along to the next person.

The team’s analysis of the map was as important as creating the map. It showed what each person needed to do with the reports and gave insights into how they might need to view the data contained within. Interviews with the 17 different people showed that there was a lot of overlap in work, because people didn’t know what others had done to process the report.

In our research, teams that didn’t spend time on measuring had trouble explaining what value they got from the prototyping process. Teams that spent as much time on measuring could easily talk about what made the prototypes valuable and what affect it would have on future design decisions.

The Three Dimensions of the Problem Space

Technology, Business, and Users are the three dimensions of a design’s problem space. Whereas the good designers would focus their prototypes mostly on technology, looking at questions like whether a particular implementation might be a viable solution, the great designers extend their use of prototypes to the other dimensions.

A team, working on a new design for their university’s admissions system, looked closely at how the application process dovetailed with the financial aid and student loan systems. They need to explore the capabilities and constraints of both the available APIs (which was a technology issue) and the financial aid department’s processes (the business issues).

They created a series of diagrams that represented the current workflows of the financial aid department and used those to spot places where an automated system could improve it. The team then created prototypes of working code (without much of a user interface) that tested the APIs to see if those improvements were feasible.

Unlike a mockup, a prototype doesn’t have to look anything like the final design. It can take whatever look and feel makes it useful for exploring the problem.

The current designs that users interact with today make perfect prototypes for exploring the needs of the user and what to do in future designs. By looking closely at the context of use, teams can learn what decisions lie ahead. Capturing the scenarios of how the users are exploiting today’s design often yields plenty of ideas for how life could be easier in a revised approach.

Shared Understanding of the Problem Space

Because design is now a team sport, it’s important that the entire team understand the problem. The best designers create prototypes not only for themselves, but for the entire team to learn from.

The implementation of a prototype, whether as a sketch, a workflow diagram, or working code, shows clearly what’s being measured. The design of the prototype is an important part of the prototyping process.

This is where the planning and learning phases of the iteration plays an important role. The team can gather around the prototype and catalogue all the important things they’ve learned. They can list out the new questions that have come up (and there are always new questions when the prototype does its job). They can brainstorm how they might build future prototypes to answer the important outstanding issues.

In the end, it’s all about creating great designs. Those designs are great because they find the best intersection of the users, technology, and business dimensions. That can only happen when the team really understand the landscape of the problem space. Prototypes are an effective tool for exploring that landscape.