FDD & Web Development

When I first learnt about FDD, I was impressed by it's simplicity and clarity. As a development process, it stood well out from the crowd when compared to other far more cumbersome & complex processes that seemed only to make things harder. After learning more about FDD, my opinion of it as a development process was not in question, I wanted to use it. The issue was whether I could apply it to what I did, ie. web development And if that was possible, how to go about making it happen?

The short answer is yes, you can use FDD for web development. How? That's not so easy, as web development covers a wide range of project types, how to apply FDD will depend on the nature of the project at hand.

There is also much more to FDD than just the five processes that have the potential to make a big difference to any software development project (which is an article in it's own right). For the purposes of this article, I'll stick to the main aspects of FDD (ie. the 5 processes).


As a general rule of thumb, FDD is extremely effective on large projects with complex business logic. It is not so effective on small projects with little business logic. That's not to say that you can't use elements of FDD to help manage your projects better but it's pretty hard to enforce code and design reviews (see processes 4 & 5) when you only have one developer on the project!


There is nothing in FDD that dictates what technology to use. However, the simple fact that the first process is primarily object modelling means that if you are not using an OO technology, using FDD is not going to be straight forward. Having said that, I've successfully used aspects of FDD on web projects using a variety of web orientated technologies such as ASP, JSP and PHP.


The key to FDD is process one, the key to process one is having a great object modeller and a great project manager. Note: it doesn't matter what process you use, you need good people. No process, including FDD will help you if you don't have the right people. If you are thinking about FDD to help you resolve this issue, think again.


You need to be well aware that FDD, to quote Fred Brooks, is not a silver bullet. It doesn't cover every aspect of development. There are many aspects of a standard project that you'll still need to manage outside of what FDD can help with. These aspects include

  • Requirements gathering
  • Interface design
  • Testing
  • Deployment


Trying to implement a new process is difficult regardless of which process you choose. Not only do you have to learn the process you also have to produce a result at the same time. Be prepared for some confusion and difficulty which goes hand in hand with trying anything new. That being said, the structure of FDD can easily be adapted to move gradually from your existing process to an FDD approach.

What I found to be an effective way get started is to look at projects in an FDD way - that is, start to think of projects as a set of features. This approach can be used on almost any project regardless of size or technology.

  1. Define a project as a list of features or functions

    At some point, every project needs to be defined by what it does or what functionality it provides. By listing all these functions (or features) of the system, you are defining what it is you need to build to complete the project.

    The key is to make sure you use the same language as the client, don't use technical terms that the client won't understand because they won't care if you build it. If they understand the feature, they will care about whether it has or hasn't been built.


  2. Plan development based on features

    Once you know what you have to build, it's a fairly straight forward task to work out the order. As some features will be dependant on others, they clearly have to be built first. Whatever the order, you now have a development plan that you use to track your progress.

    I find it useful to get the lead developer to provide you with the order and time frame for the development plan, that way, they commit themselves to the plan and I have something to go back to when things aren't happening when they are supposed to.


  3. Weekly project status meetings based on features completed

    If you have a list what needs to be done and by when, it's easy to then track progress and report back to the client. It's amazing how effective it is to be able to tell a client what features have been completed and what you're currently working on.

    As a project manager, you also find out about problems much early in the piece and have a chance to deal with them before they become a major issue.


There is no doubt that FDD can be used for web development, it has been done successful on numerous projects. As a process, it is easy to understand takes a common sense approach. But the qualities of FDD are not as important as whether FDD is appropriate to the type of development you do and will help you to achieve what it is you hope to gain from adopting FDD.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Web site Features

Hi Martin,

I'm very interested how you are applying FDD to web development here. I have a few questions...

First, how do you address the design phase? Do you use "Build Overall Model" to build a sitemap and screen flow? Identify significant pages and their functionality/content? What about the underlying code?

With a web development project, where the focus tends to be on a JSP or PHP page, how do you map features to pages? What sort of template do you use to describe a feature?


:: Gavin Baker -- http://antonym.org

Defining & Mapping Features

Hi Gavin,

Some interesting questions. We are still working on a single consistent approach to these issues which are harder than they seem on the surface. The majority of web projects that I deal with have very little business logic, they are basically content or information systems and the majority of the logic is presentation or display logic. We have to build a front end for the public to view the information and a backend (or admin section) to allow the client to maintain the content.

In defining and designing a solution the approach we take is to split it into requirements & specification. The design and mapping of features to screens happens in the specification phase.

This is basically a wishlist of what the solution is supposed to provide.

  • Establish a project objective.
  • Establish project requirements

The key is to get a concise project objective, this informs almost every decision from then on. Helps to put everything into perspective.

We create a number of documents to define the project. It's the closest we have to the FDD Process One

  • Interaction design - frontend & backend
    (this is both page flow and logic, we use a visual vocab defined by Jesse James Garrett (http://jjg.net/ia/visvocab/)
  • Page Wireframes - frontend & backend
  • DB Schema
  • Class Diagram
  • Feature List

A feature is basically a unit of functionality that is relevant to the client. For the systems I work with, it basically comes down to view/add/edit/delete.

- list surveys
- view survey state
- set survey state
- add survey
- edit survey

Features are mapped to the screens via the interaction design (similar to a page flow) and are presented in a wireframe. Often you find that more than one feature is represented on a page, infact, sometimes a single page has upto 3 or 4 features.

Even though we primarily use php, where possible we try to separate out the layers and take a MVC approach. We use a combination of Smarty Template and PEAR DB libary to separate out the interface and data layers. In attempting to take an MVC approach, we do the following:

  • Business logic is captured in classes in php (the model)
  • The view is the smarty template
  • Additional php script acts as the controller.

We have just started to investigate phrame which is a php version of the jakarta struts project to better implement the MVC approach.

Hope this helps.


Web/UI Design Prototyping


I think you might be interested in Denim, a prototyping tool for website design. An interesting article is over at Wired too.

A few years ago, while working on a fairly large FDD Java project, I was leading the UI team. I insisted that all UI design was done in pencil on huge sheets of paper, until the initial design review meeting. At first there was resistance - developers wanted to produce real screens - and customers wanted to see real screens! But the cost in time and effort to produce even mockups is enormous, wasteful, and possibly detrimental to the process.

Put a screen in front of a customer at a UI review, and the first thing they will want to do is change the font. Or the colour. Screens that are too 'real' take the focus away from the functional aspects, the all-important flow, and the relative layout. People get stuck on irrelevant detail, too early in the process, and don't end up asking or answering more important questions.

So paper prototypes give you the JEDI approach for UI. There is just enough design on paper to see the essential elements; fields, buttons, actions, linking, etc. But with a sketch, people aren't distracted by fonts and colours. And it's cheap and easy to change!

Only once you've done a few iterations on paper do you bother putting it on screen, and by this stage you've already had several design iterations on paper and at least one design review.

Anyway, Denim appears to be a tool to do on screen what we've been doing on paper. But I'm not ready to give up my H2B just yet...

:: Gavin Baker -- http://antonym.org

Web Prototyping

Hi Gavin,

I agree with you that often it's best to start with the trusty pencil and a big piece of paper. It certainy helps to focus on the functionality and flow rather than aesthetics which are all too easily distracting.

For doing mockups, we use a plugin to Visio that makes it pretty easy to build the screens. It has all the web objects defined so you can just drag and drop. Making changes is very easy, it uses a template approach so you can make a change to all screens simply by altering a single template.

Then you can export as a html prototype for clients to view online can click through (as long as you can live with html code created by microsoft Eye-wink.

I find that unless the user can see something on a screen and interact with it, you don't get a true sense of how it will work and if it makes sense, which is something that a paper prototype can't do.

Thanks for the link to Demin - looks interesting, will look into it further.


Great Tool Thanks

Denim looks like a fantastic idea, still a bit rough around the edges but very cool technology (missing things like ability to group ungroup elements, operate on multiple elements at a time .... ).

The problem with paper based sketching is that it often requires a lot of grunt work to copy screens and flows again and again and to make sure that all elements are copied accurately.

Ideally, togethersoft should take their technology and provide a new diagram type to be able to create diagrams like this. I do not imagine that it would be too difficult.

Anyway, just a quick thank you for pointing this tool out.


Maybe you're missing something...

When you say "it often requires a lot of grunt work to copy screens and flows again and again" it makes me think that you are missing an important abstraction.

When writing code and I find myself cutting and pasting, it's a sign that I should be able to "normalize" that aspect of the code by moving the repetitive code into a parent class or extract it into a helper class or something like that. In a relational databases, we normalize pieces of our data model into their own tables in order to avoid unnecesarily replicating data.

I think this applies equally to your paper design and serves as a good indicator of the direction that your software design should go.

For example, when you say "copy screens", I assume you are reffering to the header, navigation, footer, etc. that makes up the look of your site. This is an ideal place for a template abstraction that you can "normalize" out. Draw your template on a separate piece of paper and assume that all other pages will follow this template. No more copying and an indication that a central mechanism for handling the look of your website might be a usefull thing.

Visual Vocabulary Models are excellent for Step 1

I would second the comment on use of VV models for step 1 in FDD. At 4thpass we have our whole product designed in VV models now. Developing the VV model for the interaction design of the site/application has become the first step in FDD. The UI designers create the VV model. We use the VV model to devise UI Development Features - Views and Controllers (or Action classes in Struts). We also create a list of all the detailed UI designs required (wire frames). Hence, we have a Feature List for the developers and one for the UI designers.

It's great to hear that VV diagrams are getting traction with other people and particularly other FDDers.


David J. Anderson
author of "Agile Management for Software Engineering"

The Model - PD, UI & SI

There's another long thread running that's spawned some interesting side discussions. I'd like to promote one of these out of there, since it's getting rather confusing and since I think there's a lot of valuable discussion going on I'd hate for it to

applying FDD in a small dev. firm

Hi Martin,
I came to this site after reading an article on the SitePoint forum about web development methodologies. I've read through this site about FDD and am interested in applying these concepts to my web development, but from what I've read, this won't work on small web dev teams or firms. Am I correct in this assumption? I'm pretty much on my own except for a graphic designer. Is FDD scalable for smaller firms?
Thank you for your time.
Lisa Wilcox
Web Girl Web Designs

Yes, I believe you can use FD

Yes, I believe you can use FDD on small projects. Do the FDD processes as they apply to your specific situation. They don't have to be done sequentially, by the way, you can do them all in parallel if that works for you. Don't get hung up on details of what might seem to be "prescribed" practice. I've found FDD is very adaptable to very small projects.

applying FDD to in a small dev firm

Hi Lisa,

Thanks for your interest. My apologies for taking so long to get back to you. You can definitely apply the principles of FDD to a small web dev environment. On average I have one developer and one designer on each project and I still use the approach set out by FDD. Ofcourse I have modified it to scale down, I don't do the full process 1 object modelling which then leads to other modifications. The key is to think of your project in terms of features and plan the development around it. Combine this with weekly progress reports and you'll have a scaled down version of FDD that will help you run projects more effectively. I've been taking this approach for small web development projects for the last 5 years and have found it to be extremely helpful.

If you want more information, email me at martin@designit.com.au