Milestone 3: Experience Prototype and Demo Plans

Introduction

By the end of Milestone 2, we had conducted a formative study for the bus notification system we had proposed in Milestone 1, which involved both a diary study and a survey to understand the information needs of general bus riders in Ann Arbor while taking into consideration accessibility issues. Based on the study results and findings, we generated a bunch of new ideas and further combined them into 3 refined ones based on a series of criteria:

Location awareness via Bluetooth beacons and smartphone or smart watch: when a user is approaching the bus stop, the beacon recognizes him and pushes the bus information to an app on his smart device; when the bus is approaching this stop, the bus driver hears a beep, and knows someone is waiting there; when the user is on the bus with his destination set on his smart device, his smart device will receive information from the beacon embedded on the bus about each stop; and when he is arriving at his destination, his smart device tells him to prepare to get off the bus.
LED information display at the bus stop: a display with LED lights that clearly indicates which stop the bus is arriving at and which direction the bus is going, with the estimated bus arrival time showing at the bottom.
Proximity Notification System: a proximity-based smart system that presents and speaks out loud the bus arrival time when a rider approaches.

The ideas above are actually variations of the bus notification system concept, and we decided to flesh them out and test some of them through user enactments (UEs) in Milestone 3. By conducting the UEs, we hope to probe user needs and preferences towards the variations as well as different aspects of our ideas, which would help us further refine our design scope and explore potential alterations to our design.

Study Design

Overview

For this study, we started by following Odom’s approach to gather as a group and brainstorm and bodystorm scenarios to explore answers to the research questions we sought to address (William Odom et al., 2012). After that we created a set of six user enactments based on the scenarios we had developed, and we categorized them into three groups: one-way communication, two-way communication and an interactive display at the bus stop. Then we recruited five participants as our actors, and set up physical environments to test out all the UEs with each participant. Through this within-group research method, we gained the opportunity to understand each user’s priority and preference regarding the enactments. We analyzed participants’ feedback to seek more interesting patterns that could guide our design directions in the future.

Research Questions

Before plotting out our user enactments, we generated a set of research questions that we’d like to address through this experience prototype stage:

Does the user value the opportunity to have a one-way communication on the bus? What can be an appropriate frequency of pushing notifications to riders on the bus?
What information would be most useful for bus riders to display on a screen at the bus stop? How will users interact with the digital screen at the bus stop?
Is it important to provide bus information before the user leaves her current location for the bus stop? How would users expect to gain that information?
Does the actor want information on demand about the bus relevant to their closest bus stop?
Is there any value to letting communication be two-way? Is there any value in letting the driver know the user is at the bus stop?

User Enactments

For our study we have created six user enactments to observe different behaviours of our targeted audience towards our design ideas. Each user enactment session consisted of one observer to take notes and one coordinator to guide the session and control the scene. The following are the user enactments:

UE#01

Category: one-way communication

Scene: at the bus stop

The actor is at the bus stop, which is in a NQ meeting room with a whiteboard. The whiteboard has a sign that indicates the location of a bus stop. Text messages are used to simulate notifications from the app. An audio recording of road noises is played to simulate the real street environment at a bus stop.

Script:

Actor arrives at the bus stop.
He receives a text message “The bus arrives in 3 minutes”.
The actor will wait and be observed for 20 seconds.
The actor will receive another text message “The bus is delayed, now arrives in 5 minutes”.
Observe the actor’s reaction and behaviour for 20 more seconds.

UE#02

Category: two-way communication

Scene: on the bus

The actor is seated in a chair in the room with chairs positioned in rows to simulate a bus setting. Text messages again simulate app notifications and also app interactions in this scenario.

Script:

Actor is prompted via text message to reply with the bus stop where they want to get off. Another text message is sent to confirm bus stop and note that the bus driver has been alerted about their choice of destination.
Actor periodically receives text messages announcing where the bus is. Actor has the option to respond to text message and say they would like more frequent location alerts or they would like to turn off alerts.
Finally a text message is sent to say their stop is coming up and they should get ready to get off the bus.

UE#03

Category: interactive display at bus stop

Scene: at the bus stop

The bus stop is drawn on the whiteboard in the room. The display with a real-time bus map will be projected on the TV in the room. A researcher will act as a wizard to react to the user’s operations.

Script

Actor arrives at the bus stop.
Confederate will ask her to figure out bus information.
The actor will check out the screen for 1 – 2 minutes.
Potential interactions include: tapping on a button to switch routes, tapping on a bus stop to check detailed information, zooming in/out the map, signifying the bus driver, etc.

UE#04

Category: interactive display at bus stop

Scene: at the bus stop

The display is the same as the previous one, only that it has an option for the actor to play a game while waiting for the bus. The game is “spot the difference”, and when the actor spot a difference, his or her name (or nickname) could be put on the screen.

Script

Actor arrives at the bus stop.
She will check out the screen freely for several seconds.
She taps on the “game” button.
She will receive a prompt on the screen asking if she wants to join the game.
She can tap on the screen to join.
Potential interactions include: tapping on the screen to check bus information, tapping on the screen to play the game, zooming in/out the map, etc.

UE#05

Category: two-way communication

Scene: at home, school or work

A meeting room at NQ is exactly the setting of being at school. User is in SI and is doing some project work. He/she is going to catch the bus Route 2 to get back home in about 30 mins. So the user, requests the application to give information about the AATA Route 2’s real-time location and arrival time with regard to the Hill Auditorium bus stop. The actor will be instructed to send a request for bus info at a particular bus stop for a particular time. The app will then send a notification indicating the real time of arrival of the next bus at that particular stop.

Script:

Actor is about to leave to ride on the bus.
Actor sends a text message in order to determine where his/her bus is currently and at what time it will arrive at the nearest bus stop.
Once actor sends out a request, the wizard will send a reply with the accurate real-time bus information for that bus stop. This information will then help the user determine when to leave for the bus stop.

UE#06

Category: two-way communication

Scene: at the bus stop

The user is at the bus stop, which is the same setting in the NQ meeting room. Text messages are again used to simulate notifications from the app.

Script:

Actor arrives at the bus stop.
He receives a text message “The bus arrives in 5 minutes. Do you want to let the driver know you are waiting here? Reply with “Y” to let the driver know.”
The actor will wait and be observed for 20 seconds.

Debriefing

After each user enactment we would pause to ask each of our actors the following questions:

Describe your experience in a few words while you were a part of this scenario.
Rate the solution that we have provided. (Score it on a 1-10 scale: 1-Poor 10-Excellent)
What were the desirable and undesirable aspects of your experience?
Any additional comments/suggestions for this idea?

At the end of all the user enactments we would debrief the whole session with each actor by asking the following questions:

Which idea/enactment did you like best? Why?
Which enactment do you find least attractive? Why?
Do you have additional comments/suggestions for one or some of the enactments? How would you envision the bus stop in the next 5 to 10 years?

Physical Setup

For our user enactment session we chose a NQ meeting room to set up the physical environment. The reason for choosing a staged location rather than enacting in a real bus stop is that we wanted to have more control over the scene and wanted to avoid any distractions that might prevent us from observing what we actually care about the most: our actors’ attitudes and reactions. The meeting room we used in NQ had a whiteboard on which we drew a bus sign to indicate the bus stop. We used the chairs in the room to create the environment inside the bus. We also used the TV screen to play the role of an actual screen at a bus stop, and a computer connected to the TV to react to users’ operations and display content accordingly. In the background, we played a soundtrack with road noises to simulate the noise and atmosphere surrounding a real bus stop. For the communication and notifications, we used text messages to guide the flow of the session and simulate the notifications users will be getting through using our proposed system.

Participants

Since we decided to target general bus riders at the end of Milestone 2, our strategy for recruiting UE participants was to reach out to anyone that has ridden on a bus . We recruited five participants in total, who were all SI students, 3 female and 2 male. All of them had previous experiences taking buses, with four of them being regular bus riders. The users were in their twenties and were or diverse backgrounds, i.e. international and local students. All of our participants use their smartphones on a regular basis and are comfortable with new technologies.

Study Results

We held a group session to sort out and analyze the UE notes and interview feedback, from which we drew the following findings:

Participants were mostly positive about the “push” experience, i.e. getting a notification automatically when arriving at the bus stop and riding on the bus.

All user show positive attitudes towards the automatically-pushed notification (faked by text messages in UEs ) the moment they arrived at the bus stop and while they were on the bus. One user liked this feature because it had a minimum number of interactions involved to get relevant bus information. Another user said it was helpful to have the bus information pushed to a device rather than looking for it.

Although positive in general, some users still expressed concerns over the notifications. For example, one user wondered how the system knew which route she was going to take. This question prompted us to think deeper about the information sources for our bus notification system and potential privacy issues relevant to our design. Some other users thought the notification on the bus unnecessary for them because they took the bus everyday and knew their destination well, but thought it valuable if they were to take a bus for the first time in an unfamiliar place. Such reaction led us to further divide our target users into two types: regular commuters and newcomers (or one-time riders); and to consider different information needs and interactions to serve different user goals of the two user groups.

The idea of notifying bus driver added no value to most participants and might even cause trouble to both bus riders and drivers.

Although one participant liked the reassurance of notifying the bus driver that someone is waiting at this bus stop, other participants didn’t draw much value out of this function. Participants also pointed out potential pitfalls of this idea that we hadn’t thought of before. One user was concerned that the bus driver might not stop if she didn’t send the notification to the driver. Another user questioned how to cancel the notification if her schedule changed and she wouldn’t take the bus. This enactment was somewhat an “undesirable future” to our users, and thus we decide to make it an optional setting that could be particularly valued by visually impaired riders who worry that the bus might pass by them.

Participants favored the real-time bus map, and preferred a more concrete map to an abstract route map.

To test out what information should be put on the bus stop display, we provided two versions of a map to participants during the user enactments. One is a graphical map with the layout of the city, bus stops, the bus rider’s location and the real-time bus location. (Figure #) Another is an abstract route map in which dots represent bus stops and lines represent bus routes. (Figure #). Users thought the information on the graphical map, including bus location, bus arrival time and the map itself, was very helpful. One user mentioned that a map could definitely help those who don’t have a mental map of the area. However, most users were confused about the abstract map, saying there should be some legend or instructions to help understand it. Based on users’ reactions to the two versions of map, it was easy for us to decide that we would continue our design with the more concrete map. Another interesting minor finding with the map was that participants were not actually interacting with the display when checking information on the map. Only when asked by the confederator to switch between routes would they actually tap on the screen. Therefore, we thought there wouldn’t be any need to put an interactive display at the bus stop. We could just put an ordinary display and split the screen for different routes.

4. There were both likes and concerns regarding providing a game on the display.

On one hand, participants showed interest about the game on the display and thought it a good way to kill waiting time at the bus stop. Some user even proposed more ideas about the game, e.g. social competition, a ranking system and variations of games. However, most users were concerned that if there were too many people at the bus stop, they may feel some pressure or embarrassment about playing the game in front of others. Another big issue is when there are multiple riders at the stop who all want to check information or play the game on the display – how do we allow access by multiple riders? Still others wanted to continue to play the game after getting on the bus. This feedback provided more opportunities and at the same time more constraints to providing a game at the bus stop.

Participants sought minimal effort when interacting with the system.

Most participants responded that they want the interactions involved in getting bus information to be minimized. For one enactment we asked participants to send text messages to get bus information. Most participants felt the information they received was very helpful, but sending the text message was not an ideal interaction. One user suggested sending keywords instead of sentences in order to retrieve bus information. Although sending and receiving the text message was only a way of faking the notification and we wouldn’t use it for our future design, we still gained valuable insights from participant’s negative attitude towards effort-taking interactions, and would pay more attention to simplifying the interaction of our design in the future.

Ideation and Selection

Based on the feedback from our participants in the user enactments, we held another round of brainstorming in which we generated new ideas and small improvements/adjustments to our existing ones. To further determine the direction of our future design, we picked out and merged those newly-generated ideas based on the constraints we detected through user enactments, and the criteria we had established in Milestone 2 (though with a reduced importance given to accessibility). New ideas generated in this brainstorming are mentioned below:

Ideas

Put in QR codes on each of the bus stops. When the users scan the code on their smartphone, they will get a live map on their screen which will show them the exact location of the buses that arrive at their bus stop. They would be able to select which bus they wanted to observe and the location of the bus would change with time. The time of arrival is also displayed at the top of the screen. The users would also have the option of playing a game of spot the difference in order to kill time till the bus arrived.
Use a screen to share bus information and provide a playful experience by allowing users to play games based on their location. From the feedback we have received a game was an appealing idea, however it was clear that people had concerns regarding interacting with the screen while others are looking and maybe seeking information regarding the bus. So we propose an alternative idea in which users are still presented with a screen at the bus stop and there is still a playful aspect to it using their own devices. The screen will show a QR code that people can scan if they wanted to play a game specific to that location, and then they can share their scores on a small section of the screen. This will allow users to share and communicate with others without being obtrusive or controlling of the screen. This creates interesting opportunities for location-based applications, for example advertisements. Each stop will have different games or content from other stations and that content could be designed based on nearby locations and types of people who take the bus from that location.
In addition to a game, we can provide other interactions, like news checking, weather, commercials, movie trailers, etc.
Put a display on the bus that shows real time information regarding the bus location so that commuters are aware of their current locations and plan their destination accordingly. They can do that by specifying their desired destination on an app which will then inform them when they are getting closer.
Indicate in the app how many people are on the bus, color the bus in green, orange, red
Two-way communication is seen as valuable on bus, but not so much at the bus stop. Keep two-way communication on the bus, but at the bus stop make this an optional feature for visually-impaired users (so as to make sure the bus does not drive by them).

Constraints

Design for situations with one person and many people at a stop.
Design an unobtrusive experience that does not violate people’s privacy.
A design that allows for multiple types of interactions and features, both for information and entertainment.
Design for newcomers and regular commuters.
Make it easy and minimize interactions.

Criteria

These are our criteria from Milestone 2: usefulness, appropriateness, legibility/usability, plausibility, and accessibility.

Usefulness– Our system aims to make bus travel easier for the commuters by keeping them better informed about the exact arrival times of the buses. We aim to improve bus travel for commuters by enhancing their bus stop and on-bus experience. While trying to make the experience fun and engaging, we are striving to serve the primary motive of keeping the commuters better informed is served.
Appropriateness– Based on the data we have collected from our previous studies and user enactments, we have gained an understanding of the users’ needs and sentiments. Keeping that in mind, we will aim to ensure that our system meets everyone’s norms, practices, goals and desires. Our solution will be tailor made and suited to all the commuters of the AAATA bus service in Ann Arbor, Ypsilanti.
Legibility– Ease of use and early adoption are the main objectives of our solution. Interviews and user enactments have been conducted so as to get feedback from the users and see what solution would be the best fit for them in terms of usability.
Plausibility– Most of the infrastructure and technology that we have incorporated in our ideas already exist and we will use them to create our product. We envision that a few changes will have to be made in the bus stop and bus station environment for our product to work. There are displays at bus stops in various major cities in the USA. Pushing data to a smartphone by scanning a QR code is also an existing practice which is not difficult to implement. The use of Bluetooth beacons is a fairly new idea and it will help in giving accurate location and times to the commuters. There still may be some further small changes to our design over the next couple of weeks as we begin physical prototyping.

From what we learned in the user enactments, we are largely retaining these criteria from Milestone 2, but reducing the centrality of accessibility. The importance of plausibility is also reduced given that we have added screens to each bus stop, as described in the modifications of our ideas below:

QR Code at bus stop: this addition supports the goals of being useful for both newcomers and commuters. Bluetooth beacons will be retained for use by regular commuters.
Display screen at stop: This screen is not interactive but allows for people to get information on the bus’ location. A leaderboard for the game is also displayed. Gameplay will take place in the app.
Only allow two-way communication on the bus to notify the driver of the desired stop. Optionally include a setting for visually impaired riders to notify drivers from a bus stop.
Provide information in the app regarding the current capacity of the bus.

System Proposal

Storyboard 1: Newcomer

The system that we have proposed in storyboard 1 is for the first time users. Our solution involves the use of an electronic display screen at each of the sheltered bus stops in the city. This screen will display the real time location of all the buses that pass through that bus stop. It will be a split screen display of all the bus routes. The bus stops will contain a QR code and the user will be invited to scan the code using his/her smartphone. On scanning, the user will get further bus information and have the option of downloading an application which will help track the bus. The app also comes with a built-in game that commuters can play. A social element has been added to the game as well. The user’s scores will be recorded and a leaderboard will be displayed at the bus stop. Once the users have selected the bus route they want to use, the app will notify them of any particular changes in timing or if the bus is about to arrive so that they can play the game while being alerted at the same time. The QR code solution is for newcomers and potential one-time users of this feature (non-regular bus travellers). This system would need some infrastructure and capital from the AAATA in order to install the displays at the bus stops. That would take some significant time(1 to 2 years). Designing and developing the mobile application and the game and the technology to push the information through the QR code would take around 4 to 6 months at the most.

Storyboard 2: Regular commuters

The next part of our system was targeted towards daily commuters. This system involves the use of Bluetooth beacons that have to be attached to the bus stops as well as the buses themselves. Once the user has the app downloaded on the phone and has favorited the daily route that he/she takes, the app automatically sends a push notification when it detects that the user is near or at a bus stop. The GPS system on the bus gives accurate information of the bus location and that information is pushed to the user’s smartphone. The game and leaderboard feature is present for daily commuters as well. By virtue of having the application, they have a whole suite of additional features that they can use. Users can notify the driver of which stop they want to get off at through the app. There would be a provision for our visually impaired users to notify the drivers that they are waiting at a particular bus stop. The app will also notify the user about the current number of people in the bus. This will be indicated through color codes: red = crowded, yellow = moderately filled, green = lots of seats available. Another feature that the users can choose to enable/disable is receiving location updates while on the bus. If the app detects that the user is on a different or new route, it can inform him/her about the name of the bus stops as the bus is approaching them. Development time for the application and including these features would take about 6-8 months. The purchasing of Bluetooth beacons will require sizeable capital. Setting them up on all the buses and bus stops will require decent manpower and the whole process should take around a year at least including the initial testing phase of this technology.

Demo Development Plan

For our prototype we want to focus on the experience of receiving a notification at the bus stop (or scanning the QR code) and the interactions that take place while waiting for a bus to arrive (i.e. checking the status and location of the bus, playing a game, checking the leaderboard at the bus stop). These two experiences are what makes our service unique and were the highest rated aspects in the user enactments.

For a more high fidelity prototype we would ideally like to develop a very basic Android or iOS app that could interoperate with a real Bluetooth beacon (and use Android Wear to push notifications to a smart watch), but this largely depends on our programming ability and available time. We might instead have to rely on an interactive Axure prototype running on a phone to simulate these experiences. Since no interactions take place on the the screen at the bus stop, we will prototype this screen using simple images that change as needed (for instance, to show the “updated” location of a bus or an updated leaderboard).

By prototyping these experiences, we hope to better simulate the following aspects of our apps:

the seamless and effortless push experience afforded by having a Bluetooth beacon at each stop (in the user enactments, users were sometimes confused by the text messages that were supposed to simulate both app notifications and app interactions)
the social experience of playing a game only available to riders at a bus stop and competing with other riders who use that stop
the versatility of our design for both newcomers and regular commuters (the QR code aspect of our service is a new addition inspired by the enactments).

Conclusion

We feel that the enactments were useful in determining the limits of some of our ideas (for example, how many notifications a user would like to receive, their desire to have two-way communication with the driver and when and where they would want this), validating our gameplay concept, and inspiring changes (moving gameplay to the app rather than the screen at the stop). Overall, the user enactments were a good way to further our ideation, to recognize constraints and limits, and to understand how users might use (or not use) and value (or not value) what we are creating.