Google Behavioral Question 8: Handling Ambiguous Requirements

🎯 Best Story: Event Effect Requirements Clarification

Full STAR Answer (2.5 minutes)

Situation (30s)

In 2021, I was assigned Event Effect feature for LINE's Home tab - showing celebration animations for birthdays and holidays for 200M users across 200+ countries.

The initial requirement was deceptively simple: "Show special animation during user birthday or a holiday."

As code owner and main developer, I knew this simple statement hid many complex edge cases that could cause bad UX if not addressed early. With 200M users globally, getting requirements right was critical.

Task (25s)

My responsibility was to:

• Uncover all ambiguous scenarios before coding
• Work with stakeholders to define clear requirements
• Prevent functional bugs from unclear specs
• Ensure smooth launch for global audience

Action (80s)

Phase 1: Systematic Edge Case Discovery

I mapped out user journey and identified ambiguous situations:

Timing Questions:

• User birthday 0:00-23:59, but what if user opens app at 23:59:50? Show 4-sec animation that gets dismissed 10 seconds later at midnight?
• Which timezone? Device or server?
• Repeat animation if user closes/reopens app multiple times?

Special Date Questions:

• Users born Feb 29 (leap year) - celebrate on Feb 28 or March 1 in non-leap years?
• Birthday + holiday coincide? Show both? Prioritize?

Content Management:

• Can events be cancelled last-minute (national emergency)?
• Can animations be updated after scheduling?
• How handle 200+ countries with different holidays?

Technical Edge Cases:

• Animation fails to download (poor network)?
• Slow device handling?
• File size management?

Phase 2: Stakeholder Collaboration

Organized requirements alignment meeting with PM, Design (Korea), QA, Server team.

Presented each edge case with "What should happen?" questions + proposed default behaviors based on best UX.

Discussion revealed 15+ scenarios not addressed in initial requirement.

Phase 3: Documentation

• Broke feature into clear phases with defined input/output
• Documented decision records for each edge case
• Created systematic breakdown
• Wrote technical blog post sharing engineering approach

Result (30s)

✅ Zero ambiguity-related bugs at launch

✅ Smooth launch on time with clear specs

✅ Strong stakeholder alignment - everyone understood edge cases

✅ Scalable system - easy to add new event types

✅ Knowledge sharing - blog post became reference for other teams

✅ Built trust - PM/designers appreciated thoroughness, improved future collaboration

Learning: "Asking 'what if?' early saves weeks of rework later. Systematic edge case mapping prevents functional bugs and builds stakeholder confidence."

Key Follow-Up Q&A

Q: "How did you prioritize which edge cases to focus on?"

"I used a simple prioritization framework:

1. User Impact - Does this directly affect user experience?

2. Frequency - How often will this happen?

3. Technical Risk - Could this cause crashes or data corruption?

Examples:

February 29 birthday:

• User impact: HIGH (user expects birthday celebration)
• Frequency: LOW (0.07% of users)
• Risk: MEDIUM (functional bug, no crash)
• Decision: Must clarify - visible to affected users

App reopening during birthday:

• User impact: LOW (acceptable to show again)
• Frequency: HIGH (users often close/reopen)
• Risk: LOW (just annoyance)
• Decision: Lower priority - document but accept

I shared this matrix with PM so we could focus efficiently on high-impact scenarios.

The principle: Not all edge cases are equal. Prioritize by impact × frequency × risk."

Q: "What if PM couldn't give clear answers?"

"If PM was uncertain, I would:

1. Propose Default Behavior

Based on best UX and technical simplicity

2. Document Assumptions Clearly

So everyone knows what we're building

3. Make Code Flexible

Easy to adjust later based on real data

4. Add Analytics

Measure actual user behavior after launch

5. Plan for Iteration

Adjust in next sprint based on data

Example:

For Feb 29 birthdays, if uncertain:

'Default to March 1st (closer to actual birthday). Document clearly, add analytics for affected users, adjust in v2 if data shows users prefer Feb 28.'

The key: Making a documented decision beats paralysis. You can always iterate.

The principle: When perfect information isn't available, make the best decision with what you have and plan to learn."

📚 Full Version: /mnt/project/11_Event_Effect_Ambiguous_Requirements_and_Memory_Crisis.md