Nancy Nguyen
UX research case study
Company: ServiceNowProduct: Developer Portal

ServiceNow Developer Portal: How 3 Connected Studies Aligned Stakeholders and Influenced Executive Roadmaps

A newly launched AI build tool was sitting on the homepage, and almost no one was using it. I had three months to find out why. As the sole researcher, I turned that one adoption question into the research foundation for a full site redesign.

🔒 Some internal names, participant details, and figures have been generalized to respect confidentiality.
Redesigned Developer Portal homepage on a desktop monitor, next to the API reference, on a green and blue gradient

Role

Lead UX Researcher

Timeline

3 months

Skills

  • Research scoping
  • Roadmap prioritization
  • Persona and journey mapping
  • AI-assisted research ops

Tools

Great Question
Whiteboard
Qualtrics
Adobe Analytics

Results at a glance ✨

The Strategic Shift: From UI Fixes to North Star Vision

Low AI adoption was an orientation problem, not an AI problem.

Guided executive and product strategy

Unified data from 5 cross-functional teams (PM, CX, Marketing, Content Strategy, Engineering) to define targeted user segments and streamline critical developer workflows for upcoming feature releases.

Informed official product requirements

Led 3 mixed-methods studies whose findings shaped the redesign strategy, driving 4 of 6 near-term scope priorities in the PM Director's PRD.

Reduced rework and project risk

Tested 2 design concepts with developers to validate IA, catch usability issues early, and prevent costly technical changes later.

Overhauled information architecture

Defined foundational design principles adopted across multiple teams to ensure execution consistency for the redesign.

Automated research systems and engagement

Built a custom AI workflow that auto-generates research recaps from our repository, hitting a 20% stakeholder engagement target.

My role

Sole UX Researcher
Leading end-to-end studies, from planning and recruiting to analysis and final delivery

Nancy Nguyen at the ServiceNow office
  • Spearheaded the end-to-end research strategy as the standalone researcher for the vertical, managing stakeholder expectations and research operations under tight delivery timelines.
  • Triangulated qualitative and quantitative data to diagnose root causes of low product adoption, translating ambiguous user friction points into clear, actionable design opportunities.
  • Orchestrated cross-functional collaboration across distributed teams (Pacific and Eastern time zones) to align Design, Product Management, and Engineering on user needs.
  • Delivered evidence-based recommendations that directly shaped the product's information architecture and content strategy to improve baseline usability.
  • Facilitated strategic alignment workshops with cross-functional leadership (Design, Product, Engineering, and Marketing) to embed user insights into the long-term roadmap.

🌱 Why I took this on

As the only UX researcher for the ServiceNow Developer Portal, I joined a massive developer ecosystem where small friction points quickly snowball into major obstacles. I was motivated by the high-stakes challenges of this scale.

I saw this research as an opportunity to grow as a true strategic partner and advocate for the customer by focusing entirely on cross-functional collaboration and method triangulation.

Background

The front door for developers building on ServiceNow

Developer Portal gives developers free personal developer instances (PDIs), learning courses, API and reference documentation, blogs, and community. Since October 2025, its homepage has featured Build Agent, a new AI tool that lets developers build applications by describing them.

developer.servicenow.com
Developer Portal homepage with the Build Agent prompt box
The homepage at the start of the project, with Build Agent front and center.

Why it mattered

As the central hub for developers, the portal is where people start building on the platform. It offers:

  • Risk-free prototyping without fear of breaking production
  • Learning courses and certification prep
  • Access to developer resources and APIs
  • A community knowledge base and forums

Research approach

Defining the Challenge

Problem

<1%

of new PDI users were using Build Agent to build or customize applications, despite its prominent placement.

Goal

Understand what was driving low Build Agent adoption and identify design opportunities to inform Developer Portal's strategy.

Research questions and how I answered them

Why aren't developers using Build Agent from Developer Portal?

Study 1 (Diagnostic)Exploratory and evaluative
  • Telemetry and support log analysis
  • CSAT open-text audit
  • Stakeholder alignment loops

Who visits the site, what are they trying to do, and which resources do they use?

Study 2 (Journeys)Descriptive and behavioral
  • Journey mapping
  • User segmentation
  • Developer Advocate loops

How do we design a portal that matches developers' mental models?

Study 3 (Mental models)Structuring and generative
  • Card sorting
  • IA validation
  • Mental model mapping

Research journey

Triangulating the Developer Journey

How a 3-part research strategy turned fragmented stakeholder assumptions into a validated, intent-driven product roadmap.

  1. 2 monthsStudy 1Build Agent Adoption Signals
  2. 3 weeksStudy 2Developer Segments and Journey
  3. 2.5 weeksStudy 3Developer Mental Models
  4. FinalOutcomeNear-Term Design Strategy

👆 Select a study to see how it unfolded.

📊 Study 1 | Diagnostic | 2 months

Build Agent Adoption Signals

The first ask pointed toward quick UI fixes to boost Build Agent. Before recommending any, I wanted to know what the existing data already said. I pulled together CSAT feedback, Build Agent telemetry, and past research, then ran a heuristic evaluation across two real workflows: a new user looking for a course, and an experienced developer troubleshooting their instance.

🔬 Research methods
  • Secondary research
  • CSAT feedback
  • Build Agent telemetry
  • Heuristic evaluation
💡 The turning point

Developers weren't struggling with Build Agent. They were struggling to orient themselves on the portal at all. Adoption was the symptom, and orientation was the cause.

🧭 The rationale

Why start with existing data

Interviews take time and budget. Analyzing prompt logs, CSAT surveys, and past case studies first surfaced the biggest friction points: fragmented navigation and weak search, outdated and buried documentation, and no clear starting point.

Why combine sources

Each source answered a different question. Data showed where developers dropped off, and the design review explained why. Together, they turned friction themes into concrete recommendations.

Working with thin signals

Of the 2,094 survey responses I analyzed, 600+ came in after Build Agent launched, and only one of those named it directly. Rather than overstate what indirect signals could prove, I treated Study 1 as directional: it showed us where to look, not the full picture.

Two heuristic evaluation workflows with annotated homepage issues such as information overload and bad prediction
Heuristic evaluation of two workflows, each with a persona, goal, and success metric.

Key insights

What developers actually need from the portal

Four insights, each tied to a change the team made.

1

The task drives tool choice

Developers don't identify with one tool or coding style. They use whatever solves the problem in front of them, so design should support movement between tools rather than assume a fixed skill level.

"While there is an extreme version of each... most of them very quickly congregate to the middle."

✅ Outcome

Designers built a task-based structure into the final redesign.

2

Examples build trust before commitment

Developers hesitate at vague, high-stakes use cases but respond quickly to concrete, low-risk ones they can picture themselves doing. Seeing a real example builds more confidence than reading an explanation.

✅ Outcome

The app gallery became a top priority, and engineers began removing the sign-in requirement that blocked access to it.

3

Speed to answer reduces friction

When developers hit a wall mid-task, they need a fast, specific answer. Short, accessible guidance meets them at their actual point of need.

✅ Outcome

The UX team began working with internal developers on a resource library to replace long-form courses.

4

Unified search enables discovery

Most developers don't find what they need through the portal's search. They go to Google or an AI assistant first and reach official resources only indirectly. A context-aware, unified search experience will be the differentiator.

✅ Outcome

Unified search became a core pillar of the redesign strategy, prioritized over one-off UI fixes.

How I used AI

AI as a building tool and a research partner

🎯 What it deliveredContributed to two of my core research team's OKRs through the AI-powered quarterly Research POV newsletter
20%

Stakeholder engagement target hit for the quarterly Research POV (responses and reactions)

KR1: Launch an AI-powered quarterly research communication
Quarterly

Research POV newsletter launched, with format, channel, and timing iterated on feedback

KR1: Launch and iterate
1

AI workflow defined and implemented to auto-generate newsletter content from the research repository

KR2: Automate POV content generation

🛠️ Building with AI

I designed a custom AI workflow that automated research synthesis, pulling insights from repositories and generating instant summary reports.

  • Expanded visibility of internal research
  • Adopted across multiple teams
  • Sped up product decision-making

🤝 Partnering with AI

I treated AI as a research assistant for repetitive operational work.

  • Crafted prompts that produced stronger outputs
  • Drafted research plans, interview guides, and the roadmap
  • Transcribed interviews and drafted follow-up questions

Challenges

What made this hard

⚠️ The challenge

Each study came with a tight, sometimes shifting deadline, and design and product needed decision-ready findings fast.

Steps I took to overcome it

  • Prioritize by impact. I built a matrix around urgency, impact, and effort with stakeholders.
  • Make status visible. I kept a research repository in SharePoint and our portfolio management tool so every team could see study status.
  • Flex the method, not the quality. I adjusted methods to shifting timelines without compromising insight quality.
Study 2 exampleThe designer needed prototypes validated within two weeks, so I pivoted from external recruiting to internal Developer Advocates.

Reflection

Reflecting on this project, it stands out as a proud early-career milestone where I earned a seat at the strategy table to shape product direction before decisions hardened.

Managing competing priorities across different teams, directors, and VPs taught me two invaluable lessons about leadership and scale:

Lesson 1

🤝 Be proactive to build trust

Trust isn't just given; it's earned. I invested time in stakeholder interviews, scheduled regular 1:1s, stepped up with high-conviction, data-backed ideas, and started research early. This proactive approach gave research the leverage it needed to lead the conversation.

Lesson 2

🧭 Bring teams closer to the customer

Democratization keeps humans at the center of our work, but giving teams direct access to insights requires guarding data quality. By involving stakeholders early, sharing clear discussion guides, and running fast debrief loops, we helped our cross-functional partners learn quickly without sacrificing research standards.

This redesign proved that a consistent product is really just a byproduct of an aligned team. That alignment happens when research acts as both a steady anchor and an enabler for everyone else.