The Functional Prototype vs. The Clickable Mock-Up

Here at the studio we do a ton of interaction design. We create grand wireframes diagramming the details and behaviors of the applications we help develop. This is an excellent linear way of communicating to our clients how many steps and through how many hoops their users will need to pass through before achieving the goal at hand.

How do we communicate, however, other details to our clients that don’t exactly translate well in a wireframe format? Details like screen effects – interface transitions and animations, user-initiated interactions – mouse events or gestures, and general usability issues – how poor product performance can overshadow the User Interface and so on. We can develop a set of visual designs that advance through a transitional process one keystroke at a time or we can move the process into HTML space, creating a non-production environment for testing and product discovery.

Enter the Functional Prototype, or is it the Clickable Mock-Up? Honestly before coming to DesignMap I had never heard of a “Clickable Mock-Up”. My existence during the lifecycle of any project I was involved with always began at visual design and led straight into production-level build out, then QA. If you share my pain, you may understand why I have grown to love the process of prototyping.

In a Nutshell

Fundamentally, Functional Prototypes and Clickable Mock-Ups are the same thing. They help illustrate in a tangible way, specific interactions that our PSDS, our AIs and our PDFs could never afford us. They are samples or models built to test a concept or to act as a thing to be replicated or learned from. As designers developing web products, they are key to helping us define and refine the interactions we concept. At the studio we approach and differentiate the two based on a few project-specific characteristics — most notably fidelity and client-expectation. Determining how complex sets of parameters are for any given interaction usually yields the technique to use. Nailing down the final deliverable can as well.

Our Two Methods

Say for example we need to illustrate a simple user-flow using a series of click-through screens. That doesn’t seem like it requires a whole bunch of fidelity, semantic HTML and pixel-perfect styling. We could generously slice up our mock-ups, wrap them with anchor tags and be up and running in no time. This “quick and dirty” prototyping technique we tend to call a Clickable Mock-Up.

If however we need to test the functionality of an application-specific calendar module with live data, all its animations and transition affects and show how it relates to similarly dynamic siblings on the screen, our client would most likely expect a more complex prototyping method that delves into semantic HTML, JavaScript functionality and CSS styling. This approach we categorize as a Functional Prototype.

Beware the Difference

To ensure that we start a prototype project on the right foot, before coding starts, we make it a point to settle on how we’ll be presenting the finished product. We want to ensure that we’re on target with what’s necessary to build and more importantly, understand the support level. Being that we’re testing and refining our interactions in a prototype format, we won’t necessarily be creating production-level code and therefore shouldn’t put ourselves in the position of support for our client’s development teams. A prototype should only be demonstrating the desired behavior and functionality of our work.

Being that both methods essentially are the same thing (all technical differences aside) why then differentiate? A prototype adds an immediate benefit due to its tangible nature and though its codebase may be bulletproof, presenting it as a Functional Prototype may cause the client to misconstrue it as a ready for the world solution. Presenting it as a Clickable Mock-Up however might set the stage for further iterations and product growth for the project. Clients may understand much easier that what’s being presented is a tool for discovering what works, what doesn’t and what might need refinement both visually and functionally.

Understanding which technique to use before starting the prototyping process and titling the final product accordingly can be the difference between staying on target and missing client expectations completely.

Best Practices

Both techniques have their own set of production and skill level requirements and, depending on the team involved, might end up being an arduous process. Designers of the sensitive variety may cringe at one technique while heady developers may scoff at the “throwaway” work of another. Before production begins it’s important to think about why we differentiate in the first place, and what each technique means to the overall lifecycle of the project – specifically client interaction — so take caution before embarking. Meet with your team to ensure you’ll be delivering a prototype at the right level of fidelity, exactly how the client expects it – know what you want out of a meeting before going into one.

Another thing to consider as designers working in code; we’re not just prototyping the interactions we develop but the look and feel as well. Refinements of interactions brought about by moving our work from static presentation to dynamic prototypes more often than not, translate to refinements in visual design – leave room to iterate both.

Lastly, try to consider code on a more global scale – not just in relation to the project at hand. How can the code you’re developing now benefit other projects down the line? How can it benefit work you’re planning for another client’s work? This not only boosts efficiency when the next phase of production arises but also helps put in place the need to create an in-house reusable code, styling and script resource. At the studio, we’re firm believers in the idea of prototyping not being throwaway work.

Bye for Now

No matter the technique, the benefits of HTML prototyping can be a huge win to the interactions we design for. We can use them to engage our clients in a way that’s more tangible, shore-up any functionality that may have been overlooked during wireframing, learn how our designs can be implemented and most effectively communicate our concepts to our clients. Choosing which prototyping technique to use and how it gets presented can be crucial in successfully working with clients. Begin by assessing the fidelity of what needs to be communicated, evaluate client expectation, start small and build good code the right way and with forethought, making it reusable along the way.