Case study: From research to design and back
Elli, a brand of Volkswagen, is a company that provides energy and charging solutions to private consumers and businesses. One of the products Elli offers, and the one I worked with mostly, is the Elli app which allows electric car drivers to charge their cars at public stations or at home. The app is currently available in Germany on the App Store and Play Market.
For 8 months, I did an internship at Elli as UX Researcher and was happy to work in a friendly environment where user always has a seat at the table. I always look at design and research as non-separable fields, so I also actively engaged in UX design in addition to research activities.
This article is dedicated to a case study of re-designing a flow in the Elli app, a story of how we went from research to design and back — and what we learned from it.
Why research and design should not be separated
You definitely heard about design thinking, double diamond model or many other concepts that promote one simple truth — research and design cannot be separated. They depend on each other and should organically emerge from each other. This seems logical — why do some companies then get it wrong?
While the importance of research seems generally accepted, some companies still view research and design as important but separate activities — let’s do some research while we’re designing those screens! In this case, research does not inform design decisions but is viewed as just another activity that ‘they have to do’.
The findings from such research are presented and lost, while the design process continues to happen, based on assumptions. Those valuable stories and comments from your users can’t be lost in vain — so here is a case of how we at Elli took design decisions based on what our users think, and what we learned from it.
The story of one re-design
Focus of this case study
For this case study, we focus on those users who subscribe for public charging in Elli app. They would need a charging card from Elli to have access to those services.
A new user would:
- order the card in the app
- receive the card per post
- add the card to the account
- set the card as default for public charging.
We had the initial design of this flow implemented in Elli app (we further call it Version 1) — but we wanted to iterate once again because of some design flaws we noticed. Elli design team created an exploration of how an improved flow could look like. In this article, I focus only on the last two steps of the flow: adding card and setting card as default for public charging.
Adding card to account
Below I present the original (Version 1) and re-designed (Version 2) screen that users see when they haven’t added any charging cards to the app yet. In Version 2, we assumed that natural language in copy would help users better understand the action and its consequences.
Setting card as default for public charging
After users add their card by entering the card number or scanning QR code on the card, it is important to go through the last crucial step before they can use this card for public charging. A user should indicate that they want to use that card as default with their public charging subscription.
However, in the original version we failed to pay enough attention to this step— users directly received a warning that the card was not paired and can´t be used for public charging (I describe this warning later in the article). In Version 2, we decided to give more importance to this step by adding a dialog explaining the concept of setting card as default, as you can see below.
If the user skipped the dialog and decided not to set card as default for public charging, they would see a warning telling them that the card cannot be used for public charging, as shown below.
In Version 2, we shortened the warning and changed its positioning to ensure the user notices and understands the message.
How we tested the re-design
We decided to conduct user research before going forward with this re-design. In this case, we went for a moderated usability test because:
- there were specific aspects of the flow users could misunderstand, so the moderator would be there for asking follow-up questions to assess whether users succeed in performing usability tasks
- if the flow proves to be too complex, the moderator would support users to make sure the test keeps going.
We tested Version 2 of the design with 5 participants from Elli’s internal user pool — and we identified 12 issues that led to misunderstanding or confusion. We ranked those issues by importance (low, moderate or critical) and the amount of effort we would have to put into solving them (easy fix, exploration needed or needs discussion). This helped us focus on the most critical issues first.
Below you can see an illustration of how users on average reacted to the flow at different stages.
Iterating based on user feedback
Based on the analysis, we realized our re-design needed further tuning — so I did a deep dive into the problems and, supported by feedback and endless ideas from Elli’s design team, I created Version 3 of that flow.
Adding card to account
Problem: The preview of an ordered card did not make it clear to users that the card is on its way and there is no further action needed in the app until the card is received.
Solution:
- Show dotted card, like it was in the original version.
Users could not know how the card would look like when they receive it and showing a card preview confused some of them: is the card already in my mailbox? - Use an illustrative icon to make it clear the card is on its way.
The icon visualized our message, while adding some personality to the app and making the entire experience feel less formal. - Change wording: ‘add card’ instead of ‘activate card’.
We understood that the more natural terms we use, the easier it is for users to find their way through the app. - Get rid of ‘Inactive’ card label.
We tried to make it clear that there is further action needed until the charging card can be used. However, the new label did not help — it was just another term that required explanation.
Setting card as default for public charging
Problem: Users got confused about the wording ‘set as default’ as well as about the ‘Active’ label on the card, even though they could not use it for public charging yet.
Solution:
- Change wording: ‘pair card’ instead of ‘set as default for public charging’, like it was in the original version.
Even though we expected ‘setting as default’ to be a more natural action, it proved even more confusing. Users could not understand why they should set card as default if it was their only card added. - Re-design the dialog that asks the user to pair the card.
We shortened the text, rephrased action items and added an illustrative icon to catch users’ attention. All of those actions were aimed at making sure the step is not skipped, which was the case in Version 2 when users thought dialog was a confirmation message.
- Get rid of the ‘Active’ card label to avoid confusion.
Same as with ‘Inactive’ label before, we realized that labels were just making it harder for users to understand what the next required step is. Moreover, a combination of ‘Active’ label with a warning was not logical. - Make the button more prominent.
We changed button color to Elli accent color, so users would recognize easier that it is clickable. - Add an explanatory note under the button to let users know the consequences of their actions.
If users need further clarification of what pairing is and why it is required, they should find an answer in the explanatory note.
A/B testing the new version
Even though our design decisions were informed by the moderated test, we decided to go further and test Version 3 against Version 1. In this case, we conducted a quick unmoderated A/B test. We divided the total of 20 participants into two groups and asked both groups to perform 2 tasks: adding card to the app and pairing this card to subscription. But one group did it with Version 1 and the second one — with Version 3.
As a result, adding a card was easily performed and understood by both groups. However, pairing a card was not clear enough for users who interacted with Version 1 of the design — only 63% of those actually understood why and how they should perform this action. In the other group that interacted with Version 3, all users performed the action right — and around 90% of them understood that the action is required to use public charging services.
So what?
During the process of designing (and re-designing 🙂) products, we often feel as if we were acting blind — and sometimes we are. Getting insights from users is quicker and more useful than many designers think, and it actually gives us the input we often lack when trying to come up with new ideas for improvement. The A/B test I described above only took me 3 days, from setting up to getting results, but it also made me incredibly confident in the design I suggested.
