Air Monitoring Web App Redesigned

Edgar Louis
5 min readNov 28, 2020

Background

AQimos is a web app for desktops and mobile that monitors air composition. In AQimos, they believe that air is a matter of life and death, and clean air is a crucial part of life. By that spirit, my work is to present complex data while ensuring the easiness of use. I seek to design a system that ensures the complex data to be displayed as clear as possible — to reduce the thought processing while the data is displayed, so the users could make the decision without a heavy cognitive load.

My role and responsibilities

  • Interviewing the stakeholder for the project requirements
  • Auditing the content for the existing web app
  • Making the use case and user flow
  • Creating the wireframe and high-fidelity prototype
  • Doing usability test for the improved interface
  • Coding for the front-end part using Next JS framework

Platform

Responsive web application

The Problems and Requirements

The previous design

In the previous design, the web app had several problems. First, the gauge that was used to show the temperature, humidity, and battery power was shown with a level gauge. This leads to the mistranslation of data by the users.

Upon the interview with the stakeholder, they intended to show the data with a particular time period. And some elements like the battery power were less prioritized compared to, for example, the average wind speed. So, some adjustments had to be made.

The other problem was that the chart for air composition took too much space. For each composition — there are five compositions — the chart was shown separately and used the whole device viewport. This was a case where an empire state of dashboard appears. As the result, the user needed to scroll a long page to see all the data. It was both ineffective and inefficient.

It was then decided that a redesign process is needed.

Auditing the content

Content audit

Before the plan new design process happens, I first need to understand what already exists on the current web app. The stakeholder interviews took place first.

I asked questions like:

  • Why are we doing the redesign at all?
  • Who are the users?
  • What has already been decided — the deadline of the website, the technology will be used?
  • The number of developers involved in the project?

This is important as I have to build a solid foundation for the redesigning plan.

Then the content audit came in. I scanned all the elements that have already existed — tarting with the first page, top-to-bottom, listing all from the navigation menu to the smallest details. I evaluated the type of content under each navigation item. Then I classified each level and made a new sub-grouping when I found it necessary.

Defining the flow & use-case

Basic flow and use-case

The use case described a step-by-step description of how users complete specifics goals. By doing this process, I was able to define the needs and how the users try to complete that needs.

Because a redesign attempts to solve a known issue, a use case could develop an optimized workflow that should make the experience easier — and increase the conversion rate in some cases.

Based on interviews, what did people find frustrating about the site? I used the feedback to identify redundant or confusing steps in the process and cut them out of the use case.

Managing the dashboard

Dashboard flow

I designed the dashboard by first defining the prioritized function. Because the top left corner of the screen naturally gets more attention, the flow starts from there. When the users finish with the first row, they will move down to the next one.

For data that are dependent on each other and affect decision making, I made a layout that the users do not need to go back and forth — creating a continuous flow for easy scanning across the dashboard.

From the wireframe to the prototype

Wireframe

The wireframing process started from the paper sketch. I like this method because it’s easy to pour my ideas without too much time wasted. If any of the ideas need to change then I can simply sketch on the new page.

After I had the desired concept then I translated it into the prototype software. Some minor adjustments were reasonable and as long as it keeps the original concept then it won’t give a significant problem. This was where I went through from low fidelity to high fidelity and fully functional prototype.

Guerilla testing

Using task completion as a measurement, I determined the success metric by doing usability tests with some users. The test focused on how many subjects are successfully doing the task and how they perceive the data that is served by the interface. Overall, the users found that the interface is easy to read and the navigation is intuitive.

Next steps

In the future, here are some things that need to be addressed:

  • Making error and feedback state for error handling
  • Using Task Completion Time metric to see how effective the design for the larger user scale
  • Using Hotjar to track the heat map to find any existing redundancies

The takeaways

Perhaps the most challenging part in the process of redesigning AQimos is that I have to include many elements in one viewport without pruning even one element. The interview process with the stakeholder and the content examination reveals that every element is crucial for the decision-making process. Thus, the design maximizes to include every element in the best arrangement while maintaining its usability across the device.

If you like it I’ll appreciate any number of claps. Hope you enjoy reading it. Thank you!

--

--

Edgar Louis

www.edgarlouis.com Helping people solve problems and ideas through UI/UX Design. I also like to write and share stories.