View CV

‘21 - ‘22

Gett

Travel policy settings
redesign

Role

Product Designer

Team

B2B (accounts management)
Account settings, travel policy and reporting

Context

Gett is mainly focused on corporate Ground Transportation Management. They organise corporate fleet, taxi, ride-hailing and limo providers on one platform, optimising the entire employee experience, from booking and riding to invoicing and analytics, saving businesses both time and money.

Travel Policy Challenge

Gett platform allowed setting rules to limit employees' rides which were out of the company’s interest. Company administrators could control vehicle types, time, location, destination and area. These rules were organised as travel policy groups and could be assigned to employees.

Although setting travel policy could potentially save clients money, only 36% of clients had travel policy groups added. They couldn’t figure out how to set rules and often asked for explanations from account managers.

Gathering data insights

As one of the clients complained about complexity, firstly I decided to see if we could potentially reduce the number of settings.

I asked analytics team to investigate adoption level per each setting to see whether some of them could possibly be dropped. We found that:

The most popular setting was Vehicle type
Only 5% of companies set up Area, Distance or Location rules
Only 2% of companies had multi-scenario Travel Policy groups
Less than 1% of companies used Travel Policy scenarios for guests rides

I examined 40+ accounts with rare settings to see how they were used.
Area, Distance, or Locations were mainly used by big and profitable clients, while others, even though created, were rarely applied.

I shared results with my Product Manager, and we agreed to remove guests group and multi-scenarios option.

I asked analytics team to investigate adoption level for all travel policy settings to see whether some of them could possibly be dropped in the new version:

The most popular setting was Vehicle type
Only 5% of companies set up AreaDistance or Locations rules
Only 2% of companies had multi-scenario Travel Policy groups
Less than 1% of companies used Travel Policy scenarios for guests rides

I examined 40+ accounts with rare settings to see how they were used:

Area, Distance, or Locations were mainly used by big and profitable clients
Multi-scenario settings were mostly mistaken for rules, only several companies used them as intended
Guest rides setting exploration showed that even though created, such rules were rarely applied

I shared results with my Product Manager, and we agreed to remove guests group and multi-scenarios option.

I asked analytics team to investigate adoption level for all travel policy settings to see whether some of them could possibly be dropped in the new version:

The most popular setting was Vehicle type
Only 5% of companies set up AreaDistance or Locations rules
Only 2% of companies had multi-scenario Travel Policy groups
Less than 1% of companies used Travel Policy scenarios for guests rides

I examined 40+ accounts with rare settings to see how they were used:

Area, Distance, or Locations were mainly used by big and profitable clients
Multi-scenario settings were mostly mistaken for rules, only several companies used them as intended
Guest rides setting exploration showed that even though created, such rules were rarely applied

I shared results with my Product Manager, and we agreed to remove guests group and multi-scenarios option.

I asked analytics team to investigate adoption level for all travel policy settings to see whether some of them could possibly be dropped in the new version:

The most popular setting was Vehicle type
Only 5% of companies set up AreaDistance or Locations rules
Only 2% of companies had multi-scenario Travel Policy groups
Less than 1% of companies used Travel Policy scenarios for guests rides

I examined 40+ accounts with rare settings to see how they were used:

Area, Distance, or Locations were mainly used by big and profitable clients
Multi-scenario settings were mostly mistaken for rules, only several companies used them as intended
Guest rides setting exploration showed that even though created, such rules were rarely applied

I shared results with my Product Manager, and we agreed to remove guests group and multi-scenarios option.

Inside interviewing

I interviewed our account managers to discuss clients' feedback they were receiving. The most common complain was UI complexity, but they shared interesting insights:

Some clients wanted to allow out of policy rides in emergency cases
Account managers were skeptical about the travel policy as it could potentially reduce the number of rides

I interviewed our account managers to discuss clients' feedback they were receiving. The most common complain was UI complexity, but they shared interesting insights:

Some clients wanted to allow out of policy rides in emergency cases
Account managers were skeptical about the travel policy as it could potentially reduce the number of rides

I interviewed our account managers to discuss clients' feedback they were receiving. The most common complain was UI complexity, but they shared interesting insights:

Some clients wanted to allow out of policy rides in emergency cases
Account managers were skeptical about the travel policy as it could potentially reduce the number of rides

I interviewed our account managers to discuss clients' feedback they were receiving. The most common complain was UI complexity, but they shared interesting insights:

Some clients wanted to allow out of policy rides in emergency cases
Account managers were skeptical about the travel policy as it could potentially reduce the number of rides

Objectives and key results

Together with the team we defined goals for the project:

Remove unnecessary features
Simplify setup process
Update the old UI kit (we agreed to migrate to the new components library)

As the main metric of success we would expect travel policy adoption level to grow to at least 10%.

I asked analytics team to investigate adoption level for all travel policy settings to see whether some of them could possibly be dropped in the new version:

The most popular setting was Vehicle type
Only 5% of companies set up AreaDistance or Locations rules
Only 2% of companies had multi-scenario Travel Policy groups
Less than 1% of companies used Travel Policy scenarios for guests rides

I examined 40+ accounts with rare settings to see how they were used:

Area, Distance, or Locations were mainly used by big and profitable clients
Multi-scenario settings were mostly mistaken for rules, only several companies used them as intended
Guest rides setting exploration showed that even though created, such rules were rarely applied

I shared results with my Product Manager, and we agreed to remove guests group and multi-scenarios option.

I asked analytics team to investigate adoption level for all travel policy settings to see whether some of them could possibly be dropped in the new version:

The most popular setting was Vehicle type
Only 5% of companies set up AreaDistance or Locations rules
Only 2% of companies had multi-scenario Travel Policy groups
Less than 1% of companies used Travel Policy scenarios for guests rides

I examined 40+ accounts with rare settings to see how they were used:

Area, Distance, or Locations were mainly used by big and profitable clients
Multi-scenario settings were mostly mistaken for rules, only several companies used them as intended
Guest rides setting exploration showed that even though created, such rules were rarely applied

I shared results with my Product Manager, and we agreed to remove guests group and multi-scenarios option.

I asked analytics team to investigate adoption level for all travel policy settings to see whether some of them could possibly be dropped in the new version:

The most popular setting was Vehicle type
Only 5% of companies set up AreaDistance or Locations rules
Only 2% of companies had multi-scenario Travel Policy groups
Less than 1% of companies used Travel Policy scenarios for guests rides

I examined 40+ accounts with rare settings to see how they were used:

Area, Distance, or Locations were mainly used by big and profitable clients
Multi-scenario settings were mostly mistaken for rules, only several companies used them as intended
Guest rides setting exploration showed that even though created, such rules were rarely applied

I shared results with my Product Manager, and we agreed to remove guests group and multi-scenarios option.

Solution breakdown

Strictness levels

To address emergency rides concern we decided to introduce strictness levels for travel policy. This would also allow Gett to not loose rides if there was no need for a total block on the client side.

Together with the Product Owner we defined 3 strictness levels:
loose, balanced and strict. A balanced level would be selected by default as the most beneficial.

I added small explanations below each option and mobile alert preview to clarify how end users would see it, later on we polished all texts with our UX copywriter.

Travel policy group creation form

To reduce implementation effort, I decided to reuse rule creation components, but change the form structure.

Old solution had all rules hidded behind ‘Add rule’ button and required two clicks to add a new rule to the travel policy group. In fact users opened empty form, which confused them a lot. In order to see what they could set up for each type they had to add it to the form first, and then to delete if they didn’t need it, otherwise there would be an error while saving.

As I wanted the interface to speak for itself, so my first idea was to make all rules visible and pre-filled with default values.

Few prototype tests showed that users easily figured out how to set rules and tended to explore all settings. But it was hard to distinguish filled settings from default ones in the edit mode.

To highlight filled settings I came up with two proposals:

1. Collapse blocks with default settings
Ones customised, they would always stay expanded. Vehicle types would be expanded by default as they were frequently used.

2. Highlight icons for filled rules
All filled rules would have icons in inverted color

Empty state

I worked on the empty state together with our UX copywriter. We wanted to make it engaging and highlight main travel policy benefits.

To encourage users to try travel policy I wanted to create several templates, which would open a pre-filled form. But the team decided to postpone templates for later and firstly deliver more valuable features..

Table view for groups

To allow quickly review all settings I prepared a table view for groups. This would help to avoid duplications which could lead to messed structure and cause unwanted rides.

Iterative implementation

It was important for us to deliver iteratively and see how each update affects the adoption level, so we could improve it in case we don’t reach desired results. We divided the implementation into 3 phases:

1. Update rules view

2. Add the empty state and the travel policy groups list

3. Add strictness levels

For the 1st iteration we decided to leave two columns view for the page, where users have to open rules one by one to see what’s inside, but update the form itself and check whether it reduces the number of travel policy creating questions, so I prepared a special mockup with travel policy groups list to the left.

I asked analytics team to investigate adoption level for all travel policy settings to see whether some of them could possibly be dropped in the new version:

The most popular setting was Vehicle type
Only 5% of companies set up AreaDistance or Locations rules
Only 2% of companies had multi-scenario Travel Policy groups
Less than 1% of companies used Travel Policy scenarios for guests rides

I examined 40+ accounts with rare settings to see how they were used:

Area, Distance, or Locations were mainly used by big and profitable clients
Multi-scenario settings were mostly mistaken for rules, only several companies used them as intended
Guest rides setting exploration showed that even though created, such rules were rarely applied

I shared results with my Product Manager, and we agreed to remove guests group and multi-scenarios option.

I asked analytics team to investigate adoption level for all travel policy settings to see whether some of them could possibly be dropped in the new version:

The most popular setting was Vehicle type
Only 5% of companies set up AreaDistance or Locations rules
Only 2% of companies had multi-scenario Travel Policy groups
Less than 1% of companies used Travel Policy scenarios for guests rides

I examined 40+ accounts with rare settings to see how they were used:

Area, Distance, or Locations were mainly used by big and profitable clients
Multi-scenario settings were mostly mistaken for rules, only several companies used them as intended
Guest rides setting exploration showed that even though created, such rules were rarely applied

I shared results with my Product Manager, and we agreed to remove guests group and multi-scenarios option.

I asked analytics team to investigate adoption level for all travel policy settings to see whether some of them could possibly be dropped in the new version:

The most popular setting was Vehicle type
Only 5% of companies set up AreaDistance or Locations rules
Only 2% of companies had multi-scenario Travel Policy groups
Less than 1% of companies used Travel Policy scenarios for guests rides

I examined 40+ accounts with rare settings to see how they were used:

Area, Distance, or Locations were mainly used by big and profitable clients
Multi-scenario settings were mostly mistaken for rules, only several companies used them as intended
Guest rides setting exploration showed that even though created, such rules were rarely applied

I shared results with my Product Manager, and we agreed to remove guests group and multi-scenarios option.

The new page was AB tested vs the old page and proved to reduce payment information requests. It is now baked in, and we keep seeing positive Payments functionality reviews left along with high CSAT marks.

Contact me

nika.galkina20@gmail.com

Dribbble

Behance

Travel policy settings redesign

Role

Team

Context

Travel Policy Challenge

Gathering data insights

Inside interviewing

Objectives and key results

Solution breakdown

Strictness levels

Travel policy group creation form

Empty state

Table view for groups

Iterative implementation

Contact me

Travel policy settings
redesign