Tech Writing Tradition is Gone
Many months ago, prior to this year's annual STC conference, I had been privately expressing my displeasure with STC. For many personal reasons, I was not getting value from the organization. I've been a member for 14 years or so, previous membership manager, web master, and volunteer. During my time as membership manager for the Chicago chapter, I noticed a decline in renewals and overall difficulty in maintaining willing, happy volunteers. This was 1998 through 2001. Chicago went from well over a thousand members down to just over 800 and then fluctuated from there. Out of all of those dues-paying members an average of 40 would appear at the monthly meetings.
This was not isolated to Chicago. I was hearing from other chapters that meeting attendance and membership retention were top issues of theirs. I would first argue that our current economic situation was not where STC began to experience a disconnect with members. I also noticed that certain topics were recycled at every conference and STC participation in the most cutting edge Web technologies was minimal.
Maybe I was crazy, but I thought, why wouldn't tech writers be the ones driving new user interaction technologies? But for the most part, they weren't. The topics tech writers gravitated toward were software tool demonstrations and how to build website seminars. I saw Jared Spool speak at the 1998 conference in Anaheim, but it was to a relatively small room and the after session hallway conversation questioned his wisdom. I was hooked on user experience, but others were obviously not as they complained they should have attended another session.
I moved to D/FW in 2003 and have only been to a couple of local STC meetings. I haven't been able to get my enthusiasm for the organization peaked enough to drive 40 miles to a monthly meeting. It was until recently I figured out why. I was renewing membership simply because I had been a member since college. I have been paying dues from a place of sentiment.
After a long personal illness (which I will discuss in a future article), I emerged onto a scene in Twitter filled with UX (broad use of the term) professionals. I realized what they were doing was what I had been doing myself as a tech writer, but didn't realize it. Yes, I wrote user, hardware, and procedure manuals. Yes, I made online help. However, here are some examples of what I've been doing since I took my first job:
- Project management
- Requirements collection and writring
- Project documentation
- Software architecture design
- Software interface design
- Usability (without labs and even calling it that)
- User workflows and how they apply to the software they're using
- Presentations on product ROI based on user feedback
- Database design
- Wireframes and prototypes
- User training
I'm sure I missed some. I also know I'm not the only tech writer to take on these tasks because good tech writers are writers as a starting point and continually take on tech because it's fun and relevant to progressive tech-oriented organizations. So I figured out that a group of STC members have circled the wagons around certain expectations of what tech writing should be in their minds. Meanwhile, other people who make documents and end up in the interaction design world have moved on. They have no use for boundaries that no longer apply to today's world.
Today's world is all about the user experience. If you avoid user-based design, you need to board a time machine and go back to a time when AS/400 was da bomb. User experience is about a whole experience. Content must support the product consistently, no matter who wrote it. Do the terms of service match the actual product behavior? Does online help actually explain what the user is trying to do? Does online training actually track results? Do analytics provide a mechanism for change to any content? Does user feedback make its way to everyone involved in product design? Are developers, writers, project managers, testers, and system administrators all working together to produce a single, wonderful user experience?
STC represents two conflicting groups: academics and actual business world employees. These are complimentary roles for building theory but they are conflicting for actual execution. User-based design does not start in a classroom. User-based design is reverse engineering what users want to find an efficient way to provide an experience. Academics should study user ideas, feedback, and environments rather than coming up with processes that are centered around how document creation methods should be. Users don't care about SGML, XML, DITA, or anything else related to how content came to be. They like to tag their photos their way on Flickr or organize their Twitter streams their way. Users are showing the world right now what they like and don't like by their very actions. Our job is to figure out how to help the companies we work for give them what they want so they stay loyal to us and the business is viable.
See Also:
Lifelines to the STC by Tom Johnson
Does the STC Deserve to Survive? by David Farbey
How Would You Resolve the Financial Crisis in STC?
It's the STC Not the STW by Alan J. Porter
Update (06/21/2009)
This article is getting more attention than the one I did way back on Japanese swim suits. To answer a couple of questions already asked, I did not address the financial issues of STC as, in my opinion, they are secondary to the value dues-paying members receive from the organization. Many organizations have faced devastating financial hardships and survived. However, STC will not survive if the members who are left (including myself) do not receive real value for their dues and active participation.
For example, I attended the Big Design Conference in Dallas and I walked away with more value for $50 in one day that I have for the last three years in STC. My personal value was a collection of new, challenging ideas, a fist full of cards from people who work in comlimentary fields, and a real sense I could apply much of what I learned to my job.
SMU and UTD both contributed to the Big Design Conference, offsetting an otherwise enourmous cost for facilities. For all of STC's ties to academia, I've yet to attend a local STC event at an actual school. There is a lot to learn from other organizations and professions. It's time STC top acting as if it's the only place for technical communication.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=4ce7fdab-add5-42ba-923c-f2d0bc7cc205)
Lover, You Should've Come Over by Jeff Buckley
{ 5 trackbacks }
{ 6 comments… read them below or add one }
"Academics should study user ideas, feedback, and environments"
Yes, yes, and yes again; this nails it.
On the other hand, you can't reverse engineer something that doesn't yet exist; how do you design something *new*?
Milan:
Non-academics in the business world have a completely different standard. They are accountable to their bosses and in many cases the shareholders. By "reverse engineer" I mean to observe the marketplace and attempt to produce a user experience that will help maintain and/or generate revenue.
On the other hand, academics are held to different standards and work in a completely different environment with non-compatible standards. That's my point, exactly. While business people would do really well to read studies and learn from real research, it's not a requirement. Many times business decisions are based on gut feelings, the latest business book of platitudes, or someone else's assessment of ROI.
STC must separate the need to link those two environments together. Business research and academic research are different. Business implementation doesn't require proven experimentation, only funding. Businesses make bad decisions all of the time based on nothing more than leadership's intuition.
The academic world is about research and conceptual truths. It is about proving theories and paving the way for knowledge, not profits. Both should co-exist, but the two should not be confused.
If people in business and academia work to “non-compatible standards”, then it would appear that academic preparation is of little use for working in the business world. I think that people in a number of professions who find themselves working in the business would be rather surprised to learn that — accountants, engineers, lawyers, pharmacists, and nurses, to name a few.
No one is confusing the two, I believe; if you can point to such an instance I’d be interested to examine it. But separating them? You’d have to point me to at least one documented instance of the business world separating itself, with positive results, from the academic roots of its participants before I could begin to accept the possibility that this idea has merit.
Milan:
I think you and I are agreeing in a roundabout way. I believe the academic community is to achieve long-term knowledge for the sake of knowledge.
The business world is full of people with varying levels of education who are sometimes qualified and sometimes not for any given project. Methods and procedures in business do not follow consistent standards. Therefore experimentation is already not adequate enough for academic standards.
My point is you cannot treat the business world as an equal partner to academia. The two environments operate toward two completely different goals.
Well said. I share your experience as a tech writer and your perspective that users needs come first.
FWIW, I blog here, venting my frustration: http://blog.appswhisperer.com/2009/06/stc-kerfufle.html
I am glad you liked the Big Design Conference. We are planning the 2010 conference right now. We are expanding it to two days–same tracks, though. We are included workshops, as we had requests.
With respect to your posts here….out biggest expense was the venue. SMU did give us a minor discount, not as much as you assume. UTD was great–they gave a cash donation and volunteers.
I do think each group needs to expand beyond their different visions. I am going to be working with the STC-Lone Star Chapter president for next Big Design 2010 Conference. Hopefully, we can buld off of synergies.
Thanks,
Brian