Here is an outline of the ad-hoc (“dialog-driven”) continuous user research approach that I’ve further refined during the design and development of my Docsify-This open source project.

Ad-hoc (“Dialog-driven”) Continuous User Research

• Define User Research Questions, for example:
  • Who is using the project?
  • What aspects of the project work the best/worst for them?
  • What systems are they using the project with?
  • When are they using the project?
  • Where are they using the project?
  • Why did they choose the project?
  • How are they using the project?
  • How can the project be improved?
• Leverage Existing Communication Channels, for example:
  • Learn where your audience is online (e.g. Mastodon, X, LinkedIn, Discord, Slack, etc.) and then make efforts to connect with them there, moving to 1-on-1 messaging when appropriate
• Support Continual User Feedback, for example:
  • In addition to direct user communication, create a brief (i.e. <5 min. survey) to get ongoing user feedback. Link from the app, GitHub repo, documentation, social media, etc.
• Strategically Handle Feature Requests, for example:
  • First step?
    • Ask/confirm what they're trying to accomplish, and when
  • As needed, use the “5 Whys” to reveal actual goal
  • Share any possiqble workarounds
  • Consider how well the feature request aligns with your product vision
• Open Up Your Design Process, for example:
  • Share-out design “visions”, early designs, written overviews, etc. for user input and feedback
• Analyze Design of Public Projects, for example:
  • Public usage of the project provides the ability to review specific contexts of use, consider possible new features, and to learn more from the authors

This post is part of the 🧡 Building Open Source with Heart Pack - a collection of posts about fostering projects users and contributors enjoy.