In a time when every online service is competing for our attention, notifications have become notorious for distracting us from the task at hand. Despite their practically when done right, they are often overlooked and can therefore be quite detrimental to the user experience when done wrong, or even worse, when designed with ill intend. As product designer at TrustYou improving our in-app notifications became a sort of long term side-project of mine, one that I was keen on seeing through until it was up to par with modern standards.
Background
When I joined the company in 2014, their existing in-app notification system was one of the first things to catch my attention as something in need of UX improvements. Even though the mechanism behind it was quite clever and actually ended up still being in use at the time of writing, the aesthetics and usability had plenty of shortcomings.
Back then we actually referred to these as “marketing messages” and displayed them as nothing more than what we would now call a toast, with a very short snippet of text and a “Read more” button that would open up a page with the full content. Anything more than one message and they would be displayed carousel-style with left/right arrows for looping through them.
Buying time
Because this wasn’t by far one of my top priorities in terms of things to tackle, I settled for at least adding some aesthetic improvements directly in the CSS.
This approach effectively bought me some time until I could address the real usability problems:
- Intrusiveness. Banners are normally reserved for critical content that users must see because it might affect their use of the product, which was almost never the case.
- Legibility. The short banner forced the usages of small font sizes and increased the count of words-per-line, making texts harded to read through.
- Navigation. Looping through all notifications was only possible via on-screen arrow buttons, and clicking the “Read more” would leave the app.
- Management. Once a notification was read/dismissed, it was not possible to show it again for that particular user regardless of how important it was.
What followed was a long term project that evolved gradually along with the rest of our interface as did the industry standards with the rise of Material UI and other frameworks and design systems.
What makes them tick?
As mentioned above, the team was quite ingenious with the mechanism behind these notifications, relying on custom post types from an existing WordPress instance and its built-in RSS feeds to expose them as XML which a jQuery reader would then parse and render as HTML:
<item>
<title>TrustYou 6.0: Introducing a brand new TrustYou</title>
<link>...</link>
<pubDate>Mon, 1 Jun 2020 09:00:00 +0000</pubDate>
<description>...</description>
<type>feature</type>
<product>analytics</product>
<language>en</language>
</item>
<item>
<title>Catch one of this week's webinars</title>
<link>...</link>
<pubDate>Tue, 19 May 2020 08:30:00 +0000</pubDate>
<description>...</description>
<type>best-practice</type>
<product>survey</product>
<language>en</language>
</item>
Using WordPress for content management made these very scalable, and since I was no stranger to coding WordPress websites myself—having even used it to build TrustYou’s first help center—I used the feedback from my stakeholders and extended the functionality with a few extra fields such as type and language.
V1: Dropdown & modal
Consistency & modularity
By the time I got around to ideation I had already redesigned several other parts of the TrustYou web app while in the same time keeping an inventory of our UI components in what would become our first styleguide. This enabled me to keep designs consistent and helped the team build more modular interfaces based on atomic design. In the case of notifications, it also meant that things were in place to finally readdress the previously mentioned usability issues, and so I started sketching out ideas.
Since these were ultimately just WordPress posts at their core, it meant that I could display them as a list of articles with the “Read more” link expanding the notification in a modal window.
This way I could leverage the full power of WordPress posts by properly rendering rich content such as images and formatted text.
Highs & lows
Back in those days I was coding front-ends myself in HTML, CSS, and even jQuery, so all the development team had to do was take my coded templates and apply them to the existing mechanism. This significantly brought down development costs while in the same time having a high impact on usability.
With prototyping tools being somewhat limited back then, a coded prototype really enabled me to play around and get a feel for how the interaction design would turn out, not to mention simulating edge cases such as having too many notifications (e.g. triggering scroll overflows) or having no notifications at all (i.e. empty states).
After a few iterations, a first design was ready for implementation with the aforementioned usability issues addressed:
Intrusiveness.Progressive disclosure via a navbar button allowed the toggling of a dropdown containing a list of notifications, with a red counter indicating the number of unread ones.Legibility.Narrower items in the dropdown list reduced the words-per-line and usage of titles and excerpts made them more concise and easier to parse.Navigation.Lists were now infinitely scrollable with each notification opening up in a modal window without users having to leave the app.Management.Once a notification was read it would get grayed out and remain in the list, but the badge counter would decrement (or disappear in the case of zero).
This design was live for many years until eventually design patterns started to mature in the industry and along with it came the need to revisit this solution.
V2: Drawer
Motion design & emerging patterns
With mobile design maturing, the line between interfaces for different devices became more and more blurry as new patterns emerged. One such pattern was the use of drawers for pulling up content without fully changing context, a UI component that we ourselves were already using in other parts of our web app.
Besides ensuring more space to view the list of notifications, using a drawer also provided a larger viewport to read the notification in full view with less scrolling and narrower lines, not to mention being able to view embedded images in their entirety.
Leveraging the structure of our card component, I also explored ways in which opening the full view could be done in a more fluid and less jagged way. This way possible with the help of a secondary area of the card body which would slide in from the right, consistent with how the drawer itself opened.
In the detailed view, a back arrow allowed users to return to the notification list by reinforcing the horizontal direction that the entire motion design adhered to. By this point
Configurable notifications
During this entire time the help center that I mentioned had already grown to include not just documentation but also a multitude of other content types such as instructional videos, case studies, and best practices, all of which could be made more easily accessible to users via dedicated notification types.
Apart from pulling in resources, notifications could also have been used to recruit users for research initiatives, a hypothesis that we had already tested successfully when we built our own user research pool.
The possibilities were endless but then again so was the risk of spamming our users, so it was important that they could quickly and easily opt out of any notifications they did not want to receive.
Erase & rewind
Despite having things in place for this new notification center to be implemented, shifts in priorities forced the team to park the project until eventually an overall platform redesign brought it back into focus. By this time our newly established design system, TrustYou Brew, had been steadily maturing and was well in use throughout the platform which meant that my old coded prototype had to be updated as well.
As designers our own process had also matured significantly and we were no longer coding our interfaces, so the notification center had to be completely redone in Sketch using our new component library and following well-defined conventions (e.g. color, typography, spacing) and patterns (e.g. error states, empty states, loading states).
With most of the work having already been done, it was a relatively low effort to update the existing designs. These were then handed over to the develpment team via Invision and Zeplin, with the goal of going live in early summer of 2021.
Conclusion
What started off many years ago as just one of my internal side-projects ended up taking me through a multitude of learning experiences, from coding backends in WordPress and front-ends in Pug+Sass, to managing multi-stakeholder projects across different departments and establishing a component library and design system that ultimately directly impacted the redesign of an entire platform. That being said, a design is never finished and the user feedback we get will help inform what next steps are needed to continuously improve it.