Systems modernization
Case Study 4How I evolved a foundational product workspace through intentional non‑naming, modernizing the system without adding new terminology or conceptual overhead.
As Power Apps evolved, the “Start” experience had become a tangle of legacy patterns, overlapping concepts, and UI surfaces that no longer reflected how users approached app creation. A new workspace was proposed and, with that, the call for a brand and name.
My role was to evaluate that question rigorously: Does this space truly need a name? Or would naming it add unnecessary weight to an already crowded Microsoft vocabulary?
The Problem
The team was feeling the friction of a legacy flow that no longer matched user intent. The instinct was to name the space and give it a new conceptual container.
But naming inside Microsoft is never neutral. A new term:
propagates across products
competes with existing concepts
risks conflicting with existing terminology
becomes a long‑term maintenance burden
is often only needed internally - not externally with customers
My Role
Senior UX Content Designer and Terminologist, lead content strategist for Power Apps data and maker experiences
evaluated whether the emerging “Start with data” space required a formal name
analyzed the impact of introducing a new term across Power Apps, Dataverse, Azure, and the broader Microsoft ecosystem
identified risks of adding vocabulary to an already saturated terminology landscape
clarified underlying concepts and definitions to reduce ambiguity without naming the space
reorganized the experience around user intent to strengthen conceptual clarity
partnered with PM, design, and engineering to align on a non‑naming, structure‑first path forward
ensured the experience could evolve sustainably without accumulating additional terminology debt
My Process
A. Assessed the conceptual boundaries
I mapped the existing concepts, their relationships, and the points where users experienced ambiguity. This surfaced the real issue: the friction wasn’t caused by a missing name — it was caused by unclear conceptual structure.
B. Evaluated the cost of introducing a new term
I analyzed how a new name would interact with Power Apps, Dataverse, Azure, and broader Microsoft terminology. The ecosystem is already saturated, and adding another term would create long‑term maintenance and alignment challenges.
C. Explored non‑naming pathways to clarity
Instead of defaulting to naming, I examined how far we could get by clarifying the underlying concepts, tightening definitions, and reorganizing the flow around user intent. This allowed the experience to become more coherent without adding vocabulary weight.
D. Recommended structural clarity over naming
By strengthening the structure instead of the vocabulary, the team gained a flexible foundation that can support future capabilities without requiring new terminology.
The Outcome
Avoided introducing a new term into an already overloaded ecosystem
Reduced conceptual ambiguity across the “Start with data” flow
Delivered a modernized experience grounded in user intent
Established a conceptual framework that can scale without naming inflation