Design Meeting With Kate

The Cluster team met with Kate, the course TA to discuss a few things.

The first thing on the agenda was to discuss our last assignment. There was some concern over the three tasks (easy, medium, and hard) that we outlined in our last report. The tasks that we have been using are very leading, such as "create a group and broadcast your location to that group." We need to abstract them to be more like "send out a location update to your co-workers" so as not to convey the action we expect to our users. There was even some talk of eliminating the first task, since it is so simple, though it might be useful to keep around since we will be making a few design changes. We have made the decision to add the "bar-hopping" task: You are heading out to the bars on the Ave tonight and want to use Cluster to update your location to a small subset of your buddies as you move from place to place. The idea is that this would involve setting up a group as well as updating location. Kate did point out that it will be difficult to mimic context when giving this task since the high fidelity prototype would have to resident on a laptop to be portable.

Kate also helped us arrive at the decision not to do a prototype of the web interface. Though we intend that Cluster in its fully implemented form would have a full web interface that would allow the user to sign up for the service and manipulate groups, all of this functionality is mirrored in the phone interface. This is enough to satisfactorily complete the assignment.

There is some question as to whether the users in our study actually know what information they were broadcasting. In our focus on the security issues that come with broadcasting location, we neglected to be sure that our users understood that their social networking profile information was visible at all times, and not just after they've pushed the big red button.

Another issue we covered today is the ambiguity we have in referring to "location." Are we talking about GPS coordinates, addresses, or names like "Tully's Coffee?" Furthermore, what is the difference between the user's "current location" within the application and their actual physical location? Where in the app does it make sense to display this information? We've already determined that they are separate concepts so how can we convey that to the user? Where does it make the most sense to do this without making them so far apart that the user cannot use the information effectively? These are questions we hope to address in re-designing for the high-fidelity prototype.

The last issue we talked about was the home screen. Danyel has suggested that we bring information to the home screen instead of using it simply for navigation. Kate agreed. She encouraged us to think about ways to put enough information on the page to convey what each section does without overloading the user. She suggested to using cues such as an ellipses (...) or a triangle arrow to suggest that there is more information. Other ways that come to mind are to give each section a 3D "elevated" look to convey to the user that each section is actually a button. As long as we provide the correct functionality when the user touches the screen, the idea of what each section does will still be conveyed. Of course, any design changes would still need to be tested to make sure this is the case.

Even though neither of the final two assignments involve any more user testing, we've decided to take on a few extra run-throughs to make sure we are covering our scenarios solidly.