Blog · Aliso Digital
Practical thinking on digital transformation, process, documentation and the people side of change.
No articles found. Try another word or topic.
There’s a moment in most documentation jobs where an engineer explains something clearly, completely, in a way that makes total sense. You take notes, you thank them, you go to write it up. Then halfway through the third step you stop. What happens if the user doesn’t have that permission?
Let’s get the objection out of the way first. Yes, AI helped produce this article. I’ve been a technical writer on and off for nearly 20 years. Government, healthcare, finance, aviation, telecommunications. I use these tools daily. I use them deliberately, without guilt. The argument against doing so doesn’t hold
Every technical writing job has a set of tasks that sit between you, the actual writing. Building an outline. Working out what’s missing from a documentation set. Putting together an example so a concept lands. Editing the same document for the fifth time. None of that is the hard part
There’s a lot of noise about AI in documentation work. Some of it oversells what the tools do, some of it dismisses them entirely. The reality sits in the middle, which is less interesting to write about, though more useful. After a couple of years using these tools daily across
The prediction was that AI would make technical writers unnecessary. A few years in, that hasn’t happened. What has happened is that the slow parts of the job got considerably faster. Research, note taking, first drafts, restructuring, and reformatting. All of that used to take hours. Now it takes minutes,
Most conversations about AI in technical writing focus on speed. How much faster a draft comes out, how many hours a week get saved. That’s measurable, so it gets the attention. The change I notice more is harder to put a number on. By the end of a long documentation
Most improvement projects start in the wrong place. Someone books a workshop, sticks butcher’s paper on the wall, and asks the room to design how things should work. Two hours later there’s a tidy flowchart, a few nodding heads, and a plan that quietly dies within a month. The problem
Process mapping workshops have a reputation for being long, tiring, then producing something nobody uses. Usually that’s not a notation problem. BPMN 2.0 is well designed, widely understood, precise enough for developers while still readable by the business. The problem is what happens in the room. Someone puts a blank
There’s a pattern I’ve seen on more than a few platform rollouts. The business analyst writes the requirements. The designer picks them up afterwards, then makes them look good. Development builds it, testing signs it off, the thing goes live. Six weeks later the support tickets start. Not because the
