While scrolling through my LinkedIn feed last week, I came across an interesting post by @Carl Isaac where he proposed a unique approach when interviewing and hiring technical writers. He doesn’t ask for writing samples anymore. Instead he “asks them to explain a feature they hate using”. The logic behind this, in his own words is,

I’m not grading the polish. I’m watching for the moment they get suspicious of the feature before they try to be helpful about it. The weak candidates start writing immediately. The strong ones stop and ask “wait, why does it work this way” before they explain anything.

What Carl Isaac is really testing for is a writer’s relationship with friction, the willingness to stop, and interrogate a feature before smoothing it over. That instinct doesn’t just matter in interviews. It’s the core of what makes technical documentation honest.

Why am I talking about this?

I’ve been a Technical Writer for the better part of twenty years, across industries ranging from engineering and government to software and finance, all of it in Australia. And after two decades I still marvel at the job. Not just because you learn something new nearly every day, but because you end up in this oddly privileged position: you see a product, a process, a feature holistically, from the outside in, often before a single customer does. You catch the inconsistencies. You feel the friction first.

It is a fantastic profession. It’s also a persistently invisible one. Australia’s tech workforce is forecast to need 1.3 million workers by 2030, yet technical writing rarely features in these projections by name. The role gets folded into “content”, or absorbed into engineering headcount, or simply forgotten in workforce planning entirely. The Write the Docs Australia community has grown year on year since its first conference, which says something about demand from practitioners, but industry recognition still lags well behind the work itself.

Which is partly why I’m writing this post. If we’re going to argue that a writer’s friction is data worth acting on, it helps to start from a place of confidence in what the profession actually does, and what it catches that not a lot of other folks are positioned to catch.

Aren’t we all fake users?

There’s a particular kind of quiet dread that comes with opening a ticket for a feature you personally think is a bit of a misnomer. Or worse, one you literally cannot use, because you don’t have the appropriate license tier, the hardware, or the physical ability to click through it the way your reader will.

Most advice about empathy in technical writing assumes you can get close to the user’s experience if you just try hard enough. Use the product. Feel their pain. Write from the inside. That sorta thing. It is good advice, most of the time. But it quietly assumes something that isn’t always true: that you *can* be the user, even for a moment. Sometimes you can’t. But the docs still have to work.

Writing elaborate steps for a workflow that you personally find clunky, without letting your own frustration bleed into the tone is hard work.

I don’t feel I can write it if I haven’t used it

I’ve been writing technical documentation for all sorts of things (primarily software, though also processes and procedures that are not always on a computer), but I’ve never been in a position to use most of these things myself. One of my earliest contracts was writing policy documentation for Australia Post, where I worked with an excellent Subject Matter Expert (SME) on documenting terms such as suburb, locality, region, LGA, postcode etc. While it gave me an excellent understanding on what these terms mean, I have rarely had to use this information in daily life, except in casual conversations.

A Technical Writer I was talking to recently spoke about how much she learned while documenting procedures around steel fabrication very early in her career. There is no doubt she also did an excellent job translating that highly technical knowledge into something that would help their customers worldwide, though I suspect she never had anything to do with that very subject she was documenting for a better part of her career.

As Technical Writers, this is nothing new. It is second nature for us to write about something that we may indeed never use in our lifetime.

Most technical writers I know share a version of this very same instinct. One writer profiled by Codecademy put it plainly: he doesn’t feel he can write with credibility about something unless he’s used it himself. That’s a healthy instinct and it’s the whole reason “docs as code” and hands-on testing exist as practices. But it leaves a gap for the situations where hands-on simply isn’t on offer: an enterprise module you’ll never be provisioned for, hardware you’ll never be shipped, a persona built around a job you’ve never done.

Docs go stale fast, and the people who’d notice usually aren’t looking. One industry report estimated users spend around 40% of their time viewing out-of-date documentation, often without realising it, and the people making product decisions tend to badly overestimate the experience they’re actually shipping.

Named failure modes of “bad docs”: obsolete, unclear, disorganised, incomplete, and inconsistent, line up neatly with what happens when a writer can’t walk the flow themselves. Gaps go unnoticed. Wording stays abstract. Edge cases a real user would hit get missed entirely, because nobody hit them while writing.

So what do you actually do in that gap?

The dogfooding myth doesn’t help (as much as you’d think)

The comforting story here is “dogfooding”, the idea that everyone at the company uses their own product, so someone’s always got their hands dirty and can brief you properly. It has a warm appeal. It’s often not true. A former presales staffer at Appian wrote candidly about this: despite almost everyone in the industry claiming to eat their own dogfood, most creators of software don’t actually use what they build day to day.

Which means the writer being an outsider to the product isn’t as rare a position as it feels in the moment. Plenty of the people you’re interviewing for information are somewhat outsiders too, though they just don’t always say so explicitly.

There’s also a less comfortable worry worth naming: even genuine dogfooding has a blind spot. Developers who test their own features tend to unconsciously use workarounds a first-time user never would, quietly smoothing over the exact friction the documentation needs to flag. Access to a product doesn’t automatically produce a clear-eyed view of it; it merely changes what you’re blind to.

“Can’t use it” isn’t just a figure of speech

The sharpest version of this problem isn’t personal taste; it’s when a reader genuinely cannot use the product the way the writer can, or vice versa. Carolyn Stransky’s Write the Docs Prague talk on accessible documentation opened with an account from a blind developer describing his early experience learning to code: the tutorials were good, he said, but completely unreadable for him, as they were full of assumptions sighted documentarians hadn’t thought twice about.

That’s the honest end of the spectrum this post sits on. Sometimes the gap between writer and reader is a mild dislike of a clunky workflow. Sometimes it’s structural, and no amount of “just use the product more” closes it. Alexandra White’s talk Moving beyond empathy: a11y in documentation pushes on exactly this, arguing writers should stop parking at “accessibility matters” and get to the harder, more useful question of what to actually change in the work.

Over years, I’ve consciously tried to make sure we have given accessibility more than a thought in our docs, but I must admit I have often failed at getting this across with strong enough evidence. Thankfully, with AI tools, I can set up specific hooks within my authoring environment to test my docs against a base accessibility guideline.

The docs for what isn’t there

There’s a quieter version of “can’t use it” that’s less about the writer and more about the product itself: documenting the things that simply aren’t there yet, or never will be.

Tom Johnson, on his long-running I’d Rather Be Writing blog, put his finger on this years ago. He was trained to write documentation in a positive light, here’s what you can do, and look how well it works, but for every “can,” there’s a “can’t,” and it’s rarely obvious to a user which bucket they’ve landed in.

• Maybe the feature exists but is buried three menus deep.
• Maybe it’s coming next quarter.
• Maybe it’s just never going to happen.

He credits a colleague with a term for the practice of writing that down explicitly: Known Limitations. Not a bug tracker entry. A page, for users, admitting what the product doesn’t do.

It sounds like a small idea, but it cuts against a strong instinct in the profession that documentation is usually optimistic by default, structured entirely around “here’s how to succeed at this.” Walking the negative space on purpose is a different skill, and arguably a braver one.

Fast-moving teams routinely make last-minute product changes without looping the writer in, which quietly creates a documentation gap, not because the writer avoided the feature, but because nobody told them it existed, changed, or quietly dropped out of scope.

From the outside, an undocumented gap and a deliberately-skipped feature look identical. From the inside, they’re completely different problems with completely different fixes.

Either way, it’s the same friction as everything above, just wearing a different coat: an absence in the docs that the writer either doesn’t know about, or knows about and doesn’t feel entitled to name plainly.

Docs friction often is UX friction

Arguably, if you find it annoying to document, that’s a signal worth raising with the product team, not just swallowing. Use the dislike for the better. Instead of complaining and/or ranting, use this signal as data for improving not only the documentation, but also shaping the user experience.

I have often had to take back screenshots of what seems out of place when I try documenting, and have robust chats with the product team on how we can simplify where possible. I am in a fortunate place where my developers allow me to freely pursue the code repository, and take the lead on UI and UX suggestions, including button names, error messages, placement of UI elements, or just the general “flow” of things. More often than not, any PRs or tasks I raise about these are accepted without a lot of resistance.

Where that leaves us

If you can’t be the user, the honest move isn’t to fake the empathy, instead, it’s to be explicit about the gap and compensate for it deliberately: lean harder on real user testing, flag friction to the product team instead of just writing around it, and treat “I found this hard to document” as data worth reporting upward, not a professional failing to hide.

It’s also, not coincidentally, an argument for technical writers having a seat at the design/developer table rather than being handed a finished feature and told to describe it clearly. If the writer is often the first person forced to articulate the experience in full sentences, that’s exactly the moment friction becomes visible, and exactly the moment it’s cheapest to fix.

Next time you feel friction, here’s what you can do:

• Note down what feels off.
• File it or submit a PR or create a task against it.
• Raise it with your product team early.

Friction you feel as a writer, be it dislike, exclusion, awkwardness is data, not a disqualifier. It’s arguably a preview of what a first-time or struggling user will feel. Harness that friction to better your docs, and the overall user experience.