Overview
Pipedrive is a cloud-based, easy-to-use, CRM tool built for salespeople. Used by over 100,000 companies in more than 170 countries.
I worked at Pipedrive as a Product Designer for their design systems. Their token-based, theming-ready system is publicly available in Figma Community, you can check it out for yourself here. One of my main responsibilities was advancing the components and design patterns used in the web app.
This case study covers one of those projects: rethinking the use cases for the Snackbar component to provide more meaningful feedback to users without adding unnecessary distraction.
Role: Design system designer
Other participants: Design system team (feedback and reviews)
Project: Snackbar component
Year: 2022
Process
A question came up if we could use the snackbar component for different state declarations, like errors for example. We decided to explore the use cases for this component and dig deeper.
Research
The research process had two phases: Internal and External.
Internal Research: This phase included conversations with product designers in the company on how they show error messages in the product, exploration of how the snackbar component is being used in different products, and a review of past discussions about user feedback and notifications.
Our internal research showed us that some designers already use this component to show error messages, and some legacy design issues require a different way to show error status in addition to inline messages. This confirmed there was a real need to align the team around a consistent approach to feedback and error states.
External Research: For the external research I gathered information about notification and user feedback patterns from various design systems, and also looked at the design and guidelines of toast/snackbar components.
Ideation
The ideation process included working on different solutions while following the guidelines of the system. Critical error messages were also considered but left out later in the process because they require more attention from the user than we would like to provide by using this component. Some accessibility topics to discuss (like contrast issues) also came up during this process.
Design Decisions
After several review rounds with the team, we decided to keep the existing visual style and introduce only two new variants, minimizing development effort. Colourful designs were explored but rejected, they attracted too much attention for what is meant to be a low-distraction element.
These reviews also surfaced a broader need: establishing consistent notification and error handling patterns across the design system, which was added to the product roadmap.
Developer Handoff
I finalized the component design, prepared the developer handoff, and updated the guidelines. Updating the guidelines took extra care, as they serve as the main communication channel for a distributed international team. I tried to be as clear as possible, and also asked for and received feedback on the documentation separately.
Developer handoff
Outcomes
- Identified the need for a broader "Notification and Error Handling Patterns" initiative, which was added to the design system roadmap as a result of this project.
- A new Snackbar variant shipped: warning state, extending the component's use cases without increasing visual complexity.
- Updated guidelines and developer handoff published, giving the international design and development team a clear, documented pattern to follow.
Before
After
New state in use (example)