Xperio

Role: Research, Design

Tools: Axure, Figma, Marvel

Introduction

Xperio is a mobile app that aims to introduce and recommend various experiences to people who are relatively new to a city and/or have a thirst for new adventures in a city. The app functions through user input of activities which they are interested in through machine learning algorithms.

I came on this project past the ideation stage when the idea and a medium fidelity prototype had already been created. The team had a total of 3 members — two software engineers and a researcher/designer(me).

As I came onboard after, I had no input on how the Xperio should be created in the first round of iterations. The initial approach was that the team wanted to create a platform that fully relies on machine learning algorithms to recommend the best locations for a person to go to in a city.

Check out Xperio here.

Research

Since we already had a medium fidelity prototype ready to be tested (check it out here!), I had to quickly come up with a test plan and interview questions as I wanted to conduct my own discovery research to prompt for additional underlying problems that Xperio could potentially solve.

Methodology

I decided to go with semi-structured interviews as a form of discovery, followed by think-aloud tasks to get a better idea of what the users thought about the interface. I also conducted competitive analysis on products similar to Xperio, such as Yelp, Google Maps, Meetup, and Nearify to understand the scope of issues in existing solutions.

Check out my test plan here.

As a solo researcher, I had issues in deciding which groups of users to recruit. Hence, I decided to gather participants through a convenience sample, which included my friends who are all mainly international students at a university.

Materials & Apparatus

I decided on two different methods based off the proximity of testing being conducted, which was either in-person or remote testing.

For in-person testing, I will first load the design on Marvel, then use Open Broadcasting Software (OBS) to record my screen, webcam, and microphone.

For remote testing, in addition to in-person testing steps, I will utilize a VOIP program such as Skype or Discord that has a screen-sharing functionality to be able to use OBS to capture their screens and voices.

In-person testing (left), remote testing (right)

Procedure

I first begin my sessions with a semi-structured interview. Initially, I approached the user interview in an extremely rigid manner. I didn’t prompt beyond what was on the script as it was my first actual time performing an interview based around discovery. However, after a chat with a fellow researcher and getting advice on how to better conduct interviews, I changed my ways. I began to let the entire conversation flow more naturally and kept probing further. As such, this was where I finally understood how interviews could be very useful in determining deeper underlying problems that users didn’t know of before.

After user interviews, I provided the user with a brief summary of what Xperio was about. After, I allowed them to explore the app as much as they wanted, stopping them if I had any questions. I provided them with a list of basic and/or trivial tasks to perform with the app. I concluded the entire session with general follow-up questions.

Data Coding

Throughout the session, I took short notes on a notepad so I can get a general overview of the participants when looking back at them. As I also recorded my own sessions, this allowed me to return and qualitatively code any additional detailed answers, observations and cues from the users.

With this, I compiled all of them into a Microsoft Excel sheet (check it out here!). The sheet was separated into 5 different tabs — interview, exploration, post-exploration, tasks, and general. The interview tab contains the user’s answers to my interview questions, with additional boxes for answers to follow-up questions that I may ask. The exploration tab contains my notes for each user throughout exploration, where I detail down special events (e.g. errors, unique interactions, confusions). The post-exploration tab are where answers for questions regarding the app’s functionalities are stored. The tasks tab are where I detail down the actions of the user in a task and anything else I observe. Finally, the general tab houses follow-up questions after the tasks are completed.

In the tasks tab, I evaluated the user’s performance on three different metrics:-

1. Successes
2. Failures
3. Errors
4. Critical Errors
5. Non-critical Errors

Successes and failures are color coded, with each color containing a value to quantify the success and failure rates of a specific task. The colors also allow me to easily identify which functions the users had trouble with (i.e. the lesser the amount of green, the higher the likelihood users had issues with completing the task).

This evaluation system was obtained from my experience in qualitative coding and task performance evaluations at the VECTOR Lab at The Ohio State University.

Color coded task performance evaluations

Findings

Pain Points

From the interviews, I discovered a few common pain points between users:

1. The process of finding new places to go to is extremely manual as users have to sift through multiple places to identify a suitable choice, usually within a time constraint.
2. It’s tough and exhausting to accommodate everyone’s choices in a group setting as every one has unique preferences.
3. There’s a lack of personalization/proximity in apps as users often have to refer to friends for more in depth reviews.

Due to time constraints, I made a difficult decision to not create personas and journey maps, though I would very much like to in future projects.

Design Requirements

Based off the pain points and research we conducted and discovered, we summarized them into a problem statement for our users:

Users need a more efficient, easier and trustworthy way of discovering new places.

With this, we identified a list of design requirements to address this problem. The solution needs to:-

1. Help users easily and quickly identify a suitable new place to go to.
2. Help users coordinate group hangout sessions without neglecting the preferences of others.
3. Help users research for new places with the peace of mind that the review is trustworthy.

Ideation

As Xperio is an app based around experiences, we wouldn’t want to focus on only 1 type of activity (e.g. food). Hence, I held a meeting with my team to identify the general types of activity that we wanted in Xperio. We decided to base the app around 5 main categories — Food, Entertainment, Exploration, Recreation, and Special Events.

With the design requirements in mind, I began to ideate on potential solutions using sketches.

Early sketches of Xperio

At this stage, I began thinking about the content that users wanted. Specifically, what kind of activities should go into each category we listed (i.e. Food, Entertainment, Exploration, Recreation, Special Events)? I decided to conduct a card sorting session to see what the users thought — I utilized the hybrid card sorting method as while we had a pre-determined list of categories, I wanted to see what else the users could come up with.

Card Sorting, with post its on a wall in my room! (budget was tight back then)

After, I compiled all of Xperio’s functions and pages as components in our Information Architecture (IA) as Xperio’s backbone.

Wireframes

After sketches, I created a couple of wireframes on Figma to illustrate the different screens.

Design

After a meeting on the wireframes and decisions on what to keep and remove, we moved on to creating high-fidelity mockups of Xperio. I don’t have much of a background in visual design, hence I thought that the design could’ve turned out better.

This design was originally created with the idea of having 5 categories:

1. Food: Restaurants, Cafes
2. Entertainment: Nightlife, Clubs
3. Exploration: Physical activities (e.g. hiking, sky diving), tourist attractions
4. Recreation: Arcade-ish games (e.g. Bowling, Arcades), physical sports (e.g. soccer)
5. Special Events: Ad-hoc events (e.g. concerts, conferences, meetups)

However, after further meetings, we decided that we should start off with food recommendations first due to technical and time limitations. Hence, our design had to shift from the designs displayed above.

1. Train — A place where users can tell the app what they like or dislike so Xperio can build a more complete user profile to provide better recommendations.
2. For You — A place for users to see different restaurant recommendations that Xperio provides according to their likes/dislikes. They can also create groups with other friends to obtain group recommendations based off everyone’s preferences.
3. Me — Users are able to manage their friends and saved restaurants here.

Redesign

I had just over 2 weeks to work on the redesign for the app. Coupled with schoolwork, I only managed to squeeze out a medium-fidelity design in time for the next round of meetings. This was also the sprint where we were going to conduct our next round of usability testing, so I had to create a prototype as well.

Check out the prototype created on Axure here! (you may have to zoom out to 50% to see the entire screen, my apologies)

Sprint #2 (or never?)

Immediately after I completed the prototype, we obtained news that one of our software engineers found a better opportunity elsewhere. Hence, we decided to make the tough decision of dropping this project.

Reflections

There were several things I learned while working on Xperio:

1. User research, especially interviews, are extremely important in finding out underlying issues that users may not know about.
2. Interviews take time because of the reluctance of some users in opening up further on problems. Knowing how to make an interview flow naturally is a crucial but tough skill to improve on.
3. Communication between design, tech and product teams require practice. It was tough trying to communicate what the users wanted to the tech teams, who were also acting as the product teams in this small group of 3.
4. Axure wouldn’t be my preferred tool to create mobile prototypes. Rather, it would be suitable for web prototypes due to it’s ability to control and move between pages seamlessly.
5. UI Design isn’t my strong suit. Really.

There are several things I would change in the future:

1. Make interviews more conversational and less restrictive. It’s just more natural that way.
2. Work on creating functional specifications for easy hand-offs to the tech teams.
3. Try to think from a more object-oriented perspective, how each object in an interface contributes to the bigger picture.