This morning I was asked by a client to sketch out the work flow process for web development projects. Thought I’d upload it to see if anyone has any opinions on it - note this is just a sketch and not a complete philosophy or anything like that.

The workflow of building a website slightly varies depending on the type of site your building, and who the target audience is for, but the basic elements pretty much remain the same.

1. User requirements (requirement analysis/user story/etc)
This has to be done to find out what the user (customer, client etc) wants from their website, goals of it and what they want to achieve. If you don’t do this stage, then you don’t know what you’re trying to achieve.

2. Information Architecture (IA)
This is probably the most crucial part of the whole process, if this is done wrong, ignored, missed out etc then the rest of the project will be unstructured and won’t achieve the goals/requirements laid out in phase 1.

IA consists of breaking down everything to do with the site: who the target audience is, what the customer wants to say and how the site will say it. It breaks down the content into coherent and cohesive sections that will make sense to the target audience and will allow the site to meet the requirements. If this stage isn’t done then you don’t know what you want to say, how you want to say it, how this is structured, who you’re saying it to or how any of this will achieve any of the goals set.

3. Wireframes
This comes after the IA, and is the process of collating all the elements and the structure discovered in the IA and interpreting them into basic visual representations. The wireframes are all about the structure and flow of the site. As such, no design, graphics or even content (except latin) should be applied to the wireframes unless central to illustrating either the structure or the work flow - e.g. menu items, headings etc. The wireframes will help test the IA and ensure that the user paths through the website work, and meet the defined goals. If not, back to IA.

4. Technical Spec
This usually only applies to heavily dynamic sites that are bespoke built, or larger application. Once the wireframes are signed off and the functionality within them is defined, then this can be mapped out in a document used to start planning the technical aspects of the build.

5. Technical Planning
With the tech spec and wireframes as a reference, the sites functionality can be abstracted down into actual buildable chunks. Database structures planned etc. In a website this is also the place to decide how many templates or template snippets (shared bits of template across 1 or more pages) there are, and what they consist of based on the wireframes.

6 . Design.
The wireframes are interpreted into actual visual concepts, designs chosen, whittled down, blah blah etc etc. (ask Elizabeth about this!)  [Note for blog readers - can you tell I’m not a designer?!]
(can be carried out at same time as 4 & 5)

7. Templating
Once designs have been done, the templates as decided in 5 can be built

8. Build
This can be done at the same time, and in conjunction with 7 as the functionality (from 5) behind the templates can be built whilst the templates are, but the templates need to be complete so they can be integrated with this functionality.

9. Test
Make sure the thing works. Can also doe requirement testing etc

10. Deploy
Once fully tested and stable, release the product (or upload to the live site)

11. Relax and have a holiday
This is one of the most crucial stages of the entire project. Not to be skipped under any circumstance

12. Go to 1

Leave a Reply

You must be logged in to post a comment.

Posted in Development |