Arbnco - Synthetic Data Switch
Clearer ways to trust synthetic hourly energy data, and to turn it on across the platform.
- UI design
- Service Design
- Product Design
Summary
I was the design lead on a short squad sprint to make synthetic hourly data trustworthy.
Eligibility visible before users turn data on
One status pattern PM and engineering shared
Journey map to implementation in 3–4 weeks
Product goal
Help energy teams get hourly carbon insights from machine-learning estimates they could understand and trust.
User problem
Monthly meter readings were too coarse for the hourly carbon insights teams needed. Without finer data, they could not see or act on hourly patterns.
Team
We were a squad with a product manager and engineers. They owned what was technically possible, and I led the design and handoff.
What I owned
I led the UI/UX work end to end, from the journey map and wireframes through to the prototype, design reviews, and engineering handoff.
Methods & skills
Rough share of my effort- Service design15%
- Journey mapping15%
- UI design30%
- Prototyping25%
- Design reviews15%
Challenge
The business needed finer data, and users needed clarity they could trust.
Teams needed hourly carbon data, but most meters only reported once a month.
Generated hourly data could fill those gaps, but only if people could tell when estimates were running and trust the numbers behind them.
Design principles
Users need to know when generated data is being used, not just that a toggle exists
Original low-frequency readings still need to feel accessible and reliable alongside generated data
Plain-language messaging matters, so the feature never feels technical or alarming.
My role
This was a squad sprint: the team owned scope and feasibility, and I led the design.
What we did together
- The PM and engineering set the ML rules, sprint scope, and what could ship.
- In design reviews we shared our flows and reasoning, and the squad agreed which screens to build first.
What I owned
- We mapped where synthetic data fit, then focused on the project list and settings where trust is decided.
- We updated graphs, tables, and reports with plain labels instead of ML jargon, to reassure users.
- We ran design reviews and wrote handoff specs for eligibility and status tags, so engineering had one pattern.
Our journey map helped the team agree where users needed clarity before anyone opened Figma. That cut rework when eligibility rules changed late in the sprint.
Timeline
3 to 4 weeks from journey map to engineering handoff, with me leading design throughout.
Over a squad sprint with PM and engineering, I mapped the journey, designed the flows, and handed off specs, while the squad worked out what could ship.
My involvementWithout my involvement
Wk 1
Wk 2
Wk 3
Wk 4
DiscoveryDiscoveryJourney mappingSquad alignment
Journey mapping
Journey mappingMapped the energy team's end-to-end data journey.Squad alignment
Squad alignmentAligned with PM and engineers on what could ship.
DesignDesignWireframes & UIDesign reviews
Wireframes & UI
Wireframes & UIDesigned flows for eligibility and data status.Design reviews
Design reviewsReviewed designs with the squad for feasibility.
Prototype & handoffPrototype & handoffHigh-fidelity prototypeDesign reviewEngineering handoff
High-fidelity prototype
High-fidelity prototypeBuilt a clickable prototype for deeper exploration.Design review
Design reviewWalked the squad through the prototype.Engineering handoff
Engineering handoffHanded off flows, states, and specs to engineering.
Design
Quick exploration with the team, then refinement through review and prototype.
Approach
- Mapped where synthetic data affected the existing journey before moving into screens
- Used established patterns to move quickly, adding plain-language labels where users needed reassurance
- Focused on the project list and settings, where users decided whether to trust generated data
AI tools helped explore ideas. Nothing shipped without review.
Journey map
Where synthetic data fit in the existing platform journey, agreed with the squad before anyone opened screens.
Scan the portfolio
User
Compare data resolution across buildings before turning hourly estimates on.
Design
Resolution column on the project list plus All, Synthetic, and Mixed filter chips.
In prototype
List view shows coverage at a glance. Users spot gaps without opening each project.
Spot eligibilityFriction
User
See which buildings have enough readings for ML hourly estimates.
Eligibility rules only surfaced inside project settings, so blockers were easy to miss.
Design
Colour-coded chips on every row. Mixed means eligible, High means insufficient data, Synthetic means already on.
In prototype
Mixed and High are visible on the list, so users no longer discover blockers only after clicking through.
Enable one building
User
Turn synthetic data on for a single project from Edit Project settings.
Design
Dedicated toggle with plain-language copy and a first-visit tooltip explaining what estimates unlock.
In prototype
Toggle uses a green active border and helper text. The tooltip dismisses after the first read.
1–3 of 8
Initial prototype
Figma Make exploration we walked through in design review, covering the project list, eligibility, and synthetic data flows.
Design review insights
What changed after PM and engineering pushed back on the first flows.
Save had to feel deliberate, so project info only saved when users clicked Save.
We grouped building details by eligibility impact so users saw what blocked generated data.
We added complete, partial, and incomplete status tags before users committed to generated data.
Interactive prototype
Built prototype for deeper exploration across the project list, building settings, and synthetic hourly data.
Solution
From project list to confirmed generated-data state.
Example of bulk enable across projects
Checkbox selection and synthesise/revert actions for managing multiple projects at once.
Example of Edit Project settings
Toggle, status badge, and checklist make eligibility and active state visible in context.
Limitations
Working within real product and engineering constraints, not a blank canvas.
- With no time for new research, I relied on existing journey knowledge and design-review feedback.
- Fixed technical limits shaped what could ship in the sprint window.
- Because the platform structure predated this sprint, I couldn't move where features lived and had to explain eligibility within the existing layout.
Key takeaways
What making complex data legible reinforced, and what I'd apply to the next technical product.
- Complex technical features need simple, trustworthy UI, especially when they change how people read their data.
- Clear status tags, labels, and tooltips helped users see what was available, what was missing, and what to do next.
Open to new opportunities
I'm actively looking for UX/UI design roles. If my work resonates, I'd love to hear from you.