UX Designer & Manager • Chicago-based • she/her
An Accessibility-First Design System
Client: Discover Financial Services
Role: UX Lead
Timeline: ~2 years
Overview
Discover's current design system is cohesive and functional, but its documentation lacked precision and robustness. Further detail on component usage, states, variants, and screenreader behavior was evidently needed. We also needed to designate distinct libraries for Browser, iOS, and Android, given the variety of design considerations for each (e.g., font choices and screenreader standards).
We defined 10 sections for each component's documentation:
-
Usage
-
Anatomy
-
Variants
-
Style
-
Sizing
-
Positioning
-
Content
-
Exterior formatting
-
States & Behavior
-
Accessibility
Vignettes of Component Documentation
My role was spearheading the UX side of the work, while the UI designers worked their pixel-perfect magic. I conducted research for the genesis of each component, described the behavior & functionality, and annotated the accessibility details for developers.
Research
Since we work in an agile framework, our first sprint for a component always begins with research. I dive into the component's behavior, styling, and functionality in other design systems and experiences. The research begins with the main design system players (aka the Big 4): Google's Material, IBM's Carbon, Microsoft's Fluent, and Apple Human Interface Guidelines. From there, I dive into other relevant systems or experiences.
To streamline this work, I built a research template for the team. I don't expect it to be legible here, given the density of content, but here you can find a preview of the format.
The research template consists of an analysis of the existing design system's component, the Big 4's treatment and documentation of the component, initial usability and accessibility concerns, and a final recommendation for the component build.
An example of this Round 1 Research is the work I did for Floating Action Button; we were considering adding this component to our library, despite how controversial it can be. Below is a sample from my research synthesis:
Summary of Research on Floating Action Button Usage
-
Floating action buttons should be used exclusively for the most common and important action on a screen. Since it can obscure the content behind it, it should be used sparingly.
-
FABs should be used for single actions, rather than the beginning of complex user flows
-
They should be reserved for constructive (Compose, Add, Create), not destructive (Trash, Archive), actions
-
The most common FABs are Plus (adding a new event, post, or instance) and Pencil (compose a new message, start new chat)
-
FABs are often leveraged to reduce taps: if something is often 2-4 taps away, but is a hallmark action for the app, the designer can create the FAB to reduce the journey to one tap.
-
To keep the FAB footprint small, they often only include a (universal) icon. Occasionally, minimal text is included.
Accessibility Concerns
-
The Floating Action Button should appear in the focus order similarly to a tab bar or header button that overlays content.
-
However, FABs can introduce challenges with color contrast consistency, since the content behind it is regularly changing.
-
FABs may present reflow issues on zoom: at 400%, it would take up a significant amount of screen space, making multiple FABs untenable. Therefore only one should ever be shown at a time.
-
When FABs are only shown with an icon, they can only be used for actions that are effectively conveyed via universal icons (e.g., Search).
Final Recommendation
Although FABs are beneficial components in some applications, we are unable to identify a use case within the Discover app that would be appropriate for a FAB. Presently, there is no user data to indicate that a primary action is buried behind multiple taps, warranting a FAB. Existing actions like “Make a Payment” or “Add Payee” would be more appropriately handled with either a simple primary button (due to there being no scroll) or a sticky button (as they trigger a flow). Therefore we recommend against adding this component to our library.
Behavior
When defining the precise behavior of a component, I ensure triggering actions, swipability, dismissal, and error feedback, are comprehensive enough to set up developers for success.
For example, here I described the specifics of the placeholder text and input masking for fields such as Social Security Numbers. Security, accessibility, and transparency are all fundamental to a component such as this, so delineating clear behavioral guidance for our developers was my top priority.
Again, I don't expect this matrix to be entirely legible here, but here is a preview of how this content is documented.
These matrices help guide developers to understand the myriad states and variants of a component in a particular use case.
Below is a sample of my behavioral notes for Text Fields placeholder text and input masking:
Text Fields can use placeholder text to offer concise and relevant hints about the required formatting of the input text. When active, placeholder text appears next to the blinking cursor.
Placeholder Text Guidance
-
Do show placeholder text when field is active
-
Do not show placeholder text when field is enabled
-
Do not clear placeholder text as a user starts typing
-
Do replace each placeholder character as a user types
-
Do combine with input masking to enforce formatting
-
Do not use placeholder text to demonstrate unformatted inputs (e.g., name, email)
Use Cases
-
10-digit phone numbers starting with an area code
-
9-digit Social Security Numbers or ITIN
-
Card and Account Numbers
-
Dates
Where UX Informs UI
Although the UI team is responsible for giving the designs visual muscle, there are of course instances where the UX will inform aspects of the UI. This occurred for our Menu Component, when our client was concerned with the potential existence of a default field. They had reservations about how helpful these are, and potential screenreader challenges. Below is my research & recommendation for this dilemma.
A default selection can be beneficial as long as it meets one of these three criteria:
-
the menu is not part of a form
-
it's an umbrella for all selections
-
it affects content on the page
-
it can be predicted from past user entries
For example, a user is reviewing their spending graph and wants to select a category of spending. We show a default selenction of "All Categories." This passes the test because:
-
It’s not part of a form
-
The pre-selected “All Categories” acts as an umbrella for all options
-
The selection influences the graph a user sees, directly affecting the content displayed
Additionally, consider a user who is making a payment and wants to select a bank from a dropdown field. The menu would not benefit from a preselected default item because:
1. It is part of a form
2. There is no relevant umbrella selection
3. The selection doesn't affect content on the page
4. The user has made a selection in a the past that we can remember
Do: Use pre-selected menu items to facilitate ease of use or offer an umbrella selection.
Don’t: Use generic placeholder text within a menu as a selection which lacks semantic value.
Annotations
Annotating the exact functionality of screenreader behavior is fundamental. Focus order (for keyboard navigation) and reading order (for screenreader navigation) need to be delineated, regardless of platform.
For our text field component, I annotated the specifics of each piece of the design, and how the reading order (screenreader navigation) and focus order (keyboard navigation) would behave. Additionally, annotating alt-text for icons and placeholder text (which notoriously have screenreader challenges) were integral to ensuring an accessible user experience.
Sample of Accessibility Notes
Assistive tech should read the Text Field’s label, the role, the input (if any), the state (if any), and the helper text (if any), all in succession. Next, it should read the trailing icon button (if any). All other elements, such as Text Links with Help Icons, are read next.
For example, for a filled Text Field with helper text: a user hears “Email, text field, jordan@gmail.com, Please enter personal email.”
My Takeaways
As this project comes to a close, and developers continue to bring these components to life, I've gathered some reflections on the process of building a Design System.
1.
Collaboration is key on any team, but it is wholly paramount in a successful design system. Synergy between UX, UI, development, and stakeholders leads to the best user outcome. For example, when designing our Bottom Sheet, the component needed to accommodate myriad functionalities" menus, forms, notifications, disclaimers, etc. This component was also very hairy for developers, as it introduced complex questions regarding the z-index and screenreader behavior. Early transparency between teams led to a smooth design & development of this component. Through our collaboration we aligned on decisions like making the close X first in the focus order, and making the Bottom Sheet level 3 on our z-index.
2.
The better defined the problem is, the easier to solution is to find. When designing our Chip, we had a slew of conversations regarding the intersection of Chip with Selector Buttons, Badges, Tags, and other similar components. Clear delineation between the potential functionalities led us to understand what components actually added value, and which ones were extraneous.
I built a Venn Diagram of our components that shared aesthetic, as well as functional, similarities to help us discern which components needed to be built & prioritized for our library.
3.
Radical empathy and obsession for detail will drive me towards the best user outcome. Having spent hours struggling through my iPhone's VoiceOver feature, playing with complex gestures and interrogating countless apps & websites behavior, I have gained a deep appreciation for what makes Design System development succeed, and what makes it fail. Creating a beautiful design system isn't enough; having empathy for the end designer and developer leads to pristine documentation and understanding of their needs. Precise communication is a skill I have honed on this project, and I am excited to keep flexing this muscle.