Product · Iteration & Improvement

Rethinking the score

Iterating on an established product to better reflect customer goals.

Place: Siteimprove, Accessibility product.
Role: Research, conceptual direction and UI design.
Team: Accessibility product team, developers, design system team.
Timeline: From first release to follow-up iterations.

Project highlights

Quick initial adoption
Customers quickly adopted site targets to track progress towards their goals.
Iterated based on feedback
Follow-up research revealed the limits of site targets and informed the next solution.
A more relevant measure
Introduced a custom Accessibility score to reflect progress against customer-defined goals.
Used for reporting
Large accounts applied the custom score across all their sites, making it their primary focus for accessibility reporting.

Context

Siteimprove's platform brought together several products, including Accessibility, Quality Assurance, SEO and Performance. To create a more unified experience, the platform had introduced the Digital Certainty Index (DCI), a points-based scoring system that helped customers understand how their websites were performing.

Within Accessibility, however, customers faced a longstanding challenge. Digital managers and accessibility teams were responsible for improving accessibility across individual websites or entire web estates. They needed to prioritise work, coordinate efforts and demonstrate progress to leadership, but the existing score didn't always reflect the goals they were working towards.

Reaching 100% was often unrealistic, even when teams were making meaningful progress towards a defined accessibility standard or addressing the issues within their control.

I worked across research, conceptual direction and UI design to explore how we could better support these goals while maintaining consistency with the wider platform.

Discovery

Through customer interviews, we explored why the existing Accessibility score didn't always reflect the progress customers wanted to make.

Some teams were working towards a specific standard, such as WCAG AA, rather than addressing every possible issue. Others needed to prioritise the fixes they could realistically make, while some issues were outside their control, such as content managed by third parties.

For these teams, the problem wasn't simply understanding their score. They needed a way to measure progress against a more focused goal, coordinate their efforts and communicate that progress to their own leadership.

This gave us a clearer direction: help customers work towards their own accessibility targets without losing sight of the wider accessibility picture.

Diagram: three customer situations, working towards a standard such as WCAG AA, fixing what they can, and issues outside their control, lead to one need: progress towards their own target, with the wider score still in view.

Direction

Introducing a target within the existing score.

We explored several concepts, including a target marker within the Accessibility score, a points-to-target progress bar, and a custom percentage score.

The challenge was balancing customer flexibility with the purpose of the DCI. We didn't want to imply that issues outside a chosen target no longer mattered, or create an Accessibility experience that felt disconnected from the rest of the platform.

We chose to start with a site target represented within the existing score. It was a relatively subtle change that let customers focus on a goal while preserving the broader scoring context. This gave us a practical first step that could be released and evaluated before committing to a more substantial change.

Three concept sketches: a target marker within the Accessibility score, a points-to-target progress bar, and a custom percentage. The target within the score is starred as the first step.

Design

Fitting a new concept into an established system.

I explored a range of visual concepts, from more playful treatments to simpler, understated approaches. Although customers responded positively to some of the more expressive ideas, we needed to maintain the visual language and interaction patterns of the wider platform.

We settled on a restrained design that felt familiar within the existing DCI experience. I brought the concepts to design critique and worked with the Accessibility product team, developers and the design system team to refine the solution.

The implementation also required us to consider technical behaviours, including the ability to exclude specific instances from the score. I worked with the design system team to ensure the solution could be implemented as a shared React component, with potential for reuse across other product teams.

Evolving the solution through feedback.

After release, we saw customers switching on the site target quickly, suggesting that the concept addressed a real need. Follow-up customer interviews, however, revealed limitations.

Because the target was represented as a point within the existing score, it could fluctuate as issues were resolved. Customers also still couldn't reach 100% against their own goals, which limited how well the feature supported their original need.

This feedback informed further iterations. We explored alternative concepts and eventually introduced a custom Accessibility score, allowing customers to measure progress against their own goals. Rather than replacing the DCI, it was presented as an alternative view within the existing overview experience.

Wireframe of the Accessibility score card: the score ring carries a site target marker, with an option to exclude instances, built as a shared React component.

From the first release to the iteration. The site target sat as a point within the score, so it moved and 100% stayed out of reach. The custom Accessibility score can reach 100% of the customer's own goal, shown as an alternative view beside the DCI.

Outcome

The initial site target was adopted quickly after release, giving us an encouraging early signal. Follow-up interviews helped us understand where the solution fell short and informed the move towards a custom Accessibility score that better reflected customers' goals.

After its introduction, we saw accounts setting this custom score across all their sites and using it as the primary focus of their accessibility reporting. This suggested that the feature was doing more than changing how progress was measured: it was helping teams establish a shared target and communicate their progress to leadership.

The work evolved from a relatively small change within the existing scoring system into a more tailored way for customers to measure and communicate accessibility progress, while retaining the wider DCI context.

It also highlighted an opportunity to think beyond Accessibility: other product teams saw potential applications for the concept, although their roadmaps made a coordinated platform-wide initiative difficult.

Illustration: a list of all sites, each with its own custom score, leads to a report whose progress line rises towards a target, shared with leadership.

Reflection

This project reinforced the value of incremental product improvement. The first solution gave customers something useful sooner, while follow-up research helped us identify its limitations and make more informed decisions about what to change next.

It also highlighted the tension between solving a proven customer problem within one product and addressing it consistently across a wider platform. In hindsight, a platform-wide initiative could have created a more unified approach, but the immediate customer need within Accessibility was clear.

I would continue to balance practical, incremental delivery with earlier conversations about broader platform opportunities, so that a solution can meet immediate needs without losing sight of where it could create value elsewhere.

Two lessons: deliver in small steps, in a cycle of release, learn and iterate; and talk earlier about the wider platform, where Accessibility's idea could reach Quality Assurance, SEO and Performance.

Diagrams on this page are illustrative recreations. They use generic interface elements, not Siteimprove's product screens.