Content Strategy & Systems Design
I'm a content strategist working in language systems — information architecture, content operations, and the structures that make complex products navigable. Writing is one part of that practice. At ProQuest I built UX documentation, internal knowledge bases, and content systems for cross-functional teams — including a SharePoint site, an Airtable database for accessibility workflows, and structured documentation that made complex internal processes legible to non-technical colleagues. These samples demonstrate how I think about language, structure, and audience across different content contexts — all oriented toward SaaS and tech products.
Making content accessible required three separate kinds of work on the same item: legal documentation, licensing and permissions clearance, and the platform work to actually implement the accessible format. Each ran on its own timeline. Status lived in a spreadsheet plus whatever email threads the spreadsheet couldn't capture.
No one could see another team's progress without asking directly. Teams duplicated effort on some items because they didn't know work was already underway. Other items stalled because no one knew whose turn it was to act next.
Three linked trackers — legal, licensing, platform — tied back to the same content item. Each task moved through the same stages: requested, in progress, review, done. Notes and question fields carried clarification and back-and-forth on individual records, so context stayed attached to the work instead of living in a separate email thread.
Multiple views let the team group and filter records by publisher, task type, or whatever else mattered for the work in front of them. If one publisher had several records that amounted to the same task, someone could see that, claim all of them, and do the work in one pass instead of picking it up piecemeal. I built the views and taught the team how to build their own.
The database went to the UX team for review before launch — its views, fields, and navigation held to the same accessibility standard the database existed to track.
This audit examines the Ubuntu documentation landing page and upgrade documentation — a high-traffic entry point for users making consequential decisions about their systems. Five findings across three categories: content currency, plain language clarity, and information architecture.
New users don't know what they want from a tool until they've had a chance to figure it out. Onboarding that front-loads configuration assumes the opposite — and loses users at the exact moment they most need to succeed. Obsidian is a powerful, genuinely useful note-taking tool. It's also a near-perfect case study in what happens when a product is built by and for people who already know what they want — and the onboarding reflects that.