Introduction
In 2022, I had the privilege of collaborating with colleagues in the Essent 'Elektrisch Laden' Team (ELT) to create a brand-new service within Essent. We named it the Essent Elektrisch Laden proposition. This eMobility service allows customers to purchase charging stations and charge cards, as well as manage these products. One component within the Essent eMobility ecosystem was the Essent 'Elektrisch Laden' app.
This app enables users to find and navigate to public charging stations, check tariffs, review charging sessions, and monitor associated costs. To launch the app faster, Essent chose to build it using Vandebron's foundation (white label).
Key challenges
- How can I ensure a seamless experience when integrating this native app with other products within the organization, especially when dealing with white-label restrictions?
- How can I handle expectations from both Essent and Vandebron, given their geographical distance and tight schedules?
- How can I validate the design when the organization is hesitant to allocate resources and budget for end-user validation at this stage, considering it's a white-label project based on an app already validated with users?
- How can I break the project into manageable parts for efficient Agile work?
High-level process
I always start with gathering insights. What is the problem or opportunity in the market? What is the goal? Why is it so important? What is the scope? What do we already know? And are there assumptions and hypotheses we've made that need to be considered?
This process helps me understand project requirements, recognize potential challenges, collaborate with stakeholders to establish the succes criteria, and develop a suitable approach. (Pro tip: an approach is a means, not an end in itself).
.svg)
To follow up on the briefing, it's important to note the partnership between Essent and Vandebron. They're using Vandebron's framework for the Essent app, which can speed things up, but it also brings up some key questions:
- What use/edge cases are currently covered in the Vandebron app, and are there specific needs/requirements from Essent? This is crucial, as Essent may have unique interests, despite it being a white label app.
- What are the requirements of Vandebron app users, and to what extent have these been integrated? Have all user needs and desires been incorporated, or are there features in the backlog for near-future development? Understanding this helps me plan design considerations in advance and include them in my design scope, which, in turn, aided developers in getting ready for the upcoming addition.
- What deliverables are required for developing a native app, and what should I keep in mind while designing it? Deliverables like app icons and images for app stores, for instance, aren't relevant for web-based projects.
- How can I validate the concept before 2024, considering that changes made for Essent might affect the user experience? I want to avoid any negative experiences with the brand-new eMobility proposition, especially since competitors like Eneco and Vattenfall already have an advantage.
- How can we break this project into manageable chunks to gain a better overview of requirements and progress? Pro tip: breaking things down makes it easier to poker your user stories when working Agile.
To find the answers, I encountered my first two challenges in this project.
Challenge(s) and solution(s)
- How can I handle expectations from both Essent and Vandebron, given their geographical distance and tight schedules?
- How can I break the project into manageable parts for efficient Agile work?
Let's start with challenge number one. In this case, I decided to combine a Discovery and Empathy workshop and conduct it with stakeholders from both Essent and Vandebron since they have a shared interest in this project. This approach helps prevent confusion and ensures that everyone is on the same page regarding insights and decisions, allowing us to be more efficient, especially when facing tight time constraints.
However, because both organizations were spread across the country, having a physical session wasn't ideal. So, I chose to conduct it digitally through Mural. To save precious time, I first aligned with Vandebron stakeholders, as they are the ones providing the foundation. This allowed me to prepare in advance and fill in the Mural board with known insights and requirements, enabling us to focus on what we see and identify the missing elements. Saving time as a result.
Of course, you don't want to overload your stakeholders mentally. To address this and overcome challenge 2, I divided the board into multiple sections. The idea was to position overarching aspects at the top of the board and elements lower in the hierarchy below. It was structured as follows:
- The goal/objective: What do we want to achieve together?
- Scope & constraints: To prevent us from focusing on things that are not relevant during the workshop.
- What is the epic?
- What are the features for this epic?
- What are the requirements, needs, or wishes for each specific feature?
- Are there any known edge cases for this feature?
- Are there any remaining items that we need to investigate for this feature?
As the facilitator, I repeatedly guided the participants through sections 4 to 7, focusing on one feature at a time, discussing its requirements, needs, and wishes, identifying potential edge cases, and addressing any remaining open points. This leads to a clear and organized overview of insights grouped under each feature, preparing for the next step, like utilizing these insights to create suitable user stories in Jira and refine my approach.
After that, it's a matter of working on the features of the app in short cycles during sprints. Each sprint, which lasted 3 weeks at Essent, covered the following aspects:
- Setting up calls with stakeholders or team members to gather more insights is important. While the workshop provide a broad view, the detailed work occurs during interaction design.
- Work out the UI and connect them with flow lines to understand user steps and interactions. Doing so allowed me to streamline the process when needed.
At that time, I also had to face another challenge.
Challenge(s) and solution(s)
- How can I ensure a seamless experience when integrating this native app with other products within the organization, especially when dealing with white-label restrictions?
I accomplished this by using existing Essent Design System components and following its guidelines for elements like buttons, fonts, colors, icons, tone, layout, and images from the Essent database. However, because it's a white-label project, there are instances where some functionalities can't be changed.
This is because Vandebron wants to roll out updates for multiple applications simultaneously, and developing entirely new components for the app, as Essent requests, would be impractical. In that situation, I had to initiate a contribution process to design an Essent-specific variant of the component that couldn't be replaced (e.g., the segmented control) and store that in the native app Library.
Other aspects part of the sprint are:
- Scheduling meetings with stakeholders and developers for feedback and feasibility checks. Tip: A product or service is never really finished. User needs change over time, which is why organizations often work iteratively. The same goes for stakeholder needs. To keep things moving, it's essential to have a limited number of feedback loops. During a sprint, I usually have two of these loops before focusing on the final approval. This helps in better managing expectations.
- Plan regular handover sessions with developers. To maintain efficiency, I prefer to work in parallel and ahead of the developers. In various organizations like Essent, two weeks is the standard.
- Lastly, conducting small validation sessions with colleagues.
This leads to challenge number four.
Challenge(s) and solution(s)
- How can I validate the design when the organization is hesitant to allocate resources and budget for end-user validation at this stage, considering it's a white-label project based on an app already validated with users?
Validate a little with colleagues within each sprint, preferably colleagues who are not involved in the project, and frame it under the motto of co-creation (I know, sometimes you have to be sneaky). By conducting a small test each time, it feels less intrusive, and it helps iron out any initial issues. Research indicates that validating with biased colleagues is better than not validating at all.
After multiple iterations, I've not only created UI designs for the entire app but also developed a user flow that maps out the use and edge cases. This makes it easier, for example, to explain the designs to stakeholders (especially during a demo with many colleagues who aren't involved in the project). It also simplifies the process of onboarding the next UX designer to the project. As a freelancer, I place a high value on transferability!
Challenge(s) and solution(s)
If you thought we were done, think again! Designing a native app also involves working on tablet designs, App Store screens, and the app icon. Fortunately, transitioning from mobile to tablet is smoother since it prepares you for dealing with limited screen space, often referred to as "mobile real estate." This is why I addressed tablet design after finishing the mobile designs.
In the last few iterations, I concentrated on adding the final touches, including refining the app icon and store screens. I kept this step for the end because it had the lowest priority. Also, creating the app store screens required screenshots of both the app and tablet, which only became available later in the project.
Challenge(s) and solution(s)
.png)
Challenge and solution
.png)