...
Task | User Interview and Observations | Learnability | Efficiency | Safety |
|---|---|---|---|---|
View friends |
|
|
|
|
Create a LocaShare |
|
|
|
|
Edit a LocaShare |
|
|
|
|
LocaShare overview | All the users looked at the home screen for a long time to figure out how | * Photo on home page does not | * Users mentioned that a lot of | * This task did not involve any updates |
Reflection:
...
We learned a great deal from the iterative design process we carried out for this project -- both about the difficulty of predicting what a user will think when using an interface, and about the difficulty of determining the essential features of an interface in order to achieve a minimal, highly usable design.
By testing our interface on different groups of users, we learned about different kinds of problems. In some cases we found that our usability problems were universal -- these were the things that were easiest to improve in subsequent iterations. In other cases, users representing different groups would like or dislike, understand or misunderstand exactly the same interface. This highlights the fact that it is very difficult to make an interface that is highly usable for many different user populations. In order to do as well as possible, it is important to mitigate worst-case misunderstandings of the interface. When the goal is to support a wide variety of users, the best solution often involves sacrificing efficiency for learnability.
Turning now to the lessons learned about our own perspectives on the design process, it was rather profound to observe how these changed as we made design decisions. In particular, we tended to want to have many features, and our design decisions tended to be about which features to cut. Features that we thought of as absolutely necessary at the beginning were often cut, but we rarely missed them. Each such change required only a small mental reorientation concerning the capabilities of the system, and moved us closer to a minimal, highly usable design.
It took us a long time to realize what was essential about our system. One debate we had, for instance, was about the importance distinguishing the mobile phone contact list from the contact list within our system. Because of implementation constraints, we ultimately presented the user with a fixed list of contacts. Although in a deployed product it would be absolutely essential to maintain such a distinction, for the purposes of this project as a study of one user interface, this turned out to be a useful simplification in one part of a relatively complex system. If we had it to do over again, we would have focused our discussions and attention much earlier in the game on the essential user interface principles that we were hoping to test. The tendency was to think about building a fully-featured, fully-functional real-world system, but many of the features we were thinking about were just not worth the time within the scope of the project. This lesson also applies more generally -- in the scope of any project with limited time and limited resources it is important not to divert resources to non-essential features. Just as was the case for this project as a class project, when considering a project which really is for deployment, there are levels of support and interfaces which seem important or at least highly tempting, and it is critical to prioritize and cut out everything non-essential. This is both in order to finish the project on time, and to achieve usability through minimalism
...
.