DEV Community: Pavanipriya Sajja

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: https://youtu.be/KjQK0Lsiab0?si=8ZeCj7goMEejGcdM

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.

Stop Writing Interview Questions Too Early: What to Focus on First in Developer UX Research

Pavanipriya Sajja — Wed, 25 Feb 2026 23:38:46 +0000

When first starting to conduct user interviews in Developer Experience (DevX), many designers make a common mistake: they sit down and immediately begin writing questions. The natural instinct is to jump straight into the tactical details:

Should I focus on the MVP?
Should I recruit frontend developers or backend engineers?
Should I structure it by job title?

The assumption is that the interview guide is the first step in the process. However, this is incorrect.

The real first step is something most designers skip entirely and it's critical to get right before any questions are written.
When first starting to conduct user interviews in Developer Experience (DevX), many designers make a common mistake they dive straight into writing questions without establishing the foundation first.

Start With the Research Objective — Not the Questions

Before writing a single interview question, ask yourself:What decision will this research influence? If you can't answer that clearly, your interview will become a "nice conversation" instead of actionable research.

Your research objective should be specific and tied to a real problem. For example:

Are you trying to reduce friction in a CI/CD setup?
Are you improving onboarding for a developer tool?
Are you validating a new CLI workflow?
Are you testing a dashboard usability issue?

Your questions must serve a purpose. Not curiosity. Not assumptions. Not "let's just explore."
When the objective is clear, the structure becomes obvious and every question you write will drive toward insights that actually inform decisions.
When first starting to conduct user interviews in Developer Experience (DevX), many designers make a common mistake they recruit participants based on job titles rather than what actually matters.

Don't Start With Job Titles — Start With Behaviors

One of the biggest traps in Developer UX research is recruiting by title. You'll often see teams say:

"We need to interview 5 frontend developers and 5 backend engineers."
But here's the problem: job titles don't define behavior. Two developers with the same title can have completely different workflows, responsibilities, and pain points.
Instead of recruiting by title, recruit by responsibility and behavior. Ask screening questions like:

Do you set up CI/CD pipelines?
Do you manage infrastructure configurations?
Are you responsible for debugging production issues?
Do you maintain internal developer tools?

Behavior > Job Title

This shift in approach matters because UX problems live in workflows—not in LinkedIn titles. When you recruit based on what people actually do, you'll find participants whose experiences directly inform the decisions your research needs to support.

Where Does MVP Fit In?

Another common confusion arises when designers ask: "Should I design the interview around my MVP?" The answer depends on the type of research you're conducting. There are two major types of interviews in Developer UX, and understanding when to use each is critical.

1. Discovery Interviews (Before You Build)

This is where many teams rush—but discovery interviews are about understanding, not validating your solution.At this stage, you are validating the problem, not the solution.

Discovery interviews focus on:

Current workflows
Friction points
Workarounds
Mental models
Tool ecosystems

You ask questions like:

Walk me through how you deploy your application.
What tools are involved?
What usually slows you down?
What's the most frustrating part of your workflow?
When was the last time something broke? What happened?

Notice something important: You're not pitching. You're not suggesting features. You're not leading. You're learning reality. This stage prevents you from building a beautiful solution to a problem that doesn't matter.

2. Evaluative Interviews (After You Have an MVP)

This is when your MVP becomes central to the research. Now you're testing execution rather than discovering problems.

Evaluative interviews focus on:

Clarity
Usability
Learnability
Workflow alignment
Mental model match

Questions shift to:

What do you expect to happen when you click this?
How would you approach this task?
Is anything confusing?
What feels unclear or unnecessary?

Here, you are validating execution—not discovering the problem.
The Right Order for Developer UX Interviews

If you want your research to create real impact, follow this order:

Step 1: Define the Research Goal — What decision will this research inform?
Step 2: Define Behavioral Criteria — Who actually performs this workflow?**
*Step 3: Decide Interview Type *— Discovery or Evaluative?
Step 4: Write Focused Questions — Only after the above is clear.

A Simple Structure You Can Use
Here's a clean framework you can adapt for any Developer UX study:

1. Screening Questions

What is your role?
How many years of development experience do you have?
What tools do you use daily?
Are you responsible for deployment or infrastructure setup?

2. Context Questions

Can you describe your current development workflow?
What tools are central to your process?

3. Workflow Deep Dive

Walk me through your last deployment.
What steps are manual vs automated?
Where do you switch tools?

4. Pain Points

What frustrates you most?
What takes longer than it should?
What do you wish was simpler?

5. Opportunity Signals

If you could improve one thing, what would it be?
What tools have you abandoned and why?

This structure keeps the conversation focused and actionable.

The Biggest Mistake in Developer UX Research

Many teams jump straight to solution validation. They say: "We built a better dashboard—let's test it."
But if you didn't deeply understand the following, you risk solving a surface-level issue:

How developers think
Where friction truly exists
What trade-offs they accept
What constraints they operate under

Developer workflows are complex. They include automation, scripts, legacy systems, internal tools, and cognitive shortcuts. You must understand the ecosystem before improving it.

Conclusion
If you're confused between focusing on MVP or demographics, remember this:

MVP matters only after the problem is clear.
Demographics matter only when they affect behavior.
Research objective always comes first.

When you prioritize clarity of purpose over question-writing speed, your interviews stop being conversations—and start becoming strategy.And that's when Developer UX research becomes powerful.

How UX Designers Can Contribute to OpenMRS: A Beginner’s Guide

Pavanipriya Sajja — Sun, 18 Jan 2026 06:52:10 +0000

Learn how to explore, understand, and contribute to an open-source health tech platform even if you’re new to UX and open source.

Open-source platforms are a goldmine for UX designers looking to build real-world portfolio projects, gain experience, and contribute to meaningful products. One of the most exciting options in Health Tech is OpenMRS—an open-source platform powering electronic medical records (EMRs) in developing countries.

If you’ve ever wondered how to start contributing to a big open-source project as a UX designer, this guide will walk you through the process, step by step.

Why OpenMRS?

OpenMRS is not just another health tech platform—it’s a global community that builds EMR applications and tools used in hospitals, clinics, and health programs around the world.

The platform includes:

**Core backend (OpenMRS Platform): **The foundation powering all EMR applications and modules.

Front-end applications: OpenMRS 3.0 (O3) Reference Application: Next-generation UI built for usability, speed, and modularity.
OpenMRS 2.x Reference Application: Legacy frontend still widely used.

Distributions: Pre-packaged solutions like Bahmni, UgandaEMR+ O3, and KenyaEMR O3, designed for different country-specific healthcare workflows.

Modular apps: Tools for registration, appointments, clinical documentation, billing, stock management, reporting, and form building.

This ecosystem makes OpenMRS an excellent playground for UX designers who want to contribute to meaningful, impactful projects while building their portfolios.

Step 1: Explore the Website and Community

Start by visiting the OpenMRS website: [(https://openmrs.org)]From the homepage, you can explore: Products such as Learn about EMR features, technology stack, and product roadmap.

Community: Find out about events, calls, and different ways to get involved.
Roles and onboarding: Designers, developers, healthcare providers, and researchers can follow clear onboarding steps.
You can also explore success stories like UgandaEMR+ O3 in their blog: [(https://openmrs.org/blog)]

Pro tip: Keep a document with all useful links and resources. It will save you time when revisiting the platform later.

Step 2: Explore Documentation for UX Tasks

OpenMRS has extensive documentation that can help you identify UX contribution opportunities:

OpenMRS Design Documentation As a UX designer, you can:
Conduct usability studies on documentation to see if new contributors understand it easily. Suggest improvements to the UX lead or project maintainer. Work on content creation, like writing blog posts or creating YouTube tutorials.

The documentation also includes design systems, Figma files, Zeplin handoffs, demo applications, and past research, giving you everything you need to start contributing.

Step 3: Explore GitHub

Even as a designer, understanding GitHub basics is essential. It helps you:

Track project progress
Understand development workflows
Identify pain points in the product

Visit the OpenMRS GitHub: [https://github.com/openmrs]
Here’s how you can get started:

Read the README.md of a repository, such as openmrs-distro-referenceapplication, to understand the project.

Check Pull Requests to find tasks: Pull Requests Open tasks are available for contribution. Closed tasks are already resolved.

Comment on a PR if you want to participate and you’ll be subscribed to notifications for updates.

Pro tip: Look for issues labeled “good first issue”—these are beginner-friendly tasks perfect for your first contributions.

Step 4: Identify UX Contribution Opportunities

UX designers can contribute in many ways:

Improving documentation usability
Conducting usability studies
Proposing design improvements for apps or modules
Creating content for the community, such as videos, blogs, or tutorials
Reviewing UI components and workflows in O3 or RefApp

Once you start contributing, don’t forget to share your work on LinkedIn or in your portfolio—it’s a great way to showcase real-world impact.

Step 5: Applications You Can Explore

OpenMRS is a rich ecosystem with multiple applications and distributions, including: O3 Reference Application: Modern frontend for end-to-end workflows, OpenMRS 2.x Reference Application: Legacy UI still in use Bahmni, UgandaEMR+ O3, KenyaEMR O3: Pre-packaged distributions for hospitals and clinics

Modules for:

Registration & Appointments
Clinical Documentation & Diagnosis Tracking
Billing & Stock Management
Reporting & Data Exports
Form Builder & Cohort Builder

Each of these applications offers opportunities for UX research, UI improvements, and content contributions.

Final Thoughts

Starting as a UX designer in open source might feel overwhelming at first—but platforms like OpenMRS make it approachable. By exploring the website, documentation, GitHub, and community, you can find tasks that match your skills and gradually build a strong portfolio with real-world impact.

Remember: start small, participate in community calls, and document your contributions. With consistency, you’ll not only learn a lot but also make meaningful contributions to a global health platform.

If you found this guide useful, follow me for more tips on contributing to open-source projects as a UX designer!

I am also creating the videos for the UX designer. You can learn from there too. Here is my chanel link: youtube.com/@designux1428/videos?sub_confirmation=1

AI-Native UX Design: A Quiet Shift in How We Design Interfaces

Pavanipriya Sajja — Wed, 24 Dec 2025 00:37:08 +0000

When you open an AI tool like ChatGPT or a voice assistant, you might notice something unusual. There are no menus telling you where to go. There are no buttons showing you what to click. Most of the time, there is just a blank text box.

This can feel strange at first. For years, we were taught that good design needs clear navigation and visible actions. So why do these AI tools work so well, even without those things?

The answer is simple: the way we use software has changed.

In the past, interfaces were built around steps. If you wanted to do something, the system asked you to do it one step at a time. For example, booking a flight meant choosing cities, picking dates, selecting a seat, and paying. You followed the steps, and the system waited for you at each point.

As designers, our job was to make those steps easy. We reduced clicks, improved labels, and made buttons clearer. This worked well because users were always in control.

AI changes this relationship.

With AI tools, users no longer follow steps. Instead, they describe what they want in their own words. You can simply say, “Book me the cheapest flight to Tokyo in March,” and the system figures out the steps by itself. The work happens behind the scenes.

Because of this, users think differently. They are no longer asking, “What do I do next?” Instead, they ask, “Did the system understand me?”

This is the biggest change in AI-native design.

When users don’t see what’s happening, trust becomes very important. In traditional software, trust was built slowly. Every click gave feedback. Every screen confirmed progress. With AI, all that trust is placed in one moment. Users must believe that the system understood them and did the right thing.

That’s not easy.

This is why AI-native UX design is mostly about trust. Designers now focus less on buttons and more on helping users feel safe and confident. We do this by showing progress, explaining decisions, and being honest when the system is unsure.

AI also changes how designers work.

Many designers worry that AI will replace them. In reality, AI mostly replaces repetitive tasks. It can help write research questions, summarize notes, or organize information. But AI does not understand context or human emotion. It doesn’t know what is truly important.

Designers still make the final decisions. Their role becomes more about thinking and less about manual work.

When designing AI systems, it’s also important to remember that not every action should happen automatically. Some actions are low risk, like drafting a message. Others are high risk, like sending money or deleting data. Good design adds extra checks for important actions. This doesn’t slow users down—it helps them feel secure.

AI systems can also make mistakes. They might misunderstand a request or give a confident but wrong answer. When designers plan for these situations, users feel more comfortable using the product, even when something goes wrong.

In the end, AI-native UX design is not about making software look fancy or futuristic. It’s about making powerful technology feel understandable and human.

As AI becomes part of everyday life, designers who focus on clarity, honesty, and trust will play an important role in shaping how people interact with these systems.

The UX of DX: Identifying the Key Areas for Designer Participation in Developer Experience Projects

Pavanipriya Sajja — Sun, 21 Dec 2025 00:05:34 +0000

The role of a UX designer is traditionally associated with consumer-facing apps, but as companies realize that developer productivity is a competitive advantage, the field of Developer Experience (DX) has emerged as a critical frontier.

In DX, the "user" is a software engineer, and the "product" is the ecosystem of tools they use to build, deploy, and monitor code. Here is an overview of the core areas and platforms where UX designers can—and should—participate.

1. Internal Developer Portals (IDPs)
Internal portals (like Backstage or Port) are the "front door" for an organization’s engineering team. Without UX intervention, these often become cluttered "service catalogs" that are hard to navigate.

UX Participation:

The "Golden Path": Designing streamlined, self-service workflows for common tasks like creating a new microservice or provisioning a database.

Information Architecture (IA): Organizing thousands of services, APIs, and technical documents into a searchable, logical hierarchy.

Onboarding: Designing the first-day experience for new hires to get their environment set up in hours instead of weeks.

2. API Design as Interface Design

An API is essentially a UI without the graphics. If a developer can’t figure out how to call an endpoint or understand an error message, it is a UX failure.

UX Participation:

Consistency & Predictability: Ensuring naming conventions (e.g., camelCase vs snake_case) and RESTful patterns are consistent across the entire platform.

Error UX: Designing actionable, human-readable error messages that tell the developer why something failed and how to fix it.

Mental Models: Aligning the API structure with how developers think about the problem domain (e.g., "Orders" vs. "Database_Rows").

3. Command Line Interfaces (CLIs)
For many developers, the terminal is their primary workspace. UX designers can apply "keyboard-first" design principles to CLI tools.

UX Participation:

Discoverability: Designing "help" flags and auto-completion features so users don't have to keep a manual open.

Feedback Loops: Using progress bars, colors, and clear status updates for long-running processes like builds or deployments.

Interaction Design: Implementing interactive modes (prompts, selects) for complex commands to reduce the risk of syntax errors.

4. Documentation & Technical Content
Documentation is often the most important "feature" of a technical product. UX designers bring the ability to structure information for high scannability.

UX Participation:
**
The "Time to First 'Hello World'":** Measuring and optimizing how long it takes a developer to complete a basic tutorial.

Contextual Help: Designing IDE plugins or hover-state documentation that brings information to where the developer is actually working.

Search UX: Optimizing search results and filtering to help developers find specific code snippets quickly.

5. Design Systems & Component Libraries
When UX designers build design systems, they aren't just creating UI kits for other designers; they are creating developer tools.

UX Participation:

Developer Ergonomics: Ensuring components are easy to implement (clear props, clean CSS, accessibility built-in).

Documentation for Implementation: Writing guides that explain not just what a button looks like, but how it behaves in different code environments.

6. Operational Dashboards (CI/CD & Monitoring)
Developers spend significant time in dashboards like GitHub Actions, Datadog, or Grafana. These tools often suffer from "data vomit"—too much information without clear priorities.

UX Participation:

Signal vs. Noise: Helping teams identify which metrics are critical (red alerts) versus which are just background noise.

User Journey Mapping: Mapping the "incident response" journey to design layouts that help developers find the root cause of a crash faster.

The UX Toolkit for Developer Experience
To succeed in these areas, UX designers must adapt their existing toolkit:

Developer Personas: Differentiating between a Junior Frontend Dev, a DevOps Engineer, and a Data Scientist.

Usability Testing (Code-Based): Watching a developer try to integrate an SDK and noting where they struggle with the syntax or logic.

Technical Empathy: Learning enough about the tech stack to understand the constraints and "pain points" of the coding process.

Key Insight: In DX, the goal isn't "delight" in the traditional sense; it's uninterrupted flow. The best developer experience is the one that stays out of the way.

💡 Unlocking Developer Potential: The Power of User Research in DX

Pavanipriya Sajja — Tue, 16 Dec 2025 23:03:25 +0000

In today's fast-paced technological landscape, the success of any platform or tool often hinges on the quality of the Developer Experience (DX). But how do we truly know what developers need and where their pain points lie? The answer is through dedicated User Research.

What is User Research in Developer Experience (DX)?
User research in Developer Experience is a systematic and empathetic study of the developers themselves. It goes beyond anecdotal evidence to deeply understand the realities of their daily work.

It involves:

Observing Day-to-Day Challenges: Studying developers in their natural work environment to observe their existing methods, preferred tools, and standard processes.

Identifying Actual Problems: Moving past surface-level complaints to uncover the root causes of friction, inefficiency, and frustration.

Understanding Needs and Goals: Gaining insight into what developers are trying to achieve, what constitutes success for them, and how they define a seamless workflow.

Informing Solutions: Using this deep understanding to define how we can design, build, and deploy new tools, features, or processes that genuinely solve their problems and enhance their productivity.

In short, DX User Research ensures that we are building the right products for the right reasons.

Why DX User Research is Critically Important
Your personal experience highlights a crucial, yet common, gap:

"I have been working as a UX designer in the design field since 10 years and last year I have involved into the developer experience platform and noticed that... lack of understanding about UX designer researcher how they can improve their experience. Everyone is working or making the developer friendly products but without focusing on what they actually want."

This observation is the core reason why DX user research is vital:

"Prevents ""Build Trap""",: "Without research, teams often spend valuable time and resources building features they think developers need, rather than what they actually need. This prevents wasted development effort."

Drives Adoption & Retention,:
"A frictionless and intuitive experience (high DX) directly correlates to higher adoption rates for tools and platforms. If a tool makes a developer's job easier, they will use it and advocate for it."
Boosts Productivity,
"Removing friction from the developer's workflow—like poor documentation, confusing APIs, or complex setup—significantly reduces context-switching and increases the speed and quality of their work. DX is a direct measure of ROI."

Creates Empathy,
"It bridges the gap between the product team (designers, product managers, engineers) and the end-user (the developer). Empathy is the foundation for creating successful, developer-centric products."

"Uncovers ""Unarticulated Needs,"Developers often learn to work around bad tools. Research techniques, particularly observation, can uncover problems they didn't even realize were solvable, leading to truly innovative solutions."

How Can We Solve Their Problems and Propose Solutions?
The process of translating research findings into actionable solutions is methodical and requires collaboration across product, design, and engineering teams.

1. The Research Phase (Discovery)
Methods to Employ:

Contextual Inquiry/Ethnography: Observing developers in situ (while they are coding/working) is the most powerful method for understanding workflow and friction points.

In-depth Interviews: Asking open-ended questions about their challenges, motivations, and the tools they rely on.

Diary Studies: Having developers log their interactions, frustrations, and successes with a tool over a period of time.

Telemetry Analysis: Studying usage data (how long a developer spends on a task, where they drop off, API call frequency) to identify quantitative friction points.

Key Deliverable: Comprehensive research reports, Empathy Maps, and defined Developer Personas that capture the developer's goals, pain points, and current workflow.

2. The Synthesis Phase (Definition)
Identify Root Problems: Group the research findings into themes and clearly articulate the most pressing, high-impact problems.

"How Might We" Statements: Reframe the problems as opportunities for design. (e.g., Instead of "The setup process is too long," ask "How might we reduce setup time to under 5 minutes?")

Define Success Metrics: Before proposing a solution, define what success will look like. This might include:

Reduction in Support Tickets (UX/Documentation clarity)

Increase in API Calls per Day (Ease of use)

Decrease in Time-to-First-Hello-World (Onboarding success)

3. The Solution Phase (Design & Prototyping)
Ideation & Wireframing: Brainstorm potential solutions, starting with low-fidelity sketches or wireframes.

Prototyping: Create interactive prototypes of the proposed solution (e.g., a new documentation page flow, a simpler API call, or a better CLI experience).

Usability Testing with Developers: Bring developers back in to test the prototype. This is crucial—it's the only way to validate if the proposed solution actually removes the friction identified in the initial research. This is often done using a Think-Aloud Protocol.

Conclusion: Making Developer Lives Easier
Successful Developer Experience is not about being "cool" or feature-rich; it's about being efficient and effective. By embedding user research at the heart of the DX process, we move away from building what we assume is best and start building what developers demonstrably need. This dedication to understanding the user is the key to building successful, loved, and enduring developer platforms.