HCI - Group Report for Metrolink App

Human Computer Interaction (6G6Z1014_1314_9Z6) - Group Report

Group Report for Metrolink App!!Prepared By: UserCentric!

!Group Members:!

!!!!!

Darran Mottershead!

Aoife Turner!

Ben O’Brien!

Sanaa Juma!


Executive Summary!The purpose of this report is to expose the extensive flaws currently found within the existing Metrolink application, and the lasting impressions a user will have on Metrolink. Using the application in its current state provides a very limited user experience, with the inability to purchase tickets, or quickly find information of importance. This report will effectively provide a solution to the poor implementation of this application, by redesigning it from the ground up.!

A new fully-featured, simple design approach will be taken, and presented by one finalised high-level prototype. The finalised prototype will show the potential of what the Metrolink application will be able to achieve, once fully implemented onto the iOS platform.!

Creating a positive user experience, and improving the mobile presence of the Metrolink service is the primary goal. An entire redesign will keep the service fresh, and up-to-date with the current expectations of the Metrolink service users.!

In addition to redesigning the application, we further extended our goals to ensure the Metrolink service is accessible as possible. The use’s daily commute will be greatly enhanced by the Metrolink application, as it serves to provide relevant information based on location, and timing. The inclusion of notifications, real-time updates, location services and ticket purchasing, all on a mobile device, will expand the Metrolink service significantly.!

The problems plaguing the Metrolink application in its current state were resolved by including a number of new features. Most notably: Smart Journeys to quickly buy recent and most travelled journeys. Alarms on Arrival, a feature using location services to ensure the user never misses a destination. QR Codes, eliminate the need for a physical ticket, and provide a simple solution to providing evidence for business travel expenditure.!

!


Introduction! 1!

Report Overview! 1!

Goals and Objectives! 2!

Methodology (Steps of Development)! 3!

User Requirements! 3!

Initial Collaboration of Ideas! 4!

Navigation Diagram! 4!

Sketch Designs! 4!

High-Level Prototypes! 5!

How Usability Evaluations were Conducted! 6!

Results! 8!

System Usability Scale (SUS)! 8!

Neilsen’s Heuristics (Table)! 9!

Heuristic Evaluation Statements! 10!

Positive Elements of Individual Prototypes! 11!

Requirements Analysis! 12!

Personas! 12!

Scenarios! 13!

Functional Requirements! 14!

Non-functional Requirements! 16!

Design! 17!

Storyboards! 17!

Final Coloured Prototype! 23!

Reflection and Conclusion! 34!

Appendix! 42!

Task Allocation sheet! 42!

SUS Analysis of Group - (by Darran Mottershead)! 43!


SUS Analysis of Group - (by Aoife Turner)! 46!

SUS Analysis of Group - (by Ben O’Brien)! 49!

SUS Analysis of Group - (by Sanaa Juma)! 52!

Neilsen’s Heuristic Tables - (by Darran Mottershead)! 55!

Neilsen’s Heuristic Tables - (by Aoife Turner)! 58!

Neilsen’s Heuristic Tables - (by Ben O’Brien)! 60!

Neilsen’s Heuristic Tables - (by Sanaa Juma)! 61!

Heuristic Evaluation Statements - (by Darran Mottershead)! 64!

Heuristic Evaluation Statements - (by Aoife Turner)! 67!

Heuristic Evaluation Statements - (by Ben O’Brien)! 70!

Heuristic Evaluation Statements - (by Sanaa Juma)! 73


Introduction!

Report Overview!• Reasoning for New Design!

The reasoning behind a redesign of the entire existing Metrolink application, initially came from the lack of functionality that can currently be achieved. In most modern day commuting applications, purchasing a ticket for travel on that date, or a future date, is considered a prime functionality. In many cases, it may be what a user of the service is searching for the most.!

Limited functionality is not the only problem plaguing the current Metrolink application. The user experience appears to be out-dated, and unfriendly. Instead of simple notifications or quick previews, i.e tram delays and service interruptions, a user must scroll through blocks of text, attempting to pick out information relevant to their journey.!

Simplicity is vastly becoming the norm with the introduction of iOS 7, whilst the current Metrolink application is not cluttered, it is neither simplistic. The navigation is obtrusive, it is constantly visible whether it is needed or not.!

Rather than designing an application around the current application, it was thought best that an entirely new approach should be taken. The new design attempts to introduce a more simplistic, user friendly, and feature rich experience for any user.!

• Reasoning for Usability Studies!

To truly test whether an application is service its purpose, it must be tested periodically. As the nature of Metrolink is to serve the general public in commuting, the usability of their service is paramount. It is important to note which elements of the Metrolink application are causing problems in this area, and which are beneficial to the user experience.!

Usability studies allow for a smoother redesign of an existing application, time can be allocated accordingly to areas which require the most urgent attention and correction. It is imperative to keep the redesign as natural as possible, whereby existing users do not feel alienated by the sudden change in features, or user experience.!

!

� of �1 75


Goals and Objectives!• Goals!

The overall goal for the redesigned Metrolink application, is to improve on its current functionality, and to cater to the needs of many users, whom would benefit from the inclusion of additional features, such as the ability to purchase tickets from within the application.!

In essence, the primary goals are to increase the usability of the application, amongst a broad range of users. Increase the potential of the application, by implementing functionality to make commuting easier. Provide a pleasant Metrolink service experience to the user, which they will continue to use.!

A final high-level prototype will be designed, implementing a variety of new features, that will enhance usability, and address a number of user requirements. The prototype will be interactive, to provide a realistic experience of its capabilities.!

• Objectives!

To understand the user requirements of a commuting application, as a mobile experience.!

To manage time wisely and invest in the addition of features that will be worthwhile, the team collaboratively noted features that would be personally beneficial.!

Additional functionality is to be cleanly implemented, conforming to a simplistic design; removing unnecessary on screen elements, and avoiding large blocks of text.!

To improve the efficiency of the application, by simplifying the controls, design and navigation. The user should be able to complete a ticket purchase, or find information in as few steps as possible.!

Individual designs will be evaluated using a number of heuristic methods including SUS, Neilsen’s heuristics and heuristic statements. Each design is to receive an average final score derived from a number of individual evaluations.!

The final high-level prototype will be fully-featured, and visually pleasing. The design will take positive elements from individual designs, providing a usable design that conforms to the agreed heuristics, developed from the SUS analysis, Neilsen’s heuristics and heuristic statements.

� of �2 75


Methodology (Steps of Development)!

User Requirements!Given the scenario and the task of redesigning an application for the Metrolink service, that a vast amount of consumers user, it was imperative that all user requirements were considered and met.!

As a group a core set of user requirements were created, that would greatly enhance the user experience of the application, and image of the Metrolink service, if they were implemented correctly.!

• Be a cheap (if not free) alternative to current application on the app stores.!

• Reduce the amount of time a user needs to spend on the application to complete tasks.!

• Show quick real-time updates on the home screen, via an interactive status bar.!

• Be up-to-date with great simplistic visuals !

• Allow a user to purchase multiple tickets for multiple people at any one time.!

• Incorporate a QR code system, to allow for quick display of tickets to inspectors.!

• Option to save a receipt of ticket purchases for business expenditure.!

• Allow for quick purchasing of a most recent ticket, or most travelled journey.!

• Use location services to provide information that is both relevant and up-to-date, as well as closest station.!

• Have the option to set an alarm on arrival (or at a specific time) for a chosen destination.!

• Show ‘Nearby Facilities’ that use mapping to show local cafe’s, parking, shopping centres, and other points of interest.!

• Notifications, to enhance user experience of the service, even when they are not using the application. Text messages or Smartphone notifications will provide information on delayed journeys or journeys for purchased tickets.!

• Have a reward scheme, points can be acquired by purchasing tickets and using the service, allowing the user to redeem free or discounted tickets.!

!

� of �3 75


Initial Collaboration of Ideas!Before any designing took place, the team felt it would be highly beneficial to note down feature ideas that were to be implemented in the final prototype design. The purpose of this first step greatly concerned time-management. Once a solid list of ideas were noted and agreed on, a set amount of time was allocated to the researching the idea, and how it would be best implemented.!

Ideas were roughly categorised, to provide a foundation of how the application would work, this included where certain functionality appears, and how it is beneficial to the user. This step gave the team a clear understanding of how the application would look, even before a navigation diagram had been created.!

Functionality to be included would compliment the user requirements that were decided on prior. Any functionality that would not aid the user requirements was criticised, as the feature may have no real beneficial gains, and become an irrelevant feature that may cause confusion to users.!

Navigation Diagram!Creating a navigation diagram with a pre-determined image of how the application would be used, greatly improved the pace of design. All notable features were listed from the home screen, collaboratively the team branched out from the initial screen, separating features by category, and positioning them where users would expect.!

The navigation diagram provided a complete overview of the application, where features appeared, and how linear the application was in terms of accessing all of the features.!

This also represented a precise navigational structure, the purpose of which was to reduce the number of actions a user had to complete, to return to the home screen or another section of the application.!

Sketch Designs!Using the navigation diagram, individual sketch designs could be designed for each screen that branched from the home screen. Some features were also previously addressed in terms of where they would appear, which made designs simpler, however small alterations were made.!

The main purpose of this step, strengthened the teams visual expectations of the application, and how the screen layout would appear. The sketch designs were important, and were accurately detailed. The screen size had to represent the iPhone platform experience, to ensure the design would be elegant, and functional.!

Additional purposes of this step were to visualise how functionality would be implemented, in terms of input style i.e. drop-down menus and text fields. Other elements such as colour scheme and the amount of text visible per screen, were also criticised in this step.!

Sketch designs were firstly drawn, simple place-holders gave the application a sense of scale, and how a user would navigate and use individual screens. These sketch designs were improved using Pages 5.0 for Mac, colour was added, and navigation buttons were given more depth. Further alterations were made on the electronic sketches, as group ideas evolved and changed over the design period.!

� of �4 75


High-Level Prototypes!Using the previous steps of a navigation diagram and sketch designs, creating a high-level interactive prototype was considerably easier than it would have been without any prior planning. The navigation structure of how screens would link together being pre-defined, allowed the team to work purely on the content of each screen.!

The screens had to conform to the navigation diagram, by ensuring the correct links were made between screens, and it was easy for the user to return to the home screen when necessary.!

The sketch designs provided a basis of what each screen would contain, however once this design made it to the high-level prototype stage, changes were made. The location of some navigation elements changed, to conform with the iOS mobile platform, and for pure ease of use. Buttons, drop-down menu’s and their corresponding labels were implemented, however the amount of spacing between elements differed, to ensure touch input worked reliably.!

High-level prototype designs feature interactive elements that could not be completely visualised using sketch designs. Swipe gestures had to be accommodated for, but not used consistently, as an abundance of gestures may feel overwhelming to the user.!

The purpose of the design was to provide an experience as close to a real-working mobile application as possible. Using a working prototype, feedback could be obtained on a more reliable scale from Metrolink and their service users alike.!

As this is an experience close to what is to be expected in the final application, feedback could be used to make any final adjustments, to accommodate user requirements or desires. Likewise, the prototype design allowed the team to present their current design views, and intentions of how the application should look and work.!

!

� of �5 75


How Usability Evaluations were Conducted!Individual high-level prototypes were similar in terms of functionality aspects, however they varied in terms of aesthetic design, navigation structure and other optional features unthought of by other team members. It is difficult to compare a number of final prototype ideas, as individuals may believe their interpretation of the product is flawless, whereby bias opinions are formed.!

To fairly compare all prototype designs, effectively eliminating badly-implemented features, and praising well-implemented features, a number of established usability evaluation methods were used.!

Each finalised prototype underwent three usability evaluation methods: SUS (System Usability Scale), Neilsen’s Heuristics, and a further set of Heuristic Evaluation Statements. The individual could not evaluate their own prototype, as their opinion may be bias.!

• Usability Method 1: System Usability Scale (SUS)!

The SUS method is a very simple survey comprised of 10 statements, it quickly measures the usability of the system in question. The statements are quite concrete in their wording i.e. ‘I felt very confident using the system’. For each of the statements the user rates their level of agreement, ranging from ‘Strongly Disagree’ or 1, to ‘Strongly Agree’ or 5, there are three steps in between.!

A general idea of how usable and popular the system in question actually is amongst users, can be gained using the SUS evaluation method. Developers can change aspects of their system and perform another SUS evaluation, this will measure progress and head development in the right direction.!

Half of the statements are positive, the other half negative. Positive statements are graded on the basis of the scale position [(1 to 5) minus 1], whereas the negative statements are graded by [5 minus the scale position (1 to 5)].!

The positive statements include statements 1, 3, 5, 7 and 9. The negative statements are 2, 4, 6, 8 and 10. The sum of the positive and negative scores is then multiplied by 2.5.!

SUS scores range from 0 to 100, the system or software in question should aim for the highest score possible. Scorings under 80 usually represent some extensive flaws within the product.

� of �6 75


• Usability Method 2: Neilsen’s Heuristics!

Neilsen’s Heuristics were defined by Jakob Nielsen in 1994, there are ten heuristics in total that cover a vast amount of usability. This evaluation method measures the usability, efficiency, and effectiveness of a user interface. The heuristics are intended as general principles, a ‘rule of thumb’ more so than a set of specific usability guidelines.!

Each heuristic covers a specific area i.e. ‘User Control and Freedom’, defined:!

Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

As these heuristics are intended as guidelines, different interfaces may have more specific definitions intended for the software, that can be categorised under one of Neilsen’s heuristics.!

Using Neilsen’s ten heuristics, the prototypes were evaluated and clearly shown in table form. Any problems or issues that arose from using the prototypes were noted, these issues were then categorised under which heuristic it violate. A potential solution was offered to fix the problem, which also gained a severity rating (0 - 4).!

Severity ratings are as follows:!

0 - Not a Usability Problem1 - Cosmetic Problem 2 - Minor Usability Problem3 - Major Usability Problem (Important to fix)4 - usability catastrophe (Imperative to fix)!

• Usability Method 3: Heuristic Evaluation Statements!

The final evaluation method primarily expanded on the initial SUS evaluation method, whereby the statements were more appropriately tuned to the Mobile application in question. The statements were modified, to provide a solid list of heuristics that were completely relevant, and would help evaluate the application in-depth.!

Traditionally this evaluation method is comprised of a list of questions, however the team felt statements were more helpful in evaluation multiple prototypes.!

There are fifteen statements in total, and a statement i.e. ‘The application continuously provides helpful feedback to the user.’ gets a positivity rating (1 - 5) of how well the prototype conforms to this heuristic. Each prototype can score a maximum of seventy-five, as statements are positive, a high score is preferable.!

Individual prototypes can quickly be evaluated, and compared by their scorings. If a particular prototype scores poorly, it is clear that its implementation has been executed unsuccessfully.

� of �7 75


Results!The Usability Evaluation methods listed below, effectively show the average result from three individuals evaluations, per method. The average has been used as it conforms to the more popular opinion of the group as a whole.!

System Usability Scale (SUS)!The System Usability Scales can be found in their entirety under the Appendix, each individual member of the group completed three evaluations, one for each group member’s prototype excluding their own.!

As this evaluation method contained both positive and negative statements, scoring contributions were calculated using the SUS grading criteria, explained in the ‘How Usability Evaluations were Conducted’ section. A higher score indicates a greater popularity rating (maximum score is 100).!

The results for individual prototype application’s are as follows:!

Ratings for Darran’s prototype: 95 | 82.5 | 72.5 Total: 250 / 300 averaging a rating score of 83!

Ratings for Aoife’s prototype: 67.5 | 55 | 65 Total: 187.5 / 300 averaging a rating score of 63!

Ratings for Ben’s prototype: 87.5 | 40 | 72.5 Total: 202.5 / 300 averaging a rating score of 68!

Ratings for Sanaa’s prototype: 82.5 | 70 | 75 Total: 227.5 / 300 averaging a rating score of 76!

The primary Bar Chart displaying the individual SUS scorings, indicates Darran’s prototype scored the most positively, closely followed by Sanaa’s prototype. As this evaluation method takes in to account both positive and negative elements concerning the prototype, the final prototype will be significantly impacted by these results.!

The secondary Bar Chart simply indicates the SUS scorings out of 300, and the remaining points that were not scored (elements which the prototype did not excel in).!

Similar to the individual chart above, Darran’s prototype had the least improvements to make (50 points remaining), comparable to Sanaa’s which followed closely. The majority of design elements were taken from the two highest scoring prototypes, however elements from all design prototypes were considered.!

Scores (positive to negative): Darran, Sanaa, Ben, Aoife.!

!� of �8 75

0

75

150

225

300

Darran Aoife Ben Sanaa

72.597.5112.550

227.5202.5187.5

250

Scored Total

0

75

150

225

300

Scored

227.5202.5187.5

250



Neilsen’s Heuristics (Table)!The Neilsen’s Heuristics Tables can be found in their entirety under the Appendix, each individual member of the group completed three evaluations, one for each group member’s prototype excluding their own.!

As this evaluation method effectively notes negative aspects of the application (the heuristics which have been violated), a lower total score is more preferable. The total number of heuristic violations, in addition to the total severity rating of these violations, will provide great comparability of which application scored the most positively.!


Darran’s Prototype violated a total of 12 Heuristics, H2 / H3 / H4 / H5 / H6 / H7 / H8 / H10. The total severity rating of the 12 combined violations is 31.!

Aoife’s Prototype violated a total of 16 Heuristics, H3 / H5 / H6 / H7 / H8 / H10. The total severity rating of the 16 combined violations is 43.!

Ben’s Prototype violated a total of 14 Heuristics, H3 / H4 / H8 / H10. The total severity rating of the 14 combined violations is 42.!

Sanaa’s Prototype violated a total of 10 Heuristics, H3 / H4 / H8 / H10. The total severity rating of the 10 combined violations is 20.!

The Pie Chart titled Heuristics Violated shows that Sanaa violated the least heuristics, percentage based, the prototype violated 4% less than the following prototype, by Darran.!

As both application prototype’s (Darran, Sanaa) violated the least heuristics, key elements for the final design prototype were primarily taken from these prototypes.!

The Severity Rating Pie Chart also shows similar statistics, as the application designs of Sanaa and Darran again scored a lower percentage (lower the better), meaning the severity ratings for the heuristics that were violated, could be overlooked more so than Ben or Aoife, who scored significantly higher severity ratings.!

Scores (positive to negative): Sanaa, Darran, Ben, Aoife.

! !

!

� of �9 75

Heuristics Violated

19%

27%31%

23%

DarranAoifeBenSanaa

Severity Rating

15%

31%32%

23%

DarranAoifeBenSanaa


Heuristic Evaluation Statements!The Heuristic Evaluation Statements can be found in their entirety under the Appendix, each individual member of the group completed three evaluations, one for each group member’s prototype excluding their own.!

As this evaluation method contained positive statements concerning the application (graded on a scale of 1 - 5), a higher score indicates a greater popularity rating.!


Ratings for Darran’s prototype: 67 | 51 | 61 Total: 179 / 225 averaging a rating score of 60!

Ratings for Aoife’s prototype: 40 | 49 | 58 Total: 147 / 225 averaging a rating score of 49!

Ratings for Ben’s prototype: 62 | 56 | 55 Total: 173 / 225 averaging a rating score of 58!

Ratings for Sanaa’s prototype: 54 | 38 | 51 Total: 143 / 225 averaging a rating score of 48!

The primary Pie Chart displaying the individual percentage of users, indicates that Darran’s prototype received the highest percentage of positive reviews, closely followed by Ben. Using this data, the Final Prototype was based off Darran’s application.!

The four individual Pie Charts indicate the positive score received, using the average score of the three reviews.!

Darran scored 80%, meaning there was room for improvement within 20% of the application, this was the highest score. It should be noted that positive elements were taken from all application prototypes, to create the final design.!

Scores (positive to negative): Darran, Ben, Aoife, Sanaa.

� of �10 75

20%

80%

Darran's Score Total

22%

27% 23%

28%


35%

65%

Aoife's Score Total

23%

77%

Ben's Score Total

36%

64%

Sanaa's Score Total


Positive Elements of Individual Prototypes!Based on the evaluation results, the best application was designed by Darran. Each application however had its own strengths, some of which were incorporated in to the final prototype. The following are positive points for each individual application.!

Darran!

• Good and simple design.!

• Easy to use.!

• Modern, including recently added features from the trainline application i.e. QR codes.!

• The recurring ticket option saves time and proves beneficial for busy people.!

• Straight forward.!

• Clear indication of line status.!

Aoife!

• Good use of colour scheme.!

• Simple design.!

• Implementation of nearby facilities under stop information for user convenience.!

• Good use of space with clear labels and buttons.!

Ben!


• Recent journeys on the main screen make it convenient to re-purchase tickets, rather than going through the entire process of planning then purchasing. It acts as a shortcut for the more advanced users.!

• Reliable real-time line status updates.!

• Icons clearly indicate their meaning. !

• E-tickets with unique bar code gives a touch of modern design.!

• Clear indication of user choices.!

Sanaa!

• Good overview of Metrolink map.!

• Use of security features such as account log in.!


• Displays relevant information needed by the user.!

• Notifications i.e. text alerts for scheduled journeys.!

• Nearby facilities.

� of �11 75


Requirements Analysis!

Personas!• Application Users!

As the Metrolink service is focused on helping the entire general public commute efficiently, the application itself attempts to address the needs of the majority of users. Functionality of the new Metrolink application allows the same functionality a user could expect to receive without a smartphone device.!

However the application is somewhat tailored to specific users of the service, who would benefit from interacting with the mobile experience side of Metrolink, rather than the physical human interaction side. The mobile experience is widely accessible as mentioned, some features (‘Week Plan’ and ‘Smart Journeys’) however, have been implemented to benefit extensive Metrolink users, who have a busy schedule, or rely heavily on this service for work or personal endeavours.!

• Primary Persona!

Elijah Mikaelson is a 42 year old Senior Accountant living in Bury with his family. He works for a reputable company called PricewaterhouseCoopers (PwC UK), from Mondays to Fridays between 9am to 5pm, and commutes to the city using the Metrolink tram service. Due to the morning rush, he makes a point of catching a tram by 8:15 am at the latest. The travel takes half an hour, to reach the city. After a tiring day, he uses the Metrolink tram service to return home, as 5:00 pm to 7:00 pm is the peak travel time.!

• Secondary Persona!

Patrick Evans is a 21 year old student studying Biology at Salford University. He commutes form Altrincham to Salford four times a week using the Metrolink service. His timetable varies on a daily basis, so he uses the service at various times.!

!!

� of �12 75


Scenarios!• Primary Persona Scenario!

Elijah is a very busy man on a hectic schedule. With the new Metrolink application, he will firstly turn on the recurring tickets button. This option will allow him to buy multiple tickets at the same time for the entire week. Elijah will then plan his journey by selecting the desired stations and times. A list will appear from which he will select his journey of choice. This will contain the necessary confirmation information and prices. Once confirmed, he will proceed to make the payment. The ‘My Account’ feature contains his personal details such as address, credit cards details, e-tickets (QR Codes) and expenses. For security purposes, Elijah will be asked to log in only after which the payment will be possible. On successful payment, he will have a couple options to choose from as to how he would like his tickets. There will be options such as QR Code, email, post and print at station using a unique reference number. Before leaving for work, Elijah will be able to view the line status which will also appear as live feeds on the main screen. In case of any delays for the journeys he has booked, a notification via text will be sent beforehand. Elijah could use the ‘next tram home’ feature to obtain a daily or weekly timetable for his favourite journeys and save it. He could also make use of the ‘expenses’ feature, to keep track of payments or to display as proof of business expenditure to the company.!

• Secondary Persona Scenario!

Patrick’s timetable for University is a four-day week, he uses the Metrolink service to commute each day. Using the Metrolink application he is able to use the Tram Times feature to see which tram will ensure he arrives to University on time. To purchase a ticket Patrick will start the application and click on Buy Ticket, he will then be prompted to select the station he is traveling from and the destination station. Once all details have been entered, the application will continue to the payment page. Card details are saved within the application but user login is required for security. Once payment is complete, an E-Ticket with a QR code will be saved to the “My account” page, this is used for validation of purchase. As Patrick is taking the same route each day the application will save this journey to Recent Journeys, making it quicker to purchase the ticket each day. Some days Patrick will go into town after University. When he wants to go home he will use the Near Me feature, using Location Services to find the closest station to his current location. He could also check if trams are running on time by using the Line Status feature, this prevents him from waiting an unnecessary extended period of time at the station.

� of �13 75


Functional Requirements!General Start-Up and Application Usage!

• User will left-click on bar to enable additional features such as notifications, location services and alerts on arrival and recurring tickets.!

• System will implement changes to suit users needs!

• User will first plan journey by clicking on near me button!

• System will search for user location using GPS and display user location with nearest station information!

• User will select the facilities option!

• System will search and display list of facilities within 5 minute distance from user!

• User will return to main screen and select line status to view about on time or delayed journeys.!

• System will display up-to-date and real time information on various line status.!

Buying Weekly Tickets!

• User can select week plan to buy tickets from Monday to Friday and will select journey, passengers, timing and journey type options.!

• System will process, calculate and provide information on discounts, costs and terms.!

• User will accept information provided and proceed to buy tickets.!

• System will divert user to account log in page.!

• User will log in for security purposes.!

• System will verify details and on success, accept payment for tickets and develop QR Code.!

• User will select ticket collection of choice.!

• System will save QR Code for user and email the QR code if desired.!

Learning the Application!

• User will access App Information to read and understand new features.!

• User will access Settings to read and understand Recurring Ticket Purchases!

• User will access pop-out menu from the Home screen to enable additional features that will help make their travelling easier i.e. Location Services.!

!

� of �14 75


Buy Ticket!

• User can search and select station to, station from, date, time, number of passengers, journey type i.e. single or return and travel time peak / off-peak.!

• The Metrolink system will search and work out the timing and pricing of several journeys to the desired destination.!

• The Metrolink system will display station names, departure & arrival times, duration and pricing under journey results.!

• User data is stored in the Metrolink database system.!

• User will select suitable journey and proceed to buy tickets.!

• System will divert user to account log in page.!

• User will log in for security purposes.!

• System will verify details and on success accept payment for tickets and develop QR Code.!

• System will offer ticket collection choices.!

• User will select ticket collection type.!

• System will accept user choice and carry out the request.!


Re-purchase of Past Tickets!

• User will select smart journeys option.!

• System will find and display users most recent and most travelled journeys.!

• System will provide information on previous tickets such as from, to, passengers, time, ticket type and cost, and allow re-purchase of ticket for future journey.!

• User will select option to buy ticket.!

• System will divert user to log in page.!

• User will enter information for security reasons.!

• System will verify and on success, accept payment.!

• System will verify details and on success accept payment for tickets and develop QR Code.!

• System will offer ticket collection choices.!

• User will select ticket collection type.!

• System will accept user choice and carry out the request.!


� of �15 75


Non-functional Requirements!The system shall:!

• Allow fast navigation and quick exit from particular screens within 3 seconds. !

• Process selected journey information quickly and accurately within 5 seconds.!

• Retrieve journey results from database within 5 seconds.!

• Be available at all times i.e. 24 hours a day and 7 days a week.!

• Be flexible in integrating with other social networks by providing quick links and access to Facebook and twitter within 3 seconds.!

• Provide security features such as account login (password must consist a combination of numbers and characters), or enter bank security code.!

• Allow users to access their account at all times i.e. 24 hours a day and 7 days a week.!

• Respond within 3 seconds.!

• Carry out 10 transactions per second.!

• Allow personal information to be edited and saved within 3 seconds.!

• Store a maximum of 1000 clients in the database.!

• Operate on iPhone and Android devices.

� of �16 75


Design!

Storyboards!• Navigation Diagram!

The importance of having a visual aid to help collate a number of finalised ideas is paramount. Creating a navigation diagram allowed the team to clearly see all features that were intended for inclusion in the finalised prototype, and how they would interact with one another.!

A linear navigation diagram helped to simply show what functionality would be implemented on which screen, and how the user would navigate to and from this functionality, via the home screen. The use of solid and broken lines also presented whether navigation paths were direct or optional.!

The navigation diagram quickly ensured an appropriate amount of time was spent concerning each fundamental element of the prototype, and unnecessary functionality could therefore be discarded as an objective. The clear layout provided by the navigation diagram gave a complete overview of the application, this ensured functionality was present in the appropriate location within the application, and is where the user would expect to find it.

� of �17 75


• Sketch Designs!

The navigation diagram gave an extensive overlook of how the application would function, however creating a finalised high-level prototype would be near impossible, without screen-by-screen visual guides.!

The sketch designs gave life to the application, which allowed for further modification of aesthetics and layout design. Given the particularly limited screen size of a mobile device, numerous sketch designs were created, to find the optimal layout design, colour scheme, and quantity of content per screen.!

The paramount importance of a unanimous group agreement of one design should not be overlooked. Disagreement over design elements may cause riffs within a team, harming work efficiency and motivation. The sketch designs were a tool which communicated an idea, the idea could be finalised and brought to fruition once it had been agreed upon.!

On the following pages are the sketch designs for the final prototype, the final product is greatly based on the sketched designs, as these provide a greater in-depth view, as to how the application should look and feel.!

It should be noted slight alterations may be present, due to the functionality of the Wireframe and Mockup software tool. Improvements may have been made in the final prototype, in addition to aesthetic alterations.

� of �18 75


� of �19 75

Home Login

Additional FeaturesBuy Ticket


� of �20 75

Tram Times Near Me

Your Ticket Details Ticket Purchase Successful


� of �21 75

Facilities Week Plan (Day) - i.e. Monday

Week Plan Purchase Successful Smart Journeys


� of �22 75

Line Status E-Tickets App Information

Map Route Contact Us


Final Coloured Prototype!The editing software of choice for the prototype application was Axure RP Pro 6.5 / 7. The software is a Wireframe and Mockup tool, providing much more realistic functionality, than a photo editing tool such as Photoshop.!

Axure allows the use of variables to store data and present it on another screen, a large variety of checkbox, drop-down menus and radio button tools, as well as interactive gestures including swipe.!

Using this software, a realistic high end experience is provided, as screens link together, and the user can flow through the application as if they were using it on its desired platform (iOS). This provides an in-depth testing environment for the team, to resolve any small issues within the interface, and make slight alterations according to received feedback.!

The interactivity will be shown as clear as possible via image previews, however to experience the entire application prototype, the files must be downloaded and opened in Axure RP Pro. The prototype can then be published and viewed within a modern browser.!

Safari 7.0.1 on OSX Mavericks was used for the prototype application’s wireframe development and maintenance lifecycle.!

As noted alterations may appear within the final prototype designs which deviate from the initial navigation diagram and sketch designs. This is due to post-collaborative meetings that included a somewhat renewed vision of the application, and how features should be implemented.

The improvements that were made are as follows:!

• The re-arranging of the navigation menu from the Home screen.!

• Name changes i.e. QR Codes to E-Tickets and Tram Times / Near Me to Plan Journey.!

• The removal of the Settings screen, incorporating the Recurring Tickets feature with other additional features, found within the Pop-out menu.!

• New screen containing a map of the Metrolink routes.!

• The inclusion of the Account function, where a user can login, used for security features, storing payment details, and the ability to use certain discount features.!

• The ability to view all ticket details for the Week Plan feature, on the confirmation screen.

� of �23 75


Home Screen with Dynamic Notification Area / Secondary Home Screen (Pop-out Menu)!

!

� of �24 75

The Home screen on the right simply lists all of the features found within the new Metrolink design. From here, the user can swipe left or right on the dynamic notification area, shown at the bottom of the screen.!!The left-most image is a pop-out menu, which would slide out when the user taps the menu button. This provides further additional features that would enhance the application for more-experienced users. Location services, notifications, alerts and recurring ticket purchases can be turned on or off here.


Login

� of �25 75

The Login menu allows the user to enter personal information, in addition to payment details (required for in-app ticket purchasing), and any valid discounts.!

The first time a user uses the Login feature, there will be no details, however once a user has created their account, they can then either log out, or edit their details at any time.!

Important information such as payment details and passwords are hidden, for added security, the user must also enter their payment method security code when purchasing a ticket.


Buy Ticket / Your Ticket Details / Ticket Purchase Successful

� of �26 75

The Buy Ticket feature allows a user to buy a ticket on the move, a feature which is not yet available in the current Metrolink application. !

Multiple tickets can be purchased for adults and children, at different peak times. Within this prototype, screen space has been greatly considered, as the small display (4 inch) restricts the amount of information viewable at any time.!

Only after the user has checked the Return ticket box option, will additional information display.

The left-most Your Ticket Details screen displays all of the information that the user chose concerning their journey. Conformation on details allows the user to return using the back button, to edit their journey.!

For security reasons, the security code of the chosen payment method must be entered before a user can purchase their ticket.!

Once ticket purchase has been successful, a QR code will be generated and stored in E-Tickets. The user also has the option to receive a ticket receipt, and to collect a physical ticket if they wish.


Week Plan

� of �27 75

The Week Plan allows users to purchase a multiple of x5 tickets, for an entire week of journeys. This feature is extremely useful for users who know their journeys in advance (office workers, students).!

Five Buy Ticket screens are shown for each day. The confirmation screen shown, displays the details of all five tickets, and their pricing.!

A user will receive a small additional discount, as a further incentive to use the feature, and boost ticket sales for Metrolink.!

The user will again need to enter their security code for the chosen payment method.!

The QR codes are generated, and the user is provided with the same options, as the Buy Ticket feature.


Smart Journeys (Most Recent & Most Travelled

� of �28 75

Smart Journeys provides two useful methods of ticket purchasing, suggesting journeys that are potentially interesting to the individual user. Thee journeys that will be displayed in this features are highly dynamic, and follow journey patterns of the user.!

The most recent journey will provide an exact replica ticket of the last ticket purchased by the user, useful for businessmen.!

The most travelled journey is most useful to individuals who find that they travel to the same location quite often.!

Both journeys allow the user to view the details of the suggested ticket, so they can confirm that this ticket is right for the particular journey they are about to make.!

Below are samples of how the details appear, similar to Buy Ticket, the user will be prompted for their security code.


Tram Times / Near Me & Facilities

� of �29 75

The Tram Times feature provides simple timing information for certain journeys, the most useful function within this feature is Near Me. A small image uses location services showing the current location of the user.!

From the Near Me feature, the facilities option becomes available, showing all nearby places. Food & Drink, Shopping and Banks / Post Offices are displayed. Facilities greatly enhances the user experience, and provides information relevant to the user, as they may not travel to a specific location very often.


Line Status

� of �30 75

The Line Status feature is brightly coloured by intention, it may seem out of place, however it allows user to quickly distinguish different elements on screen. The elements being the specific tram lines, are colour co-ordinated to the official Metrolink line colourings.!

To simplify this feature even more, a red or green indicator presents whether trams will be running on time, or be slightly delayed.!

The key indicates time delays i.e. red indicator with the numerical value ‘4’, trams on that particular line are delayed by four minutes.


E-Tickets / Individual QR Codes

� of �31 75

E-Tickets is similar to a virtual wallet, and stored QR codes automatically, that are generated when a new ticket is purchased.!

The Wallet-styled E-Tickets screen displays a preview of the individual QR code, accompanied by the journey and number of tickets for that journey. The user may open any of the QR codes displayed, to view all of the information for that particular purchase.!

Opening an individual QR code displayed the code in its entirety, where it can be scanned to provide proof of a ticket purchase.


App Information / Map Route

� of �32 75

App Information provides details on how features work, and what some features include such as Buy Ticket, as this is a new feature to the Metrolink service (mobile platform).!

Smart Journeys is also covered, as this feature continuously updates what journeys it displays, based on application usage.

The Map Route effectively provides an entire overview of the routes each tram line uses.!

Users may use the effective and well know ‘pinch-to-zoom’ gesture, to view all stations on a particular service line.!

The Map Route allows users to see how many stations are before their desired location, and to keep track of their current journey.


Contact Us / Sitemap for Prototype Design

� of �33 75

Contact Us provides quick links to the Metrolink social networks (Facebook, Twitter), email, address and manned telephone lines (and their operating hours).!

If a user has any complaints, queries or problems, the Contact Us screen should provide enough information for the users issues to be resolved. This may be done either using the website and FAQ, or speaking to a member of the Metrolink team.

Below is the Sitemap for the Prototype Design, it follows a very similar navigation system, designed in the earlier development stages and storyboards.!

Some changes are present however, including the removal of the Settings screen, in favour of incorporating settings within the pop-out menu, accessed from the Home screen. QR Codes has also been renamed to E-Tickets for clarification purposes.


Reflection and Conclusion!• Metrolink Prototype Design!

The overall final prototype design has been well-executed in its design, and features were implemented to enhance the usability of the application. The general opinion of the designed prototype is that it will be extremely easy to use by the majority of users, there should also be a very little to no learning curve, for new users. The application had been designed not only for the advanced users, but also the beginners by providing guidance and instructions where necessary.!

The dynamic notification area found on the home screen is a feature that becomes very useful, as users can quickly glance at the application, rather than spending long periods of time navigating through screens. Another feature that is popular amongst the group is Near Me. To see all nearby facilities that may be of interest to the user, in addition to the users current location and closest station, saves a large amount of time. Without this feature the user would have to use third-party applications to view nearby facilities, and a mapping service to find their closest station.!

Recent trends such as QR Codes being used by existing transport applications such ‘the trainline’ were implemented, in addition to possible future feature trends including text alerts and nearby facilities.!

The ability to buy tickets in multiple ways such as Smart Journeys, daily tickets, Week Plan, provides users with many options to suit their specific requirements, which we felt had invaluable importance.!

Aspects that were not as popular within the application, also count as limitations to what the user is able to achieve, if they have not already entered the necessary information. In essence, there is little error-prevention.!

A user must also enter all relevant information about their status within the account section, this includes discount services that apply to them, i.e. student. There is room for improvement on issues such as navigation, currently users must return to the previous screen in a very linear manner. Home buttons throughout the application could be included in a future update, or a certain gesture / pop-out menu to perform this action.!

Overall the prototype application provides greater functionality than the current official Metrolink application. Ticket purchasing, E-tickets with QR codes, and location based functionality provide a service that would enhance the daily commute of any user. The needs of the primary and secondary personas have also been fulfilled.

� of �34 75


• Improvements!

In addition to the slight improvements discussed above, further improvements to the application’s design would include rapid account switching, by entering a unique password, this would require an additional button within the Login menu, to switch accounts.!

The first time the application is launched, there should be a user guide that indicated what each element of a screen does. Likewise, the first time a user accesses a screen, a tutorial should take the user through the entire process (if they wish to), i.e. purchasing a ticket.!

A feature to add ‘Favourites’ for stations or entire journeys would be welcome, this would be in addition to the Most Recent and Most Travelled features. A ‘Next Tram Home’ feature that would allow a user to search for specific journey times and save them (similar to favourites) would provide a great benefit to the end user. These journeys could be saved on a daily or weekly basis, depending on whether the user knows what time they can arrive at a station in advance (scheduled employment hours / educational timetable).!

Small indicators may also make navigation easier, such as left / right arrows on the dynamic notification area within the home screen. Indicators should be apparent for all gesture based elements, including the pop-out menu on the home screen, and pinch to zoom on the Map Route.!

The actual design of the application has been well implemented, however improvements could make better use of blank space, and slight alterations to the text found within the application (size / font). Inverted colours and larger / smaller text options would also greatly increase the widespread usability of the application.

� of �35 75


• Limitations!

As the prototype design currently stands, the required features for the primary and secondary personas, as for most of the general public, have been implemented. There are however some minor limitations, which could be fixed by some simple system alterations, or implemented in the near future.!

There is currently only support for one Metrolink user account, the addition of multiple accounts could be added for family purchases, or separate business and personal accounts. Due to the nature of the mobile platform, the initial thought concerned the privacy of the user, and that a user’s smartphone is quite a personal device, for their accounts only.!

Within the Week Plan feature, the user is presented with a confirmation screen displaying the information on their five ticket purchases. There is currently no way to skip back to Monday to edit the purchase details, without bypassing the other four days first. This is somewhat an inconvenience, however a swipe gesture or mini-menu could solve this issue.!

There are a number of limitations with Axure as this is a wireframe and mockup tool, rather than a fully-fledged software tool for application design such as Xcode (IDE), there is certain functionality that just cannot be implemented, or visualised within Axure.!

Working with the screen real-estate also provided some issues, as Axure (in this scenario, the iPhone) provides a static 4” screen, rather than a dynamic scrollable environment.!

Many of the application’s features such as tickets do require a logged in user, with a valid payment method. Discounts must be provided within the user’s account details, as they cannot be entered during a ticket purchase at this stage. Features such as Plan Journey do not require a valid payment method.!

From a designers perspective, the application consists of all possible features that would make travelling easier and convenient for the end user. Although features effectively accommodate the primary and secondary personas, the application provides many others features, which satisfy the needs of users, who are not considered the primary or secondary persona.!

From a users perspective, the features implemented were good enough to help commuting from one place to another. What were once thoughts / burdens: ‘what time does the tram depart?’, ‘do I have my ticket on me?’, ‘do I have enough cash on me?’, ‘which is the nearest station?’, were converted to features within the application, that solve these dilemmas.

� of �36 75


• Goals and Objectives!

As the overall goal of the newly designed prototype were to improve on the current functionality provided via the Metrolink application available now, this prototype has succeeded. Currently the Metrolink application does not allow E-ticket purchasing, and provides very little functionality, whilst being aesthetically unappealing.!

This prototype has brought a great many features including the long-awaited ticket purchasing on a mobile platform, in addition to location based Near Me services, weekly ticket purchases and the ability to check the line status of trams.!

The application may be used by a broad ranger of users (key element in goals and objectives), as the Metrolink service is a public service, available to any person who wishes to use the service. It was imperative not to appeal to only a small select group of people, and alienate others. The application has a friendly design, and with the tutorials explained in the improvements section above, any user will be able to use the application quickly and efficiently, with very little down-time.!

The design has achieved the majority of our goals and objectives, as we aimed to simplify controls, design and navigation. The design is very simplistic and only provides relevant information when necessary, however navigation can become difficult in the application’s current state. Home buttons throughout the application will solve this slight issue, as currently the user must retreat through the linear screen-pattern, to return home.!

The final prototype design has taken design elements from the four individual prototype designs, the chosen elements were considered and agreed upon, once the evaluation methods had been completed and reviewed.!

The final prototype also conforms to Neilsen’s heuristics, providing help when necessary, showing detailed descriptions of certain functionality in the Settings screen, and hiding information when it is irrelevant to what the user is currently doing. The interface is consistent, as although button functionality may change, they are always located in the same position. Text and colour remains consistent, and follows the Metrolink branding colour. Drop-down menus eliminate user input, which prevent typing errors. There is also multiple security aspects to the application, i.e. user login, which is required for ticket purchasing. The user also has to enter the security code for their desired payment method, before they are able to purchase a ticket (protection against theft / phone loss).

� of �37 75


• Using the Metrolink Prototype!

Manchester Metrolink has a very basic application that has not been able to meet user requirements. With the new and improved application, Metrolink should easily increase its user satisfaction rates, as some features have been available to other commuting services for a long period of time (ticket purchasing). !

The new metrolink application has been designed from the ground up, carrying over very little from the existing application. The newly designed application conforms to user evaluation results, and usability heuristics. Some features from the existing application were considered such as Line Status and Map Route, however the implementation was poor and seemingly useless. Firstly the Line Status has a redesign, as line services appear on the left and a status indicator on the right: red for delayed, green for on-time. The idea of presenting it this way is to simplify the design and make it easier to understand, compared to the existing application which provides large blocks of text for the Line Status, which a user must read carefully to understand. The Map Route has been given its own screen, removing unnecessary clutter from other screens, and making it even easier to find, and read.!

By introducing the newly designed application, users will see that Metrolink has put a lot of effort in to the new application, in comparison to the old application, i.e. in terms of aesthetic design and included features, which now meets user requirements. Metrolink would overhaul its image, becoming a more positive competitor on the mobile platform. Providing the application for free on the App Store, Metrolink would see the number of service users increase, thus boosting the business and cash flow for Metrolink. With increase in income, a portion of the resources could be used to further improve on current services offered, and expand the application to other platforms (Android, Windows Phone).

� of �38 75


• Project Scenario (Individual’s Experience)!

Darran!

I personally feel comfortable evaluating my own designs, and others, in accordance to heuristic statements, SUS analysis, and Neilsen’s heuristics. I am able to provide valid suggestions for improvement, based on the results of these evaluations. Usability is far more than navigation, design or interface interaction. The combination of these elements, in addition to good cognitive layouts, well-sized elements and screen content make for a great design, if implemented correctly.!

Time management has been a slight issue with the group work, however the report in its entirety entered finalisation by the 29/01/2014, leaving one week for additional tweaks, and changes to the design / report. The issue arose as without a significant push from myself, information that was required (application evaluations) before moving on to additional report sections, would have been delivered at a later than preferable date.!

I personally feel that myself and Sanaa committed to the workload more heavily, as shown by the Task Allocation Sheet. Opportunities were given to share the workload equally. It was difficult to arrange a time that the entire group could discuss the report (this includes during HCI labs), as attendance dwindled. Myself and Sanaa completed the application evaluations promptly, then continued with further sections such as finalising the prototype design, sketches and functional requirements. Group work could have been improved greatly, a lack of motivation seemed apparent and group dynamics / interaction were poor.!

Aside from the group work aspect (to be discussed next), I generally feel the prototype created in Axure, adheres to the heuristic and other HCI aspects explained in this unit, and has therefore been a success.!

Aoife!

This project has shown me that there are many different aspects to take into consideration when developing applications. It has taught me that human interaction with an application goes further than design and you have to take things such as usability, complexity, functionality and navigation into consideration to name a few examples.!

It was quickly realised that before you create an application you have to consider what the several different users would require from the application on a day to day basis to make sure that it is suitable for a wide variety of different people. For example what students, professionals and elderly would use it for and how you could incorporate enough elements to satisfy everyones needs.!

As a group we had to analyse each others prototypes identifying the strengths and weaknesses in each and use that to the create the perfect prototype. I feel as a group we succeeded in completing all aspects before the deadline. Darran and Sanaa were very proactive in the logistics of creating the group report and putting all our individual work together. Communication and regular attendance to all meetings would be something to be improved in the future.!

I feel I have learnt a lot about Human Computer Interaction from developing the prototype and have enjoyed learning how to use a different software to do so. I feel I could improve on my time management better in future projects, however all work was completed for the deadlines.!

!� of �39 75


Ben!

As a group I think we worked well in making decisions towards the project outcomes. Darran from the beginning of the project took on the role as team leader. He was well organised and set a structure that the project should follow. Sanaa was also a very valuable member of the group, she had a great understanding of the tasks that needed to be undertook and did them in a very professional manner. Aoife also had a very positive input towards the group. She had really good ideas in what we should include in our final application and undertook all of her work in a professional manner. To conclude I feel that we worked well as a group and shared similar ideas to carry the project in the right direction.!

Sanaa!

Working on the project has made me understand and realise how the consumers/users are important when designing all sorts of products. One cannot just simply design based on their thoughts. It takes thorough research and evaluation to be able to conclude on the overall design. Every bit of design has to be critically analysed and seen from a user’s point of view to meet their requirements.!

As a group, we managed to complete the project about a week earlier. This clearly shows good time management and effort put into the project, however, Darran and I were more dedicated and enthusiastic towards the project. A definite improvement that could be made in future projects is constant communication, which lacked in the group. Also, weekly meetings by all members would allow any questions to be answered and basically have every member on the same page. !

In overall, no such difficulties were faced. Every task was taken as a challenge and met very well. The final prototype was designed close to perfection to ensure all user requirements are met. Viewing the overall report and prototype, I personally think it is a job well done.!

!

� of �40 75


• Group-work Evaluation!

The usability evaluations were straight forward to complete for individual evaluations, and the heuristic statements were concrete in their significance, as they clearly related to the product under development. Once all evaluations had been completed (nine in total for each individual prototype), results were compiled, using the total markings from the three evaluations, in addition to the average score of the three combined totals.!

Developing the navigation diagram and sketch designs became apparently easy, as the basic prototype model from an individual prototype was used. The prototype used covered many aspects that would be implemented in to the final prototype, and was popular amongst the entire team. The storyboard designs therefore already had a skeleton diagram of what was to be expected from the final design, and was edited accordingly to changes discussed as a group.!

Whilst the basic design for the prototype had already been established, the group collaborated ideas to implement in the final design, and suggested changes to the aesthetic appearance were also discussed. Newly implemented features that were a team effort, included the Near Me feature, Facilities, the alteration of the Home screen layout, and the inclusion for a login page for users details.!

Working together as a team generally posed very little problems that could not be overcome. Darran began the initial writing of the report including the executive summary and introduction. Volunteering to complete additional sections of the report Sanaa and Ben compiled the personas, scenarios and functional requirements.!

Evaluations were completed by all group members, and the design section was split accordingly, shown in the task allocation sheet (found in the appendix). The compiling of this report by Darran, has been proof-read, and any final changes have been made through team discussions and suggestions.!

The majority of the report was finalised and completed by 30/01/2014, leaving one week for any later alterations, or changes requested by any team members. Therefore it is fair to say the group overall worked efficiently, and time-management was not a worry.!

Improvements for future endeavours include a timely scheduled meeting, at least once per week. A short meeting (15 minutes) could easily bring all team members up to date on the current situation of the report, and design stages of the product, ensuring the direction of the group’s work is heading in the right direction for everybody.!

Aside from communication, or the lack of, a stronger sense of enthusiasm could have been expected from team members. As the prototype design has been completed on schedule, and to a high standard of quality, slight improvements for future projects could improve the workflow and efficiency of the team, however there were no major flaws that needed to be immediately resolved.!

!!!

� of �41 75


Appendix!

Task Allocation sheetTask Allocated

ToTask

Completed (Date)

Comments

Executive Summary Darran 22/12/2013 Completed the Executive Summary (changes may be made via group discussion).

Introduction Darran 24/12/2013 Completed the Introduction (changes may be made via group discussion).

Methodology (Steps of Development)!

User Requirements

Darran!

Sanaa Ben

30/12/2013!

5/01/2014 5/01/2014

Completed the Introduction (changes may be made via group discussion).!

User Requirements discussed as group with Sanaa and Ben.

Results Writeup!

Group Evaluations!

Positive Elements

Darran!

Group!

Sanaa

26/01/2014!

24/01/2014!

20/01/2014

Write up of results in its entirety.!

Group evaluations completed.!

Completed positive elements section on individual applications.

Requirement Analysis!

Primary!

Secondary!

F & N-F Requirements

Multiple!

Sanaa!

Ben!

Sanaa

20/01/2014!

18/01/2014!

20/01/2014!

18/01/2014

Entire section completed.!

Primary persona / scenario.!

Secondary persona / scenario.!

Functional / Non-functional Requirements completed.

Design!

Navigation Diagram!

Sketch Designs!

Final Prototype!

Multiple!

Darran!

Sanaa!

Darran

03/02/2014!

20/01/2014!

28/01/2014!

03/02/2014

Entire section completed.!

Completed and discussed.!

Completed and discussed.!

Completed, based on navigation diagram and sketch designs.

Reflection and Conclusion

Darran!

Sanaa

05/02/2014 Completed as a group, reflecting upon the application and our team efforts.

Appendix Darran 06/02/2014 Completed once the report had been finalised and discussed.

� of �42 75


SUS Analysis of Group - (by Darran Mottershead)!!

� of �43 75


!

� of �44 75


!

� of �45 75


SUS Analysis of Group - (by Aoife Turner)

� of �46 75


!

� of �47 75


!

� of �48 75


SUS Analysis of Group - (by Ben O’Brien)

� of �49 75


!

� of �50 75


!

� of �51 75


SUS Analysis of Group - (by Sanaa Juma)

� of �52 75


!

� of �53 75


!

� of �54 75


Neilsen’s Heuristic Tables - (by Darran Mottershead)

� of �55 75


!

� of �56 75


!

� of �57 75


Neilsen’s Heuristic Tables - (by Aoife Turner)

� of �58 75


!

� of �59 75


Neilsen’s Heuristic Tables - (by Ben O’Brien)

� of �60 75


Neilsen’s Heuristic Tables - (by Sanaa Juma)

� of �61 75


!

� of �62 75


!

� of �63 75


Heuristic Evaluation Statements - (by Darran Mottershead)!!

� of �64 75


!

� of �65 75


!

� of �66 75


Heuristic Evaluation Statements - (by Aoife Turner)!!

� of �67 75


!

� of �68 75


!

� of �69 75


Heuristic Evaluation Statements - (by Ben O’Brien)

� of �70 75


!

� of �71 75


!

� of �72 75


Heuristic Evaluation Statements - (by Sanaa Juma)

� of �73 75


!

� of �74 75


� of �75 75

Documents

HCI - Group Report for Metrolink App