10 Steps Online Development Process

Plain Text Version

A pragmatic approach to develop an online product with the Modular Pattern System (MPS) as underlying method.

by Pat Bloom - Version 1.1 / 10-03-2019

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 can be done in various ways – with various tools, and as this is still a new area – feel free to set to your own hand in way that’s comfortable for you and efficient to create and re-use what’s been made.

1. UX Flow

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 .

A good practice is to number pages (e.q. 01 - “About”, and sub-page: 01A - “The Team”) so it’s clear what a particular page its parent is - this is handy for communication with the client but also for later on during the development phases. On the “pages” you can (if it’s clear) also already add the blocks (or sections) - and number them too. This gives a clear view of what needs to be created and what blocks we can re-use along the website - already during the first step!

The second “layer” we can create is the “User Flow”. This can be done in the same overview as long as you keep it clear to understand - this can be done by using e.g. colours, different stroke types or opacity. Use your creativity to make clear what you mean - for example; it’s a good practice to use short Scrum kinda stories to tell what’s happening on particular points in the map or what route personages use to navigate the website.

Goal

Get the scope of all pages (including "formular send", cooky policy and so on) - and when applicable the user journeys of the various personages.

Input

Marketing plan and analytics data

Preferred Tool(s)

Mindmap tool e.g. OmniGraffle, MS Visio

Deliverable

PDF file "UX Flow"

2. Wireframes

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.

These days there’s a lot of tools to create wireframes with e.g.: static, clickable, with commenting functionality or not - bottomline, it’s again about what needs to be created - and moreover what’s going to be in the scope. Practically it’s about the budget (how much detail can be shown) and how much the client needs “to see” to get an idea of what’s going to be developed with what functionality.

KISS (Keep it short & simple) - but complete enough to maintain a certain flexibility so a developer can interpreted it in his own way. Of course it’s important to determine what the viewport approach will be (desktop, tablet or mobile) so it’s clear what will be shown on particular screen sizes.

My preference are still a certain amount of “static” wireframes (after hand-sketched on paper) drawn in illustrating (e.g.: Affinity Designer, Adobe UX, Illustrator) software. First of all it’s fast - very fast. Especially when you create a library off re-usable symbols the process of creating wireframes it’s like “sketching” a GUI. From my experience desktop (large wireframes) are the most clear - but “mobile first projects” of course prefer to be drawn in portrait ratio.

The result can be printed, exported as PDF or presented onscreen and gives the viewer a good and realistic view of what a page is going to look like - without caring, (or being distracted) what the design is going to look like! In this phase we don’t want to think about that yet - tho the wireframes can be the grid which gonna use for our design elements.

Goal

Get a structural overview of the page pieces (desktop / mobile) and review this with the client to make sure all elements are covered.

Input

The "UX Flow" from the previous step

Preferred Tool(s)

Artboard (or page) based drawing tools e.g. Affinity Designer, Sparkle, Sketch, Adobe Illustrator, Balsamiq.

Deliverable

A multipage PDF document or interactive prototype that can be viewed on desktop / mobile devices.

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. Tho I only talk about 3 step this phase got – according to the MPS approach – 6 steps (or better say patterns) grouped in this 3 steps. Check the ‘Design Process’ for more details about this.

The 3 steps of this phase will force the designer to do proper research, dive into the brand guide and get the necessary assets from the client e.g. a vector logo and (stock) images. It’s advisable to document and covert these assets to a format which can be used later on by the developers.

3. Principles

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.

This will make designing elements easier as common and proved styling can be used within the designs.

Goal

Get and overview of the "assets palette" which will be used when creating the Pieces and Pages.

Input

Brand style guide(lines), logo, colours, fonts

Preferred Tool(s)

Graphic drawing tools e.g. Affinity Designer, Sketch, Adobe Illustrator

Deliverable

PDF document

4. Pieces

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.

As the MPS method is about efficiency and DRY (Don’t Repeat Yourself) it’s important when designing pieces to choose pieces that are (in some sort form) being used globally trough the project - or are pieces that are used once but have a certain importance e.g. the header, footer, an article (in various view modes) and so on, this mainly depends on the project.

When the previous step (defining ‘Principles’) is being done right, the designing of pieces should be a piece of cake. We can use font-sizes, colours and buttons easily and focus ourselves completely on designing the layout.

The pieces that are created can be presented just as you would present a mock-up or page design. Put them beneath each-other starting with the header(s), navigation, UPS’s and then the other pieces by importance - this will give the client a good view on how the pieces will look like (on a page).

After reviewing and modifications we can start the next step of this phase - creating Pages (better known as mock-ups).

Goal

Design certain pixel precise Pieces on proper scale (chosen from the Wireframes) which the client can review to see overall look and feel.

Input

Wireframes and Principles

Preferred Tool(s)

Artboard (or page) based drawing tools e.g. Affinity Designer, Sparkle, Sketch, Adobe Illustrator

Deliverable

A multipage PDF document or interactive prototype that can be viewed on desktop / mobile devices.

5. Pages

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!

Also we don’t need any content on this moment yet - ‘Lorem Ispum’ will do the job for this moment, and as a matter of fact - the design will be a good indicator of the text length and type of images that need to be used.

Feel free to use the tool of preference for this depending on the goals and needs to make sure the PO can see what the pages of the project is going to look like - with the "10 Steps (Web) Development Process" we’re not talking about 'pixel precise mock-ups' but about realistic designs that still can change a little bit along the way on various screens sizes and resolutions.

Goal

Design certain pixel precise Pages on proper scale (chosen from the Wireframes and Pieces) which the client can review to see how the page is going to look like.

Input

Wireframes, Principles and Pieces.

Preferred Tool(s)

Artboard (or page) based drawing tools e.g. Affinity Designer, Sparkle, Sketch, Adobe Illustrator

Deliverable

A multipage PDF document or interactive prototype that can be viewed on desktop / mobile devices.

Develop

Just as the Design phase this part also consist of 3 steps (made of 6 patterns – see “MVC Model” for details). The Develop phase includes the all facets of the actual development of the product with MVC as underlying concept.

This forces us to approach the process pragmatic – be aware of each part of the process and keep the overview, rather then ‘just installing stuff’ and start ‘building’.

6. Installing

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.

As the designs, wireframes and mockups were based on a certain framework (Bootstrap, UIkit, Foundation etc, etc.) it’s wise to also implement these in the first step. This makes the whole process a lot more efficient for all and will everybody ‘speak the same (front-end) language’.

Make sure to setup all (indirectly) related systems like a repository, the testing server (preferable on the target server), pipelines, domains and eventually IP blocks - so the focus in the next step can be completely on the development of the actual product. Communicate with the client what’s relevant to keep the process efficient - not too early - and definitely not too late, keep it clear and always be honest.

Goal

Make sure the server (and it's environments), core system (CMS), theme, front-end framework and work-flow is running.

Input

Provider, Credentials, CMS software, (GIT) Repo and Principles

Preferred Tool(s)

N.a.

Deliverable

A default install of the CMS with a default theme on the development, staging (and production) branches.

7. Development

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.

Moreover being approved by the client - all extra functionality is out of the scope and need to be documented or added to the backlog as extra tasks.

As the 10 phases is not about any particular frameworks or CMS I won’t go deeper into the technical part of developing. The only thing that need to be mentioned is to: ‘Think modular’, so try to code in reusable Partials (components) - that can be used in upcoming projects so valuable time can be used to make products better, nicer and more efficient to develop.

The DRY concept also applies to development maybe even more than in design. Creating a pattern library is proved way of working and moreover a good investment for future projects and will contribute to a team that’s on the same wave length and conduct of code.

Goal

Create a consistent, safe and modular product that can be maintained easily.

Input

UX Flow, Wireframes, Pieces and Pages.

Preferred Tool(s)

Development IDE e.g. PhpStorm, Laragon and MAMP.

Deliverable

A product on a staging environment that can be reviewed on a desktop / mobile device.

8. Deploy

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.

The deploy phase should on all moment be a sort of real ‘test run’ of the actual project to see what it will be in real live.

Goal

Let the client review the project on the staging environment with the intention to deploy to the live environment.

Input

UX Flow, Wireframes, Pieces and Pages.

Preferred Tool(s)

Cross browser test, desktop, tablet and mobile devices.

Deliverable

A full working website on the staging environment that's ready be deployed to the live environment.

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.

Get your website (SEO) checklist ready and test every single event to make sure it meets the standard that have been set. Run your ‘live check list’ (if you don’t have one – make one!) and check the SEO, IP-blocks and robots.txt to make sure search-engine spiders and Google can index the website properly.

Anyone experienced in developing online projects knows there can (will be) be issues small or big that needs to be fixed on the fly varying from front-end glitches to mayor back-end (domain or server) related issues. Key is get a complete overview of what needs to be done and spread the issues over minimal amount of people – most likely those who worked the most on the code, or those experienced enough – they know where to look

 If there are no (high prio) issues – good job. Open up them bubbles!

9. Debug

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. As you’re then also again depended on your own planning and the the client’s preview moments - and so on… When all (if there are any) open issues are fixed, test the staging again and push it to the live environment - and pop them corks and celebrate it with the team - you all deserve it!

Goal

Get all bugs and errors fixed that showed up after the final deploy and client review.

Input

The deployed live version of the project.

Preferred Tool(s)

Cross browser test, desktop, tablet and mobile devices.

Deliverable

The project on the live environment.

10. Live

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.

Part of the issues will be ‘backlog’ (talking in Scrum slang) others will need to be done ASAP and need to be planned on short term in a new development sprint.

Time for a new project, where we will adopt newly learned lessons to be even more efficient!

Goal

Enjoy and evaluate.

Input

The project on the live environment.

Preferred Tool(s)

Beer, Champagne and Wine

Deliverable

A satisfied client and a happy team!

10 Step Process Overview
Print this page
Social Share Buttons and Icons powered by Ultimatelysocial