Overview
I designed an online portal for a carbon ratings agency to replace the emails and shared folders its customers relied on while their projects were rated. The first release went live as a beta in May 2026.
Companies buy carbon credits to make up for their own emissions. Each credit is meant to stand for one tonne of carbon dioxide kept out of the atmosphere, but some projects deliver far less than they claim. The agency assesses the projects behind the credits and grades them on a letter scale, much as a credit rating agency grades a bond.
To get a rating, the customer hands over the project's documents, analysts spend around six weeks on them, and the customer receives a report.
Every rating now runs through the portal, with more than 50 so far. Customers who used to handle everything by email now log in several times a month, and their engagement with the platform rose by 35%.
The problem
Once customers had paid for a rating, they had no way of seeing what happened to it. The whole process ran over email, a shared SharePoint folder and an Excel sheet listing the information the agency needed. Early research found customers sending more than ten emails per project just to ask how it was going.
A rating moves through seven stages, starting with a signed contract and an introductory call. The customer then hands over documents, the agency checks they are complete, analysts do the assessment and the customer receives a draft report with two weeks to respond.
Customers had no view of any of these stages, so they only found out which documents were missing when the draft report arrived. By that point any change cost both the agency and the customer extra time and money.
Inside the agency the lack of a shared view caused a different set of problems. Sales handed each new rating to the onboarding team by email, and documents had to sync between SharePoint and Google Drive with occasional failures. Analysts started work before all the information was in around 90% of the time and chased the rest by email.
Ratings operations had run the process themselves before the product team got involved, so I built the map by asking the internal teams what actually happened at each stage. It covers eight roles, from sales and legal through to ratings operations, the analysts and the geospatial team. For the customer I mapped, there were 13 separate email touchpoints between a signed contract and a delivered report, and the number varied from project to project. Handing over documents was meant to take one to three weeks and often ran longer.
The first release replaced the shared folder and the email sign-off, but questions still ran over email.
Why it mattered commercially
A rating used to be a one-off transaction, where the customer paid, received a PDF and had no reason to come back.
Running the process inside the agency's subscription platform gave customers a reason to log in, along with free access to the rest of the platform. The rating could then become a route into a subscription.
There was also an operational case, since every status email a customer no longer needed to send gave time back to onboarding and the analysts.
Who I designed for
The primary user was a technical consultant preparing a biochar project for a rating. Biochar is charcoal made from plant waste and buried so the carbon stays locked away. The consultant works for the project developer, the company that runs the project on the ground.
They had five to ten large files to hand over, including a project design document explaining how the project works, a financial model and map files showing the project's boundary. They had answered the required questions and wanted to know when the report would be ready.
The worst case for this person was what the project brief called the silent delay. They believe they are in week four of a six-week analysis, when in fact an analyst has been stuck on a corrupted map file for a fortnight and nobody has told them.
Defining how it should feel
Before designing screens I defined how the customer should feel at each stage. A rating is expensive and slow, and it means handing sensitive documents to an outside company. The brief for the experience had to deal with that directly.
| Pillar | The customer should feel | What the design does |
|---|---|---|
| Visibility | Informed and in control | Status is always shown, even when nothing has changed, because silence reads as a problem. |
| Trust | Safe and respected | Trust has to be earned before the first upload, so the interface says who can see each document. |
| Guided | Clear on what to do next | The portal replaces the person who used to explain the process, so every step says what happens next. |
| Arrival | Accomplished | Receiving the final report should feel like an event rather than a file download. |
The trust pillar changed the most between drafts, because the first version treated it as general confidence in the system. Customers already shared sensitive material such as financial models and land records through SharePoint, a tool they knew. The portal asked them to hand the same documents to the agency's own platform instead, so I rewrote the pillar around earning trust for that switch. The guided pillar came from the same thinking, because customers were used to someone walking them through the process on a call, and a form alone would not replace that.
Before designing any screens, I mapped what the customer needed to hear at each stage.
What I built
The first release covered the stage where customers hand over their documents. The journey map showed it caused more trouble than any other stage. Customers had to supply the right information and also fill in the Excel sheet in the format internal teams needed. Every gap meant another round of emails, so we started there and planned to fit the other stages around it.
Mapping this stage showed that its internal name, data collection, did not match what customers actually did. They uploaded documents and filled in a sheet saying where each answer could be found, and the analysts extracted the data themselves. The portal follows that model, so customers point to the evidence in their documents instead of retyping it.
Each type of rating had its own separate process, so we focused on the one the agency ran most often.
The beta had to solve a real pain point and still reach customers quickly. The minimum set let customers upload documents, answer questions, point to where an answer sits in a document and see where their rating was. Contracting stayed out of scope, so the portal picks customers up just before their introductory call.
The data model had to change before the interface could, because the company used the word project for several different things. The team separated the project, meaning the forest or farm itself, from the assessment, meaning one piece of rating work on it. One project can now hold several assessments for several customers.
In the portal, customers see all their rating requests in one list, and each request opens onto a requirements list split into mandatory and recommended items. They upload documents against each requirement and mark items as not applicable where they don't fit. Progress saves as they go, and they submit when they're ready.
Mandatory items are the information the agency cannot produce a credible rating without. Recommended items make parts of the assessment more accurate, but the rating can go ahead without them. Splitting the list showed customers where to put their effort first.
Each requirement explains what is needed, how the agency uses it and what risk a gap creates. Completed items show the customer's reference, such as a page number, instead of retyped data.
I built the test prototype in Lovable so participants could click through real interactions rather than static frames.
Once features were heading into production, I prototyped them in code with Claude Code instead of handing over static designs.
Testing
Throughout the project I asked ratings operations to review each prototype. They worked with customers every day, so they could spot where a screen didn't match how customers thought about the process.
Before customer testing I ran an internal review with the people who would use the portal every day. They sorted their feedback into what worked, what to change and what they were unsure about. The review shaped the timeline itself, including how many steps it showed and whether stages such as the draft report needed a place of their own. The most useful comment was that the portal felt like a completely different space from the rest of the agency's platform. That mattered because the portal's commercial job is to lead customers into the wider platform.
I ran moderated usability tests with three participants against 19 hypotheses about how the portal would be understood. All three completed both tasks without getting lost, so the problems sat in what the interface implied rather than in the flow itself.
Nobody could tell who the listed team members were. None identified them as the agency's analysts, and one assumed they were colleagues from his own company. (3 of 3)
The team now sits at the top of the portal. Customers see their account manager first, then who is working on each part of their report.
All three said they would skip the guides and go straight to uploading documents. (3 of 3)
The guide now sits on the project page from the moment customers get access, so they can see what will happen before they start. It used to be lost in email threads.
Smaller fixes covered how projects were sorted, the label on the upload button, a confirmation when progress saves and the spacing of the "not applicable" option.
The team finding mattered most because it was a trust failure. Customers want to know which people at the agency are handling their documents. The interface showed their names without roles, which told customers nothing about who was looking at their files.
Updating the design system
During this phase I also refined the design system. I took the components the platform already used and rebuilt them on shadcn/ui, an open-source library of interface components, and Tailwind CSS, a framework for styling them in code. The aim was a more polished, tech-focused interface with every screen built from the same components.
The second reason for moving to shadcn/ui was speed, because with the components in code, designers can make changes and ship them to production themselves. The old system had grown by adding a new component for each new need. We wanted a consistent set the team could reuse instead of designing something new every time.
I designed the refinements in Figma first. I then used Claude Code to work through the existing design system and build the refined version in code.
The biggest changes were to buttons and to how information was laid out. Screens became less dense, with more white space and a more considered layout.
I also added a component the platform never had before. It is a clickable timeline that walks customers through each stage of their rating and shows where they are now.
The refinement was also a response to the internal review comment that the portal felt like a different space from the rest of the platform. Building both from the same components brought them visibly closer together.
The tooltip is a typical example: the old version came in six variants built from two nested parts, with a large arrow and generous padding. The refined one has a single property for which side it opens on, takes its colours from theme tokens and matches the coded component exactly.
Outcome
Every assessment now runs through the portal, with more than 50 so far. Customers who used to handle everything by email rarely visited the platform, often once every six months while a rating was under way. Once they used the portal they logged in several times a month, and engagement from that group rose by 35%. Those regular visits also led them into other parts of the platform.
After the beta I mapped the full journey against what the portal covered. Handing over documents now happened in the portal, but the checks, the analysis and the draft report were still invisible to the customer. The final report also still arrived as a PDF by email. That map set the next round of work: guidance before customers start uploading, visible status during analysis, and analysts requesting extra documents inside the portal instead of by email.
One decision from this round was not to show the draft report in the portal yet. A summary of the rating built into the platform itself was due to follow shortly, and a temporary view would have been thrown away.
The full blueprint covers what the customer sees, what the portal shows, what happens internally and a proposed fix for each gap. The summary below pulls out the customer's view.
What didn't work
The first release covered the middle of the customer's journey and left the stages either side of it unchanged. Handing over documents was the most painful stage and the beta was scoped to ship quickly, so starting there was a deliberate choice. The side effect was that a customer could submit everything in the portal and then go back to waiting with no news, which is the silent delay the project set out to remove.
Permissions turned out to be harder than expected, because each person in ratings operations needed exactly the right level of access. The agency also keeps an ethical wall, a rule that keeps certain information away from people whose role could create a conflict of interest. Sales could not see some documents that analysts worked with, and some confidential material was for analysts only. New permission cases kept appearing as more people used the portal, so we added rules as we went.
Internal adoption was also slower than I expected, because the teams involved weren't used to working in a technical tool. We shipped changes continuously while they were still learning it, which gave us constant feedback but also some teething problems. Regular communication with those teams became part of the work.