The vision of the Smart City project is to create an application that monitors various events in the city. You can imagine this as monitoring urban furniture, monitoring energy consumption, evaluating savings or monitoring the condition of roads in the village, and more.
The goal of the project was to innovate and search for new business opportunities in the market.
The Smart City application was to help municipalities with energy management by monitoring the consumption of commodities in municipal buildings using IoT sensors, informing municipal management about events, and providing them with accurate information, which is necessary for decision-making when planning budgets.
What is the idea of Smart City about? You can see in the video board (CZ).
Mayor: Approves the budget, decides where to invest, and needs relevant data.
Official: Prepares documents for mayors, needs a tool to monitor consumption, recommends where to invest.
The current application was based on the displaying data and their subsequent aggregation through a commodity and a physical object, a building.
Unfortunately, apart from a few screens and an application that was being developed, I did not have anything in my hand that would help me understand the needs of users or the context of use.
I wanted to understand what the basic scenarios look like. After analysing the displayed data and knowledge from a team, which was a few months ahead, I narrowed down my thoughts into the following scenarios.
Another question was the definition of relationships and views of measured data. It can be a combination of three views that intertwined in the application:
Another interesting question was, how do I know where the mistake is when costs increase compared to the plan? Three parameters enter the relationship: an increase in the price of a commodity, a bad plan, an increase in consumption.
Because I had several hypotheses from the previous step and wanted to test how the current design works for users, so I went into the field together with the researcher. First, but the preparation.
I established the research goal as mapping users’ requirements for content and features and how important these are to them in their daily use. The target group was about ten people who were recruited by the agency according to mine screening criteria.
I also created research questions, wrote a research guide for a semi-structured interview, created an interactive prototype in Axure, where I, apart from current features, also included a new dashboard that displayed the plan/price/consumption relationship, see animation below.
After a month of visits to municipal authorities, the conclusions could be summarized in one word:
Yes, the application failed from the user's viewpoint.
* I present only the final recommendations, which I used in the following steps.
Back to the drawing board. The results of the research were not the only reason to take a step back. Due to the technical debt, further development of the application was almost impossible and at the same time, it was decided that the application should follow the company's brand.
We closed with the product owner, a new business analyst and a scrum master in the meeting room, where we built the base for a new backlog and reprioritized the scope.
After two days, we were shortlisted for the following topics:
* In this case study, I will only discuss the topic of "visualization of sensors" because it is the broadest topic.
Based on my knowledge from the research, I looked for answers to the questions:
I start to brainstorm and look for answers to questions. I move freely between the whiteboard and the sketch, depending on how fast I need or how exactly I need to capture the idea.
Similarly, I analysed all the questions and created different solutions to the same problem.
Because I wanted to make sure that users accepted the created design, I did another round of testing. I created a simple prototype in inVision and went to the users again.
Overall, understanding of the data as well as the usability of the application has improved. Users had access to all the data and were able to interpret them as needed.
As in the first test, aggregating data from buildings on the dashboard proved to be a problem.
Again, I dived into the topic of aggregations, which turned out to be a bigger problem than expected
In the physical world, the sensors can be connected in series or parallel. At the same time, one physical building can have multiple consumption points, which may or may not be equipped with sensors.
In the same way, I can measure only some buildings in the village and measure only the consumption of some commodities. The aggregation of consumption of such installed objects is at least misleading.
The user in the application does not need to know which places are measured because the data consumer is usually a different person than the one who installed the sensors.
If I do not measure all the entities at a given level, the aggregate number does not correspond to reality. And who would want to decide based on incomplete data?
I drop aggregations from the dashboard and set them aside as a topic for further application development. The dashboard will now serve as an overview of the objects I manage and their status (flood, fire, etc.).
Descope, descope, descope. There are many thoughts and ideas about what could be done. We only had three months to develop and test the MVP. Anything that did not fulfil the basic use-case had to go. After discussing with the team, we left the topic of data visualization:
See more Linkedin Medium