AN ESSENT CASE STUDY: HOW REBUILDING OUR APPS PREPARED US FOR THE FUTURE AND INCREASED THE APPSTORE RATING BY 1,5 POINTS
In recent years the energy crisis in The Netherlands greatly impacted Essent and its customers. Reduced availability caused market prices of energy and gas to spike. Hence, people’s interest in their energy consumption and costs grew exponentially. This resulted in nearly 100 million app visits in 2023, which is on average around 50 visits per customer per year. With an average app- and play store ratings of around 2.2 out of 5.0, we knew that our customers were not happy with the app, and neither were Essent employees.
The apps team worked hard to turn this around. However, this was a challenging process. The codebase became very hard to manage over the years. Next to that NativeScript, the old framework, could not meet our performance and maintainability standards. Framework updates took a long time or had a high risk of breaking features. Any innovation was simply not possible, because we already had a hard time keeping up with making required legislative changes. Something had to be done.
In this case study, we’ll discuss how we eventually made it happen, which challenges we ran into and how we solved them. We’ll highlight the process and describe the eventual successes. The case study serves as a transparent view on how we rebuilt the Essent and Energiedirect apps together with our partner Navara.
SUCCESSES:
- A staged release without any major incidents
- The new look and feel, including dark mode, helped with improving the user experience
- The average app store rating went from a 2.2 to 3.7 out of 5.0.
- More than half of our customer base has used the new app.
- We are fully in control over our automated release process.
- We are compliant with the WCAG 2.2 level AA standards for accessibility
- We improved all tooling and processes for the people working on and with the app, by using feature flags, Adobe Analytics and Contentsquare for analytics, Sentry for error detection, and multiple preview environments for testing.
We do understand that we're not there yet. For example, some of our competitors have better rated apps, but we know what we need to do to improve further.
WHERE WE CAME FROM:
The Essent apps were originally made internally by a combination of internal and external developers, but due to cost savings reasons development had been offshored to Eastern Europe. Unfortunately, this didn’t go well. We were not in control anymore over our processes and the most important customer interaction channel. On top of that, we had suffered an outage of almost one week contributing to negative internal and external sentiment about the app.
Old Essent App
NEW PLAN
It was clear that change was needed. Making a new app also gave us the opportunity to consider additional requirements, features and wishes.
- Rebranding – the look and feel of the app wasn’t great: see screenshot above and judge by yourself :) At the same time, Energiedirect was working on a rebranding and redesign, which ideally would be deployed across multiple channels at the same time, including the new app. The believe was that improving the look & feel would improve the user experience and increase brand engagement.
- New accessibility standards (WCAG) – Essent’s core values state that we want to be there for everyone. Around 2 million people in The Netherlands have a form of impairment while interacting with digital channels. Next to that, having accessible digital products would become mandatory by law in a couple of years.
- Future proof – this means that we will be able to develop and deploy the apps at high speed and with high quality for many years to come. For example, focusing on DevOps metrics such as speed, efficiency, stability and reliability. It was clear that the feeling of not being in control of releasing and experiencing a major outage was something we never wanted to experience again. We believe that high quality and speed are not mutually exclusive. In other words, we would set high technical standards.
THE TEAM
The team consisted of six engineers, 1-2 UX professionals, a part-time Scrum Master and a full-time Product Owner. The team was assisted by many people from the organization, like a project lead, a digital specialist, marketeers, legal specialist, etcetera. During the 9 months before releasing the apps to the public, the team was stable and had no changes in its composition, which contributed to the success of the launch. The team is responsible for both the Essent and Energiedirect apps, which share most of their functionality and design system.
CHALLENGES
New vs. Old apps
Because the market was changing relatively quickly, scope and requirements also changed while developing the new apps. The team working on the new apps was also the team that maintained the old apps. New feature requests kept coming in for the old apps, and requirements for the new apps already changed before they were live.
We ended up in a downward spiral where the team was disappointed, they couldn’t focus on the new apps and stakeholders were disappointed because things took longer than expected. To prevent both ‘sides’ drifting further apart, some things had to change.
Agile vs. Project
Initially when the project started at the end of ’22 with the groundwork for the app repository and the design system, the target release date was 1st of October ’23. This launch date would mean it could be combined with the go live of the new rebranding across all channels. The pressure to combine multiple deadlines was one challenge related to project management.
Next to that, it wasn’t transparent enough what the remaining steps would be to get the app live. Management felt a lack of control and the team felt insecure, because they didn't get all detailed requirements yet. During the rebuild, some things were simply not clear yet. We had to create a shared understanding again. Working on a project, while being agile.
Structuring app development
A major upside of this project was that we had one central app team working on both the existing and the new apps. Communication lines were short and app development knowledge was centralized.
However, the structure was also a downside. Within Essent we have people from the business - those who hold domain knowledge and who set the requirements - that would usually work with teams working on the website. The distance between both the “business” and “IT” as well as “web” and “app” was too big. It was incredibly hard to discover all the requirements that were in the existing apps from all those different teams. The apps team itself did not have the people with the right knowledge about domains like consumption or invoicing, for example.
Another related challenge that arose was cooperation between disciplines. The domain experts would send requirements to a designer that would translate them to a design, but these were made from a web development perspective and not always checked for feasibility. The consequence was that the development team couldn't meet the new standards. In the end, everyone was dissatisfied with this process.
HOW DID WE FIX SOME OF THE CHALLENGES?
- Drastically decrease work on the old app. We decided to basically stop all non-essential (feature) development in the old app. Of course, we would make sure the app was still secure and meeting legislative requirements, but all new requests were put on hold. If we would still change a feature in the old app, it would only be live for a couple of months, so the return on investment was not worth it. A lesson is that this is something that we should’ve done sooner.
- Re-discuss scope. The opportunity of a new app felt like we could include some new features as well. However, this led to a moving target. We rediscussed scope together with stakeholders, so that it was a shared decision. In the end, the goal was to rebuild an app that was at least as good as the old app, or better, but not less, with at least a new design and a new technical foundation. Feature-wise we made practically no changes.
- Restore trust. The two things that helped most were creating transparency (roadmap) and delivering small milestones. We (re)started the sprint review, worked a lot on our relationship with (project) management and in the meantime, we would create smaller (visual) milestones to show progress, so that trust would increase, and pressure reduce.
- Everyone in one room from the start. Knowledge holders, designers and developers were now together in one room discussing the as is situation of each individual feature in detail. Because we did it together, nobody would put blame on someone else if something was overlooked. We would just also solve this together. Involving development and design very early in the process helped a lot. Nobody knows everything.
GO LIVE
During development we introduced an internal- and external test group. We surveyed them with an online form. This way we could find many bugs and fix them while developing. Also, when we knew that around 70% of people confirmed that the app was better than the old app, we got the confidence that we had a version we could release to the bigger crowd without having to build months more to make it better. Of course, it still felt a bit scary to go live, because things were not perfect, but we could explain to everyone what those things were. In the end, we were in control and software in production is the best feedback you can get.
Our go live strategy was to release to all customers using a three-week ramp up plan where we would use App Store features to scale a bit further every day. First, one brand, one Operating System, 1% of users to 100% and so on. This decision benefited us a lot, because we could fix even more issues on the go. I’m still amazed how many things or edge cases are only discovered this far in the process, so I’m glad we decided on a very clear go live strategy.
AFTER GOING LIVE
In the first month after going live, we were still closely monitoring all feedback. We fixed tens of bugs and stories with half of the team while the other part of the team already started on feature development.
For example, we had decided that we would not immediately introduce landscape mode, because a low percentage of users are using it. However, this was the biggest reason for getting tens of 1-star reviews. Though the group wasn’t big, customers really wanted landscape mode. A nice example of an MVP decision was then to enable landscape mode within a day, instead of trying to make it look very great, which would take us weeks. Just enabling it, already drastically reduced the feedback which bought us time to make it look better later. The feedback loop closed within a day.
In the months after we had momentum to catch up with (new) features. We introduced hourly energy insights, comparison mode, expected usage and started changing the back-end API’s we were using to show data like the API for your advice and the API for giving consent. These technical improvements were also put on hold in the last couple of months, so those teams were very pleased that we could speed things up now.
LOOKING AHEAD
Though we’re happy with the improved apps, they’re far from perfect yet. We now have all the ingredients to scale further in the future, making both the business and our users happier with every single release. Some fantastic new features are coming, and we can’t wait to share the news with our users.
Now, our main challenges are:
Scale our app capabilities from one decentralized team to other teams, so that multiple teams can independently deliver high quality app improvements.
Help more users via the app with personalized actions, tips and recommendations hereby reducing the pressure on our customer service department
Find smart ways to integrate all our offerings into a One Stop Energy Shop app.
Perhaps you are one of those people helping with solving this challenge? Essent is always looking for talented individuals such as developers and designers. Check-out our vacancies here: https://www.werkenbijessent.nl/nl/vacatures.