| title | permalink | categories | keywords | rebrandly | description | |
|---|---|---|---|---|---|---|
10 characteristics of ambiguous content |
/blog/what-is-ambiguous-content |
|
As a senior technical writer, part of my job description is to focus on tackling "ambiguous" content, as opposed to more straightforward content that is more commonly assigned to non-senior technical writers. At first, I wasn't entirely sure what "ambiguous content" meant (that fuzziness is part of its definition), but this has come into focus more over the past few months. Here I'd like to describe what ambiguous content means, as it helps identify content that has characteristics I've encountered for years. |
- TOC {:toc}
Ambiguous content has one or more of the following characteristics:
- The content lacks a clear owner.
- The content (and product) crosses teams, with multiple co-owners/contributors and contact points.
- The content doesn't map to an upcoming release. The content might be essential (like a product overview or a getting started tutorial), but without the deadline of an upcoming release, it's easy to neglect.
- The content lacks sufficient information and resources as a starting point. You need more information, but the info doesn't exist anywhere and the most relevant team for the info has disbanded, moved on, renounced stewardship, or is not forthcoming in detail and prioritization.
- The strategy for the content is unclear and needs to be defined. For example, the deliverable for the content might be unclear, as well as the length. Some of the sections might not be on target with user needs or use cases, but it's also unclear whether it aligns.
- The people who need to approve the content might be senior level, hard to track down, and have impossibly busy schedules. When you do track them down, you find they have a lot of strong thoughts on nearly every detail.
- The content is extremely difficult to test on your own without a lot of setup, hardware, tooling, access, or engineering know-how. This leaves you reliant on the engineer's word for the content's accuracy.
- The content has multiple challenging requirements around publishing, such as gated access, PDF output, content re-use, localization, personalization with variables, or conditional content. The system you're using for authoring/publishing might pose challenges for some of these features.
- Little is known about the users, their needs, their friction points, etc.; also, contacting the users is restricted. This leaves you somewhat in the dark in trying to write to the user.
- The content builds on another content set, but adding or modifying the tasks in various ways; as such, the content itself lacks the full story and appears as piecemeal, standalone articles that assume knowledge is defined elsewhere.
- The content consists of building blocks without a sense of what they are intended to be used for. You have to derive back the reason and purpose for the building blocks, and how the blocks might fit together.
Ambiguous content usually checks off several of these boxes. If the content checks three or more, it can be really difficult to complete. If you look at tickets in your backlog, look to see if some of the stalled tickets (which no one ever seems to get to) involve ambiguous content.
{% include ads.html %}
Once you've identified ambiguous content, consider assigning these doc tickets to more senior writers. For example, if your team consists of junior technical writers, technical writers, and senior technical writers, consider using this identification of ambiguous content as you divide up tasks. Give the junior technical writers tasks that are more straightforward, with clear owners and information resources, as well as timelines and deliverable expectations.