Improve and Launch
By this point, the vast majority of the issues will have fluidly moved across Linear and the project will be in a solid place. The point of this phase is to make sure everything really hangs together well and add any polish or flare to the mix. Often digital projects just build the thing, but never take any opportunity once the thing is built to improve it before a wider group of people sees it. We want to try and make things as good as possible, so build in this step.
We are going to Improve and Launch, usually in that order. Make improvements to the project, then launch it publicly.
But an alternative here is to launch a version of the project – either to the general public or quietly, as 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. We really like doing it this way and will try and encourage collaborators to do this.
Polish QA Run
Now the thing works together, the designer will take a final look at the project and a whole, make sure everything hangs together and make any minor tweaks to things that don't really work once the thing has been done. Cross-browser and device testing can also be done at this time, as well as any final accessibility and performance testing. With accessibility and performance testing, this should be done continuously throughout the Design and Build phase, which is relatively easy now with browser tooling. Sometimes issues with accessibility and performance will only be evident when the individual pieces of work have been weaved together, so it is important go once more through at this stage.
This will be tracked on Linear.
Letting the collaborator show it around
As the project is mostly there, we want to allow the collaborator the space to show the work to their wider organisation to encourage any final feedback and tweaks to the work. The emphasis here is final. Anyone who is going to have a substantial view should have been identified in Groundwork and their views fed in, or by establishing a way for them to be feeding in at particular points.
It is important therefore to find some good way of capturing this feedback but also framing the feedback in such a way that wider stakeholder know the project is on the downramp and that their feedback should not be wholly fundamental.
At this stage, we usually need to encourage collaborators to just launch the project and prioritise gathering feedback from their audience or community. This is feedback is ultimately far more valuable than anything that can come internally, particularly as people will encounter the project in the real world under natural conditions, rather than the quite artificial conditions of user testing or internal feedback processes. Analytics can also be used to work out what is not working quite so well, and these can only be built up once launched.
User Testing
If we didn't do user testing with a prototype in Groundwork, we now want to do user testing now, with people as close as possible to the real users of the project, observing how they are using it, then modifying it to improve it. The reason being that we want the project to be a success and this will always improve things. If we have to choose to do user testing in Improve and Launch or testing in Groundwork, we'd prefer to do user testing in Groundwork, with design prototypes. This is so there is space still in the overall project budget and timeline to make changes. Preferably, substantial testing with the launched site should be scoped as a follow-up project (or a substantial part of the initial project, which means less time in the Design and Build stage) rather than added as an afterthought.
Typically the feedback we are listening for at this stage is about the words people are seeing and how they work together - for example if they persuade as to the salience of the campaign or the necessity to join the organisation or organising drive. This should be easy to fix, either in the content management system, or through tweaking the copy. More substantial feedback should have been captured at an earlier stage in the project and already incorporated. Further feedback should be captured and put into Linear. But realistically it is now going to be part of a follow up project, or work on as a support item if thought to be particularly important.
Launch
By launch we mean some kind of public launch where needed. Or at least a point where people outside those working on the project are using the project.
We want to try and avoid as much as possible a big bang launch. We'd rather launch early then add more than do this. As we've been practising continuous deployment since the first moment of the project, the thing should already be very on the internet and the launch should be as simple as switching over DNS.
At Common Knowledge, we like public launches to be accompanied with an atmosphere of calm. We will have the project live from day one, meaning that deployment proper is a matter of flipping a switch. Collaborators have quite enough political and other complexity to deal with when launching something that they shouldn't have to worry about where the website is at.
However, with websites and tools, we sometimes forget some elements of a complete project on the web. We maintain a list of these on Linear, which can we used to make a launch.
Celebrate!
Wow! The project is in its second to last phase and has just gone out the door. Everyone working on the project should take a moment to celebrate this.
In the typical project phases, after Improve and Launch comes Reflect and Change).