By: Jeremy Wright

March 18th, 2002

Reader Rating: 8.5

<chant>
I am a professional!
</chant>

Before reading any further, please chant the above in monotone three times.

Done? Great. The way I figure it, if you truly want to believe that you're a professional, you can either chant those words so often that you believe them, or you can become a true professional.

I'm not about to take some lofty stance and tell you that "professionals" are those who are paid to do the job, who have a certain amount of credibility, or who are rich enough to afford business cards that have "Professional Web Developer" written on them. In my opinion, a professional is someone who acts like a professional. You can be 13 or 33; you may have been doing your job for 15 years; you may be one of the best in your field -- and still not be a professional. Being a professional requires that you act like one.

In this article I will explain how we here at NMC Group develop Websites. This is not an end-to-end client interaction process -- it's a look at the steps that we personally take behind the scenes when we build a Website. It's fairly comprehensive and I give you full permission to steal it, discount it, or add to it as you see fit!

I refer to a number of documents in this article - you can download them all here [1].

Laying it on the Line

As far as I can tell, this could very well be the first article ever in which a company opens up about its internal processes in such a way. This may well get me ostracized, or it could get me a job for Dubya. Either way, here are the steps we move through with each project we take on:

1. Project Inception


2. Project Launch Meeting


3. Project Requirements Document


4. Discovery Documents


5. Information Availability Flowchart


6. Website Flowchart


7. Prototype


8. Prototype Approval


9. Working Production


10. Final Production


11. Testing & Final Approval

1. Project Inception

This is it, the miracle of miracles: birth. This is where your project truly begins. It's an often-unpraised but highly important step, and one that you may not have ever appreciated. More often than not, this is simply an idea or a dream. If you run a Web development company, it may not even be your dream: it may be the dream of your client. In this case, make it your dream -- feel free to imagine how great the site could be if it were created without limits.

2. Project Launch Meeting

The first official step in the development of a site is the Launch Meeting. This is a true brainstorming session. No decisions will be made, but you'll talk about things like colours, fonts, logos, hierarchy, navigation structure, and who the site will target. Essentially you want everyone in the meeting to walk away seeing the same "team vision" for the site.

3. Project Requirements Document

Here's [2] a project requirements document I put together for a client project we've just started. Essentially you want this document to summarize what the team currently thinks the project will look like when it's completed. There's no need to "get it all right", or feel tied down. At this point you are moving from brainstorming to making certain decisions, but you're also allowing yourselves a structure that can be followed in further client meetings. It'll also help out when it comes to decision making.

4. Discovery Documents

Here [3] are the discovery documents we use, and have helped develop. These are used at the point at which you start to get down to the real nitty gritty. Before, you didn't really make too many decisions, instead focusing on being open-ended and ensuring that creative discussion flowed. But with these documents, you'll get down to working out who your target audience is, what they want, the sections of the site, and what they will contain, etc. This will become the true roadmap for the project.

5. Information Availability Flowchart

This is a really great tool for a highly database-driven site that incorporates many different independent systems. It essentially outlines which types of information will be available and where. This image [4] illustrates one we set out for a shopping cart system.

6. Website Flowchart

The flowchart is one of the most useful and least-used tools I've ever come across. It sets out the information flow, how systems talk to one another, the points at which authentication occurs, and more. A well-made flowchart will not only define how the site will work, but it often allows you to write high-end code and distribute tasks in ways that would be impossible without the flowchart. Here's [5] an example flowchart for a project we've recently started. Your flowchart should illustrate not just the paths users can follow, but also the various systems and interactions they -- and the site's administrators -- would be able to access and experience.

7. Prototype

Here's where the real fun begins. By now you should have spent enough time on the project to ensure that everyone's comfortable with how it will work. The prototype will turn your documents into a reality. Your goal isn't to bicker about minor design elements such as whether you should use one- or two-pixel borders, nor is it to lay down any ASP or PHP. Now is the time to simply produce a visual that you can show the client.

8. Prototype Approval

Because most of the work we do is client-centered, we include this vital phase. If the project you're completing is for a client, this may well be the last time they'll see the site until it is ready for launch. It will give them a vision of where you're going, and provide just enough information for them to digest and be happy.

However, prototype approval is just as essential for internal projects as it is for client work, as it gives everyone a chance to see and critique where the site is at, providing both designers and developers with valuable feedback and information they'll need in order to go forward.

After this step you could easily split your team up into two groups: designers and developers. The designers have enough visuals to produce a final copy, and the developers have enough information, examples and forms to lay down some incredible code.

9. Working Production

This is where the rubber hits the road. Your designers design, your developers develop, and you come together with something that isn't necessarily perfect, but which works. The database is laid out, the ASP and PHP are done, you've written all your compiled components, the design is finished, and the navigation and headers are the best this side of the new millennium. It should look decent, work smoothly, and give everyone a chance to see where the project now stands -- and appreciate how far it has come.

10. Final Production

Yeah baby! This is the final "Look, see? It works!" You'll clean up the code from the Working Production, sharpen up design elements, turn JPEGs into GIFs and vice versa, and ensure that your final output is as standards-compliant as possible. You'll also write a list of the current weaknesses in the system which need to be addressed before you can release the system: things like removing useless code, ensuring there are no server memory leaks, etc.

11. Testing & Final Approval

The word of the day is "hammer". Get tonnes of people to use your site and make sure they enjoy it. Take their comments into consideration, but unless they are extreme, don't rush out and do a redesign -- just tweak the site where necessary. This is also the stage in which you nail down your final codebase, make the code modular so you can reuse it later, and give each other bruises from too much patting on the back.

Wrapping Up

Once again, this article was not designed to be the Perfect Guide to developing a Website. In fact, some suggestions I have to improve this would be to include steps on usability studies, focus group testing, writing documentation and doing a maintenance evaluation study. As I said, this is how we currently work jobs and I already recognize several holes in our process. In the meantime, focus on whatever will grow your business, and whatever brings you the most joy. As a wise man once said: If you wait for the perfect time to do something, you'll never get anything done.

Read on! In Part Two [6], Rachel Goldstein explains the Website development process from a freelance perspective.

[1] http://www.webmasterbase.com/examples/sbprocess/sbprocess.zip
[2] http://www.webmasterbase.com/examples/sbprocess/sbprocess.zip
[3] http://www.webmasterbase.com/examples/sbprocess/sbprocess.zip
[4] http://www.webmasterbase.com/examples/sbprocess/sbprocess.zip
[5] http://www.webmasterbase.com/examples/sbprocess/sbprocess.zip
[6] http://www.webmasterbase.com/article/677