Smart City: Using HCD to redesign digital product

About

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.

How?

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).

End users

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.

My role

I joined the product team during the development phase of the first version of the product (proof of concept) and inherited the design from an external agency.
I worked on the project as the only designer. I handled the entire design process, from research to final design and delivery for the SCRUM team.
I helped organize the backlog, write user stories with the product owner and business analyst. During development, I addressed design changes with developers and answered their questions.

Constraints

Respect the company's brand manual.
The UI must scale. The customer can work with a hundred or thousand sensors.
Low development budget.
Based as much as possible on the original version of the inherited design.

1. Understanding the problem

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.

As mayor…

I want to see consumption so I can adjust the behaviour in buildings.
I want to see the execution of the budget so that I can ask the city council to increase the budget or adjust consumption.
I want to compare consumption with previous periods so I can evaluate the introduction of austerity measures.

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:

Place (village, building, sensor)
Commodity (electricity, gas, water, heat, air)
Unit (consumption, finance)

Three dimensions of AI place, commodity, unit.

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.

Three dimensions of problem price, plan, consumption.

2. User research

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.

Research target

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.

What are our results?

After a month of visits to municipal authorities, the conclusions could be summarized in one word:

Fail

Yes, the application failed from the user's viewpoint.

Users lacked data context. "For what period are the data?" or "From which buildings are the data displayed?" They asked.
We presented bad metrics. “Current consumption? Nobody cares about that. I’m interested only when there is a problem."
Usability errors. Most could not get to the detail of the building in the application.
The comparison of the price-consumption-plan relationship in the form of numbers with an arrow indicating a trend was hardly understood by anyone.
Users could not compare energy consumption with the previous period.

User's needs

Users are interested in measured metrics shown by longer periods, months, years, which they want to set up.
Support year-on-year comparisons on the same building Support comparisons of measured points with each other.
Support notifications that should alert all representatives of the hierarchy (mayor, official, technician) and send information about the status of the accident (new accident, resolved accident, end of the accident).

* I present only the final recommendations, which I used in the following steps.

User research outcomes — Analysing research outcomes

3. Redefining

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:

Visualization of data from sensors
Notifications
User management
White-labelling

* 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:

How do I display aggregations of data from individual objects?
How do I compare current consumption with previous periods or another place?
How do I display the consumption profile of the building?
How do I visualize budget consumption?

4. The first iteration

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.

What has changed?

I added a date filter to make it clear from which period the data is being displayed.
I allow the comparison of consumption with the previous period.
I add a dashboard with a commodity, where you can see the objects that are affected by consumption.
I do not use current consumption, but all data is related to the selected date filter.
I used a material design library to make it possible to meet the requirement for cheaper development. Developers then don't have to write UI components from scratch, but just reuse and modify them.
The visual design respects the brand manual. Company colours are used for the header, buttons and graphs, the rest UI elements uses shades of grey. This should make the application white-labelling easier.

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.

Exploration of budget burning and PoP comparison

The result of the second round of testing

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.

5. Second iteration

Again, I dived into the topic of aggregations, which turned out to be a bigger problem than expected

What is the root cause?

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.).

6. Packaging for development

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:

Basic dashboard with a map. If a notification is triggered in the building, it will be highlighted on the dashboard.
The user sees the budgets for energy and their drawing on the object.
The course of consumption and the status of individual sensors.
The amount of consumption and money that can be filtered by date.

7. Development

After hiring and onboarding developers, I gave them my full support and dealt with questions during their work. What is worth mentioning is our concept of responsive design.

By treating the UI design as a system and using material design elements, we could finetune the responsiveness of the application with the frontend developer, without having to have detailed designs.

We have saved time and money, on the definition of the UI for various resolutions, handover and review.

What did I learn?

Although I did decent research at the beginning, I would do it much broader, with thirty participants at least.

Apart from the final screens, I didn't have my design decisions and deliverables always ready to be shared. Sometimes it was difficult for me to explain the details in design.

In the spirit of the agile manifesto, I left more things around the frontend to the ad-hoc agreement with the developer. E.g., with the already mentioned responsive design, it proved to be an effective way of working. Unfortunately, this did not work very well in the case of sharing a description of functions or other logic, where it is necessary to have more detail written down for later needs.

Retrospectives are needed. Occasionally, the team needs to sit down and discuss how to work together. Whether a person is internal or external, it should be heard. We only had one retrospective for the whole project, which I think creates some unspoken expectations and a certain incompleteness in the team.

Conclusion

In the project, I did three iterations of the design and two rounds of user testing. I helped with writing user stories for the first part of the development and was on hand during the development to fine-tune the details.

I spent 75 working days on the project and delivered over 100 screens.

In addition to the topic of data visualization, we in the team did:

Management of users and their onboarding into the application.
Sending predefined notifications from sensors.
The application supports sensors as well as an electricity meter, gas meter, flood sensor, smoke sensor and SOS button.

What I have described here is only the design of a human-centred digital product.

A similar-sounding story certainly took place from the viewpoint of architects, developers or product management.

The essential point is that we delivered a tool that will allow the client to offer another innovative service in the portfolio, which can be developed further.

The goal was met.