It is a solar energy monitoring app designed entirely from scratch, built for homeowners, offices, and businesses running solar panel installations.

The app serves two distinct roles.

✦ Customers, link their solar inverter by scanning a QR code, which pulls their system data directly onto a personal dashboard.

✦ Installers, on the other hand, don't scan anything. Every client they've set up appears on their profile automatically.

Solar monitoring isn't a simple category. The people using this app range from a homeowner checking their savings after a power cut to an installer managing dozens of client systems simultaneously.

Designing for both without making either experience feel compromised was the core design challenge.

The decision to split the experience into two distinct roles of Customer and Installer, came from understanding that their goals are fundamentally different.

A customer wants to know: is my system working, and how much am I saving?

An installer wants to know: which of my clients needs attention right now?

The same interface can't serve both questions equally well, so it doesn't try to.

Ranade brings a clean, slightly geometric character that works well for headings and key data points, giving the app a technical feel without being cold.

Excon handles the supporting text, offering readability at smaller sizes while staying consistent with the overall tone.

Together they create a hierarchy that feels purposeful.

Typography in a data-heavy app does more than set a visual tone. It creates a reading hierarchy that guides users through numbers and metrics without requiring them to consciously think about where to look.

Ranade's geometric structure draws the eye to the most important figures first, while Excon keeps the supporting context readable without competing for attention.

The combination also signals credibility. Solar monitoring is a technical product, and the typeface pairing reinforces that without leaning into the cold, clinical aesthetic that often follows technical design.

The core function is real-time visibility: energy produced, energy consumed, daily savings, and total savings are all surfaced on the main dashboard without requiring the user to dig through menus.

For customers, the dashboard answers the question they have every time they open the app: is my system performing well today?

Peak production times, consumption patterns, and savings are shown in a format that's readable at a glance, not just after studying the screen.

For installers, the value is in the overview. Rather than checking each client one by one, every connected system appears on their profile automatically. Anomalies and underperforming systems surface without needing to be searched for.

Before opening Figma, the report screen was sketched on paper first.

This screen carried the most data complexity in the entire app. It includes:

all needed to coexist without overwhelming the user.

Sketching it by hand allowed the information architecture to be mapped out freely. No constraints, no components, just structure and logic.

It cleared the ambiguity early so the Figma work had a clear direction to follow.

The web dashboard extends the product for installers who need a larger view of their client base. The kind of detailed monitoring that works better on a wider screen than a phone.

The same design language carries over from the mobile app: the color system, typography, and component style are consistent across both surfaces.

This wasn't done just for visual consistency, it reduces cognitive load for installers who switch between their phone in the field and a desktop back at the office. The interface feels familiar regardless of where it's being used.

The dashboard gives installers a deeper view of individual client systems: historical performance data, usage trends, and system health details that go beyond what the mobile overview surfaces.

The Figma prototype covered the Report screen end-to-end — the most complex screen in the app and the one most likely to expose UX problems before development began.

Walking through the prototype revealed how transitions between time ranges (daily, weekly, monthly) felt in practice, whether the data hierarchy was immediately readable, and where the eye naturally landed on first load.

Issues that would have been expensive to fix in development were caught and resolved at the prototype stage.

A working prototype also serves as a communication tool. It gives stakeholders something concrete to react to rather than asking them to imagine how a static design will behave.