How to use Feathery conditional logic for smarter user journeys

If you’ve got a form or onboarding flow, you want it to feel like it “gets” your users—not like it’s making them slog through questions that don’t apply. This is where conditional logic comes in. If you’re using Feathery, you can build smarter, more responsive user journeys without writing code. But setting it up well isn’t just about flipping switches. You need to know what’s actually useful—and what’s just a distraction.

This guide is for anyone who wants to make their forms feel less like a government survey and more like a conversation. Whether you’re a product manager, designer, or just someone who wants their forms to stop scaring people away, read on.


Why Conditional Logic Matters (But Won’t Save a Bad Form)

First, a reality check: conditional logic won’t magically fix a confusing or bloated form. If your form asks too much or makes little sense, adding logic just creates a more complicated mess. The best use of conditional logic is to make good journeys even smoother—showing the right questions to the right people at the right time.

So, before you start, ask: Do I really need this question? and Who actually needs to see it? If you’re not sure, keep it simple and test.


Step 1: Map Out Your User Journeys First

Don’t jump straight into Feathery’s UI and start building rules. That’s a great way to end up with a spaghetti mess.

  • Sketch your main paths. Who are your users? What choices do they make? Where do their journeys split?
  • List the fork points. Where do you want logic to kick in? Example: “If user says they’re a student, show student-specific questions.”
  • Decide what shouldn’t happen. Sometimes, the real value is in hiding stuff that doesn’t matter to certain users.

Pro tip: Try mapping this out on paper or a whiteboard first. It’ll save you hours of rework later.


Step 2: Get to Know Feathery’s Conditional Logic Features

Feathery lets you build logic without code, but that doesn’t mean it’s all intuitive right away. Here’s what actually matters:

  • Show/Hide Rules: The bread and butter. Show a field, step, or section based on a previous answer.
  • Skip Logic: Jump users ahead if you know you don’t need to ask them certain things.
  • Field Validation: Trigger rules depending on what someone types—or doesn’t type—in a field.
  • Dynamic Branching: Route people down totally different flows, not just hiding or showing questions.

What to ignore for now: Don’t get lost in complex, nested conditions unless you know exactly why you need them. Start simple.


Step 3: Build Your First Conditional Rule

Let’s create a simple path: If a user says they’re “employed,” show job-related questions. If not, skip those.

  1. Add your base fields.
  2. Example: “Are you currently employed?” (Yes/No)
  3. Followed by: “What’s your job title?” and “Employer name.”

  4. Set up your show/hide logic.

  5. In Feathery’s editor, select the employment question.
  6. Add a rule: If answer is “Yes,” then show job title and employer fields.
  7. Add another rule: If answer is “No,” hide those fields or skip to the next relevant section.

  8. Test it live.

  9. Click through as if you’re a user.
  10. Try both choices. Make sure nothing weird happens (like both paths showing at once).

Don’t overthink it: Most of the value comes from a few well-placed rules, not dozens of edge cases.


Step 4: Use Branching to Create Smarter Flows

If you want to get fancier, you can branch entire form paths. This is great if, for example, business users and personal users need totally different info.

  • Create steps for each user type.
  • Set up a selector early on—“Are you using this for business or personal?”
  • Use Feathery’s branching logic to send users to the right set of steps, skipping irrelevant sections.

Warning: Branching makes maintenance harder. Keep branches shallow unless you’re willing to manage the complexity.


Step 5: Handle Validation and Error States

Conditional logic isn’t just about what to show—it’s about catching issues before they become support tickets.

  • Conditional validation: Only require certain fields if they’re shown.
  • Custom error messages: Make sure users know why they can’t move forward (e.g., “Please enter your job title if employed.”)
  • Disable/enable buttons: Don’t let users proceed if they skip a required, conditionally-shown field.

Common gotcha: Don’t forget to test what happens when users change their answers. Fields that were shown and filled in might get hidden, but their data could still be lurking in the background.


Step 6: Keep it Simple—and Test With Real Users

You can build wild logic trees in Feathery, but more logic means more things can break or confuse people.

  • Test with a few users. Ask them to click through, and watch where they get lost or annoyed.
  • Check analytics. Where do people drop off? Sometimes your logic hides key info or makes the path too weird.
  • Iterate, don’t overbuild. Start with the basics, then add rules as you see real needs.

Pro tip: Every rule you add is another thing to document and maintain. Only add what solves a real problem.


What Works (And What’s Overkill)

What’s worth your time: - Using show/hide logic to avoid overwhelming users with irrelevant questions. - Branching when the user types are truly different (think business vs personal, not just “likes cats vs doesn’t”). - Validating only what’s visible.

What to skip: - Deeply nested conditions unless you’re solving a specific, painful problem. - Overly clever logic that tries to anticipate every edge case. You’ll just confuse yourself and your users.

Watch out for: - Logic that’s hard to follow later. If you can’t explain it in a sentence, rethink it. - Data left behind in hidden fields. Make sure your system clears or ignores data from skipped questions.


Summary: Start Small, Stay Flexible

Conditional logic in Feathery is powerful, but don’t let it tempt you into overengineering. The best user journeys are the ones that feel simple, even if they’re a bit smart under the hood. Map out your main flows, build only the rules you need, and test with real people. Keep things lean, and you’ll spend less time untangling logic—and more time building forms that actually work.

Remember, you can always add more logic later. Start with what’s essential, and let your users show you where to go next.