diff --git a/README.md b/README.md
index cfa814e5..e26570e4 100755
--- a/README.md
+++ b/README.md
@@ -26,9 +26,9 @@
 
 ## 1.2. Overview
 
-Welcome to the [West Midlands Combined Authority Design System](https://wmcadigital.github.io/wmca-design-system).
+Welcome to the [West Midlands Combined Authority Design System](https://wmcads.netlify.app/).
 
-The WMCA Design System is ran at the designated url on startup (usually [http://localhost:3000](http://localhost:3000)) and is the primary means of viewing your work - it will live update as you make changes.
+The WMCA Design System is ran at the designated url on startup (usually [http://localhost:8080](http://localhost:8080)) and is the primary means of viewing your work - it will live update as you make changes.
 
 - Tailored for building West Midlands Combined Authority apps and websites: Using the WMCA Design System markup and CSS framework results in UIs that reflect the West Midlands Combined Authority look and feel.
 - Continuously updated: As long as you're using the latest version of the WMCA Design System, your pages are always up to date with West Midlands Combined Authority UI changes.
@@ -41,9 +41,9 @@ The WMCA Design System is ran at the designated url on startup (usually [http://
 You'll need [Git](https://help.github.com/articles/set-up-git/) and [Node.js](https://nodejs.org/en/) installed to get this project running.
 
 1. Clone the project with `git clone https://github.com/wmcadigital/wmca-design-system.git`
-2. Run `npm install` in the root folder.
+2. Run `npm i` in the root folder.
 3. Run `npm start` to launch the dev environment with hot reloading.
-4. Visit [http://localhost:3000](http://localhost:3000)
+4. Visit [http://localhost:8080](http://localhost:8080)
 
 Having trouble getting these steps to work on your machine? Follow the [troubleshooting guide](doc/troubleshooting.md).
 
diff --git a/doc/CODE_OF_CONDUCT.md b/doc/CODE_OF_CONDUCT.md
new file mode 100644
index 00000000..21e5ef92
--- /dev/null
+++ b/doc/CODE_OF_CONDUCT.md
@@ -0,0 +1,73 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+education, socio-economic status, nationality, personal appearance, race,
+religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at {{ email }}. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
diff --git a/doc/contributing.md b/doc/contributing.md
index 2e2700d0..651334db 100755
--- a/doc/contributing.md
+++ b/doc/contributing.md
@@ -14,7 +14,7 @@ These docs are to help you understand our contribution guidelines and standards.
   - [CSS](#css)
   - [JavaScript](#javascript)
   - [Components and Nunjucks API](#components-and-nunjucks-api)
-- [Testing and linting](#testing-and-linting)
+- [Linting](#testing-and-linting)
 - [Supported browsers](#supported-browsers)
 - [Commit hygiene](#commit-hygiene)
 - [Updating Changelog](#updating-changelog)
@@ -47,23 +47,23 @@ See [running locally](/doc/contributing/running-locally.md).
 
 ### CSS
 
-See our [coding standards for CSS](/doc/contributing/coding-standards/css.md) and [testing and linting](/doc/contributing/testing-and-linting.md).
+See our [coding standards for CSS](/doc/contributing/css.md) and [Linting](/doc/contributing/testing-and-linting.md).
 
 ### JavaScript
 
-See our [coding standards for JavaScript](/doc/contributing/coding-standards/js.md) and [testing and linting](/doc/contributing/testing-and-linting.md).
+See our [coding standards for JavaScript](/doc/contributing/js.md) and [Linting](/doc/contributing/testing-and-linting.md).
 
 ### Components and Nunjucks API
 
-See our [coding standards for components](/doc/contributing/coding-standards/components.md), [coding standards for Nunjucks macros](/doc/contributing/coding-standards/nunjucks-api.md) and [testing and linting](/doc/contributing/testing-and-linting.md).
+See our [coding standards for components](/doc/contributing/coding-standards.md), [coding standards for Nunjucks macros](/doc/contributing/coding-standards.md) and [Linting](/doc/contributing/testing-and-linting.md).
 
-## Testing and linting
+## linting
 
-See [testing and linting](/doc/contributing/testing-and-linting.md).
+See [Linting](/doc/contributing/testing-and-linting.md).
 
 ## Supported browsers
 
-Your contribution needs to work with certain browsers as set out in [README](README.md#browser-support). See also [supporting Internet Explorer 8](/doc/installation/supporting-internet-explorer-8.md).
+Your contribution needs to work with certain browsers as set out in [README](README.md#browser-support).
 
 ## Supported assistive technology
 
@@ -92,4 +92,4 @@ See [deploying](/doc/contributing/deploying.md).
 
 ## Releasing a new version
 
-See [publishing](/doc/contributing/publishing.md).
+See [versioning](/doc/contributing/versioning.md).
diff --git a/doc/contributing/application-architecture.md b/doc/contributing/application-architecture.md
index 2cc8f5d5..8d954a70 100755
--- a/doc/contributing/application-architecture.md
+++ b/doc/contributing/application-architecture.md
@@ -4,7 +4,7 @@
 
   Source files. See [README.md](../../src/README.md) in the src directory for details.
 
-  - `wmre/`
+  - `wmcads/`
 
     This is where the core library of all components/patterns are built using nunjucks for the WMCA Design System. These are then referenced by the Design System Website to show examples to other collaborators.
 
@@ -18,19 +18,19 @@
 
       - `sass/`
 
-        Any core SASS/SCSS that is used for styling components/patterns etc. should be placed in here and then referenced in `src/wmre/assets/sass/wmre.scss`. Note: Anything referenced will appear in the live build.
+        Any core SASS/SCSS that is used for styling components/patterns etc. should be placed in here and then referenced in `src/wmre/assets/sass/wmcads.scss`. Note: Anything referenced will appear in the live build.
 
         - `components/`
 
-          Examples of components usage in various contexts. See [README.md](../../src/components/README.md) in the components directory for more details. You can access these examples from [WMCA Design System components](http://localhost:3000/components/).
+          Examples of components usage in various contexts. See [README.md](../../src/wmcads/components/README.md) in the components directory for more details. You can access these examples from [WMCA Design System components](https://wmcads.netlify.app/components/).
 
         - `patterns/`
 
-          Examples of pattern usage in various contexts. See [README.md](../../src/components/README.md) in the components directory for more details. You can access these examples from [WMCA Design System patterns](http://localhost:3000/patterns/).
+          Examples of pattern usage in various contexts. See [README.md](../../src/wmcads/patterns/README.md) in the components directory for more details. You can access these examples from [WMCA Design System patterns](https://wmcads.netlify.app/patterns/).
 
     - `www/`
 
-      Anything that is specific for the [WMCA Design System website](http://localhost:3000) goes in this folder. It also contains generic layout templates used to render preview and content pages.
+      Anything that is specific for the [WMCA Design System website](https://wmcads.netlify.app) goes in this folder. It also contains generic layout templates used to render preview, content pages and template mockups.
 
       - `assets/`
 
@@ -44,7 +44,7 @@
 
           Any javascript files located in here will be concatenated and compiled into `docs/js/wmcads-vendor.min.js` via the [javascript build task](tasks.md#markdown-header-141-scripts-javascript).
 
-- `docs/` **contains auto-generated files**
+- `build/` **contains auto-generated files**
 
   Standalone builds of WMCA Design System. Provides a way to consume WMCA Design System without using npm.
 
diff --git a/doc/contributing/cms/cms-integration.md b/doc/contributing/cms/cms-integration.md
new file mode 100644
index 00000000..71a5f70c
--- /dev/null
+++ b/doc/contributing/cms/cms-integration.md
@@ -0,0 +1,5 @@
+# CMS Integration
+
+Every new template should be created on a new branch based on `release` following the guidelines in [Versioning](../versioning.md#123-new-branches).
+
+Where feasible any new components should be added as a partial view and imported into the template.
diff --git a/doc/contributing/coding-standards.md b/doc/contributing/coding-standards.md
index a3d48203..1804cc0d 100755
--- a/doc/contributing/coding-standards.md
+++ b/doc/contributing/coding-standards.md
@@ -1,6 +1,6 @@
 # Components
 
-Find components in `src/wmre/components`.
+Find components in `src/wmcads/components`.
 
 Components must use the `.wmcads-` namespace.
 
@@ -24,10 +24,9 @@ Component folder and files should be singular, except in cases where they are mo
 The folder structure should be:
 
     component-name
+      - `component-name.njk`
       - `_component-name.scss`
-      - `component-name.html`
-      - `component-name.js`
-      - `README.md`
+      - `component-name.js` (optional)
 
 ## Nunjucks template API
 
diff --git a/doc/contributing/css.md b/doc/contributing/css.md
index 0258c9ca..b2e0dd82 100755
--- a/doc/contributing/css.md
+++ b/doc/contributing/css.md
@@ -2,7 +2,7 @@
 
 ## Class naming convention
 
-## `wmre` namespacing
+## `wmca` namespacing
 
 All class names start with a `.wmcads-` namespace to reduce the likelihood of
 conflicting with existing classes in your application. It also helps to identify
@@ -112,12 +112,12 @@ This makes it easier to keep track of different contexts.
 # Linting
 
 To ensure code quality and consistency in our Sass files we check that certain
-style rules are followed using a project [YAML file](../../../config/.sass-lint.yml)
+style rules are followed using a project [YAML file](../../../master/.sass-lint.yml)
 
 As we're using node-sass parser to parse our scss files, the package of choice
 is [sass-lint](https://github.com/sasstools/sass-lint).
 
-See [testing and linting](../testing-and-linting.md) for more information.
+See [linting](../contributing/testing-and-linting.md) for more information.
 
 ## Running the lint task
 
@@ -126,7 +126,7 @@ or check linting directly in [Sublime Text](https://github.com/skovhus/SublimeLi
 [Atom](https://atom.io/packages/linter-sass-lint)
 or other [IDE's](https://github.com/sasstools/sass-lint#ide-integration)
 
-See also [testing and linting](../testing-and-linting.md).
+See also [Linting](../testing-and-linting.md).
 
 ## Linting rules
 
@@ -492,12 +492,4 @@ Good:
 
 ### Remove trailing whitespace
 
-More write up on [supported rules](https://github.com/sasstools/sass-lint/tree/master/doc/rules).
-
-## SassDoC
-
-We document SCSS using [SassDoc](http://sassdoc.com/file-level-annotations/). This includes most of the settings, helpers and tools layers, with variables, functions and mixins being marked as private or public.
-
-The syntax is used to generate a [SassDoc application](http://wmcads-frontend-review.herokuapp.com/doc/) that documents SCSS in a readable format.
-
-See [colour.scss](../../../src/wmre/helpers/_colour.scss) for an example of SassDoc syntax.
+More write up on [supported rules](https://github.com/sasstools/sass-lint/tree/master/docs/rules).
diff --git a/doc/contributing/ds/creating-pages.md b/doc/contributing/ds/creating-pages.md
new file mode 100644
index 00000000..378c297d
--- /dev/null
+++ b/doc/contributing/ds/creating-pages.md
@@ -0,0 +1,5 @@
+# Creating pages
+
+When the Design System is built it automatically generates files from `src/www` to the `build` folder. These are the files used to generate the [Design System front-end](https://wmcads.netlify.app/).
+
+These pages are created from the files within `src/www/pages`. This is where you can import [components](../../../src/wmcads/components/README.md) or [patterns](../../../src/wmcads/patterns/README.md) found in `src/wmcads`.
\ No newline at end of file
diff --git a/doc/contributing/ds/nunjucks-params.md b/doc/contributing/ds/nunjucks-params.md
new file mode 100644
index 00000000..5faaa03f
--- /dev/null
+++ b/doc/contributing/ds/nunjucks-params.md
@@ -0,0 +1,29 @@
+# Nunjucks parameters
+
+Change the behavior of components by sending custom parameters.
+
+This enables us to re-use components without having to duplicate them just to change copy or UI features.
+
+## Change copy
+
+As an example lets change the title of a component:
+
+1 - In the compoent `.njk` file add a custom parameter like this:
+
+    {% set title = params.title or 'Default Title' %}
+
+This is looking for a parameter called `title`, if the parameter is not found the default value is used after `or`.
+
+2 - Display the value in the front end.
+
+Add the parameter name within `{{  }}` where you want the value to appear:
+
+    <h1>{{title}}</h1>
+
+3 - Send the title value to the component
+
+    {{
+        wmcadsComponentName({
+            title: "New title"
+        })
+    }}
diff --git a/doc/contributing/git.md b/doc/contributing/git.md
index bb7546e7..e81dfb15 100755
--- a/doc/contributing/git.md
+++ b/doc/contributing/git.md
@@ -103,11 +103,11 @@ will make sense to your fellow developers. In particular, you may find
 commits and use git rebase master instead. However, you should not rewrite commits
 that have been pushed unless you:
 
--   are **very sure** that no-one else will be affected by you rewriting the
-    branch history
--   have an Extremely Good Reason. For example: someone has committed
-    sensitive information (personally identifiable data, passwords and suchlike)
-    and it needs purging from history
+- are **very sure** that no-one else will be affected by you rewriting the
+  branch history
+- have an Extremely Good Reason. For example: someone has committed
+  sensitive information (personally identifiable data, passwords and suchlike)
+  and it needs purging from history
 
 When in doubt you should err towards smaller commits, which can be rebased
 together later. It's harder to break large commits out into smaller chunks.
diff --git a/doc/contributing/internal-process.md b/doc/contributing/internal-process.md
new file mode 100644
index 00000000..ac65b985
--- /dev/null
+++ b/doc/contributing/internal-process.md
@@ -0,0 +1,55 @@
+# Internal process for developing the new WMCA website
+
+These docs outline the process all designers and developers should be following when updating the WMCA Design System and for testing templates for the new WMCA website.
+
+## Development
+
+Make sure you are familiar with how the design system is setup and how to contribute to it by reviewing the [Contributing guide](../contributing.md).
+
+Main points to follow:
+
+- Each new feature or bugfix should be created on a new branch based on `release` following the guidelines in [Versioning](versioning.md#123-new-branches).
+  - This makes it easier for multiple developers to work on the same feature or bugfix without disturbing the main codebase.
+  - This also makes it easier to carry out staggered releases to the main codebase.
+- All new components or patterns need to follow the [Coding standards](coding-standards.md).
+- Any new CMS templates should be added to the design system to ensure:
+    - That the latest components and patterns are in use
+    - To show the template to designers for sign off
+    - Any custom styles and javascript are checked and generated in the build process
+- Once you are ready to propose new changes, you must **open a pull request to the** `release` **branch**.
+  - This will trigger the Github actions which will:
+    - Check the pull request title to ensure the semantic-release works correctly
+    - Checks the codebase for any linting or accessibility issues
+    - A preview will be created in Netlify
+    - The pull request will then be reviewed by the head developer and any issues identified.
+    - Once the lead developer is happy with the pull request an ICT change request will be created and merged into the `master` branch.
+
+### Points for template creation
+
+- All templates should be added into `src/www/pages/templates`. These will appear on the main Design System site [here](https://wmcads.netlify.app/templates/).
+- Ensure you use the appropriate style [utilities classes](https://wmcads.netlify.app/styles/utility-classes/) for the template layout.
+- Check that the page passes accessibility checks using automated tools such as [AXE](https://www.deque.com/axe/), [Wave](https://wave.webaim.org/) or [Lighthouse](https://developers.google.com/web/tools/lighthouse) (or a combination of the tools).
+- Once the pull request passes all checks and the lead developer confirms it's ok the template preview will be sent to the designers for final sign off.
+
+## Design / UX / UI
+
+- When a template has been signed off by the lead developer a Netlify preview link will be sent to the designers
+- Designers should review the template on desktop, tablet and mobile to ensure the design works as expected.
+- Any issues to be added to the GitHub repository [issues](https://github.com/wmcadigital/wmca-design-system/issues) page. Where possible add the sprint card reference found in the [West Midlands Combined Authority - Backlog](https://github.com/orgs/wmcadigital/projects/18). E.g. `DS2.1 - Font issue with body copy`.
+
+### Template Sign Off
+
+Only when the template has been signed off by the lead developer and design can it be integrated into the Content Management System.
+
+#### Sign off checklist
+
+- Templates use the design System utility classes, components & patterns
+  - If the template requires extra styles or scripts these should be added into the `src/www/pages/templates/template-name` folder so they can go through [Linting](../contributing/testing-and-linting.md) and the build process.
+    - If the code is concidered useful for other pages it should be added to the base Design System.
+- Templates pass accessibility checks
+- Approved by lead developer
+- Approved by Design
+
+## CMS Integration
+
+When the template has been signed off it can be integrated into our [CMS](../contributing/cms/cms-integration.md).
diff --git a/doc/contributing/js.md b/doc/contributing/js.md
index bd2407e5..1527b11e 100755
--- a/doc/contributing/js.md
+++ b/doc/contributing/js.md
@@ -122,4 +122,4 @@ The standard docs have a [complete list of rules and some reasoning behind them]
 
 Read more about [running standard manually or in your editor](https://github.com/alphagov/styleguides/blob/master/js.md#linting).
 
-See also [testing and linting](../testing-and-linting.md).
+See also [Linting](../testing-and-linting.md).
diff --git a/doc/contributing/misc.md b/doc/contributing/misc.md
deleted file mode 100755
index 73a1a1d1..00000000
--- a/doc/contributing/misc.md
+++ /dev/null
@@ -1,170 +0,0 @@
-[HTML5 Boilerplate homepage](https://html5boilerplate.com/) | [Documentation
-table of contents](TOC.md)
-
-# Miscellaneous
-
-* [.gitignore](#gitignore)
-* [.editorconfig](#editorconfig)
-* [Server Configuration](#server-configuration)
-* [robots.txt](#robotstxt)
-* [humans.txt](#humanstxt)
-* [browserconfig.xml](#browserconfigxml)
-
---
-
-## .gitignore
-
-HTML5 Boilerplate includes a basic project-level `.gitignore`. This should
-primarily be used to avoid certain project-level files and directories from
-being kept under source control. Different development-environments will
-benefit from different collections of ignores.
-
-OS-specific and editor-specific files should be ignored using a "global
-ignore" that applies to all repositories on your system.
-
-For example, add the following to your `~/.gitconfig`, where the `.gitignore`
-in your HOME directory contains the files and directories you'd like to
-globally ignore:
-
-```gitignore
-[core]
-    excludesfile = ~/.gitignore
-```
-
-* More on global ignores: https://help.github.com/articles/ignoring-files/
-* Comprehensive set of ignores on GitHub: https://github.com/github/gitignore
-
-
-## .editorconfig
-
-The `.editorconfig` file is provided in order to encourage and help you and
-your team define and maintain consistent coding styles between different
-editors and IDEs.
-
-By default, `.editorconfig` includes some basic
-[properties](https://editorconfig.org/#supported-properties) that reflect the
-coding styles from the files provided by default, but you can easily change
-them to better suit your needs.
-
-In order for your editor/IDE to apply the
-[properties](https://editorconfig.org/#supported-properties) from the
-`.editorconfig` file, you may need to [install a
-plugin]( https://editorconfig.org/#download).
-
-__N.B.__ If you aren't using the server configurations provided by HTML5
-Boilerplate, we highly encourage you to configure your server to block
-access to `.editorconfig` files, as they can disclose sensitive information!
-
-For more details, please refer to the [EditorConfig
-project](https://editorconfig.org/).
-
-## Server Configuration
-
-H5BP includes a [`.htaccess`](#htaccess) file for the [Apache HTTP
-server](https://httpd.apache.org/doc/). If you are not using Apache
-as your web server, then you are encouraged to download a
-[server configuration](https://github.com/h5bp/server-configs) that
-corresponds to your web server and environment.
-
-A `.htaccess` (hypertext access) file is an [Apache HTTP server
-configuration file](https://github.com/h5bp/server-configs-apache).
-The `.htaccess` file is mostly used for:
-
-* Rewriting URLs
-* Controlling cache
-* Authentication
-* Server-side includes
-* Redirects
-* Gzipping
-
-If you have access to the main server configuration file (usually called
-`httpd.conf`), you should add the logic from the `.htaccess` file in, for
-example, a <Directory> section in the main configuration file. This is usually
-the recommended way, as using .htaccess files slows down Apache!
-
-To enable Apache modules locally, please see:
-https://github.com/h5bp/server-configs-apache/wiki/How-to-enable-Apache-modules.
-
-In the repo the `.htaccess` is used for:
-
-* Allowing cross-origin access to web fonts
-* CORS header for images when browsers request it
-* Enable `404.html` as 404 error document
-* Making the website experience better for IE users better
-* Media UTF-8 as character encoding for `text/html` and `text/plain`
-* Enabling the rewrite URLs engine
-* Forcing or removing the `www.` at the begin of a URL
-* It blocks access to directories without a default document
-* It blocks access to files that can expose sensitive information.
-* It reduces MIME type security risks
-* It forces compressing (gzipping)
-* It tells the browser whether they should request a specific file from the
-  server or whether they should grab it from the browser's cache
-
-When using `.htaccess` we recommend reading all inline comments (the rules after
-a `#`) in the file once. There is a bunch of optional stuff in it.
-
-If you want to know more about the `.htaccess` file check out the
-[Apache HTTP server docs](https://httpd.apache.org/doc/) or more
-specifically the [htaccess
-section](https://httpd.apache.org/doc/current/howto/htaccess.html).
-
-Notice that the original repo for the `.htaccess` file is [this
-one](https://github.com/h5bp/server-configs-apache).
-
-## robots.txt
-
-The `robots.txt` file is used to give instructions to web robots on what can
-be crawled from the website.
-
-By default, the file provided by this project includes the next two lines:
-
-* `User-agent: *` -  the following rules apply to all web robots
-* `Disallow:` - everything on the website is allowed to be crawled
-
-If you want to disallow certain pages you will need to specify the path in a
-`Disallow` directive (e.g.: `Disallow: /path`) or, if you want to disallow
-crawling of all content, use `Disallow: /`.
-
-The `/robots.txt` file is not intended for access control, so don't try to
-use it as such. Think of it as a "No Entry" sign, rather than a locked door.
-URLs disallowed by the `robots.txt` file might still be indexed without being
-crawled, and the content from within the `robots.txt` file can be viewed by
-anyone, potentially disclosing the location of your private content! So, if
-you want to block access to private content, use proper authentication instead.
-
-For more information about `robots.txt`, please see:
-
-* [robotstxt.org](http://www.robotstxt.org/)
-* [How Google handles the `robots.txt` file](https://developers.google.com/webmasters/control-crawl-index/doc/robots_txt)
-
-## humans.txt
-
-The `humans.txt` file is used to provide information about people involved with
-the website.
-
-The provided file contains three sections:
-
-* `TEAM` - this is intended to list the group of people responsible for the website
-* `THANKS` - this is intended to list the group of people that have contributed
-  to the website
-* `TECHNOLOGY COLOPHON` - the section lists technologies used to make the website
-  
-For more information about `humans.txt`, please see: http://humanstxt.org/
-
-## browserconfig.xml
-
-The `browserconfig.xml` file is used to customize the tile displayed when users
-pin your site to the Windows 8.1 start screen. In there you can define custom
-tile colors, custom images or even [live tiles](https://msdn.microsoft.com/library/dn455106.aspx#CreatingLiveTiles).
-
-By default, the file points to 2 placeholder tile images:
-
-* `tile.png` (558x558px): used for `Small`, `Medium` and `Large` tiles.
-  This image resizes automatically when necessary.
-* `tile-wide.png` (558x270px): user for `Wide` tiles.
-
-Notice that IE11 uses the same images when adding a site to the `favorites`.
-
-For more in-depth information about the `browserconfig.xml` file, please
-see [MSDN](https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/dn320426(v=vs.85)).
diff --git a/doc/contributing/nunjucks-api.md b/doc/contributing/nunjucks-api.md
new file mode 100644
index 00000000..5b5a78c4
--- /dev/null
+++ b/doc/contributing/nunjucks-api.md
@@ -0,0 +1,63 @@
+# Component templates
+
+The WMCA Design System is built using the [Nunjucks](https://mozilla.github.io/nunjucks/) templating engine.
+
+Each Design System component and pattern is built using a Nunjucks Macro. Macros are then imported on a page ready to be exported as content pages in the build process.
+
+## Nunjucks templating
+
+Find out more about the [Nunjucks templating language](https://github.com/mozilla/nunjucks/blob/master/docs/templating.md).
+
+
+## Creating new components
+
+1 - The first step is to create the component files following the [component guidelines](coding-standards.md#component-folder-structure-and-naming).
+
+2 - Next add the following to the .njk file to create a new Macro.
+
+    {% macro wmcadsComponentName(params) %}
+
+    {% endmacro %}
+
+3 - If you think the component would benefit a description or comments in order help other developers you can add it like this: 
+
+    {% macro wmcadsComponentName(params) %}
+    {# Component description/ comments here #}
+    {% endmacro %}
+
+4 - You can now start adding the component html: 
+
+    {% macro wmcadsComponentName(params) %}
+    {# Component description/ comments here #}
+
+    <div class="wmcads-componentName">
+
+    </div>
+
+    {% endmacro %}
+
+## Importing components
+
+Each component or pattern should have a corresponding [page](../contributing/ds/creating-pages.md) in order to demonstrate how and when to use it.
+
+1 - Import a component using the following:
+
+    {% from "wmcads/component/component-name/component-name.njk" import macroName %}
+
+Most of the time any imports are added to the top of the document but they can be added anywhere within the block.
+
+2 - Rendering the component
+
+Render the component in the page by adding the following where you want the component to display.
+
+    {{
+        wmcadsComponentName()
+    }}
+
+## Nunjucks parameters
+
+In order to reuse components and patterns we can send parameters to the Nunjucks file in order to change what is displayed in the front-end.
+
+E.g. Change a heading title, image or link.
+
+[Read more on Nunjucks parameters](../contributing/ds/nunjucks-params.md).
diff --git a/doc/contributing/publishing-a-pre-release.md b/doc/contributing/publishing-a-pre-release.md
new file mode 100644
index 00000000..04749e51
--- /dev/null
+++ b/doc/contributing/publishing-a-pre-release.md
@@ -0,0 +1 @@
+# Publishing pre-release of WMCA Design System Frontend
\ No newline at end of file
diff --git a/doc/contributing/running-locally.md b/doc/contributing/running-locally.md
new file mode 100644
index 00000000..7c9bd5dd
--- /dev/null
+++ b/doc/contributing/running-locally.md
@@ -0,0 +1,12 @@
+# Running locally
+
+## Quick start
+
+You'll need [Git](https://help.github.com/articles/set-up-git/) and [Node.js](https://nodejs.org/en/) installed to get this project running.
+
+1. Clone the project with `git clone https://github.com/wmcadigital/wmca-design-system.git`
+2. Run `npm i` in the root folder.
+3. Run `npm start` to launch the dev environment with hot reloading.
+4. Visit [http://localhost:8080](http://localhost:8080)
+
+Having trouble getting these steps to work on your machine? Follow the [troubleshooting guide](doc/troubleshooting.md).
\ No newline at end of file
diff --git a/doc/contributing/testing-and-linting.md b/doc/contributing/testing-and-linting.md
index 0e31519d..01fd3e56 100755
--- a/doc/contributing/testing-and-linting.md
+++ b/doc/contributing/testing-and-linting.md
@@ -1,51 +1,11 @@
-# Testing and linting
+# Linting
 
-The CI lints SASS and JavaScript, and runs unit and functional tests with Node.
-
-## Running all tests locally
-
-To check the whole codebase, run:
-
-```
-npm test
-```
-
-This will trigger [standard](https://github.com/standard/standard) and [sass-lint](https://github.com/sasstools/sass-lint) for linting, and [Jest](https://github.com/facebook/jest) for unit and functional tests.
-
-See [Tasks](tasks.md) for details of what `npm test` does.
+The CI lints SASS and JavaScript.
 
 ## SASS linting
 
-See [CSS Coding Standards](coding-standards/css.md#linting) for details.
+See [CSS Coding Standards](css.md#linting) for details.
 
 ## Javascript linting
 
-See [JavaScript Coding Standards](coding-standards/js.md#formatting-and-linting) for details.
-
-## Unit and functional tests with Node.js
-
-We use [Jest](https://jestjs.io/), an automated testing platform with an assertion library, and [Puppeteer](https://pptr.dev/) that is used to control [headless Chrome](https://developers.google.com/web/updates/2017/04/headless-chrome).
-
-We test individual components and for instance global Sass files. See [all.test.js](../../src/wmre/all.test.js). for examples of global tests we run, and [checkboxes.test.js](../../src/wmre/components/checkboxes/checkboxes.test.js) for an example of component tests.
-
-We aim to write the description of our tests in as "natural language" as possible, for instance "back-link component fails to render if the required fields are not included".
-
-### Running individual tests
-
-You can run a subset of the test suite that only tests components by running:
-
-`npm test -- src/wmre/components/button`
-
-Note: There's a watch mode that keeps a testing session open waiting for changes that can be used with:
-
-`npm test -- --watch src/wmre/components/button`
-
-### Updating component snapshots
-
-[Snapshot tests](https://facebook.github.io/jest/doc/en/snapshot-testing.html) are used for preventing unintended changes - when the snapshot test runs, it compares the previously captured snapshot to the current markup. For components, the snapshots are stored in `[component-name directory]/_snapshots_`.
-
-If a snapshot test fails, review the difference in the console. If the change is the correct change to make, run:
-
-`npm test -- -u src/wmre/components/button`
-
-This will update the snapshot file. Commit this file separately with a commit message that explains you're updating the snapshot file and an explanation of what caused the change.
+See [JavaScript Coding Standards](js.md#formatting-and-linting) for details.
diff --git a/doc/contributing/versioning.md b/doc/contributing/versioning.md
index 44d0d552..02e7ec0f 100755
--- a/doc/contributing/versioning.md
+++ b/doc/contributing/versioning.md
@@ -1,131 +1,212 @@
-# Versioning
+# 1. Versioning
 
-With our user interface (UI) library, users [can consume our code in different ways](#public-api).
+The process of versioning The West Midlands Combined Authority Design System is automated via GitHub Actions, mainly through the use of [semantic-release](https://github.com/semantic-release/semantic-release).
 
-We follow [Semantic Versioning](https://semver.org/) but a UI library often has subjective changes such as visual spacing changes.
+## 1.1 Table of contents
 
-This document aims to outline the processes we follow when we version our releases.
+- [1. Versioning](#1-versioning)
+  - [1.1 Table of contents](#11-table-of-contents)
+  - [1.2 Branches](#12-branches)
+    - [1.2.1 Master](#121-master)
+    - [1.2.2 Release](#122-release)
+    - [1.2.3 New branches](#123-new-branches)
+  - [1.3 Adding to the next release](#13-adding-to-the-next-release)
+    - [1.3.1 Pull request title](#131-pull-request-title)
+    - [1.3.2 Merging into release](#132-merging-into-release)
+  - [1.4 New release](#14-new-release)
+    - [1.4.1 Merging into master](#141-merging-into-master)
+    - [1.4.2 The release workflow](#142-the-release-workflow)
+      - [1.4.2.1 Requirements](#1421-requirements)
+      - [1.4.2.2 Steps](#1422-steps)
+        - [1.4.2.2.1 semantic-release dry run](#14221-semantic-release-dry-run)
+        - [1.4.2.2.2 Site build](#14222-site-build)
+        - [1.4.2.2.3 semantic-release proper run](#14223-semantic-release-proper-run)
+        - [1.4.2.2.4 Netlify deploy](#14224-netlify-deploy)
+  - [1.5 Extra information](#15-extra-information)
+    - [1.5.1 Bumping the version number](#151-bumping-the-version-number)
+    - [1.5.2 Updating the changelog](#152-updating-the-changelog)
+    - [1.5.3 Add to CDN](#153-npm-package)
 
-## Stability
+## 1.2 Branches
 
-A stable library prioritises the users and ecosystem that it supports.
+The repository is set up with two main branches: `master` and `release`.
 
-We often release new components and features which will encourage people to update.
+### 1.2.1 Master
 
-But we should make sure that we only make breaking changes when we have a good reason, and have decided that it is absolutely necessary.
+The `master` branch holds all the commit history of changes to the Design System, with each commit being a change that has been added by one of the two methods below.
 
-Good examples of such situations would be:
+The `master` branch is only updated by:
 
-- issues that are barriers for end-users (users of services) based on evidence (for example user research)
-- issues that are barriers for users (users of WMCA Design System Frontend) based on evidence
-- accessibility issues
-- security issues
-- performance issues
+- Pull requests from the `release` branch, merged via the merge commit strategy
+- Urgent pull requests from a hotfix branch, merged via the squash and merge strategy
 
-We would not make breaking changes for:
+After any push to the `master` branch, the release workflow is triggered.
 
-- thinking you can sneak a change in with other breaking changes
-- changing the name of an API, based on a hunch
-- adopting a technology based on popularity and not because of the problems they solve
-- changing a component's interface without a good reason to do so
+### 1.2.2 Release
 
-This is similar to how we try to tackle most problems, by focusing on user needs first.
+The `release` branch holds all the changes that will be automatically released when the branch is merged into the `master` branch.
 
-Whenever we decide to make a breaking change we must ensure we do our best to try to first [deprecate the feature](#deprecation) and allow a [migration path](#migration).
+The `release` branch is only updated by:
 
-## Proposal
+- Pull requests from other branches, merged via the **squash and merge** strategy
 
-Some breaking changes that need discussion may first be proposed in the [WMCA Design System Design System architecture repository](https://github.com/alphagov/wmcads-design-system-architecture/blob/master/proposals/README.md).
+### 1.2.3 New branches
 
-This is to ensure the community can get involved with the decision.
+In order to add to the Design System, you must first create a new branch with the following format `xx/type/short-description`.
 
-Make an active effort to involve the community, this might be in the form of presentations or meetings.
+Where:
 
-## Deprecation
+- `xx` is your first and last initials, e.g. `jd` for John Doe
+- `type` is the type of change the branch is working on, e.g. `bugfix`, `feature`
+- `short-description` is a short hyphenated description of the branch, e.g. `red-button-variant`
 
-Deprecation is the practice of communicating features in the library that should no longer be used and requires a user change behaviour in their application.
+With the full example being: `jd/feature/red-button-variant`.
 
-Deprecating features in the library helps users migrate to the new code while still being able to run the older code.
+**This branch must branch from the `release` branch.**
 
-Note: Our users may not know what 'deprecation' means, so it's important to also clarify that we are no longer recommending the use of a feature.
+## 1.3 Adding to the next release
 
-Example 1: Fixing a typo in a CSS class name.
+Once you are ready to propose new changes, you must **open a pull request to the** `release` **branch**.
 
-1. We discover the class name `.wmcads-visually-hidden-focussable` includes the typo 'focussable'
-2. We raise a pull request that renames the class to `.wmcads-visually-hidden-focusable` while keeping
-   the previous class available.
-3. We add a comment to the source code that indicates this is deprecated, and raise an issue to remove it in a future breaking release.
-4. When releasing the change we include a clear summary that indicates what was the problem, what we've changed and how a user can migrate before the future breaking release.
+### 1.3.1 Pull request title
 
-Sometimes it is not possible to deprecate code, this is OK but try to make this a last resort.
+Opening a pull request to the `release` branch triggers a workflow to lint the pull request title, as well as other workflows that lint the code itself.
 
-### Sass doc deprecation annotations
+Pull requests to the `release` branch are to be merged via the **squash and merge** strategy so that each pull request appears as a single commit on the release branch.
 
-When deprecating Sass, you can use the [deprecated annotation](http://sassdoc.com/annotations/#deprecated).
+As a result, pull request titles **must** follow the [Conventional Commit Specification](https://www.conventionalcommits.org/en/v1.0.0/), so that semantic-release can correctly bump the version and update the changelog.
 
-If there is an alias, for example if you are renaming something, you can use the [alias annotation](http://sassdoc.com/annotations/#alias).
+See the [bumping the version](#151-bumping-the-version-number) and [updating the changelog](#152-updating-the-changelog) sections for more details.
 
-See [an example of deprecating a Sass mixin on GitHub](https://github.com/alphagov/wmcads-frontend/blob/9424d87ed54764d2d8afe35d6e0077ee43d231e1/src/helpers/_grid.scss#L20-L26).
+### 1.3.2 Merging into release
 
-## Migration
+When the pull request has passed all the necessary checks and reviews, it must then be merged into the `release` branch via the **squash and merge** strategy.
 
-Migration is the practice of a user moving from one approach to an equivalent approach.
+This reduces all changes on the branch into one commit with the title of the pull request appearing as the commit message.
 
-It is very important that we make it easy to migrate when we make deprecations.
+When the `release` branch is merged into the `master` branch, [semantic-release will use these commit messages to determine the type of changes in the new release](https://github.com/semantic-release/semantic-release#commit-message-format).
 
-If possible include clear steps for users should update their code directly in the CHANGELOG entry that introduces the deprecation.
+## 1.4 New release
 
-## Public API
+Once the `release` branch has changes that are ready to go live, a pull request must be opened to the `master` branch.
 
-The [Semantic Versioning specification](https://semver.org/) requires a public API.
+### 1.4.1 Merging into master
 
-> For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself.
+Once the pull request has passed all necessary checks and reviews, it must then be merged into the `master` branch via the **merge commit** strategy.
 
-### Design System Website
+This is so that all the commits on the `release` branch are added to the `master` branch.
 
-One of ways users interact with WMCA Design System Frontend is through the [WMCA Design System Design System website](https://design-system.service.WMCA Design System/).
+_The title of the pull request or merge commit do not have to be in any specific format._
 
-This includes:
+### 1.4.2 The release workflow
 
-- HTML - Documented in examples (for example, the [buttons code example](https://design-system.service.WMCA Design System/components/button/))
-- Nunjucks - Documented in examples (for example, the buttons code example)
-- SCSS - for example [colours variables](https://design-system.service.WMCA Design System/styles/colour/)
+As mentioned before, the Design System uses [semantic-release](https://github.com/semantic-release/semantic-release) to automate our release workflow.
 
-### npm package
+#### 1.4.2.1 Requirements
 
-The other primary way is through what is [published to npm](https://github.com/alphagov/wmcads-frontend/tree/master/package).
+The workflow requires the following tokens:
 
-This includes:
+- `SEMVER_GITHUB_TOKEN` - a personal access token with repo permissions. See the [semantic-release configuration](https://github.com/semantic-release/github#configuration) for details.
+- `NETLIFY_AUTH_TOKEN` - Netlify personal access token. See [actions-netlify](https://github.com/nwtgck/actions-netlify#required-inputs-and-env) for details.
+- `NETLIFY_SITE_ID` - Netlify API ID. See [actions-netlify](https://github.com/nwtgck/actions-netlify#required-inputs-and-env) for details.
+- `NPM_TOKEN` - npm access token with publish permissions. See the [semantic-release configuration](https://github.com/semantic-release/github#configuration) for details.
 
-- [JavaScript](https://github.com/alphagov/wmcads-frontend/blob/master/doc/installation/installing-with-npm.md#using-javascript)
-- SCSS - https://wmcads-frontend-review.herokuapp.com/doc/
-- Nunjucks Macros (Templates)
+The workflow also requires a `GITHUB_TOKEN` but that is made available automatically during any workflow run.
 
-## Updating Changelog
+#### 1.4.2.2 Steps
 
-If you open a GitHub pull request on this repo, please update `CHANGELOG` to reflect your contribution.
+The workflow works in the following way:
 
-Add your entry under `Unreleased` as `Breaking changes`, `New features`, `Fixes`.
+- [semantic-release dry run](#14221-semantic-release-dry-run)
+- [Site build](#14222-site-build)
+- [semantic-release proper run](#14223-semantic-release-proper-run)
+- [Netlify deploy](#14224-netlify-deploy)
 
-Internal changes to the project that are not part of the public API do not need changelog entries, for example fixing the CI build server.
+See the [workflow file](https://github.com/wmcadigital/wmn-design-system/blob/master/.github/workflows/semantic-release.yml) for additional information.
 
-These sections follow [semantic versioning](https://semver.org/), where:
+##### 1.4.2.2.1 semantic-release dry run
 
-- `Breaking changes` corresponds to a `major` (1.X.X) change.
-- `New features` corresponds to a `minor` (X.1.X) change.
-- `Fixes` corresponds to a `patch` (X.X.1) change.
+Uses the following tokens:
 
-See the [`CHANGELOG_TEMPLATE.md`](/doc/contributing/CHANGELOG_TEMPLATE.md) for an example for how this looks.
+- `SEMVER_GITHUB_TOKEN`
+- `NPM_TOKEN`
 
-Include the modified `CHANGELOG` in the PR.
+semantic-release runs in `dry_run` mode to analyze commits to check if a new release is necessary.
 
-## Accidental breaking changes
+The package outputs the next version number as variable in the GitHub Action context, which can be accessed by other step / jobs in the workflow.
 
-If a backward-incompatible change is released unintentionally, we will follow the process outlined on semver.org: https://semver.org/#what-do-i-do-if-i-accidentally-release-a-backwards-incompatible-change-as-a-minor-version
+This step is necessary because if we want to include the new version number in the static site, it has to be available at build time. However, semantic-release would normally only change the version number (and changelog), via a new commit, after the site has been built. Therefore the new version number must be determined beforehand.
 
-> As soon as you realize that you’ve broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it’s appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version.
+_We also have to use [a separate semantic-release action](https://github.com/marketplace/actions/action-for-semantic-release) when running the dry run running as semantic-release npm package seems to cause conflicts when run twice in the same workflow._
 
-If appropriate, you can set up an incident review that allows the team to see if there are
-any steps to avoid this happening again in the future.
+##### 1.4.2.2.2 Site build
 
-Communicate any actions as a result of an incident review, this will ensure our users will see that we take incidents seriously and can avoid some loss of trust.
+See [Building](./tasks/building.md) for details.
+
+##### 1.4.2.2.3 semantic-release proper run
+
+Uses the following tokens:
+
+- `SEMVER_GITHUB_TOKEN`
+- `NPM_TOKEN`
+
+First, [semantic-release analyses the new commits](https://github.com/semantic-release/commit-analyzer) and to determine if a new package release is necessary.
+
+If a version bump is not necessary the workflow will go straight to the [Netlify deploy step](#1.4.2.2.4-netlify-deploy).
+
+If a version bump is necessary (major, minor or patch), it [publishes the new package to NPM](https://github.com/semantic-release/npm). See the [NPM package information for more details](#1.5.3-npm-package).
+
+Next, it [updates the changelog](@semantic-release/changelog) and [updates the version number](@semantic-release/git) in the `package.json` via an extra `chore(release):` commit on the master branch.
+
+Finally it goes through all issues and pull requests referenced in any commits and [adds a comment and a tag](https://github.com/semantic-release/github) to say that they have been included in the current release.
+
+See the semantic-release [release steps documentation](https://github.com/semantic-release/semantic-release#release-steps) for full details.
+
+##### 1.4.2.2.4 Netlify deploy
+
+Uses the following tokens:
+
+- `GITHUB_TOKEN`
+- `NETLIFY_AUTH_TOKEN`
+- `NETLIFY_SITE_ID`
+
+The built site is deployed on netlify through the use of the [actions-netlify](https://github.com/nwtgck/actions-netlify) github action.
+
+_Note that **Netlfiy's automatic builds must be turned off** or else the site will be deployed twice_.
+
+## 1.5 Extra information
+
+Once the release workflow has finished, the Netlify site will be updated with any new changes and a new NPM package may be released.
+
+### 1.5.1 Bumping the version number
+
+The version number in the **package.json** will be automatically updated during the [semantic-release proper run](#14223-semantic-release-proper-run).
+
+In order for semantic-release to include a commit in its analysis, it **must** follow the [Conventional Commit Specification](https://www.conventionalcommits.org/en/v1.0.0/).
+
+semantic-release will only bump the version number if the release contains a commit starting with `fix:` or `feat:` or if a commit contains `BREAKING CHANGE:` in its description.
+
+If we are starting from version 1.0.0, the version number bump will change as follows:
+
+- `fix:` - Patch release, 1.0.1
+- `feat:` - Minor release, 1.1.0
+- `BREAKING CHANGE:` (in the commit description) - Major release, 2.0.0
+
+It will always increase the version number by presence of the largest change. If a release contains both `fix: ` and `feat:` commits, the version number would be bumped to 1.1.0. If any commits contain `BREAKING CHANGE:` in its description, the new version would be 2.0.0.
+
+For more details see [semantic-release commit message format](https://github.com/semantic-release/semantic-release#commit-message-format) and [semantic versioning specification](https://semver.org/).
+
+### 1.5.2 Updating the changelog
+
+Commits that follow the [Conventional Commit Specification](https://www.conventionalcommits.org/en/v1.0.0/) will be included in the changelog.
+
+Depending on the type of change (e.g. `fix:` or `feat:`), the rest of the commit title will appear under the respective section within the changelog.
+
+For example:
+
+- `fix: header line spacing` - will appear under the **Bug Fixes** heading in the changelog as "header line spacing"
+- `feat: add new button component` - will appear under the **Features** heading in the changelog "add new button component"
+
+### 1.5.3 Add to CDN
+
+Once built and cleaned the app needs to be added to the wmca cdn within a folder named the version number. E.g. https://cloudcdn.wmca.org.uk/wmcaassets/1.4.0
\ No newline at end of file
diff --git a/doc/preview.png b/doc/preview.png
index 41bec2dc..25c80777 100755
Binary files a/doc/preview.png and b/doc/preview.png differ
diff --git a/doc/troubleshooting.md b/doc/troubleshooting.md
index 2a9884f5..86ec005e 100755
--- a/doc/troubleshooting.md
+++ b/doc/troubleshooting.md
@@ -2,7 +2,7 @@
 
 ## npm and Node.js
 
-The West Midlands Combined Authority Styleguide uses `npm` to manage dependencies. Please [install Node.js](https://nodejs.org), and try running `npm install` again.
+The West Midlands Combined Authority Styleguide uses `npm` to manage dependencies. Please [install Node.js](https://nodejs.org), and try running `npm i` again.
 
 If Node.js is already installed, make sure you’re running v8 or up.
 
@@ -10,8 +10,8 @@ If Node.js is already installed, make sure you’re running v8 or up.
 
 JavaScript dependencies sometimes get out of sync and inexplicable bugs start to happen. Follow these steps to give a fresh start to your development environment:
 
-1. The installed `npm` version must be at least v3.10. You can update your npm with: `npm install npm -g` (`sudo` may be required).
-2. Re-install dependencies: `rm -Rf node_modules && npm install`
+1. The installed `npm` version must be at least v3.10. You can update your npm with: `npm i npm -g` (`sudo` may be required).
+2. Re-install dependencies: `rm -Rf node_modules && npm i`
 3. `npm start`
 
 If this did not work, try running `npm cache clean` and repeat the above steps.
diff --git a/doc/usage.md b/doc/usage.md
deleted file mode 100755
index 1492f232..00000000
--- a/doc/usage.md
+++ /dev/null
@@ -1,130 +0,0 @@
-[HTML5 Boilerplate homepage](https://html5boilerplate.com/) | [Documentation
-table of contents](TOC.md)
-
-# Usage
-
-The most basic usage of HTML5 Boilerplate is to create a static site or simple
-app. Once you've downloaded or cloned the project, that process looks something
-like this:
-
-1. Set up the basic structure of the site.
-2. Add some content, style, and functionality.
-3. Run your site locally to see how it looks.
-4. Deploy your site.
-
-Cool, right? _It is_. That said, the smart defaults, baseline elements, default
-attribute values and various other utilities that HTML5 Boilerplate offers can
-serve as the foundation for whatever you're interested in building.
-
-Even the basic use-case of a simple static site can be enhanced by manipulating
-the code through an automated build process. Moving up in complexity HTML5
-Boilerplate can be integrated with whatever front-end framework, CMS or
-e-commerce platform you're working with. Mix-and-match to your heart's content.
-Use what you need (toss it in a blender if you need to) and discard the rest.
-HTML5 Boilerplate is a starting point, not a destination.
-
-## Basic structure
-
-A basic HTML5 Boilerplate site initially looks something like this:
-
-```
-.
-├── css
-│   ├── main.css
-│   └── normalize.css
-├── doc
-├── img
-├── js
-│   ├── main.js
-│   ├── plugins.js
-│   └── vendor
-│       ├── jquery.min.js
-│       └── modernizr.min.js
-├── .editorconfig
-├── .htaccess
-├── 404.html
-├── browserconfig.xml
-├── favicon.ico
-├── humans.txt
-├── icon.png
-├── index.html
-├── robots.txt
-├── site.webmanifest
-├── tile.png
-└── tile-wide.png
-```
-
-What follows is a general overview of each major part and how to use them.
-
-### css
-
-This directory should contain all your project's CSS files. It includes some
-initial CSS to help get you started from a solid foundation. [About the
-CSS](css.md).
-
-### doc
-
-This directory contains all the HTML5 Boilerplate documentation. You can use it
-as the location and basis for your own project's documentation.
-
-### js
-
-This directory should contain all your project's JS files. Libraries, plugins,
-and custom code can all be included here. It includes some initial JS to help
-get you started. [About the JavaScript](js.md).
-
-### .htaccess
-
-The default web server configs are for Apache. For more information, please
-refer to the [Apache Server Configs
-repository](https://github.com/h5bp/server-configs-apache).
-
-Host your site on a server other than Apache? You're likely to find the
-corresponding server configs project listed in our [Server Configs
-](https://github.com/h5bp/server-configs/blob/master/README.md) repository.
-
-### 404.html
-
-A helpful custom 404 to get you started.
-
-### browserconfig.xml
-
-This file contains all settings regarding custom tiles for IE11 and Edge.
-
-For more info on this topic, please refer to
-[Microsoft's Docs](<https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/dn320426(v=vs.85)>).
-
-### .editorconfig
-
-The `.editorconfig` file is provided in order to encourage and help you and
-your team to maintain consistent coding styles between different
-editors and IDEs. [Read more about the `.editorconfig` file](misc.md#editorconfig).
-
-### index.html
-
-This is the default HTML skeleton that should form the basis of all pages on
-your site. If you are using a server-side templating framework, then you will
-need to integrate this starting HTML with your setup.
-
-Make sure that you update the URLs for the referenced CSS and JavaScript if you
-modify the directory structure at all.
-
-If you are using Google Universal Analytics, make sure that you edit the
-corresponding snippet at the bottom to include your analytics ID.
-
-### humans.txt
-
-Edit this file to include the team that worked on your site/app, and the
-technology powering it.
-
-### robots.txt
-
-Edit this file to include any pages you need hidden from search engines.
-
-### Icons
-
-Replace the default `favicon.ico`, `tile.png`, `tile-wide.png` and Apple
-Touch Icon with your own.
-
-If you want to use different Apple Touch Icons for different resolutions please
-refer to the [according documentation](extend.md#apple-touch-icons).
diff --git a/src/wmcads/components/README.md b/src/wmcads/components/README.md
index e69de29b..1c9e9942 100755
--- a/src/wmcads/components/README.md
+++ b/src/wmcads/components/README.md
@@ -0,0 +1,36 @@
+# WMCA Design System Components
+
+Components are reusable parts of the user interface that have been made to support a variety of applications.
+
+Individual components can be used in multiple different patterns and contexts. For example, the text input component can be used to ask for an email address, a National Insurance number or someone’s name.
+
+If you are using the WMCA Design System Frontend included in your build, the coded examples provided will render exactly as they do inside the Design System.
+
+## Component guidelines
+
+See [Coding standards](../../../doc/contributing/coding-standards.md)
+
+## Component List
+
+- Accordion
+- Breadcrumb
+- Buttons
+- Content card
+- Details
+- Document
+- File download
+- Form elements
+- In-text step
+- Inset Text
+- Links
+- Lists
+- Loader
+- Message
+- Page header
+- Phase indicators
+- Portfolio dashboard
+- Portfolio leads
+- Share
+- Table
+- Tag
+- Warning Text
diff --git a/src/wmcads/patterns/README.md b/src/wmcads/patterns/README.md
new file mode 100644
index 00000000..e83a8840
--- /dev/null
+++ b/src/wmcads/patterns/README.md
@@ -0,0 +1,18 @@
+# WMCA Design System Patterns
+
+Patterns are reusable parts of the user interface that have been made to support a variety of applications.
+
+Individual patterns can be used in multiple different patterns and contexts. For example, the text input component can be used to ask for an email address, a National Insurance number or someone’s name.
+
+If you are using the WMCA Design System Frontend included in your build, the coded examples provided will render exactly as they do inside the Design System.
+
+## Pattern List
+
+- Autocomplete
+- Banner
+- Contact details
+- Cookies
+- Feedback loop
+- Header and footer
+- Question form
+- Search
\ No newline at end of file