8 Pro Tips for Effective Prototyping

We’ve talked about how prototyping plays a part in our creative and development processes. Recently we’ve seen an uptick in interest among clients and momentum building, which is very exciting for us here at R/GA. With one of our major clients we’re now hearing the rallying cry internally, “Powerpoints don’t win customers!”.

The benefits of prototyping are fairly well understood. A prototype is a more accurate representation of an experience than wireframes, schematics, and visual boards. Prototypes end internal debates quickly, reduce risk, and improve the ability to plan, staff and budget work. Most importantly, prototypes save money and speed time to market. It’s not a surprise that clients are clamoring for more prototyping and less deckware.

Having built all manner of prototypes, we’ve navigated many pitfalls and in the process developed some guidelines that we’ve found helpful

1. Specify the goal of the prototype upfront and map that goal to the appropriate type. For example if you’re simply testing UI behavior, you are likely creating a “clickable prototype” or Animatic . If you’re testing the feasibility of an approach to a specific technical problem, it may be a Technical Spike . In our experience, multiple goals overlap and we’re increasingly developing a Functional Prototype, which has UX elements along with complex functionality and technical mechanics.

2. Determine whether code created will be primarily throwaway or reused. The distinction between evolutionary and throwaway approaches is key in determining the style of development and technologies used. With throwaway you expect to rewrite most or all of the code and can generally build even faster, while with evolutionary you expect the code to be ported and adapted in subsequent prototypes.

3. Make user experience and visual design part of the prototype. Technology and design are intimately bound together in software, and separating them can either create a false appearance of success (i.e. “don’t worry, this will all look really good when we skin it”) or a total failure to establish consensus (you’ve solved some hard technical problem but the client hates it because it looks like a black and white wireframe).

4. Design for real-world users and social connections. For example, don’t make users login as “testuser_05″, rather link users to their real Facebook account, load their real friend graph and their real user data from your custom services.

5. Since real user data often lives in production systems, its a good idea to build a sandbox off to the side where select data can be copied, aggregated and accessed from within the prototype without making changes to production. You don’t want to involve your clients’ DBAs when making a change to the functionality in your prototype.

6. Build prototypes within existing products and applications if that’s where the product or service will eventually live. Creating greenfield environments, separate applications, may hide the complexity of integration with existing services and apps. Oftentimes on our projects, we are branching a codebase of an existing application, and creating our prototype within the branched app to test out new functionality.

7. Even if your prototype is based on largely throwaway code, look to harvest the APIs and service contracts for reuse in subsequent prototypes or production. Your mobile application code may be throwaway but the web service spec, the parameters and the JSON response format may be production-ready.

8. When speed of development is a primary driver, use PaaS dev environments, and code using dynamic languages. For example, Google App Engine with Python is a popular solution here because it takes care of data storage, background jobs, deployment, versioning, scaling, and soon, auto-generation of mobile client libraries for services.

If you have other prototyping tips, or want to get involved in prototyping projects at R/GA, let us know. We plan to follow up with some more specific case studies and example of how we’ve used prototyping on our projects.