Turn Car iOS App Return Feature

*Please Note: Some content in process images and artifacts may have been altered in order to protect confidential information.

Product Overview

Turn Car is a car subscription service offered online through web, iOS, and Android platforms. With Turn, you can subscribe to a car for as long as you want and receive included benefits such as basic maintenance just by paying a Starter Payment and Monthly Payment.

Project Intro

After launching the Turn Car MVP app with the basic functionalities needed for a user to subscribe to a car first, it was time to build out more advanced features and design a service that would address future pain points in the customer’s journey, specifically returning a car.

Prior to designing and implementing the return user flow and service, the only way for customers to return their car was to submit an inquiry form through the app and await a call from a customer support representative to follow up with them manually.

However, after the MVP launch, a more full fledged in-app return user flow and service became a higher priority to increase convenience for users approaching the return phase as well as efficiency for the internal team to process returns.

The Opportunity

Without a more efficient digitized return service, handling returns would be a slow and laborious process that could potentially diminish the overall product experience for the user and efficiency for the business due to the limited amount of internal staff and tools available at the time.

This looming problem thus provided us with a solid opportunity to help both the user and our internal team through the return service design.

My Role

Working with 2 iOS engineers and 1 backend engineer, I was the main product designer for the return feature’s flow and interface (including the visual+interaction designs and UX writing) in the consumer facing app and for the return management flow and interface in the internal facing app.

Additionally, with guidance from my manager, I also provided suggestions for the overarching service design necessary to create a more holistically positive return experience for the user.

Scoping Out Requirements + Constraints

In order to tackle the return feature, I met with the product owner to get a basic understanding of the business requirements first and inform what the user can expect to experience at a minimum for the return flow.

After this initial meeting, I mapped out a rough flow chart to help improve the efficiency for a kick-off meeting with the frontend and backend engineers.

PICTURED: I drafted a quick flow chart illustrating the customer’s required actions, the internal operator’s required actions, and which platforms those actions needed to happen on to help with discussions at the kickoff meeting. Internal facing inf… — **PICTURED:** I drafted a quick flow chart illustrating the customer’s required actions, the internal operator’s required actions, and which platforms those actions needed to happen on to help with discussions at the kickoff meeting. *Internal facing information has been omitted for confidentiality purposes.*

Through the meeting, it became clear that the return feature would involve many moving parts beyond just the consumer facing app to create a holistic return experience for the user.

In addition to the consumer facing in-app return feature, the other parallel pieces that would be required to create this holistic return experience included:

New features in the internal dashboard to process returns.
A new internal facing app for the customer support representative to use out in the field.
Some new tasks that the customer support representative would need to undertake during the return process.

I also learned of the technical and operational constraints we would face which would require the return feature to have multiple phases in order to address how the feature might evolve as each of those constraints become gradually lifted.

With this knowledge, I knew that I needed to design the return feature with all these pieces in mind, being careful to think about how they all interact with one another to create the return experience.

Drafting the Consumer Facing Feature

Taking the business and technical requirements, I then synthesized them with additional requirements that might address some user concerns while using the return feature.

Some of the questions that I focused on while designing were:

How might we provide some helpful answers to questions a user might have while initiating a return in the app?

How might we prepare users for the ultimate car handoff so that they don’t feel lost at the day of handoff?

How might we make users aware of any potential charges they may need to settle to complete the return?

Using these questions as guidance for my design decisions, I then sketched up some initial low fidelity layout ideas to review with my manager before mocking up the following iteration in higher fidelity wireframes of a happy path that would capture the initial requirements and show the basic content and user flow.

PICTURED: A rough initial sketch of the return form flow of the return feature. I also captured running thoughts I had for potentially useful future features/functions related to returns. — **PICTURED:** A rough initial sketch of the return form flow of the return feature. I also captured running thoughts I had for potentially useful future features/functions related to returns.

PICTURED: Screenshot of the wireframes of an early iteration of the flow I created for initial feedback from my manager and the developers. — **PICTURED:** Screenshot of the wireframes of an early iteration of the flow I created for initial feedback from my manager and the developers.

With the wireframes of the happy path, I was then able to have an early meeting with a developer to review for any initial technical feasibility issues that they might be able to advise on. Together, we were also able to think of some additional use cases and edge cases to account for after having a clearer picture of the happy path.

Moving to High Fidelity

Using feedback from the developers and my manager, I moved on to the following high fidelity iteration and prototype with the full visual and interaction design along with UX copywriting. This higher fidelity prototype would then continue to go through a cycle of review with the stakeholders, spinning off additional iterations as needed until we landed on the solution to implement for this first version of the consumer return flow.

Thanks to the groundwork my manager and I had previously laid out for our foundational design system, I was able to design the high fidelity mockups with greater efficiency without sacrificing accuracy.

Some of my main priorities for the visual and interaction designs in addition to usability and accessibility were to ensure that I was accomplishing the following:

Capturing the different use cases depending on whether a user has one, multiple, or even zero car subscriptions by designing for these varying types of users and scenarios.
Increasing chances for the user to receive a strong enough information scent to understand what to expect for the return process by sprinkling in contextual tips and messaging.
Accounting for any known edge cases, empty states, and error states by providing design specs and copy for those cases and states in addition to the happy path.

PICTURED: An example of a part in the flow that needs to consider how many cars the user has. In order to communicate which screen to show depending on the user’s condition, I ensured that the logic for these use cases were captured along with the a… — **PICTURED:** An example of a part in the flow that needs to consider how many cars the user has. In order to communicate which screen to show depending on the user’s condition, I ensured that the logic for these use cases were captured along with the appropriate UI.

PICTURED: A common concern with errors is that, if left unidentified, the system message can be very unfriendly and difficult to understand so I worked with a developer to address as many as we could catch on our own and provided more human-friendly… — **PICTURED:** A common concern with errors is that, if left unidentified, the system message can be very unfriendly and difficult to understand so I worked with a developer to address as many as we could catch on our own and provided more human-friendly copy to use.

PICTURED: An example of the dynamic Return Details screen that I designed for with a goal of providing strong information scent for the user to understand its changing states through updated messaging and visual cues. — **PICTURED:** An example of the dynamic Return Details screen that I designed for with a goal of providing strong information scent for the user to understand its changing states through updated messaging and visual cues.

Designing a Service

As mentioned before, the return service required multiple pieces to function as a holistic experience. The consumer facing app was just one piece.

In order to address that, I also worked on the internal facing tool app that would be used by the customer support representative in person at the point of car handoff to complete the final phase of the user’s return journey.

Additionally, I worked on a rough service design to document all the moving parts within the organization that would be required to create the holistic return experience beyond just the consumer app. The service design captured what and when the internal processes would be triggered upon the user’s initial return submission in-app and required to complete the return journey.

PICTURED: A short snippet of a possible path from the internal facing returns management app tool showing a glimpse of how user input from the consumer app flows into the internal app. — **PICTURED:** A short snippet of a possible path from the internal facing returns management app tool showing a glimpse of how user input from the consumer app flows into the internal app.

Handing Off the Solution

In order to communicate the final product designs to the stakeholders, developers, and QA, I created prototypes and passed over design specs through InVision, where the developers were then able to use the Inspect mode to get granular details into the visual and interaction designs.

I also mapped out the user flow diagrams through Overflow.io which was then used to communicate the flow of the happy paths and varying use cases from a bird’s eye view.

PICTURED: User flow diagram of the consumer facing return flow I created through Overflow.io which was shared with stakeholders, developers, and QA to communicate the final flow. — **PICTURED:** User flow diagram of the consumer facing return flow I created through Overflow.io which was shared with stakeholders, developers, and QA to communicate the final flow.

PICTURED: Animating the expand+collapse interaction of an estimate through InVision helped developers easily understand how the actual implementation should flow. — **PICTURED:** Animating the expand+collapse interaction of an estimate through InVision helped developers easily understand how the actual implementation should flow.

Reflections

This first version of the return service was a speedy deliverable due to business objectives, and as with many situations where time is of the essence, there were some parts of the process that I would do differently if we had infinite time and resources.

If I was able to work on the following versions of this return service, I would do the following things now with the experience and learnings that I gained through designing this first version.

Testing with users.
I definitely would have liked to work with some potential users to test the usability and usefulness of the prototype prior to implementation to reveal any issues we overlooked earlier on.
If I worked on the following version of this return service, I would strongly recommend conducting an evaluative testing session to access the usability of this first version and use that insight for the second version.
Defining tracking events.
I would have worked with the developers to outline potential tracking events throughout the flow that may be helpful for us to obtain insight into any usability issues that users encountered while going through this flow.
“Out in the wild” research.
Post first-version launch, I would have loved to shadow a customer support representative throughout one user’s return journey to understand both the user’s and the internal team member’s experiences with the return service as a whole from return request submission to actually collecting the return in person.

Overall though, I really enjoyed designing for these multiple constraints, discovering how the digital app is just one touchpoint in a user’s entire experience with a product, and thinking about how it relates to all the other touchpoints in the service.

Have Questions?

Of course, this summary is just the tip of the iceberg for a peek into the behind the scenes of this project.

If you’d like to chat more about it, send me a note and I’d be happy to discuss further!