4 weeks (divided into 1-week long sprints)
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
Aspiring teachers were excited about Dabble! They wanted to share their hobbies and connect with a community of similarly passionate minds.
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.
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.
A simple, minimalistic interface that walks the user through the crucial first steps of onboarding.
To better inform teachers about best practices, we also visualized contextual data about the market.
To better build communities, showcase new and popular teachers on the site.
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.
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.
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.
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.
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.
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.
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.
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.
Work with the marketing and sales teams to design a marketing package.
Work with the developers to make a data analytics dashboard.
