A MVP to request takes

Discover

I started reading the product backlog of ideas and issues. This is a place where mainly customer-facing teams share feedback on feature requests and issues. After reading it, I categorized the ones that aligned with my squad's mission.

The offer of takes* was a card in this backlog. It called my attention given the impact on clients and business. So I started an asynchronous conversation via Slack with the team.

*Takes are multiple versions that talents record the same script, but varying tone, speed, style, etc, so clients can choose the best one.

Meanwhile, the data team started a discovery in the platform. So far, we only had anecdotal information from the Operations team about clients requesting takes in different parts of the project form.

The UX researcher and I planned a survey to send to the freelancers.

The goal was to understand the Freelancer's perception about:

• takes vs parts

• the expectation of earnings for extra takes

Main insights

• ~0.66% of projects had requests for takes

• Freelancers agreed they should be compensated accordingly

• Freelancers expected to be paid around 10% to 50%

• Freelancers shared that multiple takes would be beneficial for both freelancers and clients:

  • It would down on revisions and turnaround time significantly

  • Clients can choose the best-fitting style for their purposes, and identify styles they hadn’t considered before

• 2 or 3 takes was the most frequent amount of takes request

• 8 takes was the maximum a client requested

Define

Overall, we learned that not explicitly offering takes on the platform was creating:

• Operational burden

• Friction in the experience

• Risking freelancers and the business losing money 💸

The friction was affecting 3 main areas

• Freelancers: If freelancers did not tell the company they have recorded takes, they would not be paid. The company could only cover the cost once freelancers raised a flag, as they were not previously aware.

• Clients: they found a way to request takes by asking for multiple revisions until they get the tone they wanted;

• Operations: depending on the back-and-forth, this increased operational costs, and turnaround time, of which 85% of the projects were completed in 12h and 56% in 2h. Really fast.

Develop

Along with a UX designer, we ideated different possibilities and arrived at 2 different use cases.

User story 1

As a client, I want different versions of the same script, so I can choose 1 as the final version

Approach: the client needs to be able to specify styles for the script as a whole and doesn't need to differentiate styles between parts.

A take applies to all parts equally

Flowchart exemplifying use case 1

User story 2

As a client, I want different versions for each part, so I can experiment with different styles for each part (e.g., video game character speech).

Approach: the client needs to be able to specify different styles for different parts; meaning one style cannot be applied to all parts equally, like in the first user story. A take is different for each part.

Flowchart exemplifying use case 2

After this exploration, I started getting more data to understand which use case was the most common.

Main challenges

• Connect the takes specifications to the fulfillment flow, where freelancers would receive the information – depending on the proposal, would increase a lot the implementation complexity

• Explain the dynamic pricing without increasing complexity for clients and the implementation

• Make it clear to clients that ‘takes’ will be applied to the parts delivered

Exploring 3 solutions

Alternative 1

Specification for takes goes below the script/parts section:

1. First, paste the script specifying how many parts they want their voice-over to be delivered

2. Select how many takes they want

3. Insert specification for takes

The first proposal shared with the team to gather feedback

Trade-offs

• Could require more effort to develop as we would need to create new fields for the dynamic pricing

• This could impact the fulfillment flow as the information inserted here would need to reflect in that part of the flow

Alternative 2

Specification for takes in the remarks sections:

1. First, paste the script specifying how many parts they want their voice-over to be delivered

2. Select how many takes they want

3. Go to the Remarks section below to add the specification

Second proposal shared with the team to gather feedback

Trade-offs

• Simplified implementation: remarks section already existed (clients were already requesting takes from this section) and would not directly impact the fulfillment flow pricing is not dynamic, we would add a text below the field to explain it

• Asking to provide instructions in a section after this one, was too out of context for the user

• Clients could forget to add the specification as it would be mixed with other remarks for the project

Alternative 3

Takes goes right below each part:

1. First, select how many takes the client wants

2. Then paste the script specifying how many parts they want their voice-over to be delivered

3. Insert specification for takes below each part (the system would automatically add a takes' field below each part of the script field)

Third proposal shared with the team to gather feedback for future references - as the use case was discarded at this moment

Trade-offs

• More effort is to develop as we are adding fields and new logic inside the script component

• Enables clients to request different takes for each part of the script (use case 2)

• Takes information is contextual, right below each part, making it more self-explanatory for which part the takes refers to.

This option was eliminated from the experiment as we learned it was not a common scenario. Once we learn more about users’ behavior, we could go back to this solution if needed.

Delivery

After the feedback section and a few iterations, the tech lead and I met with the other squad responsible for the fulfillment flow. The goal was to gather insights on the implementation.

The first solution seemed better for the user experience, but not an easy implementation.

Once we all understood how the fulfillment flow worked, the engineering team proposed a solution that made the first proposal viable and with no major effort.

Basically, any information shared by clients in the takes' field would be sent automatically to each script part. With little effort, we could use the same funnel we had and the first proposal. With this set, I created the specs and handed-off to a developer.

Final version

The default option was 1 take as it was the most common behavior. Once users select more than one take, they instantly get the price in the checkout component.

Gif of the final version

Announcement

I aligned with marketing and the CX team on the announcement of the feature for clients, freelancers, and the operational team. It was an exciting release.

Email sent to clients

Outcomes

Less operational burden

• Freelancers getting paid for the takes recorded

• The operations team, having a defined process

53% increase in projects w/ takes

• Compared to the initial analysis

37% increase in the order value

• Compared to projects without takes

6 weeks

• From discovery, to launch and announcement to clients and teams

What did people say?

“Helloo! So, I’ve been looking into the projects. Clients seem to grasp the functionality pretty good! All of the canceled projects had nothing to do with takes. Both New and Ongoing clients seem to be using the functionality without any issues."

A CX Coordinator

Thank you. This is what we needed!

A freelancer

This will be a big time saver, thank you for the feature.

A client

Reflections

Keep up the cross-functional collaboration 

• The platform has complexities such as the fulfillment flow where freelancers receive the request for a project, the pricing system, and the quality control

• Finding a viable and easy-to-implement solution, along with evangelizing the release, was only possible given cross-functional support

Simplify to experiment fast

• I made some trade-offs that were not the dream solution, but I was confident it wasn't going to impact negatively the experience. We ended up using what we already had implemented, and it worked well.

Make informed decisions, but do not wait for all the desired data

• I wanted to understand the current state instead of relying on anecdotal information, but given the context, the data team could not accurately detect the current state, so we made a bet, knowing the worst-case scenarios, to learn fast

Do not wait until the technology was migrated

• This project form was part of a legacy user interface and technology as well. Both were going to be migrated, but the deadlines were uncertain. Even so, we prioritized this experiment given the impact and implementation complexity.

• The interface has some uneven margins and outdated and cluttered visuals. This was being tackled, and a new version was coming.

Shoutouts & Credits

• Marina UX Designer/Researcher: support the design process, and research 

• Data & pricing team: defined the pricing, find and analyzed data, and created the dashboards to analyze the results

• Rodrigo CRM Specialist: for writing and sending announcement email to clients and freelancers.