Yours visually

Wireframing a product or enhancements is a great way of validating customer propositions. Given the choice, customers and prospects will any day choose an html prototype over powerpoint hyperbole. Thus it is sad that html prototyping remains suboptimally utilized in the product development cycle – overused at the begining and consigned to the trash bin before it has yielded all it could.

I am no genius figuring out why a touch-and-feel prototype is more effective than paperware. The commercial/sales guys figured it out much earlier. The zeal to sell (or to just awe the audience) leads down the slippery slope of over-jazzed visual prototypes getting in front of customers. Overpromise. When the rubber hits the asphalt things start falling away. Engineering cannot deliver to the wireframe in the committed time or without overhauling the architecture. Underdeliver. A tool to elicit, refine and enhance requirements has been relegated to a cheap selling trick.

Html wireframes are much derided within the engineering fraternity as mickey-mouse. The prototype quickly dies off and after a while no one even as much remembers where the code is. What a waste. With some thought, practice and process, it is possible to extend the wireframe into the development stage as a bona fide artifact. Preserving the spirit, content and visual signature of a wireframe right throughout the development cycle is more guaranteed with this extension. Product Managers and Usability folks should retain some oversight into the engineering process to ensure minimum deviation from original state.

On the side try this. Ask Usability or engineering to give you a flash version of the wireframe. Put that on the thumbdrives of every salesperson in your organization. Trust me, leaving a “live” version of the product with a prospect is times better than leaving dead-tree version collaterals. The sales folks will love you. The flash and html versions will come in very handy when you are running subsequent marketing campaigns and want your prospects to see and play with the product over the web before they sign up for a trial.

Wireframes are not use and throw. Rather used as flow and grow they can return a staggering return on investment for the product in question.

Update: Seth Godin has a brilliant post on measuring ROI on design. No, he doesn’t give you the spreadsheet you are looking for. On the other hand, he leaves you with enough food for your gray cells. Quintessentially Seth.


4 thoughts on “Yours visually

  1. Hi Subrata,

    I disagree with a couple of points you make here

    1) Prototypes should be reused – No, absolutely not – they should be throw aways. If you are creating prototypes with the intent of reusing it in production, you will end up spending too much time creating them. Defeats the purpose. The purpose of the prototype is get something cobbled up quickly to get quick feedback from potential users. I agree that usability/product management has to have some sense on what is possible, but this can easily be done without having to engineer the prototype for production use. Get developers involved early to make sure you are not painting yourselves in a corner.

    2) Put the prototype on the thumb drive of every sales person – I would not let sales anywhere near the prototypes. I would not even tell them what is coming. Why? They will sell it to prospects and this is going to create nothing but problems. Software industry is well known to sell vaporware and no wonder many customers are pissed off because they don’t get what they were shown when they buy the real product. If sales people want to hate me for not giving them flashy prototypes to jazz the prospective customers, I as a product manager don’t mind. I want happy customers in the long run, not the jazzed ones who are going to feel betrayed if we cannot deliver what they saw.

    My two cents.


    • Good feedback Gopal.
      I should clarify two things which I did not do a good job of in the post. One, my focus was more on creation of wireframes, which provide the visual signature of what the product would be like (as opposed to a say proof-of-concept). Two, the product itself is one that has a heavy dependence on an UI.
      With these two criteria perhaps some of my arguments would make sense.
      I understand where you are coming from too. Actually, if the product development process (for a product that satisfies the above condition) can ensure that what comes out of the door finally looks and behaves a whole lot like what was envisaged in the wireframe then sales would not have anything that deviates from the final output.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s