For the iterative design phase we had some key pain points which needed to be dealt with as well as the integration of various desirable functionality which would aid users in achieving their goals. We needed to come up with a general idea of how we would tackle these issues and ensure that key tasks and goals where addressed before moving to our first iteration of the paper prototype.
Choices we made
Based on research outlined in previous posts and literature reviews we decided to remove certain existing functionality, add additional functionality and redesign the overall interface of the current Blackboard email system to better match the users conceptual model of how an email system should function.
Removal of Two Steps
We removed the two initial steps when creating an email on Blackboard Learn. Based on the user observations these had caused considerable confusion. Not only had these steps added unnecessarily to the cognitive load of the user but it removed this same functionality where it would normally be found when composing an email. Users were were also prevented from being able to create groups, access groups or add recipients while composing an email.
Integration of Calendar
The ability to be able to add calendar events while within the email system was one of the pieces of functionality which survey respondents had listed as desirable to have. Reviews of existing email clients such as Microsoft Outlook and Thunderbird shows that this functionality is well established.
As part of the desired functionality identified in our research the addition of an inbox and the ability to view threaded conversations rated quite highly. We decided to enable this functionality jointly, providing the ability to view thread conversations through access via the thread root in the left hand panel, and to then allow the user to view emails as a threaded conversation or as individual emails. This functionality is a feature of many email clients such as Google Gmail, Microsoft Outlook and Mozilla Thunderbird. Threaded conversations allow users more easily find and access messages as well as find related messages, track backwards through a conversation and quickly identify conversation status. (Whittaker et al., 2011). Conversational threading also provides provides for less inbox clutter through the organisation of conversations via the root message as well as making the chronological order of messages clear (Whittaker, 1996; Kerr, 2003).
Integration of Documents
Although part of our secondary scenario and also identified in the user survey as desirable we felt due to time constraints that it was not feasible to tackle this additional functionality in a meaningful way. We did add the option as a tab similar to the calendar, suggesting that it would be functionally similar in manner to the calendar.
First iteration of prototype
Before we began our brainstorming session to kick of the first iteration of the prototype we undertook some secondary research and recorded it using a Figma board .We looked not just at email clients but various user interfaces and layouts such as Googles Material, Microsoft Xbox , Facebook Messenger and various others. Although we would not actually reach the visual design phase we felt it was useful to have a collective idea of how the email system might look. We felt that a minimalist look similar to Googles Materiel would be suitable as it fitted or idea of a paired down email system, the fact we would not actually be implementing the design made the further researching of supporting material a little redundant.
For the initial brain storming stage we took one hour to each separately come up with quick prototype sketches as to how we envisioned the new email application. Below are some examples of the results.
Of the three prototypes we settled on Maria’s version as it addressed all of the issues succinctly and allowed the user preform all the various tasks without having to move the user to another screen. It was also the strongest prototype as regards addressing the navigation of threaded emails. Although we did use research data to make our decision a certain element of the decision for myself personally, was based on gut feeling and Maria’s was the only prototype that spoke strongly enough.
Before moving to the task of building the prototype we made a list of all the previously identified tasks and functions so that we could easily reference them while designing the prototype.
The proportions for the the prototype were roughly 30% x 70% x (35%) , with the right column remaining hidden while not in use. We felt that this was most appropriate as it allowed for a large central panel for the reading of emails, while providing enough space for core navigation on the left and secondary navigation and functionality on the right in the hidden panel, which could be accessed via tabs.
After our first run through of the prototype we realised there were various area which needed improvement and some which had been missed entirely, which we quickly rectified with yellow stickies.