A workflow that only exists in someone’s head isn’t really a workflow — it’s a dependency. I start by understanding how work actually moves through a team or project, not how it’s supposed to move on paper. From there the goal is a process that’s clear enough to hand off, consistent enough to repeat, and simple enough that people will actually use it rather than work around it.
That usually means mapping the current state first — messy as it is — before redesigning anything. The output might be a visual process map, a written procedure, a checklist, or a combination, depending on what will actually get used. The format matters less than whether it solves the problem.