Before beginning the second iteration of the prototype, and the final push to our completed version, we underwent a classroom review as well as heuristic analysis of the prototype. Both these reviews allowed us to identify key issues which would need to be clearly identified in the next iteration.
Lecturer Feedback and Review
We presented or prototype to both Stefan and Andrew on Wednesday night in class and based on their reactions and comments we immediately realised we had some design issues which would need to be rectified.
Our choice of a dialogue box for creating a new email was initially seen as overly fussy and added a step to the process which on review could be removed. It is also did not take any ques from existing email systems for creating a new email.
The currently active email was not identified clearly enough. This lead to confusion as to what the user was looking at, also it is not an established norm to provide the user with the last active email or thread with all messages in the thread set to open.
New Groups & Events
There was no clear way to create a group of contacts from within the email, this forced the user out of their current task and moved them to a new screen. Also the event creation from within the email although capable of been initiated from the message area of the email, the user was unnecessarily moved to secondary panel on the right to complete this task.
The email thread was unclear as to its function and required a bit of explaining and it was felt that a review of the current state of the art would be needed.
Using the information we had gathered from our classroom review we began a Heuristic Analysis of the prototype using the following four heuristics from Jakob Nielsen’s 10 General Usability Heuristics (Nielsen, 1995)
- Consistency & Standards
- Flexibility & Efficiency of Use
- Error Prevention
- User Control & Freedom
Consistency & Standards
Our first major issue as regards consistency and standards was the initial screen, in our prototype we we had presented the user with the last conversation they had, with all messages expanded in threaded form. This caused confusion, as it is not how current email systems work and not how users understand them to behave. As pointed out by Nielsen, (1995)…
“Users spend most of their time on other sites. Thus, anything that is a convention and used on the majority of other sites will be burned into the users’ brains and you can only deviate from it on pain of major usability problems.”
These usability issues had clearly occurred. Not only was the initial opening state of the application confusing, but we had failed to highlight which was the currently selected email in the inbox on the left panel. Although these issues had caused a lot of confusion (and momentary panic for the team) these were easily addressed with some minor changes in the second iteration.
The second problem we faced was the creation of a new email. Not only was it not totally clear how to create a new email but we had also introduced a new dialog for the user when the new email button was clicked. Again this was a break from standard conventions, all of the information and functionality in the new dialogue window could easily have been moved to the central pain when creating an email.
Flexibility & Efficiency of Use
Our prototype suffered in a few areas regarding this heuristic. In the case of the frequent action of creating groups, a pain point identified in our research we had only provided the option to create groups via the new email dialog (see above images), clearly these are two separate tasks. There is no way to edit or create groups outside this dialog.
A second issue was that of creating an event, although we provided for the functionality of creating an event while writing an email we did not provide the option for the more advanced user to customise or edit the event directly from the email, which meant the user must navigate to the event panel, find the event and then edit it.
In the case of error prevention we became aware of the fact that the cards in the inbox representing email threads had icons that sat extremely close to each other making it possible for the user to mistakenly delete an email when they actually wanted to pin it. In effect this is equivalent to the accidental deployment of an ejector seat as described in Cooper (2014)
A second issue which was identified was the failure to highlight the currently selected email, which could introduce user frustration as they tried to map the currently open email with the email card in the inbox. This poor mapping between controls and the things they effect was forcing the user to have to think about the relationship, breaking the current train of thought (Cooper et al. 2014).
User Control & Freedom
User control and freedom issues where similar to Flexibility & Efficiency of Use issues and centred around the creation of groups and events. Users had no way of easily editing or deleting groups and where forced to access the right hand panel to edit events. This panel was overlay complex and had unnecessary features which could have been automatically filled by the system.