Second Iteration of Prototype

For the creation of the final prototype we met over both Saturday and Sunday to complete the 3rd iteration. At this stage we had already completed some rough drawings, a paper prototype and heuristically reviewed the prototype. By the end of this final stage we intended to have the completed prototype and carried out a user observation of the prototype in use.

Refinement of Prototype

Before we began work on our individual areas of the prototype we discussed and quickly sketched some iterations of detailed functional elements of the system which we felt needed to be addressed. Below are sample images addressing the inbox cards and their functionality, how the inline calendar edit function would work, the events calendar edit panel and the reverse of the inbox card with additional functionality.

We then agreed on set of standards regarding button sizes states, sizes, input fields and the overall size of the various key areas of the email system so that we would have a common base to work from. We created a template that each team member could then use to size their individual elements against while working.

Prototype Sizing Template

Issues Addressed

Taking our ques from our heuristic analysis and class room review we addressed the following issues

Threaded Emails

The issues with threaded emails were relatively simple to correct. It required that we present the users with emails in a collapsed state with the most recent one left open, this made it easier to understand the chronological order of emails as well as reducing the amount of on screen clutter and the amount of scanning the user was forced to do.

Threaded Email Initial State

As part of this iteration we highlighted the active thread in the left panel so the user could easily see the mapping between the two. As well as this we moved some of the thread card functionality to the rear of the card, which could be accessed via three vertical dots. This functionality can be seen on Android devices as well as a horizontal version in Microsoft applications

Android 3 Dots
Thread Inbox States

Creating a New email

To fix the issue with creating a new email required that we completely scrap the new email dialogue window. Instead we replaced it with something which was closer to the standard conventions for creating an email.

Prototype 01- New Email Issue
Prototype 01- New Email Issue

We did this by moving all of the functionality in the dialogue into the area presented to user for composing an email. This involved moving, the subject, recipients and priority setting as well as the creation of groups and simplifying there actions.

New Email Redesign
Function Action
1 Subject None
2 Recipients Predictive text allows rapid entering of names
3 Create a group Create Group uses current recipients and the Subject for the group name
4 Priory Priority has one setting On or Off.

Adding and Editing Groups

The adding of Groups has already been discussed above. After a user has created a group which is named using subject of the email, the the list of recipients becomes a group  and the “The create Group ” button changes to an “Edit Group” button. (This functionality was accidentally left out of the video).


Correcting the issues with the calendar required two stages. Firstly the user would need to be able to see an option to easily create the calendar event in context, without interrupting the task of typing. Rather than letting the system launch the dialogue itself, as was previously envisaged. We would also need to provide a method whereby the user could easily edit the event, this would also need to be context.
The below screenshots show the in context creation and editing functionality

Calendar Event in context creation
Calendar Event in context edit
Calendar Event in context edit

The additional functionality to edit a calendar event is accessed through the event card within the email as can be seen in the above image. By clicking on the card the user is presented with a fly-out panel from the right hand side. In the original  iteration there was an over abundance of functionality, as can be seen below.

Prototype 1 Calendar Panel Event Management

With the second iteration much of this functionality was either removed, simplified or managed by the in context event creation, see below image. The calendar details would be pre-populated, with the user only needing to access this panel to create an event outside of email or to edit an existing event. The user can either chose to leave the calendar panel by using the “X” on the top right or by clicking the calendar tab.

Prototype 2 Calendar Panel Event Management

If the user chooses to update the calendar entry they are presented with the image below confirming the calendar event has been updated.

Prototype 2 Updated Calendar Event

As part of providing the user useful feedback from the system we also included the functionality whereby the user receives a notification when an event was due, this was in the form of a highlighted number (the number of notifications) on the calendar tab, see below image.

Prototype 2 Calendar Event Notification

By clicking the calendar tab the user is presented with the calendar panel in view mode. The panel contains a calendar view and a list of upcoming events in chronological order. They can choose to select an upcoming event and edit it, the email system will then present them with the calendar panel Event Management as discussed above.

Prototype 2 Calendar Panel View mode

Leave a Reply

Your email address will not be published.

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑