1. Summary
Keeping users informed of major feature releases and smaller product updates is key to maintaining a good level of engagement and activation, however it is easy to create an overwhelming experience that results in the opposite effect – where users become blind to any kind of notification. During my time in the Shared Experiences team I lead the research, definition, and design of our Product Update pattern – so every team at New Relic was able to implement and follow our best practices and guides on how, when, and why to inform our users of relevant changes and releases.
💪 The challenge
Up until that point, the only way to communicate updates to our users was through the use of callout components, essentially a pop-up that was automatically triggered by the platform that each individual team was able to call on demand whenever their PM considered there was a need to disrupt the user's journey. One of the main problems of this approach was that teams did not share a common criteria to define what is worth notifying which resulted in some parts of the platform having way too many callouts per session. The other main issue was that the major product launches and smaller visual updates (such as a new button or layout) were treated without distinction of visual hierarchy or prominence.
Finally, the callout component itself allowed too much flexibility on it's implementation without much clear guidance which resulted in teams implementing different variants for things like the positioning of the main CTA.
💡 The solution
Create a new shared pattern to communicate product updates that is easy to implement, offers flexibility, and can scale into future sub-patterns such as Walkthroughs and Product Tours.
2. Discovery
Mapping the current status
Before we could start drafting solutions we needed to evaluate the current status by mapping all the implementations available. This would allow us to later organise our findings based on different criteria like:
- the type of updates we tend to communicate
- the type of interactions we use to trigger, and dismiss them
- the style and length of the messages
- the actual usability or practicality of the notifications
What we learned early on
What we found was a big discrepancy in how teams were designing these experiences. Some teams were using a top banner component while others were relying exclusively on the callout which not only confirmed the inconsistencies we knew but it also forced us to look into the current documentation of the Design System.
The main use-cases we detected when it came to the usage of the callout and the banner were:
- Small updates: for things like a button changing placement.
- Medium updates: for things like adding a new dark mode option. This was a rare use-case but the examples we found tend to use a
calloutwith animated screenshots. - Big updates: for major feature releases like a new AI query builder. Some implementations used the
bannerwhile others used thecallout. - Walkthroughs: when a user landed on a new feature for the first time (not available in all features though).
Too many components?
An important key finding was realising that although the Design System had specifically designed components for communication purposes, the way it was trying to fit many roles within the banner component in combination with the callout was creating a lack of cohesion and logic that could partially explain why teams were having trouble understanding when to use each one.
After the initial house cleaning we realised we had a bigger scope at hand than what was initially defined.
Takeaways
After the initial house cleaning we realised we had a bigger scope at hand than what was initially defined. We had common, day-to-day type of update notifications that were designed to improve engagement and activation by notifying users of relevant, useful updates – we then we had big splashy launches that required a less intrusive approach, a bigger cadance, and an overall more intense marketing approach. Finally, we had a set of tutorial-like experiences that were dependant on the same two components used for the previous use-cases but had never been defined from a pattern point of view.
General VS Specific context
While analysing the previous experience we also identified a sub-level of hierarchy that would determine the entry-point to the notification: the context to which the message belongs to.
- General context: These would be updates that can be perceived across the entire platform. From navigational elements, to changes in specific user management pages.
- Specific context: All those other updates that are only relevant once the user is inside the feature that is being affected.
Competitive analysis and market research
Once we had a good understanding of the use-cases and common requirements for the experiences, we needed to explore what were the common patterns used in these scenarios outside of our ecosystem.
We analysed 42 different players from major SaaS, and B2Bs services and we categorised them again based on their use-cases, types of interactions and overall UX strategy.
This time around we focused not only on the nuances of the types of update notifications but also in the kinds of UIs used and the differences between their use-cases.
3. Drafts and sketches
Some initial explorations trying to combine the information color token with the floating callout component. At the bottom some explorations on a new version of the banner component that could be embedded to specific parts of the UI.
Testing color tokens against different color modes (dark, high contrast, light).
Exploring highlighting within specific areas while guiding the user through a stepped discovery tour.
Exploring new UI patterns for big splashy announcements.
4. The Outcome
After many rounds of fine-tuning, collaborating with the Design System team, work sessions with engineers, endless discussions on how to make it easy to consume, and presenting it to stakeholders we were ready to present the final outcome. This consisted in 3 deliverables:
🛠 Components revamp
A revamp of the current callout that added new features, cleaned up the spacing and proportions of the previous version, and offered more optional customization.
Simplification of the banner component by eliminating marketing like use-cases and re-purposing the component exclusively for state status feedback.
New announcement component designed to serve as the high focus launch for those bigger feature updates and product launches.
🆕 Introducing the pulse
A new UI element meant to be used in combination with the callout to signal and focus the user's attention on the context of the messaging of the pop-up.
This addition disrupts the way in which we had been thinking about the UX of notifications and introduces a new approach in which the user is able to decide wether they want to trigger the message and discover what's behind the pulse or if instead they prefer to discover it at a later time or through exploration.
📑 Patterns documentation
A robust, and comprehensive new patterns section on our Design System documentation page in which we describe the common best practices, possible use-cases, do's and don'ts and example prototypes in order to facilitate implementation of the new set of patterns.
The final result not only provides an improved experience when consuming the documentation, and offers better designed components but it also provides a new approach when it comes to the fundamentals of the user experience. By allowing users to opt-in the content's of the callout we stablish a new relationship with our users, reducing noise, and increasing trust by removing barriers when they are trying to monitor their systems and applications during a critical situation.
Prototypes
5. Currently: on hold
At the moment the team is still trying to allocate the resources to implement the new set of patterns. In the meantime we are collaborating actively with different teams, offering our guidance and recommendations on how to apply the new principles on their upcoming set of updates and releases.
So far, we've noticed positive feedback from other designers as well as engineers that have expressed how necessary this effort was, and how much work it will remove from their plates since they won't have to re-invent the wheel every time.