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

Everyone has a different approach to software development. Your method is just as viable as your client's. However, since your client is the one paying you, I suggest you conform to their standards OR suggest your method and see how they react.

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.

Answer 3

I use screen mockups in Balsamiq. It demonstrates the general look and user experience, without getting side tracked with the aesthetics of design

Answer 4

You might find the following articles useful in your communications:

• The Iceberg Secret, Revealed
• Painless Functional Specifications - Part 2: What's a Spec?
• Painless Functional Specifications - Part 3: But... How?

Remember you can still mock up HTML for yourself if it helps you think about the rest. To a large extent, the HTML design will then be your decision.

Personally, I'm a fan of FIT and Fitnesse for specifications. They make it both easier to keep up to date, and include some tests to verify that the code meets the specifications.

The other thing to remember is that as a rule the customer does not entirely know what they want, so even with a full spec don't consider it completely fixed.

Answer 5

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 6

The user interface is not the most important part of the app, focusing on this part so early might lead to false assumptions and impose choices based on interface, not on functionality.

I suggest focusing on functionality first, in order to agree what the app is expected to do, not how it will look on the screen. The interface will change in time, the client will want this button to the left not on the right, colored blue, not yellow, this text box larger and a different font, these are details for later, if you provide an interface with the specs you risk discussing those minor details instead of the important functionalities.

Take a look over Applying UML and Patterns, I think it might be useful. One of the books from the "Extreme Programming" series was also nice, I'll check later which one exactly.

Answer 7

You may want to take a look at the answers to the following question, though the question is for Medium size, it could still be rather complicated:

What are the basic questions to ask a person who wants his Medium sized website done?

Have you asked the customer why diagrams or prototype screen shots are being discouraged? They may have their own reasons for this, such as trying to limit the amount of work done before the "real" work begins. As an idea, that isn't so bad assuming they have gone through making a spec with others before and are comfortable with that process. If this is new to them, then it may be worth discussing why you want to have those prototypes, e.g. sometimes words are open to interpretation and this is more easily resolved with a picture than the thousand words that the picture shows easily.

Answer 8

First, you have your terminology wrong. In your question's title you ask "The right approach to design a web application" - but note: your client asked to you to write specifications for the application.

Specification does not equal design. It's dangerous to try and equate them.

As another replier said, a spec is so that both you and your client know what you are building. Design is the art of how to build it.

Specifications generally don't include mock-ups. In a nutshell, they include statements that describe exactly what the software should do. Note that this is very different from how it should do it. For web applications, I'd argue that mock-ups should be done in the design phase. So yes, to answer your question, you are incorrect in your approach.

I suggest you look at this article on Wikipedia for more information on what a specification is.

Edit: While what I've said is technically correct, as tvanfosson points out, it's difficult to completely spec out a system before beginning development. I recommend you read through his answer and talk to your clients about adopting a more realistic approach.