A List Apart

Menu

Sketching in Code: the Magic of Prototyping

Issue № 261

Sketching in Code: the Magic of Prototyping

by Published in Layout & Grids, Project Management, Workflow & Tools33 Comments

Over the last year, I’ve noticed more and more conversations about prototyping as a method of approaching web application development.  Beyond casual conversations, prototyping has also increasingly been the topic of blog posts or subject matter for conference presentations.  The reasons for this increased interest include a laundry list of benefits that prototyping can bring to the process of developing compelling web applications. Ranging from increased collaboration to more effective solutions, these benefits have made prototyping a valuable new approach to consider for your next project.

Wireframes: square peg, round hole

One of the obvious developments in the web application world that has made prototyping approaches more attractive has been the rise of Ajax and rich internet applications (RIAs). Before the arrival of these more interactive approaches, wireframes hit the sweet spot. They could be used in many different contexts and in high or low fidelity to satisfy many different end goals. We could use lightweight, low-fidelity wireframes to explore solutions at the beginning of a project.  We could use more developed versions as documentation for developers and designers to work from. We could use wireframes to explain to stakeholders how pages were to look. In many cases, they were a key part of the deliverables associated with a project. Wireframes really were the “go to” tool for web application documentation.

With the rise of Ajax however, wireframes started to come up short. When we leave the world of page-based interactions, how do you document all but the simplest interaction?  Flowcharts and diagrams don’t work. Even with a single interactive element on a web page, we often have to generate multiple wireframes or use extensive annotation to convey the different possible states.  When there are multiple, possibly mutually interacting elements on the same page, the problem is exacerbated. Even when we do manage to convey all the possible states, we lose a sense of timing.

These shortcomings are difficult enough, but the situation gets worse when we start to consider not just design, but development as well. Development involving Ajax and RIAs requires closer communication between developers and designers, and this communication often has to be iterative.  Tossing wireframes over the wall to developers doesn’t work.  The critical information required for this interchange often can’t be captured in wireframes. Cross-discipline communication issues aside, attempts to use wireframes to explore tough interaction problems are problematic.

Prototyping is the magic

Prototypes keep us focused on our actual goal. I’ve seen countless hours spent generating thousands of pages of documentation that were never used. This in itself wouldn’t be so undesirable if we had infinite developer resources. Unfortunately, this is rarely the case, and I’ve often seen features cut from a product launch in favor of generating “better” documentation. With prototypes, the focus is always on the application and making it better, and it’s much easier to stay focused on value to the end user.

Additionally, prototyping conveys the “magic” of a web application. I, and likely many of you, have been in this industry for quite some time and I still come across web sites that excite me. There may be some bit of interaction or some nice touch that makes me pause for a moment and say “Damn, that’s fantastic.” I may find it surprising, unexpected, or even just well thought out. These moments have a distinct emotional and visceral impact that I can’t get from wireframes or paper documentation, and are often based on interactivity or features that will set your product apart. The only way to convey this facet of interactive applications is through an interactive prototype.

The benefits of prototyping

Prototyping allows us to see problems more clearly—and often earlier—in the design and development process. As we move beyond corporate content sites and into applications that have rich, complex functionality, our ability to sit down at the beginning of the project and foresee potential interactions and problems is diminished. The problem-space is just too complex. This is the reason we started using wireframes in the first place. Often the only way to really understand where problems are going to arise or to figure out potential solutions is to sketch them. We use wireframes to sketch content and layout, but as we move into more interactive interfaces, wireframes aren’t as effective. We need to sketch with actual functionality—to “sketch in code,” so to speak—so we can see how the application will really behave.

Another clear win is in presentations to decision makers. Prototypes can help you sell a decision that is fundamentally or radically different from the client’s current solution or application.  The traditional approach is to create a compelling story and a riveting PowerPoint presentation, and spend a day arguing for the wisdom of your approach. Instead, sit a stakeholder down in front of a working prototype and show him or her why your approach is compelling.

Finally, let’s not forget the users. In user-centered design, research is one of the early stages that we explicitly seek out feedback from users. Often these are current or potential users, of the product under development. This approach is incredibly valuable but if the users in question are familiar with a current product, it can be difficult for them to imagine a completely different approach. And just as we, in our role as designers and developers, can’t always foresee the implications of our decisions until we see them played out in front of us, users are governed by the same constraints.  Users can request features they “need” only to discover when using the new application that the feature in question was not actually helpful. Putting interactive prototypes in front of users is a great way to get effective and accurate input.

There are also two related but distinct advantages that I consider “hidden” benefits of a prototyping process. First, prototyping processes foster collaboration. They often require designers and developers to work closely together on tangible output in a short timeframe, getting the right people in the room communicating. Second, designers and developers start to understand what is possible. (Clients and users can also gain the same understanding.) So later on, when they are by themselves or working on the next project, a designer or developer can better understand what is likely to be easy or hard when he is pondering solutions.

Making prototypes work in your development process

So where does prototyping fit in the development process?  Well, it can be used appropriately just about anywhere. Think of sketching. Drawings, from quick back-of-the-napkin pictures to fully-realized drafting diagrams all fit under the umbrella of “sketching.” Similarly, there are a variety of prototyping approaches, from really quick low-fidelity methods to fully realized working mock-ups. It is important to choose the correct approach for the problem at hand.

Consider where in the development process to use prototypes and who your audience will be. Perhaps you’ll use prototypes early on to brainstorm ideas and explore them in more depth than you can get with quick whiteboard sessions. In this case, a lightweight prototyping process can be ideal. If you use prototypes during the development part of the process, in the meat of the engagement, then you’ll likely want something more developed and robust. Or, if the prototype will be the actual deliverable, give some thought to visual design and a full range of functionality. Ultimately, the audience can affect how polished a prototype needs to be. If a prototype is just going to be passed among the design and development team, you can probably rely on a shared understanding of what is significant. On the other hand, if you are presenting the prototype to stakeholders or decision makers that are not involved in the actual development, you may need to explain what is “real” and what isn’t.

The inevitable caveats

There are some caveats and drawbacks of a prototyping approach that bear mentioning. Fidelity can be a problem. This is nothing new; we had the same problem with wireframes. How many times have we presented wireframes that were too high fidelity and received feedback like “Can we lighten up that shade of green?” or “We need to give that logo more pop.”  Or conversely, we present wireframes that are too low fidelity and we run into problems of acceptance.  These same issues can arise with prototypes if we don’t present them within the proper context. If they are too low fidelity, no matter how robust the functionality they may display, it can be hard to take them seriously or to perceive their value. If they are too high fidelity, we can get the frightening response “Great. Let’s launch this next Tuesday.”

Consider also that annotation is difficult. Documentation-heavy approaches not only record the final decision and outcome of the project, they record the path taken to get there. They capture decisions made (or not made), who made them, and when and why they were made. Because it is often difficult to annotate a working prototype, this visibility can be lacking. An element may end up in the upper right hand corner because it was tossed there early on and there was no compelling reason to change it, or it may be located there because there was spirited and lively discussion and some critical reason placed it there. Looking at the final prototype, the distinction between the two cases may not be evident. Usually this is not much of an issue because the team working on the prototype is also involved in the later stages of the project and this historical knowledge is not lost. However, if the prototype is used as a deliverable and the original team is not accessible, some explicit thought should be given to conveying this type of information as well.

Also, many methods of prototyping require development resources of one sort or another. Sometimes this requirement is easily met; design teams often have front-end development resources readily available. When this isn’t the case, this requirement can actually be a good thing, providing influence to get developers involved in some of the design process.  However, even if a design team has no access to developer resources at all, there are still prototyping methods that can be used.  They may not be as robust or ideal, but they can still be sufficient to satisfy the prototyping needs at hand.

Solve the right problem

A final thought: it is critical, when taking this approach, to solve the right problem.  A common impulse is to over-engineer the entire prototyping process. Remember part of the reason the proponents of Agile Development look askance at documentation is that they want to stay focused on building the actual product. This attitude should translate to an approach involving prototyping as well. A useful guiding principle is to use the quickest and most lightweight method that gets you the results you’re after. Once you’ve taken your first steps, you can expand on them and evolve your process into what works best for you and your organization.

Show, don’t tell

So if your next project can benefit from increased collaboration, consider prototypes. If you want to increase the odds of providing a better end result to customers and visitors, consider prototypes. If you start small, the costs are minimal and I rarely hear people say they wish they hadn’t built that prototype. There’s rarely a magic bullet when it comes to web development but prototypes are a step in that direction. Give them a try.

About the Author

33 Reader Comments

Load Comments