Working in the alpha phase
It’s common for content designers to join a project at the beginning of or during the alpha phase. There should be a discovery report you can read when you start on an alpha.
It’s worth reading the service manual on how the discovery phase works if you’re new to services. This will help you understand what should have happened before this stage.
What is the alpha phase?
Alpha is the second phase of the service delivery process. It’s the phase where you try out different solutions to the problems uncovered in discovery.
Alpha services are not open to the public.
During the alpha phase, you’ll:
- test your riskiest assumptions
- explore new approaches
- build prototypes based on your ideas
Alpha focus
In alpha you'll explore areas of your service that are uncertain, starting with the riskiest assumptions. These are things that could hinder the user from completing a task and negatively impact the service.
You might not be working on a prototype of the whole service – you could just be focusing on a particular element or transaction.
During alpha you will get the chance to:
- work on a prototype with your design colleagues
- work with business analysts and policymakers to determine what information the service needs from the user
- understand your core user profiles
- use accessible design techniques to ensure the service doesn’t exclude any users (including if it needs more than just an online solution)
- identify and work through design challenges as they arise
- help gather or identify success metrics needed to monitor the service
- work in the open, for example, sharing your work in show and tells
- test your hypotheses on users
- explore the wider user journey outside your service by engaging the business-as-usual (BAU) guidance team
Who you work with on an alpha team
Just as in discovery, you’ll work with a multidisciplinary team in alpha phase. Your main collaborators will be an interaction designer, service designer and user researcher. But you’ll also work with a product manager, delivery manager, business analyst and engineers. Together, you’ll prioritise what to test, as well as when and how to test it.
Often, the same team works on discovery and alpha phases. This helps with continuity. But it’s also common for new teammates to join for alpha. This helps bring assumptions and fresh ideas to the surface.
As a service content designer in alpha, you also need to keep in close contact with the content designer in the BAU team who works on the GOV.UK guidance for this area. Contact them by messaging on the #content slack channel.
They can help you with background, policy contacts and will be the team you’ll need to work with if you need any GOV.UK guidance page updates.
How content designers contribute to an alpha
Being a content designer in the alpha phase is quite exciting. By this stage you should have a good understanding of who your users are, their needs and the business requirements.
As a content designer, you’re the champion of words. How we communicate with users is vital to them understanding and completing the task. You’ll continually engage with stakeholders and challenge rationale to help everyone speak the same language.
You’ll act as an advocate for user needs, analysing evidence to distinguish what’s true about your service, and what’s assumed. You might run riskiest assumption testing (RAT), which helps surface uncertainty about your service, users, or delivery plan.
A few tasks you might own include:
- creating a question protocol
- starting or maintaining a style guide for specialist language or acronyms
- designing content for different prototyping techniques
- hosting content crits
- applying WCAG guidelines
You will also:
- test different content with users
- understand and define jargon and acronyms
- make content compliant with regulatory and policy requirements
- identify and test accessibility challenges
User testing
You’ll start to test the language you’ve used in the service through user testing. For example, you could be testing whether users are able to answer the question you’ve asked properly or how users navigate to complete a task in the service.
As a content designer, you’ll have to balance the business needs and wants set by policy and legal stakeholders against what you learn from user testing. This can be tricky and takes time, but using your evidence to tell a story and prove your design decisions is important to convincing stakeholders.
Prototyping
You’ll typically be working on prototypes alongside your interaction designer. Some prototype formats include:
- pen and paper sketches
- Word documents
- Figma
- GOV.UK prototype kit
It’s a good idea to keep things simple and lean when prototyping in alpha. This is because you will likely make many changes, and this will save you time.
Don’t worry if you’ve not used Figma or the prototype kit before. Ask your interaction designer how you can support them.
Design histories
Design histories sit alongside your prototypes as part of a sprint. You should support the team by writing these design histories as they’ll be important supporting documents to keep a record of your work, to feed decisions back to stakeholders and to review before assessment.
They often detail:
- the focus for the sprint
- any research findings, such as what went well and what needs work
- what the design team did
- key milestones, for example, testing a new component or message
It can be helpful to approach a design history like a blog. Use informative headers and plain language to give the reader and clear understanding of the sprint.
Copy decks
Throughout alpha you’ll create and develop copy decks.
A copy deck is a single document that contains everything a developer needs to code a page on your service. This includes all content on the page, including headers, metadata and error messages.
A copy deck could be created in any format, for example, a Word document, a spreadsheet or a Confluence page. Speak to other content designers if you don’t know how to start a copy deck or what format to use.
You will hand your copy decks over to the developers when you move to private beta.
You will also refer to these to check your content has been accurately transferred into the built page.
Error and validation messages for developers
Error and validation messages are created by the content designer alongside the interaction designer. Typically error messages would not be coded into a prototype, unless it’s needed to test risky assumptions, for example, bulk CSV uploads.
Once these have been drafted, developers should use them rather than holding text. They may have some content for standard messages or specific scenarios, but you should also review these with your user in mind.
You should check these error and validation messages as part of the quality assurance and testing process. It’s beneficial to be part of this process in general – to check your content acts as you expect it to.
This is the same process for Welsh language translations.
Further information
Service assessment
A service assessment measures a service against the 14 points of the GOV.UK Service Standard. It's a space for service teams to get expert advice from a panel of specialists. They will look at the design, technical and delivery elements of the service, as well as accessibility.
A service assessment is often booked in advance by the delivery manager. You’ll work with the wider team to understand what is needed to prepare for the assessment.
An interaction designer typically leads the design conversation at an assessment.
Historically a content designer wouldn’t attend the assessment, but they are now often invited and included on the day. As well as adding to your experience and an opportunity to showcase your work, your interaction designer will probably want you to attend to support them and to answer any content-related questions.
Speak to your lead content designer if you have any issues with attending an assessment.
Before the assessment
You’ll play a supporting role in preparing the team for assessment.
This could include:
- refining prototypes and supporting your design colleagues
- supporting the team to tell the story of your service so far
- updating presentations and documentation
It’s a good idea to share information with the panel ahead of time, for example, slide decks, prototypes and design histories. This allows more space for valuable discussion at the assessment and can give you some helpful recommendations from a design perspective.
Your assessment planning is a good chance to reflect and review the decisions you made throughout alpha.
During the assessment
A service assessment typically takes place across one working day online.
You might be expected to talk at your service assessment if you attend but don’t worry – you shouldn’t write a script or over-prepare.
Don’t worry if you don’t play an active part in the assessment. It’s good to be there in case there are any content questions and to support your UCD colleagues.
After the assessment
The panel will have a wash-up meeting and write a report. Your team should receive the report about a week after the assessment meeting.
The report will give a rating of red, amber or green for each point of the service standard. Red means the standard was not met, amber means it was met with conditions, and green means it was met. The panel will comment on each service standard point and what the team needs to do to pass.
Your service will also receive an overall rating of red, amber or green.
Stopping the work
Some services will not progress to beta. This could be for several reasons, including budgets and policy changes, but it can also be a team decision based on your findings.
Part of alpha is understanding the constraints and limits to your service. It’s a good use of time and resources to come to this decision. In fact, testing things out and pivoting is the whole point of alpha.