Touree, an app designed for those concerned for their safety while they travel, helps users find fun excursions with tour guides who have been verified via background checks.
Over the course of 5 weeks during the UX/UI bootcamp through UCI, the 5 of us came together and formed a group that we affectionately named Team AwesomeSauce. We were then tasked with choosing a wicked problem to take on. We were given a few options, and our team chose the problem of travel.
We dove into the design thinking process to find a solution.
We began with empathizing, conducting preliminary user research and creating behavioral archetypes to help us put ourselves in the user’s shoes.
Then, in order to define the problem we conducted user interviews and created a survey to help us hone in on the specifics.
Once we picked up a few key user insights, we created our “How Might We” statement and began to move on to ideation. In hindsight, I believe this was the point in the process where we unknowingly began our run-in with scope creep.
We held a few brainstorming sessions, using various techniques and tools to create a divergent/convergent flow, helping us come up with a few solutions. Once we settled on our “must haves” and prioritized our solutions, we began prototyping.
We then divvied up the tasks, but in our excitement to exceed expectations a few of us lost sight of our primary focus and extra features crept in. Our issues with scope creep became much more noticeable (though at this point we did not know what scope creep truly was), and once we ran a few user tests we realized our user flow had become much more complicated than intended. However, we pushed ahead, acknowledging the issues and noting them to be resolved in future iterations.
We presented our project to our instructors and peers, answering questions and receiving feedback. This was when we learned that the issue we had run into was called scope creep, and afterwards, I proceeded to research it in order to avoid the issue in the future.
My favorite part about this team was the collaborative effort and sense of camaraderie. Was it perfect? No, we had some disagreements, but we all respected each other and made sure everyone’s voice was heard. I find that level of cohesion is commendable.
As a group we chose Johnny to be lead. I voted for him because he had already demonstrated to us that he was extremely organized, confident leading discussions, and he openly expressed his interest in the leadership role. Looking back, I believe we made a good decision.
In our group we commonly worked together via Zoom, Figma, FigJam and Google Docs. We scheduled multiple weekly meetings outside of class to facilitate our collaboration, and to assure that everyone was gaining valuable experience in each aspect of the project.
There were some activities that we each performed individually, then came back together and combined our work into a new product, such as the creation of the behavioral archetypes.
The only activity we split between us visibly was the creation of the wireframes. During this part of the project I was tasked with designing the search results page and the tour guide profile page. I also designed the header bar, hamburger menu and footer menu bar, and iterated them after receiving feedback from the team.
Once we had formed our team, our instructor gave us a selection and asked us to choose a wicked problem to address.
A wicked problem is defined as a problem that is difficult or impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize. It has no determinable stopping point as there is no single solution. A solution to a wicked problem is not judged on a scale of right and wrong, but on a scale of better or worse.
Our team chose to tackle the problem of travel and we were tasked with finding our own solution.
Which aspects of travel should we focus on?
Time for the team to take a journey through design thinking! Where do we start? We must put ourselves in travelers’ shoes in order to form an understanding of their needs.
So our journey will begin in the Floodplains of Empathy.
A mobile app to help travelers connect with professional excursion and tour guides.
It needs to be easily navigable
Travelers and professionals need to be able to communicate in a timely manner
Travelers must be able to read and leave reviews
Professionals must be background checked
Travelers must be reassured that the professionals they’re connecting with have been vetted
We were given a total of 5 weeks to complete this project, from initiation to the presentation of our prototype.
We were required to work with Figma and Google Docs.
A 5-week-long journey across the vast lands of Design Thinking.
Week 1: The Floodplains of Empathy; We begin our journey here, and we must pay a toll consisting of user research in order to make it through these lands.
Week 2: The Defining Mountains; In order to navigate this terrain we must answer a riddle, by defining the user problem that we aim to solve.
Week 3: The Dunes of Ideation; To safely cross the sands we must first conquer the brainstorm, and then prioritize our design decisions.
Week 4: The Allied Nations of Prototype and Testing; First we must build and iterate a prototype of our ideas, then we must test our prototype with users in order to complete this leg of our journey successfully.
Week 5: The Presentation Sea; To master the sea, we must gather our research and design decisions, then make our case to the stakeholders in order to procure passage across the waters.
In order to determine which specific aspect of travel causes users the most pain and brainstorm solutions, Team AwesomeSauce scoured the Floodplains of Empathy. We gathered up preliminary user research and used behavioral archetypes to identify shared needs among potential travelers.
Before reaching the border, the team stopped at a tavern for a brief respite. Here, we met Josephine Smith. She was the embodiment of our target audience; she had a thirst for life, and was traveling in search of new and exciting experiences!
Intrigued, the team asked her to join us on our journey and share her story with us. As it seemed we were traveling in a similar direction, Josephine agreed, and the next day we continued our journey into the Defining Mountains.
“I thought once I settled up there in my cabin that that would be my place, you know? That I had found my spot and I could finally just be content.” Josephine sighed wistfully as the group continued their comfortable pace down the worn road. The air had a cold crispness to it that only came with the dawning of a new winter’s day. Thankfully they were far enough to the south to have avoided snowfall, at least for now.
“Once the weather turned and the chill started seeping into my bones, the longing hit me again. The wanderlust. And I just started thinking, I bet it’s still warm further south, it’s been a while since I traveled… You know I’ve never been to the rainforests, I don’t mind a bit of rain… I bet it’s warm rain at least.” Josephine’s eyes were alight with amusement as she followed her train of thought aloud.
After a beat Josephine let out a sigh, “I wanted to bring my friend Crystal along, but I found out she went through something terrible the last time she was traveling. She was too afraid to come, and I had no idea how to reassure her.” She shrugged helplessly, but continued walking along with the group.
We considered Josephine’s friend - she was scared. She was concerned about her own safety. Safety while traveling is a huge concern for everyone, so what could Team AwesomeSauce do to help travelers feel safer?
After hearing about Josephine’s friend, the team decided to conduct some interviews of fellow travelers in order to gain more insights.After hearing about Josephine’s friend, the team decided to conduct some interviews of fellow travelers in order to gain more insights.
Knowing that in order to gain as much data as possible we would need a multi-pronged approach, the team also set out to survey other travelers.
We had hoped to meet a few professionals during our travels, but were not fortunate enough to encounter any. The team decided that if we were to find ourselves with the same need in the future, perhaps we would have better luck putting out a call to The Order of the Reddit.
The group arrived at a split in the road and paused. “Welp, it looks like it’s time for us to part ways.” Josephine announced with a small smile. We said our goodbye-for-nows, sure that we would see her again one day, and she continued on her journey to the Melipona Rainforest. We turned and continued on our way towards the Dunes of Ideation.
While we walked, Team AwesomeSauce reflected on what we had learned. We used the time to synthesize our research, and we were able to come up with a few key user insights.
Travelers want to be able to find a reliable and trustworthy guide in order to appease their worries while traveling.
Travelers wish to be able to communicate with their guides in a timely manner in regards to their excursions.
Travelers do not want their whole trip to be scheduled tightly and prefer to have flexibility in their plans.
Travelers read reviews beforehand in order to check the quality and safety of their trip.
After synthesizing the data, the team had to decide which pain point to focus on, so we asked ourselves…
How might we reassure users that they can connect with knowledgeable and verified professionals, in order to have safe excursions?
The team generated several ‘how might we’ statements based around various user needs, but agreed to primarily focus on this one. We needed to figure out a way to convey a sense of security to our users.
Unbeknownst to the team, a small being had appeared, and it stalked us silently from the shadows.
It was a Scope Creeper - a complicated little creature emboldened by ambiguous scope definition, and strengthened by lack of formal scope management.
While AwesomeSauce did a fantastic job of making sure everyone was heard, our struggle with narrowing down our focus began with our ‘How might we…’ statements, and we unknowingly began our encounter with scope creep.solution.
It started out as a small monster, and the team did not notice the beast, but it began to follow us along our journey, and it began to grow…
Team AwesomeSauce continued our journey through the lands of Design Thinking, moving from the Defining Mountains to the Dunes of Ideation - a stark yet beautiful landscape that would allow anyone brave enough to explore its vastness to envision their wildest solutions.
But making it safely through the dunes meant that we had to conquer the brainstorm.
We used a creative matrix to help us access our divergent thinking, opening our minds to possible features and ideating creative solutions.
We used the “Must Have, Should Have, Could Have, Won’t Have” prioritization method (a.k.a. MoSCoW) in order to access our convergent thinking, reeling ourselves back in and giving ourselves some more realistic constraints for the scope of the project.
After the MoSCoW Prioritization, our team narrowed down our scope even further by using FigJam for dot voting. Once we agreed on the route we wanted to take, off we went!
Team AwesomeSauce finally made it to the nation of Prototype, the land where dreams become reality!
After our long journey, we excitedly shuffled into the border town of Wireframe. The town was surprisingly busy, and larger than expected. We agreed that the best strategy to make it through was to divide and conquer.
Each team member was assigned two screens for wireframing and prototyping. I was assigned the page for search results and the tour guide’s profile page. These are the first iterations.
What is this beast?!
We've bitten off more than we can chew!
After the team split up, in our excitement to exceed expectations, we lost sight of our scope and new features crept up on us.
Without a product owner or a clear form of scope management we had no defense, and some of us lost focus on the primary features.
In the scope creeper’s wake, we were left with more screens than necessary, and a complicated and confusing user flow. The functionality of the prototype also ended up suffering a little bit, as we had a few missing connections here and there.
After the attack there was nothing left to do but keep on moving forward, so we packed up our progress and extra features and departed from Wireframe. We followed the i-1 (iteration-1 highway) westward toward Mid-Fi City.
Once we reached the city, the team worked diligently to bring our creation to life!
Once we had our functioning mid-fidelity prototype in hand, we traveled to the docks of Mid-Fi City. There, we secured passage across the Presentation Sea and prepared for the next exciting step in our journey!
The time had finally come... The time for the team to pull together all of their knowledge, relying on each other’s strength to make it through the stormy waters as they engaged the boss.
And engage they did.
If you’d like to watch our presentation click the button below.
The presentation itself is 8 minutes in length, and it is followed by a 10 minute Q & A session.
Knowledge is power.
Once the name of the beast was revealed to me, I began to study it - to learn from it.
I gained some powerful insights.
I believe there are two primary reasons we ended up struggling with scope creep.
Ambiguous scope definition
Lack of any formal scope management
Through my research I discovered a few steps and strategies the team could use in the future to help prevent scope creep from becoming an issue.
We could create a scope statement with features both in and out of scope.
We should be thorough, making sure everybody on the team is aware of requirements, deliverables and other details.
We could create a scope management plan that includes a change management process.
In order to help manage the process, we could use traceability by formally communicating, reviewing, and getting all requirements approved by a Product Owner.
If preventative measures prove not to be enough and our team still runs in to scope creep in the future, there is a two step damage-control plan that I came across.
We need to pause and think about how this scope creep will affect our project. A good tool for this is the project management triangle! The triangle shows that the quality of your deliverable is determined by finding a balance between three constraints - scope, speed and cost. If the scope changes it will affect the others. Will the scope creep extend the expected timeline of the project? Will it increase the cost? Knowing how it will affect our resources is important in determining how to deal with it.
Once we determine how scope creep will affect the project, we need to decide which constraints to prioritize. If a client has a firm launch date then we’ll need to prioritize time, which might mean an increase in budget. Vice versa, if the budget is non-negotiable then the timeline might need to be extended. If we expand the scope, but wish to maintain the original cost and timeline, the quality of the finished product will suffer.
Avoiding the scope creeper requires remaining ever-vigilant! It is not a beast that can be forever defeated, but it can be guarded against and driven back if summoned!
In order to progress and improve, we would need to go back to the empathy stage and really dig into all of the feedback we received from our user testing, presentation and peer critiques. Then, I think the most important step would be clearly defining our scope and agreeing on a method of scope management before we iterate.
In spite of our struggles with scope creep, I thoroughly enjoyed creating Touree with my teammates on this project. Should Team AwesomeSauce ever reunite, I know we would overcome any obstacles we might encounter along our journey and succeed in reaching Hi-Fi, the capital city!
Thank you for joining us on this adventure!
While I did explain a few of the tools and techniques that were used during this project, our team used quite a few that are not shown above. If you’re interested in seeing our use of a specific tool or technique, here is an alphabetized list of what we gained experience in while we tackled Touree.
Click any of them to view our work.