Challenge : 2 The Project Selection Trap

Section: 1 Choosing the Right Project And Where You Can Truly Contribute

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.