Product Overview

What is Rivian ServiceOS? Rivian ServiceOS is the platform used by Rivian’s Service Center technicians, managers, vehicle advisors, among others, across the United States, to provide service to all consumer and commercial EVs bought from Rivian along with its fleet (EV and gas powered).

What can you do with this tool? Anything vehicle service related. From accessing vehicle information, full work orders completion, payment approval and transaction, vehicle inspection, parts management, to virtually locking and unlocking a vehicle.

Rivian ServiceOS is available for desktop, iPad, and iPhone devices only. Each platform, desktop and mobile, has its own set of users and use cases. ServiceOS for desktop is meant for high level Service Center managers and SSAs (Service and Support Advisors) to support customers when they call for service.

ServiceOS Initial Design

As the Enterprise and Fleet design team was being built, some of the team members already established started working on the desktop version of ServiceOS. So far, all internal tools have been designed for desktop first and then, if needed, extended to mobile.

In the case of ServiceOS, this was going to be a platform that must have a mobile version due to the nature of the type of service Rivian offers to its customers. With that in mind, some months later a designer dedicated for mobile was added to the team.

At Rivian, most projects are Product Manager led. For ServiceOS in particular, the project was led by a Sr. Product Manger expert whose approach to the mobile version of the product was very similar to the desktop version.

In the image above, you’ll see three different screens. Two of them pertain to the same level in hierarchy and one of them to the next level. Both levels use the same navigation structure, very similar to the desktop version’s side nav. The intended purpose of this was to maintain the mobile design as close as possible to the desktop design to keep the users used to a familiar interface if they go from desktop to mobile and vice versa.

User Personas

For ServiceOs for mobile, we have two main users: Vehicle Technicians and Service Center managers. Even though their jobs are completely different, both users will relay on the tool for their day to day tasks.

Vehicle service technicians will have to balance themselves out between in-service center appointments and mobile service appointments, being the later the main focus of Rivian customer service approach to customers.

To do their jobs efficiently, vehicle service technicians will need a reliable, fast, and easy-to-use tool they can carry anywhere they go to service a Rivian vehicle.

On the other hand, Service Center managers need to know the current status of all appointments, who’s working on what, the ability to assign a technician to any job without having to go back to the office to use the desktop version of ServiceOS, .

User Feedback

The team presented this initial version to a small group of future users at a Service Center in El Segundo, California.

To conduct this user testing exercise, a GoPro camera was placed 10 feet above the user to observe how he would interact physically with the device and the tasks he needed to complete to inspect the vehicle.

Besides the camera, the device screen was recorded along with audio so the Technician could walk us through the whole process while providing details about his experience with the ServiceOS app, especially those areas of high friction.

After finishing the user testing, the feedback was mainly confusion.

This feedback referred to the main navigation at the top. Both, at the Work Order and Service Request levels, had Overview as the first option, from left to right. Although with some differences, at both levels the user would find Parts as part of the nav, also causing confusion.

Going through a work order from start to finish requires that the technician performs certain tasks in a certain order. The initial design didn’t provide for this. The user had to know by memory what needed to happen next and the workarounds for some specific situations, like changing a pay type or re-sending a billing authorization.

However, the users were able to see the potential of the tool and how it would impact their day to day work.

User Challenges

When it comes to the users’ daily work, some of their main challenges are:

• Close a vehicle work order as fast as possible to accommodate or be able to service more vehicles in one day. Or just fulfill the appointments scheduled for the day.

• The use of different tools to complete their jobs such as Excel sheets, whiteboards, Slack channels, and paper.

The need to perform different tasks in the shortest time possible is key for job efficiency. To be able to do this, the Service Centers team have come up with different solutions that have worked partially but that aren’t efficient.

After putting in front of potential users the first iteration of the product, these are the challenges they encountered:

• ServiceOS design for mobile was confusing as the navigation structure was very similar at work order and service request levels.

• Users were not clear of the order of the tasks they needed to complete close out a full Work Order.

To better understand the ideal order of a Work Order flow in ServiceOS, I put together a diagram showcasing each step (starting from left to right) and the tasks that fall under it. When design time came about, I used the diagram as a reference.

Solution

To tackle the problems the users are currently facing, we came up with three main solutions:

• Design screens that provide a sense of an order and organization.

• While maintaining an order, design both work order and service request screens different to avoid confusion.

• Show clear task statuses to help the users know what has been completed and what’s left.

Sketches

I sketched some of the ideas I had in mind to quickly understand if they would be a good start for the overall concept of the “Progress” flow we were thinking of. Also, to analyze if the idea would fit with the design system already in place.

Explorations

After sketching some ideas, I jumped into Figma to explore the visual possibilities within the already established design pattern and system.

I usually start designing for iPhone first. It’s easier to go from small to big. That’s why all my explorations were done for iPhone.

In the original concept, I had thought of implementing a notification system that would tell the user exactly what should happen next along with alerts for when a task had to be completed in order to move forward.

This idea was later discarded due to technical constraints. The “progress flow” concept had to be implemented in another way without using notifications.

Constraints

Some of the constraints we encountered, and still do, are:

• Being ServiceOS an internal tool, it doesn’t represent a direct revenue stream for the business. It’s more a business need, rather than a product they offer to customers. What happens with this is that the company doesn’t allocate enough resources or time to do research, market analysis, and user testing before launching the product.

• The need for the tool is urgent. This also contributes to the lack of research and testing. Also, there’s not much time to explore different concepts, prove the hypothesis, and go back to the whiteboard to refine what didn’t work.

• The product has been based on previous teammates experience and assumptions. Since, the product is fairly complex and it’s been created before for other vehicle companies, the business has decided to build its own Service platform based on people’s previous experience rather than going through the whole design thinking process or methodology. It has to comply with legal requirements, among other technicalities.

Next Steps

As we continue to design and build the tool, one of the next steps in the process is going back to the Service Center to put again the tool in front of the technicians to observe how they interact with the new design and collect their feedback.

This should be planned in a way that allows us not only to see the interaction with the platform at the Service Center level, but to see how the tool fulfills the needs of the technicians that service mobile service appointments.

This user testing should also include the so-called “A Day in the Life of a Technician” flow (currently in work-in-progress) which will provide a unique experience for those technicians who will be servicing vehicles wherever the customers are. Being this type of assistance the main way Rivian will service its customers' vehicles, it will convert this mobile-service-technician experience into one of the most used among all internal Rivian platforms.

Success metrics will also have to be defined. However, I see metrics like task-time completion, percentage of app usage, increment of mobile service appointments, and the number of active users as part of the main metrics we need to use to understand the level of success of the app.

And as with any product, this will be an ongoing process as long as the company decides to keep using the tool as its main system for vehicle service. New features, better designs, and innovative ways to improve service will come as Rivian evolves as a company and ServiceOS as a product.