How to design for IoT smart battery dashboard
Background
I have been working in a British leading smart battery company designing and implementing UI for IoT (Internet of Things) batteries. Our digital dashboards target both consumers and business. This article is going to walk you through my redesign process for our consumer-orientated apps (both web and mobile) using a design system and note down my design decisions.
Is using the scientific terms and concept not user-centred in data visualisation?
The UI displays electricity readings from the cloud-connected meters installed with the batteries at users’ houses. The ultimate goal is to help users visualise, manage their electricity usage and savings. Unlike the business-faced dashboard, this UI is to serve individuals who purchased the smart batteries. Hereby there is always a debate on whether we should design the UI in the “Common sense” way, or we should present data in a scientific way which means accurate graphs and terms. It is an interesting decision that I am still exploring the answer. Here are some methods I tried.
Define why users use the product and what the technique restrictions are.
Two questions users are going to use this IoT product to find out:
- What is electricity doing in my house at the moment?
- How much I have saved by implementing a smart battery?
The first question in V1 was answered by the “real-time” data, and this is how we collect it: 4 meters send the reading data to the server. Being processed, the reading data and the calculations are displayed by UI has the current refresh rate optimised to every 5 minutes.
Although V1 UI called it “real-time”, it is actually the latest data within 5 mins. The fact that V1 UI chose to call it “real-time” because it fitted what users want better misled the users to think they can see the immediate update in their electricity change. Therefore, we decided to stick to the fact and explain the data’s update rate by putting the last update time stamp on the app.
The second question can be solved by displaying the result of savings and total costs in the dashboard. However, the function has not been developed at the moment. The V1 app solved it by displaying the historical energy usage and allowed users to calculate by themselves. To satisfy users, V1 made the interpretation by calculating the meter readings to get the electricity flows, so that people can see the details of the house consumption sources, grid usage or export, solar usage and battery charging source and usages. The meter reading and computer calculation can cause margin. V1 UI gathered all the flows in one positive stack bar chart, which means we needed at least 6 colours to display in one chart. If we would like to add new flows, the graph will look extremely busy and hard to interpret. Too many colours also potentially become hard for some people to identify. So we decided to split the detailed graph based on the 4 meter reading datasets.
V1 Historical data
Is the scientific way not a user-friendly way?
At the early stage, we gathered user feedback from the V1 app and observed the user flows. We also studied competitors and other existing IoT applications. The most important things to start with are understanding the user flows and our dataset. Based on the observations, we later looked for the pain points and sorted into what we can solve at this stage.
During the Observe stage, I noticed that people had a different understanding of the datasets and how to display. Internally, our main conflict was whether to visualise the data in the way that users find it easy to understand or the way that matches the scientific theories. For example, one way to split the unified stack bar was to split the 4 meter-reading data into different charts and use the positive/negative numbers to indicate the flow directions. To keep the consistency, we proposed to follow the Passive Sign Convention (https://en.wikipedia.org/wiki/Passive_sign_convention), which defines electric power flowing out of the circuit into an electrical component as positive, and power flowing into the circuit out of a component as negative. Our main concerns are that most users with no electrical engineering background may not necessarily hear about this term and the concept. As our competitors also do not have a consistent way of displaying data, it brought up a debate, should we proceed to use the convention?
No matter what rules we chose, the products have to stick to it across the platforms. Therefore we will need an internal agreement across the team. The benefits of sticking to the scientific way are:
- Users who know the concept can interpret the data easily and will not complain that the visualisation is not correct.
- Users who would like to learn from our apps can learn the knowledge and have a scientific way to interpret their electricity usage.
- Negative (-) and positive (+) signs are shorter and more graphic than texts like Discharging and charging when representing the flow direction, like icons. Users who do not know the concept need to learn at the beginning. For experienced users, it can be quicker to look at the sign to tell that data node is giving or receiving electricity rather than reading words like “discharging/charging” or “import/export”.
The withdraws are not overlooked, we are aware that users who cannot understand the sign and are not happy to learn the concept will not understand the sign and therefore disagree with the whole data visualization. We currently do not know the percentage of these users. According to the user testing interviews, our sample users were able to understand the signs or quickly pick up the knowledge. Thus we made the conclusion that as long as the visualisation is consistent, it is simple enough to earn by our target users. At the moment, the company decided to go for the options that are “more friendly” to the new users, which means the Passive Signal Convention is temporarily not applied. We will review the option in the near future and make the necessary iterations, also any comments and thoughts on this point are welcome.
Design system and component library — the key to the consistency and efficiency
There was a noticeable inconsistency between the mobile app and the web app in the V1 app. The colours varied from different platforms and the icons had different widths of strokes. Some icons were outlined while the rest were filled. The way data displayed was different across the platforms. As mentioned previously, there was not a decision on whether to follow the scientific concept or do something that people do not need to learn, but without academic support. A holistic design system can improve these.
To summarise, the redesign work was carried out with the following goals.
Icons and colours
We went for the outlined icon style as it brought a light visual style. Our UI is mainly for data visualisation, thus the line icons will allow the graphs to stand out. We also wanted to make icons look more friendly to narrow the gap between technology and normal users.
When we look at the trendy UI design ideas online, we usually see the design for showing the statistics of sales or bank savings, the design tends to use one or two colours, each graph with different information might use the same colour. But in this case, data visualisation is the main goal of the UI and there are many graphs in different forms across apps. To keep them consistent, we decided to assign a certain colour to a term. According to some data visualisation research, in most of the cases, do keep the same colour for a specific item. Once the users associated the colours with the object, they would not need to repeatedly read each graph’s legends or instructions.
To define a reasonable colour palette for our main dataset, we collected all the colours in the V1 apps and referred to the existing brand guideline. At the same time, we spoke with stakeholders like the Leadership/Marketing team/BD team and our users to get the pros/cons of the current usage. We also took the accessibility into consideration throughout the whole design process. We set up a specific colour to represent a certain data point, some data points have subsets, like storage data has multiple batteries and each of them will have its graphs. At the moment, they will be assigned similar or even the same colour. There was an outstanding colour usage case that was mentioned by most of the stakeholders, which is using red (pink) to represent Grid. People pointed out that under the current colour scheme, pink was used also when there is a warning or error, therefore it potentially brought a negative association to Grid. We counted it as a key point to solve with our new colour scheme.
When developing the code, we usually have a concept called Extend. It means that we have a base with the essential attributes and functions, then we have instances extended from the base. In this way, codes can be reused and keep consistency. Based on this theory, in design, we also proposed a base of colours, designers should first pick the colours from the colour base to add sentimental value. When necessary, we can include more colours, but it has to be under a reasonable use case. In this way, we can keep our design system away from the redundant visual elements. As mentioned, we summarised the usage pattern from the existing platforms and mapped into the new colour scheme.
Particularly, we mapped the Brand Blue to Storage core value, Light yellow to Production (mainly solar at this stage). Violet is mapped to Grid to avoid the negative association of Grid. Turquoise is for Electric vehicles. We kept the Radical red and mapped into Consumption core value. Under our new colour scheme, error, warning and success were handled with the secondary colours, thus there will be no direct relationship between data visualisation and system state visual feedback and hence Grid is not associated with Negative anymore. Also, if some users still consider pink colour as a warning, then using it for Consumption will still make sense.
Page structures/Information logic — keep the most used features at the handy places
The best practices of the data visualisation showed that it was more comprehensible when one graph contains less information but obvious trend or comparison. The new design went for the structure of one Highlight page where users can find the latest and historical data from 4 meter-readings (Core values) and the latest data of batteries status.
As our interview session reflected, users tended to look at the latest Core value animation and the Power flows chart several times a day. Occasionally, they checked the energy usage and did some basic calculations on the savings by themselves. As the savings calculation is still under development, we kept the function for users to download the data and did some further analytics to give some insights into the usage summaries.
We first implemented the structure on the mobile app. We displayed the latest updated core value data and the battery states on the landing page so users can have an overview of what happens in the battery system and make sure that the system is working, which 85% users did several times a day. In the detailed page, we displayed the Power and Energy for the 4 core value nodes, also followed by breakdowns in the pie chart.
From users testing sessions, we learnt that almost all the users gave very positive feedback on UI updates, they appreciated the way we rearrange our data and app structure.
One of the suggestions that we received from more than 40% users was that they preferred to see the stack graph on the old version, to understand the usage breakdown changes overtime.
However, due to the accessibility concerns, we would like to display fewer data in one char. We tried to emphasize the user flow to research why users prefer to see this chart. Via some workshops and interviews, we found that hypothetically users would like to see the breakdowns over time, especially the household consumption breakdown. Therefore, on the web app, we made an improvement, to show the breakdown of the specific core value data in the stack graph on its own detailed page along with a doughnut chart to give a brief of the accumulative data within that time interval. Besides, over 90% of users thought it was more helpful to display the value in the doughnut chart legends rather than a percentage, which we included in our web app too.
Based on our experience on the mobile app, we applied the same page structure with the adjustments. We had the web app landed on the overview page so that they can see the animation and today’s overview directly. From there, if they’re interested, can also toggle different time interval units to see weekly/monthly overview graphs. The graphs were mostly based on the existing app, however, we added a breakdown chart for each detailed page, so that people can clearly find the sources of the electricity and usages with their proportion in the total amount.
3. Providing more interpretation and analysis gives more value than pure visualisation
One of the targets of the new app is to provide more interpretation of the data. Therefore, on the overview page, we also added a summary of today’s usage and comparison to yesterday’s total amount, so that users can quickly have an overview of the day.
Furthermore, in the detailed pages, other than the Power flows chart and Energy chart breakdowns, we also provided the data analysis to have a summary of the current time interval and a comparison to the previous interval because we found some tech-savvy users often did the calculation by themselves.
4. Consistent time intervals across the platforms
The mobile app and web had inconsistent time intervals. For example, on the mobile app we had [“today”, “yesterday”, “2 days” “3 days”] as real-time data’s interval, whereas for a web app, we had [“today”, “yesterday”, “2 days”, “3 days” and “4 days”] for real-time data. As for historical data, the interval was set as [“7 days”, “6 weeks” and “3 months“] for historical data, and [yesterday, last week and last month] for a general consumption report.
Legacy data intervals in the Mobile app and web app.
The data visualization is meant to give users a brief overview of the trend of the usage/generation within a period of time, thus we suggested to have a consistent and meaningful period as the interval. Rather than have a certain amount of days, we proposed to use day, week, month as units, to describe both real-time and historical data. Combining this proposal with the interpretation of we changed the information structure from time-based to subject-based. We proposed a highlight view as an overview and separate core value data into the detailed views. In both overview and detailed views, people could view the real-time data and historical data, in day/week/month range. To enhance UX, we also provided a customized time range on the web app. The time interval selection was made as a global variable, so the charts will be shown at the same time interval when the user clicks around the whole website.
Mobile:
Web:
Data intervals in the mobile app and web app in V2
Last but not least, we implemented responsive design, so the users can access with mobile phones or tablets if they prefer to use the web app.
Summary
In brief, this redesigns greatly improved the UI and the data display structure. In our design process, we learnt how to efficiently display necessary information and help users to understand their data. We had debated on whether to design the graphs in a scientific way or in a way that is closer to common sense. This is still under observation while we picked the later one and keep the consistency. As the hardware and technology develop, there will be new challenges and opportunities for improvement. We are excited to release the current version and prepare for the missions in the near future.