Product Build Maps
Establishing shared understanding of the complex internal product build environment at Tableau to prioritize improvements.
Problem
The internal software build at Tableau was complex, handling multiple languages, producing multiple products, managed by multiple teams, and used by diverse development teams. It was difficult to design and prioritize improvements to the build due to stakeholders’ different perspectives.
Goal
Create a shared understanding of the developer experience of the internal product build in order to foster agreement on how to progress the build and prioritize improvements.
My role
This was a solo customer journey mapping project and I was the User Researcher, Workshop Facilitator, Content Strategist, and Graphic Designer. I collaborated with Infrastructure Developers and Managers to describe the product build system and design the user research and I interviewed and observed Product Developers.
Timeline
Mapping the software build system
In my approach to this project, I was heavily influenced by Jim Kalbach’s book Mapping Experiences. He recommends two research phases in journey mapping, researching with the experts and then with the users and also recommends involving stakeholders throughout the process rather than simply sharing a map at the end.
Interviewing experts allows you to map the system so that you have context for the perspectives you get from users. Getting an expert overview was particularly important for a topic as complex as an enterprise software product build and I interviewed a number of developers and managers of the infrastructure, took notes, created transcripts and also invited them to create diagrams of the build system to help inspire my own diagrams.
*Image shown at low resolution for confidentiality purposes
Workshop and plan with stakeholders
*image shown at low resolution for confidentiality purposes
Based on the input from experts, I created a diagram that showed how developers got code into the build, what systems it passed through, and what were the outputs. I took this build diagram into a workshop with the experts and asked them to add more painpoints, interfaces, and current work to validate my analysis, generate a richer view of the system, and involve stakeholders.
I also asked for input into the different kinds of developers needed to be representative of the users to help design the user research.
Understanding the developer experience
With a basic understanding of how the build worked, I began interviewing developers to learn about what it was like to use it. Targeting representatives of different programming languages, levels of seniority, length of time at the company, and areas of the products, I did hour-long free-form interviews. As I went, I developed a flexible list of questions to repeat but the discussions were largely unstructured to focus on discovery.
The ease of recruiting representative participants is an awesome aspect of doing employee experience. On the other hand, complaining about difficulty using internal systems can have negative consequences. In order to protect privacy and make it safe to share the biggest gripes on using internal tools, I created a system for tracking participant names separate from the interviews and managing the transcripts in permission-restricted file storage.
Build experience maps
After the interviews, I synthesized the information into two customer journey maps showing what developers were doing, thinking, and feeling at different stages of Setup, Sync, Code, Build, and Submit, providing a quick but detailed overview of what it was like to work with the builds from the developer perspective. An Opportunities section at the bottom provided suggestions for improvements and prioritization.
I designed the Build Experience Maps tabloid size so they could be easily printed out on office printers and be a convenient size to use for reference and discussion at desks or meetings.
Workshop build experience maps
*image shown at low resolution for confidentiality purposes
After creating the maps, I did a second workshop to create a structured time for processing and internalizing the information across the infrastructure group.
Results
The maps garnered an overwhelming positive response. I was struck by how the maps positively influenced discussion dynamics in a collaborative direction because they were holistic and a shared external object. The “Build Maps” as they came to be commonly called were used for an Architectural offsite, to onboard new engineering leadership, and created a shared understanding that the next generation build is being constructed with.
Thanking Participants
Doing the research for the Build Experience Maps deeply moved me. I was grateful for the time infrastructure staff and product developers took to explain the complexity and nuance of the systems and the trust to share their experiences candidly.
At the end I wanted to offer my thanks and show what their contribution had ultimately created so I made Build-X-Map compasses and thank you cards for everyone with information on how to access digital copies. I distributed cards and hard copies of the maps to all the offices with gratitude and pride in what we had made together.
