Updating Sifter Part 2: Notifications

Alerts and notifications are an inextricable element of software design, yet they rarely receive the attention that they deserve. Despite being one of the primary means of communicating between software and user as well as being the first line of defense when things goes wrong, alerts and notifications are notorious for being neglected.

Despite being one of the primary means of communicating between software and user as well as being the first line of defense when things goes wrong, alerts and notifications are notorious for being neglected.

Sifter was never the worst offender, but we certainly weren’t going to win any awards for our notifications. Don’t get me wrong, we still aren’t going to win awards, but the situation is much improved, and with our upcoming update to Sifter, I saw updating the header and notifications as almost going hand-in-hand. Now we have a solid foundation upon which we can improve.

It feels odd diving into the details and considerations for designing notifications, but these updates really make a huge improvement in the overall experience of using Sifter.

Why are alerts and notifications so hard?

Alerts and notifications have a perfect storm of complexity to make them one of the more challenging parts of interface design. Creating notifications that are helpful and visible without getting in the way is a difficult balancing act. When you break it down, there are quite a few factors at play that lead to these challenges.

Transience Notifications aren’t always visible. So they receive less attention.
Prioritization “Fix me now!” vs. “Take a look when you get a chance.”
Varying States Dismissible vs. Permanent vs. Temporary
Usage & Purpose Interactive vs. Informative
Context Success vs. Failure
Content Succinct vs. Detailed
Audience Account Holder vs. Administrator vs. Everyone

Each of these variables introduces its own level of complexity. Mix them all together, and you have a fairly complex multivariate design equation. Creating a flexible and consistent framework to support with all of the possible scenarios can get messy.

Let’s look at a quick example. While we want to tell an account holder that their account is frozen because their credit card was declined three separate times over a week, we should probably tell their end users only that the account is temporarily frozen and to contact the account holder without any mention of billing issues. Similarly, while the message for the account holder is of the “Fix me now!” variety with an actionable next step, the message for the other folks on the account is only informative/explanatory with no explicit action that must be performed. Depending on the audience, both the severity and content will be different.

Just how many different alerts are there?

Over time, with new features, interactions, and pages, the visual design for Sifter’s notifications and alerts had become increasingly, uhm, let’s call it “eclectic.” An extra notification here. One there. Lots of fragmentation. Not a lot of continuity. But, before we dive into the specific mistakes, let’s run through the various types of notifications and alerts.

Account Alerts

These include billing problems, trial expiration warnings, and that sort of thing. The account holder is the only person that will ever see these. However, in the case of a frozen account, we still need to present an explanation to everyone else. 1

Screenshot of a trial reminder within the account area of Sifter — 1 Account alerts are more context-aware so that they don't pester folks but are also not easily overlooked.

Bouncing Alerts

Sifter has extensive bounce handling in place so that we can let folks know whenever we have delivery problems to a specific user’s email address. 2 These notifications help people get to the bottom of things and get delivery back on track. These become complex due to the diversity of email delivery problems. 3

Screenshot of a bouncing email alert for the logged in user. — 2 Bouncing notifications are one of the most common alerts that require action. However, the diversity of reasons for why we can't deliver email to a user requires a high touch process. The new notifications make it easier for customers to assess and address the problem.

Screenshot of bouncing email address alert for a user other than the logged in user. — 3 In addition to informing the logged in user about problems with their own email address, we also need succinct notifications to let administrators know when someone else's email address needs attention. More often than not, these are caused by typos in the person's email address when initially inviting them to Sifter.

Flash

Flash messages are generally for confirmation of an action, but they come in handy in other ways as well. For clarification’s sake, in this context, I’m referring to the Rails terminology where “flash” is a temporary session-based message passing system rather than Adobe Flash. 4

Screenshot of a flassh confirmation message after creating an issue. — 4 Flash messages are the most frequently encountered message, so they need to be visible but not too obtrusive.

Errors

These are the temporary messages to either confirm the completion of a user-initiated action or alert the user to errors with their submission. 5 These are fairly standard, and we haven’t done anything wild here. I envision a lot of room for improvement in the future, but since these are so closely tied to forms and the associated interaction, I felt it made sense to significantly improve these in conjunction with improvements to our forms.

Screenshot of error messaging after a failed attempt to create an issue. — 5 Next to Flash messages, error messages are one of the other most common types of notifications. These need to be slightly more obtrusive and generally provide actionable advice.

Announcements

Announcements help keep folks in the loop on things like new features, system maintenance, or downtime. 6 These are not pressing issues, but maintaining reliable communication with customers helps them get the most out of Sifter. Long-term, we’re working to make news and announcements a more significant feature within Sifter to help customers take advantage of and learn about features, but we had to cut scope somewhere for this release.

Screenshot of an announcement on the dashboard. — 6 Announcements are a work-in-progress, but they're key for helping ensure that our customers know about new features and improvements from which they could benefit.

Warnings

On any page where folks are able to do irreversible damage and delete large amounts of data, we want to make it crystal clear what’s happening so there’s never any regrets. 7 In some cases, these messages can present alternatives to deleting the data. For instance, when deleting a project, we suggest that they archive it instead.

Screenshot of a warning regarding attachments when downloading an XML export of a project's data. — 7 Sometimes, we just want to give people a heads up so they take a second and read instructions. Ideally, we wouldn't need the instructions, but these warnings come in really handy on pages where customers can permanently delete data.

In this example, since issue attachments are stored with Amazon S3, they aren’t included in the export and require some extra effort to obtain. When customers need attachments upon exporting their data, we have a script that can download them. This is currently a manual process, but eventually, we’ll be able to automate it and the warning will be unnecessary.

This is a simple example of compromising on where we invest our time. Using an attention-grabbing notification here is a sign that we can improve the underlying functionality, but as infrequently as it’s used we improving it in baby steps.

Screenshot of questions linked from our plans and pricing page within the application. — 8 Throughout the application, there are some questions that we'll always receive.

Tips & Suggestions

With all of the questions we receive, we’ve found that it’s really helpful to include some tips and links to our help docs directly in the page. 8 Helping expose these questions and answers helps save our customers time emailing us and helps us save time replying to those emails. Customers get more done. We’re able to focus on improving the product.

These aren’t traditional notifications, but they are still an important means of increased communication with customers. They definitely still fall under the category of helping people use Sifter and get the most out of it with the least effort. And for our customers, clicking a link is much easier than emailing us a question.

There may be a better name for it, but we’ll go with “Related” for now. In some cases, for instance if a user’s email address is bouncing, that can affect other areas of the application. So, while we don’t want to have bulky notifications on every page, we do need to remind them that a related feature might also encounter problems if they don’t address a related issue. 9

Screenshot of an alert about a bouncing email address on the notifications page. — 9 You can't fix a problem with a bouncing email address on the notifications page, but if you're not aware that your email address is bouncing, it's definitely going to affect your notification settings because you won't receive any notifications regardless of your selected options. So we have to be able to place smaller alerts on relevant pages at times.

So how did we go wrong?

All of these different contexts, combined with the variations of alerts create a lot of room to make mistakes and do a poor job of communicating via alerts. Fortunately, I have some very specific mistakes and lessons learned to share.

Difficult to Update and Test

First and foremost, our biggest challenge was keeping the notifications updated and consistent. By their very nature they’re not always visible, and making sure to cover and review every possible permutation is difficult and unreliable. Even simply copywriting changes were tricky. This was more of a code mistake than a visual design mistake, but it mattered. With this pass, I rebuilt how we handle notifications so that copywriting changes are incredibly easy by centralizing the messaging copy.

For the visual design, I set aside time to create a simple set of tools to quickly scan all of the different types of alerts. It’s nothing fancy, just a page that hard codes samples of all the alerts. 10 This helps with the style, but not the substance.

Screenshot of our handy notification template designer for testing. — 10 Building this template page makes it easier to adjust and improve our notifications without having to go into the application and trigger a notification to appear.

Now we can extend or modify our notifications framework and apply the right approach in each situation without fear of rocking the boat. Despite the improvements, this is one of the pieces I’m most excited about because it makes it easier for us to continue to improve.

Too Subtle

Some information was included on the pages, but it wasn’t emphasized. While I’ve always heard and believed that people don’t read the instructions, it becomes much more clear when you receive many emails asking questions that are answered on the page. It becomes a fine line to walk between informing folks and blasting a message at them.

Before and after screenshots showing how much more visible key information is with our new approach to notifications. — 11 I'm still hoping to find a more elegant solution, but sometimes, you just have to make things bold and bright to make sure they get seen. This is one of those cases where the need for highly visible notifications is a sign that we can improve how the functionality works.

One of the most frequent problems is Sifter’s email integration. Since Sifter is designed to be an internal and private system, our inbound email addresses are tied to user/project combinations. This is how we know who created the issue and what project it should belong to. Despite the emails being private for each user, we frequently receive support requests or catch situations where folks are sharing the emails.

It becomes a fine line to walk between informing folks and blasting a message at them.

With the earlier approach, we made this information subtle, but based on support requests and failed attempts to create issues by forwarding emails from another address, we had to make a change. 11 With this update, we wanted to visually emphasize the limitations of Sifter’s email integration and provide easy answers to folks looking to understand how it all works. 12

One could easily make the case that the need for some of these types of notifications is the result of a poorly designed feature, and to some degree, that’s valid. In a way, with our long-term plans, the presence of some types of notifications serves as an internal reminder of where we need to improve how the feature works. We have to choose our battles, though.

Screenshot of header with flash messaging before and after to illustrate the improved contrast. — 12 Before, the header and the flash message blended together. Contrast was low, and it was easy for useful information and links to get lost in the shuffle. The new flash messages pull away from the header to stand out and feel more like a temporary element.

Too Obtrusive

Just as some notifications were too subtle, others were too obtrusive. 13 Previously, most of the notifications and alerts were tied closely to the header, and by “tied closely” I mean “slapped on top of.” There was little intelligence to them and they were sort of crammed in there. This approach was the result of a one-size-fits-all approach to notifications and left a lot to be desired.

Screenshot of the old header with bounce notifications and flash message all blending together. — 13 While it was a rare occurrence, it was entirely possible for people to see a page look like this. Little contrast. No hierarchy. It was difficult to understand what was most important.

With the improved navigation, instead of displaying full alerts, subtle visual cues are used to guide people to areas that need their attention. The improved hierarchy of the new navigation also helps implicitly prioritize notifications so that users aren’t choosing between competing notifications. 14

Screenshot of the newer header with several alert icons on the global navigation and the system notification on the page. — 14 While this screenshot doesn't include the flash message like above, it's much more clearly organized with less important notifications relegated to the simple alert icons in the global navigation.

With this header and navigation redesign, the goal was to ensure that the alerts wouldn’t be missed but also wouldn’t get in your way. This way the alerts can be present on every page without getting in the way when you’re in the middle of doing something else. Adding a small icon to the relevant navigation item is a much more effective notification than a set of huge yellow bars. This is a case where aiming for the smallest effective difference works nicely. It’s just different enough to not be missed while being unobtrusive enough that it’s not annoying.

Screenshot of the header with several navigation items highlighted with a small icon — 15 With this update, notifications and alerts were designed to be part and parcel of the navigation. Instead of a separate inbox for notifications, they're tied directly to the affected area.

The other big advantage here is that the alerted links are smart enough to take folks directly to the relevant area of the application that needs attention. Once they’re in the right place, we can provide a much more detailed notification. 15 Then, once you’ve navigated to the correct location, the repetition of the icon ties together the relationship between the navigation icons and the notification on the page.16

Screenshot illustrating how the navigation and relevant notifications all use the same icon. — 16 By carrying the icon through the navigation and down to the alert, people have a visual cue to help them recognize the relationship between the alert and notification.

At one point, I explored the idea of having some sort of application inbox for collecting all of the alerts, but it never felt right because the alerts were out of the context of the problems to which they were referring. By using the alert icons, we avoid the extra inbox, link, and area of the application and focus on taking people directly to the problems so that they can fix them.

Bolted On

In some cases, the notifications were a sad afterthought for a specific scenario. Our worst offender was archived projects. When a project is archived, it’s still browsable and accessible, but nobody can’t comment or create new issues. With the old header, I just slapped our standard notification on and called it a day. It looked less like a reminder and more like an error. 17

Screenshot of the standard big yellow bar over the header to indicate an archived project. — 17 Slapping a big yellow bar on archived projects was a side effect of the one-size-fits-all notifications approach.

But with this new header, I was able to plan for archived projects from the start. Since the “New Issue” tab isn’t relevant for archived projects, it can be replaced by a more subtle “Archived” tab that can display details about the project and, if you’re an administrator, guide you to unarchiving it. 18

Screenshot of the new header with the 'New Issue' tab being replaced by an 'Archived' tab. — 18 The new header planned for accommodating archived projects from the get go. As a result, the design is much less obtrusive, and the information is much more useful.

Inconsistent & Inflexible

One of the biggest challenges with the alerts is that they share some key elements but are all unique due to various contexts, target audiences, desired actions, and content. So it becomes difficult to have a consistent framework for alerts and notifications while still maintaining flexibility. The previous approach was “flexible” only inasmuch as they fit into the design. They had been reduced to a bare minimum amount of visual elements, and there was little to no room for meaningful subtlety or variation.

With the new approach, I looked over the variety of notifications that we’d be using and designed a layout that was more flexible so that it could be adapted to different contexts while still feeling familiar to users regardless of where or how we used it. 19 The consistency aspect may sound like designing for design’s sake, but it is the consistency that creates familiarity and helps customers by providing an intuitive interaction model and visual design. Given that many notifications are tied to situations where something went wrong, providing a familiar guiding hand can help decrease anxiety around fixing the problem.

Screenshot showing the various editable parts of our notification framework. — 19 Designing a modular notification system from the ground up has not only improved the experience of using Sifter, but it's made it much faster for us to improve notifications by easily adapting a standard interface to different contexts.

They look better, and they’re easier for people to recognize and act on. It feels like an almost trivial detail, but once you start seeing them in the application and using them regularly, it feels so much easier to interact with.

It’s About Communication

Given their transient and dynamic nature, it’s easy to make notifications a lower priority. They aren’t always there, and they’re easy to forget about. Yet notifications are one of the key means of communicating with the people using software. Spending the extra time to ensure that they’re clear, succinct, and consistent makes software easier to use and understand when things go wrong.