Low Fidelity Prototypes

To explore the initial the direction of design patterns for the three deliverables, and the scope of requirements, I made a a series of low-fidelity wireframes. These functioned as explorations of layout and as a tool to visualize the user journey and workflow, rather than as a blueprint for the final design.

Discovery of New Requirements

In creating the low-fidelity wireframes, I quickly discovered that the list of three deliverables would need to be further clarified and expanded.

One of the first things I found was the single-page messaging center envisioned by the Product team needed to be built out into a more robust feature, like a traditional inbox. The messaging center would require filtering and sorting capabilities, the ability to archive messages, differentiate read and unread messages, and dedicated pages for each message to view the full content.

Implementing the Product team’s requirement for five different color-coded message types created something of an overwhelming rainbow of messages in the Inbox. To mitigate this, we suggested a streamlining of the color-coded system, and created badges for each message type using only three colors: red for urgent / critical messages, yellow for important messages and warnings that were not critical, and blue for everything else. We would differentiate action items from non-action items with an icon. In addition to an icon and color differentiation, the badges also displayed the message type in a text title to enable accessibility and comply with WCAG and VGAR standards. The content of the message subject line provides further context to describe message types.

Several message types required a follow-up action. Some urgent / critical messages would require an immediate action, while other action items did not. Messages that were not urgent / critical but required a follow-up action would be presented as a notification in the user’s Inbox and in the Quick-View Tray. Urgent or critical messages requiring immediate action would be presented as a system-wide alert, in addition to a notification in the user’s Inbox and Quick-View Tray.

All action item messages would display a link for the user to navigate to the relevant section of the platform to perform the required action.

We suggested to the Product Team to create new user stories for each new requirement, and to deliver the scope of the design requirements in two phases, each phase lasting one two-week sprint.

Phase I would deliver an MVP version of the Quick-View Tray, System-Wide Alerts, and the Inbox, with only informative messages available in the Inbox. In Phase I, messages would not be able to be opened and read, only the subject line is viewable. Therefore, there are no “read” or “unread” messages — these would be built during Phase II. The only action available for messages would be to archive them.

Phase II would flesh out each of these features with more specific message types: urgent notifications, warnings, and actionable items, with subsequent follow-up notifications if required actions were left unperformed. Messages could be opened and read on a dedicated message page, and the user would be able to filter “read” and “unread” messages, as well as filtering by message type (critical / urgent, action items, informative).

Usability Testing

To validate the designs, I conducted several usability tests on the UserTesting.com platform.

In the Phase I sprint, I conducted tests to confirm user’s understanding of the navigation system within the Inbox, their perception of icons within the Quick-View Tray, and their comprehension of the System-Wide Alerts.

Later, in the Phase II sprint, I tested the designs for user’s comprehension of the different types of messages, the usability of links for action items, and reminder messages for actions left unperformed.

In the tests, users performed a series of actions, and gave feedback on their ability to complete those actions and their perception of how their actions affected the interface. Users were also invited to contribute any additional thoughts, feelings, or opinions of their interactions.

For each test, I recruited 4-6 participants. For all tests, I was pleased to find that the participants were able to complete all actions asked of them, and consistently gave feedback that the designs were straightforward and intuitive to use. There was some variation on the users’s methods used to navigate through the workflow — for example, some users would click on the “see all” link in the Quick-View Tray to get to the Inbox, while others used the Message Inbox link in the masthead navigation bar. Within the Inbox, some users would click on the left-hand navigation to view only Action Item messages, while others used the filter feature. This behavior was predicted; I intentionally built navigation redundancy into the design.

The usability test results not only validated my designs, but also helped lead to the quick adaptation of the new design components to the Crate library.

Hand-Off to Engineering

Two hand-offs occurred, at the end of each phase. In general, hand-off went smoothly. I walked the engineering team through each of the screens I rendered in InVision, explained features, fielded questions and clarified details.

During the Phase I hand-off, there were some concerns around rules of how to display the number of new messages within the bell icon in the masthead navigation bar, so we decided to postpone adding that feature until the Phase II hand-off. For both hand-offs, I made sure that the Engineering team had what they needed from me and the Design team, and I made myself available for further questions and clarification.

Final Steps

Once the hand-off of Phase I was complete, I kept in contact with the Engineering team to provide additional design assistance, and to conduct quality testing on their code builds. Eventually, due to the COVID-19 epidemic, I had to hand off oversight of the project to another coworker who was employed full-time with ASIF.