Mercury Text Inputs
As Mercury’s grown, so too have our inputs. New pages meant new requirements, and new implementations, which lead to inconsistency and visual differences. To counteract that, we embarked on an input redesign project—unifying everything from text inputs to comboboxes to radio buttons under a single visual style.
I’ll share about the others soon, but I wanted to start with text inputs. Let’s dive in.
Getting started
Prior to this update, we did have some pre-existing input patterns. Our legacy styles generally were a simple underlined area with a floating label and placeholder. Occasionally it was just a placeholder, with an invisible bounding box. While this led to a clean visual presentation, it also was sometimes difficult to interact with, and made it hard to differentiate between input states.
Whatever aesthetic we chose needed to:
Solve those consistency and usability issues
Avoid a bland “rectangle with text;” we wanted a little "Mercury" personality
Avoid having too much presence, so only subtle use of color/shadow/animation
Work across many other input kinds: phone, dropdown, radio, checkbox, etc.
We started with a workshop exploring a bunch of different styles. The team pulled in a ton of examples, and experimented with all sorts of properties—fill style, shadows, label positioning, focus states and more—to figure out what felt right. From there, I built out a basic set of each of our core inputs, complete with all the necessary states. That helped us test designs in real form examples, to get an idea of how they might work in the wild.
Components and Variants were phenomenally helpful here, particularly interactive components. It made it super easy to create fully interactive forms while iterating through different property adjustments on the fly. Nobody on the team is dedicated to design systems work, so efficiency was important in balancing speed on this project against my normal product design workload.
What we ended up with
After we’d settled on a visual style that felt right, I was able to expand the set to include a ton of different properties (see attached) based on what we had in production, and what we knew we were likely to need in the near future.
As a principle, we try not to predict the future too much with component work—it generally means increased scope and complexity, without much immediate benefit (which means it’s not likely to get built).
From there, we deprecated the old component from Figma, and started using the updated one in our designs. The rollover process has been slower on the web—we have a ton of text inputs across our product, and opted to upgrade inputs whenever we touched an area. This means some initial inconsistency, but also made it easier to make some progress on the change.
Looks interesting?
We're hiring product designers at all levels, and I'd love to work with you. Shoot me an email (alexp@mercury.com) if you have questions, or check out the job posting.
