Interview with Michael A. Hughes; Author of “A Research Primer for Technical Communication”

 Interview by Angel Candelario


Michael A. Hughes
Author of “A Research Primer for Technical Communication”

Research in technical communication improves technical communicator’s decisions. Michael A. Hughes wrote a book that is currently used in undergraduate courses, aimed to technical communication students and practitioners who are new to empirical research.  Michael has a PhD in Instructional Technology from the University of Georgia and a Masters in Technical and Professional Communication from Southern Polytechnic State University. He is a Fellow with the Society for Technical Communication and a Certified Performance Technologist through the International Society for Performance Improvement.

Very kindly, Michael shares with members of Technical Writer In Action his experiences related to research in technical communications.

TWIA: Michael it is a pleasure to interview you; thanks for your time.

Michael A. Hughes:  My pleasure.

TWIA: Can you tell us a little bit about yourself? What is your experience in the technical communication field?

Michael A. Hughes: Currently I am a User Experience Architect for IBM Security. I define requirements and develop design artifacts for a customer portal that serves our Managed Security Services customers. Leading up to this role, I have been a technical writer, instructional designer, and usability tester.

TWIA: The roles and responsibilities among technical communicators differ by industry and the company where they work. Despite this, the ability to research is vital to any technical communicator.  What research is and the role that research plays in technical communication?

Michael A. Hughes: Research provides data about our users that inform our design decisions. It grounds our practices in something other than our own idiosyncratic preferences or ego-centric world views.

TWIA:  Which are the goals of research?

Michael A. Hughes:  Understand the problem space—What do users do today? What are their goals within a task? How fast/accurate/satisfied/etc. are they in the current state? What is dissatisfying them? What are they lacking?

  • Assess validity of a design concept—How would users make sense of this user interface/instruction? Could they do it fast/accurately/satisfactory enough? Does it solve their problem?
  • Compare and contrast alternatives—Which design is better/faster/more usable/more useful/more satisfying?

A rigorous research project could take on all three of those goals over the life cycle of a design project. Sometimes you only do one. Time, money, and priorities always dictate how broad and how deep you go.


TWIA: What types of research can be done?

 Michael A. Hughes: 

  • Qualitative—Understanding how users make sense of or feel about something. Findings such as users dislike clicking “OK” to negative messages would come from this kind of research.
  • Quantitative—How many, how fast, how long, how often, etc. This kind of research uses statistical methods to draw reliable conclusions.

In addition to those two significant methodological branches, we can talk about other kinds of research differentiations:

  • Theoretical—Readability, mental processing models, etc. This kind of research is usually abstract and broad—academic stuff that can be applied to many kinds of design problems. Findings such as users read better when line lengths are between x and y characters would come from this kind of research.
  • Post modern—How technology impacts specific social groups. More popular with academics than corporate sponsors of research.


TWIA:  What steps are necessary to conduct an effective research?

Michael A. Hughes: 

  1. Know what high level questions your research is trying to answer. Too many research projects start with “Let’s send out a survey.” Then people write a bunch of questions and have no idea what to do with the results. Even high level, exploratory research projects need to be driven by specific research questions like “Why do users come to our portal,” “How often do they come,” and  “What information do they need when they are there.”
  2. Find out what’s already been done to answer these questions. This could be a formal literature review or a simple Google search. The point is that nothing is new under the sun—start where others left off, not from scratch.
  3. Reframe and refine your research questions based on your now deeper understanding.
  4. Design the study.
  5. Take some data.
  6. Analyze it and draw your conclusions.
  7. Act on those conclusions.

bookTWIA:  You are the author of “A Research Primer for Technical Communication: Methods, Exemplars, and Analyses”; could you talk a little about this book? It’s this book part of a training program or certification?

Michael A. Hughes: 

I saw the need for such a text when I taught a research course in a Masters program in technical communication. Most texts were geared around educational examples and leaned more heavily on the statistical math than a real practitioner needed. I contacted George Hayhoe, the editor of Technical Communication, the journal for the Society for Technical Communication (STC) and pitched the idea. I wrote most of the front end of the book that explained how to conduct research in technical communications and George compiled the back half in which he critiqued seminal research papers that had been publish in Technical Communication.

The book was named as one of the top books in our field in the last 20 years by STC. It has been used in undergraduate and graduate programs.


TWIA: Could you describe a recent challenge you’ve been presented with at work related to research and how (if possible) you were able to overcome it?

Michael A. Hughes: 

The biggest problem is getting access to customers in order to conduct research. I have had success with two strategies to deal with this.

  • I have partnered with our Customer Loyalty team—a group that deals with key customers or accounts at risk—to get access to the customers they deal with. The Loyalty team uses the engagement to show customers we care about their opinions.
  • I find internal customers, i.e., IBM consultants who use our product on behalf of customers. They do all the things that customers do and have all the same problems, but because they are IBM employees, I have an easier time getting access to them.

TWIA: What are your current projects?

Michael A. Hughes: 

  • Designing a portal that would let users assess their enterprise security risk and identify potential ways to reduce or mitigate that risk
  • Understanding how customers use our security alerts and how those alerts could be more useful to them


TWIA: What advice would you give –- if any -– to those looking to develop their research skills?

Michael A. Hughes: 

Don’t turn your nose up at qualitative data, that’s where the greatest value is; don’t discount the need for statistical rigor when you are dealing with quantitative data. Never use sample data to make sweeping statements about a population at large without first testing the statistical significance of those inferences. Tip: Let a spreadsheet do the math, worry on understanding the concepts. Uh, my book would be a good resource for that.  🙂 


TWIA: Do you have anything specific that you want to say to your readers?

Michael A. Hughes: 

It is said that Aristotle proclaimed that women have fewer teeth than men, never having bothered to count Mrs. Aristotle’s teeth. Quit guessing about users and readers, start collecting data and making informed decisions about you designs.





Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s