Digital Construction, Up-Front Design and Happy Clients
I know that "no specs" is very big right now, with high-profile designers insisting that you don't need to do any kind of documenting or specs, that you just need to make a few sketches and then start writing HTML prototypes, re-writing it until the customer likes it. This sounds suspiciously like the code-and-fix model, which we all know is garbage. Even worse, it sounds like undisciplined, hippy-dippy, egocentric, "I am an artiste" thinking. In fact, I dare say that it is non-design. For God's sake, people, we're in a pseudo-engineering profession. Act like it. Plan your work ahead of time, at least the important parts of it.
Also, I'm not sure where people find clients who are OK with having no idea what they're paying you to produce until you finally nail it on the 155th HTML re-write. "We're being iterative". No, you're being lame and wasteful. Clients LIKE to have some idea of what is being built before you start working. Clients LIKE to have some idea of how much time it will take before the project starts. Clients LIKE to have some idea of how much it is going to cost before the first invoice arrives. If you simply start writing code and re-write it until the client likes it, there is no way on God's green earth that you can reliably provide accurate answers to the questions of What/How Long/How Much.
That said, you can't plan for and spec out everything, either. If you do that you'll never get any actual work done. You also don't leave any slack in the project to allow for change, and allowing for change is good (that's the one thing that the hippy-dippy non-designers are right about). The trick, the real trick, is to follow the 80/20 rule and nail down the most critical 20% as best you can before starting.
I know that you're all going to scream that this is an awful analogy, but think about buying a house. The builder is going to provide you with a floor plan, some elevation renderings, and maybe even some material swatches. The builder is NOT going to say "wood is cheap, so we'll just frame it up and let you request changes until we have it the way you like it". That's wasteful of everyone's time. And it is still wasteful even if you are "only" writing HTML mock-ups, creating screens in VB, or coding interfaces in C#. Don't start writing code until you know (mostly) what it is you need to write.
Yes, I realize that writing software applications and creating websites is not the same as building a house. However, I believe that this digital construction industry of ours can - and should - learn from the physical construction industry. We need to get over ourselves and admit that our profession is not so much of a unique snowflake that we can't learn from our analog counterpart.
This is something that I have experimented with myself in recent months. I don't do lavish mock ups, but I do produce simple "floor plans" for clients when I take on a new web site or application project. All it takes is a flow chart, a layout diagram showing where the controls are going to be placed on each page or screen, and some notes right there on the layout diagram. Add in a page per screen outlining whatever business rules apply to the task the screen helps to accomplish, and a few more pages describing the context and any additional particulars regarding the process we're trying to automate or streamline. Heck, one time I went so far as to print the diagrams out like blueprints. The client loved it. We scribbled on the diagrams, then I made the changes in Visio and re-printed. We did this until we had hashed out all the spots that didn't look right. The client was pleased to feel like they had the most critical things hashed out before construction was in full swing, and I had a clear blueprint to build from that actually reflected what the client wanted. No guesswork. No rework. We made a few more changes as we went along, because you can't predict everything, but we more than covered the critical 20% and it made things go so much more smoothly than it would have gone if I just jumped in and started writing code.
It doesn't take much to come up with a good development blueprint to help steer the developers and some good client-facing materials that let the client know what they're getting into BEFORE construction actually begins. You don't have to produce NASA-level documentation, but you do need something to steer by and to make sure the client understands what is about to be done. I often hear developers and designers suggest the ludicrous idea of a one-page story for an application. Think about how crazy this is. A one-page story is not enough for a whole application, even if it's a tight and focused application with few features. There is no way that a client is going to really understand what you're building from a one-page story.
Now, bear in mind that although I am an advocate of designing up front, I am not an advocate of letting that design be sacred from its very first draft. can you change the design once the client takes a look at it? Hell yes. SHOULD you change it? Probably. It's rare to hit a home run on the first try, and the documentation is not meant to appease people, it's meant to make sure they understand what's going on so they can question it and change it if needed, BEFORE it's actually been built. Designing up front lets you catch a lot of mistakes before they are made. Paper is cheap. Visio is cheap. Take advantage of it.
I've heard this referred to as Big Design Up Front, but it's not really big, not if you do it right. It's more like Lean Design Up Front. And trust me, it is infinitely better than No Design Up Front.
