Design and ship large features faster, part 2/2
This is part 2 of this article, where I go through how to design and ship a large feature in iterations so that you can deliver value to your users and get feedback early.
You can find part 1 here.
Iterating on your feature based on feedback
You shipped it, 20 nurses tested it, and not surprisingly you got some feedback. They found the feature useful, and they also have some constructive feedback on how this feature could be even better for them.
Let us look at the top three things they commented on:
- Too many notifications
- Make the notifications go away
- I don’t know that I have new notifications
After some digging and some user interviews, you come to the conclusion that these are four separate but interconnected issues, three of which you can solve by yourself. Let us try to unpack all of it.
Too many notifications
It turns out that the system is a little bit too eager to send notifications about events to nurses, this leads to notification fatigue, and consequently the nurses are starting to ignore the notifications.
Through user interviews, you should try to find out which notifications are important, and which can safely be omitted. Not every event needs to trigger a notification, and this is something you need your users and domain experts to help you prioritize.
This is an example where user feedback from testing involves all of the company, not just you as the designer. In this case, it is decided that the system will be tuned to give fewer notifications, and no further action is really needed from you as the designer. The system will simply send fewer notifications to the front-end.
Make the notifications go away
These are actually two separate issues. The first use case is that some nurses do not want to see notifications they have already interacted with. The second use case is that it is inconvenient to have to click on every notification to make it go from “read” to “unread”. Some notifications they simply do not need to or want to click, leaving them perpetually in a “new” state. We can therefore break this down to two enhancements to the notifications feature:
- Archive “read” notifications
- Mark notifications as “read”
I don’t know that I have new notifications
This is a big one. It turns out that you forgot to design an indicator for new notifications, and how many new notifications a user has. This is often done by putting a badge on the notification icon in the top bar, so you decide that is a good approach here as well, and you also decide to put the number of new/unread notifications in the badge.
Enhancements you have to design
The too many notifications problem will be taken care of by your PM and engineers after you have helped prioritize which events are important enough to notify the user. You are then left with these problems to tackle and deliver designs for:
- A way to mark notifications as read
- A way to archive notifications
- A way for the user to understand that they have new notifications, and how many
Marking notifications as read and archiving them
Together with your PM, you decide that only read notifications can be archived, but it is ok to mark all notifications as read. After this discussion, you decide that the best approach is to give the user a dropdown menu with more actions within the notifications panel. From this menu the user can do two things:
- Archive read notifications
- Mark all notifications as read
You decide on the word archive since this gives you the opportunity to later design an interaction for viewing all notifications including archived. If you chose the word “delete”, the user would probably expect that those notifications are gone forever.
Your next deliverable is therefore a dropdown menu that takes care of these two actions:
What you want to happen might seem obvious to you, but in this case, it is a good idea to again provide a detailed interaction design to the developers.
New notifications badge
You also need to deliver the design for the badge that tells the user how many notifications they have. This badge will reflect the number of unread notifications the user has.
To make sure this works for the cases where the user has a large number of notifications, you deliver a design for no notifications, 1 to 99 notifications, and the case where the user has more than 99 notifications. If you find that having more than 99 notifications happens often, you should probably revisit this entire feature, constantly having lots of unread notifications might be an indicator that this feature isn’t useful in its current design.
You’ve already delivered a design for where the notification icon lives in the app, so you only have to deliver an updated design for the notification icon.
You’ve iterated on the design based on user feedback, and you’ve improved the notification feature. Let us take a final look at the feature as a whole.
In this wireframe, we can see that the user has 3 unread notifications. They have a read notification that they can choose to archive, and they can also choose to mark all notifications as read. In order to clear all notifications, they can mark all as read, and then archive all of them.
What we haven’t done
There’s a lot we haven’t covered in this design or in this article, and some of the things we have ignored could be vital to the user experience.
These are just some of the things that should be paid more attention to:
Timestamps
How should they be displayed? For a first version it is probably good enough to display them as a date, but do you also need time? And how should you format the date? If you don’t design this you might get something like this from the developers:
2020.02.12 23:59:23
While this is accurate, it is not necessarily formatted in a way that is the most useful to the user. When designing timestamps think about what the time of the notification should tell the user. You could say things like “5 minutes ago”, “Yesterday”, and then use a date for notifications older than that. This requires much more design to cover all of the cases.
Visual design
All of the designs in this article are clearly wireframes. The best case is that you already have an established design system and templates that can be reused from other parts of the app, for instance for dropdown menus. In that case, this might be all you need to deliver to have a version of this feature that also fits the rest of the visual design of this system. If your feature contains lots of new elements, you will also have to properly design them so that this new feature doesn’t look out of place in your app.
Additional requirements
Should the user be allowed to set preferences for types of notifications? Perhaps they should be allowed to turn them off, or to snooze them? Perhaps you don’t need a badge for all notifications? If you look at a product like Slack, they have much more sophisticated ways and options to manage notifications.
Perhaps some users would like to search and filter their notifications?
The user can archive their notifications, but some might want to see the archived notifications, this could happen if they accidentally archive a notification they meant to read.
In the current design, the user has to either click a notification to mark it as read, and then navigate to the view that the notification is about, or mark all notifications as read. What if there is no associated action or view for some notifications? Some notifications might be purely informational, and how does the user then set it to “read”? You might need additional interactions for those kinds of notifications.
Checking in with the users again
- Was your design for notifications the right solution to a problem the users had?
- Has this feature solved their problem and hopefully made life easier for them?
These are important questions to ask, and you should follow up with your users after the feature has been live for a while to see that the assumptions you had were valid, and to see if there is anything you can do to facilitate an even better user experience.
You can also use analytics to see if the feature is being used. Are users clicking on the notifications icon? Are they clicking on notifications, or perhaps they just archive them all?
Conclusion and main takeaways
I’ve shown a way to think about larger features as independent components that can be designed and delivered to development independently in order to speed up the release of a feature.
I’ve used notifications as an example, but this could be applied to other types of features you need to release. For instance a shopping cart experience, organizing playlists, handling user preferences, or a messaging system between users.
It is important to keep the focus on delivering value to the user. Prioritize the parts of the feature that delivers value to the end-user, that way you can ship parts of the feature faster, get feedback, and iterate on your design.
A benefit of this approach is not only that you can deliver and ship parts of the feature incrementally, but also that you can easily split up the work between the designers on your team. If a small part of the feature is self-contained, for instance the notifications container, a junior designer or intern can work on that independently while a more experienced designer works on the overall experience together with the PM and the tech lead.
