OCI Research Project
Talk to users and develop a vision for combining 10+ applications into 1
Situation: All the teams involved in researching, planning, building, and running OCI’s data centers are using dozens of tools maintained by different internal software orgs to do their jobs. They lack insight into the work of up- and downstream teams they rely on, have multiple sources of conflicting data, and lack a “one source of truth” for current project statuses and priorities.
Task: Talk to key members of all these teams to understand how they do their work now, what tools they use, other teams they rely on, their current frustrations, and what they need to truly excel in their roles.
Result: A deeper understanding of needs across teams, a set of core themes that emerged, and a map forward for the project.
Actions:
Competitive research
User interviews
Task flows
Journey maps
Role-based personas
Beginning
The leadership team had a broad idea of what they wanted to accomplish, which was to take the 10+ tools teams work with and combine them into one place to log in where users can do all their work. There are a couple large 3rd party software providers they could buy this from, but OCI prefers to build everything in house. The benefit is that the tool wouldn’t have too much or not enough capabilities for what our users needed. I worked with Technical Product Manager and Technical Program Manager to figure how to start tackling this very big and murky problem. We identified 3 tiers of teams we needed to speak with and what we thought some initial deliverables could be. I advised creating role-based personas, capturing tools used, and mapping their job tasks. We presented to the leadership to get buy-off on this path forward.
Identifying the Life Cycle of a DC
After gathering initial information from our networks, I worked with the 2 TPMs to break down the life cycle of a data center (DC) into 5 pillars, with various sub-teams underneath. I then created this graphic to illustrate the concept, which was helpful for project documentation and presentations to leadership. We used it to help identify where we wanted to start - dive deep into one pillar or survey across multiple pillars? We chose to start by surveying the first 3.
Talking to Users
The TPM and I identified 7 individuals to speak to as part of our first wave. I created an interview template with questions that would tell us about the person’s role, team makeup, how their success was judged, what was going well/not well, all the tools they used and teams they interacted with, and what data and insights they were lacking or had trouble putting together. I learned:
People didn’t always know which team came before or after them, so they didn’t know who to talk to about delays or when problems arose, which put them at risk.
They’re on tight deadlines and in the dark about project statuses, and often on different pages about priorities.
They have too many tools, too many manually updated spreadsheets, and too many places to pull data from (and data often conflicted depending on source)
They’re desperate for automation to cut down on manual tasks.
They’re desperate for dashboards and reports that could help them make decisions faster and more accurately.
Themes Uncovered
To help leadership quickly understand the major themes I uncovered, I created a board showing what our users are asking for.
I then pulled out each sticky and had leaders do a dot vote on a video call in order to establish priority. Access to data was the winner, followed by knowing which person or team was responsible for what, better processes, automation, and trust in data.
Some additional thoughts I asked leaders to keep in mind were that users were creating lots of individual documents and storing them locally. What would happen if they suddenly left the company? Also, we can raise and facilitate process improvements, but ultimately not dictate those that belong to other teams because they’ll need to own and manage them on their own.
Advocating for Time to Envision
After that exercise my engineering leadership said, “Great, now that you know what to build you can start cutting tickets to the dev team.” Well, not quite yet. I certainly had ideas but I didn’t have it all figured out yet. I had to advocate for time to do deep thinking and come up with creative ways to solve all these problems.
I created journey maps for each persona that told the story of a new, improved way of working. They resemble comic book panels, and each story ends with a hand-off to the next team in line so leaders could understand how projects would move through the new, integrated, one-place-to-do-all-your-work application. I also added a box beneath each panel calling out new functionality so the leaders would know which features I was thinking about. They were a hit because they made it much easier to see the benefits of this new way of working.
Results & Post-Mortem
1. The project was put on pause for a higher priority so I didn’t get to finish it. However, it was incredibly valuable for illuminating the various steps involved in building data centers. As a small win, I got the team to build a small feature in one app that shows the status and owner of the process when launching a new region.
2. Getting time on very busy people’s calendars was a challenge, and there was a lack of trust that their time would yield actual results. It’s unfortunate that we didn’t get to prove them wrong, but I continue to work to bring forth the new feature ideas on a smaller scale.
3. The team thought we had a good idea of how everything worked and flowed, but we discovered a lot we didn’t know and other teams and people we’d need to talk to. We only scratched the surface.
4. Leadership began to see the value of user research and storytelling to understand problems and envision ideal future states. I even got the OK to hire another designer!
Conclusion
There wasn’t a good understanding of the UX process on the engineering team I worked on, so I really had to advocate for time to do the research and deep thinking to come up with creative ideas to solve tricky problems. They were used to UX’ers just producing wireframes and “making things look good,” so I had to educate them on the greater up-front work we do, and I had do so politically with senior leaders and execs. The same problems persist for our teams, however, and so I continue to advocate for resuming this project while working on moving forward ideas with users who still hope to see value from their efforts.