apps in Australia have two things in common. They are pretty unpleasant to use while having high scores in the Store. As I prefer to rather act than bitch around, I decided to redesign one of them. I picked an called AUS and focused on feature only as that was the one I struggled most with. To highlight the biggest problems and opportunities, I used by Jakob Nielsen. I sketched paper prototype with a proposed solution and tested new information architecture with Treejack test. I also designed low fidelity prototype in Sketch, made in interactive in inVision and finished the whole process by conducting four tests. And in this article, I’ll walk you through it. Also with my ups and fails.

I visualized the process using a double diamond model.

👨‍💻 Identification of problem areas according to usability heuristics

Even for a normal user, it would be easy to identify the biggest problems when using the radar feature. I decided to and then use usability heuristics as it’s one of the commonly used methods for usability evaluation. I also prioritized the list of problem areas to learn what to focus on.

Problem: The user can’t use the map in the way he already knows

The user can’t change the location on the map to whatever he needs. He has an option to choose from the preselected locations by tapping on the icon on the right side next to the slider. To zoom in, the user can do that in a rather limited scope or use one of the predefined terrain heights below the slider.

Also, the radar feature works only when the location is enabled in the app settings. If you don’t want to allow the app to use your location, the radar feature shows some random place or crashes.

Proposed solution: Don’t force the user to enable location when it’s not essential for using the app. Allow him to manipulate the map the way he knows from another map based systems by dragging and zooming in and out.

Affected heuristics

  • match between the system and the real world
  • consistency and standards
  • flexibility and efficiency of use

Problem: The slider is located too far from the thumb zone

When the user wants to achieve the main goal of the rain radar — checking how the rain clouds move, he needs to reach out from the thumb zone.

The ad at the bottom doesn’t help the user to achieve any of his goals. It creates a clutter on the screen and a distraction when it’s placed so close to the navigation. If the ad is essential to stay in the app, it should be at least moved to some less important zone, for example to the top of the screen. Also, the status sign on the slider is reversed. It shows paused sign when it’s paused and green arrow when moving.

Proposed solution: Moving the slider to the bottom of the screen and moving the ad to the top.

Unfulfilled heuristics

  • consistency and standards
  • aesthetic and minimalist design
  • error prevention

Problem: Controlling how the rain clouds move is not visible and clear enough

When the user wants to check how the rain clouds were moving for let’s say past 24 hours, he needs to find the option buried in the top navigation. Also, the labelling is not consistent, notice “1 hour”, “Since 6 AM”. I also doubt that 6 minutes is a standard option for such a feature.

Proposed solution: Make the options easier to find and understood to the user. This also creates an opportunity to study what are the standard periods for such radar apps and rebuild it.

Unfulfilled heuristics

  • aesthetic and minimalist design

Problem: The overlay icon serves multiple purposes

The overlay icon turns off values of the temperature in the map, shows the direction of the wind and it also serves as a locator. It doesn’t represent any of it by the visual. The enabled/disabled status is indicated very poorly by changing the colour between very close scales of grey.

Proposed solution: Break the overlay icon into features that can be independently controlled. Stress out the current status of the icon.

Unfulfilled heuristics

  • flexibility and efficiency of use
  • visibility of system status
  • consistency and standards

Problem: The Doppler wind function is visually grouped with other features

The Doppler wind is grouped together with the time periods of the rain clouds although it’s a different function.

Proposed solution: Make it stand out as a separate feature.

Unfulfilled heuristics

  • flexibility and efficiency of use

Problem: The map shows too many details

The map shows details the user doesn’t need to achieve the main goals of the app, for example, the terrain heights.

Proposed solution: To prevent the distraction and also help user orientate in the map, use rather plain map with a few information.

Unfulfilled heuristics

  • flexibility and efficiency of use
  • aesthetic and minimalist design

Problem: The radar icon in the navigation is messy

The radar icon in the bottom navigation is not clear and recognisable. It also doesn’t meet any standards for icon design.

Proposed solution: Change the icon for a different one the user might already know from other systems.

Unfulfilled heuristics

  • consistency and standards

Knowing all the problem areas I couldn’t wait to sit down to sketch the first ideas. Based on the analysis I defined three main goals of the weather radar feature:

  1. navigating easily through the map using map controlling the user already knows
  2. controlling how the clouds are moving
  3. and flexible change of the time period of the clouds radar data.

I also invested a little more time to the preparation and research phase. So I

  • installed about six weather apps and I inspected their radar feature. I was ready to make notes about solutions I like, yet there weren’t any.
  • studied Apple’s Human Interface Guidelines for iPhone iOS as this was my first time when I came across mobile app design. I also went through Android Design Guidelines as well.

✏️ And now to the paper!

Let me make a small side note — I have a lot of experience with online campaigns. When preparing a campaign I’m always trying not to spend too much time polishing the idea. I’d rather ship it as soon as possible and work on the optimisation based on the data gathered. I started with the paper prototype in the same way, drew the first sketches and immediately tested them.

One of the first lo-fi prototypes.

Based on the main goals I got rid of the top navigation. This maximised the space on the screen that was reserved for the map. I moved the slider above the bottom navigation where the ad was placed. I also created three side buttons for changing the location, menu with the radar data and the locator. I also removed the “show me the whole continent” option as this should be reachable by the zooming out.

I needed to maximise the map space.

I struggled with the icon for the menu with the radar data. After a short study that didn’t make me any smarter, I decided to leave it for the usability testing. Giving an order to the radar data was also a great opportunity to test the information architecture of the menu. I conducted a short Treejack test to see how easy is for users to navigate through it. I shared the test online and was waiting for the data. But I was aware of the fact that missing context of the map might skewed the results.

Tasks asking about the location were both more than 80% successful. The one on the picture above had a 30% direct success rate which means only 30% of people marked the right answer on a first attempt. I wondered what could have been the problem and I came with a few hypotheses

  • the task was poorly defined and people were confused about what they should be looking for
  • the whole picture of the radar feature was incomplete due to missing map
  • the copy on the buttons was too vague
  • the information architecture was not easy to understand.

I decided to replicate the task during the usability test to get more insights.

🖥️ High fidelity prototype

After having all the data I needed, I switched to Sketch to create a prototype for usability testing. I used a few tones of grey and font to state that this is a low fidelity prototype for testing purposes and not a final visual design. I tested the screens on a physical device via Sketch’s Mirror. This helped me to fix problems such as buttons too small for tapping or a slider too low in the thumb zone to reach it.

I realised I was missing a few more artboards after I uploaded the screens to inVision to create an interactive prototype. I forgot about changed statuses, changed slider and updates that were not crucial to sketch on paper to visualise the function. But when I started to play with the prototype on my iPhone, it felt so good!

At that time there was a workshop happening in a few days and I thought it might be a great opportunity to take my prototype out for a usability testing. I already had some knowledge about the topic, but I wanted to refresh my memory with practical articles and guides. If you’re not much familiar with the subject, I found these sources as the best: How to Conduct Usability Testing in Six Steps by Toptal and Turn User Goals into Task Scenarios for Usability Testing by NN Group.

👱 Let’s give it to the users

When knowing the main goals it was easy to come up with what I need to test in the usability testing. I struggled with providing the user the context of the task and with not telling them what to do right away. But I guess it’s a common problem for anybody who’s new to this.

So I prepared five short user tasks:

Task 1: This is your first time opening the app right after the installation. How would you find your current location?

Task 2: You want to get more detailed view about the place you’re currently at. Take a closer look at your area.

Task 3: It’s evening and you need to walk out your dog before going to bed. You want to check how the clouds are moving so you won’t get soaked by the rain.

Task 4: It’s morning and you found your outdoor plants destroyed by heavy rain. You want to check on the radar if there was any big storm during the last 24 hours.

Task 5: You turned on the news on TV and you’re hearing that there is a big storm in Sydney. You want to check quickly on the radar what’s going on in Sydney NSW.

I also did a pilot testing with my colleague. This was a great exercise because it provided me with quick relevant feedback. It allowed me to remove the biggest obstacles before the live testing. I realised that I can make the path to the selection of the time periods more simple with removing one step:

I put all radar data to one table.

The usability testing

I gave myself a goal to conduct at least 3 but ideally 4 usability tests. When looking back on what I learned during the testing I would highlight

  • using an icebreaker right after someone agrees to take part in testing. I was asking whether they are using any weather app. I provided them a context of what the test is going to be about, but it seemed that the icebreaker made people much more enthusiastic about the topic and the testing.
  • it doesn’t matter if you’re using colours or percentages to mark the achieved task. But always make side notes about what was the user trying to do, what were his comments and so on. You will use it later for the potential redesign.
  • at the end of the testing, ask participants whether they have any feedback or comments by asking them open questions. More data you collect, more resources you can work with.

So here are the results of the tests:

Source link


Please enter your comment!
Please enter your name here