End-to-end design of an IoT energy product's digital ecosystem, from a consumer's home device to a business operator's fleet.
Client
Next
Industry
IoT
Year
2024
Methodology
Lean
Role
Lead product designer
Team
Project manager Design director Lead product designer Back-end developers Front-end developers
End-to-end design of an IoT energy product's digital ecosystem, from a consumer's home device to a business operator's fleet.
Client
Next
Industry
IoT
Year
2024
Methodology
Lean
Role
Lead product designer
Team
Project manager Design director Lead product designer Back-end developers Front-end developers
End-to-end design of an IoT energy product's digital ecosystem, from a consumer's home device to a business operator's fleet.
Client
Next
Industry
IoT
Year
2024
Methodology
Lean
Role
Lead product designer
Team
Project manager Design director Lead product designer Back-end developers Front-end developers
CHALLENGE
From a physical device to one connected ecosystem
Next needed an entire ecosystem built from the ground up around a physical energy device, the brand and product language, a consumer app and a business platform. The device moved through more than ten distinct states, each with its own logic, constraints, and actions, all reflecting the hardware's real-time status in a way that had to read instantly. The same system also had to serve two very different users: a consumer monitoring one device at home, and a B2B team managing a fleet. The challenge was holding all of it, hardware and digital, in one coherent product rather than separate tools bolted together.
CHALLENGE
From a physical device to one connected ecosystem
Next needed an entire ecosystem built from the ground up around a physical energy device, the brand and product language, a consumer app and a business platform. The device moved through more than ten distinct states, each with its own logic, constraints, and actions, all reflecting the hardware's real-time status in a way that had to read instantly. The same system also had to serve two very different users: a consumer monitoring one device at home, and a B2B team managing a fleet. The challenge was holding all of it, hardware and digital, in one coherent product rather than separate tools bolted together.
CHALLENGE
From a physical device to one connected ecosystem
Next needed an entire ecosystem built from the ground up around a physical energy device, the brand and product language, a consumer app and a business platform. The device moved through more than ten distinct states, each with its own logic, constraints, and actions, all reflecting the hardware's real-time status in a way that had to read instantly. The same system also had to serve two very different users: a consumer monitoring one device at home, and a B2B team managing a fleet. The challenge was holding all of it, hardware and digital, in one coherent product rather than separate tools bolted together.
OUTCOME AND IMPACT
A technically dense product that still feels simple
The device generated a lot of technical, real-time data, but most people using it just wanted to know what was happening and what to do. So the product surfaces the essentials by default and keeps the full technical detail one layer down, for the users who want it. The same approach held across every touchpoint and both user types, from a consumer glancing at their home device to an operator managing a fleet. The result is a technically dense energy product that still feels simple to read and control.
OUTCOME AND IMPACT
A technically dense product that still feels simple
The device generated a lot of technical, real-time data, but most people using it just wanted to know what was happening and what to do. So the product surfaces the essentials by default and keeps the full technical detail one layer down, for the users who want it. The same approach held across every touchpoint and both user types, from a consumer glancing at their home device to an operator managing a fleet. The result is a technically dense energy product that still feels simple to read and control.
OUTCOME AND IMPACT
A technically dense product that still feels simple
The device generated a lot of technical, real-time data, but most people using it just wanted to know what was happening and what to do. So the product surfaces the essentials by default and keeps the full technical detail one layer down, for the users who want it. The same approach held across every touchpoint and both user types, from a consumer glancing at their home device to an operator managing a fleet. The result is a technically dense energy product that still feels simple to read and control.
DESIGN DECISION: INTERFACE AND MOTION
How do you make the screen feel like the device itself?
The device produces a constant stream of technical data, two batteries, shifting states, energy moving in and out, but most people just want to know how it's doing right now. The core decision was to make the main element on screen the device itself: the fill shows how much energy it holds, so charge level is something you see rather than read. Its color reflects the device's state, turning red the moment something goes wrong, so a problem registers before anyone checks a status label. The essentials show by default, while a toggle opens a denser view with per-battery data, since the device runs two batteries an operator may need to read separately rather than as a combined total. Energy flow is shown through animation, particles moving toward the device as it charges and away as it discharges, turning an invisible physical process into something you understand by watching. Together these made the interface a direct mirror of the device, so its status reads at a glance, before anyone looks at a single number.
DESIGN DECISION: INTERFACE AND MOTION
How do you make the screen feel like the device itself?
The device produces a constant stream of technical data, two batteries, shifting states, energy moving in and out, but most people just want to know how it's doing right now. The core decision was to make the main element on screen the device itself: the fill shows how much energy it holds, so charge level is something you see rather than read. Its color reflects the device's state, turning red the moment something goes wrong, so a problem registers before anyone checks a status label. The essentials show by default, while a toggle opens a denser view with per-battery data, since the device runs two batteries an operator may need to read separately rather than as a combined total. Energy flow is shown through animation, particles moving toward the device as it charges and away as it discharges, turning an invisible physical process into something you understand by watching. Together these made the interface a direct mirror of the device, so its status reads at a glance, before anyone looks at a single number.
DESIGN DECISION: INTERFACE AND MOTION
How do you make the screen feel like the device itself?
The device produces a constant stream of technical data, two batteries, shifting states, energy moving in and out, but most people just want to know how it's doing right now. The core decision was to make the main element on screen the device itself: the fill shows how much energy it holds, so charge level is something you see rather than read. Its color reflects the device's state, turning red the moment something goes wrong, so a problem registers before anyone checks a status label. The essentials show by default, while a toggle opens a denser view with per-battery data, since the device runs two batteries an operator may need to read separately rather than as a combined total. Energy flow is shown through animation, particles moving toward the device as it charges and away as it discharges, turning an invisible physical process into something you understand by watching. Together these made the interface a direct mirror of the device, so its status reads at a glance, before anyone looks at a single number.
DESIGN DECISION: DESIGNING WITH ENGINEERING
How do you design a product whose hardware isn't finished yet?
Much of the product was still being defined while I was designing it, the device states, the technical requirements, what the hardware could actually do. Many of those answers didn't exist yet, so engineering and I worked them out together: what each state and requirement should mean, what it should let a user do, and how it should behave. I drove this through constant reviews and by structuring the shared documents we worked from, which became part of the product's core documentation. The states and requirements ended up designed and specified at the same time, by design and engineering together.
DESIGN DECISION: DESIGNING WITH ENGINEERING
How do you design a product whose hardware isn't finished yet?
Much of the product was still being defined while I was designing it, the device states, the technical requirements, what the hardware could actually do. Many of those answers didn't exist yet, so engineering and I worked them out together: what each state and requirement should mean, what it should let a user do, and how it should behave. I drove this through constant reviews and by structuring the shared documents we worked from, which became part of the product's core documentation. The states and requirements ended up designed and specified at the same time, by design and engineering together.
DESIGN DECISION: DESIGNING WITH ENGINEERING
How do you design a product whose hardware isn't finished yet?
Much of the product was still being defined while I was designing it, the device states, the technical requirements, what the hardware could actually do. Many of those answers didn't exist yet, so engineering and I worked them out together: what each state and requirement should mean, what it should let a user do, and how it should behave. I drove this through constant reviews and by structuring the shared documents we worked from, which became part of the product's core documentation. The states and requirements ended up designed and specified at the same time, by design and engineering together.
DESIGN DECISION: CONSUMER AND B2B
How do you serve a person with one device and a team managing hundreds?
A consumer checks a single device at home, while a B2B operator monitors a large fleet, often on the move, heading out to collect a device or troubleshoot one that has stopped working. Their needs barely overlap: one wants a calm glance at status, the other needs to track many devices at once and act on them in the field. Rather than build two separate products, I extended one design system across both, keeping the same patterns so the two experiences feel like one product. The B2B side adapts those shared foundations to far denser, higher-stakes use, without inventing a different language to do it.
DESIGN DECISION: CONSUMER AND B2B
How do you serve a person with one device and a team managing hundreds?
A consumer checks a single device at home, while a B2B operator monitors a large fleet, often on the move, heading out to collect a device or troubleshoot one that has stopped working. Their needs barely overlap: one wants a calm glance at status, the other needs to track many devices at once and act on them in the field. Rather than build two separate products, I extended one design system across both, keeping the same patterns so the two experiences feel like one product. The B2B side adapts those shared foundations to far denser, higher-stakes use, without inventing a different language to do it.
DESIGN DECISION: CONSUMER AND B2B
How do you serve a person with one device and a team managing hundreds?
A consumer checks a single device at home, while a B2B operator monitors a large fleet, often on the move, heading out to collect a device or troubleshoot one that has stopped working. Their needs barely overlap: one wants a calm glance at status, the other needs to track many devices at once and act on them in the field. Rather than build two separate products, I extended one design system across both, keeping the same patterns so the two experiences feel like one product. The B2B side adapts those shared foundations to far denser, higher-stakes use, without inventing a different language to do it.
DESIGN DECISION: A SCALABLE FOUNDATION
How do you build a foundation that scales with the product?
I built a design system for data-heavy IoT screens that had to stay legible no matter how much information they carried. Modular components and a consistent structure keep dense, real-time data readable, with core modules shaped around the idea of an energy container, the same device-as-mirror logic that runs through the interface. I also shaped the brand strategy and architecture: the positioning the product would grow into, and a scalable structure built to carry the company into new product areas without being rebuilt each time. Together they give the product a foundation that holds as it grows, from a single device to a wider family of products.
DESIGN DECISION: A SCALABLE FOUNDATION
How do you build a foundation that scales with the product?
I built a design system for data-heavy IoT screens that had to stay legible no matter how much information they carried. Modular components and a consistent structure keep dense, real-time data readable, with core modules shaped around the idea of an energy container, the same device-as-mirror logic that runs through the interface. I also shaped the brand strategy and architecture: the positioning the product would grow into, and a scalable structure built to carry the company into new product areas without being rebuilt each time. Together they give the product a foundation that holds as it grows, from a single device to a wider family of products.
DESIGN DECISION: A SCALABLE FOUNDATION
How do you build a foundation that scales with the product?
I built a design system for data-heavy IoT screens that had to stay legible no matter how much information they carried. Modular components and a consistent structure keep dense, real-time data readable, with core modules shaped around the idea of an energy container, the same device-as-mirror logic that runs through the interface. I also shaped the brand strategy and architecture: the positioning the product would grow into, and a scalable structure built to carry the company into new product areas without being rebuilt each time. Together they give the product a foundation that holds as it grows, from a single device to a wider family of products.
LEARNINGS
Accept uncertainty as part of the design problem
The most valuable part of Next was designing a product whose foundation was still being built. I couldn't wait for the hardware to be finished and then design around it, the answers didn't exist yet, so design and engineering worked them out together. That taught me to treat uncertainty as part of the design problem rather than a blocker, and to use design as a way to make decisions concrete enough for a team to move on. Like many startups, Next didn't reach the market yet, for reasons unrelated to the design, but building a whole ecosystem under that kind of uncertainty taught me to be comfortable with "I'm not sure yet".
LEARNINGS
Accept uncertainty as part of the design problem
The most valuable part of Next was designing a product whose foundation was still being built. I couldn't wait for the hardware to be finished and then design around it, the answers didn't exist yet, so design and engineering worked them out together. That taught me to treat uncertainty as part of the design problem rather than a blocker, and to use design as a way to make decisions concrete enough for a team to move on. Like many startups, Next didn't reach the market yet, for reasons unrelated to the design, but building a whole ecosystem under that kind of uncertainty taught me to be comfortable with "I'm not sure yet".
LEARNINGS
Accept uncertainty as part of the design problem
The most valuable part of Next was designing a product whose foundation was still being built. I couldn't wait for the hardware to be finished and then design around it, the answers didn't exist yet, so design and engineering worked them out together. That taught me to treat uncertainty as part of the design problem rather than a blocker, and to use design as a way to make decisions concrete enough for a team to move on. Like many startups, Next didn't reach the market yet, for reasons unrelated to the design, but building a whole ecosystem under that kind of uncertainty taught me to be comfortable with "I'm not sure yet".
Next up
Next up
Next up
