Creating a UX and Design process for The Sun

We all know the ideal processes and steps involved in creating a unique, user-centred design, but in reality, it’s not always easy to follow them. Here’s how the News UK design team developed a UX and design process for The Sun.

Why we needed a design process

The Sun is very fast-paced — projects sometimes feel like they were needed yesterday, and ‘ASAP’ is a common deadline for projects to be completed by. As a result, our team got into the habit of sometimes skipping steps in the design process in order to get work done. We wanted to address this, so decided to develop a UXD process for projects going forward.

How the process developed

It was important for us not to be blinkered by our own process on The Sun — research was just as important as it is in any design process.

We initially carried out interviews with members of other teams, including designers from The TImes and our UX Research Hub, and I made sure we gathered requirements from both UX and UI designers.

This research allowed us to pull out nuggets of good practice that existed, as well as dig into any issues that existed in current processes. From this, we could move into mapping out the process.

Once the pieces of work in our process had been mapped out from the start of a project to delivery, it was clear they could be split into 4 phases:

• Brief
• Discovery
• Conceptualise/Test
• Delivery

Each phase is important and involves a number of steps.

Phase 1: Brief

Put together a brief. This is as simple as someone documenting what the project is, why we’re doing it, who’s involved, who it impacts and how we measure success (we’ll come back to that later). To address this, we created a brief form, which allows us all to know what we’re doing and why. The key to a brief form is simplicity — or it won’t get filled out by stakeholders.

Plan. This is where we’ll come together as a team, take the brief and work out who’s picking up the piece of work and the steps we think are needed. If we know at this stage that we need to carry out moderated testing, we can get the ball rolling. By this point we should have a good idea of what’s needed for the project, who’s going to do it and what steps they’ll take.

Phase 2: Discovery

Now that we know the basics of why we’re carrying out the project, we can start to shape what the solution may be. The discovery phase of the project is a chance to work out everything you need to know and is the building block for your design phase.

Gather requirements. It’s important to know as much as possible upfront — there’s nothing worse than finding out a requirement when you’re halfway through designing the solution. At the start of a project we’ll have a meeting with relevant stakeholders to capture business and user goals, as well as capture any initial vision or requirements that people have in their head — this gives you an idea from the outset of what’s needed by the business and what a user may want from the product.

Define success metrics. This allows us to return to a piece of work and measure how successful it’s been. Thinking of this upfront helps to get everything tracked early on, rather than it being an afterthought.

Do competitor analysis. Once requirements have been captured, we can start to look at best practices. Although time-consuming, It’s vital that this is a considered piece of analysis — a considered approach means you can notice even the smallest element and understand the impact that may have on a user. Creating a stand-alone competitor analysis document means you’ll have something to return to throughout the concepting phase, as well as being able to share with stakeholders to bring them along on the design journey with you.

Gather user insight. You should now have a rough idea of where your solution may head, as well as concerns, but this is a great opportunity to find out more from users. There’s often existing insight that can be referred to, so this is a good time to reach out to the Insights team for existing research. We can also gather quant insight from users in the form of short surveys or user interviews. With stakeholders, we’ll map out the goals of the research, for example: Are users interested in this kind of feature? Do they struggle to find certain features currently? How do they interact with this kind of feature elsewhere? This helps to build a picture of what users may want from a feature.

Once each of the discovery phase steps are complete, you should have a really clear picture of what your problem is and how you may solve it. These findings will feed into the concepting/testing phase.

Phase 3: Conceptualise and test

We need to ensure at each stage that we’re keeping stakeholders and other members of the team updated with progress. If they know where we’re heading design wise, they can give input early on and have an impact on the final design.

Now comes the really fun bit — the reason we enjoy being UI or UX designers. It’s here we get to shape the solution and test with users to make sure we’re building the products they want and understand.

Run a workshop. Now that we have our initial research, we’re ready to involve other members of various teams. A workshop might not always be necessary, but if you’re running one, the important thing is that your research feeds into it. All workshops I run start with a run-through of what we’ve discovered — this helps everyone in the room (or on the Zoom) get ideas in their head, understand requirements and understand the business and user goals of the project.

Collaborate and conceptualise. It’s at this stage that UX and UI come together to flesh out concepts. Due to a lot of crossover between UX and UI and the need for projects to be completed quickly, it’s easy for one person to end up doing the majority of the concepting.

One thing we wanted to get away from in our process was a UI designer feeling like they’re colouring in wireframes and a UX designer feeling like all they’ve done is carry out some research and not been involved in the outcome.

As a team we’ve now been using Figma for some time, which has made it much easier to collaborate. At this stage we take the basic concepts that have come out of the workshop — this can be sketches, basic wireframes or even just notes — and work together to flesh out these concepts into a more detailed solution.

Wireframing and flows. Once UX and UI have got a good idea of the design, the UX designer can go away and flesh out these concepts into wireframes and user flows. This is also an opportunity to highlight any edge cases that only arise once you get into the detail.

It’s important at this stage for UX and UI to have regular catch ups, run through ideas, issues the UX designer has spotted and any changes to the original concept. Again, this is to make sure both UX and UI feel part of what ends up being developed.

Perform a technical review. By now we have a good idea of where the design is going and what the solution may be. A technical review helps us catch any issues early — if developing something is going to push estimates back by a long way, it’s better we know at this stage, so designs can be tweaked.

Perform user testing. Now that we have a solution we and the business are happy with, we can validate with user testing. We want users to feel like they’re in the product, so we’ll usually get relatively high-fidelity mockups created for testing. These aren’t final by any means but help to give a more realistic experience than wireframes.

The important thing here is that you can validate your concerns about the design. This is when we’ll create a document and catch up with stakeholders to pull out any concerns they may have, for example: are they worried users won’t find the feature? Won’t understand a checkout page, won’t know a closing date of a competition?

By documenting this, we can shape the user testing script. Having clear goals allows us to target specific concerns with tasks or questions.

Which type of usability testing is best?

This depends on the project we’re working on. If it’s a small change to a feature or we’re on a tight deadline, we’ll carry out some remote unmoderated testing via our testing platform, User Zoom. In general we set up two tests each time: one qual where we set tasks and observe videos of users, and an almost identical quant test to gather more robust results.

When setting tasks for quant tests, it’s key to ask post-test questions to dig into how users reacted to each task. This helps us understand what does and doesn’t work and gives us confidence when presenting back to stakeholders.

Obviously unmoderated testing will never be effective as face-to-face sessions with customers but results can be turned around in a few days as opposed to over a week when recruiting users via a panel.

Of course, nothing beats sitting down with a user and really digging into those issues they may have. Doing this regularly also helps you to understand our users more, and their pain points. We’re designing for them so need to know as much about them as possible.

Once testing is complete we will have some learnings that mean designs need to be tweaked. It’s really important to present back these findings and changes to the business. Taking them along on the design journey, makes them feel part of the solution but also saves any issues further down the road.

Polish final designs. By now we’re pretty sure on what the final design will be, so the UI designer can take the current designs, tweak them and finish off their designs so they’re ready to hand over to developers.

Once final designs are complete, there should be a playback to stakeholders so they understand what change is going to be made to their product — the last thing we want is them seeing it for the first time when it’s released.

Perform a team review. Product owners, BA’s, developers and designers come together to discuss development and roll out. As designers, this allows us to know when to expect to review development work.

Phase 4: Deliver

We’re now nearing the end of the design cycle — the point at which we hand over all designs, user flows, wireframes, prototypes and any supporting documentation that will aid the development process. It’s vital that these are as detailed as possible — this saves back and forth conversations with devs during development.

Perform a design review. This is one of the most important steps in this phase. No matter how detailed your design documents are, there is still the chance of the final product not being quite as you envisioned. This is your chance to catch any discrepancies and allows you to catch things early, not when they’ve already been released.

Release and measure. At the start of the process we set out requirements and success metrics, but how many times have you returned to a project to make sure it’s actually a success? You may be able to tweak your design slightly and improve metrics rather than a feature just sitting there and being forgotten.

Measuring success also helps you tell the story of the project. Why did you carry it out? How did you carry it out? What was the final solution? Was it a success?

Key takeaways

This may seem like a really long process, and the reality is that not every step happens. Most importantly, aim to:

• Get a decent brief in
• Gather requirements
• Carry out some research
• Collaborate in the design process
• Perform some user testing
• Hand over-detailed designs
• Measure your success

If you do this, I guarantee you’ll create better, more user-centric products and the design process will run more smoothly.

Here’s a link to the process diagram. Not all processes are the same, so let me know how you do things differently in the comments below.