Following the completion of our Discovery phase in February, we agreed to move forward into building an Alpha. After looking at two specific topics in a lot of detail in this Discovery phase, we decided to focus on just one of these areas in our initial Alpha – chickenpox.
To begin this Alpha phase we gathered the whole team together for an Inception day, so we could all meet up to discuss where we’re heading and what we need to do to get there.
Moving on from Discovery
As we were bringing some new people into our team, it was important to recap the journey we’d been through on our Discovery phase. Matt, our Product Lead, talked through:
- How we’d approached Discovery – some of the things we’d done
- What our outputs were – what we discovered
- How it went, and what we might do differently in the future
What is Alpha?
The idea of our Alpha phase is to take what we learned in Discovery and build a working system that meets the users’ needs we discovered. It is partly about proving we can build a service that meets these user needs, and partly about reducing the risks we see ahead in making this into a real live service.
We’ll continue to iterate ideas during the Alpha phase, and do further User Research.
You can read more about how GDS defines an Alpha phase.
Expanding our team
In order to build a working system, we need to expand our team by bringing in some specific expertise.
To start with we’re bringing in Michael, Tom A and Tom B. Michael and Tom A are both Developers, Michael being a UI specialist. Tom B will provide us with some Operations expertise. This might be quite light touch to start with, but it’ll be useful to have someone to help us out with cloud hosting configuration and associated tooling.
Cue A/B testing gag, to find the preferred Tom…
We also reminded ourselves what it means to be part of a multidisciplinary team – while we value expertise, we also have to all be willing to get involved in doing things that might be outside of our particular specialism.
Resetting our vision
Together our new team agreed a vision for our Alpha. This was helpful in ensuring we’re all on the same page and have similar expectations about what we’re doing when we all walk out of the room.
THE chickenpox alpha
IS a potentially disposable, responsive (mobile first), private website
FOR the chickenpox alpha team
WHO WANT to understand and demonstrate we can meet user needs
THIS SERVICE will build on what we’ve learned in discovery / demonstrate (and test) an end-to-end journey through the content / test practical advice / be a test bed for relevant choices content / inform, and be informed by, the technical alpha
UNLIKE current NHS Choices / any future beta
THIS will assure stakeholders we can build the right beta
Coming up with an initial plan
As the day went on we were building shared expectations about what we embarking on, but we also had to come up with an initial plan, so we all knew what we were going to do during the first week or so.
We started with the user story map we’d produced as part of our Discovery, which summarised the user needs we’d found.
Matt, our Product Lead, then divided the stories on the map into an initial three groups – essentially grouping the top stories into three consecutive iterations that we’d work through.
This plan will change as we progress, come up with new ideas and gather more feedback, but this gives us a good starting point.
User research in Alpha
During Discovery we had a one week User Research cycle – talking to users and then getting some new ideas, questions and prototypes in front of users a week later.
This was pretty intense, so for Alpha we decided to opt for a two-week cycle, with our User Research included at the end of each two-week iteration.
We also agreed to try out some different research tools and techniques – making use of remote tools such as UserZoom, and trying out some pop-up testing too.
To enable us to move fast, we decided to keep the alpha technology as quick, cheap and simple as possible. This meant using familiar technologies like ASP.Net MVC, Azure for hosting, and GitHub for source control.
We also agreed to investigate the use of a content-as-a-service style CMS, to see if that would be an appropriate solution in the longer term.
In terms of tooling for the team, we stuck with Trello for our work-tracking, as it’s really simple, and gives us enough of what we need right now. We might need something more complex in the future.
We made a general plea to reduce email by making more use of instant-messaging tools for team comms. We’re not all based in the same place, so we’ve set up a team Skype group now, and it really helps to keep people in touch with each other throughout the day.
I think everyone left the room with a good idea of the goal we’re aiming for, and how they can help us to achieve that goal. It really helped to get everyone out of the office for a day, and let them focus on how we work together through this next phase.
Some of the ideas and exercises we ran through on the Inception day are based on this agile inception deck.