1

Lyft &Operator ServicesUser-centered Design Process

2

Contents03 About04 My Role05 Design Process06 Empathize

07 Contextual Interviews09 Quantifying the User Experience

10 Define12 Ideate16 Prototype and Test21 Refine26 Results and Learnings

3

AboutDetailsDate: April 2017Client: GreatCall, Inc. Platform: Desktop Application

Situation• Jitterbug flip phone customers could dial 411 to request a Lyft ride.• However, the call handle time was too long, which made this service unprofitable. There

was a need to investigate why and to come up with solutions to make this a profitable service.

Obstacles• Before, operator service agents were dispatching rides using a concierge tool provided

by Lyft. However, the tool caused increased handling time and user frustrations. As a re-sult, the product owner decided to build the service into an existing tool they use. How-ever, the tool only had the bottom 35% of the screen for real estate to use.

4

My RoleTasks• I created mockups to show how the Lyft concierge features could be mapped onto the

operator services tool. • I gathered early feedback using paper prototypes and incorporated changes into the

next iteration.

Team• 1 UX Designer• 1 Front-end Developer• 2 Back-end Developers• 1 QA• 1 Product Owner

Why I’m Proud of This ProjectSince this tool had such limited screen real estate, I had to be creative about where I could lay information. In addition, I advocated for early testing to quickly validate ideas and identify potential obstacles. Early testing proved helpful when we found a way to furher re-duce handle time. Agents were giving real-time information to the caller about where their ride was, which was addressed by not showing the car’s position on the map.

5

Design Process

6

Empathize

7

Contextual Interview During the interview, I observed an operator ser-vice agent complete tasks such as answering calls, looking up business or contacts, adding numbers to a phone book, and transferring cus-tomers to customer service.

• After two hours of not getting a Lyft call, I asked open ended question to learn about what worked and did not work on a Lyft call.

• During the observation, I learned that first-time callers have the longest call time. Customers are asking a lot of questions about the legiti-macy of this service, the difference between Lyft and taxi, and whether the drivers have gone through background check.

• I also learn other information about the agent’s job experience. For example, the agent felt frustrated that she got penalized for not adher-ing to the script, using Google to find informa-tion, and using her lunch time to answer calls.

• After the interview, I wrote a report about my observation (see right).

8

Contextual Interview• In my report, I listed each observation and as-

signed a 0-4 rating. A rating of 4 meant that the issue was severe.

• I separated my observation from my interpreta-tion because I believe what occurred could be seen in different ways.

• In addition, I provided recommendations about how the issue could be resolved.

9

Quantifying the User ExperienceAs part of my report, I estimated how much call handling time could be saved if certain fixes were applied.

• For instance, since our demo-graphic is more used to taxis than Lyft/Uber rides, training agents to say it’s curbside pick-up will pre-vent a ride cancellation and a call back.

10

Define

11

Find Out Where the Tool Lives• At the start of the project, I spoke with the product owner and the software developers to understand where it

was going to live. Then, I asked the software developers to provide me a screenshot, so I could start designing.

• One of the first thing I noticed about the tool was how little screen estate there was. I asked if I could move some the information around, however, the developer said no since the change could break the tool and impact QA.

12

Ideate

13

Design A (Tabs) - Dispatch Ride• The product owner provided requirements for phase 1, which include features such as dispatching a ride and

viewing ride history.

• I gathered screenshots of the Lyft concierge tool and mocking up the functionality onto the new tool. I did not use wireframes because I was given a deadline of three weeks to finish the design.

14

Design A (Tabs) - Ride History• In this design, I proposed using an accordion to save space.• I presented two designs, one with a tab layout and one without.

15

Design B (All-in-One) - Dispatch Ride and Ride History• In this version, dispatch ride and ride history were laid side-by-side to each other.

16

Prototype & Test

17

Paper Prototype TestWhy a paper prototype?• For this project, I made paper prototypes by simply printing out my mock-ups. A click-

able prototype was not used because the team was eager to start development. In ad-dition, the user researcher was not allocated to the project yet. I also wanted to spend time with the agents, so I can better understand their workflow.

Setup• At the call center, the product owner randomly asked two agents for their feedback. I

moderated one session. Then, I asked the product owner to moderate the other, so he could understand what usability testing is like in person.

• Before I started testing the prototypes, I asked the agents to tell me their name, depart-ment, years of experience, responsibilities, and current tool usage. This helped us get to know our users a little better as well as help ease them into the test.

• Then, I asked the agents to role-play. During the role-play, I asked them to pretend that certain situations occurred and find specific items on the interface. Afterwards, I showed design A before design B. It was vice versa for the second participant. At the end of test-ing, I asked the agents for their thoughts of the tool overal and to rate the tool on a scale of 1 to 5.

18

Usability Testing Report• After testing the paper prototype, I gather my notes as well as the product owner’s, so I could generate a report.

• Instead of writing a lengthy report, I decided to keep it concise in a PowerPoint presentation, so the team could review it when they had time at work.

19

Usability Testing Report• In addition to my finding, I also included in my report the method I used, who was there to moderate, what type

of data was collected, how it was recorded, and a brief background about the participants.

• I also add in a conclusion at the end, so I could succinctly summarize what the key findings were.

20

Usability Testing Report• At the end of my report, I like to include a comprehensive list of recommendations. This helps the product owner

turn these findings become design or development tickets.

21

Refine

22

Collaboration• The product owner has

worked with me on other projects and he knew that I believed that sketching out ideas was the fastest way to iterate and evalu-ate the design.

• Before he wrote a ticket to request design revisions, he consulted with me about what would work best with the design.

• Together, we agreed on keeping a tab layout that separated dispatch rides and ride history.

• We also talked about hav-ing only the address entry and display fields to be in the same place. Howev-er, we both realized that space was an issue and the scheduled future ride feilds will be in the way.

23

Next Interation• Since the product owner was present during paper prototype, he understood the usability finding very well. He

took my report and created a ticket with details about the revisions he wished to see in the next design.

24

Incorporating the Changes• Using the ticket as a checklist, I incorporated the changes the product owner wished to see in the design.

25

Incorporating the Changes• As shown below, the final design incorporated elements from design A and B.

26

Results & Learnings

27

ResultsThis tool has not been released onto the call center floor yet. However, the user that we spoke with during the paper prototype test did mention in passing that it would speed up the process of scheduling a Lyft ride.

28

LearningsSoftware LimitationsIt was interesting to learn that shifting graphical user interface elements is not easy on desktop applications because it touches backend code. I learned that changes would mean more QA resources would be needed and that it could potentially break things.

I also learned that software developers did not want to show the map unless it was neces-sary because it requires a call.

Well-defined Requirements Makes Designing EasierMore often than not, I oftentimes do not have well-defined requirements at the start of the projects. Sometimes, I have to speak to multiple people to collect the information. This time around, the requirements were given upfront, which made it easy for me to just focus on designing.

Learning About Older AdultsOn this project, I learned that older adults would call operator services because they were lonely and needed someone to talk to. I also learned that they used operator services like Google. Operator service agents would provide information about the TV guide schedule if they asked for it.