Content strategy

Case Study 2

How I guided a low‑code product into cross-functional territory by introducing a technical term and process with lightweight explanatory patterns.

Dynamics 365 Virtual Agent had decoupled from Customer Service Insights and found a new home in Power Platform. The new Power Virtual Agents was evolving from a low-code/no-code tool for SMEs into a product used by cross-functional teams, including technical contributors. With that came increased functionality and the need for more terms to describe it.

A new feature allowed makers to define structured, domain-specific information that the bot could extract from natural language. The most accurate label for this concept was a technical term already established in Azure and the broader data-science community: entity.

The Problem

  • Without a background in database managment or data science, the term “entity” could mean.. anything

  • The concept needed a name, and would feature prominently in navigation and as a selling point

  • Industry and competitors were a consideration

  • Alternative labels (“slot filling,” “data type,” etc.) were not clear enough and too complex

  • Aligning to this term would later highlight a major term conflict within Microsoft

My Role

  • UX Content Designer specializing in terminology and conceptual clarity

  • Responsible for introducing the technical term in a way that:

    • preserved the low‑code experience

    • supported technical contributors

    • aligned with Azure and the industry, competitors

  • Designed the explanatory patterns that taught users how to configure the feature

  • Partnered with PM, design, data science, and research to validate comprehension

My Process

A. Positioned the technical term with a clear, approachable definition

  • Introduced the term with plain language

  • Anchored it in real‑world examples

  • Created a shared mental model for SMEs and technical users

B. Designed lightweight explanatory patterns for configuration

  • Framed choices around user intent, not technical theory

  • “Use a list when…” → known values

  • “Use a pattern when…” → values follow a format

  • Paired technical labels (e.g., Regex) with plain‑language explanations

  • Used examples to make abstract concepts concrete

C. Hid complexity behind optional, supportive content

  • Helper text

  • Inline examples

  • Short, focused modals

  • Progressive disclosure so SMEs weren’t overwhelmed

D. Ensured alignment with Azure without importing unnecessary complexity

  • Preserved the canonical term

  • Avoided introducing competing labels

  • Clarified the boundaries between PVA’s implementation and Azure’s

E. Validated the pattern with cross‑functional teams

  • SMEs understood the concept without needing ML knowledge

  • Technical users recognized and trusted the term

  • The pattern scaled across features

The Outcome

  • SMEs could build their knowledge of data science

  • Technical contributors recognized and trusted the terminology

  • The feature shipped with strong comprehension and low support burden

  • The explanatory pattern became a model for introducing other technical concepts

  • The product evolved without losing the clarity that defined it

Previous

Concepts and terminology
Next

Conflict resolution