Smart WiFi app — UX design case study
For Niobe Mesh & Sparks mesh routers
In this article I’m sharing extensive documentation of my UX/UI process, reasonings and learnings from designing a Wi-Fi app to manage a mesh router for one of the main Internet Service Providers in Spain.
More than half of Spaniards consider it vital to have a high-speed Internet connection in all rooms of the house. In fact, Spain stands out for being one of the countries with the highest number of devices connected to the Wi-Fi network (7 on average, exceeding the European average) and for a greater use of signal amplifiers, with a penetration of 30%, only surpassed by the Russian average of 42%.
These trends highlight two new opportunities for service providers: on the one hand, reducing the internet connection problems faced by almost two-thirds of Europeans as a result of growing network demand; and, on the other, to provide high-speed Internet in all rooms of the house.
Users are asking for better connectivity — one that is more reliable, offers higher speeds and that’s personalised.
About the project
Briefing and goals
What we knew from our client:
- Customers contacted the call center and opened a high amount of tickets because of ‘bad or no connection’ issues.
- Customers were not really getting the internet bandwidth they were paying for.
- Customers were having to buy separate products like Wi-Fi extenders and mesh routers to improve their home connectivity.
- Customers were changing to different internet service provider companies.
The end goal was to create a product that would improve the customer’s internet experience at home and we would achieve this by giving them better Wi-Fi and as a result of that, less reasons to contact and/or change their ISP.
- Better Wi-Fi was going to be achieved by offering a new premium service that included at least two devices called Niobe Mesh & Sparks.
- At the same time, the development of a mobile app to manage the router in a very easy and intuitive way, thus decreasing the interactions with the call center and clients getting extra features from their ISP.
Niobe Mesh is a ONT (Optical Network Terminal) + mesh router in a single-box solution. A tri-band AC2200 specially designed for operators that together with Sparks creates a potent mesh network.
Sparks is a mesh router (also called node). A tri-band AC2200 specially designed for operators to, together with Niobe Mesh, create a potent mesh network. To create a mesh network, a household needs 1 Niobe Mesh, and as many Sparks as needed depending on the size and shape of the place (usually between 1 and 3).
Problem statement
Conceptualising a new product and its business model (premium Wi-Fi) in an assigned niche (Internet connectivity) and applying fundamental knowledge of Research, Information Architecture (IA), Wireframes, Visual Design and Prototyping to create experiences for a Wi-Fi app.
Timeline
A few weeks — on and off.
Project Type
Solo; Niobe mesh & Sparks demo app + Ironhack final project.
Platform
Designed for iOS using Material Design Guidelines.
Deliverables
Visual design and prototypes for the topology drawer, guest networks and parental controls. Next steps + features roadmap.
UX.
Research
Extensive research was made to really understand the user. Having the freedom to design a physical product from scratch (with only a few requirements and guidelines) and base our design and production decisions on real and useful data, was key to reach a desirable outcome.
During this process, several tools were used. They made it possible to thoroughly analyse the problem and all the information surrounding the project focusing on benchmarking and comparative analysis, users and possible solutions.
The following table showcases a comparative analysis of retail solutions (mesh routers sold directly to final users like Google WiFi, Linksys Velop, Netgear Orbi, Asus Lyra, Eero, etc.).
I was fortunate enough to be able to test 4 router mesh devices, together with their mobile apps.
The apps onboarding — being such a key element when it comes to successfully installing and synchronising nodes —required a big part of the research resources. Which is why each app was independently analysed to avoid mistakes and see what was already working (and not working) with real users.
New technologies and future router releases were also analysed to be able to understand where the market was moving towards to.
A Lean UX canvas was made to understand the problem we were facing and to try to preview solutions based on what we knew from the research.
Quantitative & qualitative research
A Lean Survey Canvas was made to create a survey which, together with a few interviews, provided me with insights from real users.
An Objetive — Key — Results analysis was also made to define the main goals and the ways in which those goals were going to be measured to determine whether they were successfully or partially achieved.
The framework is simple and easy to understand and focuses on the results the organisation needs rather than the process that defines those goals. These OKRs were only a guideline since we didn’t yet know how much we were going to be allowed to participate in the measurement of these results.
User Personas
After having quite a few insights regarding the user, the following user personas were created to exemplify 3 different types of users. This was particularly useful for our weekly meetings with our client so that we could explain to the stakeholders the reasoning behind our choices and the direction we were taking.
Brainstorming session
When there was time I made sure to propose brainstorming sessions with the team (project manager, product manager, industrial designer, hardware engineer, mechanical engineer, software engineers and any other profile I could get!). These sessions always gave me new perspectives and ideas that I hadn’t considered before. All I needed was a few brains, a meeting room with a white board and a slot in our calendars.
Information architecture & prototypes
Affinity Diagram
All the insights from the research (including comparative analysis, desk research, surveys and interviews) were showcased in an affinity diagram to be able to see all the information together in one place and get an easily accesible panoramic view of the data.
After having a few ideas to include as features, we had to prioritise them in order to include the ones that were really useful and needed. For this I used the MoSCoW method.
The method puts needs into four buckets based on their order of importance — which make up the acronym for its name:
- Must have: Functionalities that must be delivered within a time frame to declare success. Even if one of the requirements from this category is not delivered, the delivery should be considered a failure.
- Should have: Such classified needs are important, but are not necessary for success. Items here eventually have to be delivered, but they’re not as time-sensitive as the Must-haves above.
- Could have: Functionalities in this bucket are usually small enhancements that could improve a product but are not essential. They’re less important than the previous two categories, but can be implemented if time permits.
- Won’t have: Items here have the lowest importance. They either don’t match the current challenges of product users or are deemed to be the least critical.
The method is best used to prioritise time-sensitive requirements within a fixed timeframe, making sure the most important items get delivered first. With this in mind, it’s important to note that the most common critique of the technique is that it doesn’t distinguish between items within the same category.
I’m focusing on this tool a tad bit more than the rest because it has been particularly useful during the whole project. There were so many possibilities when it came to new features that we needed a quick system to prioritise them. We did this regularly in order to plan each new software release.
User Journey
This user journey was based in Beatriz García (user persona) to exemplify the use of the feature ‘Guest Network’.
Card sorting
I organised this activity with 3 different people in our company (business development manager, software engineer and hardware engineer). It was very useful to see the similarities, as well as the differences, in the way they would each organise and group the information. This helped me with the information architecture and to create a coherent set of features for the product’s MVP.
Mind Map
Site Map
User Flow — Parental Control
UI.
Once the app’s content for the MVP was defined I started creating the visuals. I decided to create a whole new branding to showcase the results and decisions made from the research. To give it a name, an aesthetic, attributes… everything needed to make sense of the project in a consistent and coherent visual way.
However, after doing all the research, user flows and low fidelity prototypes, the client decided that the final designs were not our team’s responsibility, since the internet service provider had their own app and finally decided to integrate these features into that app instead of having two different ones.
On one hand, this made sense because that way they could guarantee having all the traffic go through one place. However, we were very clear on the negative impact this decision had on the way the app was designed and the way the features would work. For instance, to access the main app the user had to log in using their email and password (which can only be one per contract, not person/email/device).
Once logged in, there was no way to differentiate who the user was (since many people in the same household may want to have the app to manage the router for whatever reason). This worked against the parental control feature, for example. If teenagers had the app to create guest networks or forward ports for online gaming, they could also manage any existing parental control.
This was analysed and explained to the client and solutions to solve this problematic were going to be tackled in the next iteration.
