What I’ve learnt through Beta as a UXer

In September 2019, I began my first Government Digital Standard (GDS) Beta project as a UX consultant. From day one it’s been a steep learning curve, but for all the right reasons. My client is undertaking a hugely ambitious but vital transformation programme. Part of this involved building a new digital service that harmonised the way hundreds of thousands of users were granted millions of pounds in funding on a daily basis.

They had spent a year researching their user’s needs and designing ‘proof of concept’ prototypes in the Discovery and Alpha phases. Closely following the GDS processes and designing system, they were soon ready to start coding the product.

In Beta, we’ve been working from the ground up to get our processes in place to deliver the pilot launch. In classic GDS style, we work in an agile way and use Scrum methodology. We’ve had to make difficult technical and design decisions in quick succession. This was to ensure we build a user-focused service that also supports the organisation’s long-term strategic plans.

Sometimes, the size and importance of the product can be overwhelming. But luckily, I learned a few things along the way. I’d like to share some of them with you now to help you make a success of your next GDS project.

1) Make sure you have ‘experts’ on your team

It’s a great advantage to have someone on your Beta team who has the knowledge of all things internal within the organisation. We’ll call them your ‘organisation expert’. Your organisation expert will help bridge the gap between the Beta team and the business.

They’ll be able to answer your questions and make design decisions quickly, and without needing to ask a string of people who the best person to contact is. They will be able to feed into the design and build challenges along the way with insights about what will and won’t work.

For example, the content on a particular page may need to change due to internal politics you couldn’t have been aware of. The flow of a user journey may hinge on the structure of a particular department, and your organisational expert will be able to flag this early on. In our project, the organisational expert was also the product owner. This meant they came with over a decade of experience in the organisation’s make-up and legacy digital systems.

It’s also important to have someone who worked on the Discovery and/or Alpha phases, as they can be seen as a ‘project expert’. Your project expert will be your consistent voice for the user, advocating for design decisions based on previous user research.

When new people are onboarded onto your Beta team, they will (and quite rightly) want to know why something has been designed the way it has. And your project expert will have the evidence on-hand to gain quick buy-in from them. That way, you are all convinced of the same single goal. They will also have learnt from Alpha what didn’t work so you can save time and not repeat work.

Of course with any client, internal staff will move on and contractors may be only be around for a fixed term, so it may not always be possible to have a project expert. Make sure you get a thorough hand-over when you start Beta about all the user research done previously as well as who they spoke to. If the research is documented well enough, you will be able to draw on this to make evidence based design decisions, and follow up with participants to clarify certain feedback. Your organisation expert may be able to help with this too.

2) Assign an Accessibility Champion

To pass a GDS assessment you need to ensure that the digital product is accessible. It quickly became apparent to me that there wasn’t enough emphasis on making our product accessible. No one owned it as a task.

If accessibility isn’t considered by your front-end developers from the beginning, you will have a huge task on your hands to retrospectively fix your code at the end. For example, you have to consider things such as alt-text and page structure for screen readers, which is a lot easier to tackle as you go rather than change what you’ve built as an after-thought.

We all have a responsibility to ensure our product is accessible. But it is a good idea to have one person charged with advocating it so we know it won’t slip along the way. I’ve named this person our ‘accessibility champion.’ This ‘accessibility champion’ must have the knowledge of what needs to be considered from an accessibility standards point of view, but also for GDS.

They will need to have time dedicated to checking all the code written during a sprint. This is why we made sure that our champion was part of the sign off process for any feature we developed. The product owner, UX consultant and our accessibility champion all had to give a green tick of approval to say that they were happy with what had been built.

3) As soon as you can, create a pattern library and design system

This goes for both your design team and your development team. Our design team created a pattern library fairly early on in Beta. This enabled us to maintain consistency with our components and how we used them. You can create masters within most design software packages; use this to your advantage to ensure changes are updated to all your files.

We’ve also created a similar system for the developers. They used an online product to create a design system with all the necessary coded components. Much like any master component, any changes to the design system code is implemented across the service. Designers can also have access to this to approve how the components have been implemented so they know that what is being used is correct.

The later you implement a pattern library and design system, the bigger the burden on the build. Every time a component is used in your product/service without it being created in a design system first, the inconsistencies in CSS add up. This creates tech debt to address later on.

The more inconsistencies, the more tech debt and the more time and manual effort you’re using to correct your code. This not only uses up valuable sprint time, it also means your front-end code could fall down when it comes to accessibility standards.

4) Document all of your user research

To pass your Beta GDS assessment, you need to provide evidence of why you came to the design and tech decisions you did. This often comes down to feedback from users, so you’ll need to show where this feedback came from and what you did with it.

Assessors want to know who you researched with, the format of the sessions, what you researched and how. Additionally, they need findings from the research and outcomes from it, e.g. what features you changed as a result of user feedback.

To stay on top of this, it’s really important to document all your research and outputs, and store them somewhere that’s easy to find. It’s good to keep records of participant first names and session times, your research plans, findings and new wireframes, as well as development tickets created based on your research.

You should also conduct research on a regular basis with quick turnarounds to ensure your designs have constant user feedback. This means contacting potential participants regularly, too. Therefore, it’s essential to create and maintain a list of participants to make recruiting smoother. You’ll spend a long time reaching out and setting up sessions with people. The more time you can save with a pre-populated list of willing participants, the better. Lean on your organisation expert for internal contacts too to help with this.

5) Your pre-development processes need to be tight

For my project, the way we worked as a pre-development team involved trialling many different processes. All necessary, all painful to set up. Our main processes centred on signing off features to go into development tickets. Who is included in this process, and at what stage, has been adapted along the way to continuously improve how we hand over features.

A key take away for me would be to involve technical leads and/or architects early on so that they can discuss the technical solutions as soon as possible. This avoids painful conversations down the line with developers about how features are to be implemented. However you decide to work as a pre-development team in Beta, you just need to make sure that you mutually decide a way forward and keep your processes tight.

Our goal is to stay ahead of the developers by two sprints. That means we have features designed and approved four weeks ahead of when we want them to be built. If we don’t adhere to our strict process of who needs to review those designs and when, delays become likely. This approach also helps you avoid reviewing designs and making decisions last minute. Pushing products out the door leaves no time to talk to tech representatives properly about the implementation, pushing you back even further.

That said – we’re still learning. All our processes adapt in parallel with how we’re learning to work with varying disciplines. Every Beta project will be different depending on deadlines and the product you’re actually building. Define how you’re going to work as early as possible, especially with a team who are new to each other. Find who your experts and champions are going to be and create your pattern libraries! I’ll certainly do so in any and every future Beta project I work on.

Find out more about our projects and how we work with clients in the Public Sector. If you’d like to discuss an upcoming project with us, call or email hello@nomensa.com to start the conversation.