Hassle-free car ownership

The online car shop, cinch, aimed to take the hassle out of purchasing a car for customers. The next step was to help customers take the hassle out of car ownership.

Photo by CHUTTERSNAP on Unsplash

Therefore, the aim of this piece of work was to understand what hassle-free ownership could be and how we could help customers achieve it, through various products and services.

Discovery

User needs

By speaking to customers on other projects, we had already identified that customers experienced a lot of various issues with car ownership, from having to reinsure their cars every year to unexpected repairs and maintenance.

To build on this, we started to speak with customers on more specific issues they faced and what services and products they currently used to solve them. Many said they found maintaining cars highly expensive, with lots of options to choose from. In addition to this, customer found that without having expertise, it is hard to know what service or product to purchase and if they are worth it.

With this insight, we started to focus on what services and products customers would add most valuable and what needs we need to design for, for example, transparency, flexibility and value for money.

Additional research conducted helped us understand which of the current vehicle products and services customers currently valued and which they didn't, from this research we identified that products like warranties and service cover were highly valued, however products like tyre and alloy cover were not.

This was mainly due to customers preferring to spend money on maintaining their car quality and fixing mechanical issues, over maintaining the appearance of their cars, especially in regards to used cars which customers would already expect to have some wear and tear. However, nearly all customers highlighted that all of the products and services would be a nice to have and wouldn't always be a priority for customers right away, even though they could see the benefit of them throughout their car ownership.

Business needs

By conducting stakeholder interviews and attending a group kick off session, we started to understand that the business needed to move beyond just selling cars, but to provide even more value to customers, through selling more products and services that could be added. The business identified it needed to be the destination for customers to resolve both their car purchasing and ownership needs.

To help understand how other businesses helped their customers manage the ownership of products, like cars, I completed competitor analysis across both automotive and non automotive industries. I looked at how competitors sold valued add products and also how they enable customers to manage products in account areas. Many companies offered additional products whilst in the checkout, which felt like a bolt on. Others offered additional products as part of bundles based on customer needs which helped customers see the value of them and therefore they were more inclined to purchase.

Defining the problem

By understanding both customer and business needs, the next step was to define the problem to solve. As a team, we gathered all the insight we had gained in discovery and began to form a problem statement that would help us design solutions. We had identified that the customers had a variety of issues with vehicle ownership, and the business wanted to help remove all of those issues for customers by offering affordable and valuable products and services.

This led to a fairly broad problem statement, which would also form the vision for the tribe: How might we [cinch] remove various car ownership pain by offering simple, easy to use, affordable products and services?

Along the problem statement, we also created guiding principles to help when designing solutions. These were: be customer centric, be data driven, be flexible, be transparent and to remove complexity. Through prioritisation of challenges to solve, we identified that there was a couple of products and services that we could deliver and have high impact with minimal effort. This would also enable us to test and learn from delivering a new proposition at cinch and build future products and services from. As a key pain in car ownership for customer was around protecting their cars exterior and interior to keep it in great condition, we decided to develop and deliver a car protection product for customers purchasing cinch cars.

Design

Designing for multiple products & services

To help investigate other services and products whilst we were developing our first, I worked on helping the team develop a service vision for customers purchasing and managing multiple services and products with cinch.

To start, I conducted desk research looking at how competitors have solved the problem of offering customers additional products and services alongside their main product. I began looking at direct competitors of cinch and then explored companies outside of the automotive world. I identified various approaches and documented them to share with the team. Many simply offer additional products within the checkout which can feel like an after thought and just a way for companies to bolt on extra costs. Others allow customers to build out a package to meet their specific needs, which feels more personal.

In addition to offering products and services, I also reviewed how companies helped customers manage multiple products in life. Many offered an app for customers to download and complete various actions related to their products, for example booking in a service for their car and viewing all past service history. In the case study of Tesla, if there is a software issue noticed the app will automatically send a message to a Tesla garage and guide you to book a service appointment. To add to this, if the issue can be resolved remotely the garage will send you a message and cancel the service appointment, providing an extremely useful and also hassle free experience.

From research and competitor analysis, I started to build out a holistic view for how the end to end service of offering multiple products could work. To do this, I ran through the end to end of the existing service and overlaid where the new service would touch. I mocked up concepts for customers purchasing one extra product, multiple products and for customers purchasing products without needing to purchase a car. This gave the team a framework to interrogate, build from and validate with users.

Designing a service for adding car protection for cinch cars

Whilst looking holistically at the vision of multiple products and services, I also started to focus on designing the service for the first product we would be delivering to customers, which was the product to help customers maintain their paint, interior and glass quality (named cinchShield).

To begin, as a team we defined the optimum customer experience for the added product. I helped the team look at key touch points for customers, from discovering and learning about the product, adding it in the checkout, and then receiving the product (although invisible) on their cars before delivery. From this the UX team built out prototypes for the customer experience and tested with users to understand if the experience met their needs.

Through testing the customer experience design, we learnt more about the experience customers expected and where we needed to iterate the experience. For example, customers felt they needed more information about the product before coming across it in the checkout, as this felt more like an afterthought. By the product only being surfaced in the checkout, customers also felt they were less likely to purchase as they had already worked out budgets for their purchase and hadn't factored in any other costs. Using insights, we started to iterate the customer experience to better meet their needs.

After defining the customer experience, I started to design how the service would enable this experience. To do this I pulled out an existing service map and built the new service into it, linking it with the customer journey. From doing this, I could start to see which parts of the service needed to be linked up.

For example, a key part of the service was letting all the relevant teams know that a product had been added to the customers order and now needed to be applied to their car. This already existed in the service, but for a car only, therefore I identified that the added protection product needed to be added here too. I therefore collaborated with the team involved in communicating the existing message and the teams receiving it, to make sure each team had what they needed to make this part of the service work.

On the reverse the team adding the product needed to effectively communicate back to the other relevant teams that the product had been applied, so that customer experience and delivery drivers could reassure customers that the product had been added. Without this, we risked our teams not being aware of the product being successfully added as the product is invisible and thus increasing uncertainty with customers who cannot be sure the product has actually been added.

Once I had designed the service, the service blueprint I had created became a working document to help shape the service. It was used to talk through key touch points, co-design areas with multiple teams, define unhappy path scenarios and highlight risks.

With high risk areas, I worked with teams to co deign the service so it was less risky. We would then communicate this to stakeholders to get agreement that this was the right approach to take. An example of this was when customers wanted to cancel the protection product being be applied but not the car itself. The original solution was to cancel the full order and ask the customer to re order their car without adding the product. Using the service blueprint, I highlighted that we were at risk of losing the customer altogether by asking them to re-order as this meant they had to reschedule their delivery, potentially lose out on their finance agreement or at worse someone else buying the car before they have time to reorder it.

By playing back the service map, I helped facilitate collaborative decision making and help teams and wider stakeholders reach consensus on the way forward that met our customers needs. Playbacks also helped multi-disciplinary teams to reach the best outcomes by ensuring insights and ideas are shared effectively and that different work streams are aligned.

Delivery

Once the team had defined and validated cinchShield service design, the team used the service blueprint to define what would be the minimum that could be released to add value whilst being quickest to develop. For example, for the Phase 1 release, the delivery drivers needed to know that the product had been added to the car, so they could talk to customers about the product and answer any questions.

To do this in the leanest way, we decided the team responsible for planning deliveries would be sent an order confirmation with the added product and would then contact drivers and let them know which cars had the product. Whilst, this involved lots of manual process, we decided this would be viable for the first release where the amount of orders would be minimal.

However, when scaling up the amount of orders, this solution wouldn't be substantial as it would require lots of human intervention and would be at risk of information not being passed on. Therefore, I started to design a solution that would enable automated communication straight to drivers when an order was sent. This would form the Phase 2 service blueprint which would be released after Phase 1, to enable successful scaling.

Once we had defined the Phase 1 release, I started to build out more scenarios including both happy and unhappy paths. I mapped the various scenarios onto the core service blueprint and linked this to a scenarios table and raid log. We used both documents to run through with various teams and stakeholders to collaborate on solutions whilst moving into delivery. By having the document we could work through all possible scenarios and by having the map, we could see holistically of how the scenario might impact the customer and business.

As the service started to be developed, new requirements became apparent. To help navigate around new requirements, I would refer back to the service blueprint and gather relevant teams to discuss how to iterate the service, whilst always keeping a holistic view and keeping the customer at the heart of the service.