The Structure of a Digital Project

Groundwork

We begin every project with a kick-off meeting between our team and key stakeholders from yours.

This is to make sure that we've all met each other and we're on the same page before we begin work. We will establish how we will work together, clarify any outstanding questions from both sides, agree on the key deliverables and identify how we will measure success.

We will also discuss your overarching strategy, to ensure that what we develop aligns with and supports your goals and theory of change. If you haven't already defined your theory of change, then one thing we can do is help you build one.

We don't build digital software just for the sake of it. We want to make sure it makes an impact on the world and helps bring about the change you want to see. This means we need to understand the broader context of the project, right from the start.

Discovery

During this phase, we learn as much as we can about your work and start to think together about how to meet your goals for the project.

Usually this involves:

  • Understanding your community and audience: creating personas, clarifying their needs, conducting research interviews and defining user flows.
  • Understanding your content – text, images, videos, resources like PDFs, etc. We will undertake a content audit to understand what you have already and what new content will need to be created or sourced. We always like to approach projects by “designing from the content out”, making sure that any design decisions are based on your actual content, rather than speculation.
  • Technical scoping. If it's a new project, we'll spend time identifying which tools or services would best meet your needs. If it's an existing project, we'll take a look at what you're currently using (codebases, deployment pipelines, hosting solutions, third-party services) to identify technical risks and plan how to handle them.

At the end of this phase, we'll to share with you what we've learned, what we're thinking about and our thoughts on how best to approach the project.

Prototype

Next, we design and develop an initial prototype, based on our Discovery work.

This can take a number of different forms, depending on the project: either low-fidelity interactive wireframes, or something built using code or existing digital services.

We design for user flows, rather than individual screens. We try to keep our prototypes as lightweight as possible, so we can move quickly to testing our assumptions. We strongly recommend working with real content during this phase, as this will be a key part of the user testing.

User testing sessions always yield a great deal of insight, which is why we encourage clients to begin testing as early as possible.

After user testing, we will share what we've learned from these sessions. We'll use these learnings to iterate on the prototype and inform our work moving forward.

Design and Build

We will often begin the design process by finding and discussing visual references with you, as this is an efficient way to agree on a general visual language (including colour, typography, look and feel).

In our experience, the best outcomes are achieved when designers and developers work in tandem, rather than having specific handover points.

For this reason, rather than design static layouts of every page, we create a design system of components and modules that can be applied throughout the site and in future. We generally also design a number of key pages in their entirety, to ensure that all components are working together well.

We like to take a mobile-first approach to creating websites, as this ensures that the information hierarchy is well-considered and the website is as simple and usable as possible. We also make sure that designs comply with the latest accessibility guidelines.

We practice a technique called continuous delivery when creating software, which means that from the first day of development there will be a working version of the site on the web. We'll update this site continuously during the course of the project.

At the end of this sprint, the site will be at a place where you can share it internally and gather feedback from your stakeholders. We will use this staging version of the site for further user testing.

Improve and Launch

We will consolidate this user feedback, identify any issues that have emerged and prioritise these in collaboration with you. We then make improvements to the site based on this feedback.

The alternative here is to launch this version of the site – either to the general public or quietly, as a soft launch – and then observe how people use it. After a few months of this, we can examine what we've learned and then make further improvements. The advantage of this method is that it allows you to see the site being used in real life, rather than an artificial testing environment.

During the Improve phase, we will also test the site for bugs and across different browsers and devices. This quality assurance phase involves both us and you – we encourage collaborators to check how the site is looking and working across different devices regularly, to avoid last minute stress.

We also use this time to create some visual assets for your social media accounts, ready for the public launch.

At Common Knowledge, we like public launches to be accompanied with an atmosphere of calm. We will have a staging site live from day one, meaning that deployment proper is a matter of flipping a switch.

results matching ""

    No results matching ""