1. Prototype just enough.

   You need to get your point across to stakeholders so they can make informed decisions. Simple wireframes often aren’t enough to convey understanding, but don’t fall victim to over-prototyping (from both a functional and graphical fidelity perspective). Remember, the prototype is not the final product. Those who want to create a hi-fi prototype that “fools the end user” into thinking the prototype is actually the final product are setting themselves up for failure. The goal is to effectively communicate ideas so that you can get feedback, not to waste time trying to build a pixel perfect representation of the final product.

2. Know your audience.

   Who is your audience and what do you need to communicate to them?  What type of feedback do you want from them at this stage? What are your objectives? With a tech savvy internal team, low-fi may be enough to get the job done. If you’re working with non-technical stakeholders, a greater level of interactivity is likely needed to get everyone on the same page and eliminate the usual interpretations/assumptions. Knowing your audience will help you determine what level of fidelity will be required to communicate your concepts effectively.

3. Set the stage.

   Prepping your audience by setting the right expectations is important. They need to know that they’re experiencing a prototype and not the final product. They also need direction from you on what feedback you need at this stage. (Is this what you meant? Layout architecture vs. design details? Where would you go to do X? How would you complete task Y?  Internal team/exec stakeholder/end user?)

4. Plan less, prototype more.

   Prototyping is a perfect way to validate and refine existing assumptions and requirements. However, it is also a very efficient tool for eliciting superior requirements. Heavy documentation leaves far too much room for interpretation and assumptions that won’t be revealed until late in the development process. Less documentation and more prototyping will get everyone on the same page much faster. A solid prototype can quickly deliver universal understanding to all stakeholders and trigger the valuable feedback you need to make good decisions early in the process.

5. Share early and often.

   Prototyping is a cyclical process. Start with basic wireframes and functionality, and then iteratively flesh out the areas that need clarification and detail based on stakeholder feedback. The key is to share your prototype early and often (even though it may be far from perfect) to ensure you’re not designing based on incorrect assumptions.  Often, stakeholders don’t even know what they want until they see it.  Each round of feedback turns the dial and brings the project and stakeholders’ vision into clearer and clearer focus. By sharing early and often, you eliminate risk by failing cheaply as well as quickly identifying the winning concepts.

6. Don’t prototype everything.

   Just as you should avoid wasting time by creating too high fidelity of a prototype (functional and graphical), you also should avoid prototyping every single aspect (every individual component, interaction, or page) within your project. You can focus on the areas or pieces of your project that are complex, need buy-in, or require end-user testing.  Often, you build prototypes to get feedback on key scenarios.  In this case, prototyping anything outside of these specific scenarios is a poor use of time. And remember, the prototype is not the final product; it’s a means to clearly convey understanding, collaborate, and gather quality feedback early in the process.

But guess what? Your perfect prototype wonʼt be perfect (and thatʼs the point of a prototype, to trigger feedback and iteratively evolve your concept). Sometimes itʼs because an idea simply seems better in your head than it actually is. Other times it’s because false assumptions were made or requirements were misinterpreted. Often the project requirements are incomplete or incorrect. But most of the time, itʼs because your clients don’t know what they want or what they don’t want until they see and interact with it (either as a prototype or the “final” product). Even if they did know what they wanted, theyʼd have a difficult time describing it in a way that a developer could construct it. And resolving these issues quickly and cost effectively is why you build a prototype in the first place.

One of the toughest aspects of web and application development is that your team not only needs to understand what the customer wants, but you also have to help the customer figure out what it is they really need to meet their goals. And by “customer”, I mean several stakeholders with important business needs and varying ideas about what they want (customers may be internal or external).

How can anyone expect to “get it right” the first time if the client stakeholders (including end users) donʼt even know what they want?

And if things werenʼt already messy enough, add to this the fact that as your interactive projects get more complex, there are more unknowns, more assumptions, more requirements, and more stakeholders to please.

Fail Quickly & Cheaply

The earlier you share your concepts, the sooner you hear, “Thatʼs not what I meant.” Congratulations, thatʼs a huge win! And no, Iʼm not being sarcastic. You just failed quickly and cheaply. In a typical development process, that same feedback may not have been uncovered until much more time, money, and effort were invested in the development process. By sharing early you reduced risk, saved your organization money, and saved yourself a lot of wasted time and frustration.

To not share early and often is to defeat the purpose of prototyping. Itʼs essential that you share and get feedback before you invest too much time on the details of your design. Waiting to share your prototype until you have it “just so,” dramatically increases the risk that you’ll waste precious time by running too far down a road paved with one or two bad assumptions. And one of those may be as simple as assuming that the requirements given to you are an accurate reflection of what your stakeholders will actually want in the end.

Embrace An Iterative Process

Prototyping lets you visually communicate interactive design concepts to both your team and non-technical stakeholders so that you can gather constructive feedback early in the process when itʼs most valuable. You prototype to validate existing requirements, uncover missing requirements, help your clients understand exactly what they need, and ensure that youʼre not designing based on incorrect assumptions. You repeatedly share, gather feedback, and refine your prototype through as many cycles as is required to reach a decision. Every iteration turns the dial, bringing the customerʼs needs, and the project itself, into clearer and clearer focus. Each time you share your prototype you are one step closer to delivering the right solution.

Letʼs face it; quality interactive products are the result of iterative development (which is where a traditional waterfall process falls down). You canʼt avoid iteration when there are stakeholders, often with very different agendas, to satisfy. However, you do have control of whether you iterate early in the design phase or late in the development phase – and that makes all the difference. By prototyping and gaining insight early, youʼre able to make changes quickly and cheaply. Making these same changes during or after the construction phase is far more costly and time consuming. Any changes made after the spec has been signed off results in exponentially higher costs (as much as 100 times more). That is why iteratively nailing down your spec with an interactive prototype can make all the difference.

Repeat this process – prototype, share, get feedback, and refine – until youʼve boiled down the project to itʼs simplest and most usable form and your stakeholders understand, and can therefore legitimately approve, what you intend to build.

How Does ProtoShare Help Me Share Early & Often?

Prototyping tools that have easy sharing capabilities and built-in collaboration features are typically your best bet to facilitate the critical practice of sharing early and often.

ProtoShare is a prime example of a tool that was built to facilitate the best practice of share early, share often. You can start with low-fidelity wireframes and iteratively add visual and functional fidelity as needed to communicate your vision. As a web-based tool with an integrated collaboration engine, you have instant access to share your work with team members and clients in the cloud so that you can gather contextual feedback and get answers.

Faster feedback cycles, fewer iterations, far less rework/waste, and a better user experience. A web developerʼs job isnʼt easy, but at ProtoShare, we work hard to take some of the pain out of the process and your daily life.