Skip to main content

Services

I'm a documentation specialist with over a decade of experience. My services include writing docs, but also thinking about how to organise, maintain, and deliver them; how humans find and learn information, and how your developers can be better at owning their own docs.

Most projects are a blend of the services on this page, so don't worry too much about which box you're in; get in touch for a chat about what you need.

Writing documentation

Clear, accurate, usable documentation, from API references to knowledgebases.

Designing documentation

Content strategy and quality design work to get docs organised, structured, and easy to navigate.

Improving docs processes

Training, workflows, tooling, and style guides, so your team can confidently own their own docs.

UX writing

Docs and UX are the same problem, two sides: tooltips, UI labels, error messages, journeys.

Writing documentation​

My core craft is in writing clear, accurate documentation, targeted for the people who rely on it.

My expertise covers many forms of software documentation, including:

  • User manuals
  • API reference docs
  • Knowledgebases
  • Release notes and patch notes
  • Internal documentation portals

I've worked with some incredibly complex technology, and I'm used to diving into unfamiliar products and figuring out how they actually work. I'm great at building mental models of technical systems, even from limited documentation or a developer's half-explained shorthand. If you're worried your software is too complicated for a non-developer to get their head around, book a free consultation and try me!

Designing documentation​

If your documentation already exists, but has grown into something sprawling, unmanageable, or impossible to navigate, I usually start with a plan to fix it.

Docs content design and strategy involves deciding which pages should exist, how they should be organised, and how people will realistically find them. I use established information design frameworks like Diátaxis and DITA, and I pay close attention to cognitive accessibility, structuring content so it's easy to find and easy to follow.

On the quality side, I help teams build good practice into the documentation process, rather than bolting it on as an optional step at the end. That means style guides and templates people actually use (a particular obsession of mine!), review and authoring workflows that catch problems early, and a shared definition of what "good" looks like, so everyone knows what they're aiming for.

The longer-term goal is usually cultural: getting a team confident enough to think about the docs like they think about their code.

Improving docs processes​

Usually, my goal isn't to just hand you a finished set of docs; it's to help your team take ownership of documentation. This relies on your workflows and your team's culture.

Docs workflows​

I can help you set up authoring and review workflows that catch problems early, and set up the right tooling to reduce docs friction.

Docs work succeeds when your developers aren't afraid to jump in and get involved, so I prioritise tools and workflows that complement your existing processes.

Tooling I work with:

  • Source control (Git, Mercurial)
  • Static site generators (MkDocs, Docusaurus, Hugo, Jekyll)
  • Docs authoring tools (MadCap Flare, GitBook)

I'm happy working directly in your repo or your in-house tools, and if you don't have a docs pipeline yet, I can help you pick one.

Docs culture​

I can help you build the kind of team culture where documentation gets the same care as the code. In my experience, what prevents development teams from taking docs ownership isn't lack of interest, but lack of confidence.

I've spent years teaching technical communication at all levels, from junior writers finding their feet, to senior developers who want to be better at communicating complex technical information with their users and each other. I can provide one-to-one mentoring, bespoke style guides and cheatsheets, presentations, and ongoing writing support if needed.

UX writing​

Docs and UX are the same problem seen from two sides: how easily can someone understand a concept or a workflow? Docs aim to quickly get a user from question to answer; UX writing aims to quickly get them from idea to execution.

I've trained in UX writing with Andy Welfle and Michael J. Metts, authors of Writing Is Designing, and I bring that together with my documentation background to help with:

  • User journeys
  • Tooltips and UI labels
  • Error messages

Most usefully, I act as a first tester for user journeys and workflows. If something is hard to document, it's usually hard to use; I can spot the sticking points, and help you work out whether it's a docs problem or a design problem.

Before all this, I worked as an agency copywriter and spent years in customer-facing roles like retail, hospitality, and support. I don't do that work day-to-day now, but it means I understand the people your product actually has to serve: not just your end users, but your support agents, your salespeople, and your newest hires.