Ford Commercial Solutions

Ford Commercial Solutions is a telematics software tool which helps automotive fleet managers keep their vehicles up and running 100% of the time. 

CONTEXT

Our goal as consultants was to help our client create an MVP of their software while teaching them new practices of software development.

MY ROLE

Enable client designers with new methods of software design and development while assisting them in creating a Minimum Viable Product.

CATEGORY

Product Design, UI/UX

FCS wanted to create two products: a telematics software that would help to optimize your fleet and help your business run more efficiently, and a data tool which would leverage Ford's unique insight into their vehicles by delivering and deciphering data signals directly to you through integrated software or an API.

THE PROBLEM SPACE

At the time we were dealing with a few challenges:

01

Scalabity — How can we make our young software work for thousands of vehicles in the future?

02

Automation — how can we accelerate the process of onboarding vehicles into the software?

03

User outcomes — what are the main user pain points for fleet owners, managers, drivers, and dispatchers? What problems can we solve using Ford Telematics?

04

Data — how can we make sure the data signals we receive are accurate and timely?

THE TEAM

Our team was large, made up of about 5 feature teams distributed across two offices (Detroit and London). I was a product designer on two feature teams.

Those teams were "Setup & Admin" and the "Driver" team.

On the S&A team I was the sole designer, while on the Driver team I had a design pair. It was my job to enable her to understand agile software design practices while improving the software with her. 

On each team there was: 
(1) Product Owner
(1) Product Manager
(1 or 2) Product Designers
(4-10) Engineers

It would have been preferable to keep teams small, between 4-6 people, but our client wanted to scale quickly and felt that we needed to hire a lot of engineers quickly (though we advised against it, as we felt it would reduce the speed of progress and decision making). 

PRODUCT DESIGN

Overall, I worked on a team of between 5 to 8 designers (there was a lot of turnover during this six month project). Our responsibilities were:

DISCOVERY & FRAMING
Business Goals
Stakeholder Interviews
User Research
Workshop Creation & Facilitation
Service Blueprints

PRODUCTION
Defining Personas
Defining Pain Pts. and Desired User Outcomes
Creating Designs based on learnings
User Testing 
Research/Testing Synthesis
Continuous Discovery & Iteration
Story Writing

We call the Product Designer the "Empathizer-in-chief:" our job is to understand users in order to define solutions that are useful, usable, and desirable. We provide design education, direction, and leadership to our organizations as experts in design patterns. It is our responsibility to always check in with the vision and mission of the product and to make sure we are solving business goals as well as helping users achieve their desired outcomes. 

TEAM VISION

In order to ensure our team was always on the right track, I organized a team Mission & Vision workshop to help us define what outcomes we wanted to acheive with our feature.

This was the result:

VISION STATEMENT

Ford Commercial Solutions will allow Fleet Managers access to the data and tools that will aid them in maximizing the uptime of their fleets.

AREAS OF FOCUS

Access Management — who can access what and when.

Billing & Payments — billing for the subscription.

Account Information — i.e. Business name, business type, address, payment method, etc.

FEATURES

Creating Accounts — Who can access what for whom.

Billing & Pyaments — billing for the subscription.

Onboarding Vehicles — Create, Review, Update, Delete Vehicles and view their status.

THE APPROACH

Here I'll focus on one problem we solved on the Setup & Admin team in relation to Access Management.

As our research and work continued, we started to realize that different types of users would need different types of access to our software. There is a difference in the hierarchy of employees within an organization based on Industry and number of employees, as well as other factors. There is also the possibility of there being multiple locations or employees who oversee multiple locations. 

We conducted interviews with several different types of organizations, from small construction companies to large city Police departments, to come up with these evidence based personas:

PERSONAS

A CLOSER LOOK

DEMOGRAPHICS
Dispatcher
35 Years Old
Ann Arbor, MI, USA
3 Years working with current fleet

GOALS
Wants drivers to get to customers/drop-offs on time
Wants to optimize the assignments of drivers to pick-ups

NEEDS & PAINS
Needs to see where drivers are on a map
Needs to set driver schedules
Needs to dispatch vehicles to drivers daily
Needs to mmonitor drivers' curent locations
Has a hard time prediciting when drivers will arrive to job sites
Needs an efficient way to know which Drivers are available

USER RESEARCH

To better understand how our users structured their Organizations, we scheduled user interviews. We interviewed companies of various sizes, from a small construction fleet of 15 vehicles to a police fleet of nearly 500.

TEST PLAN
Fleet Manager / User Hierarchy Interview

GOALS

• Understand the hierarchy of roles in a Fleet Manager’s business
• Understand what roles need access to what information

HYPOTHESIS

We believe that different users need access to different types of information based on their roles in the fleet.
 

METHODOLOGY

• Conversation (20 min)
  • Open-ended questions to drive dialogue in order to understand the needs around access management.
• Card Sorting Activity (15 min)
  • Give users a variety of roles and understand how they would organize the hierarchy based on their fleet.
    
    

INTERVIEW QUESTIONS
Sample Question: Demographic / Day in the Life

Who do you trust to manage overall fleet operations? (Billing transactions, ordering vehicles, etc.)

Specifically, who besides you is allowed to handle:

• Billing?
• Buying vehicles?
• Decommissioning vehicles?
• Hiring and dismissal of employees?

I used a program called Optimal Workshop to give each interviewee a series of Admin roles and organize them based on who they believed would need the priveleges we aligned with each role. 

RESEARCH RESULTS

These are the roles we were able to define after the card sorting activity. For each role, the person that would fulfill that role in the system would be able to do the related tasks. For example, only the "Owner" should be able to create or remove entire Fleets, and this Owner would probably have a title like "Operations Manager". These interviews directly informed the roles we created in order to provide fleets of various sizes with the flexibility of controlling access to different features within the software.

POTENTIAL SOLUTION

As a potential solution, using our learnings from our user interviews, we created prototypes that we could test with users. 

Build. Measure. Learn.

 Our goal was to build a feature into the software weekly (an MVP version), test it, learn from it, and revise it or scrap it alltogether. When we couldn't do that, we would prototype in Invision and test it that way. We had weekly interviews with the same customers so that we could continue to get valuable feedback on changes that we made.

After testing this feature, we learned that some fleets define their offices by location and others by a certain name, so we started working on how that might alter our design in order to test it again the next week (previously we had only considered location). 

We also realized that Fleets may want to customize which role had access to which features, so we started to design a more modular solution in their Settings — with this solution, I could choose which role could do what, and then assign those roles to people in my company.

Everytime we wrote stories for the engineers, we wanted to slowly build so that we could make quick progress. We gave them designs/stories based on the smallest amount of value we could deliver to the user in the shortest amount of time, and then built on that. For example, the first step in making these changes was just to show the user's name in the top right corner so that they knew that they were logged into their own account.