DEV Community: Pavanipriya Sajja

Please Engineers share your feedback — It helps products easy to use

Pavanipriya Sajja — Mon, 27 Apr 2026 22:45:34 +0000

Through this article, I will share my real experiences, including the steps, process, and insights that helped me encourage engineers to easily and happily participate in usability 1:1 meetings to improve the KServe experience.

Power of sharing your feedback:

Before we jump in, let’s take a moment to understand the power of feedback.

Imagine you’re booking flight tickets for your entire family with an airline you really like. The overall experience is excellent—you enjoy the journey, there are plenty of entertainment options onboard, and both the complimentary and paid food and beverages are delicious. The airline even offers family-friendly meal options and services throughout the journey. From booking to boarding, everything feels smooth and well-designed. On top of that, they provide lounge access at a much more affordable price compared to other airlines.

However, there’s one issue: the online check-in app doesn’t work. Because of that, you have to check in at the airport, which means standing in long lines and wasting time. It’s frustrating.

Even so, this was just a one-time issue, while the rest of your experience with the airline has consistently been great. Instead of switching to another airline, you might choose to share your feedback so they have a chance to improve.

If you don’t provide feedback, the airline may never know about the issue and won’t get the opportunity to fix it. But if you do share it, they can improve the experience—not just for you, but for many others as well. Over time, this leads to a better product, happier customers, and increased trust in the brand.

That’s the power of feedback.

A single issue like a temporary failure in the online check-in system doesn’t define the entire service. Behind the scenes, engineers and teams are constantly working to build and maintain systems that serve millions of users every day. While mistakes can happen, feedback helps identify and resolve them.

Instead of immediately switching to another airline and going through the effort of adapting to a new experience, simply sharing your feedback can lead to meaningful improvements. The next time you fly, you might find that the issue has been resolved—and your experience is even smoother.

Feedback doesn’t just fix problems—it strengthens experiences.

Number of ways to share your feedback.

There are many ways to share your feedback.

For example, an airline team might call you and ask about your experience. During this phone conversation, you can share your thoughts in detail this is known as an interview in user research.

Sometimes, they may ask you to walk through the online check-in process step by step, possibly over a video call. This allows the UX team to observe how you interact with the system in real time and identify any difficulties or pain points you encounter. This method is called a usability study.

Finally, you might be asked to complete a short form in the application at the end of your journey—usually a 3–5 minute questionnaire about your recent experience. This is known as a survey in user research.

In all these ways, you are given opportunities to share your feedback, helping teams understand your experience and improve their services.

What is usability studies and how it can be conducted?

Let’s learn what usability studies (User research's method) are and how I started a usability study project with K-Serve, which is one of the CNCF incubating projects.

Usability studies are one of the key user research methods used to understand engineers’ challenges in real world workflows. In this approach, engineers on the video call with UX designer or live in person in 1:1 meeting to share their screens and perform tasks such as deploying ML models using K-Serve or walking through how they debug issues.

During these 1:1 meeting, UX designers don’t just listen also they observe. This gives them direct visibility into where friction occurs, which tools or documentation cause confusion, and where workflows break down. These real time observations are critical for identifying gaps that might not surface through interviews or surveys alone.

Based on these 1:1 meeting, UX designers document their findings and create reports that highlight engineers’ pain points, usability issues, and opportunities for improving the overall K-Serve experience.

How to conduct usability studies:

1. Prepare tasks and guidelines for usability studies

In this phase, UX designers prepare what they want to learn from the study.

First, they create a list of tasks for engineers to perform. For example, in KServe, tasks might include: Deploying an ML model, Monitoring ML workloads, Debugging issues

Once the tasks are ready, UX designers prepare follow-up questions. These questions help engineers share more details, such as:

Did you face any problems during this task?
Was anything confusing or difficult?
How do you think this process can be improved?

This gives engineers a chance to share their thoughts and overall experience with K-Serve. Next, UX designers create guidelines for the study. This includes:

Choosing tools for the sessions (for example, Google Meet for 1:1 meetings), Deciding how to handle data (what can be shared publicly and what should stay confidential), Making sure any shared data is anonymous and combined (not personal or raw data), Planning the timeline for sessions and analysis, Deciding where and how to share the final results

These steps help ensure the usability study is well-organized, respectful of participants’ privacy, and useful for improving the product.

2. Participant recruitment planning

In this phase, the UX designer plans how to recruit participants and collect basic information about them.

The UX designer creates a simple survey for engineers to sign up for usability studies. This survey helps gather important details such as:

The engineer’s role and experience
Their availability for a 1:1 session
How they use KServe in their work
The main challenges they are currently facing

This information helps both the UX designer and the engineer save time. The UX designer can understand the participant before the session and prepare better.

For example, if an engineer mentions that they face challenges during deployment, the UX designer can focus on deployment-related tasks during the session.

Overall, this process makes it easier to recruit the right participants and helps the UX designer learn about their challenges in advance, leading to more focused and useful usability studies.

3. During the Usability study 1:1 meeting:

Once the usability session is scheduled, the UX designer observes the tasks the engineer performs and takes notes.

With the engineer’s permission, the UX designer may record the session for study purposes. The recording will not be shared publicly—it will remain confidential and only be used by the UX team and KServe maintainers for research.

At the beginning of the session, the UX designer will ask for consent to record. If an engineer is not comfortable being recorded, that is completely okay—they can still participate and share their experience.

4. Analysis - After the Usability studies:

Once the UX designer completes usability studies with engineers (for example, with more than 10–20 participants), they begin analyzing the data.

The UX designer uses analysis methods such as thematic analysis and pattern identification to find common themes and trends across all sessions. Based on this, they create a report that includes both key insights and metrics.

For example, the report might show that 60% of engineers faced difficulties with the deployment process. A common pattern identified could be configuration complexity.

In this way, the UX designer creates a clear summary of findings without sharing any raw data.

5. Sharing the findings in community meetings for improvements:

Once the UX designer has created the findings report, the results are shared with the KServe community to support improvements.

The insights from the report are discussed in community meetings to help identify what can be improved in K-Serve. In some cases, the findings may also be shared in CNCF KubeCon talks to highlight the challenges engineers face while using K-Serve and to encourage broader discussions and solutions.

This is how usability studies, through these five steps, can have a significant impact by making KServe easier for engineers to use.

Engineer Effort and Real-World Challenges in K-Serve:

K-Serve contributors (engineers) are building tools for other engineers who use K-Serve to deploy and manage ML models. Often, contributors make a plan on the user requirements and begin building the product based on those engineers knows.

Once the product reaches production and more engineers start using K-Serve in real environments, usability challenges begin to surface. As usage increases, engineers start noticing difficulties while working with the system. In my research, I have heard users say that it is “very difficult to use,” “needs to be easier,” or that they are “looking for alternatives,” or "they are trying to figure out which approach that we can began for ML deployment"

However, there is still an opportunity to improve KServe significantly. By observing and listening closely to engineers—especially where they struggle in real workflows, we can identify meaningful usability gaps. Documenting and analyzing these insights can help make K-Serve easier to use for both current users and new engineers who are adopting it for the first time.

Ultimately, this approach ensures that K-Serve evolves based on real user experiences rather than assumptions, making it more usable, accessible, and widely adopted in production environments.

Why engineers hesitate or afraid to share feedback:

Engineers often work within environments that involve sensitive systems, production constraints, and organizational policies. Because of this, they may hesitate to participate in UX research (Usability studies), assuming it requires sharing confidential or restricted information.

However, UX research does not focus on internal data, architecture details, or anything proprietary. Instead, it focuses on the engineer’s experience and their workflows, challenges, and friction points.

This includes:

Where workflows slow down
What feels overly complex or unclear
What takes too long to configure, deploy, or debug
What drives engineers to avoid certain features or switch tools

For example, when engineers use KServe in production, they may encounter challenges in deployment, configuration, or maintenance. These challenges can increase cognitive load and make the system feel overwhelming. Importantly, sharing these experiences does not require revealing any confidential information only the difficulties encountered during usage.

When such feedback is not shared, these issues often remain unresolved. Over time, this can lead engineers to seek alternative tools that are easier to use.

On the other hand, when engineers provide even high-level feedback, it creates meaningful impact:

It reduces cognitive load across workflows
It improves existing tools and platforms
It simplifies onboarding for new engineers
It increases overall adoption within the engineering community

UX research, in this context, becomes a way for engineers to contribute beyond code by sharing their experiences to improve the ecosystem.

Even simple insights, such as "This step was confusing" or "This process took longer than expected" can directly influence product improvements.

Ultimately, participation in UX research helps create better tools for engineers, by engineers without requiring any compromise on confidentiality.

Increase participation in usability studies:

To increase participation in usability studies, we started reaching out directly to the community. we sent messages to more than 1,000 members in Slack threads across the KServe community channel and contributor channel. we also reached out to other CNCF platforms like Kubeflow, since many of them use KServe for model serving.

To further increase reach and participation, we also started posting on LinkedIn to engage a wider audience and encourage more engineers to join the usability studies.

We are still working on usability studies to understand the challenges engineers face while using KServe. In a future article, we will share the analysis process and the results we gather from these studies.

Takeways:

It’s completely understandable that screen sharing and recordings during usability studies can feel sensitive or confidential. If you are not comfortable sharing certain information, there are still many flexible ways to participate and give feedback.

For example, if something confidential comes up during the session, you can ask the UX designer to pause the recording and then share your feedback. You can also choose to participate without any recording at all and still explain your experience. The UX designer will take notes and capture the key issues you mention.

If you don’t have much time, you can let the UX designer know in advance. For instance, you can say you only have 10–15 minutes to try a task like deploying a model and want to quickly share the challenges you face. You can also join a short discussion or share your feedback through a survey by listing the main issues you are experiencing.

In this way, your feedback can still help improve KServe usability in a way that fits your comfort and availability.

Final thoughts:

Usability studies create a strong feedback loop between engineers and UX researchers.

They help to:

Identify real-world challenges
Improve developer experience
Strengthen tools like KServe
Build systems based on actual usage, not assumptions

Most importantly, feedback turns individual experiences into shared improvements. Even small input from engineers can meaningfully shape the future of the platform.

Design Systems : How They Shape Developer Experience in Modern Product Building

Pavanipriya Sajja — Mon, 27 Apr 2026 17:09:46 +0000

When I first started discussing and presenting system design concepts for one of my UX projects, many engineers on my team were surprised. Initially, they seemed confused about why I was explaining this information under the “design system” title.

This reaction made me reflect. After the meeting, I asked one of the engineers why there was confusion when I referred to “system design.” The developer explained that system design means something quite different in engineering compared to how it’s often interpreted in UX.

That conversation led me to explore the topic further. I began researching to better understand what “system design” actually means from both a developer’s perspective and a UX perspective especially when you are working on developer experience platform.

As a result, I’m writing this article to clarify the differences between system-level design in UX and system design in engineering.

Let’s start with system design from a developer’s point of view:

System Design in developer's point of view

System design is the process of defining the architecture, infrastructure, data flow, and communication patterns of a software system. It is the technical blueprint that determines how a system is built, scaled, and maintained to meet both functional requirements and non-functional requirements like performance, reliability, and security.

Why is it Important to Consider?

System design plays a critical role in building reliable and scalable systems by addressing key challenges early in the development process.

It helps prevent costly architectural mistakes before they escalate into production crises, while ensuring the system can scale smoothly as user demand increases.

A well thought out system design also defines how the system behaves under failure conditions, reducing the risk of outages and improving overall resilience. Additionally, it aligns engineering decisions with business requirements such as SLAs, latency targets, and throughput expectations.

By establishing clear patterns and boundaries from the beginning, system design ultimately minimizes technical debt and creates a strong foundation for long-term system stability and growth.

How Will it Be Useful?

System design provides engineering teams with a clear technical roadmap before any code is written, creating a shared understanding of how the system should be built.

It reduces ambiguity in critical architectural decisions such as database selection, API design, and caching strategies, allowing teams to move forward with confidence.

By thinking through the system early, teams can anticipate potential bottlenecks, failure points, and scaling challenges in advance. It also enables faster onboarding of new engineers by offering clear documentation of the system architecture.

Ultimately, strong system design supports the long-term operability and maintainability of complex systems, making them easier to evolve and manage over time.

When Can You Use it in Projects?

System design becomes especially important at key moments in a product’s lifecycle. It plays a crucial role at the start of any new product or platform, before major architectural decisions are made, helping teams establish a solid foundation.

It is equally valuable when scaling an existing system that is reaching its performance or reliability limits, as it guides necessary improvements.

During transitions, such as migrating from a monolith to a micro-services architecture, system design provides structure and direction. It also supports onboarding new engineering teams by offering clear architectural context, and it helps organizations prepare their infrastructure for high-traffic events or rapid user growth, ensuring the system can handle increased demand effectively.

If You Learn Design Systems, What Impact Can You Make?

Strong system design enables engineers to build systems that are resilient, scalable, and production-ready from day one. It empowers them to influence critical infrastructure decisions that can impact millions of users, while also reducing friction within engineering teams by establishing clear and reusable architectural patterns. Beyond technical outcomes, it helps individuals build credibility as senior technical voices in cross-functional product discussions. At the same time, it fosters a culture of incident prevention by encouraging proactive thinking around failure scenarios and system reliability.

What Kind of Projects Can You Work On?

System design is especially critical in complex and high-impact environments where reliability and scalability are non-negotiable. It plays a key role in large-scale distributed systems such as e-commerce platforms, streaming services, and fintech applications, where millions of users depend on consistent performance.

It is equally important in cloud-native and Kubernetes-based infrastructure platforms, where systems must be dynamic and resilient by design. In real-time systems like messaging apps or trading platforms, system design ensures low latency and high responsiveness.

It also supports multi-region, globally distributed applications by enabling seamless operation across geographies. Additionally, system design is foundational for developer platforms, internal tooling, and API-first products, where clarity, consistency, and scalability directly impact developer experience and productivity.

Examples of Design Systems (Developer / System Architecture):

Examples of system design in real-world applications highlight how leading technology companies architect their platforms for scale and resilience.

Netflix: Microservices + chaos engineering for resilience
Uber: Real-time geolocation with event-driven architecture
Airbnb: Search ranking with distributed caching at scale
Twitter/X: Fan-out on write for timeline delivery at massive scale
WhatsApp: Handling billions of messages with minimal infrastructure, showcasing extreme efficiency in system design.

Here is the example of the Uber system architecture and you can learn more from this blog: Link

Core Concepts of Design Systems:

System design is built on several key components that ensure a system can operate efficiently at scale.

Scalability — horizontal and vertical scaling strategies for handling user growth.
Availability & Reliability — redundancy, failover, and uptime guarantees
Data Storage — relational, NoSQL, time-series, and blob storage trade-offs
APIs & Communication — REST, gRPC, GraphQL, and event-driven messaging patterns
Caching — Redis, CDN, and in-memory strategies for reducing load
Load Balancing — distributing traffic to eliminate single points of failure
Observability — logging, metrics, and distributed tracing as architectural requirements

What is the Mental Model?

A developer’s mental model for system design is centered on asking the right questions before building anything. They begin by identifying both functional and non-functional requirements to understand what the system must do and how well it should perform.

They then consider the read/write ratio to determine how it will influence data storage and access patterns. From there, they analyze potential bottlenecks across the system—whether in the database, network, or compute layer—to anticipate performance constraints.

Developers also think critically about failure scenarios, defining what can go wrong and establishing clear recovery paths. Finally, they focus on how the system will be observed and maintained in production, ensuring there are robust mechanisms for monitoring, debugging, and continuous improvement.

📚 Developer System Design Resources with Links:

1. Designing Data-Intensive Applications — Martin Kleppmann
The definitive book on distributed systems, databases, and data architecture trade-offs.

Official book site → dataintensive.net

2. System Design Primer — GitHub
Free, open source, comprehensive study guide covering everything from basics to advanced system design interviews. Github Link

3. ByteByteGo — Alex Xu
Visual, beginner-friendly system design explanations covering real-world architectures like Netflix, Uber, and Twitter. Website Link

4. Cloud Architecture Centers
Official cloud-native design pattern libraries from the three major cloud providers. AWS Architecture Center Link, Google Cloud and Microsoft Azure.

5. High Scalability
Real-world architecture case studies from companies like YouTube, Netflix, WhatsApp, and more. Website link

6. CNCF Landscape

The complete cloud native ecosystem reference — tools, projects, and categories across the entire CNCF landscape. link

Key insights : The most powerful insight in system design is that the cost of a wrong architectural decision compounds exponentially over time — a trade-off made poorly at the design phase can take years and millions of dollars to unwind at scale.

Developers who internalize the mental model of asking the right questions before writing a single line of code become the engineers who build systems that not only work today but endure, scale, and recover gracefully for years to come.

Now let's move on to UX designer perspective design system.

Design system in UX Designers point of view:

A design system is a centralized collection of reusable UI components, design tokens, interaction patterns, typography, color palettes, spacing rules, and guidelines that ensure visual and experiential consistency across an entire product. It is the single source of truth for how a product looks, feels, and behaves from the user's point of view.

Why is it Important to Consider?

A well-designed system ensures consistency across every screen and touchpoint a user interacts with, creating a unified experience throughout the product. It embeds accessibility and inclusivity standards directly at the component level, rather than treating them as an afterthought in the design process.

By standardizing patterns and decisions, it reduces design debt by eliminating repeated and inconsistent UI choices over time. It also creates a shared language between designers, developers, and product teams, enabling better collaboration and alignment. Ultimately, it builds user trust by delivering predictable and coherent experiences that feel familiar and reliable across the entire system.

How Will it Be Useful?

A design system significantly speeds up the design workflow by providing ready-to-use, tested components that reduce the need to build interfaces from scratch.

It helps bridge the gap between design and engineering by establishing a shared component language that both teams can understand and use consistently.

This allows designers to focus more on solving complex user problems rather than repeatedly recreating basic UI elements. It also enables rapid prototyping and smoother, more consistent design handoffs between teams. Additionally, when a single component is updated, the improvement can instantly propagate across every product surface, ensuring consistency and efficiency at scale.

When Can You Use it in Projects?

A design system becomes especially important in several key scenarios within product development. It is essential when building a multi-product ecosystem that requires a consistent UI across different surfaces to maintain a unified user experience.

It is also valuable when a team is scaling and multiple designers are working in parallel, ensuring alignment and reducing inconsistencies. When the design-to-development handoff becomes slow, inconsistent, or error-prone, a design system helps streamline collaboration and improve accuracy.

It is equally important when a product has matured enough to require standardization of its UI language for better coherence and maintainability. Finally, it plays a critical role when accessibility needs to be systematically enforced across the product, ensuring inclusive design is built into every component from the start.

If You Learn Design Systems, What Impact Can You Make?

A well-established design system helps elevate product quality and maintain brand consistency at scale across every user touchpoint. It positions designers as strategic contributors who shape product direction, rather than focusing only on individual screens.

By removing repetitive design decisions from the workflow, it enables faster and more efficient product delivery. It also supports the systematic adoption of accessibility and inclusive design practices across the organization, ensuring these principles are embedded throughout the product.

In addition, it acts as a bridge between design vision and engineering execution, helping both teams stay aligned from concept to implementation.

What Kind of Projects Can You Work On?

Design systems are especially valuable in enterprise SaaS product design, where interfaces are often complex and must support multiple user roles with different needs and permissions.

They are also critical in the creation and governance of design systems within large product organizations, ensuring consistency, scalability, and long-term maintainability across teams. In developer tools and platform UI, where precision, information density, and efficiency are essential, design systems help maintain clarity and usability.

They are equally important in mobile and cross-platform product design, where consistent component behavior is needed across different devices and environments. Additionally, design systems play a key role in open source contributions such as Material Design, Carbon Design System, and Atlassian Design System, which help standardize and scale design practices across the broader industry.
You can explore the Open MRS website and their applications are using the Carbon design system to make consistent products among the OpenMRS platform.

Examples of Design Systems:

Material Design : Google - Comprehensive motion and component guidelines
Carbon Design System : IBM - Enterprise accessibility and data-heavy UIs
Atlassian Design System : Atlassian - Developer tool UI patterns
Fluent UI : Microsoft - Cross-platform consistency across Office products
Polaris: Shopify - E-commerce focused UX patterns
Lightning Design System : Salesforce Enterprise CRM - UI standards

Core Concepts of Design Systems

Design Tokens — the atomic values of color, spacing, typography, and elevation that feed every component

Component Library — reusable UI building blocks like buttons, modals, forms, and navigation patterns

Pattern Library — documented solutions to recurring UX problems like empty states, error handling, onboarding flows.

Accessibility Standards — WCAG compliance baked into every component by default
Governance Model — who owns, contributes to, and maintains the system over time
Documentation — the living guide that explains when and how to use every element.

What is the Mental Model?

A UX designer approaches a design system by asking:

What experience are we creating, and for whom?
What are the most repeated UI patterns that need standardization?
How do we ensure every component is accessible and inclusive by default?
How does this component behave across different screen sizes and contexts?
How do we govern and evolve this system as the product grows?

UX Design System Resources

Google material design — Material Design documentation and guidelines
carbondesignsystem.com — IBM Carbon full documentation
atlassian.design — Atlassian design system patterns
designsystemsrepo.com — curated directory of public design systems
Figma Community — open design system files and UI kits
Storybook.js.org — tool for building and documenting component libraries

Key insights: A design system is never truly finished — it is a living product that grows with the organization, and the designers who treat it as such become the architects of consistent, trustworthy user experiences at scale.

The deepest insight is that a design system is not about restricting creativity; it is about liberating designers to focus on the problems that truly require human judgment, while the system handles the repetitive decisions that slow teams down.

Conclusion:

In such a way when you are working with the developer experience domain to understand what design system that discussing in the meetings. That could help you understand what design system the team is talking about and what design system decisions are making as per the requirements.

From a developer’s perspective, a design system is often discussed and defined before development begins—it helps set the foundation for how things will be built.

From a UX perspective, a design system typically evolves during the product-building phase, especially after research is completed, to ensure the experience is grounded in real user needs.

At the end, both perspectives play a critical role in product development.

Whether you’re designing the experience a user sees or the infrastructure that powers it, both disciplines share the same fundamental truth: great systems are built on intentional decisions, not accidental ones.

UX thinking and developer system thinking are two sides of the same coin. Teams that bring both perspectives together build products that are not only technically sound but also genuinely human.

I believe this explanation on differentiation about design system point of developer's and UX is different but these both are very important while building the real products.

🚀 “𝗗𝗲𝘀𝗶𝗴𝗻𝗶𝗻𝗴 𝗳𝗼𝗿 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗶𝘀 𝗻𝗼𝘁 𝗷𝘂𝘀𝘁 𝗨𝗫—𝗶𝘁’𝘀 𝘀𝘆𝘀𝘁𝗲𝗺 𝘁𝗵𝗶𝗻𝗸𝗶𝗻𝗴.” 👉 DevEx Design Challenges Series — Now Complete: https://dev.to/priya_sajja_c336921bbda87/series/38724

Pavanipriya Sajja — Sat, 25 Apr 2026 00:14:44 +0000

Developer Experience designer challenges & Solutions Series' Articles - DEV Community

View Developer Experience designer challenges & Solutions Series' Articles on DEV Community

dev.to

Challenge : 4 System-Level Challenges in Developer Experience (DevEx) Design

Pavanipriya Sajja — Tue, 21 Apr 2026 23:30:22 +0000

One of the most critical challenges in Developer Experience (DevEx) design is operating at the system level rather than the interface level. DevEx is not simply UX applied to a technical domain—it requires designing across a distributed ecosystem of tools, infrastructure, and workflows.

Unlike traditional UX, where the focus is a single product or interface, DevEx involves understanding how developers interact with an entire toolchain. For example, when designing for Kubernetes, the scope extends beyond a single UI or feature. It includes CLI tools, infrastructure configurations, CI/CD pipelines, and collaboration patterns across teams.

Engineers typically work in fragmented, non-linear workflows—switching between tools, environments (cloud, on-prem, multi-cluster), and communication channels. This constant context switching increases cognitive load and makes it difficult to design seamless experiences.

The core challenge, therefore, is not just improving individual touch points, but understanding and optimizing the end-to-end system. Effective DevEx design requires system-level thinking to reduce fragmentation, improve interoperability, and create cohesive workflows for engineers.

In this article, I’ll break down these system-level challenges into five key areas, using a hybrid engineer persona operating in a multi-cluster environment as a reference.

1. Invisible User Journeys:

In traditional UX domains such as designing a hospital digital ecosystem the user journeys or workflows are relatively deterministic and well-defined. For example, a public facing hospital website typically follows a structured information architecture: organizational overview, service catalog, provider directory, and contact endpoints. This often extends into a patient portal, which introduces authenticated workflows such as appointment scheduling, access to electronic health records (EHR), diagnostic results, and medication management.

From a system design standpoint, these two surfaces (marketing website and patient portal) are loosely coupled but clearly integrated via identity, routing, and backend services. The interaction model is predictable, state transitions are well understood, and user flows can be explicitly mapped end-to-end.

However, when designing UX for developer platforms particularly in complex domains like multi-cluster infrastructure the concept of a “user journey (Engineer Workflows)” becomes significantly more abstract and non-deterministic.

Developer workflows are shaped by infrastructure topology, organizational constraints, and tooling ecosystems. Consider the variability across multi-cluster environments:

A platform engineer deploying Kubernetes clusters across multi-cloud environments (e.g., AWS, Azure, GCP).
An enterprise engineer managing strictly on-premises clusters due to compliance requirements.
Edge engineers deploying lightweight clusters across distributed edge locations.
Hybrid setups combining on-prem + cloud + edge infrastructure.

Each of these scenarios introduces different constraints around networking, identity, observability, and lifecycle management. Additionally, tooling fragmentation further diversifies workflows.

For example:

Teams using Rancher for centralized cluster management
Organizations leveraging Azure Arc for unified control planes
Developers interacting with clusters via Headlamp
Internal platforms built on top of custom abstractions and proprietary orchestration layers

Two engineers solving the same problem (e.g., cluster deployment or debugging) may follow completely different paths using different tools, scripts, or automation pipelines.

Why These Are “Invisible Journeys (Invisible workflows)”

Unlike traditional UX flows, developer journeys exhibit the following characteristics:

Non-linear execution paths: Tasks such as cluster provisioning, scaling, or debugging do not follow a fixed sequence. They depend on runtime context, failures, and system state.
High degree of personalization: Developers create scripts, CLIs, and automation pipelines tailored to their workflows. Two engineers solving the same problem (e.g., cluster autoscaling) may use entirely different approaches.
Toolchain-driven interactions: The “interface” is often not a single UI but a combination of CLI tools, YAML configurations, APIs, CI/CD pipelines, and observability dashboards.
Low visibility into real behavior: Much of the workflow happens outside observable UI layers—in terminal sessions, scripts, or internal tools—making it difficult to capture through traditional UX methods.

Core UX Challenge

You cannot rely solely on predefined user flows, wireframes, or static journey maps. Instead, designing for developer platforms requires:

Modeling workflow variability rather than enforcing a single “happy path”
Understanding environment-specific constraints (cloud, on-prem, edge)
Capturing real-world behaviors through contextual inquiry, shadowing, and telemetry
Designing for composability and extensibility rather than rigid interfaces

Key Insight

In developer focused systems, the “user journey” is not a fixed path—it is an emergent property of: Infrastructure architecture, Tooling ecosystem, Organizational practices

This is why these journeys are often invisible, they exist across fragmented systems and only become apparent through deep, context-rich research.

2. Designing for Systems, Not Screens:

This section draws from hands on work within the Kubernetes multi-cluster research space, where the core challenge was not UI design, but modeling end-to-end developer workflows across heterogeneous environments.

During research synthesis, I constructed a hybrid engineer persona based on raw qualitative and behavioral data. The analysis revealed that multi-cluster operations do not follow a single deterministic workflow. Instead, engineers operate across three primary workflow paradigms:

Manual-first workflows: high cognitive control, low automation dependency
Hybrid workflows (automation + manual overrides): balanced control with selective automation
Automation-first workflows (AI-assisted or fully automated): minimal manual intervention, high system trust

Each category introduced distinct tooling expectations and system constraints. For example:

Some engineers required AI-augmented observability and decision support embedded into existing toolchains. Others preferred standalone orchestration platforms for multi-cluster lifecycle management. Enterprise-scale environments imposed organizational constraints, such as security policies, internal platform dependencies, and legacy integrations. Toolchains varied significantly, including internal systems, open-source ecosystems, and custom scripts.

As a result, the research surfaced 10+ distinct workflow variants, each representing different combinations of:

cluster management strategies, observability patterns, deployment models, organizational constraints

This complexity makes it clear that designing a single multi-cluster UI is insufficient. The problem space requires system-level design thinking, where the goal is to support workflow continuity across tools, not optimize isolated interfaces.

System-Level Nature of DevEx: In Developer Experience (DevEx), workflows are inherently distributed across multiple touch points, not confined to a single interface. A typical developer journey may span: Documentation systems, CLI environments, Logging and observability platforms, Monitoring dashboards, Issue tracking systems like GitHub

The “interface” is effectively the entire ecosystem.

Core Challenge

You are not designing a screen, you are designing interoperability across a fragmented system.

A failure in any single component such as ambiguous documentation, inconsistent CLI behavior, or poor observability signals can propagate and break the entire workflow chain.

This is why DevEx design requires:

Deep system awareness (APIs, pipelines, infra constraints)
Workflow orchestration thinking, not just UI optimization
Alignment across tools, teams, and environments

The outcome is not a better screen, it is a cohesive, resilient developer workflow system.

3. System Constraints Drive Design Decisions(Not Just UX)

In distributed systems especially multi-cluster platforms design decisions are rarely driven by UX alone. They are tightly coupled with underlying system architecture and operational realities.

For example, in a multi-cluster environment (e.g., orchestrated via Kubernetes), engineers often decompose applications (such as e-commerce systems) into micro services and deploy them across multiple clusters. These placement decisions are influenced by:

Workload distribution strategies (latency, failover, cost optimization)
Cluster topology (cloud, on-prem, edge)
Service-to-service dependencies
Data locality and compliance requirements

As a result, the UI/UX of a multi-cluster management tool must reflect this complexity rather than abstract it away entirely. Technical Dependencies That Shape UX

Design is constrained by several non-negotiable system factors:

Backend Architecture: Microservices, service meshes (e.g., Istio), and distributed data stores dictate how information can be surfaced and interacted with.
APIs and Contracts: UX is bounded by available APIs (e.g., Kubernetes API). Limitations in API granularity, latency, or consistency directly impact what the interface can support.
Infrastructure Constraints: Resource quotas, network policies, and cluster heterogeneity (multi-cloud + on-prem + edge) influence both system behavior and UI responsiveness.
Open Source Ecosystem Constraints: Many platforms depend on upstream tools and CRDs (Custom Resource Definitions). Design must align with their capabilities and limitations rather than reinvent abstractions.

The Core Challenge

Even when research clearly identifies a more intuitive or efficient user experience, it may not be immediately implementable due to these constraints.

This creates a fundamental tension such as UX wants simplicity and clarity, Systems introduce complexity and trade-offs.

What This Requires from UX

Designing in this space means operating with a systems mindset:

Understand Technical Trade-offs: Evaluate latency vs. consistency, abstraction vs. control, and flexibility vs. complexity.
Collaborate Deeply with Engineers: UX decisions must be co-designed with backend and platform engineers, not handed off after the fact.
Design Within Constraints

The goal is not to ignore constraints but to make them visible, understandable, and manageable for users.

In highly technical domains like multi cluster systems, good UX is not about removing complexity. it’s about structuring and exposing it in a way that aligns with how engineers actually reason about distributed systems.

Additional Context: Platform & Ecosystem Constraints

Constraints are not only technical they are also platform and ecosystem driven.

In platforms like Rancher, any new feature or plugin must align with Rancher’s architecture, permission model, and extension framework. Even if a UX problem is identified, the solution must stay within what the platform allows. Similarly, when building plugins in tools like Headlamp for ecosystems such as K-native, teams must account for: K-native APIs and resource models, Compatibility constraints, Extension boundaries and lifecycle

While some tools (like Headlamp) offer more flexibility, they still need to respect the constraints imposed by the target ecosystem (e.g., K- native).

Key takeaway:

Even extensibility (plugins, integrations) operates within strict boundaries, UX solutions must align with platform permissions, APIs, and ecosystem rules before they can become usable reality.

4. Consistency across a distributed ecosystem :

Consistency across a distributed ecosystem is one of the most complex challenges in Developer Experience (DevEx) design. In modern systems, development responsibilities are inherently fragmented: one developer may focus on API design, another on backend services, another on frontend integration, while others handle database architecture or CI/CD pipelines. In parallel, especially in open-source or cloud-native ecosystems, different communities may own different domains—for example, one group concentrating on core multi-cluster operations such as deployment, while another focuses on multi-cluster networking.

This distribution of ownership introduces structural misalignment. In DevEx, the overall experience is not controlled by a single team but is instead shaped by multiple teams, contributors, and sometimes independent communities. As a result, inconsistencies naturally emerge, terminology may vary across components, interaction patterns may differ between tools, and documentation often becomes fragmented or siloed.

The core challenge, therefore, is maintaining a coherent and consistent experience across this decentralized system. Achieving this requires not just strong communication, but also shared standards, aligned mental models, and deliberate design governance to ensure that, despite the distributed nature of development, the end-to-end experience feels unified to the user.

5. Unified experience & Thinking Beyond Features:

In Developer Experience (DevEx), the product experience is not centered around the UI alone, unlike traditional software products. Instead, it is a composite experience formed by documentation, CLI tools, APIs, and UI dashboards working together as a unified system.

Designing for DevEx requires treating these elements as interconnected surfaces rather than isolated components, where each one supports and reinforces the others to enable a seamless workflow.

The core challenge lies in ensuring strong cohesion between them—how documentation guides CLI usage, how APIs are reflected in both CLI commands and UI actions, and how UI dashboards surface and simplify underlying system operations.

For instance, if the documentation is unclear or incomplete, even a well-designed UI becomes difficult to use effectively because developers rely on documentation and CLI workflows to understand system behavior and operational intent.

In traditional UX design, success is often measured by how well individual features, screens, and user flows are designed and visually presented. The focus tends to remain on isolated interactions and how each feature appears and behaves within a defined interface. However, in Developer Experience (DevEx), the emphasis shifts away from feature centric thinking toward the efficiency of end-to-end workflows.

What matters more is how quickly developers can complete tasks, how smoothly they can move across tools and systems, and how much cognitive effort is required to understand and operate the environment.

In this context, success is not defined by the quality of a single screen or feature, but by the overall flow across documentation, CLI, APIs, and UI working together.

The key challenge is to move beyond asking “How does this feature look?” and instead evaluate “How does this entire workflow feel and perform in real usage?”

Conclusion:

The key takeaway is that DevEx UX goes far beyond improving individual interfaces; it is fundamentally about improving entire systems of work. Instead of focusing on isolated UI enhancements, the emphasis shifts toward understanding and optimizing how developers interact with interconnected tools, processes, and platforms across the full lifecycle of software delivery.

This requires strong systems thinking to see how components like APIs, CLI tools, documentation, and UI dashboards influence one another, along with technical awareness to understand how these systems actually behave in practice. It also demands a deep understanding of developer workflows, including how tasks are executed end-to-end and where friction typically occurs. When approached this way, the role of a UX practitioner evolves from being a traditional UX designer focused on interface design to becoming an experience strategist who shapes and aligns complex technical ecosystems for efficiency, clarity, and scalability.

Challenge: 3 Making UX Work Understandable to Engineers

Pavanipriya Sajja — Mon, 20 Apr 2026 22:25:20 +0000

I want to explain this challenge through a real experience I had while working on improving the developer experience for KServe.

Because this is where I truly understood:

👉 UX work doesn’t fail because of bad research.
👉 It fails when developers don’t understand it fast enough to care.

The Situation:

We set out to improve usability for developers using KServe, specifically focusing on how they deploy ML models, manage inference services, and work within Kubernetes-based workflows. As a UX team, we took a structured approach: we conducted a usability study, designed task-based scenarios, and collected feedback from real engineers to anchor our decisions in actual developer needs. We even received approval from maintainers, and everything seemed solid in theory. But when it came time to present this work to developers… we struggled.

What Actually Happened:

In one of our community interactions, we presented a set of usability tasks, our research approach, and what we wanted developers to do. From a UX perspective, everything felt clear and well-structured but from a developer’s perspective, it wasn’t landing the same way. The reaction was subtle but telling: people didn’t ask many questions, feedback was minimal, and engagement was low. At first, it was easy to assume, “maybe people are just busy.” But looking deeper, the real issue became clear: we hadn’t explained the work in a way that aligned with how developers think.

Where We Went Wrong:

1. We presented too much information at once

Including multiple tasks, long end-to-end flows, and heavy contextual details. From our side, it felt like organized research with clear structure, but from the developer’s perspective, it came across very differently. It felt like: “This will take time. I’ll come back later.” And in real developer workflows, “later” often turns into never, which meant the key message and intent were easily lost in the volume.

2. We Used UX Framing Instead of Developer Framing:

We used UX framing instead of developer framing when explaining the work. We described it in terms of “usability study,” “user tasks,” and “feedback collection.” From our perspective, this language was standard and clear but developers interpreted it very differently. They were instead thinking: “What exactly do you want me to test?” “How long will this take?” and “What part of KServe is actually broken?” The gap wasn’t in the research itself, but in the fact that we didn’t clearly answer the practical, implementation focused questions developers needed upfront.

3. We Didn’t Anchor to Real Workflows:

We were talking about tasks in general, without clearly anchoring them in real developer actions. Instead of connecting them directly to things like deploying a model, defining Kubernetes manifests, or troubleshooting inference latency and failures, the examples stayed too abstract. As a result, the link to their day to day workflow was weak and not immediately obvious, making it harder for developers to see how the work applied to what they actually do.

The Turning Point:

After seeing low engagement, we changed our approach completely. Instead of trying to “present UX properly,” we asked:

👉 “How can we make this feel like a small, real developer task?”

What We Changed (And Why It Worked):

1. One Task at a Time:

We shifted to a one-task-at-a-time approach instead of sharing everything at once. Rather than overwhelming engineers with a full set of activities, we started sending one small, focused task per engineer. For example: try a specific setup step, tell us where you get stuck, and share what feels confusing during the process.

This approach worked because it reduced time commitment, made the request feel actionable, and fit naturally into their existing workflow. Instead of feeling like a large study or formal exercise, the task now felt simple and approachable like: “I can quickly try this.”

2. Short, Direct Communication (Often via DM)

We shifted to short, direct communication (often via DM) instead of relying only on meetings. Rather than scheduling long discussions, we reached out to engineers individually, sent simple, step-by-step instructions, and asked focused, specific questions. This approach changed the response rate significantly because it better matched how developers prefer to work. Developers tend to favor asynchronous communication, clear and explicit asks, and minimal overhead, so reducing friction made it much easier for them to respond and engage.

3. We Stopped Explaining “UX” — and Started Showing Friction

We stopped explaining “UX” in abstract terms and started showing real friction instead. Instead of saying, “We are conducting a usability study,” we shifted to something more direct and anchored in actual behavior: “We noticed developers get stuck during this step , can you try it and confirm?”

That small shift made a big difference because it made the problem real, made it relevant to their experience, and made it easier to respond without extra context or effort.

4. Strong Documentation Built Trust:

Once we started getting feedback, the next challenge emerged: “How did you reach these conclusions?” To address this, we improved how we documented our findings, focusing on clearly capturing what we observed, the patterns across users, the common failure points, and how the insights were derived. We made the reasoning explicit by showing a clear flow: Raw feedback → Patterns → Insight → Recommendation. This step became especially important because developers don’t just accept results at face value—they want to trace the logic and understand how each conclusion was formed. Present the documentation along with the presentation or part of the results that explains how did you reach these conclusions.

5. Repeating in Community Meetings:

Another important learning came from repeating in community meetings. In environments like KServe, not everyone attends every meeting and the context resets frequently, which means people often miss earlier explanations. To address this, we re-presented the work multiple times, explained it again across different sessions, and shared updates incrementally over time.

At first, this approach felt repetitive, but it turned out to be essential. In reality, it significantly improved awareness, increased participation, and built stronger trust within the community.

A Simple Question That Changed My Entire Feedback Strategy:

One moment really changed how I think about presenting UX work. I was in a developer team meeting where I presented a persona, and at the end, I simply asked: “Can I get your feedback?” The response I received was unexpected: “What feedback do you want from us?”
That question caught me off guard. From my perspective, I had explained the work, walked through the persona, and assumed it was obvious what kind of input I needed. But from their perspective, it wasn’t clear at all they needed more specific context and direction on what to focus on.

I was presenting in the same way I typically do in UX-focused meetings, assuming the format would translate. But developers don’t think in the same way, and they don’t automatically understand what a persona is, why it matters, or what kind of feedback is expected from them.
So when I asked for “feedback,” it was too vague and open-ended. And that’s exactly why the response came back as: “What exactly do you want from us?”

After that experience, I changed how I structured my presentation approach. Instead of jumping straight into the persona, I began explaining it step by step, starting with the fundamentals. I now start with the basics (very important)—clearly outlining what a persona is, why we are creating it, and how it will be used in the context of the work. Then present the process of persona creation form the research data and finally explain the actual persona that you created form the raw data.

For example, I created a persona of a hybrid engineer who deploys clusters across multi-cloud, on-prem, and edge environments.

When presenting this persona in a meeting, you can ask for feedback like this:

“If you are an engineer deploying clusters across cloud, on-prem, and edge environments, does this persona reflect your problems, goals, workflows, and tools?”

You can also ask:

“Does this persona represent your day-to-day tasks as a hybrid engineer, or is something missing?”

“Do these goals and pain points resonate with your experience?”

“Is there anything that doesn’t match your workflow or feels completely different?”

Based on their feedback, you can refine the persona by adding missing tasks, adjusting goals, or removing elements that don’t align with real-world workflows.

What Changed After This: Once I started asking specific, targeted questions, things began to shift. Developers responded more frequently, feedback became more detailed, and conversations turned more meaningful and insightful.

Instead of silence, I started hearing responses like: “This part is correct, but we also struggle with…”, “We don’t use this tool—we use something else,” and “This step is missing in real workflows.”

Key insight: The problem wasn’t that developers didn’t want to give feedback—it was that I didn’t clearly ask for the right kind of feedback.

When you explain the context, show your process, and ask specific, targeted questions, developers know exactly how to respond. And that’s when UX feedback actually starts working.

What Changed After This:

Once we adapted to developer behavior, the quality of interaction changed noticeably. Feedback became more specific, engineers engaged more actively, and conversations became deeper and more meaningful. Instead of silence or minimal responses, we started hearing things like: “Yeah, this step is confusing because…”, “I had to check another doc for this”, and “This part could be simplified.”

That’s when it became clear: 👉 the UX work itself didn’t change — the way we communicated it did.

The Real Insight:

This experience completely changed how I think about presenting UX in DevEx. It’s not about having perfect slides, using heavy UX terminology, or relying on structured frameworks. Instead, it’s about something much more practical and aligned with the audience.

👉 It’s about making your work feel like part of a developer’s workflow

Conclusion:

If developers don’t understand your UX work, it’s not because they don’t care—it’s usually because it doesn’t fit their mental model, doesn’t align with their workflow, or feels too heavy and abstract to act on.

But when you break things into small tasks, show real friction points, speak in terms of their actual work, and provide traceable logic behind decisions, something shifts.

UX stops being seen as “design work”… and starts being understood as engineering value.

Challenge : 2 The Project Selection Trap

Pavanipriya Sajja — Fri, 17 Apr 2026 23:25:19 +0000

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.

Challenge 1: The Learning Curve Feels Endless (and Unclear)

Pavanipriya Sajja — Thu, 16 Apr 2026 22:52:25 +0000

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.

How we derived behavioral and motivational patterns for user persona?

Pavanipriya Sajja — Thu, 12 Mar 2026 17:34:14 +0000

This article explains end to end process of the methodology used to identify and derive behavioral and motivational patterns from UX research data collected on multi-cluster Kubernetes operations.

The analysis draws on a Google Sheets sample dataset containing 20 verbatim quotes, 20 pain point themes, and 20 desired solutions — 60 data points in total — used here as a working example to illustrate how patterns are surfaced, calculated, and translated into actionable persona insights.

Here is the link for the google sheets:

Sample Raw Data - Google Sheets

docs.google.com

The goal of this methodology is to move beyond surface-level pain points and equip product, design, and engineering teams with a deeper understanding of how platform engineers, SREs, and related roles actually behave and what outcomes they are genuinely optimizing for.

How did we Derived Behavioral Patterns?

Behavioral patterns are identified by looking at what people are actually doing in response to a problem — the observable actions, workarounds, and habits described in the data. The question we asked of each data point was: "What is this person doing right now to cope with this situation?"

We grouped responses that described similar actions — not similar topics — and named the underlying behavior.

Our Worked Example: "Workaround Accumulation"

These three raw data points were the anchors:

"Cost visibility is nearly zero at the namespace level. We have no easy way to map spend to teams without custom Prometheus dashboards that we build and maintain ourselves."

"GitOps drift detection is useful but noisy. ArgoCD sends so many sync notifications that engineers create automation to silence them."

"Capacity planning for multi-tenant clusters requires manual analysis... we rely on gut feel and occasional spreadsheets."

On the surface, these look like three separate problems: cost, notifications, and capacity. But the behavior across all three is identical — the platform doesn't provide what's needed, so the engineer builds something themselves. Custom dashboard. Silencing automation. Spreadsheet.

The critical observation is the second half of each quote: "that we build and maintain ourselves," "create automation to silence them," "occasional spreadsheets." These aren't solutions — they're debt. Each workaround introduces something that can break, drift, or fall out of date.

That's what distinguishes this as a behavioral pattern rather than just a pain point cluster: it's a repeating action (self-build), triggered by a repeating condition (platform gap), producing a repeating consequence (maintenance burden).

The pattern name — "Workaround Accumulation" that captures both the behavior and its compounding nature over time.

How did we Derived Motivational Patterns

Motivational patterns require going one layer deeper. Instead of asking "what are they doing?", we asked "why are they doing it — what outcome are they actually trying to reach?" This is where you look past the stated problem to the underlying goal.

The method is essentially asking "what would success feel like to this person?" and finding where multiple people converge on the same answer, even if they're describing different problems.

Our Worked Example: "Desire for Speed with Confidence"

These three data points pointed us here:

"A dry-run mode for NetworkPolicy that shows which traffic flows would be blocked before the policy is applied."

"A visual RBAC policy editor that validates configurations before applying them to the cluster."

"Lightweight remote dev environments that mirror staging infra so engineers can test against real dependencies locally."

The surface topics are completely different — networking, access control, local development. But if you ask "what is the engineer actually trying to achieve?" across all three, the answer converges: they want to act quickly, but they need to know it won't break something first.

Notice what they're NOT asking for. They're not asking to slow down. They're not asking for approval gates or more review cycles. They're asking for earlier feedback so they can move confidently. Dry-run, visual validation, staging parity — all of these are mechanisms that move the moment of truth earlier in the workflow, before consequences become real.

This is what separates a motivational pattern from a feature request. The feature request is "build a dry-run mode." The motivation underneath it is "I want to move fast without causing outages." Once you see that motivation, you realize a dry-run mode, a staging mirror, and a policy validator are all answering the same psychological need — and that a product team solving for just one of them is only partially addressing what the engineer actually wants.

The Core Methodological Difference

	Behavioral Pattern	Motivational Pattern
Question asked	What are they doing?	Why are they doing it?
Data cues	Verbs: building, jumping, silencing, ignoring	Goals implied: "so I can," "without," "before"
Grouping logic	Same action across different contexts	Same underlying goal across different actions
Risk if missed	You fix the symptom, not the habit	You build features that don't address the real need

behavioral patterns show platform teams what is happening today, while motivational patterns show product and tooling teams what engineers are actually optimizing for, which is where the most actionable design direction lives.

How to integrate this patterns into persona:
There are a few ways to integrate these patterns into your personas depending on your audience

1. Embedded Section within each persona You add a "Behavioral & Motivational Profile" block directly inside each persona card, right after Goals or Frustrations. Clean and self-contained.

2. Cross-persona Pattern Matrix A separate table or section that maps each pattern to the personas it affects. Better for showing systemic themes across all four personas

3. Pattern as a Quote + Insight block Each pattern is anchored by a real verbatim quote from your research(Qualitative and quantitative) data, followed by the behavioral or motivational insight.

We can also include behavioral and motivational patterns in percentage format. Presenting these patterns with percentages makes the insights more credible and easier to reference or cite within the persona.

Again, let’s go back to the sample raw data. The dataset contains 20 qualitative responses (verbatim quotes), 20 pain point themes, and 20 desired solutions, which gives us 60 data points in total.

However, in practice, the 20 verbatim quotes serve as the primary evidence base for identifying behavioral patterns, because they describe the engineers’ actual actions, experiences, and workflows.

Here's my approach to calculate percentages honestly:

Method: Evidence Mapping For each behavioral pattern, I'll count how many of the 20 raw responses contain explicit evidence of that behavior — not just the topic, but the actual action being described.

Let me map this now (Based on the sample research data):

Behavioral Pattern	Responses with direct evidence	% of 20 responses
Reactive Debugging Over Proactive Monitoring	Responses 1, 14, 5 (jumping dashboards, blocked traffic, silent misconfigs)	3/20 = 15%
Workaround Accumulation	Responses 7, 15, 19 (custom dashboards, spreadsheets, silencing automation)	3/20 = 15%
Context Switching as Default Workflow	Responses 1, 3, 11 (three dashboards, six wikis, fragmented secrets)	3/20 = 15%
Tribal Knowledge Dependency	Responses 3, 16, 9 (scattered docs, deep controller knowledge, CRD research)	3/20 = 15%
Standardization Avoidance	Responses 8, 11, 13 (mixed rollback, mixed secrets, brittle local dev)	3/20 = 15%
Alert Desensitization	Responses 10, 19 (ignoring alerts, silencing GitOps notifications)	2/20 = 10%

The honest point I want to highlight here is that 20 responses represent a small qualitative sample, so percentages derived from this data may appear more statistically precise than they actually are.

When working with a larger dataset—for example, more than 100 responses (n ≥ 100) — the percentages become more reliable and meaningful. That is where percentage-based insights should ideally come from.

What is the difference between the straight percentage version and the detailed version when presenting behavioral and motivational patterns in a persona card? Which approach is the best way to present these patterns?

There are two approaches:

1. Straight Percentage Version (Quantitative Layer) This approach presents behavioral or motivational patterns using only numerical insights derived from the research data.

Example Behavioral Pattern: Reactive Debugging Observed in 68% of respondents

Raw data: Engineers wait for failures to surface before investigating, jumping between tools after the fact rather than catching issues proactively.

Advantages

Easy to read and scan quickly
Looks data-driven and credible
Works well for presentations and executive summaries

Limitations

Lacks context about why users behave that way
May oversimplify complex behaviors

Now let’s learn about another approach:

2. Detailed Version (Qualitative Layer): This approach combines behavioral patterns with contextual explanations, quotes from research participants, and the underlying trigger behind the behavior.

Example of Behavioral Pattern: Reactive Debugging Over Proactive Monitoring

Quote:

“When a pod crashes, I need to jump between three dashboards just to find the root cause.”

Trigger: Lack of integrated observability tools
Action: Manual investigation across multiple tools
Cost: Hours lost during each incident

Advantages

Provides deeper insight and context
Shows the reasoning behind behaviors
Stronger for research reports and documentation

Limitations

Longer and harder to scan quickly
Less suitable for compact persona cards

Which Is Best For Each Pattern Type

This is the key insight — they serve different pattern types differently.

Behavioral patterns can carry percentages because behavior is observable and countable. "X% of respondents described workaround-building behavior" is a defensible, citable claim.

Best Practice

The most effective approach is usually a hybrid format:

Use percentages for credibility
Add a short explanation or quote for context

Motivational patterns should almost never be percentages. Motivations are inferred, not directly stated. Saying "72% are motivated by speed with confidence" would be misleading — no one said that directly, you derived it. A quote + insight format is far more honest and persuasive here.

The reason for including behavioral and motivational patterns is based on five main purposes.

A persona without behavioral and motivational patterns only tells you who the person is.

A persona with these patterns shows how the person thinks and what motivates their decisions.

This difference is important because design and product decisions are not based on demographics or job titles. They are based on understanding how people behave in real situations and what outcomes they are trying to achieve.

1. Move from Descriptive to Predictive: Without patterns, a persona describes a person at a snapshot in time. With patterns, it lets you predict how that person will behave in a new situation you haven't researched yet.

Example: For example — once you know Alex (Platform Engineer) has a Workaround Accumulation behavioral pattern, you can predict that if you ship a feature with gaps, Alex won't file a bug report. He'll build around it. That prediction changes how you design the feature in the first place.

Purpose: Make personas useful for decisions that go beyond what was directly researched.

2. Explain Why Pain Points Exist, Not Just That They Do: Pain points alone tell you what's broken. Behavioral and motivational patterns tell you why it keeps being broken even when people know it's a problem.

Example: Alert desensitization is a great example from sample raw data. The pain point is "too many noisy alerts." But the behavioral pattern — engineers actively suppressing alerts as a coping mechanism — explains why just reducing alert volume won't fix it. You've broken trust.

The motivational pattern underneath, cognitive offloading — tells you the real design target: engineers need the system to carry the triage burden, not just send fewer notifications.

Purpose: Surface the root cause behind the symptom so solutions address the right problem.

3. Create Shared Language Across Teams: When a designer, a PM, and an engineer all read the same persona card, they need to walk away with the same understanding of the user. Job titles and tools lists don't achieve that — they're interpreted differently by different disciplines.

Behavioral and motivational patterns are discipline-neutral. "Reactive debugging over proactive monitoring" means the same thing to a backend engineer as it does to a UX researcher. It becomes a shorthand the whole team can reference in standups, design reviews, and roadmap conversations without needing to re-explain the research.

Purpose: Give cross-functional teams a common reference point rooted in user reality.

4. Prevent Solution-First Thinking: Without motivational patterns especially, teams default to building what users asked for rather than what users actually need. Your data is full of this gap, users asked for a dry-run mode for NetworkPolicy, but the motivation underneath is "I want to act fast without causing outages." Those are different design briefs.

If a PM only reads the pain points and desired solutions sections of a persona, they'll build a feature checklist. If they also read the motivational patterns, they'll ask "does this solution actually address the underlying motivation, or just the surface request?"

Purpose: Shift teams from feature-building to outcome-building.

5. Make Personas Defensible in a Research Context: A persona card that only contains job title, tools, and frustrations reads as anecdotal. Reviewers will ask — how do you know this is representative?

Behavioral and motivational patterns — especially when tied back to evidence from your (n>100) research respondent — demonstrate that the persona was derived from systematic analysis, not assembled from assumptions.

They show the reasoning chain: here is what people said, here is the pattern we observed across multiple respondents, here is what that tells us about this persona type.

Purpose: Establish research credibility and make the personas publishable and citable.

Conclusion:

Behavioral and motivational patterns are what elevate a persona from a static profile into a practical decision-making tool.

By grounding each pattern in observable actions and inferred goals — backed by evidence from the research dataset — teams can predict user behavior, address root causes rather than symptoms, and build toward outcomes rather than feature checklists.

What is Engineer persona?

Pavanipriya Sajja — Fri, 06 Mar 2026 06:01:42 +0000

What is an Engineer persona in a user research method?

A user persona is a research-based, fictional but realistic representation of a user group, built from patterns found in real data, interviews, and observations. It gives your team a shared mental model of who you're building for.

For Example: A persona for a platform Engineer isn’t one specific person at your company. It's what you learned from interviewing 15 platform engineers across different orgs, distilled into one coherent, usable profile.

Why it is important to consider?:

Developer experience projects fail not because engineers lack skill, but because teams build for an imagined user instead of a researched one. Personas make the real user visible inside engineering decisions.

73% of DevEx friction comes from tools not matching how developers actually think and work — not from technical limitations alone.

3X Teams using personas in design reviews are significantly more likely to catch usability issues before engineering investment begins.

How these personas are useful:

These personas help teams make better decisions by keeping real users at the center of every conversation. Instead of guessing, debates and discussions are grounded in actual evidence from users. Features get prioritized based on what engineers truly struggle with day to day.

Documentation is written around the tasks and goals engineers actually have, not just technical specs. Onboarding is scoped to the right starting point so new users aren't overwhelmed or under-informed. And in every meeting, there's a clear answer to the question "who is this actually for?" which keeps everyone aligned and focused.

Why DevEx is Different from Consumer UX?

Developers are power users with strong mental models and well-established workflows. While they can handle complex systems like Kubernetes, they have very little tolerance for friction in their critical path tasks such as debugging, deploying, or scaling applications.

Unlike consumer UX, which often focuses on visual delight, enjoyable interactions and engagement in platforms like Instagram, Developer Experience (DevEx) focuses on reducing cognitive load. A DevEx persona therefore emphasizes clarity, efficiency, and predictable workflows so engineers can complete high-frequency, high-stakes tasks with minimal mental effort.

👉 In simple terms: Consumer UX tries to make products enjoyable, but Developer experience tries to make complex tasks faster, clearer, and less mentally exhausting.

How to create a Engineer persona?

Creating a developer persona is different from creating a typical consumer persona. Instead of focusing on demographics, DevEx personas focus on workflows, tools, goals, and friction points in technical tasks. Here is a practical step-by-step approach.

1. Start With Real Research Data

Developer personas should always be based on real evidence, not assumptions.

You can collect data through:

Developer surveys
Interviews with engineers
Observing real workflows
Reviewing support issues or GitHub discussions

For teams building infrastructure platforms like Kubernetes, this might include understanding how engineers deploy, debug, and manage clusters.

2. Identify Behavioral Patterns

After collecting data, analyze it to find patterns in how developers work.

Look for similarities in:

Goals (deploy faster, automate operations, reduce downtime)
Pain points (configuration complexity, unclear errors, manual steps)
Workflows (CI/CD pipelines, CLI usage, automation scripts)
Tool usage (for example Docker or Terraform)

These patterns help define distinct developer groups.

3. Define the Persona Structure

A developer persona usually includes the following sections:

Role and Context:

Job role (Platform Engineer, Developer, SRE)
Experience level
Type of environment they work in

Goals:

What they are trying to achieve in their workflow

Key Tasks:

High-frequency tasks like deploying services, debugging failures, or scaling clusters

Pain Points:

Friction points in their daily workflow

Tools and Ecosystem:

Technologies and platforms they regularly use

Mental Models:

How they expect systems to behave

It is useful as a decision-making tool.

4. Focus on Workflows Instead of Demographics

In DevEx, demographics are less important. Instead of describing age or hobbies, focus on:

deployment processes
debugging patterns
infrastructure management workflows

This makes the persona actionable for engineering teams.

5. Validate With Developers

Once the persona is drafted, review it with actual engineers. Ask questions like:

Does this reflect your real workflow?
Are the pain points accurate?
What is missing?

This step helps ensure the persona reflects real developer behavior.

👉 In simple terms: A developer persona is created by studying real developer workflows, identifying patterns in their goals and challenges, and translating those insights into a clear representation that helps teams design better developer tools.

Tools to Create Developer Personas

What tools should we use to design personas? Typically, UX researchers create personas using tools such as Figma or Miro, or other platforms that provide ready-made persona templates. In these tools, researchers usually add persona data directly into the template format.

This approach works well when collaborating with UX design teams or teammates who are already familiar with these design tools. However, when working with developer experience teams, it is important to choose tools that developers can easily access and use to provide feedback.

For this reason, I chose to use Google Sheets to build the persona. A spreadsheet allows the information to be organized in a clear tabular format, making it easier for developers to review the data and add feedback directly.

Choosing the right tool makes collaboration easier and more effective. It also helps avoid repeating the same work across multiple tools, saving both time and effort.

How many personas that you actually need or build and how can we prioritize?

The number of personas you need depends on the diversity of users and their workflows, but in most DevEx or platform products, teams typically build 3–5 core personas. Building too many personas can dilute focus and make it harder for teams to use them in decision-making.

1. How Many Personas Are Usually Needed

In developer-focused products (for example platforms built around Kubernetes), teams usually identify a small set of representative roles such as:

Platform Engineers – manage infrastructure and clusters
Application Developers – deploy and run applications
SRE / Operations Engineers – maintain reliability and monitor systems

Each persona represents distinct goals, workflows, and pain points, not just job titles.

👉 A good rule is: Create enough personas to represent different behaviors, but not so many that teams cannot remember or use them.

2. How to Prioritize Personas

Not all personas should have equal weight. Prioritization usually depends on three factors:

Frequency of Use: Which users interact with the system the most? And High-frequency users should often be prioritized.

Impact on the System: Which users influence the platform architecture or adoption? For example, platform engineers often shape how tools like Kubernetes are configured across organizations.

Critical Workflows: Which personas perform the most critical tasks (deployment, scaling, debugging)? And Improving their experience usually delivers the highest value.

3. Persona Prioritization Model

Teams often classify personas into three levels:

Primary Persona:

The main user the product is designed for,
Most design decisions should support their workflows

Secondary Persona: Important users but with fewer or overlapping needs

Tertiary Persona: Users who interact occasionally or indirectly

👉 Focus design decisions around one primary persona, support 1–2 secondary personas, and avoid building too many additional ones.

How Teams can use this persona?

Personas are useful for engineering teams in several practical ways during a project. Here are five key ways they help:

1. Aligning the Team Around the User

Personas give engineers a clear understanding of who they are building for. This helps teams avoid assumptions and focus on real developer needs, especially when building complex systems like Kubernetes platforms.

2. Prioritizing Features

Personas help teams decide which features matter most. If a feature supports the primary persona’s workflow, it should usually be prioritized over less critical improvements.

3. Identifying Workflow Friction:

By mapping goals and pain points, personas reveal where developers struggle in their workflows, helping engineering teams focus on reducing friction in high-frequency tasks.

4. Supporting Design and Architecture Decisions:

Personas help engineers understand mental models and expected workflows, which guides better decisions when designing APIs, tools, or developer platforms.

5. Improving Communication Across Teams:

Personas create a shared language between product, UX, and engineering teams, making discussions about user needs clearer and more consistent.

👉 Personas help engineering teams align on users, prioritize features, reduce workflow friction, guide design decisions, and improve collaboration across teams.

Conclusion:

Engineer personas are a practical research tool that keeps real developer needs at the center of every product decision. By grounding design and engineering conversations in actual workflows, goals, and pain points rather than assumptions.

Teams can reduce friction, prioritize the right features, and build platforms that developers genuinely want to use. Whether you're designing for Kubernetes, internal tooling, or any developer facing product, a well researched persona is one of the simplest ways to close the gap between what teams build and what engineers actually need.

Engineering Research Beyond Surveys (Part II)

Pavanipriya Sajja — Wed, 04 Mar 2026 04:19:21 +0000

When Surveys Are the Right Method in Engineering Teams

Engineers are data driven, practical and skeptical of anything that feels vague or time consuming, which makes research a tricky thing to get right. Surveys are often the go to tool, but they only tell part of the story. Used the right way, research can help teams understand not just what is happening, but why.

This guide walks through how to use surveys effectively, when to go beyond them, and how to present findings in a way that engineers actually trust and act on.

Step 1: Use Surveys for Measurement, Not Discovery

Surveys work best as a measurement tool, not an exploration tool. They're most useful once you already understand the problem space, the workflows, and the main pain points, basically when you know what questions to ask.

For example, surveys are great for

tracking how developer satisfaction changes over time,
measuring whether onboarding improvements actually made a difference,
helping teams prioritize a known list of feature requests, or
checking how a new release landed with users.

Where surveys fall short is in discovery work. If you're trying to uncover friction you don't yet know about, understand how developers work through complex debugging scenarios, or do deep research into how people actually use a tool day-to-day, surveys won't get you there. Those situations call for interviews, observation, or other methods that let the research breathe and go in unexpected directions.

Surveys are powerful — when used intentionally.

Step 2: Define a Clear Outcome Metric

Before launching any survey, you need to get clear on one thing: what decision will this data actually influence? This is your outcome metric, and it should guide every question you write.

For example, you might be trying to

figure out whether CLI performance should move up the roadmap,
whether a recent change to the CI pipeline made onboarding easier,
or whether developers are finding the documentation usable.

Without that decision target in mind, the survey loses its purpose. You end up collecting a lot of responses that feel useful but don't actually point anywhere. The data becomes noise rather than direction

Step 3: Keep It Focused (Engineers Hate Long Surveys)

When creating surveys for engineers, keep them short, between 10 and 20 questions is ideal. Mix in some rating questions along with one or two open-ended questions where they can write freely.

The most important thing is to ask about real behaviors and actual experiences rather than general opinions.

For example, instead of asking "Do you like the platform?" try asking something like "How many times did the build fail last week?" or even better, "What was the last frustrating moment you experienced?" Questions like these give you much more honest and useful answers.

Step 4: Pair Surveys With Usage Data

Surveys tell you what developers think and feel, but engineers tend to trust a different kind of evidence - logs, metrics, and performance data. That's just the nature of technical teams; they're wired to look for measurable signals.

If you want your research to land with credibility, pair your survey findings with actual usage data.

When you combine what people perceive with what the data shows they actually do, the picture becomes much harder to dismiss.

Maybe developers say onboarding feels slow, and the metrics confirm where drop-off happens. Or satisfaction scores dip right around the same time error rates spiked.

That combination of perception and behavior is far more persuasive than either source on its own, and it speaks the language engineers already trust.

How to Convince Engineering Teams to Go Beyond Surveys

Getting engineering teams to embrace research beyond surveys is really a question of how you frame the conversation. Telling a room of engineers that you need more qualitative research won't move the needle, it sounds like a methodology preference, and that's easy to brush off.

What does get their attention is framing it as a gap in the signal. Engineers are already thinking in terms of failures, blind spots, and missing data. So instead of leading with the research method, lead with what's being missed.

When you say "we're not catching failure signals early enough,"
that lands differently. It connects to something they already care about — reliability, visibility, and not being caught off guard. Once you're speaking that language, the case for richer research methods makes itself. Let's learn step by step.

Step 1: Start With Their Pain

The most effective way to bring engineering teams along is to start with a problem they're already feeling. Rather than walking in and asking for interviews or more research time, anchor the conversation in something that's already causing friction.

Why are support tickets going up?
Why are developers finding workarounds instead of using the platform the way it was intended?
Why do satisfaction scores look healthy but adoption numbers tell a different story?

These are questions that surveys alone can't answer, and that's exactly the point. When you surface those gaps, you're not pitching a research method, you're pointing at a real problem that needs a deeper kind of investigation. That shift in framing makes it much easier for engineering teams to see the value, because you're speaking directly to something that's already on their radar.

Step 2: Show the Blind Spot

Sometimes the data you have tells one story while reality tells another. Imagine your survey shows 75% of developers are satisfied - that sounds like a win.

But then you look around and notice people are quietly building workarounds, Slack is full of complaints, and CI timeouts are happening every single day. There's a clear disconnect, and that gap is your blind spot.

This is where you can reframe the conversation in a way that resonates with engineers. Surveys are good at telling you what is happening, but they rarely explain why.

And engineers deeply respect root cause analysis, it's how they think about system failures. So instead of framing additional research as a soft or optional exercise, position it as debugging user behavior, running a root cause investigation, or building observability for humans the same way you'd build it for systems.

That language clicks with technical teams because it maps directly onto how they already approach problems.

Step 3: Run a Small Pilot Study

Rather than proposing a full research program upfront, start small and let the results do the talking.

Suggest something contained and low-commitment — five developer interviews, one session where you shadow someone through their actual workflow, or a single usability test focused on something specific like CLI setup.

That's easy for a team to say yes to because it doesn't feel like a big investment.

The key is what you do with it afterward. When you come back with concrete findings, a specific point in the workflow where things break down, a pain point that never showed up in any survey, or a quick win the team can act on immediately, that's when the skepticism starts to fade.

Engineers are pragmatic, and a small pilot that produces real, actionable insights is far more convincing than any proposal or methodology argument you could make upfront.

Step 4: Translate Research Into Engineering Terms

How you communicate findings matters just as much as the findings themselves. Telling an engineering team that "developers feel confused" doesn't give them anything to work with — it's vague and easy to set aside.

But if you say that onboarding has three distinct friction points, two undocumented assumptions that users have no way of knowing upfront, and one configuration issue that's consistently causing 40 minute delays, now you have something concrete.

That level of specificity speaks directly to how engineers think. It turns a feeling into a defect, a complaint into a root cause, and a vague observation into something that can actually be prioritized and fixed.

The goal is to make your research feel less like a report and more like a diagnostic, something that tells the team exactly where to look and what to do about it.

Conclusion: Building a Research Practice Engineers Actually Trust

Surveys are a valuable tool for engineering teams, but only when used with intention and paired with the right approach. They work best for measuring what you already know, not for uncovering what you don't.

To get the most out of research, keep surveys short and focused on real behaviors, back them up with actual usage data, and know when to go deeper through interviews or observation.

When bringing engineering teams on board with broader research, speak their language, frame gaps as missing signals, start small with a pilot study, and translate findings into specific, actionable problems they can actually fix.

When research is done this way, it stops feeling like an extra step and starts feeling like a natural part of how good engineering decisions get made.

Part(I) of this article:

Pavanipriya Sajja

Feb 26

Why do the majority of the Engineering teams focus on conducting the Surveys?

#management #softwareengineering #ux #tutorial

Comments

5 min read

Why do the majority of the Engineering teams focus on conducting the Surveys?

Pavanipriya Sajja — Thu, 26 Feb 2026 15:28:53 +0000

When I have started exploring my self interest in the developer experience domain, I have noticed that the majority of the engineering teams are focusing on conducting surveys methods in (User research). To know the feedback on the product, workflows, architecture, Tooling stack, methods, process to improve experience on these dedicated areas for the engineering teams.
Whether the survey conducting teammate is Engineer or Project Manager not particularly UX designer or the researcher is focused on conducting the survey and working on the analysis results and presents results with the teammates.

Let’s learn why behind the creating surveys:

Most engineering teams focus on surveys because they’re the easiest, fastest, and most scalable way to collect feedback — especially in technical environments.

But there are deeper reasons behind it 👇

Surveys Scale Easily

Surveys are a great fit for engineering teams because they scale well. These teams typically build things like developer platforms, internal tools, APIs, and infrastructure and their users can range from hundreds of internal developers to thousands of external ones. Trying to schedule and run individual interviews with that many people is time consuming and hard to coordinate. A survey solves that problem by reaching everyone at once, requiring far less effort to organize, and delivering results quickly. For engineering organizations that are always busy, that kind of efficiency is really appealing.

Engineers Prefer Quantifiable Data

Engineering culture is built around measuring things. Engineers are used to working with metrics, dashboards, and concrete outcomes so when it comes to understanding their users, they naturally gravitate toward data that feels the same way. Surveys deliver exactly that: percentages, NPS (Net Promoter Score) scores, satisfaction ratings, and trend graphs that can be tracked over time. This kind of output fits neatly into the ways engineering teams already communicate their work, whether that's through OKRs (Objectives and Key Results), sprint reviews, or reports to leadership.

Qualitative methods like interviews and observations, while valuable, can feel too abstract or "soft" to many engineering teams because the findings are harder to put into a chart or tie to a specific number.

Time & Resource Constraints

Most engineering teams don't have a dedicated UX researcher on staff, and the people doing research often have no formal training in it. They just need quick answers to move forward. In that context, surveys feel like the obvious choice, they're low effort, low risk, and can be sent out in a matter of hours. Compare that to something like usability testing or contextual inquiry, which requires careful planning, recruiting the right participants, moderating sessions, and then spending significant time analyzing what you found. That's a real investment of time and resources that many teams simply don't have. So surveys seem like the cheaper, faster path and on the surface, that's hard to argue with.

Perceived Objectivity

There's something powerful about a number. When a survey comes back showing 72% satisfaction or a 6.8 out of 10 usability score, it feels decisive and trustworthy like the data is speaking for itself. Leadership responds well to this because it looks like objective, data-driven decision making. Interviews and qualitative research, on the other hand, can feel subjective to people who aren't familiar with how rigorous those methods actually are. Without that understanding, findings from a conversation can seem like "just opinions" compared to a clean percentage on a slide. So surveys carry a perception of credibility that makes them easier to sell internally, even when the numbers don't always tell the full story.

Tooling Makes Surveys Easy

The tooling available today makes surveys almost frictionless to run. Platforms like Google Forms, Typeform, in-product feedback widgets, and various internal tools let anyone put together and launch a survey in just a few minutes, no special skills required. Deep research methods like interviews or contextual inquiry don't have that same kind of ready-made infrastructure. There's no equivalent "click and go" tool that makes those approaches just as easy to set up and scale. So naturally, teams reach for what's most accessible, and right now, that's surveys.

Engineering Mindset Bias

Engineers are trained to think in systems to optimize, troubleshoot, and find patterns in data. That's a real strength, but it can create a blind spot when it comes to understanding user experience. UX problems are often behavioral, emotional, and deeply tied to context and workflow, which are things that don't surface cleanly in a spreadsheet. Surveys can tell you that 40% of users find a feature difficult, but they rarely explain why the friction exists, what workarounds people have quietly invented, how users are actually thinking about the problem, or where the hidden pain points live. Despite that, surveys can feel sufficient to an engineering mindset because they produce the kind of structured, numerical output that feels familiar and complete. The gap between what surveys capture and what's actually happening in users' workflows often goes unnoticed

The Real Issue

Surveys aren't the problem, it's how they're used.

They're genuinely good at certain things: tracking trends over time, helping teams prioritize, and benchmarking satisfaction across releases. But they have real limits. They struggle to uncover problems you didn't know to ask about, they can't capture the nuance of how someone actually moves through a workflow, and they fall short when the goal is to deeply understand complexity. This matters especially in areas like developer experience, platform UX, and internal tooling, where the problems are often subtle, context-dependent, and buried in the details of how engineers do their work day to day.

Using surveys as the only research method in these spaces means you'll get data, but you'll likely miss the insights that would actually move the needle.

Surveys Are a Starting Point, Not the Whole Story

Engineering teams reach for surveys for all the right reasons — they scale, they produce numbers, they fit into existing workflows, and they're fast to deploy. In environments where time is short and data-driven culture is the norm, surveys feel like the natural, responsible choice. And in many ways, they are. There's nothing wrong with using them.

But the problem emerges when surveys become the only tool in the research toolkit. Surveys can tell you what is happening at a surface level — satisfaction scores, adoption rates, feature preferences — but they rarely explain why it's happening, how users are actually working around it, or what problems haven't surfaced yet because no one thought to ask the right question.

This gap matters most in developer experience, platform UX, and internal tooling — exactly the spaces where engineering teams tend to rely on surveys most heavily. These environments are complex, workflow-driven, and deeply contextual. The friction that slows down an SRE or breaks a platform engineer's flow often lives in the in-between moments — the workarounds, the unspoken frustrations, the mental models that don't match the system's design. A survey won't find those. An interview will.

The path forward isn't to abandon surveys. It's to use them for what they're genuinely good at — tracking trends, benchmarking, and validating at scale — while pairing them with qualitative methods that can uncover the deeper behavioral and contextual insights that numbers alone can't capture. Interviews, usability testing, and contextual observation aren't replacements for surveys. They're complements to them.

The most effective research practice is a mixed-methods one. Use surveys to scale. Use qualitative research to understand. Use both together to build products and platforms that engineers actually love to use.

The UX Hackathon: Your Guide to Rapid Innovation and Career Growth

Pavanipriya Sajja — Thu, 26 Feb 2026 00:32:53 +0000

Are you looking to fast track your design skills, build an impressive portfolio, and connect with the vibrant UX community? Look no further than the UX hackathon! Often misunderstood, these events are powerful catalysts for learning and growth, especially for aspiring designers.

Let's dive into everything you need to know.

What is a UX Hackathon?

A UX hackathon is a time limited collaborative event where designers tackle real world user experience challenges. Unlike traditional coding hackathons, UX hackathons focus on research, ideation, prototyping, and presenting design solutions rather than building functional software.

These events typically last 24-72 hours and bring together designers, researchers, and sometimes developers to solve problems for organizations, communities, or hypothetical scenarios.

Design Hackathon Key Characteristics:
No-Code Focus: Emphasis on design thinking, research, wireframing, and prototyping rather than programming.

Real-World Problems: Challenges often come from nonprofit organizations, startups, or community needs.
Rapid Iteration: Quick cycles of ideation, testing, and refinement.
Team Collaboration: Cross-functional teams combining different UX specialties.
Mentorship: Access to industry professionals who provide guidance and feedback.

In short, we can say that UX hackathons focus on problem-solving, research thinking, rapid prototyping, and storytelling — not just visuals.

Why Participate in UX Hackathons?

Participating in UX hackathons offers a wealth of benefits for your career and skill development.

Career Benefits: According to industry surveys, 78% of hiring managers view hackathon participation favorably when evaluating candidates. Hackathons demonstrate your ability to work under pressure, collaborate effectively, and deliver results quickly.
Portfolio Building: Create impressive case studies in condensed timeframes.
Networking: Connect with other designers, potential employers, and industry mentors.
Skill Development: Practice rapid prototyping, user research, and presentation skills.
Industry Exposure: Work on real problems from companies and organizations.
Recognition: Win prizes and gain visibility in the design community.

“No real projects? Hackathons can become your real-world experience.”

Who Can Participate?

This hackathon is open to a wide range of participants, including students, career switchers, beginners in UX, developer and designer teams, researchers, and product thinkers. If you're new to UX, don't worry—many hackathons are beginner-friendly and designed to help you learn while you build.

Many hackathons are beginner-friendly!

Where to Find UX Hackathons?

You can find UX hackathons on a variety of platforms. Devpost, Major League Hacking, Eventbrite, Meetup, and AngelHack are popular sites that regularly list hackathon events across different skill levels and themes. Beyond these, LinkedIn is a great place to discover opportunities shared by your network, and design communities often post hackathon announcements as well. Don't overlook Slack and Discord groups focused on UX and design—these communities frequently share hackathon opportunities and can connect you with potential teammates.

When Do Hackathons Usually Happen?

Hackathons tend to follow predictable cycles throughout the year. They often align with university semesters, tech conference seasons, product launch cycles, and global design events. You'll find both online and offline formats available—online hackathons offer flexibility and accessibility from anywhere, while in-person events provide more immersive collaboration and networking. In terms of time commitment, hackathons typically range from 24-hour sprints to weekend-long events, though some extend over a week or more with lighter daily involvement. Understanding these rhythms can help you plan ahead and find events that fit your schedule.

How to Participate in a UX Hackathon (Step-by-Step)

Participating in a UX hackathon follows a straightforward process.

Register early to secure your spot.
Read the problem statement carefully to fully understand the challenge.
Form a team or join one if you're flying solo—many hackathons have channels for finding teammates.
Understand the judging criteria so you can tailor your work accordingly.
Plan your time strategically A helpful breakdown is to allocate roughly 20% of your time to research, 20% to ideation, 25% to wireframes, 20% to prototyping, and 15% to preparing your presentation. This structure keeps you on track and ensures you have a polished deliverable by the deadline.

How to Find a Team?

Finding a team for a hackathon is easier than you might think. Many events have dedicated Discord or Slack channels where participants can connect and form groups. You can also comment on the event page expressing your interest in joining a team, post on LinkedIn to reach your professional network, or reach out directly in design communities like the Interaction Design Foundation, UXPA, or IxDA. When building your team, consider partnering with developers who can bring your designs to life, and look for someone skilled at storytelling—a strong presenter can make a significant difference when it's time to pitch your solution to the judges.

Roles in a UX Hackathon Team

Understanding team roles can help beginners navigate hackathons more effectively. Common roles include:

UX Researcher: Gathers insights and validates ideas.

UX Designer: Focuses on user flows and interaction design.

UI Designer: Handles visual design and aesthetics.

Developer: Builds the functional prototype.

Presenter/Storyteller: Crafts and delivers the final pitch.

Product Strategist: Keeps the solution aligned with user needs and business viability.

Keep in mind that hackathon teams are often small, so one person frequently takes on multiple roles. Flexibility and collaboration are key!

Online vs Offline Hackathons: What’s the Difference?

Both online and offline hackathons offer valuable experiences, but they feel very different.

Online Hackathons:

Pros: Remote, accessible from anywhere, flexible collaboration tools, easier to balance with personal schedules, lower travel costs.

Cons: Harder to build team energy, communication gaps can arise, time zone differences may complicate coordination. Require stronger communication discipline and organized documentation.

Offline Hackathons:

Pros: High-energy environment, immediate collaboration, strong networking opportunities, faster brainstorming sessions.

Cons: Physical exhaustion, more intense time pressure, less flexibility. Often feels closer to a startup sprint.

If you're new to hackathons, online events are a comfortable starting point. If you want deep immersion and networking, try offline events when possible. Both formats build real-world skills.

Resources and Websites to Participate in Design Hackathons:

UXHack: https://uxhack.co/
Devpost: https://devpost.com/hackathons
Global Hack Week (MLH): https://ghw.mlh.io/
Unstop: https://unstop.com/hackathons?oppstat...
Eventbrite: https://www.eventbrite.com/d/online/u...
Dev.Events: https://dev.events/hackathons/ux
Major League Hacking (MLH) : https://mlh.io/
Hackathon.com: https://www.hackathon.com/

How to Find Teammates as an Independent Designer

Finding teammates as an independent designer requires proactive community engagement.

Discord: The primary platform for hackathon team formation. Join communities like Design Buddies (92K+ members), Devpost Discord (45K+), and MLH Community (500K+) and be active 2-4 weeks before your target hackathon.

Networking: Include your role, timezone, experience level, and desired skills when introducing yourself.

Other Platforms: ADPList for mentor connections, LinkedIn UX groups, and local meetups.

Event Matching: Many hackathons have built-in team matching during opening ceremonies.

Pro tip: Consider going solo for your first hackathon to learn the format, then leverage that experience to attract stronger teammates for future events.

Hackathon Mindset for Beginners: Perfection vs Progress

One of the biggest mistakes beginners make in hackathons is chasing perfection. Hackathons are not about perfection—they are about progress. You're working within 24–48 hours; enough time to demonstrate clear thinking, strong prioritization, and problem-solving ability, but not a fully refined product.

Shift your mindset from perfection to progress: instead of "the UI must look flawless," ask "what is the core problem?", "what is the smallest valuable solution?", and "does this clearly communicate impact?" Judges are not looking for a production-ready app; they're looking for clarity, innovation, feasibility, and user-centered thinking.

Progress wins hackathons. Perfection delays them.

How to Prepare Before the Hackathon

Preparation gives you a huge advantage:

Keep templates ready: User persona, problem statement, empathy map, user journey map, pitch presentation structure. This saves 2–3 hours during the event.

Optimize your Figma setup: Clean file structure, basic wireframe components, reusable buttons, input fields, layouts, organized pages for different stages.

Prepare research frameworks: "How Might We" questions, assumption mapping, rapid user interview questions, competitive analysis outlines, problem framing canvases.

Understand design system basics: Typography hierarchy, spacing consistency, button states, basic accessibility, color contrast. Use simple grids and minimal color palettes.

Ask yourself: can I clearly define a problem, simplify a complex idea, and communicate my thinking confidently? Hackathons test more than design skills—they test decision-making, collaboration, and clarity. Prepare your mindset, tools, and frameworks in advance, and you'll feel ready and confident.

How to Present Your Hackathon Project

A strong presentation can make or break your hackathon success.

State the problem: Clearly articulate the challenge you're solving.

Introduce your target user: Help judges understand who you're designing for.

Share a key research insight: Validate the problem and show your homework.

Present your solution: Explain how it addresses user needs.

Focused demo: Highlight your core feature in action.

Close with impact: Explain what difference your solution makes and why it matters.

This structure keeps your presentation clear, memorable, and persuasive.

How to Turn Hackathon Work into a Strong Case Study

Turning your hackathon project into a strong case study is invaluable for your portfolio.

Document your process: Capture research, sketches, decisions, and pivots.
Show constraints: Highlight time limits or team size to demonstrate working under pressure.
Highlight collaboration: Explain how you worked with teammates and your role.
Include iterations: Show how your design evolved based on feedback.
Add a learning section: Reflect on what you'd do differently.
Include measurable impact: User feedback, test results, or awards won.

Standing Out in Job Interviews with Hackathon Project Experience

Hackathon experience is a powerful differentiator because it demonstrates skills that traditional projects often don't: working under extreme time pressure, rapid collaboration, creative problem-solving with ambiguous constraints, and delivering polished results quickly.

When discussing hackathon projects, use the STAR method (Situation, Task, Action, Result). Highlight how you handled challenges, prioritized features, made quick decisions, and presented your work persuasively. Include metrics like task completion rates or awards won to quantify your impact.

Tools Commonly Used in UX Hackathons

Having the right tools ready can give you a significant advantage.

Figma: For wireframing and prototyping.

Miro: For collaborative brainstorming and mapping out ideas.

Notion: For organizing documentation, research, and decisions.

Prepare templates before the event to save time.

Common Mistakes Beginners Make

Beginners often stumble on a few predictable mistakes:

Spending too much time perfecting the UI while neglecting the core UX.
Ignoring research completely.
Poor time management.
Failing to develop a clear narrative.
Overcomplicating the solution with too many features.
Not preparing the final demo properly.

Remember: clarity beats complexity.

What If You Don’t Win?

Not winning a hackathon does not mean you've failed. Regardless of the outcome, hackathons provide:

Valuable experience working under pressure.
Exposure to real-world design challenges.
Networking opportunities.
Feedback from judges and peers.
Portfolio content that demonstrates your skills.

Every hackathon improves your design maturity.

I have created a video as well, you can watch the video, Here is the link:

Final Thoughts

UX hackathons are powerful learning platforms for beginners. They simulate real-world product challenges, force quick decision-making, and strengthen collaboration skills. If you are waiting for “real projects,” hackathons can become your real projects. Start small. Participate consistently. Learn from every experience. Your growth matters more than trophies.