Approaches that are either too general or too specific can easily overwhelm practitioners—and derail budgets. Fresh from recent experiences with two large-scale redesigns, Katie Kovalcin suggests that flexibility and open communication can transform all team members into what she calls “80/20 practitioners,” creating a more effective balance of time and resources.
I'm always puzzled by the misunderstanding, distrust, and sometimes downright animosity between academic and practitioner members of the technical communication family. At its extremes, this attitude manifests itself in practitioners who consider research and theory to be ivory tower games with no relevance to their practice, and in professors who regard practitioners as ignorant anti-intellectuals. The vast majority of us, of course, would never admit to being either academic snobs or practitioner rednecks, but many of us evidence less extreme vestiges of these biases.
SIGs exist to serve specialized needs within the greater organization. Special Interest Groups (SIGs) and Professional Interest Committees (PICs) are a tool by which the local chapters can serve a diverse range of special interests, boosting chapter membership. The Lone Star Chapter (Dallas/Fort Worth) began hosting SIG meetings three years ago. Currently, with four active SIGs, we are hosting an additional 100 to 200 members per month. This is how we built our SIGs to promote membership in STC. In the spring of 1990, a group of disgruntled contractors began to meet formally to discuss dissatisfaction with insurance plans for independents available through the society. We had been meeting informally for many years, to discuss the job market, rates available, and generally to gossip. We call it networking. personal contact or the sudden ice storm we had that night attendance was down significantly. From that point, we have kept a mailing list updated from our sign-in sheets, and sent postcard reminders about each meeting.
I manage a group of editors at a software company. This topic describes how we strive to achieve consistency in editing software documentation among a group of editors both within a department and across divisions in a large company. We have a staff of 14 editors that serve five large writing departments. Our editors are excellent grammarians before they come to SAS, but they also get considerable training and mentoring in SAS specific guidelines when they join our staff. I acknowledge that it’s impossible to achieve 100% consistency across all editors, but consistency is worth striving for for several reasons.
Stakeholders with business, design, and technology viewpoints can pull products in different design directions—sometimes without knowing how the design work fits into an overall strategy. This can leave stakeholders feeling lost and unhappy. Creating a focus around design goals and asking and answering the hard design questions as a team is an effective way of coalescing a team around one design direction. At the same time, it can create a more optimal and fun working environment.
Collaboration between designers and developers is always great topic to write about. I believe that for the first time that kind of collaboration is possible to full extent and it is possible today. Key element for enabling this is XAML – eXtensible Application Markup Language aka Holy Grail of designer – developer collaboration.
According to research in educational psychology, advance organizers lead to better learning and recall of information. In this research, the authors explored advance organizers from a business perspective, where larger documents are read under time pressure. Graphic and verbal advance organizers were manipulated into six versions of an advisory report, read by 159 experienced professional readers in a between-subjects design. Their reading time was limited to encourage selective reading. The results show that graphic advance organizers facilitate selective reading, but they do not enhance recall. Verbal advance organizers introducing a problem enhance recall, and graphic advance organizers moderate the effects on both selective reading and recall.
The central mistake new managers make is egoism. On the surface, the change is all about you: you’ve been promoted, you have a new job title, you have a new office. Perhaps you’ve been waiting for this change for some time, while watching peers or friends get promotions, and now finally you feel you’ve received the respect you’ve earned.
One of the Agile Manifesto’s basic balance equations is valuing working software over comprehensive documentation. This line of the Agile manifesto can be confusing to some supporting roles in an Agile development enterprise. As technical support staff, trainers, and content creators, what are we doing to fit into this Agile methodology, and what’s working well? Let’s explore some old habits that need to die, and some new rituals to fill that space.
I have been a technical writer on Agile development teams, and working in tightly collaborative environments has taught me a lot about adding value in the customer’s perception. I still remember being challenged by Michael Cote when we were at BMC Software. He asked, “Why does it take three days to get a PDF out for review? Why aren’t technical writers using wikis for documentation?” Those questions prompted quite a bit of research that finally resulted in my book, Conversation and Community: The Social Web for Documentation.
There's an irony about agile development. There is no hard evidence that it produces better software, faster. And formal adoption rates, admittedly hard to measure, don't reach the 20 percent mark. Yet the ideas that underpin agile development--defining requirements incrementally, writing software in short stints, seeking customer feedback, testing code as it's written, frequent builds--have caught on like wildfire. They are widely accepted as sound development practices, even among teams that have not formally adopted them.
RITE differs from a “traditional” usability test by emphasizing extremely rapid changes and verification of the effectiveness of these changes. Specifically, practitioners make changes to the UI (prototype or application) as soon as the problem is found and the solution spotted. Changes such renaming buttons, changing the text of menu items often happen before another participant arrives. More complicated, but obvious changes are made as rapidly as possible. This way the change can be tested as quickly as possible.
When your organization lacks a compelling cause, you can at least take comfort in the idea that you’re pursuing your calling or vocation. Aligning with your calling is ideal, but this can be an issue for technical writers, because almost no one feels that technical writing is a calling.
A good manager is someone who makes everyone feel like he or she is creative in their work. Because creative work is the most fulfilling work, and we are each capable of that kind of work.
Every other team meeting, three team members get 30 minutes each to talk about projects they are working on, and they get to demonstrate some of the cool things they are integrating into the project. As a team, we look at the project and both learn from what they’ve done, and make suggestions on how they might improve the project.
This article calls for a rhetorical perspective on the relationship of gender, communication,and power in the workplace. In doing so, the author uses narrative in two ways.First, narratives gathered in an ethnographic study of an actual workplace, a plasticsmanufacturer, are used as a primary source of data, and second, the findings of this studyare presented by telling the story of two women in this workplace. Arguing that genderin the workplace, like all social identities, is locally constructed through the micro practicesof everyday life, the author questions some of the prevailing assumptions about genderat work and cautions professional communication teachers, researchers, and practitionersagainst unintentionally perpetuating global, decontextualized assumptionsabout gender and language, and their relationship to the distribution and exercise of power at work.
Usability and design are two fields that collide more often than not. But why is that? Why can’t we all just get along and center our efforts around delivering a better product, a top-notch Web site or a user-friendly interface. Everybody would benefit from an open-minded, reciprocal understanding. Right?
The authors (both coming from a heavyweight software development environment) describe their approach to transferring a heavyweight method into a more agile approach. One can argue whether the described result is intermediate or final, the the process described and the choices made are well worth studying.
I’m permanently interruptable because that’s my job. It took me quite a while to realise this, and getting yourself into a position to be interruptable isn’t all that easy. You need a good team around you (which I have) and you need to trust them and delegate to them as much as you can (I trust them, and I’m working on that delegation thing!).
I know some people see asking questions as a sign of weakness or insecurity (and believe others will view them that way), and that asking questions can produce answers we don’t want to hear. Both of those possible results pale in comparison to the potential good that just sitting down and asking questions can produce.