Add the right data
Keep the category, template and upload together.
Turning a Scope 3 dashboard into an operational data workflow.
I led the design and contributed frontend implementation for Oren’s new Scope 3 data workflow. It connected category-based upload, failed-row correction and available calculation detail in one production path.
The result in sixty seconds
The dashboard became a working route into Scope 3 data collection.
Matched 130-day windows around the 14 May 2026 release show a clear change in behaviour. The strongest evidence belongs to bringing data in; recovery and explanation have narrower proof.
- Bring data in
- 16.2% → 81.5%
- Client dashboard users who reached upload: 6 of 37 before launch; 22 of 27 after.
- Bring data in
- 8 of 11
- Uploading client organisations repeated upload activity in another month.
- Explain the result
- 12 of 27
- Client users opened a result group or method detail. Comprehension was not tested.
Route visits and interactions were measured. Successful processing, resolved errors and calculation comprehension were not. See each goal against its evidence →
01 · Who it’s for
Sustainability teams preparing an emissions report.
They bring together business data from spreadsheets, fix errors and explain the numbers in their report. They need to see which files are ready and which still need attention.
Scope 3, in plain terms: emissions across a company’s wider value chain, including the goods it buys, their transport and the use of products it sells.
02 · The design brief
The brief: upload data, fix errors, explain the total.
Four needs shaped the design. Teams had to bring data in, fix it and understand the result without losing their place.
Fix errors in place
Edit failed cells in a spreadsheet. Save the fixes together.
Know what happens next
Show upload status and a clear retry action.
Explain the reported total
Connect the total to its records and method names.
Designed for bulk Excel or API data, with a requirement of up to 10 million rows. Background processing status and full calculation history did not ship.
The brief came down to three jobs.
03 · The journey
From uploading a file to checking its result.
I reviewed the brief and calculation logic, then worked through the upload and reporting flows. The difficult joins were returning to files, fixing part of a dataset and handling dependent uploads. Each needed a clear next action.
Prepare the right data
Choose category Get template
What does this category need?
Keep category guidance and the correct template together.
Upload and work through errors
Upload file Correct failed cells
Which data worked, and what needs fixing?
Separate processed rows from errors; correct and save without leaving the file.
Check and explain the result
Review health Inspect calculation
Can I account for this number?
Connect the category total to groups, items and available method detail.
04 · The design
Three principles kept the decisions consistent.
Recognition over recall
Keep the category, template and file status in view. Do not make people remember where their data belongs.
Error prevention and recovery
Protect valid data, explain failed cells and make it safe to leave with unsaved changes.
Progressive disclosure
Start with the overview. Reveal groups, source data and calculation detail as the user goes deeper.
Keep uploads inside their category.
I kept upload and file management attached to the selected category. The upload action opens a dedicated view with that category already selected. Users can get its template, add a file and return to their files without choosing the category again.
Transport needed an exception: trade flows must arrive before shipments. I kept the same upload and correction pattern, adding the dependency rather than another workflow to learn.
Keep context attached to the work.
Start from the category
Upload with the category already selected
Then manage the uploaded file
- First fileTrade flows
Establish the IDs that shipments refer to.
- Second fileShipments
Unlock after trade flows are available.
Fix failed rows without losing the good data.
A file can contain both useful data and invalid rows. The editor shows failed rows only, protects clean cells and explains each error in place. A summary accounts for processed rows, so they do not seem lost.
Per-row saving would add repeated waits at scale. I used one batch Save action and unsaved-change protection. Offline corrections remained an option, returning to the same editor.
Preserve good data; focus attention on what needs repair.
Find what needs fixing
Only failed rows appear in the editor. Valid data stays protected.
Open full-size screen
Make the corrections together
Edit several cells, then use one Save action. The floating bar keeps pending changes visible.
Open full-size screen
See that the file is ready
The saved state confirms that corrections have been processed.
Open full-size screen
Show how each number was calculated.
The calculation rules came from the brief. Reviewing the logic corrected an early interpretation: A, B, C and D named methods, not data-health grades. I replaced those codes with full names and kept health separate.
Category, group and item views reveal progressively more detail. But the database did not retain every calculation step. Partial detail shipped; a complete audit history needed backend work, not just a more detailed drawer.
Explain what the system knows, without implying evidence it does not store.
Why four levels?
The brief specified this hierarchy. Each level narrows the question, from a reporting overview to the evidence behind one record. I made the depth purposeful through the content and actions at each step.
- Dashboard
What needs attention?
Compare categories and their status.
- Category
Where are these emissions coming from?
See its total, groups and uploaded files.
- Group
Which records contribute?
Inspect a smaller set of related line items.
- Item
How was this record calculated?
See its input and available method detail.
Reporting detail follows this hierarchy. Uploading and correcting files remain available from the category.
Six edge cases, with a clear way forward.
Edge cases were part of the workflow, not separate error screens added at the end.
Processed rowsProtected
Failed cellsEditable
CorrectionsSave as a batch
Some rows pass. Others need help.
Keep processed data safe while failed cells stay editable. A partial correction leaves the remaining errors available to fix.
Category templateAdd the first file
An empty category needs a starting point.
Offer its template and upload action in context, before any data exists.
.xlsx.csv
The file format is wrong.
Explain which formats are supported before the user tries again.
Upload failed
The upload fails.
Show a failure state with a clear retry path, not an indefinite loading state.
Possible duplicate
ReplaceCancel
A file may already exist.
Ask for confirmation before replacing it. Keep cancellation available.
Unsaved changes
SaveDiscardCancel
The user leaves with unsaved edits.
Offer save, discard or cancel before navigation loses their changes.
Documented design behaviour. These diagrams explain the states; they are not product screenshots.
05 · What shipped
I carried the design through to production.
I documented ten flows, reviewed the build and implemented production frontend changes: category upload, inline editing and sequential-upload gating. Engineering led the backend and wider implementation. The workflow shipped in May, with further refinements in June.
Design review: put the work first
The audits challenged repeated summary, guidance and navigation elements. I simplified these instead of adding more explanations around them.
Implementation review: protect the real task
I flagged clipped dashboard content and duplicated headings and guidance. I retained engineering’s keyboard-accessible rows, loading states and retry handling.
How review changed the design
Three major refinements show what changed and why. Five smaller changes follow.
Three summary cards
one strip
Keep the total and its split visible without pushing the category table down.
Separate resume card
category-level status
Remove a second list of categories already present below.
Welcome card
six-slide, reopenable guide
Explain one idea at a time and retain help after the first upload.
Multiple dashboard views
one table
Prioritise comparing and acting on category data. The table-only refinement reached production in June.
Duplicate category navigation
one category list
Keep one route into the same work.
What the launch did not yet cover
Six of fifteen categories were supported at launch; the rest were marked unsupported, not ‘not applicable’. N/A justifications needed stored reasons. Background upload status remained in the design, not in production.
06 · Results
Three goals. Three different levels of evidence.
The live product strongly supports the first goal, shows use of the second, and leaves the third only partly evidenced. The distinction matters: route visits and clicks do not prove successful processing or comprehension.
More clients reached the upload step.
Matched 130-day windows · Reaching upload measures progression, not successful processing.
Uploading organisations came back.
8 of 11
Uploading organisations uploaded in more than one month.
Each block represents one organisation · Client-only production activity.
Bring data in
Add category data and return for the next reporting period.
What the evidence shows
- 16.2% → 81.5%
- client dashboard users who reached upload
- 8 of 11
- uploading client organisations active in multiple months
Strong behavioural evidence
Six of 37 client users reached upload before launch; 22 of 27 did after. Most organisations with upload activity repeated it in another month. This measures reaching and using the workflow, not a successfully processed file.
What would prove it
Track upload outcome, rows accepted and rows rejected, then separate client work from assisted delivery.
Recover from errors
Correct invalid data inside the product, with the file still in context.
What the evidence shows
- 23
- production users used editor Save
- 171
- editor Save clicks across all production traffic
Usage evidence
People used the in-product editor after the old offline repair loop was removed. These figures include client and internal production traffic, and a Save click does not prove that every failed row was resolved.
What would prove it
Track corrected rows, remaining errors and whether the file returns to a valid processing state.
Explain the result
Follow an emissions total down to the data and method behind it.
What the evidence shows
- 12 of 27
- client users opened a result group or method detail
Partial evidence
Clients explored the result hierarchy, but the product did not record calculation success and no comprehension study was run. The database also lacked the full history needed for complete traceability.
What would prove it
Store calculation history, emit a calculation-ready event and test whether users can explain a record from source to total.
Conversion, repeated upload activity and result exploration use client-only production and tenant data; staff, QA and test accounts are excluded. Editor Save figures cover all production traffic and are labelled separately. Samples are small. The matched pre/post comparison shows observed behaviour, not an A/B test or proof of causation.
07 · Next steps
Next: measure completion and protect interrupted work.
Clicks show use; they do not show whether the task was completed. I would check saved processing records to measure successful uploads and corrections. Two observed friction points would guide the next design tests.
What I learned: the report is only half the job.
I connected collection, correction and explanation, and carried that design into production. Live behaviour strongly supports the move from dashboard to upload, while recovery and explanation still need outcome-level instrumentation. The next test is whether files finish processing, failed rows are resolved and teams can account for the resulting numbers.
