Navan

Overview

Context Outcome

_______________

Process

Patterns Interaction Handoff

Creating a bulk action on selected transactions

Context

Managing transactions as an admin user is repetitive

When an employee spends over their allowed limit using their company card, the assigned admin approver reviews the transaction and can allow, reject, or request for more information. These transactions can also be managed by admin users to change the assigned approver, transaction category, designated cost center, etc.

Essentially, an admin user can edit properties of a transaction such as its status and fields.

Admin users execute the same action on transactions repetitively. Dealing with this extensive number of tasks leads to an exhausting interaction.

This initial bulk action design allowed users basic functionality to approve, reject, request info, or update GL code.

problem

Limited functionality

Initial design only covered basic actions to handle transactions.

Additional actions commonly made in individual transactions are not able to be done in bulk, such as switching approvers or editing the details.

Inconsistent meaning

Current snackbar component meaning conflicts with its meaning in the rest of the product.

In the rest of the product, the snackbar pops up to save and discard while editing. Using the snackbar to initiate a bulk action confuses the pattern's meaning and use cases.

Distance

Buttons needed to take action are across the page from each other.

After selecting the transactions using the checkboxes on the top left side, the actions to cancel and create a bulk action are on the bottom right across the page.

outcome

Creating bulk actions to edit transactions

The final designs included the bulk action embedded buttons as well as flows for additional bulk actions, switch approver, and update fields.

Patterns

Weighing between design patterns

I weighed my options for the general direction based on user experience, design system, and technical feasibility.

Considering UX

When selecting a group of items to create a bulk action, there are two main patterns: a floating snackbar or embedded buttons.

Floating Snackbar

The snackbar pattern is a bar at the bottom of the page that floats above the list.

Although this bar is easily noticeable by the user, the item selection is across the screen from the cancel and bulk action buttons that are needed next. In addition, the bar partially blocks the view of the bottom of the list.

Embedded buttons

On the other hand, the embedded buttons pattern is group of buttons at the top of the list next to the Select All checkbox.

It utilizes space that is already there before selecting items, and its proximity groups actions to select the items and choose the bulk action together.

See more: Working with the design system & Technical feasibility

Working with the design system

floating snackbar

In the product, it has already been an established common pattern for admin users to see the floating snackbar when making edits and unsaved changes.

This same snackbar component is being used to initiate a bulk action. These buttons lead to the various paths of bulk action creation in pop-up confirmation modals.

snackbar: while editing

snackbar: creating bulk action

While the editing snackbar allows the user to finish their task in making changes, the bulk action snackbar pushes the user to start creating a bulk action. These are contrasting meanings for the floating snackbar pattern.

Therefore, using the snackbar for bulk action creation would conflict with its meaning users are accustomed to.

Embedded buttons

Although the pattern of using embedded buttons above a list are new to this product, this pattern is likely familiar to users from outside workflows. For example in Gmail, multiple emails can be selected to start bulk actions such as archiving or deleting.

Gmail: selecting multiple emails

Since this is already an established user interface design pattern, users can more easily adjust to using the embedded buttons for bulk action creation.

Technical feasibility

After determining that the embedded button pattern would be beneficial to the user experience and design system, I worked closely with engineering and product to hear how these potential changes would impact development.

Because the snackbar component was already implemented in the product, I wanted to understand the technical feasibility of implementing an embedded buttons component instead.

floating snackbar

In the current product, communication between the snackbar and selected list is adding complexity for development.
Also, wherever a list of transactions are made, the snackbar is an additional component that needs to be added.

Embedded buttons

Embedding the buttons above the list of items allows for the bulk action buttons to be a property within the list component instead.
This allows for less needed complexity and communication between the list and bulk action buttons. In addition, whenever a list is created in the product in the future, bulk action buttons will be simpler to add in.

In short, the embedded buttons are actually more ideal for development long term.

interaction

Tweaking interactions to improve usability

After determining the general direction, I iterated on how the user would see and interact with the design pattern.

1 / Selection

The user should be able to go between all selected, partial selected, and unselected easily.

Addressing the user problem in having a long distance between selection, bulk action buttons, and cancel, these features are now in close proximity.

2 / Scrolling

As the user scrolls down to view transactions, the bulk actions bar becomes sticky to the top to stay in view. This allows the user to view all of the transactions until the bottom and then choose a bulk action.

3 / Weight and color

I iterated on the color treatments and order of the bulk action buttons.

After getting feedback during a design team critique, I landed on my final design, #5, based on what admin are accustomed to when managing individual transactions.

Handoff

Final thoughts

Since this feature was released after my internship, user feedback was limited to internal users. However, I sought out multiple rounds of feedback from design, product and engineering who knew the admin users well.

Next steps

The screens above were handed off for the bulk action redesign. Next steps would be to see how users adjust to a new design pattern and to iterate further based on testing.

With this redesign, I want to also consider using this bulk action pattern in more lists across the product and increasing the scale of which individual actions on transactions can be done in bulk.

Learnings

When pushing for a redesign, I was nervous about engineering pushback. If there was already an implementation in place, would a redesign be prioritized?

However, meeting with engineering (thank you Justin!) surprised me. I found out that the redesign reduced complexity and was beneficial to development long term. In addition, working closely with product and engineering helped me learn how to justify designs and push for good UX.

& More

This is just one of the projects I worked on!
Here is a high level presentation of all the major projects I worked on during my internship.