...
Design
Overview
The overall structure of our application is similar to the one we initially envisioned when constructing our paper prototype. It is data-centric, with two dimensions of tabs controlling the information displayed in the main, split-pane interface. A graph is displayed in the top pane, with textual data and related actions (e.g. selling power, changing device settings) available in the bottom pane. Tabs across the top of the screen allow the user to change the source of the data shown: from consumption devices, generator devices, or from the power grid. Tabs along the left side of the screen allow the user to control the time interval for which data is shown. An earlier or later time period can be chosen by swiping across the graph, or by using the date pickers above the graph.
...
Paper Prototyping Feedback | Original Design | Change |
|---|---|---|
The original labels of some interface elements, such as the "device list" view, were unclear to users. We reconsidered the names of these elements, trying to improve their information scent. The new names we chose, such as "sorted device list" view, proved easier for users in later testing rounds to understand. | | |
While we had originally thought of power sales as an action belonging to the "grid" (now "pricing") tab, most users of the paper prototype looked for this feature under the "storage" (now "reserves") tab. We added a "sell power" button under the "storage" tab to increase the flexibility and learnability of the application. | | |
Many users were initially confused about what each graph represented. This emphasized the importance of having clearer and more prominent labels and legends for graph data, which we focused on including in our final implementation. | | |
Similarly, users either ignored the data snippets in each top tab, or were confused about what they represented. We added the word "currently" to each tab, which drew more attention to the snippets and clarified their meaning. | No photo available | |
...
The tablet screen is partitioned into multiple fragments. Some fragments provide inputs. For example, the MainTabFragment reports which function tab that user has selected: consumption devices, reserved power, or pricing information. TimeframeTagFragment TimeframeTabFragment reports which timeframe that user has selected: daily, monthly, or yearly.
...
Our third user is a male apartment resident with a roommate, also part of our targeted population. He had no existing knowledge of smart grid or smart meter technology. He was given the GR3 debriefing before the test, and was then asked to perform the same tasks as User 2, above.
The user commented that overall, our application seemed "solid" and "simple." The test elicited the following observations and comments:
- At first, the user thought that the green line in the graph represented a particular device. It took a while for him to realize that it actually represented the sum of all devices. Despite having realized this, he was momentarily confused about it again later in the test. It would be useful to have some kind of visual indicator (e.g. a bolder line) to show that this line is conceptually different from the ones which represent individual devices.
- After scheduling a transaction using the "sell power" button in the Reserves tab, the user was not sure how to view or change that transaction. While we had initially intended to switch to the Pricing tab when the "sell power" button was pressed, we currently pop up a transaction scheduler within the Reserves tab. This creates a visibility/feedback problem when the user schedules a transaction in this way, precisely because the results cannot immediately be seen or modified. Implementing our original idea to switch tabs would help with this problem.
- As with User 2, the user had difficulty discovering the graph's ability to be scrolled, commenting specifically on the lack of affordances for scrolling.
Reflection
Risk Assessment
...