Designing Confluent’s User Personas/Journey Maps
Evoking empathy for our customers so we can build better products
Overview
Summary
User persona and journey maps are incredibly important for user-centered companies. They provide an in-depth description of the users, their needs/goals, and how they interact with the product. Such information allows organizations (such as Confluent) to empathize with users and to drive a fantastic customer experience. The main goals/use cases for Confluent creating our own user personas and journeys were to:
- Promote consistency in our employee’s understanding of who the users are
- Evoke empathy towards our users/customers
- Identify and prioritize projects based on users’ experiences
- Provide context for projects (what stage of adoption our users are at, who exactly we are building this for, and what is our user’s objective)
My Role
My role as the designer for this project was to take the data we collected via user interviews and create individual persona “profiles” and journey visualizations. The final artifact had to be presentation-ready, but also easy to reference for Confluent employees as they work on projects.
Design Process
Iteration 1
I started out the design process by first researching how personas and journey maps are organized and designed.
In general, personas contain basic background information/stats about the user, followed by additional information such as their motivations, goals, and challenges.
On the other hand, journey maps depict the different steps the user takes when interacting with a product and — within each step — information about: how the user is feeling, what the user thinks, and what the user is doing.
I initially thought that this was a fairly straightforward project in which I would take our data and organize it in the standard layout of how user personas and journey maps are formatted. However, as I began to design and organize our users’ information based on examples, I realized that following the generic layout didn’t work well for our content and was not very useable.
There was information overload, limitations with how employees could work with this information, and not enough real estate to present all the information at once. I tried to solve the latter issue by breaking the large file up into a powerpoint — since this was also intended to be used for presentation purposes — but the powerpoint format limited how employees could navigate through the information.
Iteration 2
After hitting this block, I decided to take a step back and think about what was most important for the project to communicate:
- The relationships between our users i.e. who is working with whom at different points in time
2. Who is involved at each of the company’s stages and what they are doing
3. Pain points — where/when it is difficult for our users to work with our project
I then thought of the use cases for this project — how our employees will use these personas and journey maps:
- Presentation: For our user researcher to present this information to the company
- Reference: Either to identify which part of the user experience to improve on or to help provide context on a given project
While going through this process, I realized that to fulfill these core needs, a typical persona/user journey layout was inadequate and inappropriate. Instead, an interactive prototype of the information would be more useful, since it would provide the flexibility needed to support our different use cases, better communicate the relationships between user personas, and reduce information overload. I then worked towards changing/improving my current graphs, visualizations, and information to fit this new medium.
Iteration 3
At this point, the information was a lot easier to work with and navigate through, but I felt that the project still lacked empathy. The current design was a more graphical, data-driven approach to knowing our customers rather than an attempt to truly understand them. I started to imagine and sketch out ways our journey maps could be more like telling a story about our users.
After deciding on the layout, I worked on creating a color palette that would be professional enough to use in a work context, but still provided a sense of warmth that we should be feeling towards our users.
When figuring out how to represent our customers, I explored the idea of incorporating illustrations. I wanted to make the illustrations fairly vague so that they could represent people from many ethnicities and backgrounds and prevent the development of generalized or false assumptions about our users, while still keeping them relatable and human.
Final Design
After this long process, I finally finished the designs and transferred the screens from Sketch to Invision Studio where I implemented the prototype.
When employees first enter the interactive prototype, they are introduced to the user personas. Each persona contains a name, persona title, job titles list, qualities, responsibilities, and pain points. While it is important for Confluent to understand each persona’s job, responsibilities, and frustrations in relation to adopting Kafka, I felt that it was also important to include the qualities section so that we can understand more about how each persona thinks, works, and who they are as a person.
After familiarizing themselves with the personas, employees can then navigate to the journey section where they see each illustrated stage of the organization along with a short description about what the organization as a whole is doing and which users are experiencing difficulty (as indicated by exclamation icons).
Employees can focus on a persona at each stage by clicking on the image of that person. The description at the side changes to show what the persona is doing at that particular stage and what pain point(s) they are experiencing (if applicable).
If users navigate forward or backward, they will continue to view the selected persona’s journey. To focus on a different persona or return to the full organization information, one needs to click on the image of that persona or click the link below the descriptive text.
Conclusion
What originally appeared to be a fairly simple, and straightforward user persona/journey project ended up evolving into designing a completely new representation of user personas and their journeys. After seeing how poorly the general format fit our data, I realized that my initial approach was wrong. In order to make these personas and maps a useful internal tool, I needed to design it for the users (Confluent employees) and their use cases and with the same level of empathy these journey maps are reminding Confluent to utilize when creating experiences for our own users.
Presently, this project is being distributed across the company and integrated into the Confluent work flow. Moving forward, we will be doing a quantitative analysis on who our users are and adapt the current personas/journey maps as they evolve and as new information comes to light.
