Redesigning the UK’s National Rail App
Malgorzata, Girika Upadhyay, Alex In The Dam, Maud de Boer
Last week, we completed our first group project at Ironhacks’ part time UX/UI Design course. This was, for some of us, our first introduction with the design thinking process, or EDIPT as I like to call it (aren’t mnemonic devices the best?)
Brief
This short ten-day project aimed to develop the ability to observe people’s behavior when navigating the interface and interpret their pain points, specifically when purchasing a train ticket. The first thing we had to do was select a rail service we wanted to investigate. Choosing the Netherlands’ train provider was too easy and not very imaginative, so we opted for the UK’s National Rail Service. The next step was to come up with a team name that was the name of a band. We had spent so much time trying to put our first survey together; we almost forgot about that step and randomly came up with Freddie Mercury’s Queen, which worked out because Queen is a British Rock band, so it tied in nicely with our service provider choice.
EMPATHIZE
Surveys: defining our target
So, surveys, am I right? (shout out Google forms and free logic capabilities). Who would have thought that putting together a survey was an art form? There are so many aspects to consider: do our answers cover all possibilities, are our categories well defined, how not to include leading questions, but wait, what about this and that, who do we want to screen out, are we being inclusive in our options? We wanted to include so many things that we forgot the most important, keep it simple.
After almost 4 hours, we had a survey we knew would allow us to isolate our user group, give us enough insight to create an in-depth interview guide and conduct interviews and usability evaluations which would yield enough information to continue with our process. The lean survey canvas was a useful tool that we can highly recommend for those who have never put together a survey before. Getting answers was the easy part. Today, with all the resources at your disposal, think: facebook groups, reddit, whatsapp groups, slack channels, etc, we quickly mustered up close to 150 responses and quickly discovered that:
- Out of all the age groups, 16–25 is the only age group more likely to buy tickets online and through a mobile app. 42% of all 16–25 are using a mobile app, compared to 29% for 26–35 years old, and 30% for 36–45 years old
- Every age group travels by train, at least yearly
- All age groups more likely to use a national service provider app rather than a 3rd party service
Interviews: defining the target’s pain points and testing the existing app
From our quantitative data, we could identify our target and quickly set up an interview guide. It is worth mentioning that the survey says 16–25-year-olds are our age group because 42% of people in this age group use a mobile application to buy their train tickets. We decided on doing two interviews and usability tests of the ‘National Rail Enquiries’ app each, to bring our total to eight. Useful insights from the interviews included the fact that:
- Users mostly want to plan their itineraries ahead of time
- Users sometimes feel unsafe using an app
- While on the other hand, people like the ease of use and convenience of apps as it avoids standing in a queue, and losing physical tickets
From the test we could see that:
- Users don’t like ads on mobile (who does?)
- The users didn’t quite understand why the home page of the existing app included an overview of live trains and previous journeys
- When users were trying to purchase a ticket, they couldn’t find the ‘buy tickets’ button
- Users liked the ‘live trains’ feature
You can find the main findings from our usability tests here, with the negative results on the left and the positive ones on the right.
DEFINE & IDEATE
With our usability tests done and our survey and interview finished, we were able to put together an affinity map and finally start to see where opportunities lied. We’ve finally came up with dividing our main findings into several sub categories such as advantages of using the train, and the disadvantages of using an application for online train ticket purchasing and the opportunities that come with it.
We were also introduced to cognitive and hierarchical task analyses. Those of you familiar with this concept might hear those words in that order and cringe as we did, however, their importance cannot be understated. Although probably the least exciting to actually do, they yield some pretty interesting results when compared to our usability testing. The major finding was that the main problem people had with the app uncovered during usability testing could also be easily identified during the cognitive task analysis, namely that there was in particular one redundant screen that confused people. This allowed us to put some ideas down on paper and think how we might create a clearer happy path for our users and the next step was finally putting something down on paper.
PROTOTYPE
Before we started with the prototypes, we wanted to figure out which problems we could solve and how much value this would add to the user. As we wouldn’t solve all the issues, we used the ‘Value vs. Complexity Quadrant’ as a tool to locate and prioritize the problems that we wanted to focus on.
We created a low-fidelity paper prototype to test some of our ideas. Our primary focus was on:
- Redesigning and simplifying the information architecture on the existing application
- Make the feature ‘journey planner’ the landing page, so that users can straight away check timetables and purchase tickets for their preferred itinerary
- Keep the ‘live trains’ option
- Remove the ads
TEST
By this stage, we were a little behind with our project. Ten days was not a lot to get all things accomplished next to a full-time job. In the end, we were only able to complete one usability test on our lo-fi prototype. The outcomes from this single test were to fine-tune the main feature and add a button or two for confirmation.
Learnings and Takeaways
For the first project, working together in a group with total strangers, we found this project very rewarding. However, there are some points worth mentioning. First of all, we got entirely carried away to discuss the questions in our survey and interview. In the future, we would include tools such as dot voting to speed up the process. Secondly, we would dedicate more time to the testing stage, as this probably would give us a lot of great insights.
Finally, the biggest takeaway of the first three weeks of this course and the first project must be: “Trust the process.” Do one part of the process at a time, and don’t get ahead of yourself. In time, insights will reveal themselves and opportunities for better design from those insights.
I’ve now written most of this article and just realized we haven’t mentioned our new found love Miro. Shoutout to Miro, a great collaborative tool that allows us to organize our information. The Kanban board was particularly useful in tracking our deliverables and making sure we respected self-imposed deadlines, but as we will see in our second project, the possibilities are almost limitless and the Kanban board was just the beginning.
Stay Tuned
