There was only eight weeks to carry out research, test a prototype and iterate on a final design. Our process was first to understand who Irish Rail customers were, the problems they were having and the top things they needed the online services to do. From there, we defined the problem. Next we hypothesised some solutions around booking a train & checking train times and tested those designs as interactive prototypes. Finally, we learned what worked and what didn’t work so well.
- Understand the users of irishrail.ie and their needs
- Define the problem statement.
- Identify the major pain points with irishrail.ie
- Prototype & test a new solution
Phase 1: Understanding the users
The main reason for gathering data at all is to glean information about something [^Preece, J., Rogers, Y., & Sharp, H. 2015]. In order to know we we needed to research, we first needed to derive at research goals. I listed out what we needed answered before we could define what what I was designing and who for. Here are the main research goals I set out for the project:
- Identify any usability or user experience issues and any barriers / drivers to use.
- Understand current behaviour and experience of Irish Rail user
- Identify any usability issues when booking a train online.
- Evaluate the top user tasks of the Irish Rail website.
- Evaluate the efficiency of the Irish Rail website and measure it against user experience.
To get a broader understanding of who the irish rail customers are and how the user the service, we sent sent our a survey. The survey finding showed that the top issues with website were with the user interface of the website, the lack of flexibility with the booking process and the inability to quickly train information.
We also learned that some of the major issues with the website were also the top tasks that customers used the website for. Check train times, buying rail tickets and seat availability were the major features that customers used online.
Interviews and observations were done with 6 participants in total. From our initial survey research we learned that there was about a 50/50 split in leisure travellers and commuters so we decided we’d talk to both as part of research.
One of the best ways to understand people’s experiences is to see them for ourselves [^Kuniavsky, 2012]. Direct observation was carried out in a controlled environment on interview participants so that we could fully understand the issues that the users were having and to see how they carried out a specific task.
We used card sorted to help understand the top tasks carried by our commuter participants. Since some of us on the team we're commuters ourselves, we knew that they was going to be only handful of features that a commuter needs from the website. So we asked them to sort the tasks as cards from top to bottom going from most important to least important to their needs
Phase 2: Defining our users & gathering requirements
Through user research I defined the user archetype that helped to guide in making product features, navigations and design decisions. Here is the persona that was created for this project.
3. Ideation + Prototyping
We had about one week to conceptualise and test the first iteration of prototype. Our first port of call was to work out the all the features that are required so that the user can carry out tasks using the website.
We utilised Jobs to be do from Intercom to help use figure out what some of these task might look like.
From here we mapped out how the user journey might look like by co-designing the user flow by way of white boarding.
Once we had a general idea of the user journey we began to work in paper for our first iteration so it meant that we could quickly try now ideas and not become attached to them if they didn’t work.
For specific user interface challenges we used crazy eights from the Sprint book to quickly conceptualise many different solutions to one piece of user interface.
Next we used Axure to create a user flow and start bringing some interactivity so that we carry out our first user tests.
Phase 4: User Validation + Iteration
Through user testing on two iterations of the prototype the following issues emerged:
- Seat selection was found to be confusing
- Users didn’t get any error messages when issues occurred in the user interface and found labelling to be confusing.
- Users had trouble distinguishing between outbound and return journeys.
- User is unsure if seat location is selected
- User felt that that the system was too restrictive and didn’t allow them to change journey details during the purchase path
Our seat selection feature still caused pain to our users. First, the users we unsure as to what direction a seats were facing, secondly the were unsure as to what facilities we available close to that seat. To overcome this, we presented two different solutions help ease this problem.
User interface issues
It was evident from our first usability test that there was clear labelling issues especially around the main call to action on our ‘live times’ ‘times only and ‘add ticket’. We resolved these issues in iteration two however, we then experienced the issue of the user clicking the wrong call to action for purchasing a ticket. In iteration 3, we resolved this by keeping the secondary CTAs inline with the form give to more visual prominence to the ‘check times & prices’ button.
Distinguishing journey details
Another thing that emerged from testing was that the users were not sure of which column of results for the outward journey and which for the return journey. In addition, they were confused when the user saw open return the did not know to click it or when they had clicked it it they were unsure of what to do next.
We resolved this in the second iteration by introduction a journey details area on the right hand side that would populate as the user makes their outward and return journey selection.
Final Prototype can be viewed here
Phase 5 Visual Prototype