When I moved from a general UX role into Developer Experience (DevEx) design, I thought the transition would be simple.
Same UX process… just a more technical domain. But my own journey quickly proved otherwise.
I come from an Electronics and Communication Engineering background, which helped me understand systems thinking early on. During my UX journey, I also learned HTML, CSS, and JavaScript, and later worked in a startup where I led both web development and UX efforts. I was involved in everything from planning and design to development and production.
Because of this, I thought I had a strong foundation. But when I stepped into Kubernetes and DevEx… Everything felt wide, complex, and undefined.
Where the Confusion Started
As I began exploring Kubernetes and developer platforms, I realized something:
👉 DevEx is not just UX in a technical space, It's a completely different design problem.
There isn’t a single learning path in DevEx.
Depending on the project, the expectations kept shifting:
- Some required understanding CLI tools
- Others focused on improving documentation UX
- Some needed API-level understanding
- Others required mapping full developer workflows
Even when I started contributing to open source, I struggled with questions like:
- What should I learn first?
- How technical do I need to go?
- Am I even focusing on the right thing?
I initially tried to learn everything — Kubernetes concepts, tools, workflows, GitHub contributions…
That approach didn’t work.
What Changed Everything:
The turning point in my journey came during my first meaningful open-source contribution.
I found a “good first issue” where engineers were struggling with a confusing UI. The interface had multiple repetitive actions represented as buttons, which created usability issues.
At that moment, I realized:
👉 I don’t need to know everything about Kubernetes to contribute
👉 I need to understand just enough to solve the right problem
I focused on:
Understanding the user flow
Identifying UX friction
Collaborating with engineers to explain my solution
That experience helped me bridge UX and developer needs — and more importantly, it reshaped how I approached learning.
Solution: Learn Based on Context, Not Completeness
One of the biggest lessons from my journey is this:
👉 In DevEx, the problem is not lack of learning — it's lack of direction.
Here’s what actually worked:
1. Start with the Developer Workflow
Before learning tools, ask:
- What is the developer trying to do?
- What does success look like?
For example:
- Deploying a model
- Setting up a Kubernetes cluster
This gives clarity on what actually matters.
2. Go Deep Only Where Needed
In my case:
- While exploring Kubernetes → I focused on core concepts + workflows
- During my contribution → I focused on UI/UX clarity
You don’t need everything at once. You need relevance.
3. Learn “Just Enough” Technical Depth
My background helped, but I still had to adjust how I learned:
- Focus on concepts over code
- Understand flows over implementation
- Learn enough to ask better questions
4. Developers as Learning Partners
One of the most underrated accelerators in my journey:
- Asking engineers to walk through real workflows
- Observing how they actually use tools
- Clarifying assumptions early
This not only improved my understanding, it also built trust.
5. Build a System Mental Model
Over time, I stopped thinking in silos like: “CLI vs API vs UI”
Instead, I started seeing:
- How everything connects
- Where developers struggle
- How experiences break across tools
That shift is what truly defines DevEx thinking.
Key Takeaway
My journey into Kubernetes and DevEx taught me something important:
👉 You don’t need to learn everything.
👉 You need to learn what matters for the problem you're solving.
The real skill in DevEx is not technical depth alone, it's knowing where to focus and why.
Top comments (0)