I attended the two-day STC New England Interchange conference at the UMass Lowell Inn and Conference Center. This year the event was in a larger and more comfortable venue than last year. It made a huge difference in my enjoyment of the event, as I imagine it did for others as well.
Jody Zolli from Akamai discussed “The Benefits of Working Embedded on Development Teams.” An Agile process helps writers to become embedded, and rather than an “us-vs-them” philosophy it becomes an “us” approach. Instead of being stuck in the waterfall approach, documenting functionality that developers may have already forgotten, the embedded writer is close to the action and part of design reviews and sprint planning. You are enveloped in a synergistic connection with the engineering team where you can make positive contributions to the user interface while the design is still fresh in everyone’s mind. Writers injected directly into the mix early in the development process often not only get problems addressed but see their documentation reviewed in parallel with development. Embedded writers can help with UI text and clarify technology. The embedded writer also becomes visible and valuable as a full contributor. The downsides to the process, such as the amount of meeting time, are largely offset by access to people and information.
Karen Giventer presented “The Job Search Sandwich” using a novel paper-only approach to present her points. Any job search can be frustrating, but people need to continue moving forward. Candidates should treat failure as learning on the way to something better. It’s up to the candidate to unearth opportunities, including cold calling, contacting people known to you, reactive job search, staffing agencies, and good old-fashioned networking. Securing the offer is another tough task that involves cover letters, resumes, phone screens, face-to-face interviews, and thank-you letters. Some of the keys to success are making your best effort, timeliness, follow-up, and honesty with yourself and others. Cover letters should quickly convince recipients that you’re qualified for the job; matching up your qualifications with the job description will also aid in this effort. Traditional Word resumes are still used by many, as well as social networks like LinkedIn. Even if you’re not actively looking for a new position, it helps to look at an old resume with a fresh eye and update old jobs or recast it to emphasize new skills. Make sure the formatting is consistent throughout. Recorded interviews are becoming more common, and it’s crucial to go in prepared after practicing with a friend and recording yourself in advance. First impressions are still really important. A professional demeanor, timeliness, and always putting forth your best effort are still important.
Rick Lippincott and tech support colleague Skip Pacheco presented “Frenemies: Tech Comm, Tech Support, and Working Together.” The tech writer’s job is like driving a bus with many stops along the way. A tech support person’s job is like driving a taxi, with a few customers who want solutions to both specific and common problems. Standard engineering groups are action-centered and have the latest information on products. Engineers know about products before development begins, and it’s important for them to remember who you are if you aren’t part of this organization. Some, however, have little or no customer contact, “real-world” experience, or insight into a product’s history. Support personnel are customer centered and have plenty of contact with customers. They have extensive product experience and knowledge of a product’s history. Good documentation in this area saves costs, and support engineers are often the best reviewers. However, they’re not always in the loop, which is why a writer tied into a development team can bring a lot of information to support. Support folks are often focused on the last release, not the current release. Docs written for tech support are often focused on troubleshooting and service, with extensive troubleshooting trees or flowcharts. Tech support is another customer, often dealing with end users who can’t be bothered to read the documentation or tried but failed to find a solution. Thus, joining tech support and tech comm means that tech support is now in the loop for upcoming changes, and tech comm can pick up a lot of valuable support information.
Char James-Tanny brought us a really interesting discussion on “Accessibility Matters: Making Your Products Available to Everyone.” There are disabilities beyond vision, hearing, and motor limitations; on average, people spend about 11% of their life disabled. Currently, 20% of the world population has a disability, and the disabled are becoming the largest minority group. Many disabilities are invisible, and we cannot know who may have a hidden disability. Accessibility is usability for almost everyone. Writers can improve accessibility: use good color contrast, headings, plain language, good link text, and alternate (alt) text for both screen readers and where users have turned off images. Fonts are important and should be set in pixels relative to a base font size. Avoid serif font families in web design. Flashing or flickering lights in videos can cause seizures. Mobile and regular websites have design differences, but should offer the same functionality, and one site should be built that meets all needs. Char offered many other tips, all designed to simplify interfaces and bring complete information to all users.
The final presentation of the day, from Steve Jong, was “Embedded Assistance: Third Rail or Third Way?” Steve talked about some of the challenges writers face, such as comments that nobody reads the documentation and now the help. Mobile devices have become the #1 web browser on the Internet, but they have little screen real estate, and mobile users aren’t inclined to seek online help even when it’s available. Already feeling marginalized by these developments, writers are ignored when they suggest interface changes. And writers have competition, from Google to YouTube to support forums and wikis. How can we make our contributions valuable? To start, the needs and problems of users still exist. Everyone reads the GUI, which is largely text and layout. Embedded assistance, textual and graphical elements that users encounter in HW and SW products, keeps users engaged in the current interface. Embedded assistance extends to UI labels, and clearly crosses into development territory. How can we get there? One way is by becoming ensconced on an Agile team. When you’re working in real time as part of the team, your suggestions are often welcomed. The vast majority of teams lack a UX expert, which allows, maybe even invites, us to assume the UX role. Learn about embedded assistance in all its forms, become Agile if you get the opportunity, and work with or even become UX if you can. This presentation gave me hope that new methods and ways to do our work exist and are there for the taking.
About the Author
Elizabeth Kliesiewicz is a Content Developer at ARRIS in Lowell, Massachusetts.