asyncapi
Usability Research for AsyncAPI Tools
Hey everyone,
After our community meeting yesterday, we agreed that since the original issue on AsyncAPI tools usability research has been open for over three years, and our community goals have evolved, it makes sense to start fresh. So, I’m creating this new issue to track the initiative and open up the discussion.
Why this research?
The goal is to improve the developer experience by conducting usability testing on AsyncAPI tools. We want to gain deeper insights into:
- How developers interact with the tools
- Where they face friction or confusion
- What improvements could make their workflow smoother
This will be a qualitative research effort, focusing on usability testing and user interviews to gather direct feedback from people using our tools. Instead of making assumptions, we want real data to drive our decisions.
Why this matters for the community
Beyond improving the tools, this initiative is also about bringing more UX research and design contributors into the community. We talk a lot about code contributions, but we also need to prioritize research—prioritize understanding how people are using AsyncAPI tools, what’s working, and what’s not.
This research is an opportunity to:
- Foster a collaborative approach to improving AsyncAPI tools
- Show that we value user research and data-driven decision-making
- Create more opportunities for UX and design-focused contributors
Next steps
To move this forward, I’ve scheduled a call with a tool maintainer to align on current priorities. But before diving in, I’d love input from the tool maintainers, Developer Experience WG, and the marketing team:
- Have there been any past usability research efforts on AsyncAPI tools?
- Where can I find any insights that have already been gathered?
- What are the current priorities, and how can this research align with them?
This will be a collaborative bounty issue, and I want to make sure we’re setting it up in a way that’s valuable for the community. If you've worked on something related or have thoughts on what would be most useful to explore, let’s discuss!
@thulieblack @iambami @akshatnema @ashmit-coder @derberg @fmvilas
What about the
issues already submitted for the Bounty Program `2025-Q2`?
- https://github.com/asyncapi/website/issues/3781
- https://github.com/asyncapi/website/issues/3782
- https://github.com/asyncapi/website/issues/3784
- What is a 'collaborative Bounty Issue'?
- Who will be rewarded for the completion of such a Bounty Issue?
- Who will confirm the completion of such a Bounty Issue?
- What will be the measurable deliverables of such a Bounty Issue?
Overall, I think that the Research matter is not subject to the Bounty Program in general; rather, to me, the way @Mayaleeeee puts it, it resembles a small working group with time constraints, a defined leader, and a set of microgrants equally distributed among all participants of this working group, which contradicts the ideology of the Bounty Program: 'one issue - one solver.'
Hey @aeworxet
I appreciate the questions, and I’d love to clarify.
- What is a 'collaborative Bounty Issue'?
Research isn’t a solo effort—it’s about gathering diverse perspectives to get the best possible insights. That’s why I structured the issues this way. Instead of one person handling everything, different contributors take ownership of different aspects:
For example:
- I’ll focus on research planning and usability testing
- Another contributor can work on participant recruitment and data collection
- Someone else can handle designing and implementing the research page
This approach makes the work more efficient, faster, and richer in perspective, instead of relying on just one person’s viewpoint.
- Who will be rewarded for the completion of such a Bounty Issue?
Each issue will have its own participants, and each will be rewarded accordingly.
- Who will confirm the completion of such a Bounty Issue?
Since this research is focused on improving AsyncAPI tooling, it makes sense for a tool maintainer to be involved in reviewing and confirming completion. I have a meeting scheduled with a maintainer next week, and I’ll bring this up to see if they’re open to taking on that role.
- What will be the measurable deliverables of such a Bounty Issue?
Each bounty issue has clear, measurable deliverables:
- A structured research plan
- Usability test findings and insights
- Concrete design recommendations based on real user feedback
- A research page where people can sign up to participate
To move this forward, I’ve already started reaching out to tool maintainers, the Developer Experience WG, and marketing to align on what’s been done before and where this research can add value. This will ensure we’re building on past efforts rather than duplicating work.
Right now, most bounties focus on code and design, but this is a chance to broaden the scope and bring UX research into the mix. Research helps us see the bigger picture—how people actually use AsyncAPI tools, where they struggle, and what we can do to improve their experience. Instead of making decisions based on assumptions, we’ll have real insights to guide us.
But beyond that, this is also about growing our UX community. We want more people contributing to AsyncAPI in ways beyond just code—whether that’s through research, usability testing, or design. This initiative is a great way to open that door, show that we value research, and invite more UX contributors into the space.
I genuinely think this is worth considering as a bounty. It may be better suited for the next bounty quarter to allow time for gathering insights, but it’s a step in the right direction.
I'll drop these questions that I had previously.
- What part of the community goals is this research going to help?
- Why focus on tooling specifically? Before diving into the full research, do you have any insights that can support why we should pursue this research, such as common usability pain points?
- Will the research be for a specific tool first, or will it be for multiple tools?
- What will be the end goal for the research, how will we measure the success, and who will use the data?
The reason why I'm asking is that with the scope of what you wrote, the research goes beyond just design and UX. Something similar to what I'm saying above https://github.com/asyncapi/.github/issues/297#issuecomment-2120222396.
I would like to propose that the subject of research be discussed FIRST, and its value and terms evaluated, rather than being constrained by a tight two-week timeframe that began with the very submission of GitHub issues, which ONLY THEN triggered a discussion about why these issues were submitted at all. Therefore, I would kindly request that these three GitHub issues be deleted from the submission list, freeing up USD 800 of the reward fund.
I would like to propose that the subject of research be discussed FIRST, and its value and terms evaluated, rather than being constrained by a tight two-week timeframe that began with the very submission of GitHub issues, which ONLY THEN triggered a discussion about why these issues were submitted at all. Therefore, I kindly request that these three GitHub issues be deleted from the submission list, freeing up USD 800 of the reward fund.
Understood. I’ve removed the issues as requested. My goal was to introduce UX research into AsyncAPI’s bounty program in a way that adds value and invites new contributors. I still believe this is worth discussing further, so I’ll take the time to engage with the relevant working groups and revisit this in the future.
Thanks for bringing the questions here, Thulie
- What part of the community goals is this research going to help?
This research aligns with our goal of improving the developer experience and making AsyncAPI tools more accessible and user-friendly. By conducting usability testing and gathering feedback directly from users, we can ensure that AsyncAPI tools are optimized for real-world usage.
Additionally, this initiative supports broadening contributor opportunities beyond code, bringing in UX researchers and designers who can help shape the user experience of our ecosystem.
- Why focus on tooling specifically?
Focusing on tooling usability ensures we’re not just building features, but building the right features in the right way. This research will help us understand pain points and drive improvements that directly impact developer productivity.
Before diving into the full research, do you have any insights that can support why we should pursue this research, such as common usability pain points?
Not yet. That’s exactly why I’m starting with conversations with tooling maintainers, Developer Experience WG, and marketing. These discussions will help uncover any existing research, highlight known usability challenges, and ensure we’re focusing on the right problems.
If similar research has been conducted before, we’ll build on those insights rather than duplicate work. I also plan to engage the marketing team to explore how usability findings can support broader adoption efforts.
- Will the research be for a specific tool first, or will it be for multiple tools?
Initially, the research will focus on gathering insights through discussions with tooling maintainers, Developer Experience WG, and marketing. The goal is to identify key usability pain points across AsyncAPI tools.
Based on what we uncover, we may start with usability testing on one high-impact tool before expanding to others. If there's already existing research on specific tools, we’ll build on those insights rather than duplicate efforts.
- What will be the end goal for the research, how will we measure the success, and who will use the data?
The success of this research will be measured by:
- Clear usability insights and data-backed recommendations.
- Actionable & and specific improvements for AsyncAPI tools
- More engagement from UX and research contributors
The data will be used by:
- Tooling maintainers & developers to improve AsyncAPI tools
- The community to prioritize enhancements based on user needs.
- Marketing & adoption efforts to highlight improvements and attract more users
The reason why I'm asking is that with the scope of what you wrote, the research goes beyond just design and UX. Something similar to what I'm saying above https://github.com/asyncapi/.github/issues/297#issuecomment-2120222396.
Got it, I see what you're saying! The main focus of this research is usability and the developer experience—figuring out where people struggle with AsyncAPI tools and how we can make them better.
That said, I get that some of what we learn could also touch on things like documentation or onboarding. If that comes up in the research, I’m happy to share those insights so they can be useful beyond just UX improvements.
If there’s anything specific you think we should keep in mind, please let me know!
Hey everyone! I completely agree with @Mayaleeeee —this is a great way to involve contributors beyond code, and focusing on research is a smart move. It will bring in fresh perspectives and help grow the community.
I think we can treat this as a collaborative effort with @Mayaleeeee as the leader of the group( only if she is open to it). This way, it still aligns with the “One Issue – One Leader” model mentioned by @aeworxet , while allowing multiple people to contribute. It would be up to the leader to decide how to distribute the bounty, if at all. Since our main goal is improving tooling, this research will help us build tools developers actually want, based on real user pain points—not assumptions. Projects like React, VS Code, and Postman all benefited from research, and AsyncAPI can too. This is also a great opportunity to bring in contributors with UX, research, and design skills, supporting AsyncAPI’s inclusive values.
I’d be happy to help with the Research Page design and implementation. If maintainers are available, I’d prefer they lead technically; otherwise, I’m happy to step in and implement as needed.
cc: @thulieblack @Mayaleeeee @aeworxet
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience :heart:
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience :heart: