Trucy Phan Yello


Yello is an event management and CRM tool for campus and professional recruiting.

Role: Senior Product Designer (Feb. 2018 - Present)

I work on a team of 3 full stack product designers. We own the entire design lifecycle from user research (customer calls, onsite interviews, and usability testing) to visual design, prototyping, dev handoff, and QA.

Switching Yello’s product team to Figma

When I joined Yello, the designers and product teams were using Sketch files synced to Google Drive for designs, InVision for prototyping, and other tools and manual processes to keep everyone in sync. It worked, but there was a better solution.

Having used Figma for at least a year before this point, I knew it would be an amazing tool we could use for managing our component library, collaborating with PMs and engineers, and also each other.

My goal was to reduce friction between designers, PMs and engineers with Figma's commenting and live Jira embed features, reduce the time needed to go from design to prototype by eliminating the need to use InVision, and increase collaboration among designers by leveraging Figma's nature of being in the cloud and having multiplayer (more than one designer can work in the same file at the same time) and observation mode (you can click on someone's avatar to see what they're viewing/designing).

I mapped a few of Yello's high level design and process needs before and after the switch so you can see the benefits:


Version History
Manually naming files in Google Drive
Figma version history

Global Components
Sketch Symbols, Abstract
Figma Team Library


Design Feedback
InVision comments
Figma comments

Developer Handoff
Screenshots attached to Jira tickets, InVision, Sketch plugins
Sharing Figma links and Jira embeds

Non-Mac device support

Because the team was already deep into Sketch and InVision, to make it easier for others to explore the tool for new design work, I recreated the majority of the team’s existing Sketch components in Figma in my spare time. These included modals, toasts, flyouts, colors, buttons, tooltips, tables, navigation, icons, form elements, UI controls, tags, empty states, and typography.

The process for switching over took about 6 months for all 4 teams, and also involved creating workshops for PMs, engineers and designers to learn the tool through on-hands projects, and writing resources on Confluence.

I also sent a survey asking PMs, engineers, and designers for feedback on the tool. Some interesting learnings include: not as many engineers as I thought were leaving comments in files, designers wanted wireframe components, and the tool's role in improving collaboration was perceived differently across teams.

Based on actionable feedback from the survey, I designed and added wireframe components to our team library, held an engineer-tailored workshop, and created a #figma-questions channel on Slack because people had more questions than I thought they would in that workshop!

Although this wasn't straight up product design, it has been one of my most favorite accomplishments working at Yello.

Unifying Yello's UI

Inheriting a limited color palette that was inaccessible and lacking the range for various design needs, I set about creating a new color palette.

I began with a neutral base set, a primary accent set, as well as your standard warning, success, and error colors. Each color at level 700 was designed to address accessibility concerns and meet AA standards (in many cases, AAA was met).

Accessibile combinations

I designed the colors to work as text, backgrounds, buttons, hover states, border colors, and more. I thought in pairs and in sets, and aimed to make it accessible but still expressive. Here are a few examples of components with my color system applied.

A set of core UI components

Event Management (WIP)

Note: this case study is currently being written (as I'm still working on it!).


In order to meet and encourage candidates to apply to jobs, recruiters often attend professional and university events. These include career fairs, information sessions, and virtual events.

Before an event begins, a recruiting team often has to consider registering for the event, inviting candidates to pre-register for the event, and inviting staff members to RSVP if they can attend.

Preceeding all of this, however, is the event creation itself in Yello.

Although it mostly worked, initial feedback from users and customer support on event creation was that it had too many steps, was confusing, and was ugly.


Before I worked on the information architecture of event creation, our team conducted a meeting with engineering, product, customer support, and design stakeholders and went through each of the 7 steps required to create an event in Yello.

Everyone was given post-it notes to write down questions, opinions, concerns, and any other feedback. I used Airtable to organize 143 pieces of feedback by location (which step, or if it was global, or if it was missing) and category (e.g. information architecture, copy improvements, ui and visual design).

In addition to internal feedback, I held user interviews to talk to clients about event management. Through those chats, I understood the different types of roles who create and view events, learned what event information and metrics are important and valuable for recruiters, and heard various pain points about the creation and management process.

For example, the following user flow below (please click to open in a new tab, as it's super wide!) shows how long and confusing it was: dozens of fields spread across 7 tabs, UI elements that only appeared once you selected a checkbox or radio button, and information that users just didn't need. Also, since there was no save as draft feature, users often lost their information if they closed the tab, or accidentally went "back" in their browser.

Event Creation Flow (Old)

Simplification of Information Architecture

Using updated form elements I designed and adding sections to create breathing room, I stripped down event creation from 7 steps to one.

However, that meant that a lot of information that was previously available to a user in event creation needed a new home, which meant event pages needed an information re-architecture as well.

I started by creating a "Settings" tab, which previously didn't exist on Event pages.

Event Creation Old vs. New Information Architecture

Event Settings

Still writing this case study... to be continued with more about process, screenshots, and prototypes :)