Lately I have been reading about Frank Gehry, the Los Angeles architect who has won several awards for his innovative building designs.
Architecture never ceases to amaze me. There is something so challenging and innovative about being an architect that makes the profession a such a charm.
In the field of Human Computer Interaction there is a tremendous amount of stress on building prototypes. Sometimes, when you do work work on a few projects, you don't create prototypes that are just simple paper mockups, instead you design your prototypes to be as close to the real product. In many cases, you can get away with creating paper mockups. But for a long time, I have been debating with myself for the need to create extremely high fidelity prototypes. For some reason, I was unable to justify the time and effort that is put into building several high fidelity prototypes before building the real software or website. Not that I still believe in pixel perfect prototypes for every prototype sample, but reading more about the field of architecture opened my eyes towards the importance of near-high-fidelity prototypes.
As many great people who came before me have advocated - a large part of innovation lies in borrowing ideas from other fields into the field that you are working in. That being said, the same reasoning of architectural prototyping can be applied to software prototyping. Let me try to explain why.
Assume that you are entrepreneur. Your company has a product to sell. The product can either be a website or a software package or an app or it could be something else. The customer has needs an you seem to have or think that you have a product that meets those needs.
Now compare this situation with that of an architect who has to build a bridge between two floating landmasses. Each of these two landmasses are analogous to your product and to your customers. The bridge is the delivery mechanism - your app, your website or whatever you great idea is all about.
In both situations - the one in which an architect wants to build a bridge and the one in which a company wants to sell a product, the missions are the same - to build a bridge that delivers what the customer needs and to build it in a way such that it is strong enough to sustain the wear and tear of time.
Although there are many other missions, being able to deliver a product that succeeds in the ones mentioned above, the likelihood of a product to succeed can increase manifold. Of course, there can never be a guarantee, in the same way that there is no guarantee in the real world for any piece of architecture that is made. Nature can be a bitch. Anytime. As human beings, the only thing that we can do is to do our best and then hope for the for the rest to fall in place.
In terms of a software product, a major part of the task of doing your best is to build prototypes. You are very unlikely to find an architect who acts on whim and creates amazing structures without building a mini prototype of it. In the case of bridges, things are even more complicated. Architects build mini bridges, using almost the same materials that will be used to construct the real bridge, try to simulate the flow of water and air and observe the way the bridge reacts to the artificial water and airflow. These mini models are then tested in all environments that the real bridge will have to sustain. Only after several modifications is a final model proposed that is then given to the engineers who go ahead and create marvels that they can be proud of for the rest of their lives.
The key to success in the real world of architecture is prototyping. Extreme prototyping. Because unlike most software, if a bridge breaks, lives are lost. And no mistake can create a deeper scar on the conscience of an individual than the loss of someone's life due to his/her negligence.
The field of software, thankfully, is a little more forgiving. A bug rarely leads to a loss of life. But considering the scale at which software is used in today's world, it can have a significant impact on the lives of people who use it. And that is the reason why prototyping is a crucial step in the process of product design. Just like an architect, you attempt to look into the future and create a model of something that does not yet exist outside of your imagination. Something, that if directly built in the real world would take a lot more effort and energy. Your prototype is meant to emulate the product as closely as is possible. And you use this prototype to test the waters. You try to learn from your mistakes. Because every prototype gets better the more you test it. Your fist idea might be good. But the intent is not to be good. The intent, is to be right.
That does not mean that you need to have high-fidelity-pixel-perfect prototypes for every iteration. But it does mean that if you dare to build a bridge without building even a few prototypes, you are not only risking the valuable time of your own life, you are also risking the time of the people that trust in you and follow your vision.
And time, my friend, was, is and will always be priceless.