By Chris Whitehead
Big Data. Small Data. These are powerful buzzwords that can inspire even the most insipid investor to throw wads of cash in all directions. And with good reason. Ralph Finos, an IT industry market research analyst, projects the industry to grow from 27 billion dollars in 2014 to over 60 billion dollars in the next four years. But what do these terms even mean, and why should you, as a technical communicator, care?
What Is Data?
In their book, Big Data: A Revolution that will transform how we live, work and think, Viktor Mayer-Schönberger and Kenneth Cukier describe the inception of the term. In the early 2000s, the term big data was coined to refer to data that was too large to fit in the memory of the computers used to process data, although now the term is used more generally. These days, big data seems to be used to refer to any project involving data analysis.
Then what is small data? The Small Data Group defines it as data that “connects people with timely, meaningful insights (derived from big data and/or ‘local’ sources), organized and packaged—often visually—to be accessible, understandable, and actionable for everyday tasks.” This means that big data is information beyond the ability of a person to comprehend, so it needs to be broken down in order to be useful (the perfect task for a technical communicator, right?).
In a presentation about deep learning, Ben Taylor, the chief data scientist for HireVue, explained that some types of big data analysis, in this case neural network machine learning, are expensive and sometimes overkill. You can spend time and money collecting and processing enormous amounts of data, then hire people to interpret it and break it down small enough for comprehension, and you’ll end up with the same answers you could have gotten from a smaller data set. This makes small data sets like Web analytics, that are easy to interpret and summarize, even more valuable.
Why Is Data Valuable?
Adobe is currently running a television commercial in which a man sits at a bar visibly distressed about a multi-million dollar ad campaign he invested in without looking at the data (https://adland.tv/commercials/adobe-gambler-super-bowl-gambling-2016-30-usa). The argument is that if he’d looked at the data, his business decision would have been less of a gamble. While all decisions cost time and money, decisions based on data mitigate risk, increasing the chance of a positive outcome.
Think of data as information. As a technical communicator, you would never undertake a project without first gathering information. You might interview subject matter experts, you might test the product, and in the software industry, you might even dig into the code so that when you start documenting, you have information (data) that allows you to write targeted information for your audience.
New technologies are continually creating new ways to collect information. Using these tools, Web-based help documentation gives technical communicators access to a significant source of information. Are there features that are difficult to use or understand? Are there some features that are more used than others? By leveraging that information, technical communicators can answer questions to improve product design, reduce support workload, and streamline their own knowledge architecture.
Start Collecting
Web analytics are the perfect place to start with small data. A good marketer will run analytics on their websites to collect important, decision-making data. Web-based documentation can be used to collect data the same way. There are a myriad of analytics tools out there ranging from free-to-use Google tools to the Adobe Marketing suite. For those getting started, I would recommend Google Analytics. First it’s free, and second it’s easy to use. It’s also easily customizable so you can get answers to the questions that come up as you dig through your data.
For many of you, the analytics platform will be a new technology. But this won’t be a problem. Not only is the documentation straightforward and easy to follow, but Google has created the free Analytics Academy with courses like “Digital Analytics Fundamentals” and “Ecommerce Analytics: From Data to Decisions” to not only help you get started, but to also turn you into an analytics expert in a short amount of time.
Once you’ve set up your analytics tool, you will have small data, both in the sense that the data set is small and in the sense that it is visually broken down by your tool for human comprehension. Depending on your situation, some of that data will be useful and some won’t. For example, our team is currently far more interested in which pages are being viewed than which cities those views are coming from. Every situation is different, but once you have the information, the skills you already use as technical communicator will help you interpret and share.
Start Learning: A Case Study
Sometimes after you start collecting analytics, you don’t know what to look for. We started with a common metric: page views. Starting at the top, we looked at the more popular pages. The home page was the most popular, that was no surprise. The next few pages made sense, too. Our writers were very familiar with the software and our audience, and they had done a good job guessing what the user would need help with. On the other hand, our fifth most popular page was a surprise. This was a feature in our software that we assumed was easy to use. After all, we all knew how to use it. This was our first insight. We quickly went in and beefed up our documentation for this topic, instantly improving the value of our helps.
At this point, we wanted to know if our changes were helpful. We worked with our developers to create a feedback script that we could add to the bottom of our topic pages. We simply asked the user, “Was this topic helpful?” and left a space for comments. The feedback code sent us emails with the users answers and the topic the survey came from. Sometimes the feedback was positive, which was nice. But more often than not, the feedback came in that the topic wasn’t helpful. In that case, we reviewed the comments and updated our topics accordingly.
At this point, we were noticing significant time-savings and increased positive feedback. Small data was working, and this was the start of our targeted documentation methodology.
We kept looking at the data, and we noticed more trends. There were topics we had written and were maintaining that no one was reading. After some discussion, we decided the topics weren’t being read for one of two reasons. Either they weren’t needed, or the user couldn’t find them. Instead of using our best guess, we wanted to use data to decide what to do with the topics.
Google Analytics has a feature that let’s you track site searches, so after some research, we added this to our Web helps. The search data was just what we needed. There were some cases where writers and users were using completely different terms to refer to features. As a result, users weren’t finding the topics they needed. In other cases, there were topics with no corresponding searches. We stopped maintaining those pages, resulting in another time saver.
The search data helped us build a better Frequently Asked Questions page and add hot topics to our landing page. We added analytics events to track which links were being clicked, and updated the links as needed. The more we learned about our analytics tool, the more questions we answered and the more targeted our approach. Now when our team makes a decision regarding our documentation, it’s data driven.
Not only has this impressed our boss, our team runs more efficiently. Now our team has the time to reach out to other units across the company to document internal processes. We’ve been able to work with live support to enhance their knowledge base. We’ve also taken ownership of the documentation for previously undocumented products, significantly increasing the value added by our team in the grand scheme of the organization.
Share Your Data
In the Software as a Service world, we’re constantly devising new features to stay ahead of the competition, and Agile development methods allow us to continually improve existing features. Now, as a technical communicator, I have an emotional connection to the value of a robust documentation system, but the truth is, users would prefer to spend more time using the software than reading help files. As we looked at our data, we were seeing searches and page views for certain features. According to our data, users were looking at the helps almost as much as they were using the feature. We deduced that this was because that particular feature was hard to use and understand.
We gathered all the data we had about that particular feature and put together a brief report. We showed that users needed constant help to use the feature. We went through our feedback emails and found that there were a lot of comments, not about our documentation, but about the difficulty of using this feature. We included these in our report.
Prior to this, documentation had been viewed as auxiliary in our organization. But when we submitted our data report to the project managers and product owners, there was a paradigm shift. We showed that we had data about how customers were using our product. This was key information the company was already trying to collect. Marketing had spent significant time and money sending surveys to try and collect this data. The company was spending money to send project managers to do ride-alongs and in-person interviews with customers. While both of these methods did provide information and insight, they were more expensive, more time consuming, and reached fewer customers than our data collection methods. Our product owners were ecstatic and started implementing our suggestions into their upcoming design changes.
Now we send monthly reports from our analytics tools to project managers and lead developers. We share our feedback emails with our user experience engineers. Our documentation team has become a key collaborator across the company. Some project managers have added our team as a permanent part of their planning process, where we sign off on software changes and stories before they even reach the developers.
This is how we’ve been able to use data in our team, and while we’re pretty impressed with our small data expertise, it all stemmed from our core skills as technical communicators. We used our research skills to learn new technologies and ask questions. Our ability to understand an audience helped us identify additional audiences for our findings within our organization. Finally, our communication skills allowed us to interpret the data in a way that managers and developers could understand and appreciate.
What’s Next?
Once you’re touched by the data bug, there’s plenty of room to grow. You may want to upgrade your analytics tools, or add additional tools to answer more specific questions. You may want to conduct a more sophisticated analysis of your data. Luckily, there are plenty of ways to learn more. Informally, there are numerous blogs on small data. Smalldatagroup.com is a good place to start. I also like to use sites like MeetUp to find groups that focus on data science or the computer languages used to analyze data, such as R or Python.
For more formal training, the online learning community provides options. several of our writers are currently enrolled in the data science specialization through Johns Hopkins University on Coursera. The cost is minimal, and even after the introductory course, our writers had more and more ideas about what we could do with our data.
References
Bonde, Allen. Defining Small Data. Small Data Group, 2013, smalldatagroup.com/2013/10/18/defining-small-data/.
Finos, Ralph. Big Data U.S. Professional Services Market Forecast 2014-2020. Wikibon, 2015, wikibon.com/big-data-u-s-professional-services-market-forecast-2014-2020/.
Google. Improve your Analytics skills with free online courses from Google. Analytics Academy, 2006, analyticsacademy.withgoogle.com/explorer.
Mayer-Schönberger, Viktor, and Kenneth Kukier. Big Data: A Revolution That Will Transform How We Live, Work, and Think. New York: Houghton Mifflin Harcourt, 2013.
CHRIS WHITEHEAD is a technical writing team lead for Verisk Insurance Solutions, Xactware. Chris holds a BA degree in English from Penn State and an MFA in creative writing from Brigham Young University.
