Turning Developer Feedback Into Better Releases
I introduced a repeatable usability-testing practice for Adobe's internal developer platform, used by more than 5,000 developers across 15 product teams. I recruited developers, facilitated task-based sessions, synthesized findings, and worked with the team to resolve release-blocking usability issues before General Availability.
Feedback arrived after the release
Adobe's internal developer tooling platform served more than 5,000 developers across 15 product teams, but it had never undergone a usability test. The team learned whether a feature worked mainly after launch, through JIRA tickets, Slack feedback, and bug reports. By then, the workflow had already been designed, built, and released, making fundamental changes more expensive.
Our product assumptions were becoming release risk
The consequences were visible in both feedback and product usage. Developer satisfaction averaged 2.4 out of 5 in our annual survey, and some releases introduced new friction instead of resolving the original problem.
One release exposed the gap clearly. We assumed developers wanted a consolidated dashboard for all their projects. Subsequent research showed that they preferred focused, single-project views because they rarely worked across several projects at once. After the consolidated view launched, daily active usage fell by 40%. The decline did not by itself prove causation, but it made the cost of validating our mental model after launch difficult to ignore.
”Better user experience. Please hire a designer to help with the crap design that you have right now.”
Response by developer in annual feedback survey
Practice challenge
How might we validate new workflows before release without slowing a platform team responsible for tooling used across Adobe?
Move validation before General Availability
I designed the practice to produce evidence the team could act on inside its existing release process:
- Biweekly testing cycles with five to eight developers completing 30-minute, task-based sessions
- A consistent session format for observing workflows and capturing where expectations diverged from the interface
- A prioritization matrix that separated release blockers from lower-risk improvements
- A direct path from research findings into JIRA and the existing release workflow
Making the feedback loop repeatable
Making the release risk visible
As the platform became the company standard, I made the case that post-release Slack messages and JIRA tickets were an expensive way to learn whether a workflow made sense. I proposed a lightweight testing practice that could surface release-blocking friction before General Availability and still fit the existing release cadence.
Designing a practice the team could sustain
I worked with engineers and designers to define a repeatable session format: give developers a realistic task, ask them to think aloud, and capture the moments where their expectations diverged from the interface. The format was intentionally small enough to fit into the existing release cadence and flexible enough to reuse across features.
Moderating task-based sessions
For each testing cycle, I recruited volunteers through our developer community channels and facilitated one-on-one sessions. I avoided leading participants toward the expected path, asked follow-up questions when they hesitated, and used a notetaker when one was available. The goal was not to collect preferences; it was to see whether developers could complete the intended workflow and explain why they made each decision.
Connecting evidence to release decisions
I consolidated the notes, grouped repeated breakdowns, and reviewed the evidence with the team. We prioritized gaps that could block a General Availability release, moved those findings into JIRA, and implemented the highest-risk fixes before launch. After release, we continued monitoring the same community channels for evidence that the revised workflow still caused confusion.
Research became part of the release conversation
The strongest evidence was operational and qualitative. Findings from sessions were discussed as release decisions rather than sent directly to the backlog, and the team resolved the highest-risk workflow issues before launch.
Features that went through testing generated fewer complaints in our developer channels and received a more positive response after release. The first cycles also gave us concrete examples we could use to explain the value of usability testing to other teams, including teams that did not build user-facing interfaces.
”For the developers who helped develop the new onboarding feature, kudos. It has been a pleasant change.”
Developer after changes were implemented
What I would change now
Move testing earlier
Recruiting uncompensated participants became harder over time, so we often relied on a smaller, familiar pool of developers. More importantly, sessions still occurred late in feature development, when changing the underlying workflow was expensive. I would now run smaller evaluative sessions as soon as the core interaction could be simulated, then reserve pre-release testing for validation.
Design the practice, not only the session
The durable outcome was not a collection of sessions. It was a shared way to recruit participants, observe tasks, prioritize evidence, and connect findings to delivery. I later worked with colleagues to turn that approach into a generic framework other Adobe teams could adapt to their own workflows.