Brightly ESPM - Astha Dhami

Overview

Sustainability managers using Streams were spending 2–3 hours weekly on manual configuration to get data to and from ENERGY STAR.

They needed to connect their buildings to ENERGY STAR to track energy performance scores, sync utility data, and maintain consistent records across both systems.

This connection didn't exist in a way users could control themselves. It required manual intervention, technical workarounds, and offered no visibility into whether the sync had worked or failed.

What I set out to do

Map the end-to-end workflow across user types (sustainability managers, building managers, implementation partners)
Design a solution that reduced setup time, surfaced sync status clearly, and required no hand-holding

Desk Research

Before designing the flow, I needed to genuinely understand how the benchmarking platform worked. I spent time going through ENERGY STAR's documentation and working through the platform myself to understand:

How accounts, buildings, and meters were structured
What a Client ID vs a Building ID actually represented
How data sharing between accounts worked
What the API could and couldn't do

Competitive Analysis

In the introductory stakeholder meeting, I asked directly: who is your biggest competitor, or who represents the ideal state you're trying to reach? The answer was Measurbl.

I used that as my benchmark. I mapped four key flows in Measurbl to understand how they handled similar complexity:

Adding sites
Connecting to the benchmarking platform
Adding a meter
Site sync status views

I found out that Measurbl had solved the problem of making data configuration feel manageable for non-technical users through clear step-by-step flows, explicit status indicators, and sensible defaults.

Measurbl's interface (left) organizes around portfolio entities. Stream organizes around system functions. These are fundamentally different mental models and understanding that gap shaped our IA decisions.

User Persona

We defined a user persona to guide our design decisions

Strategy

Through research and stakeholder alignment, I identified four distinct user scenarios that the feature had to accommodate, each with a fundamentally different starting point:

Scenario 1

New to Stream, no benchmarking account

User needs to be guided to create an account first, then build out their data in Stream, then push it across and enable automatic sync.

Scenario 2

New to Stream, has an existing benchmarking account

User links their existing account, shares properties, and imports building data — which syncs automatically within a day or two. They can also trigger an immediate refresh.

Scenario 3

Has buildings in Stream, not in the benchmarking platform

User creates their benchmarking account, adds the platform as a contact, links the integration, then shares sites and meters with appropriate access levels.

Scenario 4

Has buildings in both systems, not yet synced

The most complex scenario. Requires account-level connection first, followed by building matching — automated suggestions where possible, manual matching where not — then sync configuration per data type.

How might we

Before moving into flows, I framed the design challenge as a set of HMW questions to guide decision-making across all four scenarios:

HMW help Rob link Stream buildings to benchmarking platform buildings without requiring him to understand the underlying account structure?

HMW make sync direction controls — push, pull, two-way — feel intuitive for someone who thinks in terms of data accuracy, not data architecture?
HMW give Rob real visibility into sync status so he can trust the data without manually cross-referencing two platforms?
HMW surface errors in plain language so Rob can act on them himself, without filing a support ticket?
HMW accommodate four fundamentally different starting points within a single coherent feature?

User Flows

I mapped all four scenarios as user flows before touching a wireframe, because the branching logic had to be resolved at the flow level first. Key decision points across the flows:

Account exists vs. doesn't exist → branches the entire setup path
Buildings matched vs. unmatched → determines whether automated suggestions surface or manual entry is required
Data type selection → Spaces (two-way sync possible), Utilities (push or pull only), Energy Score (always pulled, never pushed)
Sync status → error states, success states, and the overnight delay constraint

Four user flows mapped across distinct starting points — from "no account in either system" to "buildings exist in both but aren't synced." Resolving the branching logic at this stage prevented rework at the wireframe level.
view the user flows on figma.

Design

With the user flows resolved across all four scenarios, I moved into wireframes and then high-fidelity design within Brightly's existing design system.

The three core screens I designed were: the ESPM Configuration page, the Meter Sync side sheet, and the Site Sync Settings side sheet. Each solved a distinct part of Rob's problem.

ESPM Configuration Page

The entry point for the entire feature — a table view showing all connected sites alongside their energy performance scores, certification status, validation status, permission levels, and property data. This screen had to answer Rob's most immediate question at a glance: which of my buildings are connected, and are they in good shape?

Key design decisions:

Tooltips on ambiguous columns so Rob could act without needing documentation
Colour-coded ES Score column for quick status scanning without reading every row
Permission level visible per site, critical for multi-user admin environments
Tags indicating site relationships (complex vs. standalone buildings) surfaced inline

Meter Sync Side Sheet

Once a site is selected, this sheet gives Rob control over how individual meters sync.

Meters are grouped into three categories: meters used to compute metrics, meters not used to compute metrics, and IT meters used for data centre calculations. For each meter, Rob can see the account number, type, ESPM Meter ID, units, sync direction, last sync date, last sync status, and whether it's an aggregate meter.

Key design decisions:

"Sync with ESPM" button positioned on the right, a direct response to usability testing where both testers independently gravitated to that position based on muscle memory from other tools
Meter Sync tab surfaces first — testing showed users navigated here immediately; leading with it reduced disorientation
5 meters visible by default rather than 4, a small change that reduced the need to scroll for the most common portfolio sizes
Tooltips added to ESPM Meter ID, Sync Direction, and Aggregate Meter columns — the three that caused the most confusion during testing

Test

We prototyped the flows and ran usability testing with internal users. Testing revealed several critical issues that led to meaningful design revisions:

What we found

01 Navigation and labelling were causing confusion

The tab label "Site Data Sync" wasn't landing, users suggested renaming it to "Settings," which better matched their mental model

Tags showing building relationships (complex vs. standalone) were unclear — users couldn't interpret them without explanation
"Historical Spaces" as a label confused users; they responded better to "Inactive Spaces."

02 Interaction patterns weren't matching user expectations

Both testers independently preferred the sync button on the right side — a muscle memory pattern from tools they already used

Users wanted the Meter sync tab to appear first, since that was their immediate priority when entering the screen
The number of visible meters (4) felt too few — users wanted to see 5 at a glance before scrolling

03 Status visibility needed more at-a-glance clarity

The ES Score column worked well conceptually, but users wanted colour coding to quickly identify sync status without reading individual entries

Error messaging needed more context and a downloadable error list for situations where multiple records failed, important for Rob's auditing workflow
Users wanted "last synced by" information visible, knowing who triggered a sync matters in a multi-user admin environment

View the detailed testing notes here.

What Changed

Empowered 100+ sustainability managers with direct control over their data synchronization
Delivered 14 user stories across 3 major initiatives
Eliminated the cross-platform mismatch problem by designing a clear sync state model with a defined source of truth per data type

Before

2–3 hours per manual configuration

Required support team intervention

No sync status visibility.

No control over data direction

After

Under 15 minutes

Full self Serve

Real-time status with plain-language error messages

Per-data-type sync configuration

Learnings

Embracing Change: Don’t Get Attached to Every Design

Early on, I learned that it’s perfectly normal for some designs to get descoped or set aside. Rather than taking this personally, I recognized that design decisions are driven by business needs and changing priorities. Maintaining flexibility and focusing on the project’s broader goals allowed me to grow as a resilient and strategic designer.

Adapting to Constraints: Prioritizing What Matters Most

Projects often move fast and sometimes limited budgets and tight timelines mean that not every step can be executed as planned. For example, after initial user testing and implementing feedback, we didn’t have the bandwidth for a second round of formal testing. To ensure some level of insight, I guided a fresh team member through the new designs, asking them to evaluate the experience from a user’s perspective. It wasn’t perfect—but was a practical solution given our constraints.

Knowing When to Push Back: Advocating for Users

It’s important to adapt, but sometimes you have to stand your ground, even under pressure. On one project, internal process stakeholders had already reviewed our UI, and tight deadlines made skipping further user testing tempting. My team and I insisted on a quick round of testing with end users, balancing project urgency with the need for real feedback. This approach ensured our designs genuinely met user needs before launch.

Designing for Complexity Means Designing for Trust

The hardest part of this feature was making a technically complex data relationship feel safe to configure. Users like Rob aren't afraid of complexity, but of making a mistake they can't trace or undo. My goal was giving users enough visibility and control that they could act with confidence. That's a design principle I'll carry into every data-heavy product I work on.

My desk & some appreciations

Overview

Sustainability managers using Streams were spending 2–3 hours weekly on manual configuration to get data to and from ENERGY STAR.

They needed to connect their buildings to ENERGY STAR to track energy performance scores, sync utility data, and maintain consistent records across both systems.

This connection didn't exist in a way users could control themselves. It required manual intervention, technical workarounds, and offered no visibility into whether the sync had worked or failed.

What I set out to do

Map the end-to-end workflow across user types (sustainability managers, building managers, implementation partners)
Design a solution that reduced setup time, surfaced sync status clearly, and required no hand-holding

Desk Research

Before designing the flow, I needed to genuinely understand how the benchmarking platform worked. I spent time going through ENERGY STAR's documentation and working through the platform myself to understand:

How accounts, buildings, and meters were structured
What a Client ID vs a Building ID actually represented
How data sharing between accounts worked
What the API could and couldn't do

Competitive Analysis

In the introductory stakeholder meeting, I asked directly: who is your biggest competitor, or who represents the ideal state you're trying to reach? The answer was Measurbl.

I used that as my benchmark. I mapped four key flows in Measurbl to understand how they handled similar complexity:

Adding sites
Connecting to the benchmarking platform
Adding a meter
Site sync status views

I found out that Measurbl had solved the problem of making data configuration feel manageable for non-technical users through clear step-by-step flows, explicit status indicators, and sensible defaults.

Measurbl's interface (left) organizes around portfolio entities. Stream organizes around system functions. These are fundamentally different mental models and understanding that gap shaped our IA decisions.

User Persona

We defined a user persona to guide our design decisions

Strategy

Through research and stakeholder alignment, I identified four distinct user scenarios that the feature had to accommodate, each with a fundamentally different starting point:

Scenario 1

New to Stream, no benchmarking account

User needs to be guided to create an account first, then build out their data in Stream, then push it across and enable automatic sync.

Scenario 2

New to Stream, has an existing benchmarking account

User links their existing account, shares properties, and imports building data — which syncs automatically within a day or two. They can also trigger an immediate refresh.

Scenario 3

Has buildings in Stream, not in the benchmarking platform

User creates their benchmarking account, adds the platform as a contact, links the integration, then shares sites and meters with appropriate access levels.

Scenario 4

Has buildings in both systems, not yet synced

The most complex scenario. Requires account-level connection first, followed by building matching — automated suggestions where possible, manual matching where not — then sync configuration per data type.

How might we

Before moving into flows, I framed the design challenge as a set of HMW questions to guide decision-making across all four scenarios:

HMW help Rob link Stream buildings to benchmarking platform buildings without requiring him to understand the underlying account structure?

HMW make sync direction controls — push, pull, two-way — feel intuitive for someone who thinks in terms of data accuracy, not data architecture?
HMW give Rob real visibility into sync status so he can trust the data without manually cross-referencing two platforms?
HMW surface errors in plain language so Rob can act on them himself, without filing a support ticket?
HMW accommodate four fundamentally different starting points within a single coherent feature?

User Flows

I mapped all four scenarios as user flows before touching a wireframe, because the branching logic had to be resolved at the flow level first. Key decision points across the flows:

Account exists vs. doesn't exist → branches the entire setup path
Buildings matched vs. unmatched → determines whether automated suggestions surface or manual entry is required
Data type selection → Spaces (two-way sync possible), Utilities (push or pull only), Energy Score (always pulled, never pushed)
Sync status → error states, success states, and the overnight delay constraint

Four user flows mapped across distinct starting points — from "no account in either system" to "buildings exist in both but aren't synced." Resolving the branching logic at this stage prevented rework at the wireframe level.
view the user flows on figma.

Design

With the user flows resolved across all four scenarios, I moved into wireframes and then high-fidelity design within Brightly's existing design system.

The three core screens I designed were: the ESPM Configuration page, the Meter Sync side sheet, and the Site Sync Settings side sheet. Each solved a distinct part of Rob's problem.

ESPM Configuration Page

The entry point for the entire feature — a table view showing all connected sites alongside their energy performance scores, certification status, validation status, permission levels, and property data. This screen had to answer Rob's most immediate question at a glance: which of my buildings are connected, and are they in good shape?

Key design decisions:

Tooltips on ambiguous columns so Rob could act without needing documentation
Colour-coded ES Score column for quick status scanning without reading every row
Permission level visible per site, critical for multi-user admin environments
Tags indicating site relationships (complex vs. standalone buildings) surfaced inline

Meter Sync Side Sheet

Once a site is selected, this sheet gives Rob control over how individual meters sync.

Meters are grouped into three categories: meters used to compute metrics, meters not used to compute metrics, and IT meters used for data centre calculations. For each meter, Rob can see the account number, type, ESPM Meter ID, units, sync direction, last sync date, last sync status, and whether it's an aggregate meter.

Key design decisions:

"Sync with ESPM" button positioned on the right, a direct response to usability testing where both testers independently gravitated to that position based on muscle memory from other tools
Meter Sync tab surfaces first — testing showed users navigated here immediately; leading with it reduced disorientation
5 meters visible by default rather than 4, a small change that reduced the need to scroll for the most common portfolio sizes
Tooltips added to ESPM Meter ID, Sync Direction, and Aggregate Meter columns — the three that caused the most confusion during testing

Test

We prototyped the flows and ran usability testing with internal users. Testing revealed several critical issues that led to meaningful design revisions:

What we found

01 Navigation and labelling were causing confusion

The tab label "Site Data Sync" wasn't landing, users suggested renaming it to "Settings," which better matched their mental model

Tags showing building relationships (complex vs. standalone) were unclear — users couldn't interpret them without explanation
"Historical Spaces" as a label confused users; they responded better to "Inactive Spaces."

02 Interaction patterns weren't matching user expectations

Both testers independently preferred the sync button on the right side — a muscle memory pattern from tools they already used

Users wanted the Meter sync tab to appear first, since that was their immediate priority when entering the screen
The number of visible meters (4) felt too few — users wanted to see 5 at a glance before scrolling

03 Status visibility needed more at-a-glance clarity

The ES Score column worked well conceptually, but users wanted colour coding to quickly identify sync status without reading individual entries

Error messaging needed more context and a downloadable error list for situations where multiple records failed, important for Rob's auditing workflow
Users wanted "last synced by" information visible, knowing who triggered a sync matters in a multi-user admin environment

View the detailed testing notes here.

What Changed

Empowered 100+ sustainability managers with direct control over their data synchronization
Delivered 14 user stories across 3 major initiatives
Eliminated the cross-platform mismatch problem by designing a clear sync state model with a defined source of truth per data type

Before

2–3 hours per manual configuration

Required support team intervention

No sync status visibility.

No control over data direction

After

Under 15 minutes

Full self Serve

Real-time status with plain-language error messages

Per-data-type sync configuration

Learnings

Embracing Change: Don’t Get Attached to Every Design

Early on, I learned that it’s perfectly normal for some designs to get descoped or set aside. Rather than taking this personally, I recognized that design decisions are driven by business needs and changing priorities. Maintaining flexibility and focusing on the project’s broader goals allowed me to grow as a resilient and strategic designer.

Adapting to Constraints: Prioritizing What Matters Most

Projects often move fast and sometimes limited budgets and tight timelines mean that not every step can be executed as planned. For example, after initial user testing and implementing feedback, we didn’t have the bandwidth for a second round of formal testing. To ensure some level of insight, I guided a fresh team member through the new designs, asking them to evaluate the experience from a user’s perspective. It wasn’t perfect—but was a practical solution given our constraints.

Knowing When to Push Back: Advocating for Users

It’s important to adapt, but sometimes you have to stand your ground, even under pressure. On one project, internal process stakeholders had already reviewed our UI, and tight deadlines made skipping further user testing tempting. My team and I insisted on a quick round of testing with end users, balancing project urgency with the need for real feedback. This approach ensured our designs genuinely met user needs before launch.

Designing for Complexity Means Designing for Trust

The hardest part of this feature was making a technically complex data relationship feel safe to configure. Users like Rob aren't afraid of complexity, but of making a mistake they can't trace or undo. My goal was giving users enough visibility and control that they could act with confidence. That's a design principle I'll carry into every data-heavy product I work on.

My desk & some appreciations

Overview

Sustainability managers using Streams were spending 2–3 hours weekly on manual configuration to get data to and from ENERGY STAR.

They needed to connect their buildings to ENERGY STAR to track energy performance scores, sync utility data, and maintain consistent records across both systems.

This connection didn't exist in a way users could control themselves. It required manual intervention, technical workarounds, and offered no visibility into whether the sync had worked or failed.

What I set out to do

Map the end-to-end workflow across user types (sustainability managers, building managers, implementation partners)
Design a solution that reduced setup time, surfaced sync status clearly, and required no hand-holding

Desk Research

Before designing the flow, I needed to genuinely understand how the benchmarking platform worked. I spent time going through ENERGY STAR's documentation and working through the platform myself to understand:

How accounts, buildings, and meters were structured
What a Client ID vs a Building ID actually represented
How data sharing between accounts worked
What the API could and couldn't do

Competitive Analysis

In the introductory stakeholder meeting, I asked directly: who is your biggest competitor, or who represents the ideal state you're trying to reach? The answer was Measurbl.

I used that as my benchmark. I mapped four key flows in Measurbl to understand how they handled similar complexity:

Adding sites
Connecting to the benchmarking platform
Adding a meter
Site sync status views

I found out that Measurbl had solved the problem of making data configuration feel manageable for non-technical users through clear step-by-step flows, explicit status indicators, and sensible defaults.

Measurbl's interface (left) organizes around portfolio entities. Stream organizes around system functions. These are fundamentally different mental models and understanding that gap shaped our IA decisions.

User Persona

We defined a user persona to guide our design decisions

Strategy

Through research and stakeholder alignment, I identified four distinct user scenarios that the feature had to accommodate, each with a fundamentally different starting point:

Scenario 1

New to Stream, no benchmarking account

User needs to be guided to create an account first, then build out their data in Stream, then push it across and enable automatic sync.

Scenario 2

New to Stream, has an existing benchmarking account

User links their existing account, shares properties, and imports building data — which syncs automatically within a day or two. They can also trigger an immediate refresh.

Scenario 3

Has buildings in Stream, not in the benchmarking platform

User creates their benchmarking account, adds the platform as a contact, links the integration, then shares sites and meters with appropriate access levels.

Scenario 4

Has buildings in both systems, not yet synced

The most complex scenario. Requires account-level connection first, followed by building matching — automated suggestions where possible, manual matching where not — then sync configuration per data type.

How might we

Before moving into flows, I framed the design challenge as a set of HMW questions to guide decision-making across all four scenarios:

HMW help Rob link Stream buildings to benchmarking platform buildings without requiring him to understand the underlying account structure?

HMW make sync direction controls — push, pull, two-way — feel intuitive for someone who thinks in terms of data accuracy, not data architecture?
HMW give Rob real visibility into sync status so he can trust the data without manually cross-referencing two platforms?
HMW surface errors in plain language so Rob can act on them himself, without filing a support ticket?
HMW accommodate four fundamentally different starting points within a single coherent feature?

User Flows

I mapped all four scenarios as user flows before touching a wireframe, because the branching logic had to be resolved at the flow level first. Key decision points across the flows:

Account exists vs. doesn't exist → branches the entire setup path
Buildings matched vs. unmatched → determines whether automated suggestions surface or manual entry is required
Data type selection → Spaces (two-way sync possible), Utilities (push or pull only), Energy Score (always pulled, never pushed)
Sync status → error states, success states, and the overnight delay constraint

Four user flows mapped across distinct starting points — from "no account in either system" to "buildings exist in both but aren't synced." Resolving the branching logic at this stage prevented rework at the wireframe level.
view the user flows on figma.

Design

With the user flows resolved across all four scenarios, I moved into wireframes and then high-fidelity design within Brightly's existing design system.

The three core screens I designed were: the ESPM Configuration page, the Meter Sync side sheet, and the Site Sync Settings side sheet. Each solved a distinct part of Rob's problem.

ESPM Configuration Page

The entry point for the entire feature — a table view showing all connected sites alongside their energy performance scores, certification status, validation status, permission levels, and property data. This screen had to answer Rob's most immediate question at a glance: which of my buildings are connected, and are they in good shape?

Key design decisions:

Tooltips on ambiguous columns so Rob could act without needing documentation
Colour-coded ES Score column for quick status scanning without reading every row
Permission level visible per site, critical for multi-user admin environments
Tags indicating site relationships (complex vs. standalone buildings) surfaced inline

Meter Sync Side Sheet

Once a site is selected, this sheet gives Rob control over how individual meters sync.

Meters are grouped into three categories: meters used to compute metrics, meters not used to compute metrics, and IT meters used for data centre calculations. For each meter, Rob can see the account number, type, ESPM Meter ID, units, sync direction, last sync date, last sync status, and whether it's an aggregate meter.

Key design decisions:

"Sync with ESPM" button positioned on the right, a direct response to usability testing where both testers independently gravitated to that position based on muscle memory from other tools
Meter Sync tab surfaces first — testing showed users navigated here immediately; leading with it reduced disorientation
5 meters visible by default rather than 4, a small change that reduced the need to scroll for the most common portfolio sizes
Tooltips added to ESPM Meter ID, Sync Direction, and Aggregate Meter columns — the three that caused the most confusion during testing

Test

We prototyped the flows and ran usability testing with internal users. Testing revealed several critical issues that led to meaningful design revisions:

What we found

01 Navigation and labelling were causing confusion

The tab label "Site Data Sync" wasn't landing, users suggested renaming it to "Settings," which better matched their mental model

Tags showing building relationships (complex vs. standalone) were unclear — users couldn't interpret them without explanation
"Historical Spaces" as a label confused users; they responded better to "Inactive Spaces."

02 Interaction patterns weren't matching user expectations

Both testers independently preferred the sync button on the right side — a muscle memory pattern from tools they already used

Users wanted the Meter sync tab to appear first, since that was their immediate priority when entering the screen
The number of visible meters (4) felt too few — users wanted to see 5 at a glance before scrolling

03 Status visibility needed more at-a-glance clarity

The ES Score column worked well conceptually, but users wanted colour coding to quickly identify sync status without reading individual entries

Error messaging needed more context and a downloadable error list for situations where multiple records failed, important for Rob's auditing workflow
Users wanted "last synced by" information visible, knowing who triggered a sync matters in a multi-user admin environment

View the detailed testing notes here.

What Changed

Empowered 100+ sustainability managers with direct control over their data synchronization
Delivered 14 user stories across 3 major initiatives
Eliminated the cross-platform mismatch problem by designing a clear sync state model with a defined source of truth per data type

Before

2–3 hours per manual configuration

Required support team intervention

No sync status visibility.

No control over data direction

After

Under 15 minutes

Full self Serve

Real-time status with plain-language error messages

Per-data-type sync configuration

Learnings

Embracing Change: Don’t Get Attached to Every Design

Early on, I learned that it’s perfectly normal for some designs to get descoped or set aside. Rather than taking this personally, I recognized that design decisions are driven by business needs and changing priorities. Maintaining flexibility and focusing on the project’s broader goals allowed me to grow as a resilient and strategic designer.

Adapting to Constraints: Prioritizing What Matters Most

Projects often move fast and sometimes limited budgets and tight timelines mean that not every step can be executed as planned. For example, after initial user testing and implementing feedback, we didn’t have the bandwidth for a second round of formal testing. To ensure some level of insight, I guided a fresh team member through the new designs, asking them to evaluate the experience from a user’s perspective. It wasn’t perfect—but was a practical solution given our constraints.

Knowing When to Push Back: Advocating for Users

It’s important to adapt, but sometimes you have to stand your ground, even under pressure. On one project, internal process stakeholders had already reviewed our UI, and tight deadlines made skipping further user testing tempting. My team and I insisted on a quick round of testing with end users, balancing project urgency with the need for real feedback. This approach ensured our designs genuinely met user needs before launch.

Designing for Complexity Means Designing for Trust

The hardest part of this feature was making a technically complex data relationship feel safe to configure. Users like Rob aren't afraid of complexity, but of making a mistake they can't trace or undo. My goal was giving users enough visibility and control that they could act with confidence. That's a design principle I'll carry into every data-heavy product I work on.

Building Sustainable Solutions at scale

ux research • Ux design • developer handoffs

my role

Timeline

company

tools

Research

Building Sustainable Solutions at scale

ux research • Ux design • developer handoffs

my role

Timeline

company

tools

Research

Overview

Sustainability managers using Streams were spending 2–3 hours weekly on manual configuration to get data to and from ENERGY STAR.

What I set out to do

Desk Research

Competitive Analysis

Measurbl's interface (left) organizes around portfolio entities. Stream organizes around system functions. These are fundamentally different mental models and understanding that gap shaped our IA decisions.

User Persona

We defined a user persona to guide our design decisions

Strategy

Scenario 1

New to Stream, no benchmarking account

Scenario 2

New to Stream, has an existing benchmarking account

Scenario 3

Has buildings in Stream, not in the benchmarking platform

Scenario 4

Has buildings in both systems, not yet synced

How might we

User Flows

Four user flows mapped across distinct starting points — from "no account in either system" to "buildings exist in both but aren't synced." Resolving the branching logic at this stage prevented rework at the wireframe level.view the user flows on figma.

Design

ESPM Configuration Page

Meter Sync Side Sheet

Test

What we found

01

Navigation and labelling were causing confusion

02

Interaction patterns weren't matching user expectations

03

Status visibility needed more at-a-glance clarity

View the detailed testing notes here.

What Changed

Before

After

Learnings

Embracing Change: Don’t Get Attached to Every Design

Adapting to Constraints: Prioritizing What Matters Most

Knowing When to Push Back: Advocating for Users

Designing for Complexity Means Designing for Trust

My desk & some appreciations

Overview

Sustainability managers using Streams were spending 2–3 hours weekly on manual configuration to get data to and from ENERGY STAR.

What I set out to do

Desk Research

Competitive Analysis

Measurbl's interface (left) organizes around portfolio entities. Stream organizes around system functions. These are fundamentally different mental models and understanding that gap shaped our IA decisions.

User Persona

We defined a user persona to guide our design decisions

Strategy

Scenario 1

New to Stream, no benchmarking account

Scenario 2

New to Stream, has an existing benchmarking account

Scenario 3

Has buildings in Stream, not in the benchmarking platform

Scenario 4

Has buildings in both systems, not yet synced

How might we

User Flows

Four user flows mapped across distinct starting points — from "no account in either system" to "buildings exist in both but aren't synced." Resolving the branching logic at this stage prevented rework at the wireframe level.view the user flows on figma.

Design

ESPM Configuration Page

Meter Sync Side Sheet

Test

What we found

Four user flows mapped across distinct starting points — from "no account in either system" to "buildings exist in both but aren't synced." Resolving the branching logic at this stage prevented rework at the wireframe level.
view the user flows on figma.

Four user flows mapped across distinct starting points — from "no account in either system" to "buildings exist in both but aren't synced." Resolving the branching logic at this stage prevented rework at the wireframe level.
view the user flows on figma.

Four user flows mapped across distinct starting points — from "no account in either system" to "buildings exist in both but aren't synced." Resolving the branching logic at this stage prevented rework at the wireframe level.
view the user flows on figma.