theAsianParent — Email & Mobile Verification

TABLE OF CONTENTS

1. Company Overview (Page 2)
2. Objectives (Pages 3–4)
3. Why — Reasons to Run the Project (Page 5)
4. Result Achieved (Page 6)
5. Previous Exploration Analysis (Pages 7–9)
6. Requirements and HMW's (Pages 10–13)
7. Market Analysis (Pages 14–16)
8. Explorations — Ideation Workshop (Pages 17–18)
9. Design Thinking — Constraints, User Flow & Top Tasks (Pages 19–22)
10. Key Solutions — Final Designs (Pages 23–25)
11. Usability Testing (Pages 26–31)
12. Next Step — Profile Completion (Page 32)
13. Image Scan Findings — Visual Layer Analysis
14. Second-Order Thinking
15. Third-Order Thinking

1. Company Overview

(Page 2)

theAsianParent is the No. 1 Content, Community & Commerce Destination for Parents in emerging Southeast Asia markets.

Visual observation (Page 2): The slide uses a clean, minimal white layout with the brand name prominently in blue at the top. The tagline and mission statement are left-aligned. The absence of any product imagery on this slide signals a thought-leadership, solution-driven presentation tone rather than a purely marketing-focused one.

2. Objectives

(Pages 3–4)

Section Header Slide (Page 3)

• Section number: 01
• Title: Objectives
• Background: Muted lavender/periwinkle — used consistently throughout all section dividers to distinguish structural navigation from content slides.

Project Objective (Page 4)

Core goals identified:

• Build a robust OTP verification system covering both email and mobile number inputs
• Reduce invalid/fake user data at the point of registration
• Protect lead generation pipelines and revenue flow
• Improve overall data hygiene at a platform-wide level

3. Why — Reasons to Run the Project

(Page 5)

Section label: "Reason to run the project"

Six strategic pillars were articulated to justify the initiative:

3.1 Verified Data

3.2 Drive Business

• Lead Generation Revenue & Data Hygiene
• Unclean, unverified data was putting a material share of lead-generation revenue at risk by polluting campaign targeting, conversion metrics and sales follow-up. The financial case was sized internally; the public takeaway is that verification moved from a cost centre to a revenue-protection priority.

3.3 Improve Impact of PPC Campaigns

3.4 Improve Deliverability

3.5 Avoid Distraction of Sales Team

3.6 Reduce the Marketing Cost

Visual observation (Page 5): The right-side dark-navy card uses six green icons for each pillar — a checkmark badge, upward bar chart, megaphone, envelope, person-with-settings, and a dollar coin. This visual hierarchy reinforces the multi-dimensional business impact of the problem and anchors the emotional case for urgency. The dark background card on a white background creates strong contrast and attention-drawing weight.

4. Result Achieved

(Page 6)

Section label: "We got the outcome of the module in terms of verified email and mobile leads"

Headline Metric:

Dashboard Data (visible from analytics tool — likely Amplitude/Mixpanel/internal BI):

Visual observation (Page 6): A real screenshot of a profile completion analytics dashboard is embedded — the tool shows filters for User Country, User Signup Date, User Verification Date, User Stage, and City. The dashboard shows data published live ("PUBLISHED" label visible). The split between Email OTP Verified (216,699) vs Phone OTP Verified (77,789) is particularly notable — email OTP was nearly 2.8× more popular than phone OTP among verified users.

Closing prompt on slide: "Ok, but how did I actually get there?" — signals the deck then transitions from outcome to process.

5. Previous Exploration Analysis

(Pages 7–9)

Section Header Slide (Page 7)

• Section number: 02
• Title: Previous Exploration Analysis

Previous Exploration 1 & 2 (Page 8)

Finding 1: Non-Verified Email Addresses and Mobile Numbers

The platform previously displayed a "Not verified" badge next to mobile numbers (e.g., 8655309919) in user profile screens with a "Verify mobile number" CTA, but did not enforce or gate any experience behind verification completion.

Finding 2: Profile completion widgets throughout the app

Multiple scattered widgets across different app contexts promoted profile completion:

• Home screen profile progress widget (e.g., "40% profile complete — More 40% for rewards")
• In-feed prompts: "Add Mobile Number", "Add Address", "Get Blue Tick", "10 Rewards Points"
• Community Q&A sidebar: "Profile completion 50% — Complete now"
• Multiple reward CTA variants: TAP Contests, 10 Rewards Points, Blue Tick

Visual observation (Page 8):

• Screen 1 shows the user's full profile page (Akshay Borhade, Platinum + VIP Member, Singapore/English, 40% profile complete). The "Add Mobile Number" card is visible as a widget on the profile page with a blue "Verify mobile number" CTA button.
• Screen 2 shows a contact details form with phone number 8655309919 and a red "Not verified" indicator alongside the number — indicating the system recorded an unverified number but did not block the user from saving it.
• Screen 3 shows the theAsianParent community feed view with a floating "Profile completion 50%" bar near the bottom, offering three incentives: Get Blue Tick, 10 TAP Points, More Rewards.

Key UX issues visible in screenshots:

• Verification was entirely optional and incentive-driven rather than required
• Multiple inconsistent UI entry points for profile completion existed across surfaces
• The "Not verified" label is visually subtle (small red text), insufficient as a blocker
• No gates — a user could continue using the platform fully with an unverified number

Previous Exploration 3 (Page 9)

Finding 3: Multiple registration processes within the app and web

Three distinct signup/registration pathways existed in parallel:

1. VIParent Signup — a specialized onboarding flow requesting Full Name, Email Address, Phone Number, Address Line 1, Address Line 2, Pincode, City/State/Country, plus personal details. Progress bar shows 20% profile complete.
2. Phone Contact Edit Screen — A separate profile editing screen where phone number is listed as 8655309919 with a "Not verified" red badge and a "Verify mobile number" button separate from the main signup flow.
3. General Edit Profile Screen — A standard profile editing form with Personal Details fields: Full Name, Gender, Email, Date of Birth, Mobile Number, Marital Status, Short Bio — with an "Update Profile" green CTA button.

Visual observation (Page 9):

• Each of the three screens uses a different visual language and form structure
• The VIParent Signup has a blue progress bar and section-by-section layout
• The Phone Contact screen uses icon-based field labeling (phone/education/work icons)
• The Edit Profile screen is a simple linear form
• None of the three screens share a unified design language, indicating organic, siloed development over time rather than a cohesive design system

6. Requirements and HMW's

(Pages 10–13)

Section Header Slide (Page 10)

• Section number: 03
• Title: Requirements and HMW's

Requirements (Page 11)

"Things we must figure out and ensure"

Five core requirements:

1. Strong Customer Authentication & KPIs: Ensure users complete verification to support Strong Customer Authentication standards and help reach platform KPIs, making it easier to scale.

2. Simplified Onboarding & Acquisition: Ensure to simplify onboarding and acquisition processes when bringing on new users, no matter the initiative or campaign driving those results.

3. Higher Conversion Rates: Reduce churn and loss of users during registration; remove any duplicated signups and logins.

4. Lead Generations: "This unclean and unauthenticated user data is adversely affecting Lead Generation and causing Revenue loss, as non-verified leads hinder the effectiveness of our outreach efforts."

5. Single Platform: Create a single platform for all registration processes in the app.

Visual observation (Page 11): The requirements are styled using blue hyperlink-style highlight text for key phrases (Strong Customer Authentication, onboarding and acquisition processes, Higher conversion rates, Lead generations, single platform), creating a visual emphasis hierarchy. The slide uses two cards: a dark left card for context label, white right card for content.

HMW's — Set 1: Data Verification & Drive Business (Page 12)

Data Verification — Problem/HMW pair 1:

• Problem: In the past there were no verified data in the portal that impacted on data hygiene and created trash data.
• HMW: How might we implement a user-friendly verification process which will help in data hygiene and authentic user data?

Data Verification — Problem/HMW pair 2:

• Problem: User should be able to do verification and registration process through email and mobile within stipulated timeframe.
• HMW: How might we ensure that all checks are in place in case of different set of failures or errors at the time of verification and registration?

Drive Business — Problem/HMW pair:

• Problem: In the past due to the fake emails and invalid mobile numbers it impacted on companies overall metrics.
• HMW: How might we measure the success of the verification process and its impact on Lead Generation and Revenue?

Improve Deliverability — Problem/HMW pair:

• Problem: In the past the emails weren't being delivered to target audiences because the email addresses weren't valid, that led to high email bounce rates and low deliverability.
• HMW: How might we identify and filter out invalid or fake data efficiently and improve its deliverability?

HMW's — Set 2: PPC, Marketing Cost & Sales (Page 13)

Impact of PPC Campaigns — Problem/HMW pair:

• Problem: Low-quality emails don't prevent higher-quality leads from seeing the ad, it can give a false idea about how many people your campaign could actually be reaching.
• HMW: How might we incentivize users to provide accurate and authentic information?

Reduce Marketing Cost — Problem/HMW pair:

• Problem: Large, unmaintained email list increased companies costs, and ROI went down.
• HMW: How might we continuously monitor and update user data for ongoing accuracy?

Avoid Distraction of Sales Team — Problem/HMW pair:

• Problem: Want team to focus on the right revenue acceleration opportunities.
• HMW: How might we ensure lead scoring that can certainly help sales team to focus on the right people to pursue most?

Visual observation (Pages 12–13): Problem statements are rendered in dark navy card tiles. HMW question answers are rendered in a contrasting periwinkle/blue tile directly below each problem. This problem→solution pairing format creates cognitive alignment between what was broken and what direction to explore. Two sets of HMWs cover six strategic business dimensions: Data Verification, Drive Business, Deliverability, PPC Campaigns, Marketing Cost, Sales Focus.

7. Market Analysis

(Pages 14–16)

Section Header Slide (Page 14)

• Section number: 04
• Title: Market Analysis

Market Analysis by Pattern & Inspiration (Page 15)

Apps studied (Group 1 — Hard-gate verification):

• BabyChakra — Requires mobile number OTP before any app access. OTP screen shown with 4-digit input and "RESEND" option.
• iMumz — Google Sign-In driven; social login as primary registration mechanism, positions itself as "iMumz makes your pregnancy Easier." No separate OTP for email.
• Mylo — "Mylo is only for verified users — Please login to continue." Hard gate — no exploration without verification.
• Ni Hao Community — Requires phone number login; social login with Facebook/phone visible; prompts OTP for account verification.
• What to Expect (iedname) — Quick onboarding with Email/Password, social login (Google/Facebook), consent checkboxes for health data processing. Registration-forward approach.

Takeaway (annotated in deck):

Apps studied (Group 2 — Soft-gate / explorable without verification):

• BabyCentre — Allows email/password signup, social logins (Google, Facebook), and explicit "Continue without an account" option. Verification is not mandatory to explore.
• Pregnancy+ — "Welcome to Pregnancy+" with email, Google, and Facebook login options. Users can explore without full verification.

Takeaway:

Apps studied (Group 3 — Smart Verification UX patterns):

• Expensify — Checks email in their database; if user doesn't exist, asks to continue with verification with present email address or phone number. Has clear message and CTA, guides first-time users with pop-up messages.
• First Cry — Verifies user data at the beginning of the registration process. If user skips, asks for verification again before any product purchase.

Visual observation (Page 15): Eight distinct app screenshots are arranged in a 2×4 grid layout at the top. Yellow annotation boxes are positioned below each column grouping with summary insights. The clear visual contrast between hard-gate apps (dark blue border frames) and soft-gate apps (lighter frames) demonstrates intentional visual communication. The Mylo "verified users only" screen is particularly stark — a full-screen lock wall.

Market Analysis — Second Set of Inspirations (Page 16)

Discord:

• Checks for existing account associated with phone/email; if not verified, asks for verification or removal and continuation with a new account.
• Two clear different call-to-actions on the start screen differentiate user actions (Register vs. Log In).

Binance:

• With just phone number and email address, users can view different markets, currencies, and associated news.
• Onboarding designed for both new and experienced users — accessible without full KYC at first.

Bigbasket (India):

• Switching between email and mobile in the same text field, verifying via OTP. A unified input that intelligently detects format.

Airbnb:

• Provides email validations and regex for email verification at time of signup.
• Call and OTP options available for mobile verifications.
• Clear differentiation of email and mobile given.
• Reset Password screen includes multiple password strength rules: at least 8 characters, mix of letters and symbols/numbers, can't contain name or email address.
• Social logins: Continue with Email, Continue with Facebook, Continue with Google, Continue with Apple.

LinkedIn:

• Progressive onboarding flow where the app guides users into setting up their profile step by step.
• Location, photo, and profile confirmation as layered steps after initial signup.

SoundCloud:

• Social login prioritized (Google, Facebook, Apple) over email.
• Email field highlighted less prominently, noting it likely has lower conversion due to friction.
• UX observation: "How can you identify your most popular options? With funnels, of course, but also with heatmaps."

Bigbasket Login/OTP screen (local app — right panel):

• Clear Login/Signup screen with email and "Use Mobile Number" toggle.
• After entering OTP: a green "OTP sent successfully" toast confirms action.

Visual observation (Page 16): The second market analysis slide is a dense mosaic of 12+ app screenshots across 3 columns. Yellow annotation boxes provide designer commentary. The Airbnb reset password screen is particularly instructive — showing real password strength validation UI. The SoundCloud note about heatmaps reveals data-driven thinking about UI friction at the method-selection level.

8. Explorations — Ideation Workshop

(Pages 17–18)

Section Header Slide (Page 17)

• Section number: 05
• Title: Explorations

Ideation Workshop — Q&A Format (Page 18)

The team conducted a structured ideation workshop capturing open questions (Scenarios) and corresponding resolutions (Possible Solutions). Key exchanges documented:

Q: How can we improve invalid email address text? A: Possible way — regex at client side; Educate user about invalidation on same screen.

Q: Scenario in which user has lost internet connection or app is killed when user has entered OTP and clicked on verify but verification message not arrived — is he going to lose attempts? A: Yes, user will lose attempt, as it's a problem at user end. Mail will be delivered when connection is restored but validity of OTP will have timed out.

Q: Do we really need user to enter login credentials again after creating new account? A: Yes.

Q: As a user, I want to copy OTP from email so that I don't have to enter it manually. A: Since OTP comes from email, copy-paste provides good UX. However, using UI with separate boxes it's not possible. So choosing better UX over UI, suggestion is to go with a single field for OTP where copy-paste can be used.

Q: If there is a delay in receiving OTP over email and user clicks on RESEND, will the user receive the same previous OTP or a new OTP? A: Resend means generating a new password and making the previous one invalid.

Q: Can we have a list of features that will break if there is no primary email so that we can plan for the breaking changes? A: Welcome SMS will not be sent to user; email is not a case to consider. Welcome email will be off for user who registers with mobile.

Q: Why OTP is 6 digit over 4 digit? As considering our app 4 digit seems to be enough. A: Need 6 digits — better security measure from a long-term perspective.

Q: A user might receive OTP in SPAM folder — should we inform user about this while going through email verification flow? A: Yes.

Q: Can we have OTP validity inside mail instead of having countdown? A: No. But in mailer format, time is mentioned.

Q: As a user, after requesting OTP over email, I want to understand if I have entered correct email address so that I don't waste time waiting for OTP. A: There is option of back button on OTP screen; user can go back & change the email ID.

Q: I am assuming we don't have to verify mobile number for existing users in database with both phone numbers and email address. Is my understanding correct? A: Currently for existing users it will not be done, but later existing users will also be prompted to verify email and mobile — not as part of user account credentials but as part of user profile — which is not necessary, as verification will be cancellable option except in the case of Rewards & Contests.

Q: As a user, I have requested OTP for invalid email and I want to edit the email so that I can request and receive OTP. A: When user clicked on OTP, their address has been entered by the user only.

Q: Will forgot password log out user from all other accounts in different devices? A: Yes, by default.

Q: Does this mean that we won't have either primary and secondary both email IDs? A: We will have both primary and secondary/alternate email ID in case of mobile registered user; it's just that user will update email afterwards.

Q: Do we have any plans to capture primary email address after a new user is registered via Mobile Number? A: Primary email will be the email used for registration until it is not verified.

• If the registration email is verified, its primary status remains status quo.
• If the registration email user is not able to verify (fake or non-deliverable), then alternate/secondary email verification will be asked and done — that will then become primary.
• User account credentials table and user profile table are separate, so this can be easily managed.

9. Design Thinking — Constraints, User Flow & Top Tasks

(Pages 19–22)

Section Header Slide (Page 19)

• Section number: 06
• Title: Design Thinking

Constraints — Registration Rules (Page 20)

Eleven explicit registration logic rules were defined:

• Rule 1: If number already registered, new registration will not be allowed.
• Rule 2: If user profile is deleted for certain number, then fresh registration will be allowed with the same number (only in case of secondary mobile number).
• Rule 3: If user registered with email & updated a mobile number and tries to register fresh with same mobile number — not allowed.
• Rule 4: If user registered with mobile number & updated email and tries to register fresh with same email — not allowed.
• Rule 5: If user tries to give secondary mobile number or email with which registration is already done — not allowed.
• Rule 6: If user is registered with mobile number (independent option) & tries to sign-up in FB with same mobile number — it will be allowed but no fresh registration will be done.
• Rule 7: If user registered with email (independent option) & tries to sign-up in FB with same email — allowed, but no fresh registration done.
• Rule 8: If user registered with mobile number through FB & tries to sign-up with independent mobile sign-up option — not allowed; shown already registered with FB. (Can allow creating password but no fresh registration — open for discussion.)
• Rule 9: If user registered with email ID through FB & tries to sign-up with independent email sign-up option — not allowed; shown already registered with FB. (Same discussion as Rule 8.)
• Rule 10: If user registered with email ID through Google & tries to sign-up with independent email sign-up option — not allowed; shown already registered with Google. (Same discussion.)
• Rule 11: If user has registered & updated secondary number or email in that profile, then some other user tries to register with already listed secondary email or mobile — allow or disallow? (Open for discussion.)

User Flow (Page 21)

Primary Login/Signup Flow:

Start with Email or Mobile
→ User Inputs Email / Mobile
→ Check Valid Email / Mobile
  → Valid: Check Registered Email / Mobile
    → Registered: Open password field → User Inputs Password → Check Password
      → Correct: Login Success
      → Incorrect: Show error message for incorrect password
    → Not Registered: Open OTP field → Send OTP on Email / Mobile Provided
      → User receives OTP → Inputs OTP within given time frame → Check OTP
        → Correct: Open form fields (name + confirm password)
          → User Inputs all compulsory fields → Check user provided values
            → Password not per guidelines: Show error
            → Password mismatch: Show error
            → All values match: Sign up success
        → Incorrect: Show Error Message for incorrect value
      → User does not receive OTP: Click on resend
      → User receives OTP → failed to input within given time frame: Show error message of timeout
  → Invalid: Show error message

Email OTP Delivery Failure Sub-Flow:

Two failure branches identified:

• USER-side failures: Email Issues (spam filter, mail goes to junk, can't keep up, special clients), Invalid Email (spelling mistake, typo, domain error)

  • For these: No control as user input is wrong or not valid. Basic delivery failure response: will inform user to provide valid input → Return error message to user.
  • Edge case: "If it's a case of zero-spam filter or mail goes to spam, we can't keep check. So have to put special checks."
  • OTP will be sent for 3 times; should look into OTP status within that time frame; if valid then proceed; if not, new OTP will be sent.

• TECHNICAL-side failures: Network Failure (OTP links tested, HTTP errors, retry sending errors), SMTP Server Failure/Delay (has a Mail Queue, there is a processing queue, Delay Sending Error), System Failure/Delay, Recipient Domain Blocked / IP Blocked.

  • For these: If all of the above cases are addressed, yet how only OTP delivery failed — new OTP will be sent and the previous one will be invalid; immediately a new assigned OTP (Long Id) will be sent to the registered email after verification is successful.

Visual observation (Page 21): The user flow diagram spans the entire slide in a tall vertical layout with two sections — the main registration/login flow above, and the Email OTP Delivery Fail sub-flow below. Color coding: yellow for user input actions, purple for system check/decision nodes, green for success paths, red/pink for failure/error paths. The granularity of the OTP delivery failure tree (distinguishing user vs. technical causes) shows engineering-level thinking embedded directly in the design document.

View text description

Flowchart of the full sign-up/login flow, color-coded by node type: yellow for user input actions, purple for system checks/decisions, green for success paths, red/pink for failure paths. Path: user enters email or mobile → email/mobile format is validated (invalid shows an error) → system checks whether it's already registered. Registered accounts go to a password field, checked against the stored password, succeeding at Login Success. Unregistered accounts move to OTP verification: an OTP is sent, and the flow branches into three cases — OTP received and entered in time, OTP not received (user clicks resend), or OTP received too late (time-out error). A correct OTP opens the sign-up form (name, password, confirm password); the system checks the values match a password policy and match each other before showing Sign-up Success. Below the main flow, a separate sub-flow details Email OTP Delivery Fail, splitting into User-caused issues (spelling mistakes, invalid email) versus Technical issues (DNS failure, SMTP server failure/delay, blocked recipient domain/IP), each with its own recovery messaging and a resend-and-retry loop capped at 5 attempts within 5 minutes before the case is treated as spam-filtered.

Top Tasks to Design For (Page 22)

Fifteen critical scenarios were defined as design priorities:

1. Email/Mobile — Registered user — Sign in process
2. Email/Mobile — Registered user but forgot password — Entered password incorrect → click on forgot password link → set new password or Forgot Password Click when user has provided email
3. Email/Mobile — Registered user clicks on forgot password & tries to create same password as before → show error message
4. Email/Mobile — Registered user but put wrong password or keeps on putting wrong password
5. Email/Mobile — Don't know if registered user or know I am a new user — Sign up process
6. Email/Mobile — New user & inputs invalid email
7. Email/Mobile — New user & creates invalid password
8. Email/Mobile — New user & confirms wrong password
9. Email/Mobile — New user & inputs wrong or mismatch/integer missing OTP
10. Email/Mobile — New user & OTP time out
11. Email/Mobile — New user & makes 3 attempts for OTP verification by clicking resend
12. Email/Mobile — New user & clicks on resend button twice and still hasn't input the OTP
13. Email/Mobile — Technical snag happens or Technical Failure happened more than 5 times and OTP email/sms is not being delivered
14. Email/Mobile — New user & misses on inputting name or password & clicks on submit
15. Email/Mobile — New user & did OTP verification but clicks on back button or kills app

10. Key Solutions — Final Designs

(Pages 23–25)

Section Header Slide (Page 23)

• Section number: 07
• Title: Key Solutions

Final Designs — App (Page 24)

Email Address Prerequisites (visible in leftmost panel):

• The Email address must include only RFC-compliant characters:
  • Lowercase or Uppercase (a-z) English letters
  • Numbers (0–9)
  • Characters like period (.), apostrophe ('), dash (-), hash (#), percent (%), ampersand (&), slash (/), and underscore (_) are allowed
  • Symbol characters can't be first or last character and it will not come one after the other
  • @ can be used only one time, between prefix & domain

App screens documented (left to right, top):

1. Onboarding / Splash screen — TAP heart logo, imagery grid of mothers and babies. CTAs: Continue with Apple, Facebook, Google. Bottom link: "Email or Mobile" — positioned as a less prominent option relative to social logins.

2. Registration Name/Password Screen — Fields: Enter your name, Create password, Confirm password. Submit CTA (greyed out until complete). Success toast: "✓ Your mobile number has been verified!" in green.

3. Mobile Number Entry — Unregistered Flow — "Welcome to theAsianParent" with Email Address / Mobile Number tabs. Mobile Number tab active, showing +63 flag (Philippines), number 65 20 52 65 65. Error state: "The mobile number is not registered with theAsianparent. Please verify this mobile number with OTP to continue further." — Blue CTA: "Send OTP."

4. OTP Entry Screen — "Enter the One Time Password to verify the mobile number (04:52)" — countdown timer shown in blue. OTP sent confirmation: "+63 65 20 52 65 65." Six individual digit boxes showing: 4, 4, 9, 3, 3, 4. CTA: "Verify." Below: "Didn't receive the OTP? Resend." Numeric keyboard shown at bottom.

5. Password Error / Reset Screen — Error state: "Oops, new password can't be same as previous one. Please create a different password." (red error text). Confirm password field below. Submit button greyed.

6. Returning User — Mobile Login — Verified tick (green checkmark on +63 number). "Enter Password" field. "Forgot Password?" link in blue.

7. Profile Name Entry (Signup) — "What do we call you at theAsianparent?" — Name field pre-filled with "Sagar." Password field with guidelines: minimum 8 characters, no spaces, mix of symbols, letters and numbers. Create password + Confirm password fields.

8. Email Unregistered Error — Email address shown: sagar.pradhan@tickledmedia.com. Red error: "The email address is not registered with theAsianparent. Please verify this email address with OTP to continue further." CTA: "Send OTP."

Visual observation (Page 24): The final app design uses a consistent two-tab switcher (Email Address | Mobile Number) at the top of the authentication screen — matching the mental model identified from Bigbasket in market analysis. The OTP screen uses individual digit boxes (not a single field), which contradicts the workshop decision to use a single field for copy-paste. The countdown timer "04:52" shows the 5-minute OTP validity. The error states use a red/coral brand accent color consistently. The overall visual language is clean, minimal, and coherent — a significant improvement over the fragmented previous exploration screens.

Final Designs — Web (Page 25)

Web platform screens documented:

1. Landing Page / Signup Modal — Top navigation with Home, Contest, Recipes, Food, Tracker, Topics, Articles. Left side: Parent photography grid. Right side: "Get expert-led tips and connect with other parents." Login options: Continue with Email or Mobile, Continue with Google, Continue with Facebook, Continue with Apple. Country flags shown: Singapore, Thailand, Indonesia, Philippines, Malaysia, Vietnam — indicating multi-country deployment.

2. Email OTP Verification Modal (Web) — Modal overlay on the community feed. Email pre-filled: sagar.pradhan@tickledmedia.com. Red error text: "The email address is not registered with theAsianparent. Please verify this email address with OTP to continue further." CTA: "Send OTP."

3. Mobile OTP Modal — "Enter the One Time Password to verify the mobile number (04:52)." OTP digits: 4, 4, 9, 3, 3, 4. CTA: "Verify." "Didn't receive the OTP? Resend" below.

4. Profile Name/Password Modal — "What do we call you at theAsianparent?" Name pre-filled: "Sagar." Password guidelines visible. Create/Confirm password fields. Submit CTA.

5. Password Mismatch Error State — Two password fields shown, second highlighted red. Error: "Password not matching." Submit disabled.

6. Mobile Number Verification Screen — Email address / Mobile number tab switcher. Mobile Number selected, Philippines (+63) flag, number field. Mobile Number Prerequisites panel visible (same validation rules as email, adapted for phone).

Visual observation (Page 25): The web version presents authentication as modal overlays on the existing community feed — users can see the blurred content behind the modal, creating a "sneak peek" motivation to complete verification. The country flag selector (6 countries visible) underscores the SEA regional scope. The tabbed Email/Mobile switcher is replicated faithfully from the app design, ensuring cross-platform consistency.

11. Usability Testing

(Pages 26–31)

Section Header Slide (Page 26)

• Section number: 08
• Title: Usability Testing

Remote Usability (Page 27)

"In the multiple design grooming calls, I and Product Manager, Engineering Manager, and Mobile and Web leads, Marketing People and senior developers discussed root causes and devised a plan:"

The team's five-point usability plan:

1. Reach out to affected customers to find out what went wrong and offer a solution.
2. Comb through telemetry to connect any dots.
3. Conduct usability testing to evaluate the effectiveness and ease of use of the OTP verification process.
4. Gather feedback on the clarity of instructions, the accessibility of verification methods, and overall user satisfaction.
5. Identify any usability issues or areas for improvement based on user interactions and feedback.

Experiments, Facts, Insights & Conclusions (Page 28)

Experiments run:

• Remote usability testing to evaluate user's interactions throughout the sign up and verification process
• Check for the OTP verification services
• Contact affected customers via support channels
• Explore tech solutions and restrictions

Facts gathered:

Insights:

Conclusions (action items):

1. Create forgot password flow from sign-in screen
2. Remind user which email or phone they have just signed up with on the verification page
3. Provide user a prerequisite of Email address to sign up with a valid one
4. Have a means on the verification page for users to log out of the current session to try and sign up or sign in with the right email
5. Retain existing copy on the verification page to check their spam or junk
6. Retain Resend CTA on the verification page
7. Have a means on the verification page for users to trigger the API call on verification status, if they have used their phone device to click on verification link

View text description

Four-column research synthesis board (Experiments → Facts → Insights → Conclusions). Experiments run: remote usability testing of sign-up/verification, a check of the OTP delivery services, contacting affected customers via support channels, and exploring technical fixes/restrictions. Key facts: 3 of 5 users chose email verification over mobile; 2 users forgot which email they'd used when checking for the OTP; 1 user never received the verification email even after resending and checking spam; almost all OTP messages fired on time and almost all verifications succeeded; a few users mistyped their email during sign-up and got stuck without knowing the required email format. These facts produced insights such as: users mostly check OTPs on their phone's email app rather than desktop; people can forget which email they used moments after signing up; email/mobile verification is a familiar pattern that should follow platform conventions rather than being reinvented. Nine numbered scenarios cover cases like happy-path sign-in, forgotten password, wrong OTP, and repeated failed resends. Conclusions translated into recommendations: build a forgot-password flow from the sign-in screen, remind users which email/phone they just used, require a valid email up front, let users log out mid-flow to retry with the right account, keep the resend CTA, and add a way to manually trigger a verification-status check.

Overall Testing Results (Pages 29–30)

1. Sign In / Registration Process

2. OTP Verification

Error Handling

(Continued — Page 30)

Alternative Verification Methods

Overall Experience

View text description

Task-by-task success rate table. Sign In / Registration: sign in with an existing account 100%; complete registration via email/mobile 100%; recover a forgotten password 80%. OTP Verification: recognising an OTP time-out 100%; entering a wrong or incomplete OTP 80%; making 3 resend attempts in a row 20%; clicking resend twice without entering the OTP 100%; a repeated technical snag on OTP delivery 20%. Error Handling: repeatedly entering a wrong password 80%. The two 20% scores — repeated resend attempts and repeated technical delivery failure — were the clearest signal that the retry/failure paths needed rework, feeding directly into the OTP-delivery-failure sub-flow shown earlier.

View text description

Continuation of the task success table. Error handling: entering an invalid email/mobile and checking the format prerequisites 100%; requesting a new password identical to the old one, or an invalid one, via forgot-password 40%; understanding whether they're a registered or new user before creating an invalid password 100%. Alternative verification methods: finding alternative sign-in methods on the platform 100%; successfully using Google, Facebook or Apple login to verify 100%; giving feedback on how clear those alternative methods were 80%. Overall experience: reflecting on the registration/verification process overall 80%; rating ease of use and intuitiveness (1–5 scale) 60%; leaving additional comments or suggestions 100%. The 40% score on recreating/validating a new password was the weakest result on this page, pointing to unclear password-requirement messaging in the forgot-password flow.

Lessons and Interpretation (Page 31)

Failed Tasks:

• User got confused on start screen while checking whether they are registering or signing in again
• User forgot which email they used on sign up when searching through their mailboxes for OTP verification
• User did not receive forgot password link and OTP link at all, despite double clicking multiple times
• User found email and mobile verification process time-consuming and difficult

Low Task Success Factors:

• Easier and faster OTP services for authentication
• Overall trust factors
• Email and Mobile verification are must — we can get rid of either of them
• User retention > Install vs signups

12. Next Step — Profile Completion

(Page 32)

Title: "Next Step…. User Edit Profile Cases (Profile Completion)"

The next phase after email/mobile verification was defined as a three-tab progressive Edit Profile flow:

Tab 1: Basic Details ("Help us to know you?")

• Profile completion progress bar: 20%
• Fields: Full Name*, Gender*, Date of birth*, Country*, Language*
• Terms & Conditions checkbox: "I agree to the Terms & Conditions and am aware that my data will be processed by TAP and its partners."
• CTA: "Save and Next"

Tab 2: Contact Details ("How we will reach you?")

• Profile completion progress bar: 20%
• Fields: Primary Email Address*, Alternate Email Address, Primary Mobile Number*, Alternate Mobile Number, Address section (House/Flat No*, Building/Apartment Name with Area*, Pincode/Zipcode*)
• CTA: Next tab auto-advance on save

Tab 3: Other Details ("It's nice to know more about you!")

• Profile completion progress bar: 60%
• Fields: Profile picture (Upload jpg/png), Short Bio, Marital Status, Highest Education, Working Status
• CTA: "Submit"

Visual observation (Page 32): The three-tab UI uses icon-based tab navigation at the top (person icon, phone icon, list icon). Tab 2 clearly accommodates both primary and alternate contact details — an architectural decision that aligns with the workshop Q&A conclusion about maintaining both primary and secondary email/phone structures. The progress bar jumping from 20% (after Tabs 1 and 2) to 60% (after Tab 3 is started) suggests the Other Details tab is the highest-weighted section for profile completeness scoring.

13. Image Scan Findings — Visual Layer Analysis

The following insights were extracted exclusively from the rasterized visual inspection of each page, supplementing or clarifying information in the text layer:

Dashboard Data Precision (Page 6)

The analytics dashboard screenshot reveals the tool is labeled "Profile Completion v2" with "PUBLISHED" status — indicating this was a live production dashboard, not a prototype or staging view. Filters available: User Country, User Signup Date, User Verification Date, User Stage, City. The "0" value for "Phone and OTP Verified" (meaning both simultaneously) reveals the system counted phone-OR-email, not phone-AND-email as a combined requirement.

Previous UX — Reward Incentive Architecture (Page 8)

The home screen widget area (Page 8) shows two reward icons side by side: a gold trophy (TAP Contests) and a gold star badge (10 Rewards Points). This confirms the previous system used a reward-based nudge model rather than a mandatory verification gate. The "See More" link next to "Rewards / Why to Submit" confirms there was a secondary education layer explaining reward benefits — reflecting low user understanding of why verification mattered.

Registration Form Complexity (Page 9)

The VIParent Signup screen (Page 9) shows the city/state/country pre-filled as "Bandra West, Maharashtra, India" — suggesting GPS-based location auto-fill was already in use. The 20% profile complete bar was visible even before the user had entered any information, suggesting the initial 20% came from social/login signup data pre-populated.

Market Analysis — Competitor Behavioral Gates (Page 15)

Mylo's "only for verified users" screen uses a full-screen modal with no dismiss mechanism — total hard gate. BabyChakra's OTP screen shows the SMS message content including the company name: "Your OTP is [1003] is your OTP for BabyChakra. Message ID: 8/PKS2268029A." This level of branded SMS is a trust-building signal worth replicating.

Market Analysis — Airbnb Reset Password Ruleset (Page 16)

Airbnb's reset password validation list visible in screenshot: "Password Strength: Weak → At least 8 characters, Includes a number or symbol, Can't contain your name or email address." The visual meter and itemized checklist UI pattern is a strong reference for progressive validation UX.

User Flow — OTP Delivery Failure Tree (Page 21)

The failure tree visible in the diagram distinguishes between USER errors (Email Issues, Invalid Email) and TECHNICAL errors (Network Failure, SMTP Server Failure/Delay, System Failure/Delay, Recipient Domain Blocked/IP Blocked). Three retry attempts with OTP status checking are specified before a hard failure. This server-side retry logic is not documented in the text layer of the slide and was only extractable via visual scan.

Final Designs — OTP Timer Detail (Page 24)

The OTP screen shows timer "04:52" — confirming a 5-minute OTP validity window. The OTP shown in the screen (4, 4, 9, 3, 3, 4) is displayed in individual boxes with a blue underline style — each digit box has a distinct frame. The numeric keyboard is the default keyboard type triggered, reducing friction for number entry. The "Verify" button is blue and fully active when all boxes are filled.

Final Designs — Multi-Country Deployment (Page 25)

The web signup modal shows six country flags: Singapore 🇸🇬, Thailand 🇹🇭, Indonesia 🇮🇩, Philippines 🇵🇭, Malaysia 🇲🇾, Vietnam 🇻🇳 — confirming simultaneous multi-country rollout of the verification system. The community feed visible behind the web modal shows Indonesian-language content (e.g., "Simposium Tucul dengan Shedd Bumam Tucker, lni Kali dan Tale Carannya"), confirming localization was already operational.

Testing Results Color Code (Pages 29–30)

The testing results use a traffic-light color system: green for 100%, amber/yellow for 80%/60%, red for 20%/40%. This makes the two critical failure areas immediately visible: 3-attempt OTP resend flow (20%) and technical failure scenario (20%) — the two most complex edge cases in the system.

Profile Completion Flow — Alternate Contact Fields (Page 32)

Tab 2 shows both "Primary Mobile Number" (+91 9967334146) and "Alternate Mobile Number" (+91 9820804970) fields — confirming the dual-contact architecture discussed in the workshop was implemented in the final design. The address section also appears within the Contact Details tab rather than a separate tab, reducing the number of tabs from a potentially 4-step flow to 3.

14. Second-Order Thinking

Second-order thinking examines what happens as a result of the first-order decisions visible in this case study — the downstream effects, trade-offs, and system behaviors that follow from the design choices made.

14.1 The Tension Between Data Quality and Drop-off Rate

The primary design decision was to introduce OTP verification as a required or semi-required step. The immediate second-order consequence is registration drop-off. Every additional step in a signup funnel historically reduces completion rates by 10–30%. The team appeared aware of this — the 20% success rate on "3-attempt OTP resend" in testing directly reflects user abandonment during repeated failure states. The revenue-protection case for the project must be weighed against these lost registrations — a calculation the deck does not explicitly make.

14.2 Email OTP as the Dominant Channel Has Delivery Infrastructure Risk

Email was chosen as the primary OTP channel over SMS, and the data confirms it: 216,699 Email OTP verifications vs 77,789 Phone OTP verifications. However, email delivery is inherently less reliable than SMS — it depends on SMTP server health, recipient domain reputation, spam filtering, and user attention to inbox vs. junk. The ideation workshop's entire "Email OTP Delivery Fail" tree (User/Technical failure branches) reflects this risk. By betting heavily on email, the platform is exposed to an infrastructure class of failures that SMS largely avoids.

14.3 Rewards-Based Verification Creates Conditional Trust

The previous system used TAP Points, Blue Tick, and contest eligibility as incentives to verify. The new system shifts toward enforcement-based verification. This changes the psychological contract with users: from "verify to get more" to "verify to continue." Users who were accustomed to the incentive model may experience the new system as punitive. Long-term user trust depends on how transparently the value exchange is communicated.

14.4 Single Platform Registration Creates Single Point of Failure

One stated requirement was to "create a single platform for all registration processes in the app." Consolidation reduces fragmentation and inconsistency — a clear improvement. But consolidation also creates a single point of failure: if the unified registration system goes down, all acquisition channels (VIParent, general signup, community, ecommerce) fail simultaneously rather than independently. The architectural risk increases proportionally with the centralization benefit.

14.5 The Primary/Secondary Email Architecture Introduces Ongoing Data Maintenance Complexity

The workshop concluded that users would have both primary and secondary email addresses, with unverified primary emails being replaced by verified secondary ones. This creates a database state where users have email addresses of varying verification status and freshness. Over time, as users change email addresses or phone numbers, the system needs active maintenance to avoid the same data hygiene problem it was designed to solve — at a more complex schema level.

14.6 The 0 "Phone AND OTP Verified" Metric Is a UX Signal

The dashboard shows 0 users who verified both phone AND email. This likely means the system did not require or prompt dual verification. But from a data quality perspective, having only one verified contact method per user still leaves gaps — a user could verify an email they rarely check and provide an unverified phone number they use daily. The data completeness goal and the contact reachability goal are related but not identical.

15. Third-Order Thinking

Third-order thinking traces the cascading effects multiple steps downstream — what happens to the system, the user base, the business model, and the competitive position over a 1–3 year horizon as a result of the decisions made in this case study.

15.1 Verified Data as a Compounding Asset

At 288,241 verified contacts and growing, theAsianParent is building a compounding trust asset. Each verified user is more valuable for lead generation, advertising targeting, and partner monetization. Over a 2–3 year horizon, if verification rates continue, the platform could reach a state where its lead database is a premium, defensible product — sellable or licensable at rates significantly above the industry average for unverified parenting data. The internal loss-prevention case represents only the defensive value; the positive-return compounding value of a clean database is likely several times larger over the same period.

15.2 Verification as a Moat Against Fake Account Proliferation

Southeast Asian digital markets have notably high rates of fake/bot account creation, particularly on platforms that offer rewards, contests, or commercial incentives. By requiring OTP verification, theAsianParent creates a structural barrier to fake account farming. This has a third-order effect on advertiser confidence: brands paying for lead generation through the platform can trust that leads are real, human, and reachable. This trust premium enables premium pricing and differentiation from competitor platforms that still operate on unverified data.

15.3 The Compliance Trajectory

The ideation workshop referenced "Strong Customer Authentication" — a term originating in EU PSD2 financial regulation but increasingly adopted across digital identity contexts. As Southeast Asian regulators increasingly focus on data protection (Singapore PDPA, Thailand PDPA, Indonesia PDP Law), having a verified user identity infrastructure positions theAsianParent favorably for compliance. The third-order effect: competitors who delayed verification infrastructure will face costly retrofitting when regulation mandates it; theAsianParent will have a 2–3 year head start.

15.4 Progressive Profiling as a Data Monetization Engine

The "Next Steps — Profile Completion" slide reveals the strategic intent beyond verification: a three-tab progressive profile with fields for address, marital status, education, working status, and location. Combined with verified contact data, this creates a rich demographic profile per user. The third-order monetization pathway is targeted advertising, co-registration lead sales to FMCG/baby product brands, and insurance/financial product upsells — all of which command significantly higher CPMs and CPLs when attached to verified, enriched profiles. The profile completion progress bar (20% → 60%) is not just UX gamification; it's a data enrichment pipeline.

15.5 The "Install vs. Signups" Metric Signals a Retention Gap

The "Lessons and Interpretation" slide mentions "User retention > Install vs signups" as a low task success factor. This is a third-order signal: the verification project reveals a pre-existing funnel gap between app installs and completed signups. If verification friction increases drop-off in that funnel, the install-to-signup ratio will deteriorate — potentially masking the platform's true acquisition health in top-line install metrics. Three years out, if the platform cannot close this gap, paid acquisition costs will rise while organic activation rates fall, compressing marketing ROI precisely as it was attempting to improve it.

15.6 The Dual-Channel Verification Split Predicts Feature Divergence

With email OTP at 216,699 and phone OTP at 77,789, email is the dominant verification method by nearly 3:1. Over time, this creates pressure to optimize the email verification pathway at the expense of the phone pathway — better error states, better deliverability infrastructure, better UX copy. Phone OTP users may eventually receive a degraded experience. The third-order risk is that phone-primary users (likely lower-income, mobile-only segments common in Indonesia, Philippines, Vietnam) are de-prioritized in product iterations — creating a two-tier experience that correlates with socioeconomic status across the platform's SEA markets.

15.7 The UX Debt of the Ideation Workshop Decisions

Several workshop decisions were left "open for discussion" — particularly Rules 8, 9, 10 (social login + direct signup conflicts) and Rule 11 (secondary contact conflicts across accounts). These unresolved states will generate customer support tickets, edge-case bugs, and user confusion at scale. Three years out, if the platform grows to 5–10M users, even a 0.1% rate of edge-case registration conflicts represents 5,000–10,000 users in ambiguous account states — a significant support and trust cost that traces directly back to decisions deferred in this ideation workshop.

End of Case Study

Document compiled by: Claude (Anthropic) Source material: theAsianParent Email & Mobile Verification Presentation (33 slides, PDF) Processing methods: Full text extraction (pdftotext), visual rasterization at 100 DPI across all 33 pages (pdftoppm), cross-referencing of text and visual layers, applied second-order and third-order analytical frameworks.