Category: Language

Categories
Documentation Language Writing

A Deep Dive into Technical Writing

As a writer – albeit these past 30 some years of technical topics – I believe words actually do have meaning and should be used carefully and correctly. So when I read recently in a LinkedIn post that a product manager had a “deep understanding” of his industry; or a post from my neighborhood email blast that a neighbor was looking to have someone do a “deep clean” of her house; or finally, that a webinar promised a “deep dive” into a topic; I knew something was amiss.

What’s up with all of these deep activities?

Why suddenly is an understanding of an industry insufficient that it now requires the adjective deep to make it somehow better? How does a cleaning of a house become more thorough by making it a deep cleaning? And a deep dive? Unless you’re discussing a scuba dive, what are you talking about?

The obvious answer, of course, is that corporate speak is to blame. People seem to need to misuse words to somehow make their lives more meaningful. Or something like that.

In technical writing, on the other hand, there is no “deep dive”. Or to put it another way, if you don’t know – don’t have a true understanding – of the technology you’re writing about, you’re wasting your time and, more importantly, the time of the poor person reading your useless work.

Because all good technical writing is a “deep dive”. To do less than that is not technical writing, it’s wordsmithing. And that is the biggest insult you can possibly hurl at a technical writer.

Categories
Business Computer Languages Language Marketing Process Training Writing

What Makes a Great Technical Writer

By Rachel Shoap

In a world full of individuals with such diverse skill-sets, interests, and passions, there are few who possess the expertise and chutzpa needed to be successful technical writers. The following list represents what I (a relative outsider to the field) think you need to possess to be a great technical writer:

  • Technical Aptitude: You know the old saying: “You can’t explain what you don’t understand”? Never was this truer than in the field of technical writing. If you don’t understand what you’re writing about, I guarantee no one else will either. You don’t have to be a software developer to describe how to use an app (in fact, that would probably be an impediment because you already know how it works). But you do have to understand how to use it to be able to describe the steps for someone to follow for that person to be able to use it. After all, the goal here is to communicate your knowledge.

  • Common Sense: Overthinking can be detrimental to one’s success, so it’s best to use the KISS (Keep It Simple Stupid) mindset, an acronym that I, as a salesperson, have taken to heart and that is now ingrained in my DNA. By using basic tech knowledge, and incorporating it into your writing process, you can become an asset to any company you work for.


  • Effective Communication Skills: How many times have you talked to a friend about something important, and she repeats what you said just to prove to you that she was listening, but can’t go into detail about what the conversation was about? I cannot stress enough the importance of communication in the technical writing industry. It starts with listening. Being able to listen to your clients’ needs and showing them that not only are you paying attention, but understanding and implementing those needs into the finished product (the deliverable) will build trust, surely fostering a long-term working relationship that will most likely result in repeat business.

  • Organization: The great Mark Twain once said, “The secret of getting ahead is getting started.” You can’t get ahead if you don’t even know where to start. Usually this inability to begin is a consequence of disorganization. Organization does not just mean making sure everything is in its rightful place, but mental organization and process organization: know what you want to say and have a roadmap on how to get there. Having a set organized process permits a technical writer to produce consistent results. There are always exceptions (client requests), but if you stray too far off the beaten path, then you’ll struggle to meet deadlines, which will lower customer confidence, and ultimately diminish your own confidence as a writer.

  • Declutter Your Mind: Clearing your mind allows you to become sharper and more focused. If you can’t get in the right mindset for work, your day will be full of procrastination and justifications as to why, for example, you’re taking a two-hour break when you just started working. People who can organize their thoughts and execute tasks promptly and swiftly can take on bigger projects with ease.

  • Empathy: As technical and methodical (and, let’s face it, sometimes boring) as technical writing can get, you may think that everything is written in black and white. But the ability to not only reach different audiences, incorporate those different backgrounds into your work and be understanding to the fact that not everyone can follow directions the same way – AND take that into consideration in your work – is a talent that is hard to come by.  Knowing your audience and knowing its needs can greatly increase your success when completing a project. Many companies struggle to get their intended message to customers, which ultimately leads to complaints and frustration on both sides.

If you are someone interested in starting in a new profession, or you are a client (potential or current) hoping to gain some insight and clarity as to what you should look for in a writer, then take these points into consideration. When you’re the spawn of a successful technical writer, whose business has flourished for over 30 years, you start to notice things.  Happy hunting!

Categories
Language Training Writing

Creativity in Technical Writing

By Rachel Shoap

To many people, just hearing the words “technical writing” evokes feelings of fear but mostly boredom. “What kind of person can tediously and meticulously write all day long while simultaneously lacking even an inkling of creativity and originality? I could never.” So said my technically (untrained) mind. Whenever I wrote in high school or college, my papers were riddled with profound metaphors and dialogue that formulated beautiful stories and character development that I was proud of. How could anyone choose to write technical manuals? They’re so bland! How could they knowingly choose a topic and style of writing that prohibits that creative flare that most of humanity longs for?

What exactly do technical writers do? For the most part, they put together information, precisely explain the significance of it, take the reader through the necessary steps to complete a task, and disseminate it to the masses in a way the masses can understand. This got me thinking. In its own right, technical writing has to be relatable and at the same time diverse. A technical writer has to strategically relay information while considering the mindset of the consumers of that information, as well as their ability to follow directions.

My ability to understand and dissect information presented to me may be completely different than Barbara’s, the 72-year-old grandma whose grandkids bought her a new cellphone for Christmas. Technical writers are tasked with making sure the information that they provide to consumers is relatable while making sure it is accurate and easy to follow.

Making something “easy to understand” truly takes inventiveness to another level. The ability to take this most technical information and make it understandable for people from different backgrounds, educational levels, and ages calls for the most creative of writers, even if writers that meet the social standard of creativeness do not think so.

Categories
Business Computer Languages Language Process Tools Uncategorized Writing

Technical Writing for the Cloud

Technical Writing for the Cloud

By: Eric Sedor
Eric Sedor, a frequent contributor to the Shoap Technical Reader, is a senior software engineer at MongoLab, a cloud-based database provider located in San Francisco. Eric cut his technical writing teeth at Shoap Technical Services before returning to his true passion, software engineering.

The Cloud encapsulates the idea of a distributed system built of formable, destructible, re-creatable components. Even the data within cloud systems is redundant and spread out, capable of being restored in parts to specific points in time, if necessary. Cloud systems even overlap one another.

Continue reading “Technical Writing for the Cloud”
Categories
Computer Languages Language Marketing Process ROI Training Uncategorized Writing

Documentation Needs vs Wants: What’s the Value Proposition?

Do a little research and the prevailing opinion expressed by those who write and those who want documentation is that it’s not done because (as I’ve written in a prior blog  — see http://www.shoap.com/why-bother-writing-technical-documentation/):

• It costs money.
• No one wants to do it.
• No one uses it.
While those facts remain true, the more important issue – what kind of documentation do companies actually need? – rarely gets addressed. Perhaps it’s time to talk about that issue.

Continue reading “Documentation Needs vs Wants: What’s the Value Proposition?”
Categories
Business Computer Languages Language Process Tools Training Uncategorized Useful Links Writing

Designing Effective API Documentation

The user interface of an application – even one with a convoluted design – gives users some sense about how to navigate the application. It may be painful, but users can usually muddle through if they have to. APIs, on the other hand, offer no natural affordances or signifiers allowing developers to learn how to use the API. Therefore, good documentation is crucial for any API project.

Continue reading “Designing Effective API Documentation”
Categories
Business Language Marketing Process Tools Training Uncategorized Writing

Documentation for the Brave New World

From touch screens of various sizes, to Microsoft Kinect™, Google Glass, Fitbit, and Square, we’re seeing a panoply of new devices that broaden both what technology can do and how we interact with it. This explosion of new interaction technologies has even created a bit of a hiring frenzy for interaction, user experience designers, and human computer interaction specialists whose job it is to design how exactly we are going to get all these new toys to do what they are supposed to. Dreaming up fantastic new ways to interact with all this fancy technology is one thing, but how do those dreams become applications, and how do people know how to use them once they get them?

Continue reading “Documentation for the Brave New World”
Categories
Blogroll Language Process Training Uncategorized Water Cooler Stuff Writing

Technically Speaking by Eric Sedor

Technically speaking, technical writing is writing, but all writing is not technical. Consult the textbooks and you’ll find much material describing the difference. Consider, however, the possibility that technical writing is not writing at all.  Compare, say, Moby Dick to your latest furniture assembly instructions:

Continue reading “Technically Speaking by Eric Sedor”
Categories
Blogroll Business Captivate Flare Humor? Language Process Rants ROI Tools Training Uncategorized Water Cooler Stuff Writing

Why User-Centered Design Matters

When was the last time you used an application that was just impossible to comprehend?

Shaun Article 1

 

 

 

<!–more–>

Shaun Article 2

 

 

 

 

 

 

 

 

 

 

 

 

 

Or that you visited a web page that made it hard to find what you were looking for?

Shaun Article 3

 

 

 

 

 

 

 

 

 

 

I’m guessing you don’t have to rack your brain too hard to come up with an example. In fact, if you’re reading this at work, you might very well have opened our newsletter just to take a break from the confusing enterprise software you’re stuck using for your job.

The Science Behind the Suck

During World War II, Army Air Force scientists noticed that changes in cockpit design often had disastrous effects on pilot performance. When the mental and physical capabilities of pilots did not align with the design of the aircraft, pilots were much more likely to make a mistake. Considering these “human factors” as part of the design turned out to be an important safety and performance issue. This insight led to a new science that linked human psychology to product design.

Fast forward to 1990s. Computer software starts to become mainstream. No longer the realm of the most technical users, human capabilities and product design started to clash again. Building on what the Human Factors researchers had learned, the science of usability engineering took off to meet the challenges of software design.

Some of the important human characteristics that must be considered include:

  • People have limited working memory capacities
  • Attention limits the ability of our minds to process only so many thoughts and inputs at once
  • Our eyes are drawn to salient features
  • We mentally group things in predictable ways
  • Our perceptions are colored by our experience and expectations

So how do you use this knowledge to make digital products that don’t give people fits? I’ll give you a hint: you’ll have to do a little more than add a line that “the application will be designed with usability in mind” to your requirements doc.

User-centered design is an approach to designing and developing software that results in applications and websites that are easier to use and better meet the needs of users.

What Is User-Centered Design

It starts by putting users at the forefront of design decision making. That’s what user-centered design is all about. Through research, observation, iterative design, and usability testing, we can understand the needs and behaviors of our users and use our expertise as designers to craft products which are useful, usable, and pleasurable to the users.

A typical user-centered design process would go something like this:

Shaun Article 4

 

 

 

 

  1. Analysis – Identify the characteristics of the users, user goals, context of use, and business goals. Talk to actual users and business stakeholders.
  2. Design – Create mockups or lo-fi, low cost prototypes of the solution based on the information gathered in the analysis phase.
  3. Testing – Test your mockups or prototypes with actual users to determine what works and what needs to be improved. Iterate on the design and testing phases to improve the process and move closer to …
  4. Development and Delivery – Building as you iterate through the test and design phase, you’ll approach higher fidelity until you’re ready to complete the development and delivery of your project.
  5. Evaluation and Lifecycle Management – Evaluate the success of the project against the characteristics defined in step 1 by measuring the behavior of actual users. Continue to ensure the product is updated using user-centered principles throughout the lifecycle.

Noticing a theme?

Why Is That So Important?

In the realm of ecommerce, the consultants User Interface Engineering used user testing to discover a usability flaw that was costing a major retailer $300M in lost revenue (http://www.uie.com/articles/three_hund_million_button/). When designing products, Jakob Nielsen estimates that spending 10% of a project’s budget on usability doubles the quality metrics for the project (http://www.nngroup.com/articles/usability-101-introduction-to-usability/).

When designing intranets and enterprise applications for internal use, your users may not have somewhere else to turn. In those cases, you don’t have to worry about losing customers. But poorly designed applications can cause all sorts of problems.

  • Employees are less efficient at their jobs when the tools they need are hard to use.
  • Confusing interfaces may cause employees to make costly errors.
  • Users blame themselves when they have trouble using an application, so having to spend the day using a suite of poorly designed applications leads to unhappy workers and lowered employee morale.

But We Don’t Have Designers! How Can I Get Me Some Of That User-Centered Design?

While you may not have designers, someone does design every application. It may be a business analyst or product manager doing mockups in Visio or it might be the developer turning user stories directly into front-end code. Inadvertent design is still design.

You don’t have to bring in an expensive agency or hire a team of User Experience Designers when you’re just starting out. The best way to improve the user experience of your products is simply to watch your users use your product.

User Interface Engineering has a list of excellent ways to start your user research (http://www.uie.com/articles/starting_user_research/).

Further Reading

If you’re interested in learning more, I suggest starting with the following books:

  • Don’t Make Me Think by Steve Krug – The classic introduction to designing websites and applications for usability. Quick and easy to read, it’s a must read for anybody involved in product work.
  • The Design of Everyday Things by Donald Norman – Norman is a pre-eminent cognitive psychologist and designer. Norman goes more in depth into the psychology of design than Krug, but this book is still quite accessible.
Categories
Blogroll Business Captivate Language Marketing Process Rants Uncategorized Useful Links Water Cooler Stuff Writing

Agile Development and Technical Writing

For additional information regarding Waterfall/Agile development and how it impacts technical writing, please refer to previous blog posts written by Eric Sedor and Shaun Kelly.

Moving a product out the door to capitalize on market demand is a necessity – it’s simple economics! Consumers demand constant product improvements. This “out with the old, in with the new” mentality has led many successful companies to switch from Waterfall development  to Agile. What does this mean exactly? For the uninitiated, use this simple analogy. Waterfall development can be compared to a marathon. All software features are built in one long process and then errors are fixed. Agile development is more like a series of sprints. Software is released in a series of small iterations. Each release includes a few added features, and errors are corrected along the way rather than at the end. As you can imagine, the switch to Agile development completely shatters the status quo and roles of people associated with the development teams. This led us to wonder: Specifically, how does the switch to Agile impact the role of technical writers?

Continue reading “Agile Development and Technical Writing”