Optimizing Design For Mobile Web
After analyzing our conversion data it was clear that our responsive mobile web experience was leading to a larger number of drop offs in our acquisition booking flow. By stripping down the booking flow and specifically designing for mobile we were able to improve the experience and speed that it takes users to book a MakeSpace appointment.
What We Did
We started by deconstructing our existing responsive design to see which components were necessary for completing the flow. In conjunction with pairing down our design elements we decided to take those final design components and build a UI library. The library could then be used within our new layout engine where we could easily generate new tests based on data collected. We successfully launched 4 tests during Q4 of 2017. With each test we were able to gain insights from the previous test and modify the design.
Atomic Design & The New UI Library
We utilized the Atomic Design system to build our UI library. Elements (Atoms), Modules (Molecules) and Components (Organisms) make up our design system. We’ve defined our system as:
- More that one Element = Module
- More than one Modules = Component
For instance, an element could be an icon or a button container. Modules could be an input field or button and components could be a complete form or group of card in a carousel.
Here is a visual of how we constructed our storage plan cards:
Introduction of The Layout Engine
With the introduction of the UI Library our engineering team built a new layout engine which parsed a .YAML file to determine the order and variation of the components from our UI library. This helped us switch out components and launch new experiments effortlessly because engineers had all of the specifications of our library defined. The new structure reduced the amount of code needed and helped the team keep things organized.
Below is an example of how the .YAML file brings in the components from the UI library to build the design on the right.
When the project began we had been directing all traffic to an acquisition lead capture form. This served as our control throughout the project. The form had a decent performance rate due to its simplicity but the only problem was that it didn’t provide users with a quote nor did it allow them to booking their appointment themselves. It generated a lead which was then followed up by a sales representative. It was time to challenge this design to see if we could create a better more concise booking flow experience.
The Evolution of the Booking Flow
This step is one of our biggest drop off points. This is because users have a hard time knowing what plan to choose to meet their storage needs. We noticed many users were leaving the booking flow and visiting the FAQ page. In V3 we added a FAQ modal so users could seek the answers to their questions while never leaving in the flow.
On the services step we collect information about the appointment for our crew so they can anticipate the type of appointment and services the customer will need. For the user this step was unnecessarily long on mobile. To minimize scroll and interaction we created a horizontal carousel which automatically advances once the user answers the question.
Separating the Address and Appointment Step
The main reason for separating these two steps was to reduce the amount of actions taken on each step. We were given a piece of feedback from our customer support team where customers were having trouble adjusting their selected appointment date. It was unclear to them how to get back to the calendar. This encouraged us to remove the date bar (the grey bar with arrows in V1 where users could tap to see the calendar). We decided to land the user directly on the calendar allowing them to select the date, once the date was selected the time cards populate allowing them to choose a convenient time slot. If they have to adjust the date tapping back in the browser will bring them back to the calendar. This simple yet intuitive decision makes it easier for users to edit their date.
New Billing Requirements
Long forms prove to be an obstacle for users on mobile. The billing step is important because it is the point where the user is committing to the service. We wanted to make the form as easy to use as possible so we utilized a Stripe component to condense the required fields for the credit card number, expiration, security code and zip code. This was important because we were adding the billing address fields to the form which greatly increased the length. By allowing the user to select “Same as appointment address.” we were able to condense the form to two fields.
Breaking up the Profile and Review Step
The purpose of the booking flow is to give users a calculated monthly total for their storage plan and any initial pickup services. We found that our original design pushed the total price down on the screen which made it hard for users to see. By separating profile creation and review we decreased the amount of content on each step which in return helped the user focus on the necessary actions on each step. The profile step is unrelated to review. The purpose of the review step is to summarize all information for the user’s plan and upcoming appointment. By surfacing the total cost at the top the design is clear and concise, so the user has all the information they need to confirm their appointment.
After Q4 was done and all of our tests were run, we made great progress in optimizing our mobile web booking flow. We hit our goal to reduce the content on each step in order to minimize scrolling. We now have a layout engine that supports quick iterations and a strong UI library. Lastly we’ve been able to build upon the library to create components for desktop.
The most important thing I learned from this project was the power of the library when implementing quick iterations. Being able to put together a page in a matter of minutes helped streamline my design process. The library makes it easier for me and my team to collaborate while making sure that design is consistent across all platforms.