UX Practices.

Repurposing StarShips

This project consisted of myself and group members Zim Seely, Pallavi Tulpule, Mack Moore, Jiwon Seo expanding on Starship delivery robots to increase human-human interaction (HHI). We worked with the current design space, utilizing ideation sketches, interviews/user feedback, and storyboarding to create our final design.

Project Scope

The scope of this project is to redesign Starships - typically used as food delivery systems - in a way that produces new kinds of human-human connections. Students must utilize Purdue student attitudes toward current starships to create unique delivery systems that goes beyond food service.

Design Space

The team wanted to focus on dormitory spaces on the Purdue campus, particularly a place where mostly underclassmen reside. We chose McCutcheon Hall, home to hundreds of Purdue freshmen as our testing space. McCutcheon Hall is already set up with a Resident Advisor and plenty of board games students can rent out, making it an optimal design space for our project. Our persona consists of freshmen at Purdue who are looking to meet new people through playing board games.

Goals

The goal for our project was to increase human-human interaction through the starship delivery system in ways that forge in-person connections for people with similar interests or a way to meet other students.

Primary Research

Article Reviews

Article reviews on the current design space were performed by all group members. We utilized this research to begin formulating questions to ask participants in interviews.

Interview Analysis

All team members conducted individual interviews in preparation for ideation. The script utilized for interviews was developed as a group.

The team utilized an affinity diagram to determine what factors into the average use of a starship, indicating what is common, liked, and disliked among starship interactions. From our sorting, we identified pain points, liked features, delivery time, and reason of order.

KEY TAKEAWAYS

  • Delivery takes too long / is not always consistent with what the app says

  • Main reasons for ordering starship revolved around bad weather or not wanting to walk somewhere

  • Music and other cool features were aspects people liked about starship

  • App sometimes glitches or marks starship in different location than where it actually is

Initial Design Ideas

As we moved forward with our gaming starship, we generated a number of designs that could build on our ideations and work better based on user feedback. We wanted to start with a smaller user group to test the effectiveness of our design. McCutcheon Hall of Purdue University - the largest dorm on campus - was the perfect test location.

Design Expansion

We wanted the following characteristics implemented in our design:

  • An app to reserve time slots and invite players

  • QR Code on the bot to guide users to app

  • The ability to join other people’s sessions through app

  • The starship brings games to user

  • This increases human to human interaction by providing more opportunities to meet new people

Design Evaluation

Secondary Interviews

“I probably would have used the games more often if it wasn’t a hassle to get them.” - Former Resident

“My biggest concern would be making sure all the game pieces were returned.” - Former RA in charge of checking out dorm games

“It would be cool if the starship had a role in the game or something.” - Former Resident

In order to further improve our design our team came up with some “worst case” scenarios in order to discover and fix weak points of our design. This section will explain a scenario, and then list the changes made to our design in order to fix the issues presented. This was done towards the end of our design process once we had honed in on a design idea we really liked. These scenarios were generated both internally from our team's ideas and through feedback given to us from interviews. The scenarios are as follows:

Scenarios

Scenario 1: NO ONE SHOWS UP

This scenario is one in which an individual schedules a public game to be played at 5:00 pm within the dorm. People sign up to join the game, but when 5pm rolls around no one shows. The user is left feeling more alone than before and this will definitely place a bad light on the design overall.

In order to fix the issue shown within the scenario we decided to implement a mandatory RSVP window as well as a no show fee. The RSVP window will close an hour before the game and members are expected to confirm that they will be in attendance or select that they will not be there for the game. If a user confirms their attendance and then does not show up to the game, there will be a fee charged to them for a no show. This change in our design will hopefully reduce the amount of people that do not show up for a game and thus will increase human to human interaction.

Scenario 2: MISSING PIECES / DAMAGE

This scenario is one in which a group of people have met up for their board game session, the bot brings them the game, but there are either missing pieces or the instructions are missing/damaged. This will result in the group not being able to play the game and they will most likely all go home which would result in less human to human interaction.

In order to fix the issue of missing pieces, we decided to implement a requirement when turning back in the board game. Users must submit a photo of the game with all the pieces in order for the starship to return to the front desk with the game. Users will also be able to report missing pieces if they notice any when receiving the game. This will help prevent missing pieces from happening and affecting others .

In order to fix the issue of damaged or missing directions, we decided to place a removable tablet within the bot that will display the directions of the game to the users. This is great for people who may not know how to play a certain game and the instructions are missing. These updates to our design will make sure that students will always be able to play and pieces are not missing at any point in the process

These scenarios helped us gain more context and look at our design from different user perspectives. When paired with our secondary interviews, it really helped us tune in our design so that we could make it increase human to human interaction to the best of our ability. The next section, evaluations, will dive into more detail and changes that we made to the bot based on both our interviews and scenarios.

The first instance of feedback that led to a change in our design was from a former RA of McCutcheon Hall. When asked about the design as a whole, he stated:

Summarizing Implementation of User Feedback + Scenarios

“My biggest concern would be making sure all the game pieces were returned.”

This led us to edit our design of the mobile app that was associated with the starship boardgame service. Now, in order to return a game, the user who checked out the game must submit a photo on the app of the game with all required pieces present. We also implemented the ability to report missing pieces of a game on the app as well. We decided to incorporate these aspects of the app directly because of the former RA’s feedback as he was once in a position of authority relative to board game usage within McCutcheon.

In another interview, with a student that used to live in a resident hall, when asked their opinion on our design they stated:

“It would be cool if the starship had a role in the game or something.”

This led us to try and find ways we could incorporate the bot itself within the user game experience. After brainstorming as a team, we decided that the bot itself could contain a tablet that would display game rules as well as a card shuffler on top of the bot that could be detached and help users shuffle and distribute cards. Not only did these ideas make the bot more interactive within the user’s game experience, but they can also be helpful for those who may have disabilities and find it hard to shuffle cards. The tablet with the game rules would also be helpful as frequent use of games can lead to the rules paper being damaged, lost, or completely destroyed.

Along with this user feedback, we also incorporated our worst-case scenario in order to add characteristics to our app. From our worst-case scenario and other ideas being generated, we added the following elements to our design:

Mandatory RSVP feature to avoid no shows

  • No show penalty fee

  • Private games (Invite only)

  • Public games (Open to all)

Next Steps

Usability testing within McCutcheon 

  • Test in other dorms and see how design needs to be updated

  • Gather user feedback from students and faculty

What we would do with more time:

  • Further develop aspects of the app (Party Type, Reporting Users, Different game locations) 

  • Conduct more interviews with current dorm residents and RAs

  • Gather research on popular games in order to better optimize user experience and flow of app