One of the most common pitfalls for those who are new to web app prototyping is the tendency to wait until they have everything “juuuusst right” before sharing their prototype with others. (Yet, ironically, the primary reason we prototype is to communicate our ideas and get feedback to validate project requirements.) Itʼs human nature to want your prototype to be “perfect” before showing it to anyone. You want to present your masterpiece with a bow wrapped around it and a proud “Ta-da!,” as you wait for the accolades to pour in.
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.