After years of creating websites (from the ux flow till the launch) I came to the insight that - no matter what the final product was going to be - the project can mainly be divided in 4 phases namely; the "Map", "Design", "Develop" and finally the "Launch" phase. Each phase got a few steps so it's easy to refer in what stage the project is. All together the process is generally 10 steps, and sometimes I like to refer this process as the "10 Steps Online Development Process".
What makes a system like this so valuable is the fact each phase got it's "Input" (so what's needed) and it's "Deliverable" (what's the output) - which link the phases to eachother and can easily be reviewed and "accepted" (by the customer or PO). Especially when working in (agile / scrum) teams the phases can be set up as user-stories with tasks and sub-tasks - and it's clear what input a team needs before starting. This makes it way more efficient then 'just starting', as it's clear what the input should be.
(Note: This process should not be confused with some other project I'm developing, the Modular Pattern System - tho they have much in common and can be used together.)
So where to start? As I mentioned before there's 4 main phases, let's begin with the first one, the "Map" phase.
1 - Map
The first phase (after doing your research on, for example the target visitors and most popular pages) is to map the pages and create an overview of the User (Experience) Flow and after that the Wireframes should be made. This phase contains the following steps:
Creating an UX Flow (mind-map, flowchart or how you want to call it) is the one of the first things that’s wise to do - maybe even before planning the project. It gives a good overview of what needs to be made (i.o.w.; “how big is the website going to be”) and what’s in the scope. Make sure all pages including subpages (and even the “Form send” - “Thank You” pages) are included so you get good view of all the pages .
The wireframes give us a clear view what the structure of a page (and this don’t need to be all pages of the project) should look and function like.
2 - Design
The next phase of the process is designing the elements, Pieces and Pages (better known as mockups) – which needed to be shown to the client and developers what the look & feel is going to be like.
Before the designing of pieces and pages is good to think properly about the global elements that will be used in the project. These are for example; buttons, fonts (e.g.: header, paragraphs), their sizes, colours and other elements which will differ from the underlaying framework (e.g.: Bootstrap, Foundation or UIkit) - not to forget it’s a good idea in this step to already think about the framework that will be used.
The pieces are the main building blocks for the pages. Technically speaking you can refer to these as ‘sections’, combinations of global elements that form recognisable - and more likely reusable style blocks.
After designing various pieces we can easily create a much mock-ups that’s needed for the PO (product owner) and developers to get a clear view of the various pages. Usually not all pages need to be mock-upped as they can be related to (same like) templates or pieces that are already created - that’s the power of creating well thought Pieces!
3 - Develop
Just as the Design phase this part also consist of 3 steps and includes the all facets of the actual development of the product.
When installing the back-end and especially the front-end framework make sure they are in line with the needs and principles determined in the Design phase.
When everything has been installed and configured, the actual development can start! At this moment it’s wise to refer to the UX Flow, Wireframes, Pieces and Pages that were created in the Map and Design phases - that should contain all information for the developer to know what needs to be developed.
When the project is on a point the client should review what’s been made make sure everything (the client will see) will function properly - that eliminates the moment there will come a lot of (unnecessary) feedback (like ‘Yeh that still to be done’ etc. etc.) - from which no-one get’s wiser.
4 - Launch
Yeah! (make sure to have them champagne bottles ready) the project has been reviewed and is ready to be launched. (But don’t open the bottles – yet). In this stage it’s the moment to get the team together and ready on stand-by to be alert on issue that might show up when pushing the project to the live environment.
If bugs will show up make sure to check every single page (and be critical) and map all issues that are experienced - if possible prioritise the issues with ‘getting the site live’ in mind. It’s better to stay in the flow and try to get the project live with some minor issues open - then to postpone the launch to a later moment.
The site is live, the celebration is (hopefully) over - we’re back on earth - time to double check every single aspect of the website, run the persona scenarios, spider indexing and loading time of pages and again map the issues that will optimise the project in any way.
Thanks for reading!