Kiwi

Role

UX Designer & Researcher

Duration

8 weeks

An AR application for navigation assistance and convenience through air-travel experiences.

Tools

Figma & Figjam

Method

Lean UX

Project Overview

This project was done by a team of 4 IAD students using the Lean UX design method. We conducted our work over a span of 8 weeks, from October 2023 to late November 2023.

Our objective was to design a prototype for an AR app that makes the air-travel experience seamless, inclusive, and personalized. We used a mixture of tools to share artifacts, communicate, conduct research, and cosntruct the prototype.

Goals

  • Make navigation assistance simple, intuitive, and customizable.

  • Provide route creation tools for travel assistance within airport.

  • Offer the ability to purchase/ manage services and products, related to air travel, within the app.

  • Design for inclusivity and accessibility.

  • Design interface for development in the Apple Vision Pro headset.

The Approach

The Problem Space

Our team recognized the issue of poor air travel experience. By looking at the failures current products have with accessibility, accuracy, and overall user experience, we decided to tackle this problem with AR technology. This decision was formed because of the advantage integrated, customizable visual guides would have for user navigation and comfortability in a populated, moving space. It also provided us with the challenge of developing something original, unique, and future-facing as AR / VR is becoming a more dominant technology.

The Design Method

For our design method, we used an adaptation of the Lean UX framework. In the traditional sense, this method is based on cross-disciplinary teams working within a short time frame, prioritizing continuous learning by improving designs iteratively. In the words of Jeff Golthelf and Josh Seiden, this method "brings the nature of a product to light faster, in a collaborative, cross-functional, and user-centered way" (Lean UX: Designing Great Products with Agile Teams, 10).

Our timeframe was eight weeks, comprised of two sprints - each being three weeks long, and two weeks for refinement after the sprints. Working in-person was most ideal but was a challenge since our team consisted of full-time students with our own respective availability. Being able to meet virtually impromptu and employ frequent, consistent online communication was key to achieving our goals and building a proactive environment with the given time constraints and schedule conflicts.

Making Kiwi…

The Lean UX Canvas

This canvas guides a team through collaborative, brain-storming exercises to establish our initial assumptions. This allows teams to validate ideas quickly and deliver ‘minimum-viable-products’ (MVPs) - products that require the least amount of resources to make while still being able to garner valuable data.

For instance, we initially predicted that this product would be applicable in mainly unfamiliar airports. Yet, through interviews and testing, we saw the demand and necessity for this product regardless of a user's familiarity.

For our MVPs, we made four design plans: Visual Waypoints, Navigation Assistance, Route Creation, and Purchase Portal.
These four design plans would answer each of our hypotheses in the Sprint 1 backlog, testing our most-prioritized solutions.

We decided to split up the four MVPs between the team members to maximize our time. I was assigned "Navigation Assistance", which encompassed the user journey for creating a route to a specific gate. This required multiple screens to be made in a sequence that would allow our interviewees to employ the Think-Aloud protocol - in which participants verbally articulate their emotions, logic, and decision-making during an experience.

Proto-Persona

As part of the “Users” section in the canvas, we created a persona based on our collective assumptions about what type of user(s) would comprise our audience, and their needs and behaviors. This is called a ‘proto-persona’ since it is constructed without any user research done, and is also meant to change as we evolve the product.

Our proto-persona is named Loren Hayes, and she is an auditor that has various inconveniences in her regular air travel experiences. Obstacles such as inefficient navigation, lack of contextual information for the airport, and being pressured by time-sensitive tasks were challenges the team foresaw travelers to have regardless of their familiarity in airports. We translated these obstacles to fit the personality we had curated for Loren Hayes.

Sprint 1 / Weeks 1 & 2

Refinement

Canvas Breakdown

Sprint 1 / Design Week

Sprint 1 Retrospective

The MVP for navigation assistance/ route creation was now turning into the official Kiwi Maps feature, which meant finalizing user flows and components. The most intense part of this was the actual map component. This required an interactive, scrollable graphic that contained actionable items. To achieve this, Michelle and I made a component set with 32 variations of all the possible layouts for map filter combinations called “map filtering”. To facilitate manual filtering, I constructed a filter bar component, with 32 variations of the same combinations, that was nested within “map filtering” to allow click interactions to switch between map variants. We set up over 130 interactions in order to have full functionality for users traversing our maps feature.

Once the “map filtering” component was complete, the interface for the feature needed to be created to contain the map, in addition to providing sidebar navigation and signpost elements. I made a component set called “Kiwi Maps Interface” comprised of the “map filtering” component and a “sidebar” component which had all the variations for the sidebar navigation.

The maps feature required adjustments to its sizing dimensions and a new component set for the sidebar that would appear as the user entered the map for Concourse A. Additionally, there were minor adjustments to color choices for filters and the text styles used within the “map filtering” component.

  • Forming a product problem statement by identifying current issues & opportunities in the product domain.

  • Determine ‘success’ metrics by identifying what behavior/ actions (outcomes) will lead to the desired result (impact).

  • Infer what type of users and customers we should be focusing on; formulating proto-personas.

  • State what incentives, benefits, and behavioral changes upon goal achievement our users would have with the product.

  • Seek ideas for product creation, feature, or enhancement that will meet the needs of the user and the business.

  • Combine the projected business outcomes, user-types, user benefits, and solutions into individualized assumption statements to gain an understanding of the risk associated with each design plan/ change.

  • Organize the hypotheses according to the risk level and the value of the proposed solution.

  • Planning designs that require the least amount of fidelity and resources to create yet can validate the hypotheses.

The objective at the start of each sprint was to go through the Lean UX Canvas. We collectively performed research and performed brainstorming exercises as we made our way through each component of the canvas. Meetings were facilitated in person, along with consistent communication within Microsoft Teams, as needed, to collaboratively ideate solution features, user needs and wants, and business outcomes. We created a product backlog for hypotheses validation and to keep a record of proposed solutions. We also created a sprint backlog that designated items from the product backlog which would be constructed & tested in Sprint 1.

The following two weeks of Sprint 1 was dedicated to conducting user research and constructing MVPs iteratively. We scheduled five interviews with individuals whom aligned with our projected user-type. Due to the time constraint, we conducted the first interview without any MVPs, and focused on referencing ethnographic approaches to learn more about the target audience. The subsequent interviews began with open-ended questions to still gain insight into interviewee's struggles, motivations, and emotions; afterwards, the interviewees would then be guided through the current MVPs. As we moved through each interview, we made new iterations to our MVPs. We went through four iterations in total, with the fourth becoming the first iteration for Sprint 2 as it was done following our last interview.

An interesting turn of events occurred at the end of week one. As I was working on the Navigation Assistance MVP, a vital part that I needed was actually route creation - which had been designated to another member, Michelle Hayden. In the first iteration of our designs, we made separate screens for route creation. Noting how we had many similarities as well as individual strengths within design, Michelle and I decided to develop our MVPs together. We still separated “Navigation Assistance” and “Route Creation” for testing sessions, but worked as a pair from here on out. My responsibilities were still for the user journey screens and general interface styling, but this pairing also meant more in-depth work towards a fully interactive, customizable map feature.

Our Sprint 1 retrospective was done at the end of the second week through a virtual meeting. With a template provided by the course instructor, we shared our individual thoughts via post-it notes and without any microphones or cameras in use as to ensure that we were being honest and unbiased with our thoughts. The template was organized into three sections.

What went well?
We had all felt that the team had good chemistry, communication, and work ethic. The MVPs were highlighted in the discussion because our iterations showed a definite reflection of user insight from our interviewees, and also moved along at a great pace.

What could have gone better?
Although the interviews were seen as a success, we all had the same thought: we needed better organization and etiquette. This would be improved by altering how walkthroughs would be moderated and planning out transitions between MVPs. We also noted that the UI design needed to be consistent, which meant defining and applying styles for the product.

What will we try next?
Looking toward our next sprint, we all shared a desire to have a functional prototype. We wanted to have a dynamic experience ready for the next round of interviewees, which meant narrowing in our focus so that we would have full interactions for our main features and begin integrating them into an intuitive flow.

Sprint 2 / Design Week

Going into our second sprint, we revisited our Lean UX canvas with new insights and user feedback.
Our business problem was edited to reflect new struggles we learned, such as navigation with car rental locations and accounting for TSA wait times. This also was reflected in our proto-persona through additional needs and obstacles that address assistance with planning a trip and managing timeframes, live information for store hours, and exit routes.
With these adjustments to the business problem and proto-persona, our outcome-to-impact mapping was updated with lagging and leading outcome paths.

Our solutions were adjusted, which meant we needed to look at our hypotheses next. We made 3 new hypothesis statements which introduced a trip planner feature, TSA wait time inclusions, and pop-up screens for restaurants/ stores. We also crossed out three previous statements that were deemed unnecessary and redundant. After reordering our statements on the hypotheses' prioritizations and updating the subsequent risk and MVP tables, we updated the product backlog and made a Sprint 2 backlog.

Sprint 2 / Weeks 1 & 2

This was the final phase of our project. Our tasks were to refine screens, finalize user flows, and make final adjustments to our features.

We began with the same approach: continuously learning from our user research interviews and designing in iterations. The main difference with this workflow was that we now had solidified the backlogs and styles usage. This allowed our work in Figma to have more consistency and integration between MVPs - which were now becoming “rough screens” for the final prototype. The design plans also became more defined and narrow in scope, making our iterations improve upon the interactions rather than visual designs.

Sprint 2 Retrospective

As this was our last sprint, this retrospective served to encapsulate our reflections on Sprint 2 and also set us up for our remaining tasks during refinement. We all put out similar statements regarding consistent team collaboration and continuous learning, as well as the need to finish connections across features. We also decided that our “visual waypoints” screens would be more conducive of an AR experience if the frames contained a video background.

After finalizing the state of the maps feature, I went over every interaction to ensure that the transitions were smooth and every interaction was correctly placed. This left me with the task of making a connection from the route creation’s final interaction to the visual waypoints screen. An issue arose with this, as component variant interactions cannot cross outside its component set unless they connect to a screen on the same page. To avoid having a whole component set in our “finalized paths” page, I edited the “Kiwi Maps Interface” to have screen backgrounds and included a copy of the visual waypoints. This meant that the final prototype only needed one screen that held the “Kiwi Maps Interface” and encompassed the whole user journey. I also combined the final visual waypoints screens into “Kiwi Maps Interface”, making it a variant itself, as this was the only screen that needed to be navigated to after accessing the maps.

Final Thoughts

Final Prototype

We created a high-fidelity prototype that we were all proud of. I enjoyed working with my teammates and being a member of something that was unknown territory. It was challenging and intensive, yet fun and extremely rewarding. The final state of the “Kiwi Maps interface” still had room for improvement with fully allowing manual interaction regardless of the user flow, but with our given window of time, we made the best effort to capture that experience for our users and provided something that people can use to look forward to the capabilities of AR applications in the near future.