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#section2
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#section3
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#section4
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#section5
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#section6
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#section7
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#section8
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.
You’re dead-on with this article. I noticed the trend in shying away from wireframes in recent development in favor of prototyping. It’s much easier to share concepts of interactivity with someone by clicking through (even a static example) than trying to describe “how awesome it will be.”
And also, being able to get immediate feedback, pick at UI problems and see initial reactions on a person’s face will only speed up the development process.
good read, thanks.
my2cents
I completely agree that prototyping yields far better results than wireframes for web-based design and development. My struggle, however, is with what tools to use to get there. I’ve got designers, content authors, and developers working with my prototypes at various stages of the design/development process and, of course, all have varying levels of ability to work in XHTML/CSS/Ajax, etc. Are there any tools out there that can handle iterative development of prototypes that are also simple enough for non-developers (i.e., folks with rudimentary HTML skills) to use?
I couldn’t agree more with this article. However, I wish there had been more detail given to how the author and teams he develops with actually go about their prototyping. I haven’t found an application or platform that is really agile enough to allow lots of revisions, rough outlines and the kind of “sketching” that is really necessary without requiring an overkill of development time. Anyone have input on that topic?
You are right about the benefits of prototyping, but there are pitfalls too, most often if some feature from the prototype proves to not be quite doable when the real production system comes online, the user feels they’ve been misled. Also in many cases, if you have a prototype the user tends to feel that all the “hard” work has been done, so why do you need such an unreasonable amount of time to deliver the “real” app? You’ve really got to work hard to manage expectations in that case.
Sony uses prototypes as well in the design process to exchange thought about their designs. Instead of using renders and web based image they show a working prototyping. They use this as the basis for making a decision to proceed developing the design or to discard it. It has proven that this prevents the normal disputes between different departments because they have different languages.
I have to agree with Mike (#4) in that a lot of my clients do think you’ve pretty much built a project when you give them a prototype, especially using the delivery medium that the project is ultimately deployed over.
I’ve been using PowerPoint to build my prototypes for a number of years now and believe it or not it works wonderfully. By using button actions to non-linearly navigate to other slides, I can map out what content is delivered, what UI is displayed and generally how the program will flow.
It’s also really good to highlight anything you’ve missed (man the number of times I’ve forgotten back buttons for ROM projects and not realised it until I can’t go backwards in my PowerPoint!).
My clients quickly understand how the project will function, will see how information is displayed (and capable of directing any required restructuring using a reference THEY can understand) and generally get a feel for the thing without thinking I’ve actually built the project already – a PowerPoint file with green boxes and anti-aliased Arial does not a web or ROM project make. Hell, even the presenter’s notes section is great for putting client comments on each screen as necessary.
The PowerPoint is then also abrilliant reference tool for me and/or other developers to see how the thing is put together and all of us cross-check what’s still to do.
I’ve not touched PowerPoint for presentations in about 4 years, but it’s probably the most used application on my system!
Excellent article that hits the mark. Prototyping has been used in software development for decades and is especially useful in eliciting user opinions before extensive programming is done. The positives far outweigh the negatives.
I’ve never wireframed before. I actually never even knew about wireframing until a couple of months ago.
I’ve always prototyped my web sites before handing them over to the programmers. This article really highlights a lot of the strong points of my company’s development process.
In response to Mike (#4), the last paragraph of “The benefits of prototyping” explains that if prototyping is used consistently when developing new projects designers and developers begin to understand the capabilities of each other. I often get helpful suggestions from my programmers and at times I even find ways to help them speed up their process because I’ve begun to understand what is possible in PHP.
I’ve never had too much difficulty explaining to clients, “Hey, this is just a demo. Nothing is programmed yet.” I love telling them they don’t need to actually input a username and password, they just need to click login…because nothing is programmed. Then the inevitable question comes, “is this site going to be secure?”
Some of the problems I’ve run into with prototyping:
It’s hard to keep the prototypes updated with projects that are already live on the web. We often make changes to our templates on our live projects without updating them in the prototypes.
Another problem is that my programmers use different AJAX methods to make elements appear and disappear. Why aren’t I just using the same one as they are, so they don’t have to redo it? Well, I am now. I guess that fuels the collaborative process even more. The more you do it the more efficient you become!
Awesome use of PowerPoint Ross (#6)! I will probably look into doing some small scale demos in PowerPoint now.
I completely agree with #2 and #3. I’ve been trying to help my company find a solution to prototyping, but we just haven’t found a cost effective solution yet.
I wish the author had gone into more detail about how he implements prototyping and in what stage of the process he does it. Darn!
I use wireframes early in the project as an information architecture tool, not to express interaction. I make my prototypes simplistic and devoid of brand elements, and requiring a single, specific course of action to appear functional.
We’ve been doing this where I work for 6 years. It works exceptionally well once you’ve done it a few times and your partners/clients see it in action.
We use XML/XSL for our prototyping framework. Works on almost all appservers and all newer browsers.
We have an extensive snippet library for eclipse/aptana to do common patterns as well as a standard layout template that every page inherits from. This makes it extremely simple to set up your shared components and then just forget about them.
Using XML files we create “scenarios” that define the page flow as well as hold data for display of specific page elements. This approach provides clear separation of concerns and allows us to explore multiple scenarios with very little coding.
As we walk through the prototype with the client they may point out suggested changes. We document those changes in the affected XSL file. Most of the requested changes can be made real time and presented to the client. The changes that can’t be made immediately due to complexity are commented with a TODO and put in the task list for later work.
All of the comments can then be pulled using another XSL file and transformed into implementation notes for developers or help with refining BRDs.
At the end of the design process the same XSL files can be handed off to a developer, wired up, and used as the end state product. This works well in an agile environment.
Yes, I agree prototypes are good. But I came across the same dilemma, how to develop them without too much pain. I am currently evaluating UML modelling software “Screen Architect”? (plug-in of Enterprise Architect) for work. This software is designed specially for prototyping of user interfaces.
It does have few problems, but because we are using Enterprise Architect for business requirements, use cases, wireframes, etc., it looks like a good tool to use.
I’ve heard a lot of you asking about a good tool for prototyping and wireframes and I have to heartily recommend Axure Pro RP.
As a developer, using this tool for prototyping has helped flush out implementation problems that would have cost thousands of dollars down the line, if we hadn’t done any prototyping.
I couldn’t recommend Axure (http://www.axure.com) enough as a prototyping tool. It gives non-developers the ability to easily create a full HTML prototype including links, drop-downs, hover-overs, etc. It even allows complex interactions such as Ajax-driven functionality. It’s simple to learn with the tutorials present on the site.
I’ve recently started using “Oversite”:http://taubler.com/oversite/ for my IA and prototyping work. It’s great – really easy to use, very flexible and cheap at $35 for a license.
It’s free to download and try out, so you really can’t go wrong with it.
I “wrote about it some more”:http://www.smileycat.com/miaow/archives/001080.php on my web site, along with some other examples of prototyping tools.
Great article, which underlines our recent move to prototyping over wireframes and documentation.
We just finished the first prototype for one of our clients. So far the feedback is great and helped us significantly in the discussions with the client. In future we all our web applications will be based on this approach.
We used Axure RP Pro 5 and as Rachel (#14) we can not recommend the tool enough for prototyping.
Thanks for the great article and constructive comments. It is comforting to know we are all not alone when it comes to this crucial phase of development.
I have not seen anyone yet mention the benefit of prototyping to help communicate and facilitate off shore development. I have found that a prototype not only helps business owners have a tangible example, but it also helps spell out and back up any requirements document created”¦and let’s face it, in reality how many developers fully read the requirements documentation, if there is any created at all. Second to that when a business user signs off for requirements at the development phase, a prototype is an excellent visual representation of what the final product is they can expect. No surprises”¦well okay, not as many surprises.
I LOVE prototyping. Can’t get enough of it when it is done appropriately at the right level of fidelity for where the stakeholders are at in the product lifecycle and when it doesn’t get in the way of getting to the right solution (which I have seen it do; but that is another post).
What I’m interested in here is that the title of the article talks about “sketching” and “prototyping” as if these are the same things.
Please see “Sketching User Experience” by Bill Buxton on a clearer and deeper explanation on why they aren’t, but I’ll just put out there that the intentions of a sketch are different than those of a prototype and further the purpose of a sketch are also different. A sketch can be interactive, it can be in code, but it does need to have certain properties to maintain the important design process requirements that makes sketching work.
Let me first point you to my own blog post on sketching here: http://synapticburn.com/more.php?id=288_0_1_0_C
To summarize Buxton, sketches are suggestions and prototypes are descriptions. To summarize my take, the purpose of sketching is to generate ideas. The purpose of prototyping is to communicate an idea. Yes there is a continuum here, but going back to Buxton, this is why sketching needs to be and even appear quick & rough, but also very importantly need to be disposable.
My experience with coded prototypes is that they are seldom quick enough (yes, ruby makes it quick as an example, but not nearly as quick as pencil to paper as different example), and because of the nature of pixel drawing, prototypes are almost never rough enough and thus seldom if ever have the quality of something that is disposable.
Like I said though. Prototypes are HUGELY important. They are reflexive decision points about the look and behavior and even functional requirements of the solution. In Industrial Design they would the equivalent of an appearance model which in many studios is a “signed-off on deliverable” that is used before the expensive process of tooling is commenced. They are also great for usability testing and other forms of user and customer feedback generation (as well as other stakeholders). They are also important for other methods of design refinement. But that is not what “sketching” is for. “Sketching” is not about refinement, but about ideation and maybe at best “frameworking”.
— dave
bq. Unfortunately [“¦] I’ve often seen features cut from a product launch in favor of generating “better”? documentation.
Hooray, now we know how to prevent feature bloat!
bq. it is often difficult to annotate a working prototype[“¦]
In Axure RP you can annotate any page or element; it will also generate a Word document from the working prototype. One of the many reasons why I second other commenters’ enthusiasm for this product.
David Malouf:
bq. My experience with coded prototypes is that they are seldom quick enough.
So true! Even in a rapid prototype, the more work goes into it, the more we grow attached to design ideas prematurely. No tool will be ever rapid enough to replace paper and pencil.
bq. Also, many methods of prototyping require development resources of one sort or another.
I think there’s a line between “design” and “development” that many clients don’t understand. Some may disagree with me, as they take care of everything (jack o’ all trades) in their production process.
However, many use Designers, and then Developers to finish. And the Designers must understand requirements from Developers, while they all need to understand what the client wants. That’s if the client understands what’s necessary for the project. Soon would after a good prototype, right?
Glad to read an article that emphasizes the importance of prototyping, because it not only helps the client interact, but gets the team involved to see the big picture. And the prototype can be visual (img/ppt/Ai/Ps) or interactive, even just a bunch of scratch paper to begin.
in three years my partner and have chopping away on our site and, to date, we haven’t yet uncoiled the wires. No thinking how many hours of relocating the plumbing could have been saved.
why didn’t i think of that flickers through the mind.
and. Gosh we aren’t even talking about rockets.
a clicking map for the mind.
Have to add my vote for Axure RP Pro as a solution to clickable wireframes. I’m a Business Analyst and have found it ultra-simple to use to do anything including RIA-like interactivity.
Our clients and tech guys love its outputs. Great clickable wireframes (to whatever level of fidelity you like) and it also automatically outputs a Functional Spec.
I’ll be interested to see how these softwares evolve. I can imagine them swallowing up much of the development effort – producing the UI code that just needs to be tied into the back-end. I believe Visual Studio has similar drag-drop functionality. Suddenly development becomes the realm of analysts and designers and can be done quickly.
Great article indeed! I’ve been wireframing for years in InDesign, (it’s great for spitting out nicely ordered PDF’s). However it’s not great for prototyping as you can’t add any interaction.
For those who are good at Flash, there’s a great article worth checking out here:
http://www.boxesandarrows.com/view/quick-and-easy-flash
Thanks for this David, the best article I’ve read in ages.
Stu.
I’ve been advocating rapid prototyping as an important step for a while. I think it will be amazingly beneficial for reducing the post-production rework cycle by getting it right up-front. But where can I find people with these skills? What specific skills do I need to look for?
I need someone who can rapidly put ideas into code for a RIA. Any recommendations on some specifics to post in a job listing?
I think most ALA readers will agree that prototyping is the most agile path to a great UI and a satisfied user. However, as has been iterated, the tools to do this are what’s lacking.
For a cheap and medium fidelity solution, PowerPoint does work pretty well if you don’t mind working with the Animations.
I haven’t heard anyone mention Adobe Thermo yet? Does anyone know when it may be released? It sounds/looks, from the demo I saw, a lot like what this crowd needs. But it’s been in development for a while now.
I’ve been using dreamweaver since 2000 to do rapid prototyping and it works well. It certainly doesn’t spit out good code, but it serves its purpose.
Nice article,
I agree that the future of prototyping is through programs as AJAX, Flash, Maybe Adobe Thermo, but the way we should approach each project varies. Personally I use mainly Visio and Axure at the moment as the most projects I had so far were under the pressure of time and of low budget.
However, sometimes more interactive prototypes are needed. Especially, if they involve user testing. On the other hand, there is the danger that has already mentioned of clients might confuse the prototype with the actual web site which is not good. As they focus more on the functionality for example of the navigation menu than the actual menu.
If you want to prototype may be interesting to check Seaside framework. It has debugging capabilities and flow control extremely intuitive.
In my equation with it: prototyping is making.
cheers,
Sebastian
I am currently researching wireframe and prototyping tools. I really want something web based that users can login, comment and contribute content to the live wireframe. I thinks this is a great way to manage content as well. I had experimented w/ a simple drupal install where I setup a skeleton of the site just for capturing content from the client. Each page had the options status of something like not started, waiting, in progress, complete. Then it was on the user to post content there as they had it. This has been great because then we have logs of everything they give us, when, who editied it and when they marked it complete. I have seen a lot of people mention Axure but it is not web based which I do not like. Can someone give me more feedback??
This article made me feel a lot better about visually modeling out my projects. Thanks.
I haven’t seen it mentioned yet, so I thought I would throw it into the ring 😉 I use it all the time for mocking up interactive web site designs.
I might not belong here, but still I had to sign up to make a comment. This article helped me with describing the meaning of role play. That for sure is prototyping issues difficult to grasp since they are abstract or invisible to view, however using all our senses makes it clear. I often find it usefull and inspiring to get input from disciplines you normally do not associate with drama, however having the same objectives; tension, energy, and so on.
I’ve been doing a lot of inquiry in this subject over the last few months and haven’t been completely happy with what I’ve been finding. Wireframers are great and tools like Balsamiq Mockups and Flairbuilder allow folks with domain experience to contribute, but often those folks often lack the experience necessary to avoid bogging the process down. Worse, template inheritance is often very difficult, and those wireframes typically can’t be used to generate a usable HTML foundation. Artists (for their role in a final site) don’t want to deal with a grid at all and typically stick to raster graphics programs like Photoshop.
So after reading this article, and for those interested in techniques, here’s something I’m about to try:
I use Wicket (http://wicket.apache.org) for my web templating engine, and it has a tag, which wraps prototype content in a page and removes it from rendering at runtime. Some other discussions on this (i.e. http://stackoverflow.com/questions/55363/best-tools-for-creating-website-wireframes) note the use of jQuery for prototype interactivity, which sounds like it’s worth exploring. (I’m also using wiQuery, so I’ll have to be very careful with side effects on the final code, but hopefully can deal with that using .)
Combined with Blueprint or 960gs, I’m hoping to get rapid development of a prototype, but as importantly a prototype that can rapidly transition to live code.
We’ll see!!