As far as possible, we try to use a standard process for our web projects. Although it can seem like overkill for smaller projects, one thing I’ve discovered is that when it comes to building web sites for large organizations, there really are no shortcuts.
If you cut corners, it will always come back to bite you in the end, whether it is in the form of last minute design or content changes or a site that just doesn’t meet users’ needs.
Consequently, we’ve worked pretty hard to come up with a standardized web site development workflow (GIF 91KB). Download the Visio version (VSD 423KB).
We use this to develop our project plan and we present it to customers to explain all the steps needed to develop their site and help them understand why the timeline is what it is (i.e. why it’s so long).
The Seven Phases of Web Site Development
Our workflow goes through seven stages:
- Concept
- Discovery
- Content development
- Design
- Development
- Launch
- Post-launch
The web development workflow diagram breaks down each of these phases into high-level tasks. These tasks often involve milestones or checkpoints that need to be met or in deliverables that need to be produced – these are all identified in the diagram.
In addition, some tasks have templates that can be used and others have guidelines that can be followed. This increases the level of standardization across projects and avoids ‘reinventing the wheel’.
1. Concept
This is where the project is defined. The key tool for doing this is the creative brief (learn more about how to write a creative brief). It is the document we go back to if we have questions about the goals or requirements of the project, or if scope creep threatens to interfere.
Once the scope of the project is fully understood a project plan can be developed.
2. Discovery
The discovery phase begins with the kick-off meeting in which the project is officially started. This phase largely involves research – into the competitive landscape, into users’ needs and goals, and so on.
Various elements of the web site outlined in the Concept phase will likely get amended based on the results of this work.
3. Content Development
Content development and #4, Design, actually tend to occur concurrently rather than sequentially. For instance, we need to have a good idea of the information architecture of the site (which is done in the design phase) before we start developing the content.
And, as the content is developed, it will typically impact the IA – adding or taking away pages or (rarely) even sections of a site.
4. Design
Design begins with the development of the site’s information architecture and the testing of it using lo-fi prototypes which I usually mock-up in PowerPoint.
This testing phase is critical as it’s very easy to make changes here that would be very time-consuming to do later on in the project.
Once we have the web site IA worked out, the actual visual design is done and approved. We try to build in sufficient time for the visual design piece to be as iterative as needed – there’s nothing worse than trying to be creative when up against a really tight deadline.
It’s really important to get the design approved before starting phase #5, Development. It’s much easier to do rework in Photoshop than in HTML, so it really saves time to make sure that the development phase just involves building out the site and no designing ‘on-the-fly’.
5. Development
This phase involves building the site template and then the pages themselves. We like to review the site template before the bulk of the pages are built out to make sure that the coding is up to scratch.
It’s not uncommon that some design tweaks get made during this phase, as we’re always having ideas about how the site can be improved.
However, if these ideas could cause a material slip in deadlines, they may well get pushed back to a ‘phase 2’ enhancement. We also like to do more usability testing on the actual site to make sure we haven’t missed anything.
And, of course, the site goes through a thorough content and code QA check.
6. Launch
In theory, launch is pretty straight-forward. We never launch on a Friday (who wants to be working late into Friday night, or on a weekend?) and make sure that the appropriate IT resources are available for support.
Once we’ve launched the site, we’ll do a complete link check and also check that any applications are working fine.
7. Post-launch
Once the site is live, we set up a maintenance plan with the client. We’ll then do an internal project post-mortem among our team, and later on with the client.
It’s really important to do these, so that you can learn from things that went well and things that didn’t.
Exceptions to the Rule
How closely we actually follow this methodology depends a lot on the size of the project and the amount of time we have to complete it.
It’s not uncommon for us to skip steps based on these factors; however, if we do so because of client constraints, we make sure they understand the potential implications – for example, cut back on research and your site may not meet users’ needs; cut back on usability testing and your site will be harder for people to use).
Further Reading on Web Design Workflows
Kelly Goto’s Web ReDesign 2.0: Workflow that Works takes you through the process of developing or redesigning a web site by following a series of clearly laid out steps organized into five stages.
This is a practical, great looking book that that contains lots of examples and guides to make the development process as straight forward as possible.
It’s well worth a read for anyone serious about improving their web development methodology.
Thanks for the list! This is just what I was looking for and it’s very well put together. I think this process is a little different for everyone based on their likes and dislikes. The process is also a little different for people on their own or part of a company but for the basics are the same for everyone.
Great list, and I thorougly enjoyed reading it. I’m really looking for more blog posts that give an overview of the entire development process. Perhaps in the future you could give each phase a little more in-depth look. I would be particularly interested in a post covering the creative document, and what exactly it is. Of course, I understand you can’t give away all your secrets, but it would be beneficial to the web design community I feel.
Matt – I absloutely agree that the process is different for each organization; you can never have one single process that works for everyone. However, I do believe that there are common elements across all organizations and projects.
I see a workflow such as this as something to be customized for your own particular needs and circumstances.
Nick – I could certainly go into each phase in more detail (although that is starting to sound a little too much like work – like most people, I’m not a huge fan of writing documentation).
I’d be happy to write more about the creative brief, especially as it is such a useful document. As for my secrets, please believe me when I say I have absolutely none – everything I know is available for others to use if they’re interested.
Thanks for this – it’s great to hear about other designers’ processes and a good chance to analyze one’s own. Cheers!
Way too heavy on design, usability, personas and other fluff to keep liberal arts majors employed. Way too light on what matters: the actual programming. I’ve been doing this for seven years and have never found a way around letting the most technical person in the room drive the project. Sure geeks are unpredictable – but they’re the only ones at the table with something substantive to offer. Do yourself a favor and read Joel On Software.
=?utf-8?B?ZGVsLmljaW8udXMvcG9wdWxhcg==?=
Prototype Dissected
<table class='DetailsTable' cellspacing='0' …
Hi, it is a very good explanation of the web site development workflow. I searched this for a long time and finally i accidentally found it.
I have an Italian blog (loman.it) and I think if I can translate it for my blog, obviously the link at this site will be attached, showing that my post is only a translation.
Can I? 🙂
while the text sound crispy sounds like other development workflow developed by other people. I think you should give more explanation or case study here to make it more clear.
the diagram give more information. I like it very much. thanks for the insight.
I only do tiny little sites for a few individuals and a couple of small organizations. That process sounds exactly right for small sites too. This outline is extremely useful for going over the steps with anyone with an interest in a project. I’ve had to do a couple with no content provided from the siteowners at all and not much concept either. They just knew they needed a site. A concrete explanation of what’s needed to get a good one started is a big help.
Do you think that you could post a more printer-friendly version of the workflow…it would be great to have it in a more scalable format
-Mike
Ralph – while I appreciate your point of view, it is why I believe that internal web teams should be part of Marketing and/or Communications rather than IS. Simply put, most IS folks just don’t get usability.
When it comes to building a web site (or pretty much anything, for that matter), the last thing you want to do is to let the most technical person (i.e. the programmer) drive the project.
The project must be led by someone who understands the business goals of the web site and also the user needs – which can only be determined by ‘fluffy stuff’ like usability testing, persona development and so on.
Of course, the programmer or developer needs to be involved from the get-go, but their role is more of the subject-matter expert than the project lead.
Actually, I do read Joel on Software and follow his method for writing functional specs, which is actually very much centered around understanding and catering to the needs of the user.
Content before design? Oh if it were that easy! ;0)
You and I both know (as does anyone who’s ever worked on a Web project) that the goal is always to have content before you get to design. The reality is that you almost NEVER have it.
Keith, i actually lost a job because i demanded the content before i started designeing , so i feel your pain. its hard for a small setup to get things going the way they should, seems that the more ‘muscle’ you have the easier it is convincing people the way the process should go, instead of them threating and sometimes leaving because they feel that they went to small setup to ‘get it their way’
but more on subject, i thoroughly emjoyed the read, and some of the pratices i will adopt into my own planning.
Hello Christian.
Thanks for the great post on your web development process. We use almost the same process as you when designing a website. Most of our procedures come from: Web ReDesign 2.0: Workflow that Works, a great book on the fine and long process of web development.
Cheers.
P.S. I love the Live Comment Preview.
Personally, I think it is a big mistake to start designing a site before all the content is received. I insist that at least 95% of the content is in hand before starting. The developer depends on the client to do their part. If your client is paying by the hour for all the administrative time involved when content isn’t finished, that might be okay, but not my preference, otherwise I’d turn down the job. If you want to wait five years for all the content to be supplied, go ahead – that has happened. Insisting that the content be supplied before starting design and development is only way to come up with an accurate price for the job, and no surprises and misunderstandings either. If you quote a price before your client supplies the content you’ll get eaten up my administrative costs (typically 10% of the job), but can go much higher in cases where content isn’t complete. Also you’ll end up doing re-design.
There is actually a specific section in “Secrets of Successful Websites” iirc, that delineates the types of clients they do not accept. – If you have to let a job go, let it go. Spec is everything.
Also. Ever seen stuff done solely by developers? Most of it couldn’t sell if the developer’s life depended on it.
There is no existence of the product/project without business, UI, IA, sceno/perso (use case/user), target audience, design, UT, etc. Just because they are less ‘hard skills’ than programming doesn’t make them vapor. Development is really more like a commodity these days, anyhow.
You architect the product almost like a Program Manager, the developer simply executes.
The project lead must always be a jack of all trades. It would be a wreck if he/she weren’t.
I too would wish to hear more detail on each phase. The first I heard of method was ye olde ‘5 D’s.
“Keith”:https://smileycat.com/miaow/archives/000222.php#comment-3216 & “Jeff”:https://smileycat.com/miaow/archives/000222.php#comment-3221 – it’s important to note that I include information architecture development in the design phase, which is why it starts at around the same time (if not a little before) content development.
You need to have the IA at least 80% worked out before you start content development to avoid doing work that gets discarded.
The two phases occur concurrently largely for practical reasons. If you developed all your content first before doing anything I include in the design phase, your project would take forever!
You can also get more stuff from Macromedia;
“http://www.macromedia.com/resources/techniques/”:http://www.macromedia.com/resources/techniques/
At datanumeric we always insist clients write proper project brief which defines all aspects of the web project. If client is reluctant to write brief, after discussion with them we will write the brief and send to client for approval. We also insist that client designate one person as project coordinator, all our communication will be with that person. It will be coordinator’s responsibility to take approvals from other stakeholders at client side.
This is basically a restatement of the old waterfall model of software development. I can see getting away with this for a small, static site but for anything bigger you have to iterate or die.
Peter – in my experience this process works fine for both small and large sites. It’s an oversimplication, but for larger sites you just add more steps.
The key difference between our process and from what I’ve read about the ‘waterfall’ method (thanks for the link) is that we involve the user throughout the process, not just at the beginning and the end.
The process we use does not discount the need to iterate at certain points either. During any of the phases, but particularly during the design phase, there can be (and often are) multiple iterations in order to get it right.
Honing a design through multiple iterations is an intregal part of our development process. However, we try to do this as far upfront as possible so that it has the lowest impact in terms of time and effort.
This is absolutely awesome stuff, I think you are right on. Everyone does things differently, but I certainly learned a few things from your process.
What would you think about doing a printable version of this? I would love to have this on my desk or in plain sight and refer to it. Thanks for providing this awesome resource.
In response to “Mike’s request”:https://smileycat.com/miaow/archives/000222.php#comment-3214 I’ve added a Visio version of the workflow template to the post.
Feel free to download and customize it to suit your needs.
At what point in your process do you send the proposal to the client? Do you send the Creative Brief with the proposal. Or do you only do this kind of discovery work after you get a signed proposal? Do you bill for your proposal process? Thanks.
We have developed a Standardized Website Development Process that is fully integrated with the develpment tools and the entire Websie Infrastructure. You can go from concept through grey-screen prototyping, content and design development to production launch and post-launch maintenance using one fully integrated system – WebAssemblyLine(tm). You should check it out and drop us a line what you think… Here is the link “www.webassemblyline.com”:http://www.webassemblyline.com
*Houshang* – I would send the proposal to the client upfront. The work you do in developing the creative brief can form the bulk of the proposal, although the creative brief is primarily an internal document for the web design team.
You don’t want to do too much work for free, but you need to do enough to get the gig – it’s the eternal dilemma, and where the balance lies really depends on each project.
Typically, it’s hard to charge for a proposal – too many of your competitors will not. If you can, then good luck to you!
I think this workflow is well defined, IMO. Being a software engineer, I am used to very much the same iterative approach. The same priciples apply to any kind of technical projects.
The Design phase is actually the most important, because it will condition the success of all the other steps. Going back to a design phase, when you are already well into the coding phase, will cost you a lot of time, and big $$$$!.
All the team members need to be aware of the different aspects of the project, or at least be willing to understand usability, performance, maintainability, coding complexity, testing, etc..
The other important aspect seems to be customer inputs and involvment. To build a healthy relationship always keep the customer in the loop.