How To Design a Notification System
Do you have a usability problem? Stop yourself, don't open Sketch! In this article I'll tell you why.
During my time working with tech in Brazil I've encountered many people with different design sprint processes and I'm here to tell you my team's process and why it has worked for our company. I'll use the development of our notification system as an example.
We all know how annoying it can be when we get too many e-mails notifying us of things we need or needn't take action about. Especially on a CMP platform (content marketing platform)important e-mails might end up getting lost in between all the other stuff. So, we set out to discover how to decrease the amount of e-mails our customers were being bombarded with, to provide them with a more pleasing and less aggressive user experience of our platform's notification system.
1. Discover & Plan of Action
First I gathered all the relevant information already available to me from different sources related to the problem at hand. Then my team held a meeting where we looked at the information we had and made a plan of action. This plan of action usually consists of different user research methods chosen according to their need and the time we have to develop the solution. Always try and focus the discover research in the beginning stages of your sprint.
Having a plan of action for your discovery phase helps decrease the amount of time used with re-design of your solution.
Remember:
Never ask users what you could develop to make their life easier, they only know what they want, but not what they need.
Instead, observe them while they use your product, interview them to understand how they think, their problems and their frustrations. One of the most important things to keep in mind while doing user research is to show empathy towards your users, try to really put yourself in their shoes, and excercise your emotional inteligence.
2. Definition & Low-Fi
Once we have information enough about the problem and what the users want we can finally start sketching design solutions on paper. Low-fi paper prototypes are good, remember that. They are agile, easy to change and to iterate. They are specially useful when you want to make sure your design answers user requirements. If your design has more complex objects and structures than it might be a good idea to use a wireframing tool.
Below you can see some examples of the low fidelity wireframes I sketched.
At this stage you are ready to test your low-fi prototype to validate your initial ideas.
3. Low Fidelity Validation
What is a low-fi prototype?
"The fidelity of the prototype refers to how closely it matches the look-and-feel of the final system. Fidelity can vary in the areas of: Interactivity, Visuals, Content and commands" — Pernice, Kara. NNGroup.
Having low fidelity generally means that only some of the final feature's live system attributes are captured in the form of sketches, paper and wireframes.
Do I really need to test a low-fi prototype? If you want to fly, YES!
Testing your paper prototype allows you to get feedback from users and stakeholders at an early stage of the process and change what needs to be changed without taking very long time. You can basically trash it and make another one in very short time.
To test the notification system we got a couple people from the software engineering team together with some users and showed them the interactions. These meetings are where we get valuable feedback from all involved. Engineers tells us what tech restrictions could arise with such a solution, always trying to find an MVP (minimal viable product), in this case a 'MVF', minimal viable feature. If there's one thing I'd tell everyone to keep in mind while on a design sprint is this:
Remember to use the power of your software engineers to the fullest! They are precious throughout the whole process.
4. Hi-Fi & Grooming
With the feedback I got from testing the paper prototype I was able to… you guessed it!
You can open Sketch now.
Hi-Fi, not to be confused with Sci-Fi 👽, is the high fidelity version of your prototype and can be made once your low-fi prototype has been tested.
We needed a screen where we would show all the notification history. We made list which could be filtered by project, since the nature of our content is to be divided by different projects.
The notifications appears on the top right corner inside a red circle, and when there are no new notifications, we see a bell icon. Like you can see below.
To configure the notifications, each user can choose their own settings for which e-mails they want. This way they don't need to get so many e-mails for every little change there is on their content.
Once the screens are ready, we finish up the last details, document it on our shared doc with our engineers and we are ready to go through it during a Grooming session.
5. Wrapping up
Once we've had a grooming session with our engineers we can either have some re-work to do , or not. If there is re-work, we go back and solve those problems, preferably before the planning meeting. We have groomings every Thursday, and plannings on Mondays. Choosing these days is never an exact science, but it has worked for us so far. It gives the design team a good amount of time to make small design changes, and if the changes are too big we take them to the next design sprint and score them. Yes we have scores on our design team as well, but that's a topic for my next post!
Hope you enjoyed reading this article and that it was helpful for you and your team.
There's no right or wrong when it comes to a design sprint, this is the way that worked for us, if you have a different way of doing it let me know in the comments below, I'd love to hear new ideas and inputs about this.
