NOT!

Now that I have your attention...

I actually Googled that today.  I entered interface driven design sucks right in the search box.  I even searched using:

"Interface Driven Design" sucks

"Interface Driven Development" +sucks

"IDD" +lame

I hate "Interface Driven" Design

and other variants.

There were no relevant results.

I don't know if I'm the only one that does this or not, but sometimes, when I want to make sure I've checked out both sides of "the story", I'll Google for the "anti-marketing" of whatever it is that is being marketed to me (or shoved down my throat).  I've been thinking a lot about Interface Driven Design lately, and thought it was time for a reality check.  "Let's make sure this isn't just more hype..."

I can take the lack of Google results one of a few ways, of course...

• Nobody knows what it is
• It's not being called Interface Driven Design anymore
• Nobody knows they are doing it
• Nobody's using it
• People are using it, hating it, but not blogging/posting about it
• 1...N people are using it with success

(There may be more options; haven't had my coffee yet...)

Of course, as with any approach that gains the status of Proper Noun and comes with a fair amount of "good marketing", our brains *wants* to believe that the final choice in my list above actually applies.  And given that Interface Driven Development is NOT a new concept, I'm personaly leaning that way.

I am 100% in favor of it in my own work.  And I am yanked harsly out of my own world when I encounter developers that still don't work even remotely under IDD.  I forget other people's backgrounds (that's something I need to work on, for sure).  I forget there's still a lot of developers out there that come from a world of hardcore documents that go between client and developer... tech documents that spell out very clearly (ad nauseum) "what is being built" and the "requirements", etc.  The words that even I used to utter are, "You Wouldn't Build A House Without A Blueprint".

But I think over time my idea of what medium to use for the blueprint has changed, rather dramatically.  It has evolved.  The blueprint is not a stack of papers the client puts their initials on, at least that's not the whole blueprint.  It certainly isn't the core of the Blueprinting Process.

No... for me, the "blueprint" for an application starts with what the application really is to the client.  And what is the application to the client?  The interface.  That's ALL it is.  The interface IS the application to them.

This is going to sound terribly condescending... but clients are much like 4 year olds.  I have both clients and a two year old, so I can speak from direct experience.  A two year old is incapable of thinking beyond what they see and hear.  If you tell a two year old who loves to brush their teeth, "First we're going to put your jammies on, then we're going to brush your teeth..." the only thing they hear is "teeth".  After which, you're going to have at least a little extra struggle to get them to put their PJ's on.

Sometimes, in my procedural way, I'll forget this.  And sometimes she just really wants to brush her teeth.  "Emily, let's get your jammies on and brush your teeth..."

"Tee!  TEE!! Tee Tee Tee Tee Tee Tee Tee Tee Tee!"

And so, we brush the teeth first.  (Of course this is never REALLY a big deal; I'm not THAT inflexible!)

So I say, "brush your client's teeth first".  The client has a need for software, or a website with some appilcation-like features.  They are already sold on the idea that you can build software to make their lives easier in some way.  When you say to them "First we're going to work on the specifications, then we're going to build your software", they are still thinking "software - that's what I want".  They focus on it; they obsess about it.

So, give it to them. Give them what they want to see, until it's just right and they don't feel the need to see any more.

Some of the process will feel a little nitpicky...

"Move that header image 5px to the right."

"Make the blue 'more blue'.

"I think I want to change the menu so it's on the right instead of the left"

Other parts of the process are absolutely essential to really understanding what the project is about -- where you discover the small (and sometimes very large) omissions...

"we need a new field to ask the user what their favorite color is, so we can send them the right gift shirt"
(Oh?  so when the form is submitted we need to notify the gift-shirt-department?)

"we need to make sure each item has a place to enter a tracking number, for the shipping department in Bumbleduck to see."
(Wait -- you have a shipping department in Bumbleduck?  And they're using this app too??)

I know some of these examples sound extreme, and I'm not saying that documentation and good conversation CAN'T reveal everything.  I'm not against documentation -- it's a core value.

What I'm saying is, use the user interface as the driving force behind everything you do.  Documentation should come from, and be directly attached to, a UI -- whenever possible.  It doesn't matter what prototyping tool you use - raw html, frontpage (gasp!), or even mockups in Photoshop. (Though my advice is, the UI should be modeled in its final medium... so there are ZERO changes to it later.)

The UI is the easiest thing to change -- so hack away at it until it doesn't need any more changes.  And who decides that?  The client, of course.

Clients should not be exposed to volumes of paperwork and asked to "approve this so we can freeze the spec and begin writing code".  They don't know what they are really approving.

Brush their teeth first, with IDD.  Let them obsess over the UI.  Let them show their friends and family... "look what so-and-so is building for me!"  Let them show their co-workers, their employees (Holy crap!) -- and get all the "it would be nice if..." comments and additions out of the way.  As you go, create a separate set of tech documents just for YOU, so that if you have a great idea for how to solve one of the problems/use cases presented by the UI, you have a place to put that idea down before you lose it.

Let the UI, and hence the client, drive this first stage of your project.  And, have fun doing it -- UI development is way more cool nowadays than the mundane "validate this form, store the data, and fire off some events" programming.  And, have fun with your client, exploring the different and possibly even more time-saving ways to make the UI work.

The side effects are mild, and may include:

• Faster time to completion
• Elimination of unforgotten or undiscovered requirements
• More accurate representation of the problems to be solved
• More accurate representation of the application that will be solving those problems
• The potential ability to hand the UI off to some more inexpensive developers to plug in the "guts"
• A happier client
• A happier you

I'm not all one-sided on this, even though, so far, IDD has not failed me yet.  But my Google results looking for supporting evidence against IDD came up empty.

So, I welcome your thoughts -- what are some ways that IDD can go wrong?  Have you had a personal experience with IDD *not* living up to your own expectations?  What would you have done differently?  Would you abandon IDD altogether?  If so, what technique would you use instead?  (No, you're not allowed to say "none"!!)