Designing Vattenfall's B2C consumption app to reduce churn and increase customer satisfaction

Senior Product Designer & Design Lead
Framna & Vattenfall
React Native
UX
UI

Vattenfall is Sweden's main energy provider, with strong presence in the Nordics and Germany. As electricity prices increased, customers needed a clear way to track their usage. I joined the team to design a tool that would help them cut costs and reduce their environmental footprint.

why it mattered

Customers were switching to competitors for better access to real-time data that let them consume smarter and pay less. We needed to build Vattenfall's first consumption app to stay competitive.

the challenges

1. An information architecture that serves all customer types without overwhelming casual users. The Home tab needed to adapt by contract type while the overall structure stayed consistent.

2. Visualising complex data with both depth and clarity. The graph system needed to give casual users a clear default while letting engaged users drill down.

the approach

Both challenges shared one answer: build a structure that flexes around the user instead of forcing everyone through the same experience.

We landed on a 4-tab structure built with growth in mind. The Home tab shows custom widgets per contract type: fixed price customers see reassurance first, 15-min customers see prices and consumption first. Graphs work the same way, filters let users set the resolution and comparison data they care about, and those filters persist between sessions.

the impact

We launched a Beta in September, 5 months after kickoff, followed by a full release in November.

170,000+

Downloads in Sweden as of November 2025

3.8

App Store rating

13%6%

Churn, 2023 to 2026

5,000+

New users every month

+12

NPS among app users, up to 19 points above non-app customers

Finland

Released a few months after the Swedish launch

Other projects

scoping the problem

Vattenfall's initial brief was an app exclusively for customers on the 15-min contract, around 7% of users. Through discovery interviews and a competitor audit, we learned this framing was too narrow: offering a new consumer app for only a small segment of customers would feel like a missed opportunity to bring value and increase engagement and satisfaction on the whole customer base.

Fixed price customers wanted predictability, mainly invoice confirmations and reassurance that costs were under control. 15-min customers needed hourly prices and consumption data to shift usage to cheaper hours and get the most from their flexible assets. Monthly spot customers sat in between, benefiting from market prices without constantly monitoring their usage.

We challenged the original scope and made the case for one app serving all three types.

research & discovery

The process moved through card sorting to understand how customers prioritised content, iterative wireframing and prototyping, and validation testing with real users. This is where the two design challenges emerged: serving all customer types without fragmenting the experience, and visualising complex data with both depth and clarity.

the design process

For the information architecture, we tested how the Home tab could adapt without breaking the underlying structure: layout, hierarchy and content shifting by contract type while the navigation stayed the same for everyone. The 4-tab structure came out of this work, built with growth in mind so the product could evolve without restructuring the app every time a new feature shipped. Contract and invoicing information, which users kept telling us was essential, earned its own place directly in the navigation rather than living buried in a settings menu.

For data visualisation, we worked from the same principle. The graph system carries several types, granularities and filters, so the default is readable on its own and the detail is one step away for anyone who wants it. Filters persist between sessions, so each user's app effectively builds its own default view over time.

decisions & trade-offs

We made the data visualisation in the Overview tab as detailed as we could with the data we had. The tab opens on one default graph and the customisation sits in the filter sheet: users who want granular detail can set every filter available and read their consumption closely, while users who don't want to dive deeper into their energy data don't need to go beyond default.

The same thinking shaped how features open. We used soft landings: rather than defaulting to a complex screen of components, a feature opens on a screen that introduces it first. Smart Steering is the clearest example. Users who want it carry on from there, and users who have no need for it are never dropped into something built for someone else.

The app has graphs across many screens and at different levels of complexity. Rather than building a custom component for each one, we worked closely with the engineering team on creating shared graph components that cover most cases. That made both the design and the build faster, and left custom graphs as the exception.

what I learned

Working with hybrid teams, product agency and client-side stakeholders together taught me that transparent processes and clear requirements are essential under tight deadlines. I learned to design flexibly to accommodate scope changes, start simple with complex data visualisation, and treat the initial release as a foundation for iteration based on continuous user feedback.