Databricks
Persona Journeymaps
Databricks understood who the users were in general, they lacked insight into what motivated the people they were shipping software for and where they were struggling. Product and Engineering also needed a way to make sure that the user was always “in the room” when feature discussions were underway. Being a very data-driven company, Databricks culture needed an artifact to refer to and help validate decisions that would impact their users and have empathy for their day-to-day working lives.
overview
I defined the framework we used to research, analyze and publish the personas. I felt that the standard persona document was insufficient (who cares where someone went to school). Databricks needed a persona backstopped by their journey using the product and more importantly where the experience started to degrade and how they felt throughout. I worked with one product designer and several members of the customer success team (to make introductions to customers willing to speak to us).
research
Key to the success of the project was to interview a sizable number of users so we could map their experiences as closely to their actual work realities as we could. What do people want out of work? They want success, they want to be promoted, they want to learn new things. Rather than invent a brand-new persona taxonomy for Databricks users, we stuck with what people internally understood best: the role people play at work.
We looked at very practical aspects of the people who used the product:
How are they evaluated at work?
When is work good?
When does work suck?
What do they need to suceed?
How do they feel about Databricks over time?
Where do they abandon the product and what are their fallbacks?
What does their day-to-day look like?
Does the product offer any game-changing experiences?
What improvements would be helpful to them?
the personas
the data engineer
When I arrived, I was told by my peers that the user persona that “complained” the most was the Data Engineer. After an initial inquiry, it became obvious to me that many of the systems and features that Data Engineers rely upon to deliver trusted data to their organizations were either insufficient, error-prone or simply absent. This was particularly painful in the last mile of their process: CICD and automation of data pipelines.
the data scientist (insights)
This persona was more readily understood by Databricks as it was the initial persona the founders of the company built the product for: themselves. The challenge here was to make sure that new employees fully understand the persona and what future development of features could mean for this individual. This composite serves as a benchmark in understanding the evolution of the persona. One surprising outcome was that we opted to split the persona into two variants, as the emergence of the Machine Learning focused Data Scientist was simply too unique to merge into a single composite.
the data scientist (ML)
©️ 2024, Julie Lynn Lemieux