Prototypes can serve a wide range of purposes. If you haven’t done so yet I encourage you to read previous posts in which we’ve looked at prototypes that help define the user experience and others that evaluate technical feasibility.

In this post we’ll look at another kind of prototypes, those that are used as a sales tool.

Prototypes as a sales tool
Sometimes clients come to us with very ambitious and exciting application ideas. At this point, their internal teams have spent some time giving birth to these ideas and are working towards getting them green lit to become actual products. In order for these projects to ever see the light of day, our clients usually need to get approval from stakeholders higher up in their organizations. These stakeholders are not designers or developers; they are business people. So for them to be able to fully grasp the value of these potential products it’s essential to present them with a visual depiction of how these applications might look and behave. It’s our goal to help these clients make a strong case for the investment that these projects will require when fully produced.

Prototypes are an exceptional tool to satisfy this need. They help visualize these applications requiring a lot less imagination than just reading words on paper. They can then help decide if an idea is worth investing in for a fraction of the cost and time that the actual application would call for.

These types of prototypes can range in fidelity but often require a high level of visual refinement and appeal to get stakeholders excited about these ideas. In some instances, these prototypes can have such a polished visual look that they might even appear to be finished applications without being so.

A prototype for Sling Media’s hardware device SlingCatcher

Setting expectations
Some of our clients come to us knowing that they need a prototype to fulfill their particular needs. Other times, clients with the same needs are not used to receiving a prototype as a final deliverable. In order to avoid misunderstandings it’s important to set expectations with these clients about what a prototype deliverable is and what is not.

When proposing this kind of work we make it clear to clients that these prototypes are not reusable code or a foundation from which they can build something further but a great platform for creative, quick and relative cheap iteration. Setting this expectation allows us to have the most flexibility to be creative and innovative without the burden of having to conform to strict technical specs. We also make sure to convey that a prototype can serve as a great sales tool that illustrates the intent and functionality of the product they want to create in a very exciting and convincing way.

We are also transparent in the way we sell this type of work and we encourage clients to only buy what they need. For example, if they only need a simple prototype with only some key features then there’s no reason to build a fully functional demo that shows every possible thing the application could do.

Let’s get down to business
The ideas that these clients come to us with vary in levels of refinement and definition. Before starting to build these prototypes we work closely with them to prioritize what features are the most valuable to show in more detail.

When building these prototypes it’s also important to know how they will be presented. Some prototypes are used in a very scripted way where people showing them know exactly what to do, show and talk about. Other times, these prototypes are meant to be posted somewhere for a lot of users to use on their own. If that’s the case, we often find it necessary to provide a more guided experience to avoid confusing users. This is due to the fact that these prototypes are not meant to demonstrate every feature, every user interaction and solve every UI problem. For example, some features might still be represented visually but might not be interactive in the prototype.

The next step is to spend some time wireframing what the prototype will consist of. The way data is presented to users and how they interact with it is central to a lot of these prototypes. This information architecture exercise is an opportunity to solve some UI problems and to find innovative ways to present content to the user.

A case study
The California Academy of Sciences came to use with a compelling iPhone app idea. Their needs were twofold. First they needed help figuring out what this application should be. Secondly, they needed to sell the idea of making an iPhone app to a lot of stakeholders at the Academy.

The California Academy of Sciences mobile site at m.calcademy.org

We had worked with Cal Academy before on the design of their mobile website. On the one hand, their original visual direction for the iPhone app was to follow the same aesthetic. On the other hand, the purpose and use of this application would be totally different from what the mobile site provided.

So we embarked on an Information Architecture exercise to define what features and user interface made sense for this application. At this point our goal was not to define each particular interaction but to give a broad sense of what the application would look like and what it would allow users to do.

Then we built a Flash interactive prototype that simulated the core features of the application. Along with the wireframes, this would be the deliverable for this client engagement. Even though the prototype was built in Flash, we still had to keep in mind, what capabilities, conventions and paradigms existed on the iOS platform. For example, in order to make the prototype feel as real as possible, we replicated the scrolling and spring that is so familiar in iPhone application views. Building it in ActionScript instead of Objective-C had some obvious advantages. Flash is a great prototyping tool since it provides great flexibility and speed for quickly developing and iterating.

This prototype was then used to convince stakeholders at CAS of the value of the iPhone app idea. It was very useful not only to help them visualize the application but also to get them excited about the idea and invest in it. The fact that the prototype was interactive and had a polished Cal Academy branded feel definitely helped sell the idea.

Once the actual iPhone app was green lit, Cal Academy came back to us to build it. At that point, the prototype served as a jumping point to define the application in more detail. A more in depth Information Architecture effort was required since it was a complex application with a lot of details that the prototype hadn’t captured. Since we partnered with a third party to build the application, the prototype was also very useful for this vendor to get an idea of scope and what type of user interactions and animations were expected.

Expanding our capabilities
Using our existing skills (Flash, Html, JavaScript, etc) we prototype a wide range of applications for a variety of platforms: web, desktop, mobile, set-top boxes, TV, etc. This allows us to reach a wider range of platforms beyond the ones we have the capabilities to develop for. We work with our clients to define what features need to be showcased and when necessary, we consult with engineering teams to make sure that we are not proposing something impossible on a particular platform.

Good for business
Having the ability to pitch this kind of work to clients is a gateway for odopod to get involved with some really exciting cutting-edge projects.

These clients come to us with a desire to create products that either, fulfill a need that is not yet met or that raise the bar in a particular application market. The inherent flexibility of prototyping provides a great deal of freedom to explore and try new things, hence why it’s a great platform for the innovation that these products require.

These types of projects are often a refreshing change of pace for our information architects, designers and developers. Prototyping engagements are usually shorter than other more traditional projects and often provide a fun playground for experimentation. It’s also an opportunity for developers to gain some new skills. For example, developers not as skilled in Flash might take on a prototyping project and gain some additional ActionScript knowledge.

This type of work is also a great way to open the door to new business. If we haven’t worked with a client before and their needs fit this type of work, it’s a great way to get acquainted and learn about the way we think and work through the prototype creation process. It’s great for relationship building, if we manage to impress our clients and stakeholders with a prototype it will be unlikely that they go somewhere else to develop the application once it receives the go-ahead.

There’s a downside
There is a chance that these applications will never see the light of day. After all, these prototypes are used to sell new and innovative ideas to stakeholders. There is an inherent amount of risk beyond our control that these ideas might get buried. Spending priorities might change within these organizations and these projects be put on the back burner. Other times, the stakeholder approval process might take too long and lose momentum.

In these cases, this is bad for our teams for a couple of reasons. It can be frustrating and affect morale to put so much effort and love behind these projects and not be able to actually produce this work for real. Also, due to the secret nature of these projects, we are obligated by NDAs to keep this work to ourselves and not publicly share it. There’s a significant amount of exciting work that we do that the general public never gets to see.

Closing comments
Prototypes can be used for a great variety of purposes and provide a great foundation for innovation. They can help define the user experience, evaluate technical feasibility and even become a deliverable to be used as a sales tool. Prototypes also serve as a dynamic platform for collaboration between designers and developers to quickly iterate and efficiently find the best solutions to attain the perfect balance between visual appeal and technical performance.

« We Love Prototypes - Part 2