CRM Redesign — Yi Ren

CRM Record Pages Redesign

Users locate and edit all information related to a record in the CRM on these pages

Background

Bullhorn is the leading ATS (Application Tracking System) and CRM (Customer Relationship Management) software for staffing agencies.

Problem

The old visual style was dated, which was a problem that needed to be addressed with Bullhorn going up-market. The information architecture and layout of the record pages also needed to be updated to make it easy to scale with customizations and integrations.

My Role

As the lead designer for this record portion of the redesign, I:

Compiled user feedback related to record overview from various channels,
Analyzed the user needs and business needs,
Collaborated with other members on the design team to brainstorm and produce consistent design with other portions of the redesign,
Sought feedback internally and externally, and iterated the design,
Built a design system with the rest of the team.

Design Challenges

Highly Customizable and Responsive First View

Problem

There could be up to 100 fields on an given record. Users want to see the most relevant information right away without searching and scrolling. What’s most relevant differs greatly across businesses and users inside each business.

In addition to information in the CRM, larger customers pull in information externally through integration. The design needs to be flexible enough to fit that into the layout without causing being too inconsistent.

Solution

I ended up using cards to address these problems. During the setup process, companies can group pieces of information and section them off into different cards to create a default layout. On the user level, they are able to add and remove cards, and move them around to prioritize what’s most important to them.

Because cards create visual division between each section, it makes it easier to fit in external information and design elements without creating chaos.

Associated Records

For some user scenarios, users need to locate and read one or multiple records related to a parent records. For example:

An account manager needs to find the billing contact’s phone number at a particular company to discuss a billing problem.
A account manager who just took over an account needs to read recent notes about this company to understand the relationship, and then see who the hiring managers are so she can introduce herself.

Problem

The original design takes the user to new pages without the context of the parent record. I wanted to avoid this context switching as much as I could. The UI needs to fit in multiple lists and provide detailed views of a record that users locate and allow them to toggle through.

Solution

I'd just started using Inbox by Gmail at that time and I loved the interaction of opening a thread. You click on a thread and it opens in place and pushes other threads out of view. When you’re done, it collapses and allows other threads come back into view.

I borrowed that pattern, and replaced email subject with record type and email body with a data table. Each row has a quick view button, which triggers a drawer that slides in from offscreen where you can toggle through one type of record through previous and next buttons.

Editing

Problem

In the original UI, view mode and edit mode are completely different pages. The problem is that users sometimes find an incorrect field value while in view mode and when they switch to edit mode, they need to find that field all over again.