Lately I have been involved in building a web based system from ground up. While building this product, I took up learning backbonejs which is an interesting javascript framework for building the front end of websites. Conceptually, backbonejs provides some basic structure to your javascript applications and reduces the overall spaghetti code that you might have ended up writing if all you relied on was pure javascript and jQuery.

I am going to make a case for paper prototyping from the perspective frameworks like backbonejs. Enough had already been said in the past by many influential people about how drawing is one of most fundamental ways for an individual to express and presents his/her thoughts to another person. This blog post is mainly for those who haven’t had the opportunity to explore the interesting world of design but whose work(and rework) is largely influenced by design. I am talking about the developers who are suddenly tasked with creating a single page application using a framework like backbonejs or angularjs and don’t really have the luxury to rewrite their code several times.


The side effects of client side frameworks

Backbonejs and its allies make a very interesting case. Backbonejs allows you to separate data from layout at the client side. This automatically promotes the use of RESTful API’s to create applications. The core concept is very simple - you receive some units of data in a JSON format from a REST api, you tie these data units to elements on the web page in a way that a change at either end reflects in the other.

An interesting side effect of this ‘tying together’ is the need to make decisions early on about what kind of html element the data need to be tied to. In pure jQuery and javascript based development, you could simply edit the value of a selector to choose a different DOM element, or a different element type to render your data. And you could do that again and again, iterating the look and feel of your web page as you develop it.


Its all about the decisions

But with frameworks like backbonejs, the decisions are much more concrete. Although the framework gives you the flexibility to change the selector at any point of time, there is much more emphasis on how you can architect the application code so that each visual component has a certain degree of independence with other but a higher dependence on the data that it used to render itself.

When creating a backbone view, you have to decide then and there what kinds of events you will capture in that view, what will happen when you update that view, what other elements need to listen to the changes in this view or the data in this view. There is heavy emphasis on loosely coupled communication, for example, take a look at the listenTo method.

With all these decisions being made early on, it becomes extremely difficult to suddenly change your mind and choose a different selector to render your element. The amount of investment of thought put into the design of the functionality of a view can be too expensive to throw away. And time is always of high premium.


The three pillars of paper prototyping

This does not mean that frameworks like backbone are bad. What they are, instead is an indicative of the fact that the approach of ‘design and iterate you develop’ is fundamentally flawed. Such an approach mixes the decision making process with that of creating the end result. It prevents the developers from seeing the big picture.

Its a well known fact that that if you know what you want to do, you are more likely to do it.

Applying the same principle to web design, one of the easiest ways to ‘know what you want to do’ is through doing paper prototyping.

Paper prototyping is such a drug that once you get a taste of it, you will be addicted forever.

Paper prototyping, from my perspective is the quickest way to do 3 things

  1. Present the thoughts in that blobby mass in your head to another person without any significant effort whatsoever (which directly translates to visual design and layout)
  2. Help define the interactions (which directly translates into identifying events on the interface)
  3. Helps define what data needs to be presented when and where( which translates to what REST api’s you need to invoke and perhaps also helps design the REST api’s).

And if you think about it, in order to build your applications using backbonejs and any other framework, if you have managed to get these 3 things out of the way as early as possible, writing the code for it is only a matter of connecting the dots and making ‘it’ happen. Because the ‘it’ has already been defined almost effortlessly (sketching is way faster as compared to writing and rewriting code) and for the first time, you actually know what you want to do before you sit down to do it.


What makes it cool?

Would it not be cool if you had to spend 1 hour thinking about how to present the information and then spend 3 hours implementing it rather than spending 3 hours implementing a vague thought and then 3 more hours refining it so that it works, then 3 more hours refactoring it and 3 more hours redesigning it because you don’t think its that cool and then 3 more hours refactoring the changes you made to make it cool. Thats easily 4 hours of work versus 15 hours of work. Well the numbers might not be realistically described but I hope you get the point.

First know what you want to make, then make it. Define your goals as clearly as possible. This holds true not only for life but to design as well. And that is why paper prototyping is the easiest way to create something with the minimum possible waste of time.


That said, paper prototyping is not a substitute for persona design and scenario development. For, if you are making the wrong thing, it does not really matter if you take 4 hours to make it or 15, it is going to fail, or to put it more politely, it will not achieve the success that you had hoped for it. However, wasting 4 hours is always a way better deal that wasting 15. As the saying goes in silicon valley - fail fast - fail often, paper prototyping is how you would actually do it.

Signing Off,
Ryan