Overview

To avoid risk and ensure accuracy, Rivian’s B2B customers go through an extensive onboarding process before they are eligible to transact.

The current process is manual with information exchanged on disparate apps which makes the process time-consuming.

To solve for this, Account Manager orchestrates all steps of onboarding, streamlines the document collection process, and enhances the communication between Rivian and customers.

Type: Professional Work

Duration: 8 months

My Role: Lead Designer - Swimlanes, IA, UX wireframes, Customer Interviews

Tools: Figma, FigJam, Usability Testing

Current process

Internal Rivian users manually onboard businesses by getting information via emails/ phone calls and uploading on Box.

Due to a lack of digital tooling, key aspects aspects such as a thorough risk assessment are skipped.

The process is also prone to risks such as inaccurate customer data and potential engagement with entities that are not up to Rivian standards.

How might we onboard businesses efficiently that ensures accuracy and minimal risk?

The Solution

Introducing Account Onboarding as part of ‘Account Manager’ tool within RivianOS - an internal tooling used to manage B2B and B2C customers. The solution included 3 main features:

I. Account Creation

Allows internal Rivian users to create a B2B account on behalf of the customer, while having the ability to add/edit the info once the account is created

II. Request/Upload Document

To request documents from customer for credit check or upload on behalf of them

III. Risk Assessment

Allows internal Rivian users to verify the B2B account by conducting ‘Know your business’ and ‘Know your customer’ check

[This project only covers features 2 and 3 in detail, assuming that a B2B account has already been created.]

Design Process

The project had some initial designs when I started working on it. Here’s what my design process looked like:

I. Studying existing designs

My initial task at Rivian was to convert the existing low-fidelity designs to high-fidelity. While doing that, I laid the designs out to understand the flow.

I met with the PM to understand the onboarding process, and if the current designs were meeting business needs.

We also talked to Internal Rivian users to understand how the job is being done today, what are the pain points, and how can the solution build a seamless experience for them.

User Journey

A business called ABC Construction wants to buy x amount of R1Ts for their business. They contact Rivian to express their interest. Before they can purchase the vehicles, an internal Rivian user - Jim Shetty, who will kickstart this process.

Persona

Jim Shetty is an Account Manager at Rivian. He is the point person for any business that is interested in buying Rivian vehicles. He collects their info, create their account, and helps them onboard.

After understanding the typical onboarding journey and users we are designing for, I started reviewing the designs and highlighting my questions/ missing workflows.

Insights from existing designs

  • Onboarding is not entirely a sequential process.

    Risk assessment & credit check are, but not request/upload document

  • Documents are uploaded multiple times throughout the process

    Requesting/uploading documents is a back and forth process, and can be in tandem to third party checks

  • There can be multiple files within a document

    Earlier designs were created around the ‘one file per document’ assumption, which isn’t true

  • Lack of details for each onboarding step

    Designs do not show what information is being used to conduct the checks. Additionally, there are separate results for checks which are not presented in design

  • Users need the ability to configure documents [Additional Requirement]

    In current designs, list of document that need to be requested is fixed irrespective of business type. Some businesses can be skipped from certain checks

II. Information Architecture

Once the gaps were identified in the designs, I laid out a new information architecture that included the sub parts for each feature. Based on the new flow, I started working on the initial wire-framing to accommodate the design changes as well as feature enhancements.

III. New Designs

As mentioned above, the project deliverables focused on two main features. I) Requesting & Uploading Documents, and II) Risk Assessment.

Since both features were worked in tandem, they don’t follow the sequence shown below.

Feature I. Request & Upload Document

Use Cases

I want to request/re-request documents from a B2B customer

I want to upload files on behalf of a B2B customer

I want to take following actions: view/delete files

I want to know the status of a document: uploaded or not

I want to create an ad-hoc document for a specific category

Design Focus

  • Distinguish each Call to Action i.e, Request Documents, Add New Document, Upload File, etc.

  • Identify documents hierarchy

I started sketching out the workflows for all use cases like requesting documents, uploading files, viewing files, etc. Below are some of my rough explorations (shown just to represent the process)

Once I had some clarity on paper, I created a user flow that distinguished the three use cases - request, upload file, and add ad-hoc document.

For a specific step of onboarding, multiple documents can be needed, and one document can have multiple files. To simplify this in design, I created a hierarchy in the documents table

Below are the designs I created for Feature I: Request & Upload Documents.

Request Documents

Add Document

Feature II. Risk Assessment

Use Cases

I want to conduct ‘KYB’ (Know Your Business) and ‘KYC’ (Know Your Customer) check on a B2B Account

I want to view results of checks

Design Focus

  • Indicate the information needed to perform the check

  • Clearly present the details of the results

  • Displaying the complexity of verification checks in layman jargon

Types of Risk Assessment

Below are some of the explorations that I did for Risk Assessment. I showed the designs to our users to get some feedback.

Feature I (Document Upload) and Feature II (Risk Assessment) were worked in tandem. So, some of the explorations doesn’t have the find Document Upload designs.

User Feedback

Disabled ‘Input Fields’ are confusing

Can these fields be ever edited?

‘Upload Drivers License’ button still exists as a separate pathway

If there’s already a documents table, why do we need two ways to upload driver license?

Need role based access screens

In future, two separate personas would be requesting documents and triggering Risk Assessment

Based on the user feedback, I updated the designs and made the following changes:

  • Removed disabled input fields for ‘User Name’, since they cant be edited.

  • Restricted Upload document workflow to only documents table

Future Thoughts

  • Some Documents will have a template attached to it - How will that feature work?

  • Customized email template for re-requesting submissions

  • What will the Role-Based Access Screen look like?

  • Scalability of Risk Assessment

    • Right now, we are conducting checks on one contact from a B2B Account, what happens when we have multiple contacts?

    • Will we show all the documents in the table or will there be an option to archive?

My Learnings

  • Getting feedback on quick and dirty designs works great in a fast-paced environment. Don’t focus on fidelity of designs or getting too attached to an idea - be flexible!

  • Create flows - User Flows, IA, Swimlanes - to get clarity on how things work at system level

  • Bring in the engineering early in the process to understand technical constraints

  • Aim for North Star but scope down as and when needed