Don't Make Me Read: Tips for Writing Effective Documentation
At the Data Lab, we invest to ensure that our tools are valuable and functional for our community. Documentation is a key part of ensuring that our tools are easy to use.
Over the past year, we conducted several usability evaluations for two of our data pipelines: ScPCA-nf and ScPCA Downstream Analysis.
- ScPCA-nf is a Nextflow workflow (scpca-nf) that is used to process 10x single-cell data as part of the Single-cell Pediatric Cancer Atlas (ScPCA) portal. The workflow processes fastq files from single-cell and single-nuclei RNA-seq samples using alevin-fry to create gene-by-cell matrices as SingleCellExperiment objects.
- ScPCA Downstream Analysis hosts a set of Snakemake workflows designed to work on the data available on the ScPCA Portal or the output of the scpca-nf pipeline. Among its workflows, it contains a core workflow that performs initial pre-processing of gene expression data, as well as separate workflows for performing Clustering Analysis and Genes of Interest Analysis.
We learned several lessons on writing helpful documentation through observations and feedback from users.
Our usability studies have taught us that the technical and text-heavy nature of documentation often makes it challenging for users to effectively absorb what they are reading and use it. Our goal is to structure and format the dense content to make it easier for users to find information. The documentation for ScPCA-nf and ScPCA Downstream Analysis are written as a set of linked markdown files. This blog post will focus on techniques to structure and format dense walls of text for better readability, using the documentation for our data pipelines as examples.
Structuring Content
A well-structured documentation facilitates discovery, providing the right information at the right time. These are the questions users want to answer when they interact with documentation.
- What is this tool and is it for me?
- How can I use it?
- What are these configurations? How can I change them?
Layering Documentation
Layering documentation is a lot like painting. An artist starts out with big splashes of color, with rough and broad strokes. Next, they add lines giving shape and structure to various elements in the painting, and finally, they add the little details like texture, shading, and smoothing out the rough edges.
Similarly, for documentation to be effective, readers need to be eased into the technical details; otherwise they will leave confused and disoriented. Provide information starting with high-level descriptions, and then build upon their basic understanding to get into the finer details of the tool.
Let’s examine what that might look like using an example from our ScPCA-nf and ScPCA Downstream Analysis documentation.
Big Broad Strokes
The first layers should focus on answering questions about what the tool is and should provide just enough information so users can decide whether it is for them or not.
This includes:
- Introducing the tool - Tell the readers what it does, what outputs to expect, and any other basic context that would be helpful.
For example, ScPCA Downstream Analysis is designed to work with data from the ScPCA portal. This is helpful context to provide to both users who want to use the pipeline as is and to those who might want to modify it for their own purposes.
- Outlining the steps to install and run the tool - Give an idea of what it takes to use the tool and how much effort is needed.
Adding Structure
The next layer should focus on helping users set up and use the tool, providing a structured way to approach utilizing the tool.
This includes:
Hardware and software requirements to run the tool.
A how-to guide - At this level, we can add a little more detail about what is required at each step and link users to detailed instructions for each step. Depending on the tool, some of the steps can be:
- How to organize the files
- What types of input files to provide
- What configurations are required
This information is also helping users to answer the question “Is it for me?” and “How much effort will it take to use the tool?” In addition, this granularity of information is useful to returning power users who may need to refresh their memory but don’t want to wade through all of the instructions again.
The example below shows the Overview section of installation instructions for ScPCA-nf. The overview lays out all the steps required to successfully run the pipeline, providing links to more documentation at each step.
Take a look at the full overview section here!
The Fine Details
The final layer is where you get into the nitty gritty technical details of the tool.
This includes:
- Detailed instructions for setting up - details of input parameters, configuration files and their structure. In ScPCA-nf, we link each step of the overview to detailed instructions like information about each of the columns in the Metadata config file.
- Advanced options for customizing the tool and when to use them. In the ScPCA Downstream Analysis pipeline, we link users to Additional Workflow Parameters after we have walked them through setting up the basic parameters.
Power of a Good Example
Most users in our study mentioned how useful a working example is when working with a new tool. Provide example input data, configuration files, and output data so users have something tangible to fiddle with and get a better understanding of the tool.
There are several advantages to providing examples.
- You can refer to examples in your documentation to make your instructions/descriptions more effective.
- An example reduces the investment required from the user to try the tool and get a deeper understanding of what to expect.
- A working example instills user’s confidence in your tool.
In ScPCA-nf, we provide an example directory that contains
- Example configuration files: Users don’t need to create their own configuration files referencing the documentation. This reduces the frustrating errors they might encounter due to minute mistakes in setting up their own configuration files.
- Example input data and how to use it: Users can try to use the pipeline on their own without needing to bring their own data.
- Example output files: Users have something tangible to explore without investing too much time and effort.
Presenting Content
When it comes to writing effective documentation, how you say it matters just as much as what you say. Even a well-structured document can be hard to comprehend if the language and formatting are arduous.
Language
Keep it simple.
- Write the documentation in a simple language and only use as many domain-specific terms as needed.
- Passive voice makes it difficult to comprehend the sentences. Adopt an active voice and keep the sentences as short as possible.
- Use a causal tone, don’t hesitate to use second-person pronouns like “We” or “you”. It makes the docs feel friendly and welcoming.
Formatting
People don’t read, they scan.
People scan in an ‘F’ pattern on text-heavy websites, which means that they usually end up reading only the first few words of every line.
Formatting for Scanning:
- Use informative headings: Informative headings make it easier for readers to get the most out of scanning.
- Write smaller sentences and paragraphs. They are easier to comprehend.
- Break up paragraphs into bulleted lists wherever possible to make information easier to consume.
- Draw the user’s attention to important items like crucial steps, links to valuable information, and examples. For example, you can distinguish the important links with this markdown button hack.
- Use tables to describe long lists of parameters.
Effective language and formatting in action!
Let’s look at this before and after from one section of our ScPCA Downstream analysis documentation.
On the left, the before version does a few things well. It uses formatting, and the heading is informative. It uses a table to draw attention to the fields that are required to be changed, which is an important step. However, there is still room for improvement. The information is difficult to scan since there is a big chunk of dense text. The language is informational, but it isn’t explicitly clear what actions the reader is expected to take.
On the right, we have the improved version. The information is broken down into bullets where possible. The sentences are more concise, and it provides clear instructions as to what readers can do with the information. It is easier to scan.
Let’s face it…
Writing effective documentation is challenging. Users might not always read every word in the documentation. They might even just scroll past large chunks of text, but we can accommodate those behaviors.
Give these key tips a try when writing documentation for your tools!
- Structure your documentation to start with high-level information and ease into lower-level details.
- Provide sufficient examples.
- Use simple language and short sentences as much as possible.
- Leverage the ‘F pattern’ and use clever text formatting to guide the reader’s attention to important information.
Interested in reading about other ways we prioritize the needs of our users when designing Data Lab tools? Check out this blog post to learn more about our user research activities!
At the Data Lab, we invest to ensure that our tools are valuable and functional for our community. Documentation is a key part of ensuring that our tools are easy to use.
Over the past year, we conducted several usability evaluations for two of our data pipelines: ScPCA-nf and ScPCA Downstream Analysis.
- ScPCA-nf is a Nextflow workflow (scpca-nf) that is used to process 10x single-cell data as part of the Single-cell Pediatric Cancer Atlas (ScPCA) portal. The workflow processes fastq files from single-cell and single-nuclei RNA-seq samples using alevin-fry to create gene-by-cell matrices as SingleCellExperiment objects.
- ScPCA Downstream Analysis hosts a set of Snakemake workflows designed to work on the data available on the ScPCA Portal or the output of the scpca-nf pipeline. Among its workflows, it contains a core workflow that performs initial pre-processing of gene expression data, as well as separate workflows for performing Clustering Analysis and Genes of Interest Analysis.
We learned several lessons on writing helpful documentation through observations and feedback from users.
Our usability studies have taught us that the technical and text-heavy nature of documentation often makes it challenging for users to effectively absorb what they are reading and use it. Our goal is to structure and format the dense content to make it easier for users to find information. The documentation for ScPCA-nf and ScPCA Downstream Analysis are written as a set of linked markdown files. This blog post will focus on techniques to structure and format dense walls of text for better readability, using the documentation for our data pipelines as examples.
Structuring Content
A well-structured documentation facilitates discovery, providing the right information at the right time. These are the questions users want to answer when they interact with documentation.
- What is this tool and is it for me?
- How can I use it?
- What are these configurations? How can I change them?
Layering Documentation
Layering documentation is a lot like painting. An artist starts out with big splashes of color, with rough and broad strokes. Next, they add lines giving shape and structure to various elements in the painting, and finally, they add the little details like texture, shading, and smoothing out the rough edges.
Similarly, for documentation to be effective, readers need to be eased into the technical details; otherwise they will leave confused and disoriented. Provide information starting with high-level descriptions, and then build upon their basic understanding to get into the finer details of the tool.
Let’s examine what that might look like using an example from our ScPCA-nf and ScPCA Downstream Analysis documentation.
Big Broad Strokes
The first layers should focus on answering questions about what the tool is and should provide just enough information so users can decide whether it is for them or not.
This includes:
- Introducing the tool - Tell the readers what it does, what outputs to expect, and any other basic context that would be helpful.
For example, ScPCA Downstream Analysis is designed to work with data from the ScPCA portal. This is helpful context to provide to both users who want to use the pipeline as is and to those who might want to modify it for their own purposes.
- Outlining the steps to install and run the tool - Give an idea of what it takes to use the tool and how much effort is needed.
Adding Structure
The next layer should focus on helping users set up and use the tool, providing a structured way to approach utilizing the tool.
This includes:
Hardware and software requirements to run the tool.
A how-to guide - At this level, we can add a little more detail about what is required at each step and link users to detailed instructions for each step. Depending on the tool, some of the steps can be:
- How to organize the files
- What types of input files to provide
- What configurations are required
This information is also helping users to answer the question “Is it for me?” and “How much effort will it take to use the tool?” In addition, this granularity of information is useful to returning power users who may need to refresh their memory but don’t want to wade through all of the instructions again.
The example below shows the Overview section of installation instructions for ScPCA-nf. The overview lays out all the steps required to successfully run the pipeline, providing links to more documentation at each step.
Take a look at the full overview section here!
The Fine Details
The final layer is where you get into the nitty gritty technical details of the tool.
This includes:
- Detailed instructions for setting up - details of input parameters, configuration files and their structure. In ScPCA-nf, we link each step of the overview to detailed instructions like information about each of the columns in the Metadata config file.
- Advanced options for customizing the tool and when to use them. In the ScPCA Downstream Analysis pipeline, we link users to Additional Workflow Parameters after we have walked them through setting up the basic parameters.
Power of a Good Example
Most users in our study mentioned how useful a working example is when working with a new tool. Provide example input data, configuration files, and output data so users have something tangible to fiddle with and get a better understanding of the tool.
There are several advantages to providing examples.
- You can refer to examples in your documentation to make your instructions/descriptions more effective.
- An example reduces the investment required from the user to try the tool and get a deeper understanding of what to expect.
- A working example instills user’s confidence in your tool.
In ScPCA-nf, we provide an example directory that contains
- Example configuration files: Users don’t need to create their own configuration files referencing the documentation. This reduces the frustrating errors they might encounter due to minute mistakes in setting up their own configuration files.
- Example input data and how to use it: Users can try to use the pipeline on their own without needing to bring their own data.
- Example output files: Users have something tangible to explore without investing too much time and effort.
Presenting Content
When it comes to writing effective documentation, how you say it matters just as much as what you say. Even a well-structured document can be hard to comprehend if the language and formatting are arduous.
Language
Keep it simple.
- Write the documentation in a simple language and only use as many domain-specific terms as needed.
- Passive voice makes it difficult to comprehend the sentences. Adopt an active voice and keep the sentences as short as possible.
- Use a causal tone, don’t hesitate to use second-person pronouns like “We” or “you”. It makes the docs feel friendly and welcoming.
Formatting
People don’t read, they scan.
People scan in an ‘F’ pattern on text-heavy websites, which means that they usually end up reading only the first few words of every line.
Formatting for Scanning:
- Use informative headings: Informative headings make it easier for readers to get the most out of scanning.
- Write smaller sentences and paragraphs. They are easier to comprehend.
- Break up paragraphs into bulleted lists wherever possible to make information easier to consume.
- Draw the user’s attention to important items like crucial steps, links to valuable information, and examples. For example, you can distinguish the important links with this markdown button hack.
- Use tables to describe long lists of parameters.
Effective language and formatting in action!
Let’s look at this before and after from one section of our ScPCA Downstream analysis documentation.
On the left, the before version does a few things well. It uses formatting, and the heading is informative. It uses a table to draw attention to the fields that are required to be changed, which is an important step. However, there is still room for improvement. The information is difficult to scan since there is a big chunk of dense text. The language is informational, but it isn’t explicitly clear what actions the reader is expected to take.
On the right, we have the improved version. The information is broken down into bullets where possible. The sentences are more concise, and it provides clear instructions as to what readers can do with the information. It is easier to scan.
Let’s face it…
Writing effective documentation is challenging. Users might not always read every word in the documentation. They might even just scroll past large chunks of text, but we can accommodate those behaviors.
Give these key tips a try when writing documentation for your tools!
- Structure your documentation to start with high-level information and ease into lower-level details.
- Provide sufficient examples.
- Use simple language and short sentences as much as possible.
- Leverage the ‘F pattern’ and use clever text formatting to guide the reader’s attention to important information.
Interested in reading about other ways we prioritize the needs of our users when designing Data Lab tools? Check out this blog post to learn more about our user research activities!