GOOGLE CLOUD

USER RESEARCH & STRATEGY

In collaboration with Rachel Price, I led a project for Google Cloud through a critical User Research study that successfully identified the barriers to Open Source contribution. This study resulted in the implementation of processes that effectively optimize the adoption of Open Source documentation for projects like Apache Airflow and Apache Beam. The results were shared at a variety of conferences including Google Next.

THE CHALLENGE

Most Open Source contributors do not provide effective documentation when contributing code. Open Source documentation is treated as a second-class citizen and our goal was to understand why. We partnered with a Google Cloud team and collaborators from the Apache Foundation to do research and uncover opportunities to inform process and strategy decisions moving forward.

OUR APPROACH

We conducted a qualitative research study that resulted in a series of models and frameworks that were used to address key opportunities throughout the Open Source User Journey. These documents were shared with the Open Source community and presented at a series of events and conferences such as Google Next.

After I brought this project to the agency I was working at–Guidea, my role in this engagement was to lead and conduct Design Research and translate the findings into a strategy with actionable models and frameworks for the future state of Open Source Documentation. The other members of my team included a Project Manager and an Information Architect.

RESEARCH STUDY

We conducted a qualitative research study that resulted in a series of models and frameworks that were used to address key opportunities throughout the Open Source User Journey. These documents were shared with the Open Source community and presented at a series of events and conferences such as Google Next.

METHODS

  • Ethnographic interviews
  • Competitive analysis
  • Journey mapping
  • Experience workshop

DELIVERABLES

  • Behavioral Archetypes
  • Competitor Analysis
  • Priority Matrix
  • User Journeys

PROJECT KICKOFF

My biggest challenge at the beginning of this project was understanding the expectations of my role, given that I had just started working with Guidea and everything was completely remote. I was the point of contact with the Client, since I brought the project to the agency, I was collaborating with my partner to develop the Research Strategy and trying to figure out the dynamics of not only my team, but the Client’s team and other stakeholders.

I overcame this by being proactive and communicative – asking lots of questions, not making assumptions and keeping constant communication with both, my team and the Client. We were very transparent, documented the process and made changes as needed based on the constant feedback we got.

STAKEHOLDER INTERVIEWS

KEY INSIGHTS:

  • Documentation: should rightfully be considered a “first-class citizen of engineering”.
  • Project Health: Documentation creation & governance is a core part of “project health”, yet it is hard to find volunteers to do this.
  • Contributors: Getting people to contribute & maintain documentation is an ongoing problem that hasn’t been resolved.

INTERVIEWS

We conducted 15 remote sessions with research participants, in which we discuss current and past experiences with open source. We learned about how participants assess technology for adoption, their history with contributing, barriers and contribution, and do mapping activities to foster discussion around these topics.

During the sessions, we discussed a recent contribution scenario that the participant went through and mapped it out together – actions, thoughts, and feelings. We used this as an artifact to provoke discussion of contribution and its barriers.

SYNTHESIS

Connecting the dots after collecting the data is one of my favorite parts of the process! I really enjoy making sense of the data, however, I had never done it remotely with a distributed team and it turned out to be a challenge. I was used to getting into a meeting room and filling it with clusters of post it notes and scribbles all over the whiteboard, but this wasn’t possible. At least not the way I was used to.

My partner, Rachel and I initially decided to use the online tool, Dovetail to cluster and code the data, but after hours of coding data on Dovetail, things were just not clicking to me. I was struggling to identify relationships between the data and couldn’t find any patterns. It just wasn’t making sense. So I called Rachel instead of sending Slack messages and told her what was going on only to find out that she had already moved from Dovetail! Rachel started using a hybrid between post it notes and Trello to make sense of the data and then coding everything on Dovetail. It seemed a bit redundant at the beginning, but I did something similar and things started flowing. My biggest lesson was realizing that it is ok for me to tell my partner that our plan didn’t work as expected and to ask for help as soon as needed. We resolved this by changing our approach, switching tools and keeping constant communication. Remote synthesis is possible if you keep an open mind, proactive communication, and an eagerness to troubleshoot along the way.

FINDINGS

We documented the findings into different categories to make it easier for Stakeholders to integrate them into their decision-making process moving forward.

thin

PERSONAS

We initially grouped the participants by their levels of confidence, self-efficacy, and feelings of safety. Iterated upon what defined the major differences between participant behaviors that surfaced from findings and iterated down to 9 behavioral axes.

While we originally set out to create User Personas, our research pointed us into creating Behavioral Archetypes instead. Personas often focus on the “who” and in this case, we were more interested in “who does what, when they do it, and why”. They provide better insight into behavioral patterns and Users can fall into more than one archetype throughout the journey.

BEHAVIORAL ARCHETYPES

thin

USER JOURNEYS

It was important for us to improve the user adoption of these models as they would be shared with the Open Source community. We mapped the opportunities along with the User Journeys and included the Archetypes that would be most impacted. This had a very positive reaction from both the Client and the Open Source community and resulted in the implementation of processes that effectively optimize the adoption of Open Source documentation for projects like Apache Airflow and Apache Beam. These journey maps and models were presented at a series of events and conferences such as Google Next.

The artifacts and findings from this study were presented globally at different Open Source Conferences and are quickly being adopted by some major organizations encouraging contributors to overcome the challenges of Open Source Documentation. We documented the findings into different categories to make it easier for Stakeholders to integrate them into their decision-making process moving forward.

OPPORTUNITIES

It was important for us to make sure that we made sense of what was learned with our Client to provide a clear direction forward, soo we did an Experience Workshop to strategize and align together. We went through the different opportunities that were uncovered through this research study and prioritized them based on impact and feasibility. Once prioritized, we ensured to help our Client be successful with an effective strategy that aligned with the organization’s goals. We grouped the opportunities in different categories and integrated them into a variety of journey maps and models so that everyone knew the why, what, how, who, and when. We aimed for these artifacts to provide structure and demonstrate how to address different opportunities at different levels to help guide decisions moving forward.

LEARNINGS & NEXT STEPS

Conclusions and learnings Show them that you are capable to be dropped into the middle of something that you’re completely unfamiliar with and that you can navigate your way out and produce something awesome.


This was my first time working with Open Source and I eneded up being an expert in Open Source documentation by talking to Internal experts, trying open source platforms first hand, interviewing Open Source contributors at all levels, going through both, horrible and the best documentation, and learning from what other companies are doing.


How did you navigate your way out of not knowing at all what the hell you’re supposed to be doing.By asking lots of questions and doing lots of primary and secondary research.

to top button