Context & Challenge
What is Prolific?
Prolific is a platform where researchers pay participants to complete online studies. After signing up and filling out profile questions, participants get matched with studies based on their demographics. Most studies are surveys or tasks that pay at least £6/$8 per hour, with payments sent via PayPal (minimum withdrawal: £6). Researchers create studies, set participant criteria, and collect data, while participants complete studies and get paid once their work is approved.
Who was the team?
Core team: Myself (Product designer), 2 Senior Engineers
Supporting collaborators: VP of Product, Participant Support, User Researcher, Marketing Comms Manager
Who was this work for?
This project was for researchers from a high-priority, strategically important customer (client details cannot be shared due to NDAs).
What was the problem?
Customer A (CA) assigns users an hour-long "study" made up of multiple smaller "tasks."
The ideal scenario is that users complete tasks for the full hour and return to Prolific. After completing an hour’s worth of tasks, participants should receive the full study reward.
However, CA researchers have a fixed number of tasks to complete. As the remaining tasks dwindle, participants may "run out" of tasks before the hour is over. Historically, CA has paid participants the full amount regardless, but this approach isn’t sustainable for their budget. To ensure fairness and manage costs, we aimed to create a system where CA compensates participants proportionally based on tasks completed.
Why did it matter?
This issue was the number one pain point for CA at the time.
Discovery & Research
How did I approach the problem?
To begin, we needed to understand the behaviour of both CA researchers and participants engaging in these studies. Our in-house support team, which is a valuable source of insights, revealed that some participants had been reaching out via email or messaging researchers because they had received full payment, despite not spending the full 60 minutes on a study. From the participants' point of view, receiving the full reward for incomplete studies was causing confusion.
Key insights:
CA researchers exclusively used the API to create studies.
Some participants were concerned they had inadvertently "cheated" the system by receiving full payment for less than 60 minutes of work.
The engineering team performed technical concept work to evaluate the best approach based on the available code
Ideation & Design
As a team, we agreed to take a lean approach to this initiative, aiming to deliver value to users quickly as we were approaching the end of Q4. To foster transparency and collaboration, we set up a dedicated temporary Slack channel with key stakeholders across the business.
Proposed solution
An API-first approach, meaning researchers would only be able to utilise the new system via the API.
Participants would be compensated via a bonus payment.
What is a bonus payment on Prolific?
At Prolific, bonus payments are additional amounts that researchers can send to participants beyond the original study payment. Bonuses may be given for several reasons, including:
Extra Work – If a study requires more effort than originally planned.
Good Performance – To reward high-quality or accurate responses.
Compensation Adjustments – If a participant encounters technical issues or completes part of a study without being automatically paid the full amount.
Gratitude – Researchers may give bonuses as a goodwill gesture.
Bonuses are paid directly to participants and show up in their Prolific balance, like regular payments.
We quickly synced with stakeholders to get buy-in and discuss the proposed flow. After receiving approval, we divided and concurred with the engineers building the new endpoints and I began exploring how to communicate this new concept of partial payments to participants.
How did I solve the design problem?
Now that we had a good understanding of the problem space and technical solution, I wrote the following design requirements to inform the design solution:
The design changes in the UI SHOULD:
Clearly Inform participants that this study is paid differently
Simply inform participants what reward to expect
Follow the design system and current UI patterns
The design changes in the UI SHOULD NOT:
Further confuse participants
For this exercise, I followed the just enough design approach in spirit of keeping things lean. I focused on making small key changes to where reward is mentioned in the participant flow.
Typically participants see the reward BEFORE taking a study in 3 places:
Study card
Study dashboard before taking part
‘New study available’ email alert (if signed up marketing comms)
And see the reward AFTER taking a study in 2 places:
Submission confirmation email
Submission page
Initially, I aimed to refine the copy across all touch points, with a particular focus on updating the pills in the study descriptions.
you can see other iteration here)
This version felt a bit cluttered and overstated the feature's availability, even though it wouldn’t impact most users. After several iterations and feedback—which also highlighted some technical limitations in the UI—I arrived at the following solution.
We ultimately chose the term Dynamic Rewards, as the original name, Partial Payments, could be misleading for users. From their perspective, they were receiving full payment for the work they completed.
User research
Now that I felt confident in the designs, I wanted to gather user feedback. In collaboration with our user researcher, I designed a two-part study and launched it on Prolific, targeting participants familiar with CA studies. In the first part, participants completed a study with dynamic rewards, with the expectation of a follow-up. Below is the summary I shared with stakeholders:
Dynamic rewards user research summary
Overall, the participant feedback has been mostly positive towards dynamic rewards.
89% of participants had a positive experience with the dynamic rewards test study.
72% of participants either liked or loved the experience with dynamic rewards, with 18% neutral and 9.9% not liking this type of reward.
Project Overview:
Objective: To understand if participants understand what dynamic rewards are and get an understanding of sentiment.
Methodology: 2 studies were sent out to participants. First to check the functionality and second to gauge how participants would feel about this change in rewards.
Participants: So far, we have gathered feedback from 118 participants.
Key Findings:
Fairness and flexibility: Many respondents felt that the dynamic rewards were a fair way to compensate participants.
Time-based compensation: Many participants understood that dynamic rewards are primarily based on time. Most understood that the longer they spent on a study with dynamic rewards, the more that they would be rewarded. However, a few participants also stated that effort was considered in giving the reward.
Engagement: There was a theme in participants that this fairer compensation system would incentivise them to give honest and quality responses.
Concerns about manipulation: Some participants raised concerns about some participants intentionally taking longer on studies for a higher reward. Participants also expressed some concerns and confusion around what happens if studies take longer or how this may penalise participants who complete studies faster. There were also some concerns about the levels of transparency researchers give in calculating dynamic rewards.
With this positive feedback from users, we launched. This took about 2 weeks to get to MVP.
Final design solution
Impact & Results
What was the outcome?
How we set our metrics:
📊 Built a dashboard to track feature adoption.
📈 Monitoring fill rates for dynamic vs. regular studies.
📩 Tracking participant feedback and support queries.
💰 Analysing % of dynamic studies actually using dynamic payouts.
Early signs show improved cost efficiency for CA and better participant clarity. We're iterating based on feedback to refine the experience further.
Most recent changes to the MVP:
🔹 CA Participants Misunderstood – Some dropped off early, thinking they could leave whenever and still be paid.
🔹 Solution: Removed upfront messaging about dynamic rewards to avoid confusion.
🔹 Customer B (CB) Fill Time Issue – UI elements (pay/time ranges) were discouraging participants from joining.
🔹 Solution: Simplified the UI by removing misleading pay/time ranges from study cards and submission pages.
Refections
Lessons learned
During a recent round of MVP changes based on feedback, I found myself struggling with my design process. With input coming from too many people, it became challenging to reach a cohesive solution—there were simply too many "chefs in the kitchen." This experience taught me that when, what, and how I share my work are critical aspects of the design process. The level of detail and approach should be tailored to the audience—whether it’s a teammate, a fellow designer, or stakeholders from other parts of the business.
Although this was a high-pressure project with a very quick turnaround, it was also one of the first P0 (high-priority) initiatives I worked on, making it a valuable learning experience. It helped me sharpen my stakeholder management skills while also deepening my expertise in UI design and visual communication.
Next steps
The MVP has been instrumental in helping us understand this problem space, and we’re now exploring how to evolve it further. While there are limitations on how much I can share, this phase has sparked some of my most forward-thinking design work as I envision what this could look like in the future!
