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.
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.
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.
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.
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
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
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
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
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.
Users were making selection errors → Improve readability
- Adaptive presentation style of selected options based on the size of the list
- Add selected option counts
Users were not finding options in extended lists → Improve discoverability
- Implement searching for the entire dataset (both front end and back end)
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
Users often face slow downs and crashed due to large list of options → Improve performance
- Implement lazy loading for large lists
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.
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.
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
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.
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.
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.
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.
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.
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.
- 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
Brand Identity & Graphics