Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Users had trouble discnering which of the 3 Add buttons to use for specific tasks. The one located in the Shopping List area was readily apparent, however, the ones on the side bar and calendar were not as intuitive as we would have liked. Additionally, users had trouble with the quick-add vs. regular-add feature of our prototype which depended on clicking certain areas of the button itself. Users typically had trouble finding the regular-add feature and discerning the difference between the two different functionalities. When adding events straight to the calendar, they desired to just click on the appropriate location on the calendar instead of clicking the calendar "Add" button. When the regular add button appears, a couple of users were unsure how to exit the screen, so instead they just added an event and deleted it retroactively. Along a similar issue, it was not apparently how to remove items from the Shopping List section. Lastly, users did not readily grasp the priority icon within the Shopping List or what the shopping cart icon's purpose was. This icon was supposed to represent that someone was out shopping for that item, but this proved to be very non-intuitive to the users and none of them understood that affordance. Many of the issues that we saw were a function of the limitations of a paper prototype as compared to a digital prototype with more obvious clickable areas and hover-over capabilities. A few others, such as the shopping cart icon, are learnability issues that will need to be re-worked into a more intuitive design.

Prototype Iteration

To be continued...

...

At a high-level, our second iteration was a tightening up of the first iteration. We added a large digital clock to the top of the page for a couple of reason. The first being that is was simpler from a testing perspective to say that we were at a specific time to fit with our tasks. Secondly, it was a feature that we had talked about putting into the design because we wanted our users to easily tell what time it was without having to shift focus from the site. Somehow in making the paper prototype, we simply forgot to add this feature. Additionally, we changed the manner in which a user adds a panel/quick-add button to the side-bar. Initially, the user had to click an edit button underneath the side-bar to add. However, users were not sure if that would edit the entire page. With our second iteration, we added an explicit add button to the bottom of the side-bar which removed this hesitation. When adding items to the calendar, users wanted to click on the calendar itself to add. In our first iteration, it was not a feature we had thought of having. In our second, we allowed for this functionality to retain external consistency with other calendar applications. With our second iteration, we were able to resolve most usability issues except for one. We have a Shopping List section where each item can have a shopping cart icon. This was intended to tell users that it was being purchased by someone already, which was not readily apparent to any of our users. For our second iteration, we removed the shopping cart icon altogether in favor of particular person's name, but this did not make the feature any more understandable to the user.

Studio Commentary Responses

  • Use intermediate checkmarks for shopping list
    This is actually what we did with our paper prototype, but it was still not very clear to the user what an intermediate checkmark meant. Some thought it meant that an item was complete, but just not cleared from the list; others simply had no idea.
  • Shopping Cart icon issues may disappear in higher fidelity prototypes
    Hopefully, this will be the case, but we are not entirely convinced of this issue disappearing. Because we are using a shopping car icon, people may think of our shopping list section similarly to how Shopping Carts are used in online shopping sites. However, the two designs are not the same so we run into an issue of breaking external consistency. We still like the concept of having some kind of indicator that someone is responsible for a particular shopping list item. Thus, we will make a strong effort to clarify this feature in future iterations.
  • Email messages to people about shopping list updates
    This is a feature that our group has considered using but with SMS messages as opposed to emails since an SMS can potentially convey information about a shopping list update in a fast manner. Additionally, we can potentially use a reply message to confirm that a person is getting or already purchased a particular shopping list item, and update the webpage accordingly.
  • Add comments to events
    In our current design, users have the ability to add notes to a particular item. Using comments would be another approach to this idea since it would relate a specific user to a specific comment. This could be a very useful feature down the line, but, at the moment, is not vital to user goals. As such, this may or may not be implemented in our final design.
  • Different pages for navigation instead
    When we designed our main webpage, we wanted to have our common use cases to be quickly and easily accessible because our users do not want to spend a lot of time on the webpage at any given visit. Multiple webpages would decrease the cognitive load for the user but at the cost of more searching and clicking, which was a route we are hesitant to take.
  • Is a quick-add button necessary?
    This feature isn't absolutely vital, however, we would like to include this feature for the same reason as above. We want our users to be able to add items to the calendar as quickly as possible. With our current design and after sign-in, a user needs only a single click to add to the calendar with a quick-add button. Thereafter, they can close the browser. This can greatly reduce the amount of time spent on the website giving parents/caretakers more reason to continue to use the site.