Building world class web products- A Survivor’s Checklist

For two years now, Uzanto’s software team has been engaged in building a web based software product (called MindCanvas). MindCanvas is essentially a research product and is meant to help designers (interaction designers, UI designers, web designers, usability/user experience folks, product managers et al) back their design decisions using quick, innovative & robust (online) user research methods rather than sub-optimal, manual or ad-hoc techniques. It’s a unique product and pretty much, the only one-of-its-kind anywhere in the world. In line with web2.0 trends, the product is conceptualized as a mashup; a mashup of three things– online surveys, online games and data oriented statistical methods. Presently, MindCanvas is in private beta but is being used by some of the biggest software/internet companies of the world for powering their user research.

In my role as the product manager for MindCanvas, if somebody asked me to describe the experience of building it, here’s what I would say- ‘ It’s been two long, hard, grueling years of relentless, uncompromising and serendipitous product development work’. In fact, it’s been like a tumultuous journey, with many ups and downs; many a times we have been at our wit’s ends while designing, coding or testing the software. However, I would think that we have ‘survived the initial storm’. We have learnt a lot during this journey and this learning has given us a head start in terms of understanding what it takes to make a world-class web product (specially ones that are targeted at a web2.0 audience).

So this post is essentially a wrap up of key learnings we have had while building a web product for a world audience. You could think of them as design principles, work practices or simply some observations, an appreciation of which, could help make your product better aligned to market realities. I must add that all these learnings are experiental; they are based on the mistakes we have made and the lessons we have learnt while building our product.

So here’s all that we have learnt….

Design is a Differentiator

Good design is a big differentiator; it sets you apart from your competitors, it puts you in a different league. It could be any aspect of the product design- the visual design, the process design etc. A great designed product ensures that you define the industry standards and others play catch-up. The example of Apple is a case in point.

The UI is the Software

This may sound preposterous to many, but for many a web 2.0 product, it is true. For the vast majority of users, the software is defined by the user interface. Their impressions (and thus their verdict) of your software are hugely influenced by how they react to the user interface. It’s like the proverbial tip-of-the-iceberg theory where people see only the tip (the UI) and are blind to its huge base (the backend) that is its actual foundation. What this implies for new software products is that a disproportionate quantum of time/effort should be spent on the user interface.

Users are distracted

Users today are being bombarded with a deluge of stimuli; hence catching their attention is becoming increasingly difficult. Every day, they are being exposed to newer applications/products, all of which promise them the moon. The product that you built (after all the hard toil) is just one drop in the deluge. Latest research indicates that users are making like/dislike decisions for new websites in as little as 50 milliseconds! This has huge implications for how you plan to introduce your product to first time users.

Users are empowered

We all are celebrating the power of web2.0 with its emphasis on user-generated content. However web2.0 is not necessarily good news for product companies; for it has hugely empowered users. Every user now thinks of himself/herself as an amateur journalist, a photographer or a movie shooter- thanks to user generated content. Users are in the driver’s seat. As a result, they don’t want to hear your sales pitches or go through long product demos; they want to interact directly with your product and make their own judgments. Designing a product for this web 2.0 generation of users is a different ballgame altogether.

The requirements document is dead

Agile web application development and its growing popularity means that the traditional model of software development with its emphasis on the requirements document is getting obsolete. Product development is increasingly being seen as an evolutionary and flexible process with actual user feedback influencing product design, as opposed to the rigidity of the requirements document model.

The only certainity in life is death, taxes & DESIGN CHANGES

This is a corollary of the above learning but it is more internally focused (within the development team). The team has to be made to understand the logic behind frequent design changes that the agile product development process entails. They need to appreciate the fact that design changes being affected, are not an outcome of management indecisiveness; rather they are necessitated by changes needed to the product based on feedback from users.

B.Y.O.M.

This is different from the generally understood benefits of bootstrapping. I strongly feel that if you are self-financing your product development (as opposed to being financed by private equity), you end up making a better product. The is because when you are financed externally, product design decisions start getting influenced by external revenue and profitability deadlines (often set by your equity partners). Instead of making the best product, you (probably) end up making a compromise product that is geared to meet revenue deadlines. Our experience shows that for making a great product, you should have the freedom to restructure/redesign parts of your product at any stage (based on user feedback). This freedom/flexibility is usually not afforded by an externally financed model.

K.I.S.S.

Keeping it short and simple is possibly the most abused product mantra. In a technologically overloaded environment, your product should be great at doing something, rather than be good at doing everything. Every new product feature adds complexity, costs and confuses the users, so one has to be very stingy in adding any new features to your product. The 37Signals philosophy of ‘building less’ explains this best.

Prevention >>> Cure

Early stage user testing works live preventive medication. While this has always been understood, it assumes special significance in an agile development model. Letting users interact with early product prototypes not only throws up bugs, it also gives fundamental insights into product design inadequacies that would otherwise surface only when the product has been launched.

Welcome the Devil’s Advocate

Many of the successful Web2.0 software products are coming, not from software companies but from ‘fringe’ players like web design studios, usability companies, media companies etc. This shows the importance of having people from diverse backgrounds participate in product design decisions. Such people tend to act like the devil’s advocate, asking the right questions and being a safety net against the tendency of software engineers to ‘geek out’ with the product development. We at Uzanto, have a mix of people from different backgrounds (i.e. cognitive psychology, software engineering, marketing & market research) and I think this has helped us.

Execution is all that matters

Finally, it is always the execution that matters. The product idea, by itself, is nothing; the devil lies in executing the idea really well. As the saying goes, success is 1% inspiration and 99% perspiration.