← Trucy Phan Yello

Yello

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

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. (Feb. 2018 - May 2019)

Design Ops

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 had a robust way of managing components and creating prototypes, and believed that it would be relatively easy to switch a small team over to.

Goals

At the time, these were a few of Yello's high-level design and process needs and how they were met before and after the switch.

Need
Before
After

Version History
Manually naming files in Google Drive
Figma version history

Global Components
Sketch Symbols, Abstract
Figma Team Library

Prototyping
InVision
Figma

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
None
Figma

Process

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. These included modals, toasts, flyouts, colors, buttons, tooltips, tables, navigation, icons, form elements, UI controls, tags, empty states, and typography.

I also added thumbnail status preview cards that made it a little easier to find files and communicate status (but is still a WIP).

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.

Learnings

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 where everyone could continue to learn asynchronously, and from each other.


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

Design SystemsVisual Design

Unifying Yello's UI

Inheriting a limited color palette that was inaccessible and lacking the range for various design needs, I took an opportunity to work on creating a new color palette.

Problems:

Yello's old color system

Yello's old color system failed most accessibility contrast ratios

Process

Goals

Yello's new color system

Learnings

Accessibility

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. Every 900/800/700 level of each color is designed to be AA accessible on four different backgrounds: White, Base 000, Base 100, and Base 200.

Designer Usage

To achieve the goal of having designers consistently apply colors as intended, I added descriptions to each style in Figma that shows up on hover.

I also wrote a usage guide for each hue, and included an example from our library file below.

Color Usage Guide

Here are a few examples of components with my color system applied.

A set of core UI components

User Research Product Design

Event Management (WIP)

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

Background

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.

Research

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 :)