The right approach to design a web application (design software, not graphics)

Question

Recently I got requests from potential clients for very complex web applications.
They wanted me to write a spec before the "real" works begins.
The spec, as they see it should only be words describing the app and DB.
Where I found the best approach is to "paint" or "build" a prototype of the screens the application will have (html is easier then writing a book, especially if you use WYSIWYG just for this phase...standards are not important at this point).

When you have a screen in front of your eyes, it becomes immediately clear what elements should be (calender/photo galleries/ what major links, search box etc)

So, am I wrong in my approach? Or are the customers bad-informed on the correct way to do things?

Answer 1

While I would agree that you need to have some broad agreement with respect to the scope and cost of the system being built, I think it's grasping at straws to think that you can fully spec a system prior to getting it into the customer's hands. As you've discovered the customer very often doesn't know what he wants until he actually sees it. One way to address this is with mock ups, as you are accustomed to doing. I use them too during design and planning.

Most often, however, you need to get the actual product into the customer's hands to get the inevitable feedback on what works and what doesn't. You're better off doing this earlier rather than later since changes that occur late in development are much more difficult and expensive, at least in traditional methods. Using an agile method that delivers working software early and often, in conjunction with just enough planning and documentation gets better customer feedback than iterating over reams of specifications for a product that the customer may find that they don't want (or at least want they way they said).

I'd suggest that you need some documents that outline, broadly, the scope of the project. Enough so that you can agree on what is part of the system and what isn't. If you're building an inventory management application, they ought not expect to also get a customer relations management system, for example. Then, apply techniques from agile development methods to, in a lightweight manner, track the desired functionality and get some working code into their hands as early as possible and on a regular basis thereafter. This will require trust from all parties so you may want to start with small projects and timelines and build that trust up.

Answer 2

The spec is the most important part (longest to do) of the project. It tells you (and your client) what you are building and what they are paying you for.

There is no good getting down the line with the build and then finding the client had a different idea in mind. Specifications ensure You are all reading from the same book. Bundling some GUI ideas in there is a good idea too.

Bottom line is, both you and the client need to know what to expect before work begins. Your screens and mock-ups should be part of a broader specification

Your approach seems a little broken for a large application. Their expectations seem correct to me.