We often talk about the importance of high-fidelity prototypes. And how simple, static wireframes usually aren’t enough to accurately portray complex functionality and gain real understanding from your stakeholders. We stand by the benefits of high-fidelity prototyping to gain quality feedback early in a project. But we also know that low-fidelity wireframes have a place in your process as well – helping you avoid wasting your time by developing weak concepts. In fact, mid-fidelity and high-fidelity wireframes evolve from their low-fidelity counterparts.
Getting Started
When you begin a website or web application project you likely have many ideas running through your head. But how do you know which ideas are worth running with and which don’t fit the project at hand? It’s simple: by quickly and easily publishing and sharing those ideas.
Your method(s) at this stage may vary from pen and paper to gray boxes on a computer screen, or both, but one thing is certain: Make your ideas visible, ready to share with team members or colleagues to help you narrow them down to one or two concepts.
Why Low-fidelity is Important
Keeping concepts low-fidelity in the beginning of a project lets you visualize all your ideas and work them through the wringer to see which ones hold. As Nick Pettit of ThinkVitamin says, “Low-fi wireframes keep you from getting stuck.” It’s part of the creative process to keep the juices flowing through quick iterations and then throw out the ones that won’t work. You shouldn’t waste your time prototyping an idea that clearly is a poor fit from the start.
Pettit continues, “Low-fi wireframes help you with Space, Balance, Scale, Composition, and Shape.” Once you have a pretty good idea how these should be laid out, what works, and what doesn’t, then you can move forward to the next step and nail down design or start prototyping interactions and flesh out the rest of the project’s specifications.
Sharing is Caring
The important thing to keep in mind, however, is to not be afraid to share your work with colleagues or team members – even the early low-fidelity work. Getting their feedback early and often helps you quickly gain perspective and move on to the next step. First ideas may not always be the best solutions, but you won’t know unless you work out many, or all, of your concepts. And getting to the good stuff early in the game allows you to flesh out the right requirements sooner, getting the project to development faster and avoiding costly late-stage changes.
A common pitfall in prototyping is to desire perfection before you show it to anyone. Perfection this early in the process is inappropriate because you don’t know if your assumptions are correct until you get confirmation from others. Going too far down a path without feedback also makes you overly attached to your design and less open to making changes (which is a big reason you should prototype in the first place, changes are quick and easy).
ProtoShare Facilitates Wireframe Evolution
As you move from abstract ideas to more concrete designs, ProtoShare can handle a range of web application and website wireframe and prototype fidelities. From helping you work through early concepts with gray box wireframing to fleshing out more complex functionality with interactive prototypes. It just depends on your needs and how far you have to go to gain the understanding and buy-in required to send a project to development.
Our platform lets you showcase and share your ideas, then take them to the next level. Start by building gray box wireframes in the Editor or uploading images from other platforms (or even scans of your napkin sketches). Then invite colleagues to review and discuss your ideas until a clear path is laid in front of you when you can then build on the “winning” concept, further fleshing out the project’s requirements.
Effective web development is an iterative process. Start with low-fidelity concepts to get off the starting blocks, and then add a bit of functional fidelity to the key areas of your design. How much functional fidelity do you need? Just enough to put everyone on the same page and get the feedback you need to keep moving forward. Stakeholders can show developers what they need, and developers can show stakeholders what they intend to build. Your team then becomes the hero by coming up with the right solution, reducing project headaches and rework, and delivering your project on time and within budget.