Commondrop Multi-purpose Component
Commondrop Multi-purpose Component

Commondrop Multi-purpose Component

Client
Veeva Systems Inc.
Project title
Commondrop Multi-purpose Component
Disciplines
UIUX
image

Veeva Network is a CRM web application where the input of data is paramount. Many of the pages are designed to optimize the efficiency of data input, validation, and submission. Throughout the platform's lifetime, input components such as the select dropdown were built as needed without a unified system.

My role in this project is to design, develop, and deploy a universal select component for Veeva Network.

Discovery

Initial Assessment

A quick assessment of the platform (and by spending most of the time coding in it) revealed that inconsistencies have run rampant for our input components. Our approach to implementation have always swayed towards optimizing for speed rather than reusability. As such, multiple components have always been developed in parallel to meet the use case of an upcoming feature, rather than to consolidate functionality into existing solutions.

One of the most common used component that suffered from unrestraint development is the select dropdown component. While deceptively simple in nature, it needed to fill the needs of many use cases across different features. To get a sense of the variance that was on the platform, I conducted a broad search of all the <select> elements that occurred in our code base. From there, I was able to categorize and identify all the custom use cases through an extensive site audit.

Finding variations of the <select> dropdown element
Finding variations of the <select> dropdown element

At the conclusion of the audit, I was surprised at the number of variants that seemingly accomplished the goal, but utilized wildly different presentational layout. I knew I had to understand the features their use cases to make better assumptions about these variants.

Examples of the same use case utilizing 3 different variants.
Examples of the same use case utilizing 3 different variants.

Evaluating Existing Solution

I concluded that the variants all had reasons as to it's inception. None of the variants were created without being aware of already implemented components (or the pains of using someone else's code), but rather they were created to augment an existing variant. Knowing this, I looked at all the components holistically and categorized their functionality by identifying similarities and gaps in their feature set.

Variant features were identified during the site audit and categorized among these 4 types of select inputs. This table represents the variety of features in use on the platform, not what the component supports.
Variant features were identified during the site audit and categorized among these 4 types of select inputs. This table represents the variety of features in use on the platform, not what the component supports.

Evaluating Existing Solution

I also wanted to understand the pain points for our existing users. Unfortunately, since our users are data stewards dispersed in different companies, it was challenging for me (primarily in the developer role) to reach out to these users. Instead, I was able to obtain user feedback from PMs that were responsible for formulating the features in the first place. The following insights were collected:

Identified Pain Points

image

1. Users were making selection errors Using the tag style input was difficult, it was hard for the users to identify selected options due to it's unaligned organization

image

2. Users were not finding options in extended lists When lists of options exceeded beyond 50 items, the lack of search capabilities prevented users from finding what they want without having to scroll through the entire list

image

3. Users generally wanted to select multiple options at once In certain use cases, the options selected are pre-chosen off platform, but when it comes to selecting them, users were bound to clicking on the option one at a time

image

4. Users often face slow downs and crashed due to large list of options stalling the page Lists exceeding 200 options were causing performance issues, effectively rendering the page unresponsive when opening the dropdown

Defining Opportunities & Features

Learning from the insights, the heuristics that I focused on were efficiency and adaptability. It became very clear that the input's efficiency and ease-of-use were the driving forces behind the user adaptation and acceptance of the new component. Furthermore, it's unrealistic to assume that a single component could encapsulate all possible use cases now and in the future.

Therefore I identified a set of opportunities as the basis of the component.

Opportunities

image

Users were making selection errors → Improve readability

  • Adaptive presentation style of selected options based on the size of the list
  • Add selected option counts
image

Users were not finding options in extended lists → Improve discoverability

  • Implement searching for the entire dataset (both front end and back end)
image

Users generally want to select multiple options at once → Improve efficiency

  • Provide shortcuts to select multiple category of options
  • Select based on uploaded list of values
image

Users often face slow downs and crashed due to large list of options → Improve performance

  • Implement lazy loading for large lists

Ideation

Base Layout & Features

By now, I had enough ideas and insights to ideate some features. I started with creating a layout that could integrate all of the features without cluttering up the interface.

Module Adaptive Layout

The goal was to create an adaptive layout that encapsulates many of the functionalities without overwhelming the user. Many of the layout components are designed to be dynamically resized to fit the complexity of the use case.

image

Single & Multi style / Tag & Count display style

I noticed that in many instances, the input area did not take account the number or text length of the selected options, resulting in some inputs displaying one option's label, when in fact there are dozens of selected options. My idea is to dynamically adjust the presentation style depending on the space available in the input.

image

Search

The search functionality was conceived initially as a simple way for users to filter thorough options using fuzzy matching. But for many of our advanced users, their task involves fast selection and deselection of the options.

To accommodate for an entirely keyboard based experience, I expanded the functionality of the search input by incorporating slash commands that mirror most of the functionality in the dropdown

image

Additional Features

Modifiers (Global / Option / Group)

Inspired by filters on traditional list based UIs, I explored different ways to incorporate similar interactions within the dropdown. I eventually settled on a solution that allows the developer to define common selection groups. This reduces the repetitive nature of selecting multiple options, and opens up to user-defined categories in the future.

image

Lazy Loading

One of the biggest technical limitation of the current component is how it handles a large set of options. The goal of lazy loading is to defer options made available for selection until the user scrolls to it. As such, it's imperative that the count is shown to the user so they are aware of the size of the entire list.

In my consideration, lazy loading should only be implemented as an optimization feature for large lists (150+), as it does not improve the user's ability to identify all the options compared to static loading.

image

Bulk Select

To make it easier for users to transfer selected options from one input to another, I've conceptualized several basic shortcut actions that enables importing and exporting of options. It was vital to keep the actions free of any additional UI, as the user is already within the context of the dropdown pane.

image

Accessibility

Accessibility has always been at the core of this redesign. With the introduction of so many new features for the component, it was instrumental to make all the functionality reachable, and in turn, make the usability experience more efficient.

I explored ways to utilizing keyboard shortcuts to change states of the component. Shortcuts can naturally be overwhelming for the user as it involves forcing them to memorize a series of keystrokes. So I constraint the shortcuts to use directional keybindings along with the tab key for traversing through the widget.

image

Prototype

With all the features realized, I've defined a set of preset configurations with suggested use cases for future developers to reference. I also wanted the components to be as recognizable as possible to our other components to reduce visual deviance. Thus the prototypes were built in adherence to the existing styles we've been using for all other Veeva components.

image

Validate

After I implemented the components along with its variants, the product team and I facilitated in rolling it out one page at a time to test its viability. We started with the page with the densest input to capture as much user behaviour as possible. Tying back into efficiency and adaptation, I was curious to measure overall time-on-task and user error rate as our primary KPI, as well as how well developers were able to adapt the component to their feature.

Commondrop in use on Veeva Network
Commondrop in use on Veeva Network

Outcome

  • Deployed as a 3rd party library shared across multiple products
  • Eliminated reliance on regular <select> elements (~90% converted)
  • In use for 80% of Veeva Network pages, and 100% of cross platform pages
  • Sharp reduction in ops tickets involving data duplication

Next Project →

Brand Identity & Graphics

Footer

NameRows
1
2
Copyright 2021 © JXL Studio