In this post I will outline the journey from our first iteration to our third iteration and will document the changes we made along the way based on user feedback.
For the purpose of explaining the changes made I will talk through each step of the user journey and changes that were made on that section at each iteration.
Testing Findings Summary
User Test 1 Findings
- Mistaking secondary actions for primary actions.
- Missing error messages.
- Trouble distinguishing between outbound and return journeys.
- Open return feature on wrong page.
- Confused train journey length for departure time on results page.
- Dates were inconsistent across some pages causing confusion.
- Must select arrow on date field for calendar.
- Path to completion encouraged using the wrong call to action buttons.
- Page layouts caused too much scrolling.
- Could not view where change of train was.
User Test 2 Findings
- Thought selecting open return would complete form and change page.
- Selected open return and then didn’t select departure dates and times.
- Found “Add Ticket” button wording confusing.
- Panelling form gave impression it was 3 forms.
- Open return message looks like an alert box.
- Found text too small in areas.
- Empty journey details section confused user.
- User is unsure if seat location is selected.
You can view the full test findings for both user tests below:
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.
Supporting the tasks carried out around the one form
As discussed in the previous post, the are a number of tasks that our persona carries out through the same form such as a check times facility to allow for John to plan his journey and have the ability to save a journey to book later. In addition, we needed to create an easier for John to be ably quickly check return times and the ability to easily check the status of the trains.
With this we needed to have clear jump off points to that the user can clearly see and understands.
Time range issue
As mentioned in a previous post, there was a technical bug in axure that made our time range selection to perform badly in our first round of user testing. For this reason we had to revert back to a standard time dropdown for the second round of testing.
A gif how the time range selector should have worked.
Train results page
As you would have seen in the ideate post, experimentation was done on the results page. However, the feedback was that it felt too different to what’s currently on the website. For that reason I revisited how the the key information of the train times could be displayed any strip away any unnecessary information. Because John is travelling from Cork to Galway it is important to denote that he is required to make a change on his journey.
Allowing for user to change their mind with edit details facility
From our first user testing session it emerged that there was no ability to change the journey details without having to start over. In the second iteration of our prototype we introduced change details section about the search results where the user could change the outward journey toggle between an open return or standard return journey.
Consistency in displaying journey details & call to actions.
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.
The lack of visibility of the on call to actions (CTAs) and price information also threw our users. To resolve this, we design persistent CTAs that would be display on the page but be in a disabled state until the train selection(s) had been made.
Select seats page
As outlined in the requirements section of the define post, seat selection was a major pain point that needed to be review. Overall, our new design for seat preference selection was well received. However, in our first iteration our users felt that the were too many options to choose from. To overcome this, we we changed the layout to have a graphic of the train to from which they could choose the location in which they wish to sit and also the direction the wish to sit.