GR3 - Paper Prototyping

Briefing

You are a mother of three children, Andy, Barry, and Christine. Your husband Nick helps you drive your children to and from various afterschool activities. However, you can't always get them all everywhere they need to be between the two of you. So, you turn to PackPlanner to organize your Calendar and make it easy to contact other parents for help.

Scenario Tasks

1. View events on Wednesday, April 14th and Saturday, March 17th. Christine comes home with an invitation to Daisy's birthday party, and you'd like to update your calendar. You realize you have a conflict that day and will need to ask someone to help drive Christine to the party. Once you have received an answer, update your calendar to reflect this.

2. (a)You want to view Andy's soccer practice schedule. (b)You want to create a new schedule pertaining to your daughter's Drama Club.  Events you know of are Theatre Rehearsal at 2-4:30pm, Dance Coordinator at 11-12:30pm, and Advisor Meeting at 9-10am. (c)Share the new schedule with your neighbor Elaine.

3. (a)You want to check if Billy, your son's friend, is on the Soccer Team activity group. (b)You want to create a new Activity Group, Gymnastics Team, that contains your daughter Christine and her two friends, Mary and Nancy.  (c)You want to delete Simpson from the Soccer Team.

4. You, Andy's parent, have already created a schedule for Andy's soccer team.  You want to set up a driving group with Jill, Mike, Phil and Tom to coordinate driving for the rest of the season.  After Jill, Mike, Phil and Tom respond with driving their driving availabilities, assign drivers for all the events in Andy's soccer schedule.   

Iteration 1

Observations

Prototype Iteration

Users encountered a problem when required to add a new event from the Calendar view. User 2 voiced that he looked for the new event button below the events listed for the day.

To fix this, the new event button was added to the end of the list of events, as it originally was in storyboard 3 of design 2. By having the button here, users will know that clicking the button will add an event to the currently viewed day.

When creating an event, User 1 wanted to be able to see events already scheduled for that day, even though he did not need to see it for the task.

To fix this, a quick summary of the day's events could be added to the new event modal. This way, users can choose drivers more effectively while creating an event.

Some users hesitated while filling out the new event modal because they were unsure which fields they were required to fill out.

As a simple fix, asterisks can be added to each required field along with some text at the top like "* Indicates Required"

When asked to reach out for help, many users did the wrong thing. One user clicked the edit event button while another clicked "Driving Groups" in the top bar.

While part of this may be due to the difficulty of making paper things look clickable, these buttons should still be easier to see. One possible solution is adding a drop down arrow next to them.

Two of the users completely missed that there was a message field in the reach out for help modal.

The message field needs to be more prominent and will have a default message to make users aware.

User 2 and User 3 had trouble knowing which modal they were in or how to navigate back and forth between schedules and list of events within a schedule

We attempted to fix this by adding titles to modals and additional pages to let the user know which screen they were in. Clickable headers gave the option to view the previous page

Users 1 & 2 were not sure what buttons create and add did on the schedules and similar pages

We made buttons positioned properly and more descriptive such as "create schedule", "add event", "submit schedule" that adds additional support for the user.

Users had trouble sharing schedules or view them in their calendar once they were created

Immediately after a schedule is completed, a modal pops up asking if they want to share now or later. If the choose to do so later, they can click the "share" button next to a desired schedule. Also, a "view" button for each event will direct the user to their calendar to the day an event of the schedule is listed

Users had a hard time knowing where to look for shared schedules, or invites to groups/events. It wasn't clear that these items would all land in the inbox.

In addition to showing these invites/shares in the inbox, they are show in the relevant tab. So the schedules page will contain any shared schedule notifications, the activity groups page would contain invites to activity groups and so forth.

When completing the form to indicate driving availability for driving groups, users were not sure how to indicate driving availability.

The buttons that were located at the top middle of an event tile will be removed, and buttons saying "I can drive to" and "I can drive from" will be stacked in front of the event tile.

User 1 noted that he wanted an easier way to assign drivers within a driving group

An auto-assign button will be added to the page which will automatically assign drivers to all events based on which drivers indicated their availability.

Some users could not tell what the use of the driving counter on the driving group page. For example, User 1 tried to drag and drop the names to assign driving responsibilities.

The he counter section will be redrawn as its own tile to have better affordances. This will allow the user to better understand the use of the driving counter and use it effectively.

When attempting to assign drivers, most users tried clicking on the driver button on the driving group's page. This functionality was not considered, as a separate "edit drivers" page was created.

The edit drivers page will be removed, and users will manage drivers for events by clicking on the button within each event tile. This will create a simpler flow, and remove the complexity of another page. It is more efficient for a user to assign and edit drivers from within the driving groups page, rather than navigating to a new page.

Iteration 1 Photos

We chose to show this state because it is representative of many of our content creation screens. This interface utilizes modals in the creation of most objects, such as creating an event as seen above.  Using modals creates a simpler interface as it minimizes the number of screens seen by a user, and prevents the user from getting lost within the website by simplifying navigation.  By keeping the muted screen in the background during content creation, then returning to this screen after successfully creating an event, the user can be more efficient by navigating to fewer pages.  

This state shows what is viewed in the schedules tab. This is important because its a way for users to categorize events that would be assimilated in their calendar. Clicking a specified schedule will bring a user to a list of events, which can be easily added/deleted in list view. The use of headers/modals allows user to keep track where they are and what step in the process they are of creating/viewing schedules. Descriptive buttons also provide additional support for the users.

Specifying a driver to and from an event is a key feature of this interface.  By showing that one or two drivers can be selected for each event, it allows for additional functionality for users.  The use of pop ups and drop down windows allow for the user to remian on the same page when selecting drivers.  A count of previous drivers selected helps support and guide the users.

Iteration 2

Observations

Prototype Iteration

User 1 asked if tabs will be highlighted during tutorial

We will show verification with highlighted tabs or borders representing which tab is being described in the tutorial.

User 3 felt that going through the initial tutorial was natural and straight forward. Easily walked through tutorial without many questions.

We will continue to make the tutorial straight forward and conduct a step-by-step process to ensure simplicity and optimize usability

User 1, when selecting attendees, wondered if multiple people that are added will be stacked on top of each other below the field or fill in order on a line. Also wonders if this is covered up by pop-ups or drop-downs.

When using drop downs, we will check that when the user moves outside the drop down, it will no longer be viewable.  Also, we will check what information is blocked from a drop down and if it influences any selections for remaining fields in the screen.

User 1 and 3 noticed asterisks for mandatory info when filling in event details

We will keep asterisks as a way to represent information that needs to be filled out.  Still thinking if there are only other clear ways to notify mandatory information.

When User 1 was finding drivers, first scanned the top toolbar since it looked permanent and natural place to look. Eventually found "reach out" in specified event.

No change to original design, however, perhaps a shortcut to reaching out to drivers on the toolbar rather than reaching out to a driver for specific event.

User 1 questioned if there was verification when finally selecting a driver (such as no longer highlighted, etc.)

When a user selects a driver, there will be confirmation that the driver is set (whether its highlighting, changing background color, etc.)

All users wondered how to get back to previous screen viewing all schedules from current soccer team schedule

There will be a back button on the current screen to get back to the main schedules tab.

It was unclear for users where to check for invitations. They naturally headed to the inbox, rather than the schedules page. It wasn't clear from the design that the schedules page had a pending invitation/request.

There will be a red number count on top of the schedules tab to distinguish between messages that are in your inbox and schedules that are requesting to be shared.

Users 1 and 3 think drag and drop drivers would be a good idea.

We are thinking of doing drag and drop for drivers, but not sure how to implement it just yet.  Perhaps progress will be made in the computer prototype.

All users were were unclear about the distinction between driving groups and activity groups.

In progress of getting rid of activity groups and rather link people together based on shared schedules/events or carpools.

User 1 and 2 were not sure what modals were, however, User 3 was familiar with modals

Modals are an effective way to keep most of the information viewable on the screen without transitioning between multiple pages.

User 2 preferred to type information into event fields rather than using drop downs

Parsing user input might potentially be a hard problem to solve (since the user may enter times in one of a gazillion different formats) so perhaps it should be made obvious that it's only possible to pick times from a modal, or otherwise some other simple means of input.

Users had a hard time figuring out which events may be conflicting for picking up/dropping off/driving.

It would be beneficial in the calendar page to show an overview of the user's activities for the day in terms of driving, in chronological order, in order to discern where any conflicts may arise. We can't figure this out strictly algorithmically because say, dropping two kids off to two separate events at the same time needn't conflict if you can drop them off on time along the way.

It wasn't entirely obvious where one had to click in order to edit an event. The single "pencil" button (to indicate editing) wasn't obvious enough in the design.

Make clicking on the event anywhere pop up a quick-edit modal.

User 3 had a hard time looking for a kid's particular schedule. Tried clicking the kid's name in the calendar to see his events, rather than going to the schedules section.

In production, the way you find out that you have a schedule invite is that the respective tab will show a badge with the number of notifications, so the user will naturally know to click on that tab.

Users 1 and 2 wondered if there was a way to filter between selecting groups and individual people.

The drop-down box should have a "pick a person or group" text hint to indicate the multiple functionality.

User 2 noticed that he can simply alter and adjust message to clarify drivers he wants to reach out to

When reaching out to drivers, there should be a pre-filled message with the event info, or it should be such that the event info is automatically shared and when the driver accepts the request, it is added to his/her calendar too, and the event data is synced.

When User 2 wanted to edit an event by adding a driver, mistakenly clicked on event title rather than individual "to" and "from" drivers drop downs listed per event. Users 1 and 3 did not have this problem.

Clicking on the title should take one to the edit event page, where one should be able to edit drivers in any case.

Users found the task of manually assigning all of the drivers to a schedule tedious, and noted that an "auto assign" feature would be useful.

If we can figure it out, an auto-assign feature would be nice.

Model Change

One of the biggest problems our users had were knowing the difference between activity groups and driving groups and how they interacted with one another and with schedules. Every user encountered some sort of problem with this, and User 2 of Iteration 2 even commented that he really liked the website except for the confusion surrounding the different groups. So, we will be changing our model to simplify this process. Both activity groups and driving groups will no longer have their own tab at the top of the page, and they will not be separate from schedules. Instead, an activity group is the group of people subscribed to a schedule, and a driving group can be a subset of that group making a carpool for the events in that schedule. This will be easier for users to comprehend and will avoid confusion that could lead to frustration with the site.

Appendix A

All screens and popups used for iteration 1 can be seen here: http://bit.ly/YJFsYt

  • No labels

1 Comment

  1. Prototype: Photos: Clear and descriptive, covering interesting states of the system
    Iteration Changes: Clearly motivated and very thorough!

    Briefing & scenario tasks: Briefing: Clear and concise. I like how you motivated the use of the system by presenting the user with a problem.

    Tasks: High-level, and very interesting tasks.

    User testing observations: No. of users: 6. Good!
    Obserations: Very, very thorough, with each point motivating  the changes for the next iteration. It would have been good to identify the type of usability problem encountered, but the description in your prototype iteration column actually does make some comments about it, so good job!

    Wiki presentation: Good

    Overall: Excellent work, this is shaping up well.