Messaging Ecosystem
Defining messaging components and their usage in our design system
Background
Several different forms of messaging existed in the Story design system, but there lacked clear guidelines on when to use specific components. This resulted in inconsistency across products that leveraged the design system, as well as confusion amongst both designers and stakeholders.
I set out to provide clarity on what messaging type to use when, as well as to potentially create new components for any unaddressed needs.
Role
Product Designer, JPMorgan Chase
Date
Spring 2023
Laying the groundwork
I first conducted competitor research to understand how other design systems have solved for this problem. I often came across tables that listed the different component options and provided broad explanations on what to use when based on a variety of variables such as if the message was global or contextual, what triggered the message (the user or system), and whether user action was required.
The aforementioned research helped me hone in on what themes to look for once I did an audit of the messaging components available in the Story design system. I also spoke with designers about how they were using these components in their work.
Key findings
The relevant messaging components were treated as independent entities rather than parts of a larger messaging ecosystem, which explained the absence of guidelines for what to use when.
There was no prior consideration for how to communicate global system vs. page-level events.
There lacked any persistent page or section-level messaging component, leading to an overreliance on popup modals, which are highly disruptive in nature.
At least one team had created their own local banner-type component to cover the need mentioned in the previous bullet point.
As I concluded my research, it became obvious to me that our designers were at a clear disadvantage. They hadn’t been given sufficient tools or information needed to ensure the appropriate and consistent messaging experiences in their work. It was little wonder why there had been so much confusion and incongruity when it came to in-product messaging!
Creating the assets
I devised a three-part action plan to solve for this problem:
Create a new page-level messaging component (Alert)
I gathered requirements across teams that were in need of such a component, including the one that had taken the initiative to create their own local component. It was decided to use semantic colors and icons to convey the feedback type (e.g., Success, Error, etc.) and grab the user’s attention.
Create a new global messaging component (Banner)
Because this component was meant to communicate system-wide messaging, it employed a UI with a heavier emphasis than the Alert, and it was decided that it would always be positioned at the top and span the full width of the screen.
Define the different messaging components across the ecosystem
New messaging guidelines were created as a single source of truth to compare and contrast the component options and to help designers determine the appropriate messaging for a given use case.
Messaging guidelines provide direction on which components to use when
Messaging component decision tree
Initial feedback
Designer response was overwhelming positive for the Alert component, for it created far less friction for end users compared to prior go-to component, the popup Dialog. That said, based on designer feedback, a compact variant was then created for use on screens where space is limited.
Finalized Alert component for page-level messaging
Placement guidance for the Alert component
When discussing the new components with our lead engineer, I learned that there was already an internal dev-specific component named ‘Banner’, meaning that this new component would need a different name to maintain nomenclature distinction. After workshopping alternative names with a content designer on my team, we decided on the name ’System Banner’, which would further emphasize its purpose.
Finalized System Banner component for system-level messaging
Placement guidance for the System Banner component
Impact
The two new components were released January 2023. According to the component library’s analytics in Figma, by the end of the year there were 250 System Banner instances and over 2,000 Alert instances within working design files across the organization.
The messaging guidelines were also deemed a success. They helped to foster understanding of the component options amongst designers, thus empowering them to make the right choices. The triumph of guidelines also underlined the need to take a more holistic approach with regard to design system components to ensure consistency and transparency for designers and stakeholders.