Enabling collaboration with standards for describing research across teams and disciplines — to get more done with insights

‘Nutrition facts’ metadata on reports that enables insight seekers to compar and understand study basics from any insight-generator, at a glance. Illustration shows documents with comparable header information.

How should I think of this piece of research? How does it relate to other inputs that we could build our product plans around?

Insight consumers can become confused when different insight generators, each vying for attention and impact, talk about their work in isolation. Researchers of different stripes can clarify what they offer — and start to build a more connective community — by defining common ways of describing each type of research. Communities can come together to stand on a foundation of shared language.

Speech bubbles: Q: “How does your team quickly explain a piece of research to product people — like, how do you describe a report in a table list of reports?” A: “I think everyone is doing it a little bit differently, all trying to copy what the other researchers are doing.” Q: “What do you think about coming together across teams to figure that out, so we’re speaking the same language with our shared stakeholders?” A: “I think that would be good, and then it’s clear when apples are being com

Standard ‘description blocks’ for research can answer the ‘5 whys’ in a digestible format, drawing attention to factors that are crucial to comparing research outputs. Research communities can define some of the elements as closed lists to drive consistency (e.g. research team) and leave some elements open to allow for diverse, project specific values (e.g. key topics). These descriptions can become linked gateways to more information, allowing insight consumers to drill in for more description, including strengths, weaknesses, and caveats.

Improving your insight operations

  • Gathering existing research description and assembling a working group
    Seek out examples of internal language for describing research, and locate any relevant controlled vocabularies that you can build from. Include sources that product people consider research, rather than limiting scope to specific research disciplines. In the process of assessing the current state, identify interested insight generators and insights seekers that can contribute to your standards effort.
  • Identifying common and infrequent research descriptions
    When gathering descriptive metadata from different teams, some standards will emerge as relatively straight forward, with easy alignment to how varying researchers talk about their work (e.g. date conducted). However, researchers in some disciplines may have a range of ‘in the weeds’ descriptors that may be harder to process. A quick usability study with insight seekers can help shift perspectives on what’s actually primary description and what can be included as secondary, free form context. It’s also worth noting that, if possible, terminology used in research tools should not dictate your standards.
  • Pushing further to define research inter-relations and call out key distinctions
    Define standards for consistent study titles (or at least a list of ‘don’ts’). Explore summarizing more of the method section and the ‘why’ of research into standard descriptions. Generate new descriptive content to call out key distinctions among different types of research, and to explain research methods, strengths, and caveats. Add links to education content where insight seekers can, from any research artifact, grow their understanding of the insights they are looking at, as well as how those insights fit into the bigger picture of research within your organization (method categorization, glossary of research terms, etc.).
  • Cutting down and standardizing to ensure description is legible ‘at a glance’
    Over-long description without corresponding value will increase friction on the authoring side and create unnecessary work for research consumers. Look for opportunities to combine fields. Set aside items that are more about findability than study description. Seek plain language alternatives. Rank and organize fields into logical groupings. Standardize ‘closed’ values where appropriate to simplify authoring and consumption. Push ‘open’ descriptive fields to the end of your ‘nutrition facts’ block. Again, internal prototype studies with insight seekers can identify areas to improve.
  • Iterating and operationalizing your new standard
    As with any set of standards, this is not a ‘one and done’ process. Pilot small and iterate. To grow collective identity across contributing researchers, name your new standard and seek leadership buy-in for the work that it will take to apply it broadly. Develop a process — perhaps owned by staff who ensure that each research output is a meta analysis of compiled learning (C2) — to inspect whether new reports are implementing your descriptive standards effectively. Use gaps in the portfolio of research currently available in your organization to argue for changes to research roadmaps (B3) and staffing.
  • Your idea here…

On the path from insight to product impact

A diagram of seven stages on the path from insight to product impact: Category called “Integrating research content” 1) Sufficient evidence (highlighted), 2) Usefully articulated insight (partially highlighted), 3) Awareness of possible planning target (grayed out), Category called “Integrating into product planning” 4) Envisioned solution ideas (grayed out), 5) Prioritized plan (grayed out), 6) Quality execution (grayed out), 7) Understood results (grayed out).

Let’s connect

Related posts

Selected references

  • “Our goal to give researchers the best chance to share knowledge with peers and non-researchers within their organisation by creating a UX Research vocabulary that:
    - is logical
    - is memorable
    - is easy to adapt one’s workflow to
    - is easy to integrate with existing repositories and platforms
    - is powerful enough to be used for data mining in the future.
    - extends as many existing standards as possible
    - is supported by industry, yet remains independent
    - is open source” Paul Kotz
  • “Consider if we even had just a few common tags:
    - Fiscal year (standardized list)
    - Department name (standardized list)
    - Scope (standardized list e.g. website, application, program, service)
    - Topic (unstructured)
    - Project title (unstructured)
    - Project description (unstructured)
    - Type of research (standardized list e.g. usability testing, feedback)
    - Research question or task (unstructured) — one entry per question or task

    A basic set of tags like this, with both standardized and unstructured elements, would enable merging all of the data into a central pool..” spydergrrl
  • “Ultimately, we landed on the following metadata for each research project:
    - Title of project
    - Start date
    - Researcher(s)
    - Status (planning, execution, analysis, reporting, completed)
    - Related department(s)
    - Tags (for type of research, e.g. user interviews, usability testing)
    - Products (e.g. main website, Weaver Library)
    - Keywords
    - User type” Rebecca Blakiston



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jake Burghardt

Jake Burghardt

Focused on integrating streams of customer-centered research and data analyses into product operations, plans, and designs. www.linkedin.com/in/jakeburghardt