Making microgrid design work for volunteers, not just engineers

The problem

A microgrid is a small, self-contained power system, often solar panels, batteries and a backup generator, serving a village that the main grid doesn't reach. Before anyone can fund one, someone has to estimate what the community will use and what it will cost to supply. KiloWatts for Humanity, a nonprofit that has built energy kiosks in Zambia and Kenya since 2009, sponsored a free, open-source tool for that pre-feasibility step.

Two earlier capstone teams had built it as a set of Python scripts behind a static site, driven by a single 24-hour load sheet. It worked for engineers. It didn't work for the people who most needed it: nonprofit volunteers who get handed the job with no background in power systems.

Getting to four requirements

Our users were volunteers in these communities. We learned about them through our sponsor and the KiloWatts for Humanity volunteers who have worked with them in the field, and they were clear about where the last version fell short: there was no way to export results and the graphs only partly worked, a whole community had to be entered as one hourly total with no way to describe its buildings or appliances, and new users didn't know where to start. The alternative, HOMER Pro, needs a paid license and assumes you already understand power systems, so it was never an option for them. We turned all of that into four requirements the sponsor could check:

• Performance. The tool stays usable on low-end devices and slow connections, with graphs and screens appearing within five seconds.
• Export formats. Results can be kept and shared outside the tool without rerunning a simulation.
• Advanced loads. A design can describe a real community: its buildings, the appliances in them, and how their use changes through the day.
• UI/UX. A first-time user with no engineering background can set up a microgrid and understand what the results mean.

Turning requirements into a backlog

The project ran three quarters with a four-person Agile team, our sponsor Peter Dauenhauer of KiloWatts for Humanity and the IEEE SESDC working group, and a faculty advisor. We kept the backlog in GitHub, with each feature as an issue tied to a milestone the sponsor could check. Six of them shaped the release:

1. Rebuild the front end in TypeScript, and move the simulation into a backend function, so it performs well on low-bandwidth connections.
2. Loads as components: break each building into the appliances inside it, so a school is its lights, PCs and AC rather than one estimate for the whole building.
3. Graphs and CSV downloads: interactive graphs filtered by source and time range, and a CSV of every result to keep or share.
4. Hourly profiles: a usage pattern for each load, with smart presets like a workday or household double peak, in plain terms. Seasonal profiles didn't make the release.
5. A guided project wizard with a first-time tutorial, better defaults and reference measurements, so a non-engineer can set up a microgrid on their own.
6. A workbench that shows the whole community on one screen: every building, its loads and their daily use, all editable in place.

Designing and building the interface

Screens from the live toolkit.

A new project starts in a guided wizard, built by a teammate. I designed and built the rest of the front end: the workbench, the graphs and data pages, accounts and the app shell around them. The workbench borrows one idea from CAD tools like Fusion 360, which I use often: the whole design lives in one workspace, made of named parts you can open and edit in place. Everything else is stripped away, so the user only sees the controls that apply to what they have selected, not a full professional toolbar. We ran daily standups to keep four people's work moving in the same direction, and every change went through a code review by a teammate plus unit and end-to-end tests before it shipped.

Each quarter we presented our decisions to the sponsor, and at the end of the year to faculty, industry professionals and the University of the West Indies, which also works with KiloWatts for Humanity. The toolkit launched at sesdc-toolkit.com in June 2026.

What happened

The feedback was positive across the board. Our sponsor and the reviewers pointed to how much easier the toolkit is to use than the year before, and liked that it takes on a problem whose solution could improve lives in communities around the world. It's live and free at sesdc-toolkit.com, ready for its first real project.

We handed the project to the next capstone team with a user guide and developer docs for Firebase, Preact, testing and the deploy pipeline.

What I'd do differently

Set the design rules early. Agree on the UI/UX rules the whole site follows, like the point grid, colors and spacing, and document them well before the first screen is built, so four people's work stays consistent from the start.

Break features into the smallest pieces possible. Small issues are easier to estimate, review and ship, and they show sooner when something is stuck.