Students redesign Swedbank’s mobile banking app UX
How we identified, prototyped and tested two UX improvements for a popular mobile banking app.
This is the story of how a group of students redesigned Swedbank’s mobile banking app.
The main goal of an app is to make our lives easier. The job of a mobile payment app is to help us make faster and better financial transactions, all from the comfort of our mobile devices.
So when an app makes a payment process more difficult, we have a problem. We feel like the software and by extension — the company and brand are letting us down. Because, surely, apps are designed to add value to our lives, right? Not always.
The good news is that every problem can be identified, fixed, and tested. This is one such story.
Leading by example
Design is always human-centric first. If a modern website design doesn’t help a visitor find what they’re looking for, then even the hottest fonts won’t stop a potential customer from leaving. Great design happens when designers create products with their users in mind. We teach our students that in design, empathy comes first.
Hi, my name is Edijs and I teach UX (User Experience) and User Interface (UI) design. As a leading UX and UI designer, I’ve worked on projects as versatile as designing a social network for the Technical University of Denmark, to a virtual assessment platform system for SHL and everything in-between.
Being an avid believer in continuous self-development (and not just doing work for the sake of work), I decided to teach. The best strategy for learning? Doing. In the often-quoted words of Lao Tsu: “If you give a hungry man a fish, you feed him for a day, but if you teach him how to fish, you feed him for a lifetime.”
Why Swedbank’s banking app?
Our students didn’t tackle Swedbank’s mobile app by accident. Swedbank is one of the largest banking services in the Baltic states. Its mobile payments app is outstanding. Except for two UX inconsistencies.
We chose to address Swedbank’s mobile app for two reasons:
- When I asked students to find UX problems that annoyed them daily, most of them mentioned Swedbank’s app.
- As a Swedbank client, some of the app’s usability issues had been annoying me for some time. I was curious to find out whether the students would identify the same pain points (mentioned below).
We’re publishing this as a case study because we want to encourage critical design thinking, especially in UX design. Critical thinking shapes what we know and how we got there. Conscious practice helps us improve our processes and do things better. More efficiently.
We hope this case study sparks a healthy debate about our assumptions and beliefs as designers.
This is a story of learning. Swedbank’s mobile app was an essential tool for teaching our students the importance of human-centric user experience.
We started with a brainstorming session, followed by a competitor analysis and further research on the ‘client’ — their products and their usability, as well as their underlying values. It’s important to note that we facilitated this learning process using best practices from the Design Sprint methodology, which we also practice with our business clients.
After several days of research and brainstorming sessions, the students presented the pain points they discovered. After some debate, we highlighted two main points that almost all users had trouble with:
- Requesting a payment;
- Seeing their payment history.
But first — why are some apps confusing?
User expectations are based on mental models. A mental model implies that users have an understanding of how a product works based on their previous experiences with similar products. Jakob Nielsen of Nielsen Norman Group explains: “Mental models are one of the most important concepts in human-computer interaction (HCI).[…] A mental model is what the user believes about the system at hand.” User mental models are based on beliefs, not facts. It’s what your users think they know about how to navigate any system.
The modern UX designer faces two main challenges: first — to anticipate the most likely user mental models and test their own hypothesis with user tests. The second is to remain aware of their own bias. UX and/ or product designers spend more time interacting with their apps and products than anyone else and are susceptible to being blind when it comes to seeing things from regular users’ perspectives.
Pain Point #1
Making and requesting payments
First, let’s look at making and requesting payments. Both my students and I had trouble understanding how to request and send money using Swedbank’s app. We found the app’s search box and the button on the payment screen confusing. Furthermore, the search box did not work as our mental models expected it to work. There are also no additional explanations on the button that could help guide users.
First, we wondered whether an option to send money existed at all. So we looked at other payment apps. We asked ourselves: “How do other payment screens work?” Together with the students, we went through several competitor apps and identified different user flows. The most common user-payment making flow was:
- “Find a person”
- “Make a request” or “send money”.
We then compared Swedbank’s user flow to that of their competitors, discovering that Swedbank app’s user-payment flow is more complex. To make a payment, users need to take additional steps.
1. When a user clicks on the search bar, a new screen appears with two actions:
- “New payment”.
2. Search results display the latest payments made, not user profiles.
3. Tapping on the latest payments made shows more information about the payments.
This flow is difficult to understand and navigate. We weren’t sure whether we could edit any information in the field due to a lack of any signs or instructions.
Simpler = better
After we answered the question of “how do other payment screens work?”, it became clear that Swedbank’s payment screen user flow is different from other payment app experiences. Swedbank’s app proved to contradict user mental models, confusing its users. The app’s payment sending and requesting functionalities work differently than users have come to expect from similar payment apps.
Our first hypothesis was: a simpler user flow (aligned with user mental models) would be easier for users to navigate. An easier flow makes it easier to send and request money.
Users don’t understand
The second question we asked ourselves was: “How user-friendly are the app’s components?”
In Swedbank’s case, there are no clear options to “send money” or “request money”. Instead, we have a search box with the inverted label to “make a new payment“ and a button with an icon to its right. We’ll get to the search box later. First, let’s examine the app’s turquoise button (below).
Based on our own experience, we assumed that this button’s meaning is difficult or impossible for users to understand. After all, a user’s understanding of an icon is based on their previous experiences and mental models. The blue circular button with a mobile/arrow icon inside didn’t explain the meaning behind the button’s action. What happens when we tap on the button?
This is where our second hypothesis came into play: the button’s meaning is impossible to understand.
Typically, when a user taps a search box, they expect to find a place for entering their search query. Instead, Swedbank’s app presents them with a new button. A button that invites users to “make a new payment“ (see the image below).
By deviating from the common mental model, the app experience becomes confusing. It’s difficult to understand what users can and cannot search for or whether they can search for anything at all. Nothing happened when we tried typing something into the search bar. Not even an error message popped up.
Well constructed auto-suggestions improve app usability
Baymard Institute’s autocomplete suggestion theory dictates that “when autocomplete suggestions work well, we observe that they help the user articulate better search queries.“
The autocomplete feature in search queries saves users several minutes. Revolut is a good example — clicking on the search bar shows users their recent transactions. Swedbank’s app, on the other hand, only reveals the ‘new payment’ button. No predictive search results or recent payments.
Our assumptions are that users search for payments based on receiver names (like in Revolut). For example, if you send money to a friend, the sum can vary but your friend's name remains the same.
Pain point #2
Finding a payment in ‘payment history’
The second pain point that many of our students came across was the app’s payment history. More specifically, payment history’s infinite scrolling behavior. Infinite scrolling is used when users aren’t searching for anything specific. They are then shown a large number of items to browse.
Issues arise when users are searching for something specific and not just scanning and consuming the flow of information. If it’s April and we’re looking for a transaction we made at that Christmas gift store in December, not having an option to search for the right transaction becomes problematic.
Pagination is better than infinite scrolling
Imagine having made 100 transactions per calendar month. That equates to more than 1000 transactions per year. How far back are you prepared to scroll to find the right transaction?
With our four hypotheses ready, the students started their research. We looked at a few competitors and similar mobile applications. Our insights, however, were still based on assumptions.
To recap, our hypotheses were:
- A simpler user flow (aligned with user mental models) is easier for users to navigate;
- The turquoise button’s meaning is unclear;
- Auto-suggestions improve usability;
- Pagination works better than infinite scrolling.
We now had to separate assumptions from facts and test our hypotheses.
We started by conducting user research. User research contains an umbrella of tools and methods for understanding product users, what do they want to achieve, what do they think of the product, and more. There are various ways to do this type of research. Borrowing from the Design Sprint methodology, we focused on user interviews, surveys, prototyping, and usability testing.
Student prototypes + solutions
We started with prototyping. A prototype is an early sample of design used for getting feedback and experimenting with new ideas quickly. This method provides designers with user feedback early on in the design process, helping them make iterations and improve product usability.
Each student prepared their own prototype, offering solutions to the app’s pain points presented above.
Solution to Pain Point #1
Making and requesting payments
First, students created prototypes for pain point #1 — making and requesting payments. The proposed solution was simple: adding two buttons — one for sending and one for requesting a payment (see below image on the right).
Well-written microcopy guides its users along the digital process. Poorly written microcopy confuses and frustrates them. Hence the words on the buttons — to send and receive payments are given priority.
Best UX practice dictated that both buttons are (and should be) more prominent than the turquoise icon (image on the left) since they offer users more convenient shortcuts, resolving the app’s complex transaction flow.
Solution to Pain point #2
Finding a payment in ‘payment history’
The solution our students came up with and tested was pagination — the process of separating digital content into discrete pages. Most students proposed scrollable tabs, each tab representing a specific month. This solution makes it easier to find the right payments. Users can jump from one month to another, no longer scrolling through all their payments.
Pagination, if placed at the top of the screen, helps users easily navigate through the different months. Our hypothesis is that pagination helps users find the right transactions faster and quicker.
Our solution to this issue is pagination (by month). Pagination, if placed at the top of the screen, helps users easily navigate through the different months. Our hypothesis is that pagination helps users find the right transactions faster and quicker.
Our next step was to conduct a survey. This helped us validate our prototypes and gather feedback on user experience with the current app. Our survey participants were shown 4 screens — two existing Swedbank app screens and two student prototype screens.
Our goal was to get user insights about:
- What users used each screen for — the screen’s purpose;
- What users thought they had to do within each screen-specific actions;
- Whether their perceptions changed based on the screen they were shown — existing vs. prototype.
Our underlying objective was to receive answers that would help the students design a product that delivers a better user experience. More than 100 respondents took part in the survey. Sixty-three percent of them are existing Swedbank clients. For brevity’s sake, we will only cover the most relevant responses.
1. What purpose would you use this screen for? (Current app)
Results: From all answers provided, the respondents overwhelmingly selected option “3 — See payments”.
- 58% of respondents said they use this screen for checking their payment history;
- 5% for money requests;
- 31% for sending money;
- 6% for all of the above.
2. What would you tap to request a payment? (Current app)
The goal of this question was to understand “where would users tap to make a payment?” Most respondents answered correctly, namely that they would tap option “1. seach field”. Keeping in mind, however, that 60% of the respondents are Swedbank clients, it means that the results include users with prior experience. Thirty-one percent of respondents answered incorrectly.
- 67% said the search field;
- 24% answered that they would tap the blue button;
- 9% said the E-reķini link.
We showed respondents the same image, also asking them a secondary question: “where would you tap to request money?“
- 56% answered correctly — the blue button;
- 31% responded that they saw no option to request money;
- 13% said they would tap on the search bar.
3. What would you tap to request a payment? (Prototype)
n our third question, we asked the respondents the same questions about making and requesting payments, except showing them the student-made prototype instead of the current app. Their answers confirmed our hypothesis. 91% of respondents answered both questions correctly.
- 91 % answered button one;
- 8% chose the E-reķini link;
- 1% said request.
4. If you search for a payment made a month or more ago, how would you describe this process?
We also asked our respondents to describe their experience of searching for past payments. We asked about a payment made a month or more ago. The responses were chiefly negative. Users found the process “complicated and time-consuming”. Some rated the search process as “not too comfortable”, others said it was “more complicated than searching on a website”.
Usability testing is the most common technique for checking your app interface usability from the human-centered design framework perspective. The power of this qualitative technique is that it focuses on what the user does, instead of says.
We conducted the usability test on 10–15 users. The users were asked to request money, send money and find an old payment.
We gave testers a mobile phone with the student prototype installed (using Figma). This created a realistic-feeling mobile app experience. The artificial experience was entirely based on student prototypes.
98% of testers completed our test successfully. When testing the existing app, however, some testers had trouble with the main task of sending money. 8 of 15 people first clicked on the round element of “money request”, and only then returned to the previous screen, only then clicking on the white area to “make a new payment”.
The usability test also revealed an improvement in the time it took people to complete a task. We measured how long it will take users to find and conduct a new payment. Testers spent around 1 minute 30 seconds completing tasks on the existing mobile application. In contrast, they spent only 35 seconds performing the same actions on the student prototype. User performance also improved by 1 minute.
The main goal of an app is to make consumer’s lives easier. Our students identified two UX issues with Swedbank’s mobile app. To tackle these issues, they first defined their hypothesis, then designed a prototype based on industry best practices and tested their prototype with real users.
Research data shows that, compared to the current app version, the majority of users participating in the tests found the student prototypes easier and faster to use. The test results also highlight the importance of user testing. After all, true product understanding is only strengthened through real-life practice and real user observation.
The mission of design thinking is to translate observations into insights and insights into products and services. It’s our privilege as design thinkers to watch what people do and don’t do and listen to what they say and sometimes — don’t say.
Thank you for reading! Please share your thoughts, feedback, and ideas — we’d love to know what you think.
Here’s what some of the students had to say about the exercise:
“The task was interesting because it included exciting intermediate tasks, such as evaluating the application itself based on good practice examples, formulating survey questions, and preparing optimized solutions. It was nice to discuss with colleagues how to get the most accurate information. My biggest benefit from this task was the discovery of a new testing method — I had previously used on-screen video recordings, but this time we also filmed hands, thus more effectively understanding what the process looks like from the users’ point of view.”
“I believe real case studies are key to a deep understanding of the desired profession. It might be that the only way to follow the real procedure used by professionals is to follow the lecturer’s step-by-step instructions. For me, this kind of assignment felt like an experiment in choosing a profession.