Projects
Why
The Terminal API is foundational to in-person payments, but its legacy structure made it difficult to understand,
maintain, and integrate with modern developer tooling. Improving its accessibility was critical for long-term
platform scalability and developer trust.
What
The Terminal API is based on the
nexo retailer protocol,
not REST. For years, its only reference lived on a single page assembled from many HTML files, making it hard to
navigate and incompatible with our OpenAPI-based API Explorer.
How
I mapped the full API structure by reconciling the official nexo PDF specification, existing documentation, and
the OpenAPI requirements of our API Explorer tooling. I coordinated work between the team owning the Terminal API
implementation in C and the platform team responsible for API reference pipelines.
We created a Python script to generate OpenAPI specs our tooling could consume and introduced a new page type in
the API Explorer to present the API structure by request type.
Result
The migration brought a critical legacy API into the standard developer experience without altering its
underlying protocol. It reduced long-term maintenance risk, improved discoverability, and increased confidence
in a globally used payments API.
Why
NFC integrations are prone to failure due to subtle differences between card types, terminal hardware, and
operating systems. Clear guidance here directly reduces integration errors and support load.
What
Developers must construct four different request types (identify, read, write, or session), each with
card-specific data structures. In addition, Adyen terminals run two operating systems that do not always offer
feature parity.
How
I structured the documentation around user intent rather than API shape, organizing the page so developers
could quickly identify the correct combination of card type, terminal type, and request type using existing CMS
components.
Result
The resulting documentation reduced cognitive load in a complex integration flow and improved task completion
for a feature area with a high potential for implementation errors.
Support supply-chain automation without exposing internal APIs
Why
The Logistics API enabled Adyen’s supply chain to automate delivery workflows and replace an aging messaging
system under a fixed deadline, while remaining inaccessible to the public.
What
The API needed to be documented and usable by partners without appearing in official API reference tooling.
Additionally, the API was still under development when documentation work began.
How
I authored the API reference directly from Stoplight mockups and designed an information architecture that made
the API discoverable only to intended users through navigation and structure rather than tooling.
I also identified inconsistencies across endpoints and led efforts to simplify request and response schemas to
improve integrability.
Result
The documentation enabled partners to migrate off the legacy system before the planned deadline and influenced
API design decisions that made integrations easier and more reliable.
Why
Navigation friction was preventing users from finding critical in-person payments content despite high overall
traffic, negatively affecting usability and confidence.
What
The left-side navigation contained 67 items under 10 labels, creating cognitive overload and making it difficult
for users to locate relevant information.
How
With a writer colleague, I conducted interviews with internal stakeholders and direct clients to understand how
users consume content. We validated findings against Google Analytics data and rebuilt the information
architecture around clearer conceptual groupings.
Result
The new structure reduced navigation items from 67 to 47 under 7 labels. One year after launch, analytics showed
a substantial decrease in negative feedback, increased traffic to previously underused areas, and an overall
traffic increase of approximately 25% across the IPP section.
Why
ProGlove’s products were scaling faster than its documentation infrastructure, creating risk for onboarding,
support, and partner integrations.
What
When I joined, documentation consisted of minimal content on a static MkDocs site. As the sole writer, I was
responsible for tooling, content creation, structure, reviews, and delivery across hardware, software, and
APIs.
How
I introduced Paligo to enable scalable authoring and faster review cycles, migrated all existing content using
Pandoc and custom scripts, designed a new information architecture for the full product portfolio, and
implemented OpenAPI references for public APIs.
I also customized HTML and CSS to align the documentation portal with the company’s visual identity.
Result
Within a year, ProGlove had a professional, multi-product documentation portal with versioning, release notes,
media, and automatically updated API references, supported by sustainable documentation practices.