Developing An Application To Be Gmail And Not Google Wave

I believe most of us have heard of Google Wave and of course its sheer failure to appeal to the masses. As far as I am concerned, it was gone before I could even get my hands dirty trying it out. It barely lasted an year (well ok, technically 3 before it was completely wiped out by Google) and based on reviews on blogs and by folks around me, I don’t think I missed anything special. The description alone seemed to be vague and confounding and was on the lines of “Wave is a collaboration platform that consolidates e-mail, instant messaging, blogging, RSS, Sharepoint, document sharing and what not“.  Soon after its launch, Wave’s negative reviews were all over the place with generous usage of words like spamming, overwhelming information, invite-only constraint, buggy and non-intuitive interface, lacking notification system, synchronization bugs and poor performance. So the million dollar question is: What was Google thinking and what did it do wrong?
Google wave

 

Now I am by no means a technical design expert but there are the four things that I learnt from the failure of Google Wave:

  1. Design comes FIRST Design First
    Don’t get down to implementation as soon as you have the requirements, no matter how crystal clear they are. Create mockups, wire diagrams and flowcharts to better explain the user experience to the stakeholders and consider how your design might affect existing integrations with other systems.
  2. Design as a TEAM
    Design team
    Get those valuable insights and criticism to ensure that the design doesn’t seem right to only you but everyone else on the team as well. Discuss with others and ask for feedback about how your proposed design might impact other areas. Ensure that everyone is on board and make every effort to convince those who aren’t. Having allies on the team is undoubtedly beneficial but  accommodating the genuine concerns of team members who have reservations  related to your design is what makes your design fitter and more robust.
  3. Design out LOUDDesign loud
    Trying to explain your design to your team? Chuck the fancy power point presentations or sophisticated Visio diagrams. Draw flows and mockups on a WHITEBOARD! It’s more interactive and is a better way to collaborate in an informal setup based on my personal experience. Invite others to draw out their thoughts on the whiteboard and provide them with the opportunity to offer suggestions for improvement.
  4. Design should be VETTED
    Design vettedYou think you have everything figured out and your fingers are getting itchy to implement the design? Well your design might have underwent went a lot of revision and changes since you began and it’s good practice to get that one last approval before you get down to implementation. Perform a dry run of what the user experience will be like and explain it clearly to the folks involved.

 

 

 

And one final key question that you need to ask yourself: Did I meticulously consider all recommended solutions and why did I choose this one over all others? If you firmly believe you have the answer, what are you waiting for? Go get that application up and running!