CITYQUEST
DURATION
CATEGORY
In the fall of 2019, after being named scrum master and brainstorming on a myriad of ideas, my team and I settled on an app that encouraged people to go out and explore their city or community, later known as CityQuest. Our chosen method was Lean UX, a process which allows for rapid and iterative design through in-person, collaborative communication. The goal of this process was to create an MVP, also known as a Minimum Viable Product, that could represent CityQuest for testing and iteration.
2 Months
ROLE
Scrum Master
Android App
I led a UX/UI app project with a team of 3 in my Interaction Design II class. As the scrum master, I organized my team, created the schedules and deadlines, produced much of the high-fidelity prototype, and was available for any questions my teammates had.
OUR TEAM
Brianna McBride
Scrum Master
Carter Francis
Team Member
Parker Bomar
Team Member
SPRINT ONE
We began in early October with our first of two sprint cycles, each of which spanned three weeks. These sprint cycles allowed my team to focus on a few things at a time, while also completing an MVP in two months. Our first cycle focused on creating the foundations for the project: the product backlog, the high-priority features for CityQuest, and user testing.
PROBLEM STATEMENT & ASSUMPTIONS
We began by assessing the situation and writing a problem statement that described what was missing in our app’s field, and how CityQuest would fill that gap. This ensured our team was keeping the right goals in mind as we went through the first sprint.
“…our initial focus will be building the structure of the app, including the challenges, local opportunities, and reward system.”
- excerpt of CityQuest's problem statement
From there, we wrote about the assumptions we had for our app, our potential users, and the market it was entering so that we would be aware of our own opinions and biases, and how that may affect our creation process.
We affinity mapped these ideas and discussed them in detail, which also helped us generate ideas for how to address some of the questions posed by this step.
PRODUCT BACKLOG
Once we had addressed our assumptions, we moved into creating our hypothesis table. We discussed what outcomes would be desired for the business, what our users’ goals would be in using the app, and the features that could complement those goals. We also created our proto-personas for Sprint 1: Tom, Sandra, and Tiffany.
We believe that we will achieve [business outcome] if [proto-persona] can achieve [user outcome] using [feature].
- the template for hypothesis statements
We affinity mapped our assumptions, then moved the next draft of the table to the whiteboard, thus creating our product backlog, which would be used across the entire project. Our product backlog was prioritized and pieced into a sprint backlog, which focused on the following:
-
Map View
-
Suggested Points of Interest
-
Challenges System
-
Rewards System
-
Progress Bar
PROTOTYPING
Though we were on the same page in terms of large-scale ideas, we didn’t want to limit any possibilities, so we met again to participate in an individual prototyping session. Each team member expressed their vision of CityQuest on a low-fidelity space for discussion and evaluation. We went around each whiteboard, explaining our ideas to the team as we progressed, and decided on the best aspects of each design to integrate. We then moved into our group prototyping on paper.
USER TESTING
Though we began moving the low-fidelity prototype onto the prototyping software Figma soon thereafter, we wanted to test our concepts of the app with users before getting into the details of design. We met with two groups of three users.
For the first group, our questions revolved around the larger concepts: how they preferred to explore their city, what challenges they have in discovering new experiences in their area, and their favorite things to do in town. Our participants gave us fantastic feedback on what to include, how to prioritize information, and what needed to change.
Before our second session of testing, we did some low-fidelity prototyping in Figma and began evolving that into the medium-fidelity scale. We experimented with a myriad of color schemes, one of can be seen here. Once we had the most vital pages prototyped, we moved into our second group of testing.
Our feedback became more diverse once a prototype was put in front of the users: one liked the color scheme, while others thought it was overwhelming. However, all three liked the catchy names for the challenges we had created, and they understood the structure of the pages and how they were linked together.
REVISION
Everything began to fall into place after our second group of testing. We went through a few more color ideas, but settled on the blue and purple theme. Some pages, such as the achievements page, were completely reworked. On a smaller scale, other design details were added to give the app a unique flair. Below is a sample of our pages at the end of Sprint 1:
SPRINT TWO
Kicking off our second sprint in November, we focused on solidifying the structure of CityQuest by revalidating our research, continuing to add and iterate on features, and conducting further user testing. As with before, the second sprint was three weeks.
REVALIDATION
We began our second sprint by revisiting our problem statement and product backlog now that we had been entrenched in the app for three weeks. We made minor adjustments to our problem statement, and revalidated our product backlog with very few changes. Our most significant change was in our proto-personas; we felt that our third persona, Tiffany, did not bring anything new to the table. We therefore cut back to just Tom and Sandra as our two personas. These proto-personas represent our assumptions of real users so that we can have someone in mind during the design and planning process. Unlike the research-heavy personas in Goal-Directed Design, Lean UX's proto-personas are made quickly and can change as needed.
Tom Hawthorne
"Student"
Age: 21
Income: Lower-Middle
Area: Midtown
Needs:
-
refreshed social life and romance
-
cheap experiences
-
social media integration
Obstacles:
-
low income
-
limited time to explore
-
no vehicle
Sandra Gilligan
"Stay at Home Mother"
Age: 47
Income: Upper-Middle
Area: Suburbs
Needs:
-
new experiences
-
new social group
-
new creative sources
Obstacles:
-
limited time
-
limited social group
-
considering spouse in decisions
PROTOTYPING
Though we were doing further iterations of pages we had already created in the previous sprint, we were also adding new features, so we went back to the whiteboard with an individual prototyping session. Each team member drew their concepts of what leaderboards, difficulty ratings, profiles, and social media integration would look like within CityQuest.
Through this process and the discussion that followed, we realized that difficulty ratings were unnecessary for the challenges; the challenges spoke to their own difficulty without needing a scale and did nothing but clutter the space further. We successfully integrated our ideas into a group prototype of the profile page, social media links, and leaderboard, which were then put into Figma.
USER TESTING
Once again, we completed our testing with two groups of three participants on two different days. We diversified our test subjects for this sprint, bringing in both introverted and extroverted users. This test group was focused primarily on finalizing the decisions made in the first sprint, and the feedback we received was detailed.
We received confirmation from all users that the blue and purple color scheme was the right decision, and we were given suggestions on how to improve navigation. Including a leaderboard seemed to be of a lower priority to users, while we were shown how important an onboarding process would be for the app. This led to the removal of the leaderboard from our backlog and the higher priority of the onboarding process.
These ideas were integrated into our prototype before our final group of test participants. Once again, these users were more diverse in personality, and some had background in usability.
Our most emphasized feedback focused on cosmetic details - switching from one icon to another, or color differences between incomplete and complete challenges. We therefore believed that our large-scale functionality is in order. We made these smaller adjustments, which lead to a sense of cohesiveness with the prototype.
Throughout this last group of testing, our results were overwhelmingly positive - participants discussed how consistent and aesthetically pleasing the prototype was, as well as how much they liked the concept behind CityQuest.
THE FINAL PRODUCT
At the end of the two-month project, I gave a presentation of my team's process and final design to the class. I detailed each stage of our Lean UX process and how we applied it to our app creation.
I have to thank Parker and Carter - this could not have been done without my teammates. We worked hard to create an app that can help users meet their goals, and I am excited to present CityQuest's MVP.
Click the phone to view the full prototype!