A case study for a specific use case.

Overview

A common pattern used in enterprise app are input components with post-tab with select dropdown. We explored a new pattern for a use case where there are just two options in select dropdown.

Standard Practice

A standard practice we can find for input components with select dropdown (or commonly called post-tab input) is having the select option within the boundary of the input field. A simple representation is shown below:

This pattern is the most common for a reason. You can include as many option as needed in the option menu. However, it’s better to have up to 5 for better experience. If there are more options, it is better to use a different pattern with a separate select dropdown and input field. These components are used when selecting currency, country code. It’s also a good pattern to have a search option alongside the dropdown.

Our use case

Despite the standard pattern having enough flexibility, one of the common cases we encountered while working on enterprise fintech applications were cases where we had to toggle between two units. Cases like switching between Debit/Credit, km/mi, kg/lbs and so on.

We can either keep the options in a dropdown or have a simple toggle or switch can be used like below.

This pattern provides a good context to the user. The downside is it takes a bit too much of space than the standard pattern.

Back to the inspiration board

Then we looked at how the units are represented in actual practice. We looked at how ledger reports and cases where transactions are listed in a single-column.

Debit / Credit are represented with their standard short form

Debit / Credit are represented as their standard negative () or positive values

A new pattern

Taking inspiration from how they are represented in reports, we worked on a new pattern. For cases where there are just 2 units, we found out it would be easier to just click on the unit to switch. These are cases where users are aware of both the options. If there is a debit, the user would expect the other unit to be Credit and so on.

The new pattern we implemented

This pattern allowed user to quickly switch between two units while preserving space. It also provided correlation to real-life usage.

Final words

We implemented this pattern quite a few times for both touch and non-touch devices. It helped improve usability for a specific use cases (while looking decent enough).

There are however limitations to this. This pattern is not advisable for cases where there are more than 2 options. It can be implemented for cases with 3 options where the units just toggles between the options serially.