A CoPilot Story (Pt 4): Designing Notifications
Continuing the story
A CoPilot Story Table Of Contents
2. The Product Creation Process and Designing Deploying Via A Docker Compose
4. Designing Notifications
5. Designing The Service & Application Catalogue
The following explains the design process around notifications. For more context it might be useful to read my colleague’s case study on designing the Activity Feed (coming soon) and my previous post on the design of Metrics.
Video Description
Defining Narrative
Problems arise in an application and a user will need to be notified of these issues.
This narrative is not concerned with how a user will set up these notifications; we are assuming that useful timely notifications have already been configured.
Key Performance Indicators (KPIs):
- The notifications must be noticeable so they grab the user’s attention
- The notifications should provide enough information that a user can understand on a high level what the notification is concerning, without having to delve any deeper
- The notifications should offer enough affordance so that a user will be able judge where they will be directed in the application before clicking
This narrative is relevant to all personas.
In a previous post we defined a narrative (sometimes called an epic in agile development) as a large body of work that could combine many user stories. A user story was defined as the smallest unit of work.
First Workshop
Coming together as a team we analysed the use cases and functionality that would be most important to our users. From this, combined with our initially defined KPIs, we identified that each notification would need:
- To be compact
- Have affordance
- Show frequency/time frame
- Show metric types (CPU, Latency etc)
Furthermore, we outlined, that a notification should convey information on:
- The notification’s context
- What caused the notification
- How the notification correlates with different services
- If there is a pattern
Second Workshop: Creating The Project Overview Page
Further collaborative discussions between both designers and engineers ensued after the previous workshop, where it was highlighted that the current designs for the dashboard were lacking in terms of not allowing metrics to be compared across different services at the same time; identified as vital when needing to debug as a result of notifications.
Therefore, the idea for a project metrics page was established. The initial idea for this was that it would be a “smorgasbord of metrics” that a user would be able to individually define and setup.
This idea for a project metrics page seemed promising, however we were uncertain how this new page would fit into the overall taxonomy and navigation of the existing product.
To try and solve this uncertainty, we set about conducting a comparative analysis between all the different locations that notifications would be presented in the portal: including this new project metrics page.
Initially we outlined five different locations that notifications could be displayed:
- Service & Instance List
- Header Callout
- Activity Feed
- Project Metrics
Next, we narrowed these locations down to three, due to the fact that the Header Callout would need to be persistent throughout the portal anyway and emails were out of scope for this stage of the project.
We then proceeded to conduct a more thorough understanding of the positive and negatives of the notifications in each of these locations.
Analysing Service & Instance List Notifications:
Analysing Activity Feed Notifications:
Analysing Project Metrics:
Upon conducting this analysis an interesting solution was starting to take shape; it was realised that a potential solution could be to merge both the Activity Feed and Project Metrics. As can be seen from the above, they both had complementary positives and negatives.
This concept would give the user the ability to be able to view the service metrics (on the Project Metrics page) in the context of other events across their application, as well as improving the functionality of the Activity Feed by improving the fidelity of the metrics that would previously have been limited to small thumbnail metrics somewhere in the feed.
Combining the Project Metrics and the Activity Feed gave birth to the new Project Overview Page
Third Workshop
From our initial sketches we had outlined a couple of flows from the notifications. Even though the new Project Overview was yet to be completely defined, it was important to envisage how this page would function in relation to the wider dashboard.
Additionally, although out of scope for this stage of the project, it was still important to consider the functionality of emails.
At this stage of the design process it also became important to narrow our definition of how the notifications would be triggered (designing setting up alerts occurred after our work on notifications).
We decided that notifications were to be separated by metric on a service, and then combined by threshold, and time frame/frequency. Therefore, a sample notification would be something like:
“NGINX CPU threshold A + B breached 47 times between 1/1/17 — 1/2/17”
In our initial designs, and as drawn in the sketch above, we had also envisaged a modal (or lightbox) appearing after a user clicks on a notification that presented the user with a choice to either delve into the notification on the Service & Instance List or the Project Overview page (quite adequately describing our low confidence in the Project Overview page at this point in our work).
However, we started to imagine the scenario where the new Project Overview page was the de-facto place where all notifications would direct the user.
In light of this scenario, the proposed user flow could be:
- User clicks on notification anywhere in CoPilot
- User arrives at the Project Overview page
- Notification is highlighted in Activity Feed
- The notification highlighted is at the last point in time the notification occurred, followed by all child events in the Activity Feed below this event (very similar to scaling in the Activity Feed).
- The highlighted notification provides a thumbnail metric of the event
- A Call To Action (CTA) allows the user to add a large scale metric into the metric area of the Project Overview
This thought experiment proved to very conducive so we set out to define how the Project Overview would work in this scenario:
- As the de-facto place where a user would arrive after clicking on a notification anywhere in the application, the user would arrive here with the notification they had just clicked expanded in the Activity Feed
- Clicking on a point in the large scale metrics in the left-hand metric area, would scroll the Activity Feed to that point in time (or closest point in time)
- Clicking an event in the Activity Feed would highlight this point in time on the large scale metrics
- When a master event is added as a large scale metric, from the Activity Feed, this event timescale would be highlighted along with the large scale metrics
- Timeline/skip links would be used at the top of the page to navigate to the large scale metrics
Furthermore, we began to outline how notifications would be dismissed throughout the application:
- All notifications persist in the callout and Activity Feed, however notifications are unhighlighted when a user either manually chooses to disable the highlight, or view the notification in relation to a large scale metric
- Clicking on notifications in the Service & Instance list view would dismiss these from view immediately (as well as directing the user to the Project Overview page)
- Clicking on a notification in the callout or Activity Feed will change its state between “unresolved” and “resolved”
Creating Prototype
As a result of the proposed concept flows above, the below prototypes were created to visualise this new flow in the context of the dashboard.
Clickthrough prototypes at this stage of the design process are illustrated below.
Presenting Internally
After the above prototypes were presented internally to the team, a couple of pieces of feedback were suggested specifically related to the Project Overview:
- There needed to be a way for users to be able to re-order their large scale metrics
- The skip links did not provide enough fine adjustment for the large scale metrics, for inspiration it was suggested to look at a similar component utilised on Google Maps:
First Design Iteration:
Taking the internal feedback onboard the below prototypes were created:
Presenting to Product Owner
After presenting all this work to the product owner the ideas were met with positive feedback and so we felt confident to move these designs into testing.
Design Iteration
Whilst organising the testing sessions we also had some time to inject some improved visual design into the Project Overview, with the final testing prototype embedded below:
Testing Sessions Feedback
The feedback from these sessions were as follows:
Service & Instance List View notifications:
- 6/6 users were monitored to have the notifications grab their attention
Header callout notifications:
- 6/6 users noticed when there were notifications present
Project Overview notifications:
- 5/6 users intuitively understood the relationship between the notifications shown on the Activity Feed and these notifications shown on the large scale metrics
- 5/6 users intuitively understood that clicking the thumbnail graph would add this as a large scale metric on the right hand side, however there were some confusions what would actually happen once they commenced this action
- 6/6 users were initially surprised that they arrived on this page when they clicked on a notification and it took them a couple of minutes to familiarise themselves with where they were and the functionality available to them
General:
- The timezone used and the european date format caused constant confusion
- The visualisation of the notifications in the metrics were a cause for confusion amongst most users and is addressed in the previous post describing the design of metrics.
- The reorder icons on the Project Overview page did not accurately describe the action a user could complete by clicking on them
Next Steps
Although this testing session for the notifications proves promising, the user feedback suggests the following improvements:
- Illustrations and more comprehensive educational components on the Project Overview page could communicate to users the functionality available to them on this page
- An easily accessible settings feature to be able to toggle date formats and time zones would increase the international use of these notifications (a prototype for this was subsequently created here).
A CoPilot Story Table Of Contents
2. The Product Creation Process and Designing Deploying Via A Docker Compose
4. Designing Notifications
