Thursday, July 03, 2008

Design By Prototype

We've just started a new thing at my company and I'm hoping it's a success, as I'm kinda sorta right in the middle of it.

When a new feature for your product comes along, be it big or small, how does engineering find out about it?  What's the actual hand off that they're given to work with? A spec?  Use cases?  Screen shots?  Personally we've found (being a small company, < 10 tech people) that the perfect document  never gets written, first of all.  Not only can no one decide on the proper amount of detail to use, it doesn't really matter what's documented because if you find out in the last week of development that you didn't put in a feature (undocumented) that the product manager wanted, you're going to be doing it anyway.

One step removed from Word documents is "design by screenshot", which is basically what we live by now.  This is when the graphic artist mocks up what the feature will look like (whether that takes 1 shot or 20 depends on the feature).  This way, in theory, every non-engineer can look at it and say "Ok, now I know what I'm going to get, I know what to expect."

Many, many problems with this approach.  The two biggest are a) what you just drew may not make any sense technologically, and b) the engineer charged with coding the feature is now going to spend almost all of his time dealing with issues like "Can you move that widget 10 pixels to the left?"

So we're trying something different.  Not just "design by prototype", but "design by prototype in Rails."  This is where a single engineer (and sometimes, such as in this case, a front end guy) work on a fully functional framework of what the feature should look like.  Depending on your skills this could either mean "start with the HTML and work backwards to add functionality", or it could mean "start with the web services and slap a front end on it."  The idea is to have a finished product that makes everybody happy:

  • Everybody can see and interact with it.
  • It has a real front-end, in code rather than Photoshop, so all the "move it 10 pixels over" issues are out of the way early.
  • The engineer who'll make the real version gets most of those potential "And what happens if I click this?" questions answered in a way that screenshots and word documents could never do.

Now, some people might say "We've been doing that for years."  Here's the catch, at least how we're doing it.  The current product is in ColdFusion, and we're moving it to .NET.  So what am I writing the prototypes in?  Simple - Ruby on Rails.

If you write your prototype in the same language as your real product, the temptation is far too great to just roll it out the door as Version 1.0.    That defeats the whole purpose, because now either your prototype takes longer to build because you know that it's going live to customers, or else you're burdened for the next year or more trying to hack and patch it and arguing about why oh why you made such and such decision back then, when now six months later you can clearly see that this was the wrong decision.

By prototyping in Rails, we halt this problem in its tracks by making it impossible to roll the prototype into production.  We don't even have a Rails production environment.  The goal of the prototype is the hand off to engineering.  It's not to have perfect code, or final look and feel, although the closer you get to both, the better.  The idea is to do the coding equivalent of a wireframe, where you say "Ok, this app essentially has half a dozen major sections.  Here they are, and here's how the customer gets from one to another."  Repeat and enhance with as much detail as you have time for.  My handoff meeting is actually in a few hours, and I will keep tweaking on it until I walk into that meeting.  (I'm on a train with no net access at the moment, you see....)

It also gets everybody playing to their strengths.  I am not a great "enterprise architecture" guy.  Sure I can say "I realize that this feature here is best served with a web service," but actually implementing that service in a meaningful way?  There are guys better suited to that.  So in my prototypes I whip up a quick service in Rails (typically REST style) with the knowledge that the enterprise guys can just drop in their replacement.  Meanwhile I know that I have one developer as "user interface engineer", and five who will only do markup on pain of death.  So the UI guy is charged with getting the prototype's markup as complete as possible, allowing the coders to come in and just replace the moving parts out from underneath.  The UI guy can do it faster, and can work with the graphic designers sooner, so they're happier that they see what the finished product will look like in week 1, instead of tweaking things 10 pixels to the left while trying to do QA in the last week before shipping.

Personally, I'm having a grand time.  This is the stuff I love.

No comments: