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