Discovery for Developer Experiences
Challenge: Identify pain points and opportunities for automation, unification, and increased visibility of impact across user journeys for backend engineers.
My Role: As a Senior Service Designer I led 20 interviews and synthesized findings to determine underlying mindsets for stakeholder segments and key opportunities for improvement and automation.
Team Structure: Senior Service Design (me), Product leadership
Summary: Our core infrastructure team asked for help mapping and identifying moments of friction across 3 key backend developer journeys: new development, fixing an incident, and maintaining or scaling services. Over 2 months we held interviews with stakeholders across different divisions of the company to better understand their processes, moments of friction, logic, and mindset for each of the three journeys. After each interview we then synthesized the processes to better assess what moments ran smoothly, needed standardization, or needed quicker feedback loops or approvals.
the Research and findings
Each interview was used to validate any assumptions for new feature development, fixing an incident, and service maintenance. While the general steps across teams remained consistent, the level of risk aversion affected the severity of checks and feedback throughout the user’s process. Teams that were closer to sales or core services had significant review processes and were hesitant to use any automation for fear of not being in control of the outcomes. Across the board users generally found new development quick and easy due to recent investment in new tooling. They found fixing incidents challenging in finding the problem, confirming their fix worked, and fully understanding the impact of the fix across dependent services. While maintenance was often the most planned, they found it hard to scale services without visibility of dependency map of the ecosystem.
We mapped out moments where automation could speed up feedback loops and approval processes. We then built out best practices and documentation to ease frustration identifying the problems behind the fix and assessing the best way to test and scale the service. We then followed up with each user to dig in deeper to configuration requirements - better assessing if there are any parameters we could establish as defaults given the necessary work. We found that users wanted a balance of standards and flexibility and suggested establishing the defaults as guardrails and that can be easily fine tuned when needed.