What happens when you give me access to a codebase and 6 months to figure it out
A product team with no dedicated writer needed documentation for 30+ mobile components. I partnered with their senior TPM to scope priorities, resolved a format debate between engineers and designers, and built an AI tool to scale the work. Documentation time dropped from 3+ hours to 30 minutes per component.
Role: Cross-team partnership; scoped priorities with TPM, coordinated with engineers and designers
Scope: 30 mobile app components for Amazon’s seller app
Timeline: 6 months, alongside other workstreams
The Seller Mobile App team had no designated writer. Their documentation was written by contract writers, the staff UX designer, sometimes even the engineers. Everyone was stretched thin, and the result showed: auto-generated technical references that engineers could skim but designers and PMs couldn’t use to make decisions.
This wasn’t a content gap. It was an organizational gap. A product team was shipping components that downstream teams couldn’t adopt confidently because no one owned the space between “here’s the spec” and “here’s how to use this well.”
I came to the team with a proposal to add sections with detailed guidance: best practices, edge cases, and accessibility considerations. I advocated that designers and PMs need context to succeed.
Understandably, I was met with some resistance. It’s not easy to agree to adding a layer of complexity to a system that requires minimal effort, especially when you’re underresourced.
I grounded my case in behavioral research:
Documentation that explains reasoning produces more confident decisions than rules alone. When designers don’t know why a guideline exists, they can’t adapt when the situation doesn’t precisely match the information in front of them. Positive framing and contextual instructions measurably improve follow-through, especially under cognitive load.
Ultimately, we agreed upon a hybrid approach.
I sat with engineers, reviewed JSON schemas, set up an iOS simulator to see components in context. I researched Apple’s HIG, Material Design, and Shopify’s Polaris to match industry standards and developed a template that had:
It was time to get to work. We had plans to publish docs for ~30 components in the next quarter.
About 3 components in, I realized there was a mechanical pattern to my own process: Read the schema, identify props, write the same section types, apply the same framing.
As I continued, I developed a set of rules encoded template structure, voice and tone, editorial standards (sentence case, character limits, no latinisms). These rules became the prompt for an AI content generator that used Amazon’s internal Claude-based tool.
I batched my drafts and hosted doc “bashes” with the team to verify the output and used their feedback to iterate and improve the prompt. By the 15th component, I could input a JSON schema and get a first draft that both I and the team were happy with. We shipped documentation for 30 components that quarter.
The goal was never just “write the docs.” It was to build a system the team could sustain without me.
Before: 3+ hours per component. Engineers deprioritized it. Designers made decisions without documentation.
After: 30 minutes to generate and review. Engineers went from writing docs to verifying them. The AI tool and templates stayed with the team after I moved on.
The harder problem wasn’t writing 30 component docs. It was defining a structure flexible enough to cover components ranging from a simple button to a complex navigation pattern, rigid enough that any author (human or AI) would produce consistent output.
Required sections for every component: Do’s and Don’ts, Anatomy, Editorial. Even simple components need explicit guidance on label length, punctuation, and when not to use them.
Conditional sections: Options, Placement, and Accessibility appear only when relevant. No empty sections, no filler.
Practical accessibility. Not abstract WCAG citations. Action-oriented guidance tied to the specific component.
Specific editorial rules. Not “keep labels short” but “30 characters max, 1 to 3 words.” Precision scales; vague guidance doesn’t.
“Andie quickly stepped up to bridge that gap. She took the initiative to learn our components, defined a complete documentation process, partnered with me on priorities and timelines, worked closely with developers to fact-check details, and owned the publishing workflow from review to approval. Her work became a key enabler for the successful adoption of our new platform.”
— Cecilia Fung, Senior Technical Product Manager, Amazon
“You did a darn good job running things and keeping us in check.”
— Matt Caruano, Engineering, after a documentation sprint