Case study


Project Overview

Project Length

4 weeks (divided into 1-week long sprints)

My Role

I conducted preliminary market research and designed and tested wireframes. Other members of my user experience team included a content strategist/designer, 2 other researchers, and a project/client manager.


  • Domain research report
  • User interview data synthesized into personas
  • Wireframes (Balsamiq & Sketch)
  • Final Prototype (InVision)
  • Future business and implementation recommendations

our mission

Improve Dabble's user experience in 4 weeks.

About our client

When locals are looking to try a new hobby and meet new friends doing it, they turn to Dabble. Dabble is a community marketplace for local experts to share their knowledge with curious learners in hands-on, low-commitment classes.

The business problem

Our stakeholder came to our team with a 3-pronged mission. He was looking for a way to acquire, convert and retain new event organizers. In particular, he wanted our team to examine Dabble’s current account onboarding and event creation processes.

How might we quickly build an easily implementable solution for an already existing business in 4 weeks?

Furthermore, to maximize our business impact, do we focus on customer acquision or retention?

findings from market research

Digital marketplaces are hard to pin down, but even harder to keep "leak-free."

Becoming “experts” in a week meant using what we knew to direct us to what we didn’t know and still needed to solve.

After our project kickoff, we were eager to start researching the competitive domain to better understand Dabble and identify our best competitive opening. The problem was, we had no simple way of defining what exactly Dabble did -- other than that it was a marketplace where people exchange services.

What we learned:
Dabble is a 3-sided marketplace.

Dabble’s platform has 3 parties connected in each transaction:
Students enrolling in a Dabble experience
Event organizers (teachers) hosting classes and experiences on Dabble
Venue providers, providing sites for event organizers without a place to host

For digital marketplaces, platform leakage is a war of attrition.

In researching the market, I found that many marketplaces, including Dabble’s competitors AirBnb and Groupon, suffered from a shared scourge: platform leakage. Platform leakage refers to a process in which users sidestep paying through a platform, which results in the platform failing to capture revenue at the time of transaction.

Was Dabble also impacted by platform leakage like its largest competitors? Why, and where were Dabble’s users escaping to?

findings from Initial user interviews

Power users are difficult to retain because they utilize other competitor platforms.

Early empathy mapping drew a clear picture of power users, but also revealed holes in
our research.

Initially, most of our user interviews were conducted with experienced Dabble teachers that our stakeholder had close relationships with. To get an early birds-eye view of our interview insights, we conducted an empathy mapping session halfway through our user interviews.

Power Users drift between competitors...

Dabble’s power users were seasoned teachers who mastered filling up their classes with tried-and-true strategies. Because they used the platform as a way of generating initial leads, these users were the source of the leaks. Additionally, nearly all power users listed their classes on other event platforms like AirBnb or EventBrite to fill their classes to capacity and maximize their profits.

... but they continued to use Dabble access a pipeline of first-time students.

To maximize their class enrollment, experienced teachers often opted to allocate their money to Dabble’s optional marketing services. However, they weren’t sure what exact benefits they were getting for how much they were paying. Power users were happily using the platform to funnel first-time students into their classes.

If preventing experienced users from leaking to larger platforms would be an uphill battle, what about Dabble's inexperienced users?


New users don’t have the tools they need to succeed because they don’t know what to expect.

The users we needed most were more trickier to come across.

Because we had only spoken to power users, our team quickly realized that we weren’t getting a comprehensive picture of Dabble’s users.

Overall, new users were more reluctant to speak with our team, but we managed to interview a few willing participants after working with our stakeholder to incentivize participation.

After talking to 9 power users and 3 new users, what did Dabble users want?

At the end of our 1 week research sprint, the team put our collective brainpower together to synthesize our data and extract insights via affinity diagramming. We then distilled our users’ goals into “I want” statements. These statements were crucial in keeping our problem statement, design principles, and our concepts rooted in data.

The smoking gun:
Mapping qualitative data on a binary spectrum confirmed two personas.

My teammate and I took the synthesis of our data one step further. To explore a data-driven approach to creating personas, we mapped our users on several binary spectrums.

2 clear patterns emerged, reflecting the differences in power users and new users. Although we knew that Dabble’s 2 user groups were different, it was striking how obviously different their desires and frustrations were.

Meet Persona #2:
The New User

Aspiring teachers were excited about Dabble! They wanted to share their hobbies and connect with a community of similarly passionate minds.

Leaking to competitors was a non-issue with these new users.

New teachers were loyal to the original platform that they fell in love with.

Unfortunately for our aspiring teachers, their first event wasn’t typically a success — even power users said so.

concept development

Prioritizing designs using empathy

To hone in on key concepts, empathy was our editing tool.

After grouping concepts through affinity diagramming, we used 2 stages of empathy-building to ensure that our solutions were grounded in our users’ and stakeholder’s goals.

First, I proposed that our team each role-play as the users we interviewed to really get into the mindset of our users. Acting as our users, our team voted on concepts that met our users needs and trimmed down to our final 6 concepts.

On our second pass, our team invited our stakeholder to workshop with us. By inviting him to vote on our finalized concepts, we were able to understand which exact business goals he prioritized.

After our collaborative workshop, here are our concepts that best reflected both our user and stakeholder needs.

Extended onboarding

A simple, minimalistic interface that walks the user through the crucial first steps of onboarding.

Analytics for the Teacher Dashboard

To better inform teachers about best practices, we also visualized contextual data about the market.

Homepage Redesign with Social Showcase

To better build communities, showcase new and popular teachers on the site.

A hard reality check

Finding out our minimum viable product wasn’t
minimal enough.

Aiming for the Blue Sky generated mixed results...

One of our earliest prototypes was a data dashboard that I designed. From user interviews, we knew that Dabble’s experienced teachers wanted nitty gritty performance data to identify how they could optimize their profitability.

In user tests, this data dashboard concept was positively received by power users, but new users found the charts intimidating and overwhelming.

… And ultimately, came up short.

When our team presented our initial testing results to our creative director, she immediately identified that the data analytics component would be difficult for Dabble to implement given the limited time and resources.

Small start-ups don’t have access to deep resources and capital like more established companies.

My prototype was severely limited by Dabble’s remaining runway. Although we knew that the startup had limited capital, we had no idea that Dabble had incredibly low access to developers. After a conference with our stakeholder and the development team, we learned that most of the work was maintenance work for 5 hours a week by a single person.

Within the course of the 2 remaining weeks, we had to focus on the minimum viable product — something simple and quick with maximum business impact.

Any solution that we designed had to be implementable, immediately.

Our new focus

Solving for the overlooked user:
Supporting Dabble’s amateur teachers

Ideas on the cutting room floor still have potential.

Our limited scope forced us to prioritize meeting the needs of one user group over another. Upon re-evaluating our original concepts, we realized that a viable solution was in front of us all along: onboarding for new users.

Stakeholders and users are both welcome in a minimum
viable solution.

This was important because our retooled approach supported the users who needed the most help to succeed. By guiding new users, Dabble could establish a welcoming first impression making it more likely to maintain a relationship with them through their experience.

Furthermore, focusing on onboarding addressed Dabble’s operational constraints. Not only did it present the least implementation challenge for Dabble’s developers, but it would also extend the runway of limited capital.

How might we help Dabble’s newest teachers find their first audience?
How might we help them maintain their enthusiasm for sharing
their passion?

Our improved solution

Streamlining the first path for new teachers

Reflecting back

Lessons & Takeaways


Ultimately, our solution wasn’t implemented. Although it seemed feasible at the conclusion of our project, 3 months later the updated onboarding our team created still isn’t live on the site.

Regardless of the implementation status, we equipped our stakeholder with the knowledge to make the best decisions possible moving forward. In addition to our final design assets, we compiled a document of design recommendations that Dabble could implement in the future when more resources opened up.

Lesson 1:
Scrappiness = leaning into uncertainty

In contrast to the straightforward models of design processes, our team’s actual process was full of twists and turns. Developers that I thought were there, weren’t. Users that I thought were available, weren’t. In order to adapt to shifting circumstances, I had to be open-minded enough to acknowledge mistakes early so that I could respond quickly and shrewdly.

Lesson 2:
The gospel of the
Minimum Viable Product. Amen.

Our early prototype -- the analytics dashboard I created -- was a poor minimum viable product. Unwittingly, I designed an idealized product for an idealized environment, not taking into account the very real constraints of operating a business. It’s those very constraints and limitations are what flesh out a truly empathetic product.

“If I could save time in a bottle, [a couple] things I’d like to do…”

Work with the marketing and sales teams to design a marketing package.

Work with the developers to make a data analytics dashboard.