What I Learned From My Open-Source Journey
When I started working on open-source projects such as Kubernetes SIG-Multicluster and KServe in the cloud-native community, I began to understand the importance of user experience (UX) in developer tools.
Today, many organizations and open-source communities are focusing on building new products, introducing AI features, and improving existing technologies. Engineers are busy developing new features, fixing technical issues, and releasing new versions of their software.
During my journey, I noticed that developer experience (DevEx) is important, but it does not always receive the same attention as product development.
Many engineers understand the value of UX, but they often do not have enough time to focus on improving the developer experience. Some engineers are interested in participating in UX research, but their busy schedules make it difficult to attend interviews or contribute to UX-related activities.
I also noticed that some engineers try to apply UX research methods themselves. However, without enough knowledge of UX research, they may choose methods or solutions based on what they personally feel is appropriate rather than following a structured research process.
At the same time, UX designers also face challenges when entering the developer experience field.
Unlike designing everyday applications, working on developer tools requires technical and domain knowledge. Designers need to understand how developers work, what tools they use, and what challenges they face.
For example, I have been learning about Kubernetes and the cloud-native ecosystem for almost two years. Even today, I feel there is still a lot to learn before I can fully understand the technical challenges developers experience.
Developer experience requires both UX knowledge and an understanding of the developer's technical environment.
These experiences made me think about an important question:
How can organizations improve developer experience without spending too much time, money, and effort?
1. Why Improving Developer Experience Can Be Challenging
During my open-source journey, I interacted with people from different organizations and learned how they approach developer experience.
I noticed that some large organizations have dedicated UX teams, budgets, and resources to improve their products. However, smaller organizations and open-source projects may not have enough time, money, or people to focus on UX improvements.
This does not necessarily mean they do not care about user experience. In many cases, they are already busy maintaining their products, developing new features, and supporting their users.
The challenge is not always a lack of interest in UX. Sometimes, it is a lack of time, resources, and a clear process for making improvements.
Another challenge is finding UX professionals who are interested in developer tools and have enough technical knowledge to work in this field.
As a result, even when engineers experience difficulties using a product, those challenges may not receive immediate attention.
2. Why UX Should Be a Continuous Improvement Process
One of the most important lessons I learned is that user experience is not a one-time activity. It is a continuous process of learning, testing, and improving.
Imagine an organization develops an application, tests it, and launches the first version.
During the first few months, users start exploring the application and using its features. After six months or one year, they may begin to experience challenges that were not identified during the initial development and testing stages.
These challenges may include confusing workflows, difficult navigation, unclear documentation, or features that do not work as users expected.
Even if the organization improves these issues and releases another version, users may discover new challenges as the product continues to grow.
This means UX improvements should not stop after a product is launched.
Every new version, feature, or workflow can create new opportunities to understand users and improve their experience.
In simple terms:
Build the product → Release it → Listen to users → Identify challenges → Improve the experience → Release the next version → Continue learning.
This cycle should continue throughout the product's life.
3. The Time, Cost, and Effort Behind UX Improvements
From my experience working as a Senior UX Designer at Super Purposes, I learned that even small UX improvements can require significant time, money, and organizational effort.
For example, imagine an organization decides to improve the user experience of an existing application.
The first step may be to hire a UX designer or build a UX team.
At Super Purposes, I was involved in hiring UX talent, assigning tasks, managing UX activities, and reviewing design work.
From this experience, I learned that hiring suitable UX talent can take approximately two to three months(For immediate hire, many be different time line for regular hiring talent), depending on the organization's requirements, candidate availability, interviews, and evaluation process.
During this period, the organization is already spending time and money on recruitment, hiring teams, and tools.
Once the UX designer joins the organization, the next stage involves understanding the existing product, discussing improvement opportunities with managers and developers, and identifying user challenges.
The UX improvement process may include:
Understanding the existing application: Learning how the product works and identifying its current limitations.
Conducting UX research: Interviewing users, running usability studies, and collecting feedback.
Analyzing research findings: Identifying common challenges, patterns, and opportunities for improvement.
Designing solutions: Creating design improvements and exploring multiple iterations.
Testing improvements: Evaluating whether the proposed solutions actually solve users' problems.
Collaborating with teams: Working with developers, managers, and stakeholders to review and approve changes.
Documenting the research: Recording findings, decisions, and improvements for future reference.
Depending on the size and complexity of the project, this entire process can take several months. In some cases, a major one feature UX improvement initiative may take nine to twelve months or longer.
For a solo UX designer, managing all these activities can be especially challenging, so it leads the organization to hire multiple talents.
Before AI tools became widely available, completing these activities often required more manual effort. Today, AI can help designers with tasks such as organizing research findings, preparing documentation, analyzing feedback, and exploring design ideas.
However, AI cannot completely replace the need to understand users, validate findings, and make thoughtful design decisions.
Even with AI assistance, a solo designer may need many months to complete a large UX improvement project (Start working on improvements and deliver the results and then documenting the project).
This helped me understand that UX improvements are not only about design. They also involve organizational time, money, people, collaboration, and long-term planning.
Why UX documentation is equally important
Another important lesson from my experience is the value of UX documentation.
Imagine a company completes user research and makes several improvements but does not document the findings or decisions.
After a year, the company decides to improve the same application again. If the previous research findings are unavailable, the new team may need to repeat some of the earlier work.
This can increase the time and cost of future improvements.
Good UX documentation helps organizations preserve knowledge, avoid repeating research unnecessarily, and make better decisions in future product versions.
4. New Features vs. Better Developer Experience
In software development, organizations often follow planned release cycles to introduce new features, fix bugs, and improve product capabilities.
For example, while working with the KServe project, I observed how the project continues to evolve with new releases and capabilities.
KServe has supported traditional predictive model serving, while its development has also expanded toward generative AI and large language model (LLM) workloads.
This is an example of how developer tools continue to evolve as technology and user requirements change.
However, releasing new features does not automatically mean the developer experience is improving.
A product may offer powerful technical capabilities while developers still face challenges understanding documentation, configuring the system, deploying applications, or troubleshooting errors.
In many organizations, engineering teams are already focused on delivering new releases. Conducting UX research and improving existing workflows may require separate planning, resources, and approval.
As a result, new feature development may move faster than UX improvements.
This creates an important question:
What if organizations could collect developer feedback continuously instead of waiting until they have enough time and resources to start a large UX research project?
I believe this approach could help organizations identify problems earlier and make improvements more regularly.
5. How Can We Improve Developer Experience With Less Time and Effort?
Based on my experience with Kubernetes SIG-Multicluster and KServe, I started thinking about practical ways to improve developer experience without always depending on large UX research projects.
I believe small, consistent UX activities can help organizations understand developers' challenges and make meaningful improvements over time.
Here are three approaches that I believe can help.
Approach 1: Collect Feedback Directly From Developers
One of the simplest ways to understand user challenges is to ask users for feedback while they are using the product.
For example, after a developer completes an important workflow, the application could invite them to share their experience through a short feedback form.
The form should take only two to three minutes to complete.
It could include simple questions such as:
- What were you trying to accomplish?
- Did you experience any difficulties?
- What could we improve to make this task easier?
This approach allows organizations to collect feedback regularly without requiring every user to participate in a long interview.
Over time, the organization can build a useful collection of feedback that helps identify common problems and prioritize improvements.
Many organizations already use feedback surveys in their applications.
I believe developer tools and open-source projects can also benefit from making short feedback activities part of their regular workflows.
The important point is to collect feedback at the right moment without interrupting developers' work.
Approach 2: Use Existing GitHub Issues as a UX Research Resource
Sometimes, organizations may not receive enough responses from surveys or may struggle to recruit developers for interviews.
In these situations, valuable user feedback may already exist in the project's GitHub repository.
Developers regularly create GitHub issues to report bugs, ask questions, describe technical difficulties, and request new features.
These issues can provide useful information about the challenges developers experience while using a product.
For example, instead of starting a completely new research study, a UX designer or engineer can review existing GitHub issues and identify patterns such as:
- Repeated deployment and configuration difficulties.
- Confusing error messages or troubleshooting processes.
- Missing or unclear documentation.
- Challenges with maintenance and observability.
- Feature requests that reveal unmet developer needs.
By organizing these issues into common themes, teams can identify areas that may need UX improvements.
During my KServe research, I explored GitHub issues to understand the challenges developers experience while working with the project.
This experience helped me recognize that GitHub repositories can be a valuable source of existing user feedback for developer experience research.
However, GitHub issues do not always explain the complete user journey or the reasons behind a problem. When possible, teams should validate their findings through interviews, usability testing, or additional feedback.
Approach 3: Use Developer Conferences to Collect Quick Feedback
Another opportunity I noticed during my open-source journey is the value of developer-focused conferences and community events.
Many open-source projects participate in conferences, organize booths, and introduce their technologies to developers.
For example, KServe participates in cloud-native community events where engineers can learn about the project and interact with contributors.
These events are already bringing developers and project teams together.
Why not use a few minutes of these conversations to understand developers' challenges?
Instead of only explaining the product or introducing new features, project contributors could ask developers a simple question:
"What is the biggest challenge you face while using our project?"
A developer may need less than five minutes to explain a challenge they recently experienced.
Even a short conversation can help the team discover a problem, understand a confusing workflow, or identify an opportunity for improvement.
Imagine speaking with ten developers during a conference. Their feedback may reveal common challenges that deserve further investigation.
These conversations do not replace formal UX research, but they can help teams identify important questions and decide where to focus their research efforts.
Sometimes, a five-minute conversation can be the starting point for a meaningful developer experience improvement.
6. Small UX Activities Can Create Long-Term Value
From my experience, I believe organizations do not always need to wait until they have a dedicated UX team or a large research budget to start improving developer experience.
They can begin with activities that fit into their existing development and community workflows.
For example, collecting short feedback surveys, reviewing GitHub issues, and talking to developers during community events can help teams understand user challenges continuously.
However, collecting feedback is only the beginning.
The real value comes from reviewing the feedback, identifying common patterns, prioritizing problems, making improvements, and checking whether those improvements actually help developers.
Over time, these small activities can build a stronger understanding of users and help teams make better product decisions.
They can also create useful research documentation that supports future improvements.
For smaller organizations and open-source communities, this approach may be more practical than waiting to launch a large UX initiative.
Conclusion: Developer Experience Is Everyone's Responsibility
My journey with Kubernetes SIG-Multicluster and KServe has helped me understand that improving developer experience is not always easy.
Engineers are busy building and maintaining products. UX designers need time to understand complex developer tools. Organizations must balance product development, budgets, and available resources.
But I also learned that improving developer experience does not always require a large team, a big budget, or a lengthy research project.
Sometimes, meaningful improvements can begin with simple activities:
Ask developers for feedback. Listen to their challenges. Learn from existing GitHub issues. Have short conversations at community events. Document what you discover.
These small efforts can help organizations understand their users and make better decisions.
As technology continues to evolve, especially with AI and cloud-native tools, I believe developer experience should receive continuous attention alongside new feature development.
Building powerful developer tools is important, but making those tools easier to understand, use, and maintain is equally important.
And most importantly, developer experience is not a one-time improvement. It is a continuous journey of listening, learning, and making things better for developers.
These are my personal observations and lessons from working on UX research in the cloud-native open-source community. I would love to hear how other engineers, maintainers, and UX designers approach developer experience improvements in their projects.
What small UX activities have helped your team improve developer experience?
