This is a case study of work I had done to improve version 2 of the Speedy setup process.
Speedy provides Wi-Fi verfication and monitoring for rental properties.
To achieve this, Speedy utilizes a device which needs to be connected to the appropriate wifi network. This device then monitors latency, connection speed, noise floor, signal strength, along with other metrics to form a complete picture of the signal landscape.
To perform and post the measurements, the device needs to be connected to the Wi-Fi network and the intenet, and the specific device has to be linked to the clients' user account and location.
Some of our larger clients had installers who might have limited access to credentials.
The first version of the setup process led to many support requests, with problems in up to 40% of installation attempts.
The final solution has multiple touchpoints which were implemented:
All work is mine, unless otherwise noted.
Skills utilised in the project:
To understand the problem, I used support requests and I analysed the entire user flow, from device unboxing through to final device registration to find where users got stuck.
I managed to identify the following key modes of failure:
Beyond that, we found a few other problems with our existing system:
The user journeys had to cater for various connection types and failure scenarios, with the goal being to guide the user through their specific scenario without them having to directly troubleshoot the problems themselves.
I laid out proposed user flows based on connection method, with stakeholders being able to provide feedback and pose questions.
The ideal flow
The user connects a device directly via ethernet, Wi-Fi connection is administrated remotely, and the device > location > user link is made automagically via scanning a QR code.
Secondary flow
A backup user flow, where the user can connect to Wi-Fi locally, without needing to log into the portal.
Wi-Fi only flow
A final flow was done in the case of networks where only Wi-Fi is available.
QR code flow
A proposed flow to explain how the QR code link would work. The QR code would link to the device setup documentation, where a call to the api would be made to check if the appropriate device id has registered itself. If so, the page would automatically redirect to the location registration page on the web app. If not, we stay on the page, directing the user to the setup guide.
The device is manufactured with a two colour LED, which we can use to provide a status code
I built wireframes and prototypes for each piece of work in Figma, and these were tested by the appropriate stakeholders.
1. An overview of the entire final user journey prototype:
2. After scanning the QR code on the device, the user gets directed to the device setup page on the public site. The device ID is passed as a query string, and if the query string is picked up, this automated connection check modal shows up. Upon landing on the page, an API call gets made to the backend to check if the device has registered itself and if it's online. If so, the user gets redirected to the location setup page on the web app. If not, the connection check modal provides the option for setup help, and the user gets directed to the setup wizard.
3. Here is the setup guide to help a user set up their device if the automated system did not pick up the device being connected. This is also the default state of this page.
4. If the automated connection check has passed, the user gets directed to the web app to register the location, or attach the device to an existing location. This flow also guides the user to setup Wi-Fi credentials if the device was connected via ethernet.
5. Once the location has been registered, the user is directed to the location dashboard. Here there is a connection status tab, which also allows the user to set up or change Wi-Fi credentials.
The wireframes were styled using our existing design system, and another round of prototypes were made and tested.
1. An overview of the entire final user journey prototype:
2. After scanning the QR code on the device, the user gets directed to the device setup page on the public site. The device ID is passed as a query string, and if the query string is picked up, this automated connection check modal shows up. Upon landing on the page, an API call gets made to the backend to check if the device has registered itself and if it's online. If so, the user gets redirected to the location setup page on the web app. If not, the connection check modal provides the option for setup help, and the user gets directed to the setup wizard.
3. Here is the setup guide to help a user set up their device if the automated system did not pick up the device being connected. This is also the default state of this page.
4. If the automated connection check has passed, the user gets directed to the web app to register the location, or attach the device to an existing location. This flow also guides the user to setup Wi-Fi credentials if the device was connected via ethernet.
5. Once the location has been registered, the user is directed to the location dashboard. Here there is a connection status tab, which also allows the user to set up or change Wi-Fi credentials.
Each aspect of work was then implemented on its appropriate platform. See the final product section for more details
Packaging instructions were illustrated in Adobe Illustrator. These instructions were then applied to the packaging.
1. The primary install guide that welcomes the user when they open the package
2. The packaging box tempate with artwork applied. Template provide by supplier, layout provided by marketing, illustration and final tweaks done by me.
3. The optional printed install guide.
4. Our first view of the production packaging.
The device setup portal was built in HTML, CSS & Javascript, which was embedded on the device and served via NginX.
This portal was accessible via an ad hoc Wi-Fi network hosted by the device, and the user could access it via a phone browser by connecting to the device.
Wi-Fi setup was handled via NetworkManager on the device, whilst local setup was handled via node application, and remote setup was provided via the same node app communicating with the backend over MQTT
The web application Wi-Fi setup was built in VueJS
The frontend communicated directly with the device via a secure websocket with a connection to mqtt. This was to ensure that we did not have access to any network credentials.
The connection between mqtt and websockets was built by a different developer, whilst I built the user frontend and the device side software.
These device lists are then used during the firmware flashing process, and the stickers applied onto the devices during production. This was the secret sauce to the automagical device > user > location connection, and also provided an easy channel to guide device setup.
I designed a device ID syntax which included versioning and unique device identifiers.
I then built a piece of js software which generated these device ID's in the browser and output CSV lists of generated ids per batch, along with the printable QR code stickers, which were applied to the devices
These device lists are then used during the firmware flashing process, and the stickers applied onto the devices during production. This was the secret sauce to the automagical device > user > location connection, and also provided an easy channel to guide device setup.
The device setup process has many branches and possible user journeys.
I designed, illustrated and built the setup guide, which was then embedded in the public site support section