These days my response is usually a simple one: as early as possible.

Wireframes are a part of most agencies process’ at this point. Anyone who has worked as an interactive designer or developer should have a good handle on what they are and why we create them. However, as we have continued to evolve our internal processes the value of wireframes for both agency and client has become less and less apparent.

 

 

Early in my career I began to question the effectiveness of wireframes in terms of communicating design and functionality to clients. On the web today, things like colour, motion, transitions and interactivity are key components for delivering effective solutions; and this is precisely where traditional wireframes fall short. For certain clients, they are indeed useful; but we have begun to reexamine our own relationship to wireframes and more and more we are beginning to forgo them in favour of producing rapid iterative prototypes.

The question of whether or not to include wireframing as a part of your own process is often not a simple one to answer. However, in practice, this can typically be solved by asking yourself if the client will understand and respond appropriately to wireframes. For some larger organizations, wireframes can be a key step in gaining trust and buy-in to a project. Although in most cases, when looking at wireframes, clients are unable to visualize a working site or application in the way that designers or developers can.

When clients are presented interactive prototypes where they can see how the product looks, moves and feels, they are typically able to offer much more valuable feedback and insights. Getting down to these types of insights is often significantly more difficult when you are trying to examine static or even basic interactive wireframes.

Prototyping offers immense value to both the agency and client side of any interactive project. However effective prototyping requires that designers and developers follow some key guidelines to ensure that their efforts result in a more efficient process and a better end product.

1. We must prototype within the context of user (human) experience.

When prototyping we must always revolve our efforts around improving the overall user experience of the product. Far too often clients and agencies develop design or technical solutions that harm the user experience instead of improving it. Fully interactive prototypes allow us to explore these problems as we develop the product instead of designing and developing a solution before it has even been tested. Before deciding to move forward with any design or technical solution we need to ask ourselves whether or not the feature will make the product better for our end users. Always remember that as you are prototyping the goal should be continual refinement of the user experience.

2. We must address the project’s unique and specific challenges

One issue that I have encountered countless times is that technical solutions are chosen based on what is most familiar instead of exploring all options and determining which solution best fits the specific project requirements. Evaluating technical and design solutions should be at the core of your prototyping. If the solution doesn’t address a specific need, then it is simply not worth exploring any further. Prototyping allows you to explore possible solutions in a way that you never could in wireframing, and prototyping earlier in your project lifecycle gets you to production ready solutions as fast as possible.

3. We must create prototypes that result in usable code

This is another common pitfall for many designers and developers. Prototyping is often useful for exploring possible solutions, but often the prototypes are developed using the wrong tools. There are now a myriad of rapid prototyping tools available to us, from SAAS tools like inVision to the classics like Keynote. The problem with prototyping using these types of tools is that they do not contribute to the development of the end product. If you are building a web app, start prototyping your front-end using the tools you will build the finished product in. Prototyping an iOS app in keynote may help you solve specific UX challenges or design nifty transitions, but at the end of the day it is a non-essential deliverable.

Instead, designers and developers should be working together to develop usable prototypes that can be rolled directly into your production codebase. This ensures that all your solutions can actually be developed within the context of your finished product and helps reduce the costs of experimentation within each project.

At their core, prototypes should be designed to deliver:

• More iterations on content and functionality
• Further innovation and exploration
• A higher quality user experience
• Optimal technical and design solutions

Hopefully at this point I have given you enough information to sell you on why prototyping should be a core part of your process, but often getting the rest of your team and especially your clients to understand the value of prototyping can be much more difficult. That’s why I have created a presentation that can help you sell through this idea. You can find that presentation at the link below:

https://docs.google.com/presentation/d/1RC8ETDyBX05_WuqxymmyGKFxHYx_IL2M-xuZksS4Cho/edit?usp=sharing

I have also put together some useful links with further reading on the benefits of prototyping:

http://uxmag.com/articles/ditch-traditional-wireframes
http://www.creativebloq.com/design/prototyping-code-9116762
http://substantial.com/blog/2014/03/20/prototyping-design-with-code/
https://42floors.com/blog/technology/fake-it-trash-it-build-it
http://www.smashingmagazine.com/2010/06/design-better-faster-with-rapid-prototyping/