Rescuing a GA Launch: Research and Engineering Studio User Guide

Overview

Research and Engineering Studio (RES) on AWS is a scientist- and engineer-focused web-based portal that lets administrators create and manage cloud-based research environments to visualize data and run interactive applications. It’s a complex, multi-service solution that depends on correct configuration of networking, identity, and compute.

Seven weeks before the RES GA launch, the assigned Technical Writer resigned without starting the documentation. The service needed a complete user guide for administrators and end users, plus deployment guidance—on a tight, non-negotiable timeline.

I took ownership of the project, created a documentation plan from scratch, built a test environment, and authored the RES User Guide in time for launch on November 13, 2023.

My Role

I acted as the primary technical writer and de facto documentation lead for RES. My responsibilities included:

• Clarifying scope and expectations with product and engineering stakeholders
• Creating a documentation schedule aligned with the GA timeline
• Building and exploring a RES test environment to understand real workflows
• Designing the information architecture and table of contents
• Authoring deployment guidance as well as administrator and end-user topics
• Driving review cycles and incorporating SME feedback on a rolling basis

The Problem

When I inherited the project:

• The original writer had resigned and no documentation work had started
• There were only seven weeks until the GA launch date
• I had minimal existing rapport with the service team
• No documentation plan, outline, or prioritized content list existed
• RES itself required understanding a non-trivial mix of services, including:
  • Amazon VPC
  • Amazon EC2
  • Microsoft Active Directory
  • Custom domain configuration

The ambiguity wasn’t just about the product—it was about how to even start under severe time pressure while still maintaining quality.

My Approach

1. Establish a documentation plan and cadence

The first step was to bring structure to the chaos.

• Scheduled a recurring weekly cross-functional discussion series with PMs and SDEs
• Created a documentation schedule aligned to the GA timeline, clarifying:
  • Which topics were required for launch
  • When drafts would be ready
  • When reviews and approvals were needed
• Used these touchpoints to validate priorities, reduce ambiguity, and ensure everyone understood what “done” looked like

This turned a vaguely defined, high-pressure request into a manageable, time-boxed plan.

2. Build a RES environment and learn hands-on

Rather than relying solely on second-hand descriptions, I:

• Created my own RES test environment
• Walked through the same setup and usage flows that administrators and users would follow
• Identified edge cases and potential failure points while working in the console

This hands-on exploration allowed me to:

• Design an information architecture that mirrored real tasks
• Capture accurate sequences, prerequisites, and dependencies
• Write documentation grounded in how RES actually behaved—not just how it was intended to work

3. Design a clear table of contents

With a growing understanding of the product, I drafted and validated a table of contents for the user guide, including:

• Administrator topics, such as:
  • Setting up and configuring RES
  • Managing research environments
  • Integrating with networking and identity services
• End-user topics, such as:
  • Accessing RES
  • Working within provisioned environments
  • Visualizing and analyzing data

I reviewed this TOC with the PMs and SDEs to make sure it captured the right coverage for GA and reflected both RES goals and customer needs.

4. Document complex deployment and integration steps

RES isn’t a standalone tool—it depends on a careful setup of network and identity components. I documented:

• How to configure custom domains for RES
• How RES interacts with:
  • Amazon Virtual Private Cloud (VPC)
  • Amazon Elastic Compute Cloud (EC2)
  • Microsoft Active Directory
• The key deployment steps and prerequisites that admins needed to complete before users could be onboarded

This reduced the risk of misconfigurations that could block adoption at launch.

5. Drive iterative reviews and approvals

Given the tight timeline, I couldn’t wait until everything was written to start reviews. Instead, I:

• Shared drafts as they became available
• Collected feedback in parallel from PMs and SDEs
• Resolved comments and questions continuously instead of in a single late-stage pass

This rolling review model allowed us to keep momentum without sacrificing quality.

The Solution

During the compressed timeline, we prioritized the documentation that was essential for GA: administrator setup and configuration instructions, cross-service integration guidance, and end-user onboarding. A full troubleshooting section was intentionally deferred until after launch so we could focus on delivering the core implementation workflows that customers needed on day one.

The documentation supported both early adopters and long-term customers by making a complex solution feel approachable and navigable.

Impact

• The RES User Guide was delivered on time for the November 13, 2023 GA launch, despite the project starting from zero only seven weeks earlier.
• Stakeholders had a clear, shared documentation plan instead of ad-hoc expectations.
• Administrators gained practical, step-by-step deployment and configuration guidance for a multi-service solution.

Skills & Tools Used

• Technical writing for cloud and multi-service solutions
• Information architecture and table of contents design
• Hands-on product exploration and environment setup
• Cross-service documentation (VPC, EC2, Active Directory, custom domains)
• Stakeholder alignment and review facilitation
• Working under tight, launch-driven timelines