Case Study
iOS, Android | B2C IoT | 2022-2023
The company sells weather stations that save their data on blockchain and reward users with crypto for these. The mobile apps are the interface to the stations and are key to the company’s success.
The Team had released a basic app in order to enable early adopters to claim their stations, view their weather data, connect their crypto wallet, and test the rewards mechanism. This version of the app was missing multiple key feature, and was in need of fixing some of the main flows.
Redesign the mobile in order to fix problematic flows, add missing ones needed to enable users to perform all the necessary jobs, and, unify the designs to be consistent.
I was the lead Designer/Architect of the project. My role was to sync with all stakeholders and Teams in order to gather requirements, propose strategy, design and test solutions. Since there was no PM on the company, I had to pitch in the help with this as well.To do this, I partnered up with the UXR lead, and head of weather research.
Having people properly setting up their station was critical for the success of the project. We needed to make sure this was as easy and fast to do.
We wanted to make the app the user's default for weather info. This meant that we should highlight the strengths of having hyperlocalised weather data, and make these accessible and understandable.
The support team was drowning in repetitive work. This left them with less time to focus and answer to new questions the community had. Our goal was to streamline the most common problems, and free up their time do focus on handling novel cases.
Trust of the community is one of the most important things. Everything we did should help to reinforce this. Our strategy was to be transparent and let people what was happening, and for what reason.
Part of building trust, had to do with the rewards users receive each day. This was one of the key incentives for a large portion of the community. We needed to inform them if something was going wrong, and the reasoning behind why they got fewer rewards on any given day.
This is a simplification of the process followed in this project. The actual process was a lot more iterative, with many back and forth as we gained new understanding and we received more insights and evidence.In this short selection of steps we wont see all the steps we followed
The company's business model was based on good quality weather data, provided from stations that were properly installed and maintained. This was critical to the success of the project, as it would otherwise make it impossible to close the loop and sell the weather data to third parties/clients.
In collaboration with the UXR Team we arranged some contextual inquiries observing users setting up the company's stations, claiming their devices on the app, and using it to make sense of the data.
These sessions showed us that there were a lot of parts of the onboarding experience that needed fixing as people were confused at times.
Also, setting up a station required a lot of steps users were not aware of, making it harder to properly setup one.
The app, on the other hand, required users to do a lot of manual steps that made the whole experience a bit frustrating at points.
This clearly shown us that there are a lot of pain points for people joining the company's network. The instructions weren’t clear, and the steps that needed to happen on the app were not user-friendly, as they required a lot of buggy, and manual input from the users
The existing manual was lacking information, and was confusing people. This had impact on the quality of the station installation, the weather data collected, and the rewards people received. Last but not least, if the data weren't good it reduced the value of the network,
People needed to view certain values close to each other in order to make sense of them. Also, they need to be able to glance at some of the values in order to make high level decisions for the day.
The system only showed a week back in time, and a week of forecast. A lot of people complained about this, as they were eager to make weather analyses.
It was unclear to users why some days they didn't get as much rewards as the previous one. This was creating anxiety in the community, and was overloading the support team.
There was no mechanism in place to inform users if there was a case with a faulty sensor, or wrong installation. This had impact on the data quality they transmitted, and the rewards they received.
A lot of people wanted to use the hyper-localised weather data in their smart home appliances.
This tool helped us align and create shared understanding amongst the Team.
Having defined the purpose of all of the company’s subsystems, their relationships and interconnectedness, as well as their success criteria (which lead to some fundamental KPIs) made our work easier when we needed to make decisions and adaptations
The company had a plethora of systems, and we needed to create more in order to improve and optimise the customer journeys for the main personas.
If we were to design and manage the company’s services and products in a systemic and consistent way, we needed to know which systems/touchpoints needed to be updated in order to hit specific goals.
Together with the UXR Team, we created a services & systems inventory map in order to align on the purpose, audience, complexity, business and UX success criteria of each system/touchpoint.
We managed to create an easy, fast and enjoyable device onboarding experience. This helped to get more stations online providing data to our network, and we drastically reduced the support tickets
We iterated on these flows in collaboration with the Hardware and Software Teams, making sure that the optimal flows for the users were feasible and viable given the company’s resources and plans.
This is one of the most important steps in the user’s journey. A lot of customers had pre-ordered their station up to 9 months, and this needed to be an easy experience, and a first win.
The early adopters were tinkerers and would excuse inconveniences, but, we knew that as more people would start to use our devices, they would expect to be as user friendly as other commercial products out there.
Updating the WiFi flows, and creating the ones for the Helium Network was really interesting, as these kept changing as the Hardware Team was drilling down to the nitty gritty of each system. We worked hand-in-hand to make these as easy as possible, while handling all the extreme cases.
We offered a way for users to have all the information about what it would mean to close their account, letting them make an informed decision. We made this smooth, fast and “painless”. This was especially important, as the early adopters weren’t required to agree to Terms of Service - these were created during the development of these flows
The reality is that people decide to stop using products and services for a myriad of reasons. This is inevitable. All companies can do, is to make sure this off-boarding of users is as graceful as possible.
This is especially true for companies that operate in the web3 space, where their users are “partnering” with them.
We needed be able to offer a way for people to close their account, in a way that would make them feel secure and would not break their trust in the company (their rewards will still be theirs, and all relevant data will be deleted as requested).
We also needed to learn more about why someone chose to do this, so we created a way for someone that has deleted their account to be able to talk with our UXR team.
The app is a combination of device management, weather app, and crypto/rewards management application.
In order to make this work, there are 4 main screens, the Device list (showing an overview of all the devices a user has), the Device Detail Observations (showing all the weather data collected by the station), the Device Detail Forecast (showing relevant forecast data for the station), and the Device Detail Rewards screen (showing information on the station rewards).
The UXR team provided evidence that users were looking for certain information multiple times per day. Current temperature and feels like, humidity, wind, and precipitation rate. Forecasted temperature and rani probability for the whole day, as well as the next couple of hours.
Based on that, we redesigned the device cards to in order to show such information, and offer a overview of what is currently going on, and what to expect in the next hours.
Help users prepare and plan.We also needed to show what type of connection each station has as this affects the rate station observations update. Also, Helium network outages must be shown.
Last but not least, we introduced a way for users to get more stations without having to search the web. We added a link to the company's shop in order to remove friction and make it easier to get a new station.
Updating the station list cards, we managed to create an “Overview of the day” using composite data -station measurements, and forecasted data. This helped create a more useful view for people wanting to check current conditions, and plan ahead for the next couple of hours, without having to navigate to deeper levels.
The stations used by the company have a couple of sensors, and when combining these measurements with meteorological algorithms we’re able to show 11 relevant observations in real time.
Working with the Weather Research Team we defined the grouping and proximity each observation should be shown in the UI, so that people with meteorological knowledge can make sense of these, as easy as possible.
We also added a section that represented the extreme observations for the day, as these were of high interest to many of our users.
Last, but not least, we optimised the Historical Data screen, enabling users to search and select specific dates, and/or periods. Also, by moving the information bubbles out of the graphs, and making the selection of time the same on all graphs, users were able to view the data and make comparisons easier and more accurately (even on mobile screens).
By showing all the data the station gathers, in a manner that make sense meteorologically, we helped the users have more information about the weather conditions near their station’s location. This was one of the main project goals
In the original version of the app, we only shown a fraction of the forecasted data the system had generated. By creating additional views, we offered a way for users to have an overview of the week and compare each day on some basic values. At the same time, we enabled users to view hourly forecast for the day they wish, and last but not least, to access the full forecast data.
This created more value for users by providing access to the complete data sets. Especially the weather enthousiasts
One of the things the users expected the most when installing a weather station was an improved forecast.
Having such forecast, and not showing it, is a pitty.
We decided to stick to the information hierarchy of Overview > Details > Analysis. Enabling the users to have an overview of the whole week, then choose a day they’re interested in and see more information, followed by the full forecast Analysis graphs. A thing that made the weather enthusiasts amongst the community extremely happy!
By redesigning these screens, we managed to make clear why each station got the rewards they got, as well as what the owner can do to improve them. By adding a section about today’s rewards, -in combination with QoD- were able to inform owners that something is going on with the station, set expectations for that day’s rewards, and help them to navigate and fix the issue.
This results to happier users (as they know what to expect) and in increased data quality for the network. Last but not least, we reduced the support tickets as users knew what was going on, and how to handle it themselves
Transparency and Trust are crucial for any project. Even more for a project that has monetary incentives in place in order to achieve its goals.
For that reason, letting station owners know the breakdown of their rewards and costs was considered crucial.
At the same time, we knew that rewards were a huge motivator for most of the users, so we used Loss Aversion to help users fix station problems (and thus providing better quality data for the network).
We made clear that there were certain issues with the station’s condition, informing users what does these mean for their data, and their rewards.
Last but not least, we offered help on how to solve these issues. With this, we reduced the support tickets as users knew what was going on, and how to handle it themselves
Worked with Weather Research Team to create the QoD (Quality of Data) V1 UIs.
The algorithms developed can detect if a station has obstacles around it -AKA wrong installation- or a faulty sensor. Both cases, result in low quality weather data, and thus the rewards of the station will be reduced drastically.
It is in the best interest of both the company and the station owner, to solve this as soon as possible, thus making sure a clear indication and assistance to solving the issues were critical.
Each station has a couple of alerts and warnings that needed to be able to be communicated. This would help users understand if there is something wrong, what would this mean for their data and rewards, as well as what they can do to fix this.
We needed to create a clear and consistent system to show this information on multiple screens.
We made clear that there were certain issues with the station’s condition, informing users what does these mean for their data, and their rewards.
Last but not least, we offered help on how to solve these issues. With this, we reduced the support tickets as users knew what was going on, and how to handle it themselves
How we handle errors can help to reduce their effect on the overall experience. These are inevitable to happen, and they affect the user of the app, the support and community Teams, as well as the devs, as these need to co-ordinate in to solve any issues that arise.
Having this in mind, we wanted to first of all let the users know what happens, why it does, as well as what they can do to fix the issues themselves (this saves time from all parties involved).
Next, we created a list of known issues accompanied by what can the users do, what can the support do, and what does the dev team needs to know in order to investigate further if the solution is not as simple. We create UI elements to facilitate the communication of this information to all parties.
Once a user tries to reach the support team, an email client opens with pre-filled information that support and dev Team might need, removing friction and making it easier for the users to ask for help without back and forth.
iOS, Android | B2C IoT | 2022-2023
Back-Office Web App | B2B SaaS | 2022
Back-Office Web App | Internal | 2020
Web App | B2B2C SaaS | 2021
iOS | B2C SaaS | 2018 - 2019
Web AR App | B2C Concept | 2023