• The problem: The user must download 'secured versions' of business apps and be informed of progress. Administrators also needed a channel in which they could communicate to the end user about periodic updates, security settings, and other app changes.

    The solution: An in-app notification system, built from scratch with the purpose to keep continuous communication between the app, device, and user, without being annoying.

  • 1
    The Experience goals

    • User must locate and download the apps and be informed of progress

    • Keep the user’s feedback active while downloading apps, regardless if they navigate to different screens or away from the Bluebox app

    • Inform, but do not annoy

    • Group information whenever possible, again, inform but do not annoy

    • Display the Bluebox "securing" progress (This sounded like a great idea at first, but you'll learn why this is crossed out later...)

    • Offer a channel for administrators to communicate to the end user for future actions such as prompting to update a 'secured' app and other security changes.

  • 2
    Gathering requirements and Personas

    I worked with product management and engineering to scope out the understanding of the feature. I created this diagram to understand exactly, what different scenarios would come up and when the end user would get a notifications. This also uncovered the different notification types that needed to exist. Some were persistent and some were dismissible.

    From there I referenced our personas to tailor the flow to our users. Ensuring that the experience would be best for our users. I was mindful of how they typically may be busy and cannot be bombarded with inconvenient modals and popups but also ensured that business requirements were still met with persistent notifications.

    3
    Notifications in the app

    Designing what the navigation would look like inside of the Bluebox App. The end user can observe the progress and take the necessary actions to complete the prompt. They can continue to wait and take action or they can choose to swipe the notification away. In this example, I strived to inform, but not annoy.

    4
    Notifications on the device

    At all times, the user is presented with alerts in the notification drawer. This was most important if the user chose to navigate away from the Bluebox app all together. This was a typical user journey. The user is presented with information, but it's their choice to act upon it at their discretion. The alert would sit idle as a reminder until acted upon and can be dismissed. I also designed an alternate notification type that required the task to be completed, this particular notification cannot be dismissed from the drawer until the action is completed as described in the 'required apps' diagram.

    5
    NOTIFICATION GROUPING

    The assets were created for individual and multiple downloads. I wanted to ensure our messages did not flood the notification drawer if simultaneous progresses were running. This again was an attempt to stick with the goals to not annoy the user.

    6
    Trouble in design paradise

    I originally designed the assets for Google's latest Lollipop OS, which included white notification cards. As I worked with our Android developer, we discovered on non-Lollipop devices a discrepancy in asset size. Status icons would appear larger on Non-Lollipop because they were not encapsulated in the blue circle. The size difference in padding was a fine detail, but if we had used the same asset for Non-Lollipop devices, the asset would have been too large in size. We ended up creating a second set of assets, and iterated to ensure that the icons were properly sized for each OS.

  • 7
    Iterations

    The minimum viable product requirements for the multi download notifications began just as an overview progress bar. However, quickly feedback came back stating users needed more information to feel reassured as they were able to observe the progress of each individual app. I iterated and made improvements by adding percentages to indicate partial progress.

    Rarely, if ever, are things designed perfectly the first time around. Sometimes we get it right on the money, sometimes we can be way off. This is why it's important to iterate, because there's always something that can be improved. As a designer, I can still spot all the little imperfections that no one else can see, but it's also important to know when is good enough... at least until the next revision.

  • 8
    Other Usages

    Download flows were just the basis of the notifications. The notification would be utilized for many different channels and situations. In the above illustration is a demonstration of how a user would be prompted for an app update and the flows the user would encounter.