Technical illustration showing how user choices flow through decision logic to create a personalized pet-health experience using EverBowl and connected pet-health signals

From User Choices to Personalized Recommendations: Designing the Decision Logic

10 Sep 2026 By Shreya P T

When I first started looking at this problem, it looked like a simple UI improvement. The idea was straightforward: instead of asking users to understand everything about the product themselves, we could ask a few simple questions and use their answers to guide them toward a more relevant experience. But once I started breaking it down, I realized the interesting part wasn't the UI. The interesting part was the decision logic behind it. How do we take a few human answers and turn them into a recommendation that actually makes sense? That became the problem I wanted to solve.

Starting With the User, Not the Features

One thing I noticed while thinking through the experience was that users don't necessarily think about a product the same way we do internally. As developers, we might think in terms of That difference matters. If we build the decision flow around our internal feature list, the user may have to understand the product before they can make a decision. Instead, I wanted the flow to start with the user's needs. So the basic architecture became:

User Need
    ↓
User Questions
    ↓
Collected Answers
    ↓
Decision Logic
    ↓
Recommendation
    ↓
Next Action

The First Challenge: What Should We Ask?

My first instinct could have been to collect as much information as possible. But that quickly creates another problem. More questions don't automatically mean better personalization. If a user has to answer ten or fifteen questions before seeing anything useful, the personalization itself becomes friction. So I started thinking about the questions differently. That became an important design rule. If an answer doesn't affect the final decision, there is probably no reason to ask for it at that point.

For example, the flow could ask about:

What the user wants to monitor
Whether they want additional guidance
How many dogs they have
Whether they are mainly interested in community/AI support or a more complete connected experience

Turning User Answers Into Data

Once the questions are defined, the next step is converting the answers into something the system can actually work with. At this point, we're no longer dealing with a conversation. We're dealing with structured data. That is where the technical side starts becoming important. The UI collects the information, but the decision layer shouldn't need to know anything about buttons, screens, or how the user selected an option. It should simply receive structured input.

Separating UI From Decision Logic

One thing I would strongly avoid is putting all of the recommendation conditions directly inside the UI. For example, imagine having conditions like this scattered across different screens: As the number of conditions grows, this becomes difficult to reason about. Instead, I would keep the responsibilities separate:

UI Layer
    ↓
Collect answers

Decision Layer
    ↓
Evaluate answers

Recommendation Layer
    ↓
Return recommendation

UI Layer
    ↓
Display result

This makes the system easier to test and easier to change later. If the recommendation rules change, we shouldn't have to rewrite the entire UI.

Designing for Future Changes

Another thing I considered was what happens six months from now. The product may change. New capabilities may be added. Existing features may be removed. If the decision logic is tightly coupled to the UI, every product change can become a development problem. A better structure is to keep the rules centralized.

For example:

User answers
      ↓
Recommendation Engine
      ↓
Recommendation ID
      ↓
UI configuration
      ↓
Screen

Now the UI doesn't need to understand every business rule.

It only needs to know what recommendation it received and how to display it.

This makes the system more flexible.

Testing the Decision Logic

Once we have decision rules, we also need to test the combinations.

This is where I think the technical side becomes particularly important.

For example:

Test Case 1

Input:
monitoring = false
guidance = false

Expected:
basic experience

Edge Cases Are Where Things Get Interesting

The happy path is usually easy. The real questions appear with edge cases.

What happens if the user goes backward?

What happens if they change an answer?

What happens if they skip a question?

What happens if two answers appear to point toward different recommendations?

What happens if a new question is added later?

These questions are important because a recommendation flow is still a stateful user experience.

For example:

Question 1
   ↓
Question 2
   ↓
Question 3
   ↓
Recommendation

If the user goes back and changes Question 1, the recommendation should be recalculated. We shouldn't simply keep showing the previous result. That means the recommendation should be derived from the current state, rather than stored as something permanent from an earlier step.

Keeping the State Clean

Conceptually, the flow can maintain one state object:

UserState

{
    monitoring: true,
    guidance: false,
    dog_count: 1
}

Every answer updates that state. Then the recommendation is calculated from the current state:

UserState
    ↓
Decision Engine
    ↓
Recommendation

If we know exactly which user inputs should lead to which recommendation, a rules-based system can be a very good starting point. AI could become useful for other parts of the experience, but the core recommendation doesn't necessarily need to be complicated. Sometimes a well-designed decision tree is enough.

What I Learned From Working Through This

What initially looked like a small UX improvement turned into a useful lesson in system design. I started thinking about questions and screens. I ended up thinking about:

Input
  ↓
State
  ↓
Decision Rules
  ↓
Recommendation
  ↓
Explanation
  ↓
User Action

That shift was important for me. It made me realize that even a small personalized experience can benefit from the same engineering principles we use elsewhere:

separation of concerns, predictable logic, state management, testability, and clear interfaces between components.

The UI is only the visible part. The real experience is created by what happens underneath it. A personalized experience doesn't have to be complicated. The challenge is not asking users more questions. The challenge is asking the right questions and turning those answers into decisions that are easy for both the user and the system to understand. For me, the most useful way to think about the problem became:

Ask less.
Understand better.
Decide clearly.
Explain the recommendation.
Keep the logic maintainable.

When those pieces work together, personalization stops feeling like another form the user has to complete. Instead, it becomes a simple conversation between the user and the product. And behind that simple experience is a small, well-defined decision system doing the work.