By Sam Dragga, Editor
The articles in this issue of the journal tackle important subjects of the field, but each also has a history that is important and instructive, indicative of the journey of ideas to the published page.
Ideas for research projects come from lots of directions and sources and evolve through a unique mix of education and experience, extensive reading, creativity, persistent analysis, conversations with colleagues, meticulous attention to annoying details, and the right inspiration at the right time. As I speak to prospective authors about their projects or discuss with authors the manuscripts accepted for publication, I am always interested in the origin stories of their manuscripts.
The four articles in this issue of the journal are four impressive journeys.
Tina Kister’s “Improving the Information Development Process: A Refined Iterative Development Model” is a comprehensive review that generates important new thinking. Writing as a project manager, Tina examines scores of development models across a wide array of industries and identifies defining characteristics and stages. The findings of this systematic analysis are the foundation on which she composes a flexible but rigorous process that integrates iterative efforts of progressive elaboration, feedback, and validation as well as specific stages directed to innovation, efficiency, and completion.
This article was originally a presentation that I caught at the 2015 STC Summit in Columbus. I was impressed with the wide scope, practical focus, and solid research basis of the project and encouraged Tina to consider adapting the presentation for publication in the journal. I later queried Tina about the perspective she brings to this project, and she was pleased to explain it:
My career path has been unconventional, because I’ve worked as a professional information developer for about 16 years but only entered a traditional corporate environment in 2011. In many ways, I was very naïve. As an entrepreneur, and having worked within smaller groups of people (20–30), I was always focused solely on the quality of the work (process and product).
I actually didn’t even know that “project management” was a thing. I had managed large and small projects with groups of people spread all across the country. I had been a small-business owner, managing schedules, clients, payroll, etc. Regardless of the setting, my focus had always been on the final outcome. For example, while I would break a large project into smaller segments, anticipate problems, and base the work on deadlines, I never thought of it as creating a “work-breakdown structure,” managing an “event chain,” or making a “backward pass.” I just did what needed to be done—what made sense.
On entering the corporate world for the first time, things didn’t make sense. We were delivering low-quality work in order to comply with bloated corporate policies and negotiate corporate politics. My colleagues were confused and demoralized. As a former business owner, it was excruciating to watch the company bleed money due to wasted resources, lost talent, poor processes, and downright dishonesty.
So, being a generally curious and proactive person, I decided to dive in and learn about communicating “best practices” in a language that my new colleagues could understand. As I continued to work in the corporate world, it became clear that the visual nature of development models provide an excellent starting point for discovering the more complex processes that lead to healthy development.
Tina also detailed the challenges of writing and revising for publication:
My biggest challenge in writing the article was finding a way to articulate ideas that seem obvious to me and to do so in ways that resonate with technical communicators. I think this is important, because that’s often what technical communicators must do to create quality information products—we have to work with experts who are so well-versed in a particular area that it’s difficult for them to identify and express the assumptions, shortcuts, and previous experiences that provide the foundation for their expertise.
It was (and is) very difficult for me to be aware of my own assumptions, shortcuts, and previous experiences, and to translate them into language that is meaningful. For example, because I have spent a lot of my life making furniture, building sheds, laying tile, and doing other hands-on work, I tend to make analogies between information-development processes and building things. At the STC Summit in 2015, I presented this same information and tried to create an analogy between the preparation phase in the model and creating a jig for a table saw so that you can quickly repeat standardized cuts. (I think it’s safe to say that the analogy was generally ineffective.) While I’m pretty good at getting other people to reveal what seems obvious to them, it’s a constant challenge to identify and articulate what seems obvious to me.
Brian Ballentine’s “Using Process Modeling Notation to Map the Buying and Selling of Complex Software Solutions: A Qualitative Study’s Implications for Practice and Pedagogy” examines a subject that is a point of disjunction for academic instruction and on-the-job practice. Using a rhetorical analysis of materials developed for a client, Brian considers the activity network diagrams widely taught in research methods courses versus the standard process modeling notation used in government and industry. As Brian explains, a client project initiated this journey of ideas:
The Vice President that I was working with more or less insisted that I explore process modeling notation. She was less than happy with my initial attempts at data and workflow visualizations, and she wondered why I wasn’t using technology that supported open standards. I hadn’t used process modeling in at least 10–15 years (when I worked in industry as a software engineer). The VP seemed almost alarmed that I didn’t default to using an open standard, so I took her feedback quite seriously.
He also noticed a glaring inattention in the field to this subject:
Process modeling gets minimal discussion in TC journals even though notable members of the field like Jackie Damrau have identified its rising importance. There has been more discussion lately (on TC listervs) about the rise of Business Analyst positions and their overlap with TC jobs. A basic understanding of process modeling notation is important, so practitioners can participate and/or compete for these jobs.
A key challenge for Brian was designing a representative but instructive illustration:
In an article discussing the importance of process modeling I had to offer at least one model, so readers had a basic understanding of what something like BPMN can do. I am by no means an expert, and it is likely that a business analyst would correct my ‘grammar’ in the visualization in order to make it more efficient. I chose to include the model that I did because I wanted to emphasize that with a limited time investment (and the use of free, open source tools), someone can get a draft of a model ready to show. It isn’t perfect, but a practitioner or academic could get started and/or contribute to a conversation in short order.
Like Tina Kister’s manuscript, Brian’s project also enjoyed early life as a conference presentation:
I gave an early presentation on working with Business Process Modeling Notation (BPMN) and the importance of working with open standards at the International Writing Research Across Borders conference in Paris in February of 2014 and an updated presentation on the data visualization at the 4th Annual Symposium on Communicating Complex Information run by Mike Albers at East Carolina University. Both presentations (and feedback from Kirk St.Amant as well as outside reviewers) helped me reshape the piece.
Two years and several revisions later, the idea emerging from a project for a client is the published article in this issue.
Baotong Gu and Meng Yu’s “East Meets West on Flat Design: The Convergence and Divergence in Chinese and American User Interface Design” investigates the shift from the previously ubiquitous skeumorphic (or mimetic) icons and images to the flat (or abstract) illustrations that dominate user interfaces across almost all devices at this time. Using examples from China and the United States for clarity and emphasis, Baotong and Meng consider the social, rhetorical, cultural and ideological influences on user interface design and find merit in the skeuormorphic, the flat, and the integration of the two. Their advice is to allow cultural sensitvity to guide the choice of design.
After accepting this manuscript for publication, I inquired about their source of inspiration. Baotong and Meng identified it as a recognition of the importance of their subject and a desire to assist the field in addressing it:
User interface design is one of the most important topics in technical communication, especially in this digital age where UX design is at the forefront of technical communication design. Of particular interest to technical communicators are cross-cultural aspects of interface design intended for a global audience. The convergence and divergence in user interface design approaches over the last few decades warrants a close examination of what cultural factors are at play in the shifting trends. But one of the greatest challenges in writing this article was translating our theoretical conclusions about user interface design into operationalized guidance for practitioners. We do take satisfaction in arriving at some practical advice that we hope will be helpful to our field.
I also asked about their choice of illustrations—key evidence for their claims—and appreciated their candid answer:
There are obviously millions of user interface design examples available out there. Selecting samples representative of both the American and Chinese cultures wasn’t an easy task. We did agonize over selecting the most illustrative and representative samples without being prejudiced for or against any of them. We started with hundreds of possible sample designs and decided on the ones we used after much deliberation and careful assessment. We’re glad with what we used and hope they illustrate well what we theorized about user interface design in different cultural contexts.
Claire Lauer and Eva Brumberger’s “Technical Communication as User Experience in a Broadening Industry Landscape” builds on their article in the November 2015 issue of the journal (“The Evolution of Technical Communication: An Analysis of Industry Job Postings”). This new article focuses on 502 industry job postings for user experience specialists, identifies the necessary skills and abilities of appropriate candidates, determines that technical communicators are especially equipped for this growing field, and addresses the challenges for individuals and academic programs in making the transition.
This was a project inspired by their earlier project but also by their awareness of the rising activity and influence of UX. As Claire and Eva explain,
We got interested in the subject for two reasons. One being that when we conducted our initial study of technical communication jobs, many of the jobs that came up were UX jobs, and these jobs shared a great many qualities with the jobs for which we were already preparing technical communication graduates. But even before that, we had been interested in the continued expansion of tech comm and the inclusion of UX as a viable area of expansion within the field.
We appreciated that UX was centrally about attending to audience, which is a strength that is also absolutely central to the work of technical communicators. Additionally, we have also focused our research agendas on issues of visual communication, visual literacy, and multimodal composing. Visual, Web, and multimodal texts are where UX work is most visible, so it was naturally an area to which we were attracted. In this way, UX is a synthesis of all the best parts of being a technical communicator: audience, research, design, content.
Claire and Eva also note that the project offered challenges that were mitigated by collaboration:
The greatest challenge in writing the article was by far the time it took to code the hundreds of job ads. Because of the versatility of language (i.e., the ability to describe one competency or characteristic in many different ways using many different terms and phrases), we had to closely comb through each job ad and code it for the dozens of competencies and characteristics we were looking for. The research and writing of the article went fairly quickly compared to the collecting, coding, analysis, and visualizing of the data.
We didn’t exactly know what we were going to find when we started, so we had to remain flexible and ready to expand, yet not expand so far out as to make the data collection unmanageable. But we greatly benefitted by working as a pair because we were able to brainstorm ideas thoroughly, vet approaches and methods, and more broadly determine the paths we would take. We also benefitted working as a pair by being able to embed interrater-reliability in our coding and analysis.
The origin stories of the four articles here give voice to the human beings who have navigated the rapids of research and writing to bring their ideas to this journal.
I am proud, and STC subscribers ought to be proud of the human-centered submission process this journal uses to greet the authors who bring us their ideas: authors attach their files to a simple email message addressed to firstname.lastname@example.org, and I answer. I believe that authors submitting manuscripts—manuscripts that might be years in the making, manuscripts in which professional identities are invested, to which irreplaceable time and effort are committed—deserve to pass their manuscripts to a living human being who replies with a sincere message of appreciation.
We also ought to be proud of the 30–day review cycle that this journal offers: Authors submitting their manuscripts deserve a timely review. I ask reviewers for comments in 30 days and, though the deadline slips from time to time, reviewers are typically on time and nevertheless generous with their perceptive advice. In the age of digital manuscripts and email, review periods of 60, 90, 120 days are unnecessary and inappropriate for this field.
As technical communicators assure that technology is designed for the human beings using it, I believe this journal must also make sure that it is designed for its contributors as well as its subscribers and that the humanity of writers and readers is always conspicuous in the journey of ideas.