Locksmith Service Request

Increased locksmith jobs booked for vehicle key duplication by 400% by streamlining info collection.

Kiosk Responsive web app Forms
KeyMe kiosk with an input field for phone number and mobile device with a locksmith service request web form. The kiosk says it will text the link to the web form to you so you can get a locksmith to duplicate your vehicle key.
For customers with vehicle keys that require locksmiths to duplicate, the kiosk sends a service request form to their mobile device.
New experience map for requesting a locksmith for vehicle keys. Step 1: Enter mobile number into kiosk. Step 2: Receive SMS with link to web portal form. Step 3: Fill out web portal form to request service. Step 4: Get confirmation message via email. Step 5: Locksmith reaches out to schedule visit. Step 6: Locksmith arrives and duplicates key.
Instead of just sending customers' contact info to a locksmith (old experience), the kiosk sends customers to a service request form on their mobile device. Customers then enter all of the info required for the locksmith to book a job, streamlining the process for both parties.
Comparison of the old service request form's information architecture to the new form's. The old form had 9 sections (steps) that were all visible at the same time. The new form has 6 sections, and only one section is visible at a time. The new form also groups related questions together in the same section, and sections are ordered more logically.
Improving the information architecture of the existing service request form increased the number of jobs booked.

Overview

Note: Some content cannot be displayed due to the NDA.

Customers can duplicate a variety of vehicle keys at the KeyMe kiosk. However, some vehicle keys still require a locksmith to duplicate. This means that we have to connect those customers to locksmiths via the kiosk. Initially, the kiosk would ask the customer for their contact info to send to a locksmith. Then, the locksmith would later contact the customer to gather more details and set up an appointment. This approach was ineffective because:

  • Lack of info - The customer didn't know enough about the process to feel comfortable sharing their contact info.
  • Inefficient communication - Getting all of the required details required a lot of back-and-forth conversation between the locksmith and customer. Also, not all customers responded to contact. This led to frustration and unbooked jobs.

To address these issues, we designed a flow that connects these customers to a locksmith service request form in our web portal. Instead of asking for contact info right away, the kiosk explains the process to the customer, then texts the form's link to their mobile device. The customer can then fill out the form, giving the locksmith all of the info they need to book the job. Furthermore, the form provided more info on the duplication process as the customer filled it out, which helped build trust with the customer.

We completed this project in two phases:

  • Phase 1 - We started with an unpolished, existing locksmith service request form in our web portal and completely redesigned it to improve the user experience. This form and web portal existed for customers that discovered KeyMe's vehicle key services by browsing the internet (without visiting a kiosk).
  • Phase 2 - We then modified the kiosk flow to send the form instead of accepting all contact info directly. We also modified the web form slightly to improve the transition from kiosk to web, like autofilling some fields if the customer came from the kiosk and not directly from the KeyMe website. This flow benefits customers that tried duplicating their vehicle key at a KeyMe kiosk but couldn't do so because they actually needed a locksmith.

Don't have time to read the process? Jump to Results for more final designs!

Process

Objectives

User journeys before and after the kiosk and web form updates. In the old journey, the customer merely sent their contact info to the locksmith via the kiosk, and the locksmith and customer had to have long conversations to get all of the info needed for the job. In the new journey, the customer fills out a web form so the locksmith has all of the info they need without a long conversation.

We mainly wanted to increase the number of jobs booked for vehicle key duplication via kiosk. However, we also wanted to increase the number booked directly from our web portal form. From prior research on our customers, we were planning to connect the kiosk experience to the web portal experience (or something similar) so our customers would have an easier time typing. Thus, we had two objectives:

  1. Make the service request form in our web portal easier to fill out.
  2. Streamline info collection for vehicle key duplication jobs from kiosk customers.
    1. We hypothesized that if the new web form was successful, we could direct kiosk customers to it instead of asking them to type the info directly into the kiosk. Personal devices are easier to type on than large kiosk screens.

Research: Customers see too many steps and not enough transparency

User Research

We couldn't interview actual customers at the time due to security concerns and financial constraints. Instead, we asked others from the organization to provide feedback on current and proposed designs from a customer's perspective. This and data from the analytics team allowed us to better understand our customers and their journeys.

A profile of a typical kiosk customer named Angelina. She is a young mom who recently bought a new house and a used car, and she wants a spare car key. She struggles to find options that are both affordable and convenient.
According to our analytics team, the average kiosk customer is female, in their mid-20s to mid-40s, and going through a stressful time in their lives (like buying a house). We didn't have demographic data from our web portal users, so we used our kiosk customer persona for the web portal redesign.
The old user journey for the web portal form. Angelina discovers the form, and it seems like a convenient option at first, but she is ultimately deterred by its length and lack of transparency.
Customers feel confused and overwhelmed by the current web portal form. It has too many steps, and it doesn't give the customer a good idea of what to expect.
The old user journey for the kiosk. Angelina encounters the kiosk at a store. She feels uneasy entering her contact info to send to a locksmith, but she does it in the end. However, when the locksmith reaches out to schedule a call to gather more info, she forgets to respond.
Customers may feel uncomfortable sharing their name, email, and phone number with a locksmith without knowing what to expect next. The locksmith also has to chase after the customer to get all of the details required for the job.
The old task flow for the web portal form, part 1 of 4. The customer finds the form online, lets us know that they have a working key, enters their address, and enters their contact info. The old task flow for the web portal form, part 2 of 4. The customer selects the make, model, and year of their car. Then, they choose an igntion type and indicate if they have buttons or not. After that, they share more info about their situation, like if they have proof of registration. The old task flow for the web portal form, part 3 of 4. The customer selects their preferred date and time for the appointment, pays for their order, sees a success screen, and receives a confirmation email with their receipt. The old task flow for the web portal form, part 4 of 4. The locksmith reaches out to the customer to schedule an appointment. Then, the locksmith visits the customer and duplicates their key.
The current web portal form design is cluttered. Buttons with images are clunky, and the Preferred Scheduling step is unintuitive - the box is checked and the date/time selector isn't visible by default. Some questions that would disqualify the customer from service are included late in the flow instead of at the beginning, causing a poor user experience.
The old task flow for the kiosk. The customer enters their make, model, and year. They are then takeen to a page where they learn about KeyMe's vehicle key duplication service compared to that of a dealership. The customer then enters their contact info to send to a locksmith. The locksmith reaches out later to schedule a call and gather more info.
The current kiosk flow doesn't provide enough info about the process for the customer to trust us, and the locksmith has a difficult time gathering the info they need.
Design Research

Additionally, we studied precedents and design heuristics, then used those to further audit our current designs. We couldn't find examples from competitors, but we did study long, step-by-step flows from other companies.

Examples of forms and navigation. Typeform has a simple interface where only one question is shown at a time. Vanguard onboarding, Amazon checkout, and Google Play Academy use accordions to chunk info. Onboarding forms for Chase and Charles Schwab and a Yahoo job application hosted by Workday demonstrate different styles of progress bars.
Examples of onboarding, checkout, and wizard flows. They traditionally require multiple steps and input fields, yet they make long processes feel manageable.
Reasons to use a wizard UI, design recommendations for wizards, and form design best practices - provided by Nielsen Norman Group and Baymard Institute.
Wizard and form design heuristics from Nielsen Norman Group (NN/g) and Baymard Institute.

Ideation: Better web form navigation and connecting kiosk to mobile

Based on our research, we brainstormed several different options for the web portal form and kiosk experiences.

Web Portal Form

Our ideation for the web portal form focused on the navigation system between steps. We explored different questions, orders of questions, and question formats as well.

Four ideas for form navigation: The current accordion style; a thicker, more spaced-out accordion style; a simple progress bar; and a progress bar with discrete, labeled steps.
Different ideas for form navigation. Some required a higher LOE but provided better UX, while others were easier to implement but weren't as ideal UX-wise.
Analysis of the question order of the existing form and how it can be converted into a more logical order.
Examples of changes to questions and the order of questions.
Kiosk

The kiosk is more sensitive to changes and requires a longer release cycle, so we didn't explore any large layout changes - only minor changes to copy and imagery. We did consider linking to the form via a QR code on the screen vs. asking the customer for their mobile number. However, the QR code could've caused accessibility issues, and we would've had to test libraries for generating unique codes. The mobile number input was the safest choice and the lowest level of effort (LOE) for the time being.

Ideas for changing the first page in the flow on the kiosk - where the customer is told they will need a locksmith. Both display a list of key points or steps and the savings compared to a dealership. However, one displays the list horizontally while the other does so vertically.
Design variations for the first page where the customer learns that they will need to book a locksmith. We could use this page to explain the process or key benefits of our service.
Ideas for changing the second page in the flow on the kiosk - where the customer gets access to the web portal form. One idea is to display a QR code that the customer can scan, while the other is to display a field for accepting their mobile number. The QR code idea is crossed out.
Design variations for the second page where the kiosk directs the customer to the web portal form, either by scanning a QR code or entering their mobile number. We decided the QR code might lead to accessibility issues, so we opted for the mobile number input instead.
Design System

One detail that users noted was that the kiosk's and web portal form's UIs looked very different, as if they were from different companies. We tried designs where the kiosk's more colorful design system matched the web portal form's more minimalist design system - and vice versa. However, changing the kiosk to match would've taken too long. On the other hand, changing the web portal to match would've resulted in color contrast issues. Therefore, we kept both design systems as-is for the time being.

The kiosk's blue and red color scheme applied to two form designs. The web portal form's blue and yellow color scheme applied to two pages on the kiosk.
How the kiosk and web portal form would look if they had the same design systems.

Prototyping: Separate form pages with a progress bar performed best

We tested the web portal designs and kiosk designs separately with our users and locksmiths, then combined the best-performing designs from each into a single prototype for final testing.

The key takeaways were:

  1. Our users preferred separate pages for each step/section in the form, and they liked the progress bar that displayed each step with its label.
    1. Even though it would require a higher LOE, the progress bar made the form least overwhelming while still providing transparency.
    2. The accordions occupied too much space vertically and felt too busy on mobile. They might have worked better if the form had fewer steps.
  2. On the kiosk page with the key benefits, the key benefits in the same row were easier to digest instead of in three separate rows.
  3. Our locksmiths said the form needs to ask for the customer's general availability, not a specific date and time.
    1. Locksmiths can't guarantee that the customer's chosen date and time are available, so they need a range of dates and times instead.
    2. Therefore, we can only collect the customer's preferred days of the week and time periods (morning or afternoon).
  4. If a customer was coming to the form from the link provided by the kiosk, the form needs a "Welcome" page to connect the two.
    1. It serves as a transition and sets expectations for the key duplication process.
    2. We wanted to add a Welcome page for both the web-only and kiosk-to-web customers, but we received some pushback for the former. After some discussions, we decided we would release MVP without it for the web-only flow, then consider adding it post-MVP.
Four ideas for form navigation: The current accordion style; a thicker, more spaced-out accordion style; a simple progress bar; and a progress bar with discrete, labeled steps. All of them are crossed out except for the one with the progress bar with discrete steps. Ideas for changing the first page in the flow on the kiosk - where the customer is told they will need a locksmith. Both display a list of key points or steps and the savings compared to a dealership. However, one displays the list horizontally while the other does so vertically. The one with the vertical list is crossed out.
Winning web portal form navigation and kiosk designs.
The 'before' and 'after' state of the Scheduling page in the web portal form. The 'before' state asks the customer to pick a specific time or date. The 'after' state asks the customer to select the days of the week and the time periods - morning and/or afternoon - that they prefer.
The specific date and time input question changed to two separate questions about general availability. One asks about the customer's preferred days of the week, while the other asks about their preferred time period of the day.
Where the Welcome page would be added to in the kiosk-to-web flow. It would be after the customer receives the SMS with the form link but before the Car & Key page. Where the Welcome page would be added to in the web-only flow. It would be after the customer finds the web portal home page but before the Car & Key page.
Adding a Welcome page to the beginning web portal form eases the customer into the flow and sets expectations. Due to constraints, we only included it if the customer came to the form from the kiosk, not if they came directly from the web (e.g. through a search on Google or from our website).

We updated the designs accordingly, collected feedback to make sure the designs matched expectations, and got sign-off to begin.

Development: More questions added, mobile navigation compromise, and additional redesigns

During implementation and user acceptance testing, we found more changes to make to the form:

  1. Ask the customer for their car color and if their car has remote start.
    1. Although car color shouldn't affect the key itself, locksmiths need to collect it to verify that the car belongs to the customer requesting service.
  2. On mobile, convert the horizontal progress bar to a dropdown for easier implementation.
  3. On the Welcome page, add a checkbox for the customer to check after reading the list of items they will need to bring to their appointment.
    1. By checking the box, the customer confirms that they understand that they will need to bring these items.
The Car & Key questions before and after new questions were added. The questions added ask about the color of the car and if the car has remote start.
The questions about car color and remote start were added to the first page, Car & Key. While they increased the amount of effort for the customer, they were necessary details for the locksmith team.
The 'before' and 'after' state of the navigation system in the mobile version of the form. Before, it had a detailed progress bar with labeled steps that required horizontal scrolling. After, the navigation was converted into a dropdown featuring every step.
A dropdown required more interactions to use, and progress may not have been as obvious compared to the horizontal progress bar. However, it was easier to develop and removed the need for horizontal scrolling.
The Welcome page before and after the confirmation checkbox was added.
To make sure the customer read the details on the Welcome page, we added a checkbox that they needed to check to proceed.

We were also asked to update the price displayed on the form and kiosk and create an email to be sent when an appointment has been confirmed.

While implementing all of the requested changes and gathering approval, we had spare time, so we also updated two other areas in the portal:

  1. The Vehicle Lockouts service request form. We applied the same design system as Vehicle Key Duplication for consistency.
  2. The Order Status feature. Not only did we update the design system to match, but we added more granular statuses for more transparency and made the feature more mobile-friendly.
The Lockouts form featuring the same design system as the Key Duplication form - navigation type, colors, layout, etc.
We updated the design of the form for vehicle lockouts to match our new form for vehicle key duplication.
The Order Status page before and after updates. Before, it only featured three different statuses with little detail. After, it featured more detailed statuses.
Previously, the Order Status feature only had three general statuses and didn't provide enough info. Now, it has more specific statuses and is more readable on mobile.

Results: 400% increase in jobs booked for vehicle keys

Within two weeks of the new web form's release, the number of locksmith jobs booked for vehicle key duplication increased by 400%. Although the conversion from kiosk to web (getting customers to input their mobile number and open the form) wasn't as high as we had hoped for, the conversion from the web form was much better than expected. Therefore, we considered this project a success.

We noticed that within the form, the biggest dropoff points were:

  1. From Car & Key to Service Location
  2. From Service Summary to Checkout
  3. From Service Location to Scheduling

so we made a point to address these in post-MVP.

The new user journey for the kiosk to web experience, part 1 of 2. Angelina notices the kiosk at a store and tries it out. She feels comfortable entering her mobile number to get the form. The form seems long at first, but she then realizes that each step is short, and she fills out the form quickly. The new user journey for the kiosk to web experience, part 2 of 2. The locksmith reaches out to Angelina with a proposed date and time based on her preferences, and she accepts. He later reminds her of the appointment the day before and on the day of. Angelina brings the required items and the key duplication process goes smoothly.
With the new kiosk and web portal form experiences, we appear more trustworthy, the customer has an easier time filling out the form, and our locksmiths have an easier time booking jobs.
The new task flow for the kiosk to web experience, part 1 of 5. The customer enters their make, model, and year. They then learn more about the process and enter their mobile number into the kiosk. The kiosk then texts them the link to the web form, and the customer looks at their mobile device to view the text. The new task flow for the kiosk to web experience, part 2 of 5. After the customer receives the text from the kiosk and opens the web form, they are greeted by a welcome page explaining what to expect and what is required. They confirm the car info they entered into the kiosk earlier, then provide an address to meet at. The new task flow for the kiosk to web experience, part 3 of 5. The customer selects the best days of the week and times of day to meet at and enters their contact info. Once the customer has entered all of their car, address, scheduling, and contact details, the form shows a summary of the info they entered. After reviewing the info, the customer proceeds to checkout. The new task flow for the kiosk to web experience, part 4 of 5. The customer enters their payment details and submits their request. They see a success screen with their order number and a reminder of what happens next. Then, they receive an order confirmation email. The locksmith then reaches out to the customer to confirm a date and time for the appointment. The new task flow for the kiosk to web experience, part 5 of 5. The customer receives an appointment confirmation email. Finally, the locksmith meets the customer on the set date and time and duplicates their vehicle key.
Comparison of the form on small screens like mobile devices vs. large screens like laptops. The mobile version features a dropdown for navigation between pages, whereas the desktop uses a progress bar with all steps visible at the same time. Additionally, some related fields - like make, model, and year - are displayed side by side on large screens instead of top to bottom.
The form is also desktop-responsive for customers that prefer to fill it out on their computer.
The main change to the kiosk was sending a text message to the customer with the form instead of just accepting their contact info to forward to a locksmith. This made both the locksmith's and the customer's experiences less frustrating.
The main change to the web form was chunking and reordering the questions into separate pages instead of displaying them all on the same page. This made the process of requesting a locksmith feel less overwhelming to the customer.

Reflection: Get outside feedback, finalize requirements before implementation

Considering the project scope and limitations, it went fairly smoothly. If we were to do this again, we should:

  • Get 1-2 paid users not affiliated with or familiar with us to go through the entire kiosk and web portal form flows and gather their feedback. The more user feedback, the better, but we need to keep budget and time constraints in mind.
  • Finalize the requirements and list of questions with the locksmith team before implementation to reduce the number of last-minute changes.

Next Steps

  1. Get user testing for both the web portal and kiosk flows to investigate the three biggest points of dropoff.
  2. Add a Welcome page to the form for web-only customers for consistency and transparency.
  3. Plan the implementation of a unified design system across kiosk, web portal, website, email, and other touchpoints.

Links

Locksmith service request form for vehicle key duplication Locksmith service request form for vehicle lockouts Order Status tracker Return to Gallery