Dennis D. McDonald (ddmcd@outlook.com) is an independent consultant located in Alexandria Virginia. His services and capabilities are described here. Application areas include project, program, and data management; market assessment, digital strategy, and program planning; change and content management; social media; and, technology adoption. Follow him on Google+. He also publishes on CTOvision.com and aNewDomain.

The Importance of Audience Research to Open Data Program Success

By Dennis D. McDonald, Ph.D.

Why audience research?

Click or tap the above image to download a .pdf of this article.One of the best sessions I attended at the recent Socrata Customer Summit in Arlington Virginia was Socrata’s Joe Pringle’s session “Understanding and Serving Data Audiences.”

Joe walked us through the kinds of audience questions we should be asking when planning and managing open data programs. The basic objectives Joe discussed were:

  • Identify your priority audience
  • Understand what they want and why
  • Know how they find, access, and use your data
  • Incorporate audience intel into your decisions

This may seem basic stuff when viewed from the perspective of someone who regularly performs a traditional corporate market research function but the “open data” movement — promoting open access to reusable government-sourced data — is a relatively new phenomenon and one that is closely tied to government participation and transparency initiatives.

The idea behind open data is simple: data collected by a government agency should be, with certain exceptions related to privacy and security, available to the public for use or re-use in whatever manner they see fit.

If you’re going to do that, and if you’re serious about providing data in a manner that enhances its availability and usefulness, you need to understand your audience’s needs in order to provide data in the right size, shape, and form.

Regardless of whether you call this “audience research” or “market research,” one reality of providing data and data related services is that you can never count on people using your data exactly as you planned. Because of that reality you really need to understand the who, where, what, why, and how of data usage.

What user groups are you targeting?

Understanding the “who” and “why” are the key questions.  Joe suggested one approach was to consider 5 to 10 typical “personas” as representing your key user groups; a few examples are the following:

  • Civic actor
  • Media
  • Industry
  • Researcher
  • Issue activist

Understanding that such groups exist, even if you know this is an oversimplification, should then lead to your asking why members of these groups would – or would not — use your data.

Talk to people!

You do this by asking them.  Joe suggests that you should at least use the phone to talk to people in each persona category about why they use or might use your data.

Of course you can also use a variety of survey or other tools, but at least you should start by just asking and talking.

I say that as someone who spent almost a decade doing quantitative and qualitative research into information product usage. Based on that experience — and a lot of number crunching — I can honestly say that, no matter how statistically valid your quantitative research is, there’s simply no substitute for just talking with the customer about why they might want or need your data.

Some caveats

I do  have some cautionary notes based on personal experience with designing and managing surveys of users of various information and data products and services.

First, be wary of what people say about their intentions regarding data and the services that provide data.  Many people find future behavior hard to predict. In some cases they might tell you what they think you want to hear, not what they really think.

Second, try to get to the why the data service is needed. Failure to understand why will severely limit your ability to predict or understand user behavior and the value derived from using your service.

Third, try to understand actual behavior not just predicted behavior or preferences.  This is especially important when you’re trying to understand the connection between the data you provide and the value derived from its use. Drill down on a recent incident that’s a real and fresh.  At the same time, give the user time to use the data you provide before you ask about its utility.

Fourth, don’t confuse how people interact with your data with the value they actually derive from using the data.  An easy to navigate site is one thing. Ease of interacting with, filtering and visualizing data is another. Actually using the data for some purpose is still another.  Remember, beneficial use of the data you provide is why you’re in business, not maximizing file downloads or providing a bewildering array of analytical tools that only a subset all of your users understands how to use.

Fifth, don’t assume that because a data app worked in other jurisdictions it will work in yours, even if using the app is the quick way to provide data access.  As important as it is to share tools and techniques, don’t assume that your users will respond the same way as did the users in the jurisdiction where the app was developed.

This doesn’t mean that you should not share data, metadata, and apps, but that you need to very carefully consider your own audience’s needs and experiences.  

Related reading:

Copyright © 2014 by Dennis D. McDonald, Ph.D. Dennis is a project management consultant based in Alexandria, Virginia. He works with BaleFire Global on designing and implementing open data programs and with Michael Kaplan PMP on SoftPMO project management services. His experience includes consulting company ownership and management, database publishing and data transformation, managing the integration of large systems, corporate technology strategy, social media adoption, survey research, statistical analysis, and IT cost analysis. His web site is located at  www.ddmcd.com and his email address is ddmcd@yahoo.com. On Twitter he is @ddmcd.

When are collaboration “barriers” good for innovation?

When are collaboration “barriers” good for innovation?

Problems With Résumé Driven Hiring