In terms of the argument about why tech writers should be involved, I'd say it's to do with the skills we bring. We're good at explaining what software does to users - that's what we do. And we can use those skills to improve software's UX, by improving how the software explains itself to users.
If tech writers can get involved in early-stage design, we can make such a difference. It lets us identify areas that are complex/hard to explain, and fix them before they get any further.
@mikejang : I've found it easiest to get in on the process when I'm seen as the "words person". I review stuff people have written (anything, even emails). If they can see I've improved it, they're more likely to ask me for help in the future. Sometimes developers ask me about naming classes etc, because they think of the tech writer as the person who's good with words. But it also means, when they're writing an error message, they'll ask me to review it.
I think the same can work with designers - if you can show the difference you can make, hopefully they'll be happier to let you in on their process. Asking to attend user research can be really effective, especially if you can make good suggestions based on the user feedback.
For reference, my team's current process is roughly like this:
- Designer creates mockups for a feature based on discussions with product owner and team
- Designer posts mockups on our board
- Team puts up their comments on post-its (and I'll do a string review and scribble suggestions on)
- Designer iterates on mockups, and we review all the text together
- User testing
The idea is that, when the mockups are ready to be user tested, they've already been through a tech comms review. It means we can get much more useful feedback, rather than just watching users struggle with things we already know are badly explained or hard to understand.