Azure Static Web Apps

Contextual Service Discovery
Reframing onboarding as an ecosystem entry point

As Senior UX Designer on Azure Static Web Apps, I was tasked with shaping the end-to-end experience for a new hosting solution within Azure’s cloud platform. The challenge wasn’t just designing an interface, it was defining how developers would first engage with the product and how Azure could guide them toward adoption of related services.

My role

Lead Sr. UX Designer

Company

Microsoft

Project Duration

2 Weeks

Team

UX Designer, UX Content Writer
Product Manager, UX Researcher

Context

Azure Static Web Apps enables developers to deploy modern web applications directly from a Git repository. Adoption was strong and time-to-deploy was fast. Developers could connect a repo, select a framework, and publish within minutes.

However, post-deployment behavior revealed a structural gap. Most users stopped at static hosting and did not activate adjacent services already included in the free tier, such as custom domains, serverless APIs, identity configuration, monitoring, and staging environments. The product successfully provisioned infrastructure. It did not fully guide architectural expansion.

The opportunity
Reshape onboarding from a provisioning flow into a meaningful architectural moment.

  • The Create flow, where the resource is provisioned

  • The Overview dashboard, where capabilities are activated

The Create flow
Mixed required infrastructure fields with optional feature configuration.

Overview dashboard
Mixed Configuration tasks, backend setup, upgrades, and external tools

Process

Human Centered Design
Our team approached this as a behavioral systems problem rather than a visibility issue. Why were developers skipping backend configuration? Why were free-tier capabilities underutilized? Why did expansion stall after deployment?

We combined:

  • Telemetry analysis

  • Moderated usability sessions

  • Competitive benchmarking

  • Iterative prototyping

Rather than optimizing a single screen, we evaluated the entire onboarding arc from resource creation through first expansion.

Research & Discovery

Research Synthesis

Design & Ideation

Redefining the Create flow

Clarifying Scope and Reducing Premature Decisions

The original Create page mixed required infrastructure fields with optional feature configuration. Developers were asked to consider hosting plans, domains, and deployment details all at once. In the updated experience, the Create flow was refocused on provisioning:

  • Subscription

  • Resource group

  • App name

  • Hosting plan

  • Deployment source

Non-essential feature configuration was intentionally de-emphasized and deferred. This reduced cognitive load and clarified purpose. The Create page became the place to launch infrastructure, not fully configure architecture. The message shifted subtly but intentionally: deploy first, expand next.

Competitive Analysis + Usability sessions

In usability sessions, developers explained the behavior clearly. They prioritized speed. They skipped anything that appeared optional. And when a field lacked explanation, it felt like unnecessary complexity.

Competitive review reinforced the pattern. Platforms such as AWS Amplify, Firebase, Cloudflare Pages, and DigitalOcean App Platform positioned onboarding as a capability decision. Backend and identity services were framed as part of defining the application, not as infrastructure configuration. Azure’s flow, by contrast, felt transactional. It guided setup, but it did not guide intent.

What we discovered
Through telemetry analysis, usability sessions, and competitive benchmarking, several reoccurring patterns were surfaced:

  • Developers prioritize speed to deploy over completeness. Give the option to skip and devs will skip.

  • Optional or unclear configuration fields are deferred.

  • The API location field in the Create flow was interpreted as advanced setup, not foundational capability.

  • On the Overview page, users struggled to distinguish between configuration, upgrades, and learning resources.

  • When backend and identity services are framed as architectural building blocks, adoption increases.

  • Competitors like AWS Amplify and Firebase frame full-stack capability early in onboarding, while Azure’s flow felt transactional and infrastructure-focused.

Key insight: ambiguity suppresses activation.

Developers were not rejecting backend services. They were avoiding unclear decisions at high cognitive load moments.

Identifying Patterns

After gathering telemetry insights, usability session notes, and competitive observations, our team shifted from collecting signals to identifying patterns.

Methods Used

Affinity Mapping
We grouped qualitative observations from usability sessions into themes. Hesitation around optional fields, confusion between configuration and documentation, and deferral of backend decisions consistently clustered together.

Behavioral Pattern Analysis
Telemetry data was layered onto qualitative findings to validate whether observed friction translated into measurable drop-off or non-activation behavior.

Mental Model Mapping
We mapped how developers described their workflow in their own words. Most expressed a progression that looked like:

This contrasted with the product’s original structure, which mixed these stages across surfaces.

Comparative Journey Mapping
We diagrammed onboarding flows from AWS Amplify, Firebase, and Cloudflare Pages to identify how they frame backend activation. Competitors structured onboarding around architectural completeness, while Azure emphasized infrastructure setup.

Aligning Two Surfaces into One Journey

Initial configuration happens in two places in Azure Static Web Apps:

  • First, in the Create flow

  • Second, Entry points in the Overview → Get Started dashboard

Originally, these experiences were disconnected. The redesign aligned them intentionally.

Overview Dashboard

From Mixed Cards to Architectural Progression

After deployment, expansion moves to the Overview → Get Started surface. This is where the largest structural change occurred.

V1: Mixed Intent

Configuration tasks, backend setup, upgrades, and external tools appeared at equal visual weight. Users had to interpret each card to determine whether it represented an included feature, a paid upgrade, a portal configuration, or a documentation link. This created friction and hesitation.

Evaluate & Test

V2: Structured Separation

The redesigned dashboard introduced clear groupings aligned to how developers think about applications.

Environment Details
Clear status and deployment visibility.

Configure Your Project
Enable platform features such as:

  • Custom domains

  • Application Insights

  • Database connections

Setup Your Backend
Architectural expansion:

  • Add a serverless backend

  • Configure authentication and role assignments

Tools and Resources
External learning and developer tooling:

  • CLI

  • VS Code extension

  • Documentation

Upgrade prompts were repositioned to avoid conflating monetization with required setup.

The structure now reflects progression:

Deploy → Configure → Extend → Optimize

Prototypes were evaluated through moderated sessions and internal dogfooding. Participants onboarded projects while articulating their thought process.

When backend capabilities were described in terms of outcomes rather than configuration:

  • Activation increased in testing scenarios

  • Confidence in selecting additional services improved

  • Perceived complexity decreased

Even subtle changes in phrasing produced measurable behavioral shifts. The pattern held across experience levels. Clarity influenced action.

Finalized Design

The final onboarding experience repositioned Azure Static Web Apps from a static hosting tool to a full-stack launch platform.

Backend and identity services were no longer framed as optional inputs. They were presented as deliberate architectural choices.

The impact included:

  • Increased backend activation during onboarding

  • Reduced field abandonment

  • Stronger alignment between user behavior and ecosystem goals

The broader takeaway was strategic.

Onboarding shapes mental models.
Mental models shape product adoption.

A single field can communicate optional friction or meaningful capability.
Intentional framing determines which one users perceive.