UX case study: Designing RootCause to make plant diagnosis less of a guessing game

Explore how I designed RootCause, a plant diagnosis app that uses evidence, adaptive questions, and clear explanations to reduce guesswork for plant owners.

When Your Plant Starts Dying, “What’s Wrong?” Isn’t the Hardest Question. You notice a few yellow leaves. So you water it. A few days later, more leaves start drooping. You search for an answer and find three possibilities: overwatering, underwatering, or root rot. You check the soil. It’s wet. But then you remember you haven’t watered it in days. Now you’re even more confused.

This is where most plant-care apps jump in:

Upload a photo → answer a few questions → get a result.

But plant symptoms rarely point to just one cause.

Yellow leaves can be caused by watering problems, insufficient light, nutrient issues, pests, damaged roots — or several factors at once. A confident-sounding answer isn’t necessarily useful when the evidence is incomplete.

That made me rethink the problem.

What if a plant-diagnosis app didn’t try to immediately tell you what was wrong? What if it helped you figure it out?

Meet RootCause

RootCause is a mobile concept that helps people understand why their plant might be struggling and what they should do next.

The experience starts with information users can actually provide:

• Which plant are you concerned about?
• Where is the problem?
• What symptoms can you see?
• What are the plant’s current care conditions?

From there, RootCause asks questions based on what the user has already told it.

The aim isn’t to collect as much information as possible. It’s to identify which piece of information is useful next.

For example, if yellowing leaves and consistently wet soil could indicate either overwatering or root rot, RootCause might ask how long the soil stays wet and whether there is an unusual smell. If those answers don’t suggest a root problem, there’s no reason to ask the user to inspect the roots.

The experience therefore follows a simple progression:

Observe → Understand → Narrow down → Act → Track recovery

The Problem

Seeing the Symptom Is Easy. Understanding the Cause Isn’t.

When a houseplant starts looking unhealthy, people can usually describe what they see:

Yellow leaves. Drooping. Wilting flowers. Deformed flowers. Pests.

The difficult part is understanding what those observations actually mean.

A single symptom can have several possible causes, and beginners often don’t have enough knowledge to distinguish between them. This creates a familiar loop:

Notice something → Search for answers → Find several possibilities → Try one → Wait → Hope it works.

The problem, then, wasn’t simply finding a diagnosis.

It was helping someone decide which explanation makes sense and what they should check next.

The real UX problem

I reframed the challenge as:

How might we help beginner plant owners move from observing symptoms to understanding the most plausible causes — with enough context to make a confident next decision?

That framing changed what RootCause needed to do.

It couldn’t hide uncertainty behind a definitive answer. It couldn’t overwhelm users with a diagnostic questionnaire. And when multiple causes looked similar, it needed a way to distinguish between them rather than arbitrarily choosing one.

This led to three initial requirements:

1. Start with observable evidence.
2. Ask only questions that help narrow the possibilities.
3. Make the reasoning understandable.

My Role & Responsibilities

As the sole designer of RootCause, I did everything from research and problem definition to information architecture, interaction design, visual design, and prototyping.

User Research

Starting With Real Plant Owners

Before designing the diagnosis flow, I wanted to understand what people actually do when a plant starts looking unhealthy.

Because this was a self-initiated project, I conducted three exploratory interviews with people who regularly care for houseplants: my mother and two plant owners from my neighborhood.

This wasn’t enough to make statistically representative claims, so I treated the research as exploratory. The goal was to uncover behaviors, frustrations, and decision-making patterns that could shape the first version of RootCause.

Rather than asking, “What features would you want in a plant-care app?”, I asked participants to walk me through what they actually do.

I explored questions around:

• How they notice something is wrong
• What they do first
• How they search for causes
• Where they get advice
• How they decide what to trust
• What happens when different advice conflicts
• How they know whether treatment is working

That revealed a more interesting problem than I initially expected.

From Research to Opportunity

The interviews didn’t give me a feature list.

They showed me where the existing process breaks down.

People can usually observe that something is wrong. The harder part is connecting those observations to a plausible cause and deciding what to do next.

That became the opportunity:

Instead of giving users a black-box answer, could RootCause help them narrow down what is happening — and understand why?

User Personas

To translate the research into clear user needs, I created three personas representing different levels of plant-care knowledge and different reasons for seeking help. Together, they helped me design for more than just the “beginner” user.

Key Insights

01 — Users have different levels of plant-care knowledge
Some need simple, step-by-step guidance, while others want deeper explanations and more control over their plant’s health.

02 — Identifying the problem is only part of the journey
Users want to understand why their plant is unhealthy and whether the treatment they’re following is actually working.

03 — Generic advice creates uncertainty
Conflicting information and advice that doesn’t match a plant’s specific condition make it difficult for users to know what to trust.

04 — Users need ongoing support, not just a diagnosis
Beyond identifying a problem, users want to monitor their plant’s health and know whether it’s improving over time.

Understanding the Competitive Landscape

I compared existing plant diagnosis and care apps across their diagnosis approach, features, user experience, and level of guidance.

The goal wasn’t to build a feature checklist or compete with every capability. I wanted to understand where existing experiences were already strong and where RootCause could take a different approach.

Note: This competitive audit is based on my hands-on review of the apps and Play Store user reviews. Some features were paywalled or inaccessible, so the findings should be treated as directional rather than a definitive source of truth.

The analysis reinforced an important point: Photo-based identification, diagnosis, care advice, and follow-up questions were already common patterns.

So building another app around:

Upload a photo → get a diagnosis

wouldn’t give RootCause a meaningful point of difference.

The opportunity wasn’t another feature. It was the diagnostic experience itself.

Ideation

From “Give Me an Answer” to “Help Me Figure It Out”

My first approach was to show users several possible causes and then let them narrow them down.

But when I mapped the interaction, I noticed a problem:

Answer questions → See possible causes → Answer more questions → Get the actual result

The user had already spent effort describing the plant. Asking them to participate in another explicit diagnostic stage meant the product was effectively making them do part of the reasoning themselves.

I initially treated the Diagnostic Fork as a dedicated screen — a point where two or more plausible causes overlap and the system needs another piece of evidence to distinguish between them.

But the more I looked at it from the user’s perspective, the less sense it made to expose this as another step. The user doesn’t need to know that the system has reached a diagnostic fork; they just need to know what to check next.

So I moved the diagnostic logic* behind the interface.

Instead of:

Possible causes → Diagnostic Fork → Next Best Check

The experience became:

Adaptive questions → Detect ambiguity → Ask the next useful question → Update reasoning → Show refined result

This meant RootCause could handle the complexity of narrowing down possible causes without making users navigate the diagnostic process themselves.

The system does the reasoning. The user provides the evidence.

This shift became one of the core principles behind the final diagnostic experience.

*The diagnostic logic would require a knowledge base of plant symptoms and causes combined with a rules- or model-based reasoning system. The exact technical implementation would need to be validated with engineering and plant-science expertise.

Adaptive Questions Instead of a Long Questionnaire

A longer questionnaire might collect more information, but it also creates more friction.

I wanted the questions to respond to what the user had already told the system.

For example:

Leaves + Soil
Yellowing + Drooping
Soil is very wet

↓

How long has the soil stayed wet after watering?

↓

Depending on the answer:

Do you notice an unusual smell near the soil?

If the answer doesn’t indicate a possible root problem, there’s no reason to ask the user to inspect the roots.

The principle was:

More questions when necessary, not more questions by default.

Designing for Uncertainty

One of the easiest ways to make a diagnostic product look intelligent is to give it a precise answer.

But precision and certainty aren’t the same thing.

If the available evidence can’t distinguish between root rot and overwatering, showing:

Root Rot — 87%

creates a level of confidence that the evidence may not justify.

So I deliberately avoided arbitrary confidence percentages.

Instead, RootCause uses a hierarchy:

Strongest match
Medium match
Low Match

And when the evidence isn’t sufficient:

“We need more information.”

The goal isn’t to make the product sound less capable. It’s to make its limitations understandable.

The Final Design Direction

These decisions brought the experience to a much clearer model:

RootCause should do the diagnostic work behind the scenes and ask the user only for the evidence it actually needs.

Final User flow

Turning the Logic Into an Experience

Once the flow was established, I translated the underlying idea into a few concrete interaction decisions.

01 — Start with what users can observe

Users begin with affected areas and visible symptoms rather than trying to diagnose the problem themselves.

02 — Ask one useful question at a time

Questions adapt to previous answers, collecting only the information needed to narrow down the possibilities.

03 — Don’t force physical checks

Users can choose “I can’t check” when a physical observation isn’t possible, allowing the diagnosis to continue without forcing an invasive action.

04 — Show the refined result, not an unfinished diagnosis

I removed the standalone Preliminary Possible Causes (refer to Fig. 5) step so users receive a refined result after the system has done the reasoning.

The “Show why?” interaction reveals the evidence supporting a result, what doesn’t match, and what couldn’t be verified — so users can understand the reasoning instead of blindly trusting the result.

05 — Continue beyond diagnosis

The experience continues into treatment and recovery tracking, with previous evidence available for reassessment if the plant gets worse.

Visual Design

Once the interaction model was established, I translated it into a visual language that feels calm, approachable, and trustworthy.

High-Fidelity Prototype

I translated the validated design direction into a high-fidelity prototype, bringing together the diagnostic flow, adaptive interactions, visual system, and microcopy into a cohesive end-to-end experience. The prototype demonstrates how RootCause guides users from identifying symptoms to understanding possible causes, taking action, and tracking recovery.

Accessibility Considerations

Accessibility was considered as part of the interaction rather than as a final checklist.

• Color-independent communication: Labels, icons, and visual states alongside color.
• Readable content: Clear typography, contrast, spacing, and straightforward language.
• Accessible touch targets: Interactive elements sufficiently large and well-spaced.
• Flexible interactions: Allowed users to choose “I can’t check” instead of making physical observations mandatory.

The Final Solution

From Plant Symptoms to a Clear Next Step

The final RootCause experience brings the research and interaction decisions together into one adaptive journey.

Identify Plant → Affected Area → Symptoms → Adaptive Questions → Review Analysis → Refined Results → Evidence Explanation → Treatment → Recovery

But the important part isn’t the number of screens.

It’s what happens between them.

The experience responds to the information the user provides, asks for additional evidence only when necessary, and avoids presenting certainty when the evidence doesn’t support it.

Click here to view the prototype in Figma.

Impact

What RootCause Is Designed to Change

RootCause is a self-initiated concept, not a live product, so I can’t claim improvements in accuracy, task completion, or user satisfaction.

Instead, the impact of the concept lies in how it changes the proposed experience.

The traditional journey is:

Notice → Search → Guess → Treat → Hope

RootCause proposes:

Observe → Answer relevant questions → Narrow the possibilities → Understand the evidence → Act → Track recovery

The product takes responsibility for deciding what information matters next, while keeping the reasoning understandable to the user.

It also extends the experience beyond the initial result, creating a loop between diagnosis, treatment, and recovery.

Key Takeaways

The biggest thing I learned from RootCause wasn’t about plant care.

It was about designing experiences around uncertainty.

I initially approached the problem as:

How do I design an app that diagnoses a plant?

By the end, the question had become:

How do I design an experience that helps someone make a good decision when the answer isn’t immediately obvious?

That shift changed the way I approached the entire product — from the questions users answer to the way results are explained and what happens after treatment begins.

RootCause ultimately became less about designing a plant-diagnosis interface and more about designing a trustworthy decision-making experience.

What I’d improve next

RootCause hasn’t been formally usability tested yet. That means the final interface should be treated as a design hypothesis, not a validated solution.

The next round of research would focus on:

• Whether adaptive questions feel helpful or confusing
• Whether users understand why certain questions are being asked
• Whether Strongest match / Medium Match / Low Match communicates uncertainty clearly
• Whether users understand the Evidence Explanation
• Whether recovery tracking provides enough value to return to the product
• Whether the overall diagnostic journey actually reduces perceived guesswork

The most important thing to validate is whether the underlying troubleshooting model actually helps people make better decisions.

Thank you for reading!

UX case study: Designing RootCause to make plant diagnosis less of a guessing game was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.