The app aids commercial drivers in completing their daily maintenance checklists, which are a legal requirement in the UK. Normally done with pen and paper, the app allows drivers to swipe through a pre-defined checklist for their vehicle and submit it digitally, along with notes of potential issues and supporting photos.
Bridgestone also sell a supporting product called TPMS (Tyre Pressure Management System) which is a set of sensors installed on the tyres. These pair with the app to check and log tyre pressures wirelessly, flagging if any tyres are incorrectly inflated. Vehicles with correct tyre pressures are more efficient, use less fuel and should have less maintenance downtime.
Note: This study is quite lengthy as it covers a lot of areas of development over the course of nearly a year. Acting as UX/UI Lead Designer alongside my UX Director Rob, we actually completed more work than is listed here, some of which was shelved due to changing business requirements. At the time of writing (January 2020) this project is due to be handed to VMLY&R Poland due to budget.
Part I: Activation for Drivers
- App already in MVP stage, being trialled by customers
- Testing revealed improvements to be made
- How can we make this activation process smoother for drivers?
In the MVP, drivers signed up with an email address and password. This was to change to a mobile number and PIN instead as their trial showed mobile numbers were more readily available, drivers were more likely to have a mobile number than an email address, and PINs were quicker/easier to remember than passwords.
However, they also found that some fleets have ‘communal’ phones that are used by all drivers, and that some drivers would be unwilling to give out their personal number. Therefore, we had to devise an activation and sign in method to allow for the following user types:
Personal phones, happy to provide their personal number
Personal phones, not happy to provide their personal number
Communal phones, happy to provide their personal number
Communal phones, not happy to provide their personal number
Legacy users already using the app with email/password credentials
We also had to provide a way for all of these users to be created in FleetPulse’s user management system, and an ideal way for all of these users to reset PINs/passwords should they lose them.
After several brainstorming sessions, sketches and meetings to define client requirements, we decided on the following:
- Drivers with mobile numbers were prioritised and use their number & PIN to sign in
- Drivers with no number would create a custom username & PIN. They could add a phone number during the activation process, to migrate them into the priority group
- Legacy users could still use their email/password to sign in, but we would begin a period of migration to move them to one of the two above groups
- Drivers with numbers could use SMS to receive ‘activation codes’ to verify themselves at activation or password/PIN recovery
- Drivers without numbers would need to receive their initial activation code manually from their manager, and set a mandatory secret question/answer during activation for verification purposes later on. Drivers with numbers could create a secret question/answer too, but for them this was not mandatory
With all of this in mind, I set about creating user flow diagrams for the activation, recovery and legacy migration processes, taking all of the above into account. It looked like this.
We presented these along with a lo-fi clickable mobile prototype in Invision, to show all possible user journeys. Immediate feedback from the client's Product Owner was that the journeys were too complicated - in our factfinding meetings they had overstated the importance of the ‘without phone’ user group, which was more of an edge case than we thought. Here you can see a selection of the wireframes I produced for the prototype (not necessarily in the flow order as some are missing. I created around 35)
- We removed the secret question option, meaning that ‘without phone’ users would be unable to self-serve for password recovery
- We removed the option for ‘without phone’ users to add their mobile number during activation (this was a client request to avoid erroneous data entry)
At this stage InVision was becoming too cumbersome for client review; we had several flows to show them at any one time, and also alternatives to those flows incorporating various requests they had made. I began outputting large artboards from Sketch with screen journeys on them, so that the entire journey could be seen at a glance, and the different options could be compared side-by-side more easily, particularly in terms of length.
Eventually we settled on a series of journeys that the client was happy with, and presented them with mockups for user testing and feedback. The UI design used the MVP's design - which was itself based in Material Design - as a basis and iterated upon it, evolving the design of form elements, CTAs, iconography and typographic styles throughout.
Further evolution of the user journey
During the UI phase we continued to iterate on the user journey for activation - further client testing revealed that many fleets were already using the app with legacy details, and also a number of fleets were using the app on Android tablets, meaning that mobile numbers would be impossible to use for these users. Our final process then centred on two kinds of users:
- Drivers with their own mobile devices, who would use their mobile number and a PIN to login
- Drivers with shared devices, managers and legacy users, who would maintain the old method of email address and password to login
We developed a pattern whereby the user can enter either a phone number OR email into a single field to activate, letting the app detect the input and serve the appropriate screen next. Below you can see the happy path of activation for a mobile user, compared with an email user.
We were also able to use this method for subsequent sign ins on shared devices, and the ‘Forgot Password?’ flows, unifying all of the journeys together with a single concept of 'one text field, two stages’. This allowed us to massively simplify the labyrinthine user flow diagram above into this:
As well as being the UX/UI design lead on this project, I was the lead copywriter/UX writer. For previous marketing-led copywriting jobs, I needed to be creative and ‘flowery’ with words. Here, however, we have a B2B app for commercial drivers, many of whom will not have English as a first language. I had to craft microcopy very carefully - not too cold and clinical, but not too friendly and informal either, all while being as succinct as possible.
All copy would be translated into other languages too; this was a concern as certain English turns-of-phrase don’t translate well, and some languages (namely German and Polish) would often have a higher character count for a given word or phrase. This provided a danger of certain labels, validation messages and body copy wrapping undesirably. As you will have seen above, all new UI elements have ample room to accommodate copy length. Accessibility guidelines around size and colour have been followed as well.
Part II: Onboarding Improvements
- Campaigns for app not converting to sign-ups
- Lengthy registration process likely responsible
- How can we streamline this to make signing up easier?
- The landing page for the campaign was essentially just a form. Lacking any solid communication around features & benefits, business value or social proof, users were left with no context as to what they were signing up for
- The activation process was very cumbersome and lengthy. Users had to:
- Complete an eight-field form
- Retrieve a temporary password sent to them via email
- Click a link in the email taking them to a sign-in screen
- Their email address was pre-filled, but they had to enter the temporary password
- Then they had to set their own password and agree to T&Cs
- Sign in for real using their email and new password
- Once signed up, the users were taken through an onboarding process in which they had to:
- Fill out the remaining ‘business critical’ information, which was another fifteen-field form (albeit some were pre-filled from the first one)
- Add all of their vehicles to the system
- Add all of their users to the system
This is an exhausting amount of upfront effort on the user’s part. Even if they do get through the entire process (or have a sales rep do it for them) there is no indication to a brand-new user about what they should do first, or where the important information can be found.
FleetPulse is a product that spans two different devices (desktop and mobile). However, unlike most multi-platform products where mobile and desktop are just different ways to engage with the same overall product (Gmail, Slack, Facebook, Dropbox etc), the FleetPulse mobile and desktop apps perform completely different functions.
One cannot be used without the other, and so when onboarding, we have to be mindful to take a manager across both desktop and mobile experiences so they can fully understand the process.
Our flow ended up taking shape like so, taking multiple user entry points into account:
- Users signing up for an account on desktop and then downloading the mobile app
- Users signing up for an account on a mobile browser, and then downloading the mobile app
- Users downloading the app without first signing up for an account
As well as these user types, we identified different goals for their use of the app:
- Users wanting to use FleetPulse for checklists only
- Users wanting to use FleetPulse for TPMS only (checklists are only a legal requirement in the UK, elsewhere in Europe they are optional)
- Users wanting to use both
Onboarding the desktop experience
The first thing we did was to simplify the registration. We reworked the entire registration form to be a clearly-signposted two-stage form that prioritised the crucial information required for setup and allowed the user to set a password immediately.
This dramatically reduces the time it takes to get the user to the main Dashboard, as illustrated below:
Upon accessing the Dashboard, the user is greeted with a tooltip asking if they would like to start a product tour. This can be dismissed immediately and at any stage of the tour, and restarted at any time using a link in the navigation. The tour has five steps, each of which corresponding to a main navigation section of the site, explaining the tasks available in each area (Dashboard/Vehicles/Checklists/Bookings/Users)
Ideally this would have spoken more to the features on the Dashboard, but the MVP has little to interact with. We felt it better to promote discovery of the other areas of the site.
The microcopy here is crafted carefully so that each stage users know immediately tell how long the tour is; where they are in the tour process; that they can quit at any time; and what they can do in each of the main sections.
Once the tour is completed/dismissed, the user sees a six-icon list of tasks to complete to finish their setup. As mentioned before, our analytics suggested that users who did sign up successfully were often inactive; they were not adding vehicles or users, and weren’t submitting checklists. This 'to-do list’ consists of a core set of tasks that are crucial to getting the product working for them. It provides them with direction and positive reinforcement once tasks are completed (the icon greys out and sports a large green tick) slowly building to an ‘Aha! moment’ where they first start to derive value.
Onboarding the mobile experience
The MVP already contained a basic tutorial for the checklist interaction (swiping left and right on items to mark as OK or defective), so we decided to keep the flow simple for first-time users. Upon launching the app for the first time, users are given the option to start the onboarding (Get Started) or jump straight to sign in. If they chose to Get Started, they would then have the option to further refine their journey by selecting a goal (I want to learn about checklists/TPMS/both)
These learning pieces would be simple screens that spoke to the concepts of checklists/TPMS at a high-level; we knew that the user would get further instruction at the point of accessing these features within the app, so no need to bog them down with information at this point. Once these screens had been consumed, the user sees a success message and is given the option to sign in (if they have an account) or to register if they don’t. (Unfortunately we didn't get to design these screens before running out of time on the project.)
Unfortunately the desktop app was not initially designed and built responsively; signing up and accessing the desktop app is possible on mobile, but it’s a rather buggy experience. Therefore we chose to direct people to access the registration page on desktop, and then return once this was completed. Not ideal but we’d rather a user’s first experience with the app was as good as possible; having a broken UI be the first thing they see is unacceptable.
Closing the loop
As mentioned earlier, in order to demonstrate the full end-to-end experience of this product to a manager, we need to direct them between desktop and mobile. Not many apps do this - typically a SaaS product signup flow will have a ’now download the app’ CTA at the end, but as I said these are often just two paths into the same product, and are therefore totally optional. Not so with FleetPulse. However, one interaction which does make use of this multi-device AND multi-purpose interaction is 2-step verification.
If you have a Gmail account and an Android phone, signing into your account on an ‘unknown’ device will show you a screen asking to authenticate using your mobile device. Many products do this with a text message or code of some sort - Google’s ecosystem allows them to provide a screen within the OS itself.
The desktop screen tells you to unlock your device (identifying it by make and model) and to tap a button to confirm it’s you. Sure enough, when you unlock your phone the screen is there, you tap the button and sign-in is permitted. Google realises that there is no way you can force a user to take their phone out, so it uses simple but clever messaging to direct the user to the desired course-of-action, the task they must do and what will happen when they do it.
We decided to adopt a similar approach for closing the loop in our onboarding. Later in the user’s discovery, when they have completed a checklist or TPMS check for the first time, we would amend the messaging of the ’sent successfully’ screen to draw the user’s attention towards their desktop device, where they will see the checklist/TPMS data they just submitted, as well as calling out further actions they can now perform with that data (flagged defects can now be scheduled for repair)
FleetPulse users fall into two basic groups, Managers and Drivers, both of whom can theoretically complete a checklist but only Managers can access the desktop app. Therefore we decided to make this enhanced messaging conditional, based on their user type; Managers would see it, Drivers would not.
Part III: Evolving the desktop UI
- Existing design = dated look-and-feel
- Potential to iterate improvements without complete overhaul
- Are these pages working as hard as they could be to highlight features?
In the images below you can see how sections of the UI were developed - left is the existing, right is the version I created.
We had a full 3-4 day workshop focused on improving the value proposition of the Dashboard - we felt as though the UI wasn't working as hard as it could be, and an opportunity to surface important, timely information was being lost.
After much discussion, Rob and I mapped out which pieces of information would be most important to see at the start of a manager's day, and I created widgets to visualise this information in an appealing way. Obviously there is too much here for a single dashboard view (which would ideally all fit on one screen) but it's worth seeing which information we prioritised and how it was visualised.