top of page
LOGO design
LOGO design
Frankie
kastenbaum
Frankie
kastenbaum
Frankie
kastenbaum
FRANKIE
KASTENBAUM
FRANKIE
KASTENBAUM
FRANKIE
KASTENBAUM
Frankie
United airlines handoff process
United Airlines is a major airline in the United States.
As a way to streamline our handoff processes among all the different projects, I was tasked with creating a way that would create a more efficient processes that works for all three disciplines (UX, Development and Business).
Technologies
Microsoft Teams
Figma
Duration
2 Months
Team
Business Analysts
Developers
UX Designer
role
UX Strategist, focused on understanding the pain points and needs of UX Designers, Business partners, and Developer partners in relation to a handoff.
Research
01 research
Tracing the problem's beginnings
I noticed that the different designers on my project all had varying file structures. For a team where several individuals are on multiple pods, having discrepancies was more confusing than anything to our product partners.
I realized that streamlining the way our files were laid out, would help our partners better understand what to expect from us. As well as, have an easier time moving between the different files and pods.
Handoff is not just for UX
As mentioned, a handoff process involves multiple parties. In order to make sure I accounted for everyone's needs I spent time having conversations with Business Analysts, Technology Leads, Developers, and of course other Designers.
The goal of these conversations were to learn about their frustrations with the current process as well as to see if any additional pieces were missing.
5 Business Analysts
4 Developers
10 Designers
What our partners told us
From the Business side, we learned two main insights.
The first was that they needed to see a full flow, to gain a better overall picture. The second, was they lacked confidence in Figma so interacting with it lead to preset frustrations.
From the Development side, we learned also three main insights.
Number one was that they wanted to understand all the interactions that would affect the work, understanding this new work affects other areas in the app. Number two was that they did not need to see flat screens and annotations. What was helpful to them was just the annotations; it felt repetitive to do both. And the third was that it could help to know which components were pulled directly from the design system compared to which were custom.
*MAKE THIS MORE VISUAL -- MAYBE CHAT BUBBLES LIKE FILTEROFF
02 DEFINE
Empowering Our Partners
I tried to find a solution for how to solve this problem and leaned into a Figma template.
This way it was in the same place as our wireframes, so that our partners would only have to learn one software.
However, after a lot of thought and feedback from our interviews, I decided to create the template as the overall file for the entire block of work, not just at the end for Handoff.
The reason being is for a few reasons.
1 It removed confusion of which file had the most up to date screen. It also alleviated any of our partners concerns with finding files.
2 It created less work on the Designers so that they did not have to keep moving screens between the files.
Current Solution
03 DESIGN
What this looked like
The first step in creating the template, was to create the page structure.
Two main insights affected the layout.
1 Since this file would be better appreciated as the final source of truth for a single block of work based on partner feedback, I had to find a way to separate in progress and final work.
2 I wanted to make sure the file did not feel repetitive, directly relating back to feedback from our Developer partners.
To do this, I spent time in very low fidelity with post-its and pen trying to group the pages together. I separated out UX from Business and Development sections.
V1 structure
The goal of this structure was to help our partners understand more quickly which pages they were meant to be in.
Design
Not only did I focus on the hierarchy and structure of the pages, but also the individual pages themselves. Based on what I knew from our partners, I focused on ways to highlight the overall flows of the blocks of work and to make it more explicit as to where to explore for what was needed.
To do this let's start with the Specs page.
Solution
This layout was intended to solve many of our partners pain points. Its goal was to account for all screens in a flow; horizontally per one device type and vertically for all the others. This way all the flat screens could be inspected by our developers and used to help our business partners understand how the flow would show.
V1 Specs page
zoomed in section
A few other design call outs that are important are mentioned below and can be seen in the zoomed in image above.
As a way to help our non Figma savvy business partners, I created sections for each user story block of work. This way, it was clear what work would go where. As well as, it would provide an easier time when adding links to the user stories. This was because they now had one link that contained all the wireframes or specs for that one story in a single section. It increased their ease, since they no longer had to add multiple different ones due to limitations of InVision.
On a similar note, I added in a section for the Jira story link to be dropped in. This way, everything was circular. No matter if they were in Jira or Figma, they could easily access the other one, allowing Figma to work as a source of truth along with Jira.
The last important call out is I noticed PC users were having a hard time moving around the file. They found it quite difficult to pan around and always know where they were since the infinite canvas was a relatively new concept to them. Due to this realization in our early discussions, I wanted to alleviate that. I added in header banners at the top of the sections, ones that repeated in large letters, so that no matter where they were in the section, they would always know which flow they were on. They no longer had to stop, scroll all the way to the front of the section and find the small name tag. This way, it decreased their time and efforts it took to answer this question.
The Specs page was not the only page that accounted for our partners feedback. I continued to iterate on our existing style of Annotations.
v1 annotations page
This section was intended to provide notes on changes that occurred and about certain interactions on the flow. It was also meant to act as a deck to help our business partners for sneak peak calls.
zoomed in section
The main change to this page, was to include a differentiator marker to determine when a component was pulled directly from the Design System compared to a custom one. This change directly came from our developer's feedback since they wanted clear indication of the items that they needed to work on. It allowed them a quicker glance at the level of work that was at play for them.
This structure was put back in front of members from the three product disciplines. Those conversations were vital since they provided numerous insights for how to tweak the file.
what our partners taught us
Based on this helpful feedback, I realized I had a number of changes to make to the file.
how their insights left a mark
Their feedback led to 4 main sights and changes.
1 The confusion around the groups led to the section titles changing to For Everyone and For Design Only.
2 The lack of understanding of which screens were final and which were in progress led to new section titles, Final and In Progress.
3 The repetitive nature was removed by moving the Specs page under the In Progress section and renamed it Concept Designs.
4 The unknown of Figma that caused frustrations and fear of using it was solved for by creating a Welcome page that had a quick intro for how to use Figma.
To better understand how these changes looked, let's explore the new version of the file and it's pages.
how their mark affected the file
The insights discovered that were mentioned above lead to all the following changes within the layout and file structure.
v2 structure
This updated structure, increased clarity, removed clutter, and overall provided more confidence when inside the product from our product development partners.
BREAK OUT ALL THE DIFFERENT PARTS OF THE FILE.
TALK ABOUT:
- ANNOTATIONS VS SPECS
- FINAL VS IN PROGRESS
- TALK ABOUT THE USER NEEDS AND HOW THEY ACCOUNTED FOR THE DESIGNS
- FIGMA GUIDEBOOK TO HELP EASE OF USING FIGMA
Once again, we can dive deeper into the file page layouts to truly understand how the insights affected the design.
My goal was still to create clarity for the different pages in the file. Yet, this time around, I had learned that our partners did not want multiple files per a block of work. Instead, they preferred to have one file that would work as the source of truth for all the work corresponding to that flow, in progress and final work alike.
Due to this new insight, it lead to a reorganization of the file pages. Moving Annotations and Final Prototypes to the Final section and Concept Designs and UT Prototypes to the In Progress section.
This last change also occurred due to the lack of interest in having both final Specs and Annotation pages. Both disciplines, Business and Development, felt that was redundant and unnecessary. Due to that, it lead to slight tweaks in the Annotations and Specs pages.
v2 annotations page
The Annotations page became the final handoff item, the one that provided the specs for the Developers but also provided notes and history for everyone who needed them.
There were two main changes that occurred.
The first, the navigation bar on the top right corner of all the slides were removed. I had thought this would help our partners interact with the slides in an easier manner, one that represented PowerPoint, a common tool for them. Yet what I learned, was that this step became more work than help for anyone. It took much longer for the Designers to set it up than to have the flat screens. This would have been worth it, but our partners were not utilizing this feature. So because of that I decided to take that one piece out. This way, it also connected with our partners feedback of keeping everything in the file super clean and not redundant.
I also removed the Sprint # from any of the header pages. Although we work in sprint cycles, too often teams were reverting back to old work to update it in future sprints. When this happened, it then became confusing for tracking purposes, which sprint that block of work was related to. Due to this, it was decided to focus on keeping everything circular to Jira, rather than by sprint numbers.
v2 Concept Design page
The overall layout of this page remained the same. Yet, what changed was its location and reason for being interacted with.
Since this screen was now in the In Progress section, its focus was to be the home of the design conversations between UX and Business.
​
Those conversations will take place, both on meeting review calls and also in the comments section on the tool (the colored initials on the image).
The last big change that was made involved helping out partners feel more comfortable with Figma overall.
PDF guidebook page
​Not only did I create a Welcome page with quick instructions on where to go, I also created a guidebook (one for each discipline) and Figma 101 Training courses that I ran internally.
Both of these were intended to be a helping hand to those who were brand new to Figma. They provided insights into the different functionalities they had available and how they would each help them. ​I saw during those sessions a lot of relief and removal of fear for working with us in our handoff process.
The updates where then placed back in front of our users again to confirm we they were headed in the right direction. There was no major edits or comments so this final iteration version was what was used to roll out to the entire team to use.
feedback from the wild
We are still in the roll out process, but a couple teams have begun to adopt this new structure and process.
From the first team, one of the Designers highlighted a number of the postive changes she has noticed since the switch.
The second team, one of their Business Analysts spoke up and provided us insights into how it has positively affected her workflow.
Although this is just feedback from two of the many product teams at United, it still proves we are moving in the right direction.
06 Reflect
Retrospective
Working on this project gave me a greater appreciation and understanding of the operations side of Design. It provided me insights into the world of Design Ops and has sparked an interest in learning more as a way to provide more consistency and better efficiency among teams.
If I were to start this project now, I would have tackled the other smaller handoff parts of the sprint as well within this file. These smaller less talked about handoffs are those between Business and Design, and Research and Design. Although I would have started earlier on those in another life, they are both focus areas I have already started implementing for with various checklist and template guidebooks as resources.
bottom of page