Across ROSA and Amazon EVS, I embedded with product and engineering teams early in the development cycle to shape console UX, API design, and product decisions while the documentation plan was still forming. Bringing documentation expertise into the design phase let me act as a customer-experience advocate in design discussions and resolve friction at its source.
This page collects that upstream work. The related case studies below show individual examples in depth.
The challenge
By the time documentation usually starts, the API and console decisions that shape the customer experience are already made. Parameter names, error messages, validation timing, and terminology are hard to change once they ship, and a public API has to stay backward compatible. The opportunity was to bring the customer’s perspective into those decisions while they were still being designed.
How I worked upstream
I joined weekly design workshops with product managers, UX designers, and console developers, reviewed Figma mockups, and gave feedback on workflows, UI text, and information architecture. I also carried operational knowledge between service teams, so a friction pattern one team had already hit did not repeat on the next.
Because I was in the room for the design rationale, the documentation I wrote later reflected decisions I helped shape, not just decisions I documented after the fact.
Design contributions
Across ROSA and EVS, I contributed detail-level improvements during the design phase, shaping the customer-facing API and console experience before launch.
Console and workflow design
- Recommended surfacing VPC Route Server prerequisites on the first screen instead of deeper in the workflow, preventing customers from discovering blocking requirements mid-deployment.
- Proposed a receipt-style cost summary with a table layout for the ROSA contract flow, making pricing easier to compare and understand.
API and parameter design
-Proposed the name serviceAccessSubnet for a new EVS component, chosen to be self-describing so its purpose was clear without a paragraph of explanation. It became the API parameter and the term used across related surfaces.
- Identified parameters that could not be used together, such as
dedicatedHostIdandplacementGroupId, so the mutual exclusivity was documented upfront. - Made sure validation constraints, such as the CIDR block range (
/28to/24), lived in parameter descriptions and not only in error messages, so customers could plan correctly before provisioning.
Error messaging and validation
- Reworked vague errors such as
Invalid CIDR blockinto specific guidance:CIDR block must be between /28 and /24. - Recommended surfacing validation earlier in workflows, so customers hit actionable errors before they were deep into setup.
Terminology and consistency
- Aligned ROSA terminology across AWS and partner surfaces, including console and documentation, so customers saw consistent language across the cross-company experience.
- Coordinated EVS and VPC alignment on VLAN terminology, contributing to API reference and documentation updates so the narrative stayed coherent across dependent services for both VMware and AWS audiences.
What this demonstrates
- Bringing customer-experience perspective into API and console design before documentation starts
- Detail-level API craft: parameter naming, mutual exclusivity, validation constraints, and error messaging
- Cross-service and cross-company terminology coordination
- Treating documentation expertise as design input during development
- Turning downstream documentation concerns into upstream product improvements
Outcomes
These contributions were adopted into shipped ROSA and EVS console and API surfaces. The result was a more coherent customer experience: names, errors, constraints, and terminology were settled during design, so the documentation could describe a product experience that had already been shaped for clarity.
Related case studies
These single-project case studies show the same upstream approach in depth: