DESIGN SYSTEMS
Notifications
I designed a notifications component for the Appian design system, built to support applications across government acquisition, financial services, and other industries. With each product operating under different constraints, teams were solving notifications in fragmented ways. I created a flexible, reusable pattern that reduced implementation time and redundant design/development work, and strengthened overall product cohesion.
ROLE
UX Designer
TEAM
Appian Design Team
DURATION
3 weeks
TOOLS
Figma
SAIL
✤ OVERVIEW
Why do reusable low-code components matter?
With a proven pattern, we can help designers and Appian developers move faster as they build custom applications. We can establish good design standards across the org and help teams spend more time focused on solving business problems.
PAIN POINTS
Notifications are widely used but not standardized
Most, if not all, of our software solutions have a notification feature. However, they're all implemented differently and inconsistently.
Flexible and resilient
The pattern needed to be flexible because it had to be configurable to any solution use case, but also needed to be scalable.
✤ DISCOVERY & RESEARCH
Collecting Designs
I wanted to understand how other designers created their notifications features and what they needed from a generic, reusable component. I collected designs and interviewed other members of the design team.
INTERVIEW FINDINGS
Notifications must be actionable
Everyone mentioned they needed a notifications component to enable them to perform sort of action. This was a big pain point with some of the current designs
Notifications must be easily scannable
Users can quickly understand what’s new, what’s important, and what needs action without digging through dense content. This is especially important at scale.
The component must be easily configured
Everyone I interviewed asked for a generic enough component that they could modify slightly to fit their needs.
Notifications vs. Alerts
As a team, we could not come to a 100% agreement as to whether or not alerts should be a separate pattern.
✤ DESIGN
Final Component
I wrote documentation on how to implement the pattern, the do's and don'ts, and accessibility guidelines.
✤ CONCLUSION
What I learned
Just ship it.
It's better to be uncertain about the design and continuously iterate upon it than to wait until it's perfect.
Flexibility should be opinionated, not chaotic
A flexible component still needs a “center of gravity” so we don’t reinvent patterns or introduce inconsistency.