Executive Summary
Kiwi is an AR/VR airport navigation application based on Apple's upcoming Vision Pro Headset
Approach: Lean UX
Objective: The Kiwi team's main objective is to provide our customers with an air travel experience customizable to the users' needs with a focus on accessibility.
Role: Team member in charge of creating the visual waypoints section of the application
Team Size: Four
Duration: 8 Weeks, October 2023 - November 2023
Tools: Figma, Figjam, AfterEffects, Discord Teams
Links:
Introduction
Before I get into the prototype, I first want to tell you a quick story. This past summer, my family and I went to Boston on vacation. When we touched down in the Boston airport, my family began to walk around the airport trying to find the car rental service. After a while of searching we finally found it but it took way too long. That's where Kiwi steps in. Whether you're trying to find the car rental service, your gate, or even somewhere to eat, Kiwi aims to help you navigate the airport with ease.
For this project, our team used Lean UX as our design process. Lean UX is a design process created by Jeff Gothelf. and is meant to get MVPs (minimum viable products) to the consumer as fast as possible and to make mistakes and learn from them. Lean UX builds off of both Agile and Scrum. Agile is the idea that collaboration and change is more important than any plan for a product. Scrum is the framework for teams to solve complex problems by encouraging the team to learn through their experience. Combine the practices of Agile and Scrum to UX design and you get Lean UX.
Since Kiwi was created as a school project, Lean UX has been modified a little to fit the time period of the class. For our project, we only did two design sprints over the course of 8 weeks.
This process page will go over both design sprints and my contributions to the project and conclude with my final thoughts on this project as well.
Sprint 1
Before I go into each week of the sprints, I first want to define some terms for context. A design sprint is usually a 5 day process for teams to look at the product they are creating and the problem it is looking to solve. In these 5 days teams make assumptions about how to solve the aforementioned problem, figure out which ones are the most important, prototype them, and then validate their MVPs (minimum viable products) through user research. Since this was a school project, the design sprint was modified to be over the course of 3 weeks instead of 5 days, allowing us to learn the process.
Week 0
Week 0 of each design sprint is where our team worked together to fill out the Lean UX canvas. The Lean UX canvas is an 8 step guide to understanding business and customer needs in your product domain. The first step in Sprint 1 Week 0 that our team completed was determining the business problem. We went through a brainstorming process where each team member discussed different aspects of our product and its domain to determine the business problem. Below is our teams' full problem statement
"The current state of navigational augmented reality within the air travel industry has focused primarily on individual user experience and information communication. For example, Delta’s “Parallel Reality” panel allows for users to have a customized experience in which their flight information is displayed to them when they opt-in for the experience.
What existing products/services fail to address are the users’ experiences once they walk away from “Parallel Reality” panels, users’ navigational journey to their concourse, large airport population loads, and accessibility restrictions for disabled users.
Our product/service will address this gap by providing a service in which users can seamlessly access navigation waypoints to their concourse/destination, focusing on accessibility for all users, and creating a vessel for communication between users and the airline.
Our initial focus will be providing a seamless, customized, and accessible air travel experience for users.
We'll know we are successful when we see passenger tardiness cut down extraordinarily as well as an increase in customer loyalty. We will also see a decrease in workload for customer service employees as well as flight attendants. Accessibility features will encourage user independence and instill confidence in each user."
After we determined our product statement, we then created a proto-persona to base the rest of the canvas on. A proto-persona is a fictional representation of a real user our product might have based on assumptions made by the team. Having a proto-persona allows our team to make decisions based on her needs. Our personas name was Loren, an auditor who travelled frequently that needed help navigating new airports. She also needed a better way to be notified of flight changes in a timely manner.
After creating Loren and determining her needs and obstacles, we worked on mapping our outcome-to impact. This map allowed our team to determine what we needed to see in order to deem our product a success.
Using both the persona and outcome-to-impact mapping, the Kiwi team was able to come up with several hypotheses that matched Loren's needs and made the business successful. As a team, we determined that the hypotheses that we would create and test would be visual waypoints, route creation, and a purchase portal.
With our hypotheses created, our team wrapped up Week 0 starting to design our MVPs in order to test them with various users in the upcoming 2 weeks of the sprint.
Week 1
Week 1 was the first week of user testing for our MVPs. Richy and Michelle had worked on their first iteration of the route creation, Aline had done her first iteration of the purchase portal, and I had done my first iteration of the visual waypoints.
We completed a total of 3 interviews and each team member wrote down their notes on the interviews before we collectively created an affinity map of our insights. Our interviews focused on our interviewees experience with air travel as well as their frustrations with it. We also showed them our MVPs and asked them different questions to help us improve our work to make their user experience better. All three interviewees stated that they really struggled with navigating airports, especially new ones and that our MVPs would be useful to them in navigating airports. The interviews also allowed us to gained insight about how to improve each MVP. For example, most of our interviewees stated that they preferred having a visible line with arrows to help guide them through the airport. During this week I moderated an interview and personally collected everyone's insights and created affinity maps so that we had a visual of everyone's observations that were similar so that we could apply our user's ideas and pains to our project.
Week 1 also was the first week that our team completed Stand-Up meetings. Stand-ups are a tactic used in Scrum to help teams keep track of what each other is doing and to also allow us to discuss what is coming up in the project and what we need to get done. Our team completed a stand-up every two days.
By the end of the week, our team created our second iteration of our MVPs to prepare for the next week of interviews.
Week 2
Week 2 followed the same set up as week 1 but with the new iterations of our MVPs. Our team completed 3 user interviews and collected our insights, did affinity maps on each interviewee, and completed 3 stand-up meetings. Just like Week 1, I also completed the affinity maps and moderated one of the interviews of this week. However, this week differed from week 1 as at the end of the week, the Kiwi team got together and completed a retrospective meeting. This retrospective meeting allowed us to step back and take a look at Sprint 1 as a whole, determining things that went well with the sprint, what we felt needed to change, and finally what we would try next sprint to do better.
Sprint 1 Final Thoughts
Sprint 1 was a learning experience for everyone on Team Kiwi as it was our first time doing a Lean UX sprint. We gained a lot of useful insight through our user interviews on other pain points of air travel that we had not considered before. I personally gained an understanding of just how quick we needed to move through our project. Since my first class project was done using Goal-Directed Design, a slower and more research oriented approach to UX, this sprint helped me to learn how different Lean UX truly is.
Sprint 2
With Sprint 1 completed, my team moved into Sprint 2 with a lot of additional knowledge on our product and the needs of our users. Sprint 2 is set up the same way as Sprint 1 with slight tweaks and a few new MVPs based on the information gained in Sprint 1. Sprint 2 is very important as it allowed our team to make any necessary changes to our product before the final product.
Week 0
Before our team hopped into user testing for the second Sprint, we first needed to go through our Lean UX and revalidate our choices and make any changes necessary. Revalidation is the process of using intel gathered from users to confirm past assumptions. For example, our team assumed that a main pain point of air travel was navigating new airports. After interviewing 6 different people and gaining their insights, we were able to revalidate this assumption with the testimonies of our interviewees.
During Sprint 2, we made several changes to our Lean UX canvas. The first change we made was our proto-persona. We changed her needs and obstacles to better fit the pain points we discovered in our user testing in Weeks 1 and 2 of Sprint 1. For example, one of the main problems our interviewees brought up was the struggle to find the car rental area at the airport. To reflect this, we added a need to be able to easily get to and from car rental areas to Loren's needs.
We also added a few new hypotheses to our table and got rid of old ones that we no longer needed. For example, we determined that having a rewards system in Kiwi was unimportant but having a widget showing TSA wait times was important and something we needed to test.
By the end of week 0, the team determined that our MVPs would include the ones from Sprint 1 along with a restaurant widget, a TSA que time widget, and a trip planner widget.
Week 1
Just like in Sprint 1, Week 1 of Sprint 2 was focused on user interviews and gathering insight on our old and new MVPs. Some changes were made to our process this Sprint. We changed some of our interview questions to dive deeper into the frustrations of users at the airport. For example, we started to ask our interviewees if TSA lines had ever impacted their gate arrival time. Asking more detailed questions like this allowed us to improve our product even more for our users.
Week 2
During Week 2 of Sprint 2, team Kiwi put the final touches on our project and got some final user feedback in our last 3 user interviews. All of our interviewees really enjoyed our work at this point and only had a few tweaks to mention to make the Kiwi experience that much better. One small tweak that was made to the visual waypoint design was adding the current time at the top so that users could see and keep track of the time easier.
One thing that we did different in Sprint 2 Week 2 from Sprint 1 Week 2 was that our team did a final proto-persona. Our final proto-persona changed a good bit from our original proto-persona made back in Week 0 of Sprint 1. Loren's needs changed a decent amount between the two versions of the persona. Originally, Loren's needs were that she needed to navigate airports efficiently, needed to be able to find food before/in between flights that matched her dietary preferences, and that she needed updated info on transportation to/from her hotel. In the final proto-person, Loren's needs are to navigate the airport with efficiency, to get to and from the rental car areas, to know where the exits in the airport are, to be able to plan out a timeframe for her flight, to find places to eat before/in between flights, to be notified of gate changes, and to get info on hotel transportation. Only three of Loren's original needs stayed the same with many things being added the more we learned from our interviewees.
Sprint 2 Final Thoughts
With Sprint 2 finishing, team Kiwi put the final touches on our app based on the feedback we received in the final interviews. This Sprint was very similar to the last but also allowed us to really understand our product domain and the needs of our users on a deeper level.
Conclusion
Overall, Project Kiwi was really fun to work on. It was a really interesting concept with a great team that really challenged my skills and my way of doing UX. I struggled a good bit at first in terms of prototyping as I had never done anything as complex as this project before but with a lot of dedication and help from my wonderful team I was able to learn a lot and further my Figma skills beyond what I had learned in my other classes.
I also discovered after doing both Goal-Directed Design and Lean UX, I think I prefer the fast paced nature of Lean UX that allows for failure in order to learn. I am someone who likes perfection but being allowed to fail is very freeing and allows me to pivot easier in order to create something even better.
With all that being said, Kiwi was so fun to work on and I want to thank my teammates for making this project a reality with me.