Amazon EVS introduced a new networking resource built on capability from a partner networking team. I led the naming for that resource and carried the name consistently across every EVS surface, so it reads clearly to two different audiences: VMware administrators and AWS users. This is one example of the upstream work in Design Influence and Upstream Collaboration.
The challenge
The resource gives EVS Layer 2 network segmentation, which VMware workloads need inside an AWS-native VPC. Naming it well was harder than it looked because the two audiences bring different mental models. VMware administrators expect VLAN concepts. AWS users expect VPC subnet concepts. The same resource had to make sense to both audiences, and the name had to stay consistent everywhere a customer might encounter it: the EVS API, CloudFormation, the SDK, the console, the user guide, and the dependent services it builds on.
Naming the resource
I advocated for the name from the customer’s perspective across the EVS team and the partner team whose capability the resource builds on. The name I proposed, and the one we shipped, was EVS VLAN subnet.
Each part of the name does a job. “VLAN” is the concept VMware administrators expect to see. “Subnet” helps AWS users map the resource onto the VPC model they already understand, which is why I recommended it over the originally proposed “network”. The “EVS” prefix marks it clearly as an EVS-owned resource.
Because EVS depended on several partner-team services, I also tracked their in-flight documentation and flagged terminology inconsistencies during cross-team review. That helped ensure the resource was described the same way across both teams’ surfaces.
What this demonstrates
- Naming as product strategy, grounded in customer mental models
- Cross-team terminology coordination across dependent services
- Consistent terminology across API, SDK, console, CloudFormation, and documentation surfaces
- Bridging VMware and AWS concepts in a single customer-facing name
Outcomes
EVS shipped with one coherent name for the resource: EVS VLAN subnet. VMware administrators could recognize the VLAN concept they expected, while AWS users could place the resource in the VPC model they already understood. The result was a name that reduced ambiguity across audiences and stayed consistent across the product experience.