...
- Figuring out which color related to which dataset confused her. She kept clicking them off and on to solidify which she thought was which.
- She didn't even notice the arrows next to the datasets on the sidebar.
- Other than those things everything is intuitive.
User 3:
This user is an MIT Research Fellow working with Boingo and IBM on the problem of constructing a WiFi network in Africa. This is the person who suggested the idea for the project, and a real user from our target population. Because he already knew about the problem and our project, we did not give him a briefing or task list.
We presented him with the website and asked him to use it just as he would to solve the real-life problem he's working on. In general, he found the interface very clean and learnable, a significant improvement over previously existing solutions.
Usability problems:
- Add more information without cluttering the interface (major): He said that the project is off to a good start, and the next step is to add more layers of information in a way that tells a story to the user, without requiring the user to filter through long lists of data sets. For example, when existing towers are clustered in a small area, the user would want to know when they were placed there and why. Adding this extra functionality is probably outside the scope of what was possible during the semester, as we did not have access to that type of data.
- Add New Tower button should be logically separated from filtering (minor): Because the button is outside of the Google Map, it may not be obvious to some users to click on the map to place a button. This is only a minor problem because adding a tower is very learnable after the first try. One possible solution, especially when there are more map-interactive features, would be to move the button to a "drawing toolbar" on the map itself.
- Pop-up info windows should show data for all layers (major): He wanted to know all information for a given location that they clicked on, not just for the top layer. For lower layers, it was impossible to see the info window without removing the upper layer first. Solving this problem may be potentially difficult within the Google API, as it may require querying the Fusion Tables database for intersecting regions.
- Map should include zoomed-out overlay map to show where the current view is on a map of the entire world or continent (major): For this user, it took a few seconds to realize where the map was zoomed into (South Africa). He said that it would be good to include a small map in the bottom right corner that the user can pan over to select different regions. This should be easy to solve - we think it's a built-in feature in the Google Maps API.
Reflection:
Through our iterative design process we learned that small details are important for the understanding and usability of our users. Things like menu word choice, color of datasets, and icons on new towers added a lot to the usability. In our first paper and computer prototypes there were a lot of questions about what exactly users are supposed to do with the different aspects of our design, however in the final that was clear to the testers. One important design decision we made was to use Google's API for the map interface, which definitely had benefits as well as risks. Though it made integrating with the rest of the interface and the backend more challenging, it was familiar to our users, which makes the interface more learnable. Overall, all of the choices we made along the way still make sense as they made implementation not too time consuming so that we could focus on the important small details.