The if-then-else framework for UX copy decisions
How to make defensible content choices using logic instead of opinion
You’re staring at a sign-up button.
Should it say “Sign up,” “Get started,” “Create account,” or “Continue”?
Your PM wants one thing. Your designer suggests another. You have your own opinion. Everyone’s confident. Nobody has a reason.
The meeting drags on. Someone says “let’s A/B test it” (even though you don’t have the traffic). Someone else says “what does the data say?” (there is no data yet). Eventually, the highest-paid person in the room decides, and everyone moves on.
This happens because we treat UX copy decisions like creative choices—matters of taste. But most copy decisions aren’t creative problems. They’re logic problems.
And engineers already have a framework for solving logic problems: if-then-else statements.
Four years of engineering school taught me to think in systems and logic. Whether it was circuits, code, or biological systems, the principle was the same: break complex problems into component parts, understand dependencies, work from first principles. That mindset turned out to be more valuable in UX writing than any writing course I ever took.
Let me show you how this changes everything.
New here? Subscribe to UX Writing Bud to get frameworks like this delivered every Friday. Free, always.
Why UX writers need decision frameworks
Here’s the uncomfortable truth: When you defend your copy with “I think it’s clearer” or “this sounds better,” you’re making a subjective argument that loses to louder voices every time.
The problem:
Copy decisions feel arbitrary
Consistency is impossible without a system
You can’t explain why different contexts need different copy
Stakeholders override your choices because “it’s just preference”
The reality: Every piece of UI copy makes assumptions about the user’s context. Different contexts require different copy. We just rarely make these assumptions explicit.
The solution: Borrow from engineering. Make your conditional logic visible. Turn “I think this is clearer” into “IF the user is in state X, THEN we need approach Y.”
Now you have a defensible, repeatable decision-making process.
The if-then-else framework explained
Every UX copy decision follows this pattern:
IF [specific user state or context]
THEN [your copy approach]
ELSE [alternative approach]Before you write any copy, you need to answer three questions:
1. What is the user’s state?
First time vs. returning user
Logged in vs. logged out
Free tier vs. paid tier
Empty state vs. populated state
Success state vs. error state
2. What is the user’s intent?
Exploring vs. executing a specific task
Learning vs. doing
Comparing options vs. ready to commit
Urgent need vs. casual browsing
3. What is the context?
Desktop vs. mobile (space constraints)
Critical path vs. secondary feature
High stakes vs. low stakes action
Time-sensitive vs. leisurely task
The framework in action:
Before writing any copy, complete these sentences:
“The user is _____ (state)”
“They’re trying to _____ (intent)”
“This is happening _____ (context)”
Then: IF these conditions are true, THEN your copy should do X.
This isn’t about gut feeling. It’s about logic.
Real examples with if-then-else logic
Let me show you how this works in practice.
Example 1: The sign-up button
❌ Without the framework: “Should it say ‘Sign up’ or ‘Get started’? Let’s debate for 20 minutes.”
✅ With the framework:
IF user is on homepage (not yet committed)
AND this is their first visit (low familiarity)
AND we offer a free trial (low barrier)
THEN use “Get started” (implies ease, journey)
ELSE IF user is on pricing page (already interested)
AND they selected a paid plan (high commitment)
THEN use “Create account” (sets clear expectation)The result:
Homepage CTA: “Get started free”
Pricing page CTA: “Create account”
Why it works: Different contexts, different user states, different copy. Not taste—logic.
Example 2: Password field error
❌ Without the framework: “Password must be 8+ characters” (what everyone writes)
✅ With the framework:
IF user is creating account (first time)
AND they haven’t submitted yet (proactive help)
THEN show requirements as inline help text below field
Example: “Password must be at least 8 characters”
ELSE IF user tried to submit (error occurred)
AND password is too short (specific problem)
THEN show “Password must be at least 8 characters. Currently: 5 characters.”
(Specific, actionable, shows progress)
ELSE IF user tried to submit (error occurred)
AND password is missing special character (different problem)
THEN show “Password needs 1 special character (!@#$%^&*)”
(Specific, gives examples)Why it works: The same requirement needs different copy depending on when and why the user sees it. The logic determines the words.
Example 3: Empty state message
IF user just signed up (first-time empty state)
AND account is completely new (no data yet)
THEN show onboarding-style message
“Ready to create your first project? Click ‘New project’ to begin.”
ELSE IF user deleted all projects (user-cleared empty)
AND they’re an active user (has history)
THEN show positive acknowledgment
“All clear! Start fresh with a new project.”
ELSE IF user’s filter returned no results (temporary empty)
AND they have projects (just none matching filter)
THEN show helpful guidance
“No projects match your filter. Try adjusting your search or clear filters.”Why it works: Same screen, wildly different user contexts, therefore different copy needs. The if-then-else logic makes these distinctions explicit.
Common if-then-else patterns you can steal
Here are patterns I use constantly. Steal them.
Pattern 1: The familiarity scale
IF first-time user
THEN explain what this does + why it matters
“Create project: Start organizing your work in one place”
ELSE IF occasional user
THEN brief reminder + direct action
“Create project”
ELSE IF power user
THEN just the action, minimal text
“New project” (they know what it does)Where to use it: Tooltips, inline help, feature announcements, any instructional copy.
Pattern 2: The commitment level
IF low commitment action (free, reversible)
THEN encouraging, casual tone
“Give it a try”
ELSE IF medium commitment (some investment)
THEN clear expectations
“This will take about 5 minutes”
ELSE IF high commitment (money, data, time)
THEN build confidence, reduce anxiety
“Your data stays private. Cancel anytime.”Where to use it: CTAs, confirmation messages, upgrade prompts, any action that asks something of the user.
Pattern 3: The error severity scale
IF minor error (easy to fix)
THEN brief, helpful
“Oops, that email format didn’t work. Try again.”
ELSE IF medium error (some complexity)
THEN specific guidance
“This email is already registered. Try signing in instead, or use a different email.”
ELSE IF critical error (blocks progress completely)
THEN reassure + clear next steps
“We couldn’t process your payment. Your card wasn’t charged. Please check your card details and try again, or contact us at support@...”Where to use it: All error messages. The severity determines how much information and reassurance to provide.
Pattern 4: The context-specific CTA
IF user is browsing (low intent)
THEN “Learn more” or “Explore”
ELSE IF user engaged with content (medium intent)
THEN “See how it works” or “Get started”
ELSE IF user on conversion page (high intent)
THEN “Buy now” or “Create account”Where to use it: Every button, every link. Match the CTA to where they are in their journey.
How to document your if-then-else logic
Don’t keep this framework in your head. Document it so others can use it too.
Create a simple decision doc for any pattern you use frequently:
PATTERN: Sign-up confirmation messages
VARIABLES:
- User source (organic vs. referral vs. ad)
- Account type (free vs. trial vs. paid)
CONDITIONS:
IF organic sign-up + free account
THEN “Welcome! You’re all set to start using [Product].”
BECAUSE they found us naturally; confirm success simply
ELSE IF referral sign-up + free account
THEN “Welcome! [Referrer] thought you’d love [Product]. Here’s what to try first...”
BECAUSE social proof + guidance increases activation
ELSE IF paid sign-up
THEN “Welcome! Your account is active. Here’s how to get the most from your subscription...”
BECAUSE they paid; emphasize value immediately
EXAMPLES:
[Screenshots of each variation]Why this matters:
When you document the logic:
Other writers can apply your reasoning
Designers understand your thinking
PMs can’t override with “I just like it better”
Your copy stays consistent as the product scales
The framework becomes the system.
Now you try: Interactive exercise
Here are three scenarios. Apply the if-then-else framework before I show you my reasoning.
Scenario 1: Shopping cart button
User added 1 item to cart
User is on mobile device
User is still browsing (not ready to checkout)
What should the cart button say?
Scenario 2: Account settings confirmation
User just changed their email address
This is a security-sensitive change
They need to verify the new email
What’s the confirmation message?
Scenario 3: Feature announcement banner
New feature just launched
Power users will love it
New users won’t understand it yet
How do you announce it to both groups?
Your task: Write out your IF-THEN-ELSE logic for each scenario. What variables matter? What conditions drive your copy choices?
Take 5 minutes. Actually try it. I’ll wait.
Exercise solutions
Ready? Here’s how I’d approach each one:
Scenario 1: Shopping cart button
IF mobile (limited space)
AND browsing mode (not ready to buy)
AND cart not empty (show count for awareness)
THEN “Cart (1)” or cart icon with badge
BECAUSE space is limited, user isn’t in buying mode, just need awareness
ELSE IF desktop (more space available)
AND cart has items
THEN “View cart (1 item)”
BECAUSE we have space to be more explicitScenario 2: Account settings confirmation
IF security-sensitive change (email)
AND requires verification (action needed)
AND user might forget to check email
THEN “Check your email to confirm your new address: [new email]. We sent a verification link.”
BECAUSE urgency + specificity + next steps all matter for securityScenario 3: Feature announcement
IF power user (active, engaged, frequent use)
THEN “New: [Feature name] - [One-line benefit for their use case]”
BECAUSE they’ll recognize value instantly
ELSE IF new user (< 1 week old)
THEN don’t show banner yet
BECAUSE cognitive overload - they’re still learning basics
ELSE IF intermediate user (1 week - 3 months)
THEN “New: [Feature name] - [What it does] [Learn more link]”
BECAUSE they need context but are ready to exploreDid your logic match mine? It doesn’t have to. The point isn’t getting the “right” answer. It’s making your logic explicit so you can defend it, test it, and iterate on it.
Why this changes everything
Here’s the shift this framework creates:
Before:
“I think this copy is clearer”
“This sounds better to me”
Inconsistent copy across your product
Decisions based on whoever speaks loudest
After:
“Given that the user is [state] and trying to [intent], this copy addresses their needs because [logic]”
“Based on these conditions, we should use this pattern”
Logical, repeatable patterns everyone can apply
Decisions based on frameworks anyone can reference
You move from defending word choices to defending systems.
From opinions to logic.
From “I like this” to “This is correct for these conditions.”
Your homework
Pick one piece of UI copy you wrote recently. Any button, label, message, or tooltip.
Now reverse-engineer the if-then-else logic:
What user state did you assume?
What context were they in?
What was their intent?
Write it out: “IF ___, THEN ___”
Then ask yourself:
Did I get the conditions right?
Should different conditions = different copy?
Am I handling all possible user states?
Can I document this so others can apply the same logic?
This exercise will reveal gaps you didn’t know existed.
Do this once, and you’ll start seeing conditional logic everywhere in UX copy. You’ll never write the same way again.
What’s next
Next week, we’re tackling something I see native English speakers get wrong constantly: what they think is “simple” language.
As a non-native Hindi speaker working in English, I see friction where others see fluency. I catch assumptions where others see clarity. I’ll show you what you’re probably missing—and why your outsider perspective (if you have one) is actually your superpower.
Until then, think in if-then-else.
— Mansi
Related reading:
If you found this framework useful, you might also like:
Error messages that don’t frustrate users - Apply if-then-else logic to error states
Lost in translation? - How non-native speakers approach UX writing differently
Demystifying WCAG - Decision frameworks for accessible content
Found this framework useful? Here’s how to go deeper:
📬 Send me your copy decisions - Got a piece of UI copy you’re stuck on? DM with the context, and I might feature it (anonymized) in a future issue with if-then-else analysis.
🔗 Share this framework - Know a UX writer, designer, or PM who makes copy decisions?
💬 Join the conversation - Reply to this email or join Subscriber chat with your exercise results or questions. I read every response.
☕ Support this work - If this framework changed how you think about copy, buy me a coffee/book. It’s optional, but appreciated.
UX Writing Bud delivers frameworks and systems for content designers every Friday. Free, always.
Loved the framework, Mansi — I have developed a complementary framework to measure the robustness of the content decision made (or #RuleStrength) as part of my larger Content Design Playbook.
Will be writing more on it, shall incorporate yours (linking and crediting your article).