Role

UI, Research, Prototyping, Testing

Timeline

April-September 2020

Tools

Figma, InVision, Optimal Workshop, UserBit

Scope

Complete redesign of the MÁV app, based on user feedback as well as primary and secondary research data, interviews, and insights

Goal

Create a wireframe, prioritize features, test prototypes with users

Platform

iOS 13 and iPhone 11 Pro

Deliverables

Persona, wireframe, clickable prototype, hi-fi screens

How I Redesigned the MÁV App for Hungarian State Railways

Disclaimer: I do not have a contractual relationship with MÁV-START, and the recommendations in the case study below reflect my professional opinion only. Unlike the designers working at MÁV-START, I do not have access to all the research and analysis data that had impacted the development of the current version of the MÁV app. Consequently, this case study cannot be considered complete, nor do I claim that MÁV-START should accept the recommendations described below in all circumstances.

Introduction

I've always loved traveling. I had my first train journey when I was five years old, as far back as I can remember. Later as a student, I traveled weekly.

The Hungarian State Railways (MÁV) experience meant this for a very long time:

Then things slowly started to change to their advantage; MÁV started to modernize. They seem to have been paying more attention to the passenger experience for a while.

Today, trains are clean, have free Wi-Fi, and offer an electric outlet for work.

How It Began

At MÁV, online ticket sales initially took place on the Elvira platform. It has a unique, long history, which I wouldn't go into details now, but it's worth knowing that in 2004 it was one of the first Hungarian websites where you could shop online.

Since then, a lot of water has flowed down the Danube, and MÁV may have felt the need for change because time has passed over Elvira.

Not only is the user interface outdated, but unfortunately, in 2020, Elvira still cannot be appropriately used on a mobile device. The website is not responsive, and there is no mobile-optimized version, which is unfortunate because, with the gradual increase in the number of mobile users, at least half of the people now browse the web from mobile.

In response, MÁV came out in 2018 with an Android and an iOS application whose undisguised goal is Elvira's deposition in the world of mobile train tickets.

Through the apps, passengers purchased 'only' 880,000 tickets in 2018, but by the end of 2019, the number of tickets purchased on mobile had reached 4.6 million. Add to this the fact that the registered user base of the MÁV app exceeded 283,000 in February 2020, which is a considerable increase.

It is no coincidence that, according to the statement of the CEO of MÁV-Start, the company's goal is now to reach 60 percent in e-ticket sales by mid-2021.

Spectacular development and admirable ambition, but user opinions about the MÁV app are, to put it mildly, divisive.

Anomalies

The basic idea of ​​train tickets purchased on a mobile device is good and useful. Still, the checkout flow—especially concerning train search and selection of passenger discounts—was not thought through by the app's creators.

And this, coupled with negative user feedback, is a straight path to revenue loss, rising opportunity costs, wasted resources, growing passenger dissatisfaction, and persistent brand erosion.

I also ran into a usability problem in February 2020 during a Budapest-Miskolc train journey. I think even if I hadn't used a similar app before, I should still be able to buy a train ticket in 10 minutes on my smartphone.

Unfortunately, since it did not work out for the first time, I decided to redesign the MÁV app from scratch (precisely this one).

Since I'm geared towards UX since early 2020, I wanted to see what value, as a designer, I can add to a product with a large user base.

Finally, with my recommendations below, I would like to help a vulnerable state-owned company create a high quality, valuable, and useful mobile app that will generate more profit for the company and delight passengers.

In this case study, we will cover the following topics:

1. Meeting users and getting domain knowledge (Empathize)
   
2. Defining the core problem (Define)
   
3. Brainstorming ideas (Ideate)
   
4. Creating a clickable prototype (Prototype)
   
5. Conducting usability tests and validating ideas (Test)
   

1. Meeting Users and Getting Domain Knowledge (Empathize)

In retrospect, one of the most useful steps in the entire project was to define design guidelines.

These guidelines helped a lot in keeping focus and deadlines, prioritizing, documenting the project, and making day-to-day decisions (e.g., choosing from many right solutions, deciding what to include in a prototype, determining whether the function or form is more important for the UI).

At the beginning of the project, I defined the following design guidelines:

Then I interviewed 24 users to map their travel and ticket-buying habits and conducted usability tests on the MÁV app with 15 users.

With the interviews, I had the following two main goals:

• Find out how the target audience finds and buys train tickets
• Find out what are the most problematic, flow-breaking elements of the MÁV app

Competitive analysis in Miro

And then interviews, research of similar mobile apps (Omio, Trainline, SBB Mobile, DB Navigator, Oui.SNCF, SJ, Rail Europe), and more than 15,000 user reviews in the App Store and Google Play revealed that passengers expect the following features in a train ticketing application:

• A logical and straightforward interface for buying tickets and searching for trains.
  
• Real-time information about the journey (delays, diversions, accidents, platform data) when searching and buying tickets.
  
• Print a ticket or send by email in PDF.
  
• Purchase as a guest (without registration).
  
• Real-time reservation system for Intercity trains and consideration of extra needs (e.g., a forward-facing seat, availability of an electric outlet).
• Sync traffic data with the railway information system.
• Mobile payment (e.g., Apple Pay).
• Store tickets on mobile (e.g., Apple Wallet).

The most significant issues I had to address during the redesign

The most requested features based on the interviews

Anyone interested in the details could dive into the pain points of MÁV app users and the possible features of an ideal train ticketing app based on my research here:

• Pain Points – Affinity Diagram
  
• Potential Features – Affinity Diagram
  

Empathy map

It seemed feasible (at least from a developer's point of view). However, two things ruined the original concept:

1. It doesn't make sense to cram more than five features into a prototype that needs to be built quickly for testing.
2. The usability test of the MÁV app revealed underlying problems that I had to fix as soon as possible.

These underlying problems were the following:

• 40% of users cannot leave the first screen due to usability issues (and as a result, they would prefer going to a ticket office and buy a ticket there).
• It is difficult or impossible to select passenger type and discount.
• It is not clear how you can add two different passengers and select various discounts for them.
• The user interface is illogical, complicated, and chaotic.
• The app requires a relatively large amount of cognitive processing capacity; it is difficult to navigate (the typical problem is that the users cannot start searching for trains because they do not find the relevant button).
• On the Home screen, some of the search conditions and services are unnecessary and not used.
  
• The iOS 13 native date picker is challenging to use (some said the selection bar was too small; others prefer a solution used in similar apps).
• It's hard to tap the otherwise not-so-conspicuous Cart icon with a finger, and several users have shuffled to a completely different screen because tapped in the wrong place.
  
• It's frustrating to have too many redundant fields in the billing section (e.g., users don't know why they need to enter their date of birth, etc.).
• Registration as a company or an individual is not straightforward in the billing form (users don't see the difference in selection status)
• Error messages are difficult to interpret (e.g., for passenger type).
• Confirmation messages are missing, or there are no buttons to select and proceed (e.g., missing Next/Back/Buy button in the flow).
• In the train search results, the list could be more transparent and clear.
  
• Tickets are only available in the app (you cannot email tickets, nor can you take screenshots of them).
• The current app offers only one payment option.

Flowchart for the MÁV app (click to enlarge)

After analyzing the research data, the following two personas represented the users of the MÁV app:

The next dilemma was how to include all the content (train information, discounts, menu items, journey details) in the app.

This method was the initial idea.

However, it failed in the user tests.

I tested the concept with the Treejack tool in Optimal Workshop, and the image below clearly shows that unfortunate users ran around like poisoned mice in each submenu.

Testing the information architecture in the app

If the original idea didn't work, let's ask the users what menu system they think would be the right solution.

Plus, at the same time, I tried to sort passenger discounts into logical groups with the users.

Because the two card-sorting tasks in Optimal Workshop required too much mental effort, many people clicked through on the first day, but few completed the studies.

So I had to get testers as soon as possible. That's when the idea came up to buy a couple of online gift vouchers from a Hungarian book store and post them on Facebook to incentivize participation. It worked great, and I got valuable insights.

Recruiting test participants in a private Facebook group

Later the following idea came up for the tab bar:

And I have added the following features to the MVP for testing:

• Search for a trip
• Buy tickets with student discount, without extras and seat reservations
• Tickets for previous trips have been removed from the 'My Ticket' menu, and only the most recently purchased tickets remain
• The payment method is the same as in the current MÁV app
• The purchased ticket appears in the My Ticket menu with a QR code
• Instead of Profile, Settings will be the third menu item (see image above)
  

After researched the context, domain, business and user requirements, technology limitations, and similar apps and conducted user interviews and created personas, I was ready to define the core problem.

2. Defining the Core Problem (Define)

It's a fact that with the spread of mobile devices and mobile broadband, more and more people in Hungary are now shopping online.

On the other hand, in rail transport, the share of train tickets purchased via digital channels (web, mobile, ticket machines) is still lower than tickets purchased offline: passengers buy 60% of tickets at ticket offices and 40% via digital.

The top management's declared goal at MÁV-Start is that the digital channel should reach 60 percent of all ticket sales by mid-2021.

However, there are some limitations to this:

• Technological and digital maturity of the company
  
• Limited resources (time, money, professionals, etc.)
• Dependence on the Hungarian state
• Public procurement procedures
  

Based on the above facts, I defined the core problem as follows:

Based on my hypothesis, the solution is a complete redesign of the MÁV app from the ground up.

I present the rationale for this through designing, testing, and iterating the MÁV app prototype.

I based all my decisions about the prototype on data obtained from user research and usability testing.

My goal was to develop an app concept (an MVP) that MÁV-START could later develop—as fast, efficient, and value-added as possible—into a thriving, full-featured solution.

3. Brainstorming Ideas (Ideate)

After having defined the core problem and created a hypothesis for the solution, I sought answers to the following questions to build a prototype for idea validation:

• How might we empathize with our primary persona, Eszter, when she opens the app?
• How might we redesign the user interface so that Eszter can use it more easily on the go?
• How might we simplify selecting passenger types and discounts?
• How might we redesign the train search feature without having to fill out many fields?
• How might we show the train search results in a simple, logical, and clean interface?
• How might we speed up the process of presenting the purchased e-ticket to the inspector?
• How might we alleviate the negative sentiment of a payment transaction and simplify the entire flow?
• How might we give positive confirmation to Eszter that she had successfully caught her train?

Eszter's user journey (click to enlarge)

Based on the ideas, I ranked the possible functions of the prototype in the following value/effort chart:

4. Creating a Clickable Prototype (Prototype)

After researching the domain, defining the problem, and generating product ideas, I made various user interface sketches with pen and paper.

And then these sketches were followed by wireframes in Figma:

Each screen had to go through the usability heuristics, so I evaluated them one by one and fixed them if something was wrong.

At the end of each iteration, I performed rapid usability tests and implemented the next iteration insights.

Thus, the interface gradually changed in parallel with the tests.

Wireframes in Figma

The scenario was that one of our personas, Eszter, would travel home to her parents on 21st May 2020 from the Budapest-Déli Railway Terminal to Székesfehérvár.

She buys a single ticket, is already logged in to the app with her user account, travels with a student ID, and selects a regional train.

She pays HUF 1,300 in the app with her debit card; she doesn't need a VAT invoice. She shows the e-ticket to the inspector on her smartphone.

In the next section, I will show the usability testing process and the results.

5. Conducting Usability Tests and Validating Ideas (Test)

I performed the usability tests in InVision. I chose InVision because Figma's prototyping and user testing function seemed cumbersome and complicated compared to InVision. Though, it's a matter of taste.

So, I exported the screens from Figma, uploaded them to InVison, and then connected the individual screens. Then I got a clickable, more or less interactive prototype, which was already enough to gather user feedback on the concept's usability.

However, the early version of the prototype failed due to the following issues:

• It is challenging to use dropdowns on mobile (here's why).
• Users can only move linearly between each search field (departure -> destination -> number of passengers -> date).
• The passenger discount screen is too complicated.
• It is not clear from the passenger icon that you can select a discount on the Home screen.
• The language of the app feels robotic.
• The station list is complicated and challenging to navigate.
• The labels on the CTA buttons are not clear.
• The button and font size is too small considering the context (e.g., buying e-tickets on crowded trams).
• Since I didn't follow all the best practices, the forms' usability is low (I have identified several issues based on this guide).

I fixed all of these problems in the next iteration. I continued user testing but then ran into even more issues.

In the second iteration, I had to fix these issues:

• I haven't grayed out non-clickable, deactivated fields on the Home screen.
• The Discounts and passenger types button does not have a separate Discounts field.
• The Discount slider is not disabled by default (users may accidentally select a discount).
• The label for the confirmation button isn't clear enough.
• There are no wizards, progress bars, or breadcrumbs in the searching and booking flow.
• Since the autocomplete fields accept less than three characters, it's challenging to implement the query through code.
• The Today or Now button is not displayed by default.
• The notification about delays is too prominent in the UI.
• The Recommended option is not clear enough, at least compared to the Popular choice.
• There is no clear Back and Buy button in the purchase flow.
• The X button does not indicate that users have canceled the flow consistently.
• A VAT invoice option is missing.
• The language of the payment confirmation sounds robotic.
• The user is too directed when purchasing a ticket.
• The language and currency settings are unnecessary in an MVP.

I fixed the issues in the next iteration and tested again.

Proof of concept

And this time, the booking process was completed by all users.

The results were the following:

• The interface is simple, logical, transparent, and user-friendly, compared to the current MÁV application.
• Users can complete the ticket search and checkout flow in five minutes.
• The UI elements are logical, and the text is readable.
• There are no unnecessary forms and fields in the app.
• There could be more visual weight on the status of the Single ticket button.
• Many users want to select the departure station first. However, each user should be able to start the process from anywhere.
• Three users tap the Save button immediately after activating the 'Discount' toggle, but forget to select the discount type: more visual weight could be added here (e.g., mark the blank field in red).
• The Sort by Departure icon is not evident.
• There are no Save or Export options for the tickets.
• The option for changing the billing info is easy to find in the settings.
• We could rename the option 'OTP Simple' to 'Pay with Card' because it's not clear for some users.
• In the flow or the user onboarding, we should fix the following issue: some users do not buy a ticket in the MÁV app because they are afraid that they will miss the train, and as a result, they go to a ticket office. Also, they do not know that the ticket is valid for 30 days from the purchase.

Based on the above results, I created the following high-fidelity screens:

Summary

Below, I would like to quantify the MÁV app project's top results, share a few ideas for the future, and draw some key lessons from the last six months.

Outcomes and Achievements

In the official MÁV app, 40% of ticket buyers could not get past the first screen. In contrast to this, all users of the prototype could go through the booking process quickly and easily without getting stuck.

In the official MÁV app, only 20% of ticket buyers could choose the passenger type and discount. In contrast to this, all users of the prototype were able to perform this task.

And last but not least, each test participant used the prototype with delight, unlike the official MÁV app.

Before

After

Comparison of home screens (left: current MÁV app, right: the prototype with a redesigned home screen)

Next Steps

A redesigned and optimized application can offer MÁV many benefits. Just a few ideas for the future:

• We could reduce the workload of ticket office employees.
  
• We could measure the number of new and returning passengers using electronic channels in real-time.
• We could offer additional extras to the app users.
  
• We could better customize the entire passenger experience.
• We could increase MÁV's reputation.
• We could improve the service quality through the app (e.g., passengers can chat with each other on the train or send messages to the buffet personnel via mobile).
• We could improve the load distribution of railway carriages and railway terminals.
• Conversion tracking is possible.
• The app can run much faster, thanks to the prioritized features and a smaller codebase.

We might also introduce a joint ticketing solution in which passengers could buy their bus and train tickets in a single interface.

I reached out to MÁV-START with the concept outlined in this case study.

As soon as I have any info about the project, I will update the case study.

Reflection

Finally, I would like to share some lessons I learned in the previous six months:

• The design guidelines defined at the beginning of the project helped a lot, and any similar project should start with them.
• It is worth building a clickable prototype as soon as possible to uncover early issues in usability tests.
  
• You should not fall in love with your ideas because users, clients, circumstances, or stakeholders could ruin them anytime.
  
• Learning to let go of your best work in your users' interest is one of the most challenging things for a designer.
  
• The design process is not linear but a cyclical one.
  
• Different methodologies (design thinking, design sprint, agile, lean UX) are not sacred dogmas: they are just tools for solving a specific problem.
• The final prototype to be sent for development is not the last step in the product development process: after launch, you should also consider feedback and data from key performance indicators (KPIs) and, if necessary, you should iterate further or pivot entirely.
• If you think a redesign is expensive, it's worth looking at the costs of a flawed design (see the section 'Anomalies' above).

For me, it was incredibly useful to decide what to delve deeper into (e.g., problem definition, prototyping) and learn from my own mistakes (see the section 'Reflection' above).

But best of all, the learning process is still not over.

New challenges and opportunities will await in a new project.

* * *

Special thanks to the following individuals for their invaluable help. Without them, this project would not have been possible:

• Klein Péter
  
• Szűcs László
• Kiss Ágnes
  
• Sebestyén István
  
• Árpás Anna
  
• plus many test participants, interviewees, and supporters
  

Thank you for scrolling!

Got a Mobile App Project?

Let's build something great together