You have to explore the problem space to understand what the alternatives are. Good design depends on knowledge of alternatives because the more information you have about problems and solutions, the easier it is to make good decisions.
Prototypes are the natural next step in the design process. They take everything that’s been learned and apply it to the problem without taking on the risks of full implementation. Prototypes fulfill the carpenter’s maxim, “Measure twice, cut once,” by improving the design thinking before the team commits to a plan. And as I’ll explain next, prototypes do not need to be elaborate, expensive, or require much time.
Where do prototypes start?
With four or five groupings in hand, you’ve paved the way for good prototyping. While people with stronger creative skills might have seen the directions for alternatives days before, groupings of ideas make it easier for the team to see how many alternatives there are. With 20 or 30 ideas, there are hundreds of different ways they could be combined, not counting how many different ways there are to interpret each individual idea. An experienced designer will have good instincts for how to begin. She’ll be comfortable sorting through the available ideas and deciding what to prototype first (not to mention how to go about doing it).
But should you be designing without one, there are several simple ways to choose what to prototype:
• Pick the most promising idea from each group and try to combine them in one design.
• Do small prototypes for each group to see where they go. Could all the needed problems be solved just by remodeling the architecture or by adding customization? See how far each direction takes the design.
• Designer’s judgment: allow the designer to use her experience and intuition to decide what to use in a first stab.
• Make a list of the hardest or most important design questions, and make a prototype(s) that will help answer them.
As a general rule, the more sophisticated the prototype is, the more sophisticated the questions it can answer. A sketch on the back of a napkin is fine for very early and very rough kinds of questions, but if you want to know something specific and be confident in the answer, you’ll need something more involved.
With the first prototypes underway, it should become clear which additional ideas might be added without causing problems, and which ones no longer fit. Like a jigsaw puzzle, some things will slide together and make more sense than others, but it requires trial and error to find out. Because there are so many perspectives (customer, business, technology), it’s impossible to predict which paths will work and which ones won’t. And that’s precisely what prototypes are for: making mistakes, learning, revising, and moving forward.
Prototyping for projects with user interfaces
Prototypes should be done from the top down. Start with what the users will see and the sequence in which they will see it. Involve your usability and design experts as early as possible to get to some reasonable designs and assumptions. There’s not much sense in spending days planning databases and XML schemas until a few screens have been made: that’s like building the frame of a house before you’ve seen the floor plan. If you do, you’re guaranteed to throw away production-quality work, something the prototyping effort is meant to avoid.
Instead, wait until there are sketches or mock-ups of the user interface that are promising (best determined through usability studies or by walking through decisions users will have to make on each screen to do their work). Engineers should then explore how it might actually get built. If similar discussions started earlier on in the project, this should be a natural and easy continuation of them. As far as how to build prototypes, there’s no magic secret. It takes some experience to learn which things can be faked or glossed over and which ones require more thought and investment.
The general rule of thumb is to do as little work as necessary to get the information you need. Any tool—Flash, HTML, VB, or even paper—can be used to prototype designs. It’s much more about the skill of the designer and/or prototyper than
the technique or tool.
Prototyping for projects without user interfaces.
Even on projects with no user interfaces or web frontends, it’s still sensible to prototype. Instead of user interface design issues, pick the most difficult or complex technical challenges and prototype them. Confirm that the core algorithms are sound, satisfy basic test cases, or meet a subset of the performance criteria. The goal of prototyping is the same no matter what kind of project it is: work to understand whether the rough approach(es) you’re considering can be built in the time allotted and actually solve the problems posed. It’s a chance to deal with risk before implementation begins and to learn about what needs to be done before committing to it.
Prototypes support programmers
In the situation where there is a designer or project manager who can lead the prototyping effort, programmers and engineers often complain that they have nothing to do. They might also say that the process is a waste of time (a claim often made of anything that doesn’t involve writing code). On the contrary, I think programmers benefit more from prototyping than anyone else on the team. Prototyping, when done properly, dramatically improves the probability that the designs they are asked to build have been well considered and are of high quality. Perhaps what is more important to the project manager, while prototyping is taking place, is for the programmers to have lead time to investigate the engineering approaches they’ll need to use.
The quality of their production code should rise if they invest their design time wisely. Worst case, I’m sure customers would appreciate additional bugs being fixed in the software. Here’s a short list of questions programmers should be responsible for answering at this time:
• At a high level, how will we build what is shown in the design prototype(s)? Is there existing code or technology that can/should be used?
• Are there reasonable design changes the designer should be aware of that will reduce engineering costs?
• What are the five or six main components needed, and how will they relate to each other? At the highest level, how expensive will these components be to build? (High/medium/low/unknown is sufficient. For the answer unknown, it’s the programmer’s job to start investigating.)
• Where are the greatest technical risks? Which components are hardest or most complex to build?
• Which interfaces, between which components, are the most complex or most likely to fail? (A dedicated tester or QA person, if available, might answer this best.)
Just like there is no way for a designer to confidently answer complex design questions without a design prototype, there is no way for an engineer to confidently answer complex engineering questions without an engineering prototype (despite what he might say). If ever multiple prototyping efforts are necessary, they should be done in sync with each other. It’s best for the lead designer and the lead engineer to spend time talking to each other, asking questions, and helping each other to make good decisions.
The two prototyping efforts should be on a path that could eventually join up conceptually: the engineering and design ideas should match. I’ve argued with other managers on this point. They couldn’t imagine their amazing engineers
not coding at full speed all the time. There is hypocrisy here: if the programmer’s time is so valuable, the use of it should be planned. “What will the programmers do?”, they’d ask me. And I’d say, “They’ll wait for a plan worthy of their time or help us find it.”
Alternatives increase the probability of success
Specific to user interfaces and web designs, most prototypes I’ve contributed to, or made myself, had lots of brothers and sisters. With the big pool of ideas that surfaced early on in the creative process, there were many alternatives that seemed just as reasonable as the others. The only way to understand which ones were better was to try out some of them. Designers or engineers who are experienced at making prototypes have the ability to change the user interface, layout, or other details to one of any number of configurations (CSS and HTML are great examples of this, where there are layers that can be changed independently of each other). A flexible prototype can make discussions and decisions happen much faster because people don’t need to imagine and visualize as much in their minds.
I’ve learned from experience that no matter how much it seems like people agree, if they’re not all looking at the same image, they may not be agreeing at all. Each person might have something very different in her mind’s eye, and when she says yes to the others, she’s actually agreeing to very different things. Later on, odds are good it’s the designer or the project manager who will be blamed for this kind of confusion. Prototypes are a reliable way to prevent it because they are actual things that can be shown and referred to later. “See this? You agreed to this, and everyone in the room saw you agree to this exact design.” You should specifically call out aspects of prototypes or design screenshots that you’re using in this way.
Questions for iterations
With the first cut at a prototype, tons of new ideas and questions will come up. This will include suggestions for changes, enhancements, and new ideas to try. If it’s an early prototype, its next iteration might focus on exploring big ideas or wide changes. If it’s a late prototype, iterations should be used to narrow the design space and help make decisions. As each iteration comes together, there’s an opportunity for a new discussion about the progress of the design. The best framework for these discussions is a set of questions that help evaluate the design and that focus the discussion in a productive way.
Here are some questions for early prototype iterations:
• What requirements does this satisfy? Can we verify this? (Usability, use-cases, etc.)
• What’s good and bad about this design relative to the problem it’s supposed to solve? (Pros and cons for each of usability, business, and technology considerations.)
• What data do we need to evaluate this design? (Perhaps a usability study, an informal review by a programmer for engineering sanity, marketing, an expert’s opinion, etc.)
• What did we learn from this design that we should keep in the next attempt? Eliminate?
• What might we try in the next iteration to make this better?
• Are there other ideas from the idea groupings or from other prototypes that we should include?
Here are some questions for late prototype iterations:
• What decision does this help us make?
• Which open issue will this help us close?
• Has this design confirmed the existence of a problem we need to investigate? Has it resolved a problem we needed to solve?
• What might we try in the next iteration to get us closer to writing specifications?
And with that, the designer has enough information to make another version of the prototype, perhaps integrating two different alternatives together or forking the design into two new alternatives. There shouldn’t be any restrictions on what’s allowed or not allowed, as long as whatever is done eventually brings the design work one step closer to completion.
The open-issues list
As the field of alternatives narrows, there is one new responsibility for the project manager: the open-issues list. An open issue is anything that needs to be decided or figured out but hasn’t happened yet. It’s essentially a list of questions that should encompass anything that needs to be done, prioritized by its potential impact on engineering. The form of this list isn’t as important as the quality of issues listed and the diligence of the person driving to resolve them. I’ve used a designated spot on a whiteboard or Excel spreadsheets for this, and I can’t say that the tool I chose made much of a difference either way. I don’t think these lists need to be controlled or managed like source code (that is, unless the politics of your organization make it worthwhile): the impler the tool, the better.
This list can start with a rough list of unanswered questions (“Will we use data schema A or B?” or “When do we need final UI design from Sally?”), but it should grow in detail as specifications are written. Each item should have a name next to it of the person who is driving the issue to resolution. It should be the PM’s job to make sure everyone is aware of issues they’ve been assigned, nag them appropriately, and track them to resolution. Programmers should have the full burden of engineering questions and research, but if there are any issues that the PM can take on, he should. Typically, items that might block engineering but are not engineering specific—such as marketing approval, usability
considerations, branding, and visual design—should be tracked by the project manager, as they will impact the specification more so than the implementation.
The wise project manager divides the open-issues list into two priorities: things that need to be resolved before specifications, and things that could wait until later. It’s the most natural way to prioritize issues that have the potential to block engineering—and possibly the entire project. Anything on the post-specification list should be clarified with engineers because they’re the only ones who can verify that the decision or information can wait.
Every uncertainty that needs to be addressed should be listed. No one but the project manager may need to see this list, certainly not early on. But as days go by, it can serve as a tool to unify the team in meetings or hallway discussions. The goal isn’t to make people feel bad, it’s to remind them of what remains and to help them see what problems other team members need to resolve. Because the project manager’s work affects everyone, making the list visible allows people to collaborate on resolving the issues: “Oh, that’s on my list, too. Should you take it, or should I?” This is one reason I’ve kept my issues list up on a whiteboard in my office or in the hallway. (A wiki might work fine, but no one ever looks at that list but the person who created it)
I found that whenever people came by my office and asked how things were going, I’d point to that list and say, “That’s exactly how things are going. When that list is empty, I’ll be able to finish those specifications.” While this isn’t a performance metric or something rigorously measurable over time, the state of a project manager’s issues list, and the scope of the questions it includes, reveal a great deal about how well things are going. If the list is long but contains very specific issues, things are in good shape. If the list is short but asks scary fundamentals like, “What problem are we trying to solve?” or “What programming language are we using?”, you know the project has a long way to go.
Comments are closed.