I began this project with the overall goal of improving the dashboard experience and ensuring the dashboard is doing what it’s intended to do— educate. However, I understood that our research goals needed to be a bit more specific in order to make our results more meaningful.
I collaborated with another intern to create our first draft of research goals and questions to make revisions for. We ended up going through three total drafts with our supervisor to hone in on a research goal that would generate thoughtful and meaningful results. Our initial research goals were either too specific on user interaction or too broad to really get anything meaningful out of it. After a few drafts, we settled with the following:
"How do users understand UC Davis' campus & building energy consumption using the CEED dashboard?"
One focus we wanted to have in this stage of research was understanding the parts-to-whole relationship when it came to users thinking about individual building energy use and campus wide energy use. Some questions we considered were:
To explore this mental model and better grasp how users are thinking about energy use, we included introductory questions regarding household energy use to gauge how they might apply this parts-to-whole relationship on a smaller scale.
Our finalized research plan involved introductory questions regarding household energy and then campus energy, followed by three tasks that we would evaluate. I conducted a total of 9 user testing sessions all done virtually over zoom calls.
After conducting our first round of testing, we compiled all of our data from each participant including pain points and direct quotations onto an affinity map to be organized into subgroups. After organizing these responses into groups, we started noticing some patterns and correlations that eventually led us to organizing pain points based on a specific user journey.
Based on the behavior we observed from users, their user journey with pain points is as follows:
I decided to make multiple variations of designs in the form of modules instead of a single column sidebar. This was done because people had trouble associating the sidebar to the map, so having them float on top of the map would make that association more clear.
With each module, I made at least two variations of them and included some new user interactions.
Updated prototype with modular interface
To try and help users understand the functions of the map filters slider, I prototyped a small animation to play when the page loads to exemplify the slider being activated and populating the map.
In testing, users did not know that the dropdown was interactable nor its functionality (left), so I prototyped two versions of this unit toggle to have it more explicitly signal what it does. The unit explanation is also moved to fit into the same section as the button so it is more closely associated.
I wanted to experiment between two newer versions of the map filter interactions being in their own “module”. In addition, I experimented with including the map settings in the same section which I ended up changing when we did user testing.
.jpg)
The interaction to toggle the map showing Green buildings on campus was often overlooked in testing due to its placement and the function of the button was different than the other interactions with the map so I prototyped buttons to be placed in the bottom right corner of the map instead of in the sidebar.
CEED was originally created for engineers and only later was made more user friendly for a broader audience. However, one thing that the original designers didn’t anticipate was that many users were left hanging seeing that they didn’t know what to do with this technical information. Many users were left questioning what part they play in the grand scheme of things and how they can limit energy usage, but were unable to find answers. In response to this, included a call to action for those who are interested to go to Trim The Waste, a website from our same department that tells users exactly how they can help.
Since I did not want this to be the sole focus of the sidebar and more so something to notice after interacting with the website, I didn’t want it to stand out too much to draw attention away from the other modules. I did not conduct testing on this and ended up choosing the top right option.
"What does this mean to me?"
- Yongqi Q.
"What do I do with this information?"
- Rochelle D.
Similarly with previous testing, I curated five tasks for users to complete that test the functionality and usability of the prototyped interactions. This testing featured a type of A/B testing where users performed a task with one version of a feature and then the next. Here, I narrowed each feature to two versions to compare. To eliminate bias, I separated participants into two groups to see different versions in different orders.
When considering each UI feature in terms of ease and affordance, the following versions were preferred:
After testing, I saw that there was no significant difference in how often users interacted with the slider whether or not they saw the starting animation. Users noted that their attention was instead drawn to the map which led them to ignore the slider.
"...this made more sense and also visually is easier on the eyes"
- Rochelle D.
Although there was a preferred version of the feature, there was still some confusion on the units themselves and the relationship between the units. After consulting with my project manager, we decided it would be best to replace this feature as a whole with a map key because the unit change was only added to CEED as a request from an engineer.
.jpg)
"...it's very clear to me, without even having to hover I can remove these" - Yongqi K.
"...this feels more like a filter"
- Daniel I
.jpg)
"...I know only green buildings are showing up" - John G.
.jpg)
After this round of testing, I wanted to continue iterating solutions as we still encountered some confusion especially with the Map Setting section in terms of users struggling to understand the unit conversions and the relationship between the units and the map changes that occurred when interacting with it.
As a result, we decided that it may be a better option to remove the map setting section in general as it was only initially implemented by a single request from an engineer. Instead, I wanted to explore the idea of a map key, something that users in testing seemed to instinctively look for when first looking at the map. In addition, I wanted to include an in-depth onboarding to help users understand the units, the map, and the key.
.jpg)
.jpg)
This project was extended into the Fall so I am still in the process of iterating the solutions for the key and onboarding sequence. One possible next step would be to do some further testing on whether or not the removal of the Map Settings section will make a difference for user's initial interpretation of the map, and whether or not the added key and onboarding sequence helps with understanding.
Once these changes are finalized, the handover to the development team will ensue and we may conduct further testing with the fully functional product.
Although this project is not yet complete, I have learned so much about the design process and working in a design team throughout the Summer and I have witnessed so much positive change in our product since we first started.
While I have done user research before in previous projects, this project involved a level of depth and focus towards research that I’ve never done before. Due to time constraints and other limiting factors for previous projects, user research often involved things like surveys or a few interviews with users. As a result, I didn’t have too much experience doing more in-depth research and user testing as I’ve done for this project. In creating our research plan for this project, I went through two drafts with my project manager to really understand the goals and intentions for the research we wanted to conduct. It was only by the third draft that I realized the importance of being intentional and selective about the types of research to conduct and interview questions to ask.
Another important takeaway from this experience was being aware of and preventing bias in research. While I had a general understanding of eliminating bias through research courses and previous projects, I still found myself making leading questions in the early stages of drafting the research plan. In addition, I learned that we as researchers can extract very interesting information by asking questions that are related to the topics we want to directly research and can better clarify user mental models. In our first round of user testing, we started asking about their thoughts on energy in the home, later discovering trends in how they think about energy consumption with housemates in comparison to energy consumption with different buildings on campus.
When ideation and prototyping features to address certain pain points, there were many instances where our team was deciding between multiple versions of the same feature. There was never a right or wrong answer from us as designers, so it was really important for us to test with more users to see which versions performed better in certain scenarios.
In this project I worked alongside the developers for the website at every step of the design process to ensure that we were all familiar with what was going on with CEED and that all the features and interactions ideated were feasible from a developer perspective. Many conversations were held during this process in refining the details of interactions and adjusting accordingly based on our timeline and capabilities.
