Due to a Non-Disclosure Agreement, information on this project is limited.

Navigating Salesforce Flow Builder's Resource Menu

Overview


Flow Builder is a powerful low-code tool that enables users to automate business processes by creating customizable flows. Users can design visual workflows with drag-and-drop elements to automate tasks, guide user interactions, and integrate with Salesforce data — all without writing code (see Case Study #1).

Flow Builder's Resource Menu displays the resources that are available in the flow. Within a broader initiative aimed at an improved resource selection experience, this specific project sought to guarantee keyboard accessibility for the redesigned menu.

The modifications were implemented in Java, Typescript, HTML, and CSS.


The Problem


The original Resource Menu (v1) needed a design overhaul.

The following are the core problems this product aims to solve:

old resource

v1 Design

This is where the revamped Resource Menu (v2) came in. This new design, provided by the UX team, was intended to prioritize customer needs, and improve usability and user productivity.

new resource

v2 Design

Initially, when I was tasked with integrating keyboard navigation for the resource menu, it was clear that the aim was to preserve the keyboard navigation experience akin to v1 for consistency. Yet, the interface of v1 differed from that of v2.

v1 didn't showcase a header or footer, nor did it have a distinct nested menu structure like v2. To ensure keyboard navigation was not only compliant with accessibility standards but also tailored to typical Flow Builder user interactions, every nuanced aspect of keyboard navigation had to be collaboratively addressed by the UX team, Product Managers, and Engineers.

WHEN WAS THIS?

Aug - Sep 2022 (1 month)


WHAT DID I DO?

As the team's Accessibility Champion, I devoted much of my efforts to enhancing accessibility standards across all products under our purview and identifying any that were lacking.

My responsibilities include:

  • Research & Design Strategy — Conducted accessibility research, studied human-centered design principles, and documented comprehensive requirements for keyboard navigation in the Salesforce ecosystem.
  • UI Architecture & Development — Engineered reusable UI components with ARIA attributes and designed intuitive keyboard navigation patterns, ensuring both visual appeal and accessibility compliance.
  • Technical Leadership — Identified and resolved technical challenges, led implementation efforts, and established quality assurance processes through detailed test plans and bug blitzes.
  • Cross-functional Collaboration — Partnered with UX teams, Product Managers, and engineers to refine design decisions and ensure seamless integration of accessibility features with existing workflows.
  • Product Advocacy & Documentation — Presented findings and final product to stakeholders, created documentation for accessibility standards, and championed inclusive design practices across the organization.

During this process, I worked in tandem with the UX team, Product Managers, and my engineering team to ideate and troubleshoot.

The Process


When I was first assigned the task to implement comprehensive keyboard navigation for the redesigned resource menu, I began researching web accessibility guidelines for menus. Specifically, I was recommended to refer to World Wide Web Consortium (W3C) for standards and guidelines I could use to apply to our redesigned resource menu.


Subsequently, I began documenting my findings and categorizing them into four common scenarios where the focus would land after certain keyboard navigation.

Common Focus Points

1. The Input Field

Initial focus point when users first interact with the resource menu.

2. A Menu Item

Focus lands here when navigating through available resources.

3. The Footer

Focus moves here when tabbing through the menu structure.

4. The Close Button

Final focus point when exiting the menu through:

  • Clicking outside
  • Pressing Esc
  • Selecting the X button

Delving Into Keyboard Navigation


With the help of the UX team, I documented and presented my findings using this diagram.

overall navigation

The pink numbered lines represent the tabbing order and the pink dotted arrows represent up/down/left/right arrow key interactions.


Let's see how I used this diagram to detail the four common focus scenarios.


Focus Point 1

The Input Field

When the user focuses into the text input field for the first time:

  • Dropdown menu should immediately display.
  • Secondary focus should be on the first menu item (in the diagram, that would be Users from Get Account Owners).
  • Using Enter will select the first menu item.
  • Using Tab will bring the focus into the menu (demonstrated with the 01 pink numbered line).
    • Using ↓ will trap tabbing within the menu.
  • Typing any alphanumeric character will filter the menu items.
tabbing order 1

Focus Point 2

A Menu Item

When the focus is on a menu item:

  • Using ↑ or ↓ keys, a user can navigate the menu items, excluding the header and footer (demonstrated with the up/down pink dotted lines).
  • Using Tab will move the focus straight to the footer (i.e.: New Resource) (demonstrated with the 02 pink numbered line).
  • Using → or Enter towards a chevron will traverse, display and focus the next level's menu item.
  • Menu items with tooltips will have aria-describedby pointing to tooltip contents to support screen readers.
  • Using Cmd + I (Mac) or Ctrl + I (Windows) will display the tooltip.
tabbing order 2

Focus Point 3

The Footer

When the focus is on the footer:

  • Using Shift + Tab will move the focus back to the last-focused menu item.
  • Using Tab will focus the header (i.e.: All Resources) (demonstrated with the 03 pink numbered line).
  • Typing any alphanumeric character will filter the menu items.
tabbing order 3

Focus Point 4

The Close Button

To leave the resource menu, the user can click outside the menu, use the Esc key or click the X button. When this happens:

  • This will close the combo box, but the focus will remain on the input field.
  • Using Tab will move to the next element in the field.
  • Using ↓ or Enter on the input field will show the dropdown menu again.
  • Typing any alphanumeric character will filter the menu items.

Balancing User Familiarity with Accessibility Standards


The Design Challenge

The introduction of a header and footer in v2 created a critical design decision for keyboard navigation - we had to choose between two competing design principles:

User Familiarity

Maintain v1 behavior by focusing on menu items first.

Benefits
  • Preserves existing user muscle memory
  • Minimizes learning curve
  • Maintains consistency with previous version
VS

Accessibility Standards

Prioritize 2.1 global keyboard accessibility standards by focusing on the 'New Resource' option.

Benefits
  • Ensures compliance with accessibility guidelines
  • Improves experience for keyboard-only users
  • Future-proofs the interface

Understanding User Needs

Recognizing that Flow Builder is a point-and-click automation tool, we understood that users with low vision or difficulty using the mouse would face significant challenges without proper keyboard alternatives.

Our Approach

We implemented the 'New Resource' focus path to uphold 2.1 global keyboard accessibility standards, with help popups to guide users through the new navigation. This decision reinforced our core belief that a truly enhanced user experience must be equally accessible and intuitive for all users, regardless of their interaction preferences or abilities.

Key Features

The revamped selection experience not only met but exceeded our customer's expectations. We introduced a redesigned resource menu that significantly improved user experience and underscored the importance of accessibility as part of the Salesforce Winter 2024 release.


Overview of easier Flow resource selection experience showing friendlier names, improved grouping, helpful tooltips, and clickable breadcrumbs

Friendlier Names

Easily find flow resources by label vs technical API name (e.g., Triggering Account vs $record).

Improved Grouping

Find outputs under the elements they were created in, making resource discovery more intuitive.

New Helpful Tooltip

Hover any row to see description, API Name, and Data or Element Type for better context.

New Clickable Breadcrumbs

See helpful context on the hierarchical data structure and effortlessly navigate the path.

User Feedback & Praise

User reviews and feedback

Insights & Takeaways

Seeing users embrace the redesigned interface reinforced a crucial lesson: accessibility and user experience are not mutually exclusive goals.


This project taught me three key lessons about product evolution:

  • Accessibility is a foundation, not an afterthought. By integrating keyboard navigation from the start, we created a more inclusive experience without compromising usability.
  • User experience can evolve successfully when supported by clear guidance and contextual help, even when introducing significant changes to familiar workflows.
  • Cross-functional collaboration is essential. The success of this project stemmed from the close partnership between UX, engineering, and product teams.

See Next

Whole Foods Project

Whole Foods In-Store Checkout Experience

A UX case study on streamlining access to the Whole Foods in-store checkout code within the Amazon app for a faster, frustration-free experience.
Salesforce Canvas Enhancements

Redesigning Salesforce's Flow Builder

A case study on improving accessibility and user productivity for sight-impaired users in the Salesforce Flow Builder.
Lume Project

Lume

A UX case study exploring how to help independent designers increase their market visibility through an intuitive mobile platform.