How to Build a Web Application

Business Intent
Why bother building the website? What is it going to do for your clients? I know some clients just want you to "build this", but I've consistently found that if we don't agree the organizational objectives upfront, it comes back to bite us later when we're discussing the UI or the functionality as we don't have a frame of reference for the discussion. Also, a lack of clear business intent tends to encourage scope creep. When we know the exact business problem we're building this project to solve it's easier to decide whether we *really* need a HR benefits portal as part of the sales extranet we're developing.

This is also your chance to maximize the value and the quality of the project for a very small investment of time. If the business intent is to "increase traffic", ask why. Chances are the goal is really to increase sales or leads, so at the very least you should consider measuring and improving conversions before bringing yet more prospects to an uninviting and confusing landing page.

Essential Tasks (Essential Use Cases)
What tasks must users be able to achieve via the site for it to achieve the business intent(s)? When a client just wants to take about their website, it may seem like an extra effort to describe everything in terms of use cases and to relate them back to the business intent that they're designed to solve, but it's worth burning an extra hour or two to help the client to think WHY they want a store locator or what the purpose of the "about us" page is, and when you get to the custom document exchange or workflow system or job tracking dashboard, without use cases you're extremely unlikely to build a system that achieves the business intent. It's a simple approach, but it really helps with traceability between functional requirements and their underlying business intent. Of course, having a catalog of re-usable use cases for common requirements that can be customized is often a great way to make this process more efficient for the objectives that aren't completely unique to the client.

Screens and Actions
I've tried a lot of different ways of specifying applications, but in my experience, until I have at the very least a complete list of screens and controller actions for each use case (including optional and error flows) I have no idea of the scope of a project. Of course, if someone wants a "with a twist" project, you may well be able to just select packages and allow them to customize the screens and actions to meet any custom requirements, but in my experience, until you have a complete list of screens and actions you don't really have a sense of how much work a project is going to be.

The biggest challenge I have with screens and actions is that most of my clients really don't want to think about them. They throw out a paragraph or two about the problem they're trying to solve, expect a fixed bid based on that and are often insulted that you are so stupid that you can't figure out exactly what it'll cost to build their application based upon what to them is a very clear two paragraph spec! Of course, as you start to ask questions about the app it is clear that even THEY have no real idea of how the app would work, how many screens it'd require or even what use cases are necessary. It still amazes me how many clients who at this point can't believe you won't just give them a number and sort out the scope of the project after you've agreed how much it is going to cost (*boggle*).

These days, depending upon the complexity of the app I either make up a list of screens and actions that wouldn't be a horrible implementation and provide a fixed bid for that or (if I can't do that in under three hours) just recommend an hourly discovery phase with a 20 hour initial undertaking. I also send over a document to clients who "know exactly what they want and don't need a discovery phase" describing the information I need them to send me about every single screen and controller action for each of their use cases. I don't really expect that they'll fill it out, but you never know - it might happen one day. It's also a fairly polite way to blow off someone who wouldn't be worth working with anyway. Of course, if anyone actually HAS a magical way of providing an accurate fixed bid for a fixed scope, bid, and timeframe project before you know the scope, please make a comment below!

Information Architecture
Between the business intents, essential tasks and their screens and actions, we have a pretty good sense of the functionality required, but not of the way to access it. The next stage is to develop a site map and a structure for the UI in terms of what should go where to allow users to achieve their essential tasks easily. Right now, we just fire up our content management system and we're working on a simple CSS framework that will allow us to create a skinnable wireframe to which we'll be able to attach design elements and a color scheme later in the process once the "wireframe" of the UI has been approved. I think this process is best done timeboxed in person rather than as an iterative process as a fair amount of discussion/consulting is often required. Where there are multiple decision makers, a single round of revisions for some options/choices may be required.

Functional Wireframe
Because we have a collection of Domain Specific Languages for describing and generating the code for screens, actions and the underlying object model (objects, relationships, properties, value lists, transformations, validations, class and object methods, etc.), we generate a first cut of the app based on the screens and actions described (and the object model that can be inferred or lightly designed from the details of those screens and actions). I'm still playing with the process, but I think the next step should be a client walk through and a single round of revisions to the screens, actions and underlying object model to lock down and approve the application functionality.

Look and Feel
Some designers may disagree with me, but I feel that for the vast majority of smaller web apps (consulting, project management, programming, design and deployment for under $25-$35k) it is best to start with the business intent, use cases, information architecture and then to generate the functionality to ensure you have a site with an IA optimized for the essential use cases and you have a working system which the client can add real content to. At that point, skinning the approved wireframe and adding design elements within a prescribed CSS framework allows for a very cost effective way of getting a professional looking site which you know is likely to work to solve the business problems and work with the functioning site because you have built the working site before skinning it with the appropriate design elements.

Any thoughts on the approach? Input appreciated!