Section: 1 Choosing the Right Project And Where You Can Truly Contribute
Another major challenge in Developer Experience (DevEx) design is choosing where to contribute. In the cloud-native ecosystem, different projects require completely different skills and levels of understanding. For example:
OpenTelemetry → requires knowledge of observability, telemetry data, and sometimes UI dashboards
Kubernetes / multi-cluster systems → involve infrastructure, deployment workflows, and cluster management
Kyverno → focuses on policies, governance, and configuration validation
Cilium → involves networking, security, and low-level system behavior
Why this is challenging
As a UX/DevEx designer, you may struggle with:
- Where should I start?
- Which project matches my current skills?
- Do I need deep technical expertise before contributing?
- What kind of UX problems exist in each domain?
Each area has different types of user problems:
- Observability → understanding data and dashboards
- Infrastructure → complex setup and debugging
- Policy tools → configuration clarity and errors
- Networking → invisible systems and hard-to-debug issues
It’s easy to feel stuck or intimidated, especially at the beginning.
When I started my journey in Developer Experience (DevEx), I made a mistake that slowed down my growth more than anything else:
👉 I chose too many complex projects at the same time.
I was trying to work across multiple domains Kubernetes cluster related problems and networking-heavy systems like Cilium. While these areas are part of the same ecosystem, they require very different types of thinking. The result?
- I felt overwhelmed
- I couldn’t focus deeply
- I struggled to understand problems clearly
- And I couldn’t deliver meaningful outcomes
That experience taught me a critical lesson:
👉 Choosing the right project matters more than choosing the most advanced one.
What I Discovered: Where UX Designers Can Actually Make an Impact
As a UX designer in DevEx, your value is not in mastering the most complex systems first—it’s in identifying where users (developers) struggle the most.
There are several high-impact areas where UX can make a real difference:
1. Documentation Experience (An Underrated Opportunity)
Many people say: “Contribute to documentation.”
But very few explain what that actually means especially from a UX perspective.
Documentation is not just about writing content.
👉 It’s about designing a complete learning and decision making experience for developers.
Where Documentation Breaks (From a UX Perspective)
In many developer tools, documentation has hidden usability gaps:
Broken user flows :Steps are written, but the journey is missing. Developers don’t know what comes next or how steps connect.
Unclear navigation: Important pages are hard to find. Users jump between tabs, GitHub, and docs trying to complete one task.
No real-world context :Docs explain how something works—but not when or why to use it.
Decision-making gaps: Multiple options are listed without guidance, leaving users confused.
A Real Example In platforms like KServe, there are multiple ways to deploy ML models. But the documentation often doesn’t clearly answer:
- Which method is easiest for beginners?
- Which approach is best for production?
- What are the trade-offs between options?
So developers are forced to: Read multiple pages, Watch videos, Experiment through trial and error
👉 This slows them down and increases frustration.
What UX Designers Can Actually Do
This is where UX becomes powerful. You’re not just “improving docs”—you’re reducing cognitive load.
You can:
1. Design Task-Based Flows: Instead of scattered pages, structure documentation around real tasks:“Deploy your first model”, “Which method is use and why and when in real world use-case”, Update with the buttons for easier navigation.
👉 Help users move step-by-step without confusion.
2. Add Decision Guidance Turn choices into clear recommendations:
- “If you are a beginner → use this method”
- “If you need scalability → choose this approach”
👉 This removes guesswork.
3. Improve Navigation & Information Architecture Group related content logically, Add clear entry points (Getting Started, Tutorials, Advanced), Reduce unnecessary jumping between pages
👉 Make information easy to find, not just available.
4. Fill the “Missing Middle” :
Most docs jump from basic → advanced too quickly.
UX can help by adding: Intermediate steps, Visual flows, Real use-case examples
👉 This is where most users actually struggle.
5. Connect UI + Documentation : Many docs are disconnected from the actual product UI.
You can: Map UI screens to documentation steps, Add screenshots or flows, Align terminology between product and docs
👉 This creates a smoother experience.
Why designing the documentation is important: Documentation is often the first experience a developer has with a product.
If it’s confusing: Adoption drops, Frustration increases, Support questions grow
If it’s well-designed: Learning becomes faster, Confidence increases, Products feel easier even if they’re complex.
Key Insight
👉 Great documentation is not written. It’s designed.
And for UX designers entering DevEx, this is one of the highest-impact, lowest-barrier areas to start contributing.
2. Website & Navigation Design
Many developer tools are powerful—but their websites don’t reflect that. Common issues include: Poor navigation, Difficulty finding the right documentation, No task-oriented structure
If you compare:
Cilium → clean UI, consistent design system, strong navigation
Other platforms → minimal UI but lacking usability clarity
👉 This creates opportunities to: Redesign navigation, Improve information architecture, Build consistent design systems
3. Developer Workflows & Tools
Engineers use complex tools every day and small UX improvements can create huge impact.
You can contribute by:
Simplifying workflows : For example - Deploy ML models using Kserve, debugging a multi cluster issue.
Improving dashboards : For example - Observability(improve UI for Prometheus, Grafana)
Making errors easier to understand : For example - Simplified documentation.
Supporting usability studies with better UX insights: For example improve Kserve usability to identify problems who use Kserve.
Even small improvements here can significantly improve productivity.
Section : 2 Expanding Your Impact: Beyond Just One Domain
One of the biggest mindset shifts in my journey was realizing this:
👉 DevEx UX is not limited to a single domain like networking or observability. There are other multiple paths where you can contribute meaningfully based on your interests and strengths.
1. Work Across Different Engineering Roles:
You can align your UX work with different engineering domains, such as:
Platform Engineering → Focus on internal developer platforms, tools, and workflows
DevOps Engineering → Improve CI/CD pipelines, deployment experiences, and operational workflows
Each of these areas comes with its own: Tools, Practices, Pain points
👉 Which means more opportunities to identify user problems and design better solutions.
2. Contribute Beyond Technical Domains
Not all impactful work is tied directly to systems like networking or infrastructure.
There are also initiatives focused on improving the overall developer experience across organizations and communities.
For example:
- Organization-wide developer experience improvements(TAG Developer Experience), TOC - echnical Oversight Committee
- Internal tooling usability
- Cross-team collaboration challenges
These areas focus less on what the system does and more on how people interact with it.
3. Contribute to Community & Experience-Focused Groups
In open-source ecosystems like Kubernetes, there are dedicated groups focused entirely on improving contributor and developer experience.
One great example is: Kubernetes SIG Contributor Experience
This group works on:
- Improving onboarding for new contributors
- Helping teams (SIGs) collaborate effectively
- Identifying challenges contributors face
- Creating better processes and guidance
- Supporting teams in maintaining healthy project structures
👉 Instead of building features, they focus on making it easier for people to contribute and succeed.
Why This Matters : This expands how you think about DevEx UX:
- It’s not just about systems
- It’s not just about UI
- It’s about people, workflows, and collaboration at scale
Key Insight
👉 You can contribute in multiple ways:
- Deep technical domains (like networking, observability)
- Engineering workflows (platform, DevOps)
- Organization-level experience improvements
- Community and contributor experience
You don’t have to choose the hardest path you have to choose where you can create the most impact.
Section: 3 The Real Challenge: How to Choose the Right Project
After struggling early on, I changed my approach completely.
1. Start with the UX Problem (Not the Technology)
Before choosing a project, ask yourself:
- Is this a documentation problem?
- A workflow complexity issue?
- A UI or visualization gap?
- A debugging or error clarity problem?
👉 This helps you align your strengths with real needs.
2. Look for Visible UX Gaps
Some areas are easier to start with:
- Documentation-heavy projects
- Onboarding flows
- Developer workflows
- Github: good first issue-Specially explained UX problem
These provide clear opportunities for UX impact.
3. Collaborate with Engineers
Don’t assume, ask:
- What is hardest to debug?
- What takes the most time?
- Where do new users struggle?
👉 This gives you real insights into developer pain points.
4. Don’t Avoid Complexity Approach It Gradually.
Domains like networking or multi-cluster systems can feel overwhelming at a time. But: You don’t need to understand everything at once, Start from the user perspective, Focus on simplifying one problem at a time, for example understand networking completely then jump into infrastructure.
👉 Your technical understanding will grow naturally over time.
Conclusion:
Choosing a DevEx project is not about picking the most advanced system.
It’s about identifying:
- Where developers struggle the most
- Where UX can bring clarity
- Where you can contribute with your current skills
👉 Start small. Focus on real problems. Grow into complexity step by step.
Top comments (0)