# Answer Guide: Product Critique and Behavioral Deep-Dive ## 1. Product Critique Example: Calendar Time-Zone Handling ### Users and Job to Be Done Users: - Knowledge workers. - Executive assistants. - Distributed teams. - Travelers. Job: - Schedule and attend meetings across time zones without confusion. ### What Is Poorly Designed Common pain points: - Events appear to shift when traveling. - Users do not know whether an event is fixed to a location's time zone or floating with their device. - Daylight saving time creates mistakes. - Participants in different regions see confusing times. - All-day events can appear on the wrong day. ### Evidence I Would Look For - Percentage of multi-time-zone events edited within 24 hours for time-only corrections. - Support tickets mentioning time zone or daylight saving. - Missed or late meeting reports. - User research showing low confidence when scheduling across regions. - Time to schedule meetings with three or more time zones. ### Root Causes - Ambiguous mental model. - Poor visibility into participant local times. - Weak warnings around daylight saving changes. - Complex standards and OS calendar behavior. ### Improvements MVP: - Add a clear "locked to time zone" versus "floating time" label. - Show participant local times while scheduling. - Add warnings for daylight saving transitions. - Improve all-day event handling. - Provide clearer edit history when time zones change. Later: - Smart suggestions for globally friendly meeting times. - Stronger travel mode handling. - Team working-hours intelligence. ### Metrics Primary: - Reduction in time-related edits after event creation. Secondary: - Scheduling completion rate. - Time to schedule. - Support tickets. - User confidence survey. Guardrails: - Event creation time. - UI complexity. - Calendar latency. ### Trade-offs - More explicit time-zone controls can increase UI complexity. - Automation can be wrong, so the user needs control. - Cross-platform calendar standards may limit behavior. ## 2. Going Above and Beyond Use STARL. Example: **Situation:** A customer-facing onboarding flow was causing new users to fail setup, and support teams were manually helping customers complete the process. **Task:** My formal scope was to improve the onboarding UI, but I saw that the bigger user problem included support handoff, documentation, and missing instrumentation. **Action:** I went beyond the UI change by shadowing support calls, reading tickets, building a funnel dashboard, and creating a quick-start checklist with support. I also worked with engineering to add event tracking so we could see which step caused failures. Instead of redesigning the entire flow, we fixed the highest-friction step and gave support a better playbook. **Result:** Setup completion improved, support contacts decreased, and the team gained a dashboard for future onboarding work. **Learning:** Going above and beyond should not mean unsustainable heroics. It should mean expanding the problem definition when users are blocked by more than the product surface. ## 3. Disagreement Resolved with Metrics Example: **Situation:** Design wanted to simplify a product page by removing detailed configuration text. Sales wanted to keep all details because enterprise buyers asked many questions. The team was stuck. **Task:** I needed to resolve the disagreement without turning it into a taste debate. **Action:** I reframed the question as: which version helps qualified users complete the next step with confidence? We defined metrics: demo request conversion, scroll depth, FAQ clicks, support questions, and post-demo qualification. We tested a simplified page with progressive disclosure against the existing dense page. **Result:** The simplified page improved demo requests while progressive disclosure kept qualification quality stable. Sales concerns were addressed because the detailed information remained available to users who needed it. **Learning:** Metrics help when they are tied to the real decision. The goal was not "short page versus long page"; it was buyer confidence and qualified conversion. ## 4. Tips for These Prompts - Lead with the user. - Define evidence. - Make trade-offs explicit. - Use one primary metric and guardrails. - For behavioral stories, explain what you personally did. - End with learning.