Elaiza Celemen | Feedback System: Toast Redesign

Overview

Indeed is the #1 job site in the world with over 250 million unique visitors every month. Indeed strives to put job seekers first, giving them free access to search for jobs, post resumes, and research companies. Every day, we connect millions of people to new opportunities.

I am 1 out of 6 designer on the Design System Team on Indeed based out of San Francisco. We serve 6 product business vertical that contains roughly 33 product teams. Currently, my team is working on redesigning and identify missing components on Indeed’s Components & Pattern library in efforts to complete and refine our current design language, Janus. This will allow product teams to efficiently compose consistent UIs across all Indeed product surfaces.

Within this effort, I lead the redesign of the ‘Toast’ component within Feedback System.

Role

UX Designer

Duration

May 2019 - December 2019

team

UX Research: Karen K.
Product Manager: Molly S.
UX Designer: Cadenza W.
Design Technologist: Casey H.
Copy writer: Kirsten F.

Discovering challenges

We conducted a research study to gain insight into the current landscape surrounding Indeed’s Design System. The research team interviewed 6 Product Designers from our two primary product verticals.

From this study, we discovered current challenges that our users are facing:

Lack of design guidance

Designers want more guidance on how to use individual components and how to stay aligned to the Indeed brand when they must create something that doesn’t exist.

Lacking components

Designers must create their own solutions while waiting for design system to grow to meet their needs, and are frustrated by the lack of consistency and guidance they find when they search for answers, and end up making their best guess for their needs.

Lack of examples

Designers would like clear examples of how to use foundations, like color and type.

Opportunity

Discovering our users current challenges with the current system, we recognized that before we encourage adoption of the system throughout the whole organization, our team need to refine foundational elements and existing components with clear definition and rich usage guidelines for each one. On top of that, we need to identify any missing key components that are being used in our primary product verticals to “complete” our current design system.

Goals

Foundation & Principles

Standardize the system’s visual properties and their guidelines.

Components & Design Patterns

Standardize compostable, accessible components (atoms, not organisms, design organism patterns, guidelines, and page templates).

Success metrics

Qualitative

· Designer feels that the updated documentation is much more detailed and creates clarity on usage and pattern.

· Designers don't have the need to create their own component because the system has the components they need.

Quantitative

User

· Decrease time spent producing features.

· Decrease time spent on information seeking for specific product need.

Business

· Increase adoption of the Design System

· Increase trust from our users.

· Increase consistency within product.

Milestones

Since this was going to be a very large initiative, we broken it up in different milestones. We are currently at ‘Design solutioning’ milestone.

Problem space

From our internal audit in Q2, one of the problems that we identified was our existing Feedback System:

How might we clarify how Indeed communicates information to users in relation to an action or status update, within a Feedback family?

Research

Current Feedback System

The current Feedback System consisted of 6 components ranging from low to high priority. The question that we asked ourselves was: does each component had a clear defintion and characteristics that delineates them from each other?

Internal Audit

To gain a better understanding of how these components differs from each other, I teamed up with another UX Designer to conducted an internal audit of product use cases of all 6 components on how they are being used currently.

1. Banner, Alert, Toast, & Inline messaging findings

· Product examples shows inline usage for confirmation status, informational, and product feature promotions that appears to be a banner or toast.

· However, we are finding a widespread implementation across existing with our banner (alert) and toast.

· Open question: Should we have an inline variations for banner and toast?

2. Tooltip findings

· The way we’ve used tooltip and callouts has been overlapping and does not match industry standards definition of a tooltip.

· Our tooltip has been used to explain sections with a ‘?’ or ‘!’ icon with long paragraphs.

· Industry standard definition of tooltip is very utilitarian.

3. Callouts findings

· Indeterminate usage across product.

· Callout seems like a hybrid of a tooltip and modal with all of the different elements that it has.

· Open question: Could Callout be a pattern?

Competitive Analysis

To extend our insight, we wanted to see what are the industry standards with the Feedback System components.

1. Banner

Material (Google)

Polaris (Shopify)

· Use for prominent message & related optional action

· Persistent. User can ignore or interact with at any time

· Types: only Default type (not found: Error, Warning, Success)

· Use for important changes or persistent conditions

· User can ignore or dismiss

· Types: many found, for messages ranging from critical through neutral and success (Default, Informational, Success, Warning, Critical)

2. Alert

· No ‘Alert’ component found

· Polaris ‘Toast’ is closest to our current Alert

Polaris (Shopify)

· No ‘Alert’ component found

· Material ‘Snackbar’ is closest equivalent to our Alert

Material (Google)

3. Toast

Material (Google)

Polaris (Shopify)

· No ‘Toast’ component found

· Material ‘Snackbar’ is closest equivalent to our Toast

· Use for important changes or persistent conditions

· User can ignore or dismiss

· Types: many found, for messages ranging from critical through neutral and success (Default, Informational, Success, Warning, Critical)

4. Tooltip & Callout

Material (Google)

Polaris (Shopify)

· Across Material and Polaris, tooltips should be used judiciously. Only when necessary to provide succinct supplemental explanation.

· Across both Material and Polaris, ‘Callout’ not found.

Key takeaways

Based on how we are currently defining the Feedback family through our own documentation and on product:

Internal

· ‘Banner’ (Alert) and ‘Toast’ used interchangeably.

· ‘Banner’ and ‘Toast’ currently placed inline in product.

· ‘Tooltip’ usage ranges from industry practice to non standard.

· ‘Callout’ appear to be a ‘Tooltip’ but has elements similar to modals. In product usage is indeterminate.

Industry

· Material offers 3 feedback components (Snackbar, Banner, Dialog)

· Polaris offers 2 feedback components (Toast, Banner)

Approach

Based of auditing internal usage, prosed subway map, industry examples, and levering atomic approach we concluded on a approach:

· Combine ‘Banner’ and ‘Alert’ into single Banner component.

- Question: should we unpack Banner further into ‘status (feedback)’ and ‘promotional (static)’ types?

- Should we consider renaming Banner to be more descriptive, and avoid potential confusion with marketing ‘banner’ ad?

· Remove ‘Popover’ as a subclass.

· Explore ‘Inline message’ as possible ‘Banner’ and ‘Toast’ usage.

· Add ‘Tooltip’ to Feedback family as lowest prominence.

Before

New Feedback System

Toast Redesign

Now that we have a new approach and definition for the Feedback System, I tackled the redesign of the Toast component.

Current component

Since ‘Toast’ and ‘Alert’ visually looked very similar, it was difficult to distinguish in which instance would we use ‘Alert’ vs. ‘Toast’.

· Definition: A toast notification is a non-disruptive, low-priority message, typically appearing in response to a user’s action.

· 4 types: success, informational, warning, & danger

· Since ‘Toast’ auto-dismiss, why would we put an urgent messaging that automatically disappears?

· All product usage for ‘Toast’ mostly show ‘Success’ and ‘Informational’. Never warning or danger messaging.

· Is a ‘Toast’ a success vs. confirmation?

Opportunity

We see an opportunity to really refine the definition and characteristic of ‘Toast’ to have clear delineation between components within the system and when to use what that will help guide our users to the best solution for their needs.

New definition

Toast is a self-dismissing message that appears elevated on the page to provide that status of a user's actions.

Displayed temporary and always dismissible by the user.

Toast only convey low-importance messages.

Design approach

🚫 Constraints

1. ‘Toast’ must be accessible (WCAG 2.1)

a. Color contrast ratio must be at-least 4.5:1 (AA) of the ‘Toast’ and page level (background) for colorblind or low-vision users.

Approach

· We defined ‘Toast’ to be a general confirmation of a task or action initiated by the user which resulted in eliminating status represented by color. Because we found use case of having a success of a negative action like deleting a job alert. To reduce confusion, we stuck with a neutral approach that neither be positive nor negative.

· By approaching ‘Toast’ as a neutral confirmation of action, types went from 4 to 1.

· Having the dark background allows ‘Toast’ to have a high contrast ration (passes AA & AAA level WCAG 2.1) with page-level layout which is mostly white interface defined by the Foundation & Principals.

- Drop-shadow is considered as a decorative element with accessibility.

· Decrease of content allow for clear and brief messaging.

Anatomy

1. Container

The container size depends on the text string length with 16px padding.

2. Text

The Text should display the action that the user took.

Text should be short and max 84 character count which is determined by the PD team.container size depends on the text string length with 16px padding.

3. Action (optional)

When a user has a ability to act upon the message, an action link can be provided.

5. Dismissible icon

Dismiss icon allows a user to excuse toast.

Types

Default

This is used to communicate general confirmation of a task or actions initiated by the user that are non-critical.

States

Button Link: White 48% opacity

Button Link: Underline + Indeed Blue + 88% white overlay + cursor change
Icon: + 8% black overlay + cursor change

Background: Black 900
Button Link: Indeed Blue + 80% white overlay
Icon: White

Button Link: #FFFFFF
Icon: #FFFFFF

Button Link: Indeed Blue + 88% white overlay

Variations

With action

Provide a action like when user has the ability to act upon the message

Interaction

Dismissing a toast

Clicking on action link

Hover state for CTA button link

Usage

General usage guidelines to help designers
implement Toast effectively.

Message should be short and a clear update on action taken.

Only provide an action like ‘Undo’ when it is relevant.

On wide interfaces like desktop or tablet, toast should only be on a single line of text.

Don’t

On mobile, don’t put long messaging that will wrap to more than 2 lines.

Caution

Be cautious when it comes to messaging because it will be reflected on mobile.

Don’t

On wide interfaces, don’t put a max-width that wrap content in the toast.

Behavior

Appearing and disappearing

Toast will appear on the screen and does not require user interaction. It can be dismissed by a user or will disappear from the screen from 5-10 seconds.

Consecutive toast

When a user take multiple action, each toast associated with each action will replace the current displayed toast to keep the relevance of the action to the user. Toast should not be stacked but appear one at a time.

Pattern & Breakpoint

Toast can be place either at the top or bottom of the interface closest to the related content its pertaining to. It is always elevated in front of the content.

Desktop & Tablet Placement: Top of the UI

On wide interfaces, toast appearing on the top will be placed 56px from the top of the viewport.

Desktop & Tablet Placement: Bottom of the UI

On wide interfaces, toast appearing on the bottom will be placed 40px from the top of the viewport.

Mobile Placement: Top of the UI

On mobile, toast appearing on the top will be placed 72px from the top of the viewport.

Mobile Placement: Bottom of the UI

On mobile, toast appearing on the bottom will be placed 40px from the top of the viewport.

Mobile: Message can wrap up to 2 lines if needed

On mobile, toast with long message will hit a max-width of 343px and content will wrap. The dismiss icon will be kept vertically centered-align on the container.

All breakpoint: Toast and fixed top or footer elements

Toast should appear directly above or below fixed top or footer elements with 16px spacing.

Feedback System:Toast Redesign

Tastemaker

Feedback System:
Toast Redesign