Business context
The Pre-rating Scorecard is BeZero's self-serve alternative to a full carbon rating. Users pick a project type from around ten sub-sectors and answer roughly thirty sector-specific questions. The tool returns an indicative score across three risk factors. Additionality asks whether the emissions reduction would have happened anyway. Carbon Accounting asks whether the tonnage claimed is credible. Permanence asks whether the carbon will stay put.
There are two types of scorecard. User scorecards are created by customers to share, duplicate or iterate, either manually or by uploading documents that pre-fill the answers. BeZero scorecards are projects scored by BeZero's analysts, and there are over 1,000 of them.
It's a specialist tool with a small and valuable audience. Around 140 organisations use it in a given month, all on enterprise contracts. Most users are portfolio managers, heads of origination and procurement leads deciding whether to commit real money to a project.
The scorecard is marketed as a transparent view of how BeZero rates projects. A full rating comes with a long analyst report. The scorecard gave users a letter score with no explanation of how it was calculated.
I was brought in as the designer. The product manager went on maternity leave early in the project, so I took on the product management role alongside the design work.
Impact
Comparing equivalent thirty-day windows either side of release, with the same organisations in both:
- 60 of 68 users who reached a scored summary opened at least one explanation, and they opened around ten each.
- Shares rose from 4 to 28. As a proportion of scored users, sharing went from 13% to 41%.
- Exports rose from 20 to 56. As a proportion of scored users, exporting went from 63% to 82%.
- Scored summaries rose from 32 to 68.
The number of people reaching a scored summary doubled, but that isn't all down to the feature. We ran more sales demos during the same period, and I joined them to show Limiting Factors to customers. That's why I measure the feature by what scored users did next. Sharing and exporting both rose as a proportion of scored users, which the extra demo traffic alone wouldn't explain.
The problem
During a customer call, a global consultancy told us they had run around thirty scorecards to shortlist projects for a procurement exercise. The tool was useful enough to run thirty times. Their complaint was that it never said why a project scored A rather than B. They had been working it out by changing answers and watching the score move.
In April, a portfolio manager at a European bank described the same problem from the other side. Her team used the scorecard for an annual review of the projects they held. Their process needs a second reviewer to sign off her work, so both of them had to understand why a project scored the way it did. All she got at the end was a PDF with a grade on it.
Export and share are the two moments where a score leaves the tool and enters a real decision. Customers couldn't explain their scores to their teams, so most of them didn't share them. Without knowing how scores were calculated, they lost trust in the score itself. Instead of moving them towards buying a full rating, the scorecard left them confused. They contacted customer success to ask analysts for explanations, which wasted their time and pulled the ratings team away from their own work.
Finding a solution
The challenge was to explain the score without undermining the value of a full rating. Customers needed to understand their score. They didn't need all of the analysis a rating provides.
I worked with the engineer and the ratings analysts to see what we could extract from the existing data. The scoring engine could already test every answered question against its strongest possible answer. That gave us the basis for the feature. For each risk factor, the engine identifies the questions where a better answer would lift the grade and ranks them by impact. If a user's answer earned a B, the tool could show which alternative answer would earn an A.
The explanation for each factor is written by an LLM (large language model). It draws on sector rationale written by the analysts, so the content comes from BeZero's methodology rather than general knowledge. I spent a lot of time on prompt iteration. Each explanation had to say why the current answer scored as it did and why a stronger answer would score better. Our users ranged from technical analysts to procurement leads, so the language had to be clear without leaning on AI or methodology jargon.
I set a bar for what counts as a limiting factor. A question only appears if a stronger answer would actually change the risk factor's grade. An improvement that doesn't change the letter is noise in a list whose job is to tell people what to look at first. That threshold controls the length of the list, rather than a fixed number of rows.
The feature also had to work for people who never create a scorecard. Many customers only use BeZero's own scorecards, and they can't change the answers. For them the value is understanding why a project scored as it did. Each explanation had to make sense on its own without assuming the reader could act on it.
Prototyping against real data
BeZero scorecards live in a GitHub repository, along with the analysts' answers and the sector rationale behind them. I pulled the repository, ran it locally and built the component against real content using Claude Code and Storybook. That meant working with real forestry projects, real analyst answers and real explanation text.
I planned discovery in Figma, but prototyping with real data let me open any project and see what the component actually produced. I could change the pattern and check it again within minutes. This surfaced edge cases nobody had specified and engineering had no reason to anticipate.
One project already had the highest possible score, so there was nothing to list. It rendered as an empty space that looked like the page had failed to load. I replaced it with a positive line telling the user the risk factor is already at its highest score.
Another project returned six limiting factors under one risk factor, and the list ran off the bottom of the screen. I collapsed each factor to a single sentence and moved the detail behind a control.
Some answers weren't a straight swap. On multi-select questions the stronger answer adds options to the ones already ticked, so I wrote those rows as additions rather than replacements.
What shipped
The feature is called Limiting Factors. It sits alongside the project's score and shipped sector by sector, starting with two sectors in July and reaching all nine over the next seven weeks.
Each risk factor lists what is holding its score back, ranked by impact. Each row has a thin border in its risk factor's colour so users can see which risk factor it belongs to. Every factor is one plain sentence, and the senior analysts for that sector review it before it goes live. Selecting more detail shows the current answer, the stronger answer and what the change would do to the grade.
What changed
Covering product management meant I joined sales calls, which is where most of this feedback came from.
What customers said was mostly about their own workflow rather than the feature itself. An advisory team who screen projects before passing them to their internal analysts said it was exactly what they needed for the quick read. That's the "take a look at this and give me an overview" request, rather than the full deep dive that comes later.
On a call with a Brazilian forestry developer, the tool flagged that his project issued credits every five years and that annual issuance would score better. He said it was information he could work with, then explained he had already moved to annual reporting for other reasons. The loop the feature was built for closed within a single call.
The comment I didn't expect came from a developer who said the section looked like the structured risk feedback table in BeZero's full analyst ratings. A self-serve tool being compared to a product that costs many times more is a fair summary of what I was aiming for. The consultancy who raised the problem in January saw it in July. They complimented its rigour and asked us to keep adding more context.
What's next
Limiting Factors only shows what holds a score back. I'd like to extend it to show where a project is already strong. I haven't built that yet because I can't validate its value without another round of user research and discovery.
Customer organisations are anonymised and usage figures have been scaled to keep the customer base commercially non-identifying. Proportions and relative changes are as measured.