Acer Swift SFSP14-I5T Service Guide

Overview

As a Technical Writer for PTSGI, I wrote a service guide for the Acer Swift SFSP14-I5T laptop that supported service technicians at scale. I used FrameMaker to draft the guide, Adobe Bridge to manage illustrations, CoPilot to validate completeness, and Microsoft Excel to clean up raw data for quicker processing.

Service guides are not available on Acer's website. As such, please find the lifecycle extension guide—a guide to help buyers of a specific laptop perform limited servicing procedures—for the Swift SFSP14-I5T below.

Process

The completion of most chapters of the service guide hinged on the illustrations provided by my graphic design colleagues, as well as technical specification data provided by Acer contractors for whom I produced service guides. This process could prove time-consuming, so I first gathered data for the chapters that lacked illustrations and for which the contractors often first provided information.

As illustrations and data arrived, I turned to Service and Maintenance (chapter 3) to write SOPs for the disassembly and installation of various hardware components. In addition to being the most time-consuming of the chapters to write, Service and Maintenance also boasted a longer approval chain. Drafting this chapter early on ensured I could allot ample time for my colleagues to provide feedback on my work.

I started by placing the images for each SOP on the chapter and confirming all the images were in the correct order by previewing them with Adobe Bridge. To double-check all the images were present, I used FrameMaker's built-in list generation feature to generate a list of all the linked images. I then used Windows Command Prompt to list all the file names of the images for the chapter and prompted CoPilot to compare the FrameMaker list with the Command Prompt list. If any images were in one list and not the other, I would go back to FrameMaker and relink them as needed.

Among the images for Service and Maintenance were small photographs of various screws securing components in place. Each screw image needed to placed in a table at the end of various SOPs, but they also needed to be a realistic size relative to one another. I placed all the screw images in a separate table in Field Replaceable Units (chapter 6) before doing so for Service and Maintenance. That way, I could see all the screw images next to each other, making it easier to scale them properly.

As I wrote instructions for the disassembly of different components, I checked my writing against the corresponding images. I made sure my writing captured the nuances of each annotation drawn onto a photograph. For instance, an image might be annotated with multiple different arrows and pairs of different colored lines, each of which would require its own sentence to explain.

Over the course of my writing many different service guides, I learned to recognize patterns in annotations (e.g. screws are typically circled in red, with purple and pink used as secondary colors) as well as in the writing style of prior documentation. I took meticulous notes on these conventions to ensure my documentation was greenlit promptly, instead of being flagged for deviations from style guidelines that were not explicitly noted (say, in a style guide).

After all the SOPs were drafted and validated, I generated a PDF of the Service and Maintenance chapter to view alongside the FrameMaker file. In one window, I scrolled up through the installation SOPs. In the other, I scrolled down through the removal SOPs.

• Parallel structure: Removal SOPs are the opposite of installation SOPs, so I chose words that mirrored each other (e.g. "disconnect" for a removal step versus "connect" for an installation step).

• Completeness: Notes and warnings in a removal SOP for one component have to be mirrored in the corresponding installation SOP.

Challenges

My company has been contracted by Quanta Computer Inc., which was in turn contracted by Acer, to service guides and other technical documentation. This supply chain made it difficult to understand the needs of service technicians, since neither we nor our our client contacts liaised with them directly. To address this challenge, I browsed product forums on Acer's website for the Swift SFSP14-I5T. Buyers of the laptop sometimes discussed issues with updating their firmware and understanding specific BIOS functions.

This led me to consider how I might structure the BIOS option descriptions in System Utilities (chapter 2) to aid user comprehension. Namely, I would write a one- to two-sentence summary of what a BIOS option changes before including any other information. It's worth noting that I had limited ability to change BIOS descriptions beyond correcting grammar and spelling since they were pre-approved and since team leadership de-prioritized System Utilities relative to other chapters of service guides and lifecycle extension guides.

I proposed rewrites of BIOS option descriptions and system utility SOPs when a client offered more substantial language their teams had already approved of. These rewrites focused on using standard American English syntax for readability and to better serve international English speakers. To efficiently correct grammar within time limits, I used Ctrl + F to replace phrases and prepositions en masse. For instance, I replaced "same with" with "same as," a more idiomatic prepositional phrase.

Conclusion

The Acer Swift SFSP14-I5T service guide exemplifies a user-centric approach to technical documentation. Even with constraints on time and which information could be gainfully changed to enhance readability, I championed clarity and consistency in descriptions of BIOS options. I leveraged Adobe and AI tools to ensure completeness in servicing SOPs as well.

If I had more time and visibility into the user base, I would gather insights from real service technicians through a survey released in the months after the guide's publication. I would apply these insights to improve future service guides for Acer.