Our UX Design Process

Good design reflects what the user wants to do, in the smallest number of steps possible. As we target organisations in the public sector we follow a similar agile delivery process to the GDS. However we’re flexible and can tweak process to better meet user needs and for delivery.

How design works with Sonic UX

Discovery Phase: Understanding what users wants to do

We begin by defining the problem and quantifying the value of solving the problem. 

We need to know your service works from the beginning to end, thinking about all the things the user needs to do. We do this by gathering requirements from product owners, designers and stakeholders, become an observer in user research activity or put together personas and user journey maps from any existing user research done already.

How long does it take?

While there’s no specific timeframe, normally discovery can take 4-8 weeks, depending on how much research has been done already. It’s okay to decide at the end of your discovery that you don’t think it’s worth running an alpha.

Alpha Phase: Prototyping designs

This is where we try out different solutions to the problems you learnt about during discovery.

We do this on paper then sketch then design in Figma or code the designs in HTML, whatever achieves representation of the application the fastest. We send then the URL to stakeholders or end users to ask people how the design works for them. Through peer review and end user feedback we can form a shared standard of design work. The crucial part of alpha is  identifying any riskiest assumptions and testing them. What these are will depend on the service you’re building.

For example, say the problem you’re trying to solve is to might be reduce loneliness among the elderly. If you think a chatbot might help to solve that problem, one thing you might consider first is carrying out research to find out how the people you’re trying to help get support at the moment.

You’ll need to work towards solving a whole problem for users. 

With an online prototype, we can’t apply the full range of technical accessibility tests used for production code, but we can

  • understand any WCAG accessibility principles – this will help you identify and test any specific accessibility challenges you’re likely to face with your service
  • are including disabled people in user research

To move on to beta we’ll need to be confident that:

  • We can create something that meets users’ needs and is cost-effective.
  • We’ll have the budget talent to deliver what you need to – this includes having a budget for research

Alphas tend to last between 6 and 8 weeks.

Beta phase: Building it for real

Here we begin with in ‘private beta’. This involves inviting a limited number of people to use your service so you can get feedback and improve it.

Once we’ve improved the service and are confident you can run it at scale, we take an assessment to move into ‘public beta’. This involves opening up your service to anyone who needs it. If you’re replacing a legacy service, keep the legacy service running until your new service moves into its live phase. All this ensures the service is ready so everyone can use it.

We’ll to show how we’ve run a regular accessibility testing on your service and run research sessions with people who have a disability.

We’ll also need to talk about the results of your accessibility audit and fix any issues before moving into public beta.

We’ll need to show that we’ve considered whether the service has any pain points that might lead to people being excluded, and what steps we are taking to address them.

When moving into public beta, we’ll also need to publish an accessibility page for your service.

Live phase: Building it for real

The live phase is about supporting the service in a sustainable way, and continuing to iterate and make improvements.

As in beta, improvements we make during live should be:

  • based on user research
  • tested to make sure they work with different browsers and devices
  • tested for accessibility
  • quality assured

We also make sure we are clear on the effects that changes will have on offline channels, or any related services and make sure none of the changes will have a negative impact.

We’ll also need to spend time during public beta reviewing the performance metrics you set to check the data you’re collecting will tell us whether your service is performing as it should.

Retirement phase: If those services are no longer required

Your service may eventually need to be retired, for example if policies change or if there’s evidence that users’ needs have changed.

We need to consider how the user needs will be met after your service is retired.

It might be the case that:

  • the user need no longer exists
  • a different service will meet the user need
  • the user need will no longer be met by your own organisation.

As soon as you know that your service is likely to be retired you should email all users saying:

  • what’s changing and why
  • what they’ll have to do to continue to have their needs met in future
  • what will happen to their data, whether you’re passing it on to another service and the rights they have under your organisation’s data protection policy

Some users will still try to access the service at the retired web address.

We’ll create a plan for redirecting those users to the new service, or telling them that the service that has permanently retired.

We would already have policies in place to manage that data responsibly, including details of how long it’ll be retained.

If transferring data to a different organisation, we’ll ensure must:

  • It is done in line with your organisation’s data protection policies
  • We’ve told your users

%d bloggers like this: