If Maslow Built Software

The moment your software team grows beyond a team of one, you need to communicate. Someone will have an idea on improving a new feature, creating a new product, etc.  Immediately the question arises of how best to share the idea.  For most people, the conversation moves immediately to tools.  Should we use a wiki, Basecamp, a word doc, etc?

When I first started in software, we would use documents.  Word documents.  Big, long, unwieldy pages of text intermixed with a few tables and screenshots of other people’s products for good measure.  They were difficult to create and rarely read.  They were understood even less.  They were tracked, signed off on, and referred to long after the product had forked miles away.

The early document based ways of communicating your idea (ie. what the software should do) were so broken that product managers started using this idea called “wireframing” (stolen from designers).  Think of it as a sketch of what the product should be or do.  The idea was to get the rough concept out there for discussion and iterate before too much “work” had gone into it.  A picture says a thousand words and all that.  This was a big step forward, but in the end, it was so rough that a lot was up for grabs.  After all, details matter.

Enter the mock up.  I also call this a “high fidelity screenshot”.  This is a best guess on how the screens should really look.  Every icon, every label.  No “lorem ipsum”.  Make a call.  Put in real data.  The downside of this is that it takes more time, but you get much, much better results.  In truth, I have a hard time making real decisions on anything less than this level of detail.  I have to credit the 37Signals guys with helping me to see the power of this idea.

However, last week a couple fellows from Google gave a great talk at SXSW on prototyping.  The idea here is to not only show the visual design in detail, but the interaction as well.  Not the interaction of the entire app, but just a piece – say the posting of a comment or the uploading of a file.  Interaction is a key component and one that is often left to the person writing the code. The designer or PM will usually have some great input like “follow what gmail does” or “make this like Facebook”.  Awesome.

The idea of prototyping has added benefits in selling your idea.  Every idea needs support to get done and showing it in action can help you get there very quickly.  It is an idea whose time has come.

Years ago I would make clickable ppt demos of ideas to help sell them.  Somewhere along the way I lost that idea and got stuck in mocking up pages.  Thank you Michael and Darren for reminding me of this wonderful idea and how to apply it smartly to web development.

Paul

AboutPaul

a.k.a.:ppedrazzi

3 comments

  1. It always disappointed me that no one ever seemed to use HTML for authoring documents or for prototyping UIs – why prototype a Web UI using Word??!?!?!?

    For myself, HTML seemed perfect. I could draft the interaction, and if it had to look nice, somebody could hack a stylesheet to turn my draft into beauty with no change to function.

  2. It always disappointed me that no one ever seemed to use HTML for authoring documents or for prototyping UIs – why prototype a Web UI using Word??!?!?!?

    For myself, HTML seemed perfect. I could draft the interaction, and if it had to look nice, somebody could hack a stylesheet to turn my draft into beauty with no change to function.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.