/* Long-form case-study writeups (text only; visuals composed at render) */

const NARRATIVES = {
  irex: {
    context: `Visioncraft asked me to lead design on Irex, a new crypto exchange entering an already-crowded market, and to do it while four product surfaces were being built in parallel: marketing site, retail exchange, advanced trade, and a partner widget. The hard part wasn't drawing trade tickets. It was making sure four teams shipping at different speeds didn't end up with four different products wearing the same logo.`,
    role: {
      owned: [
        "Multi-layer design system (tokens, primitives, patterns)",
        "Advanced Trade, order book, ticket, position views",
        "Theming engine, dark/light, LTR/RTL parity",
        "Design QA across all four surfaces",
        "Coaching the junior designer on the team",
      ],
      team: [
        "Brand & marketing visuals (in-house brand designer)",
        "Native mobile shells (mobile engineers)",
        "Compliance & KYC copy (legal + content)",
        "Motion explorations on the marketing site",
      ],
    },
    features: [
      {
        title: "A system that <em>thinks in tokens</em>, not screens",
        challenge:
          "Four parallel surfaces meant four parallel design files. Components drifted within a week.",
        solution:
          "Built a three-layer token graph, primitive, alias, semantic, wired to Figma variables and exported as JSON for engineering. One change cascaded everywhere.",
        impact:
          "180+ components shipped with full dark/light and LTR/RTL coverage. No parallel files; one library, four products.",
      },
      {
        title: "<em>Bi-directional</em> by default, not by patch",
        challenge:
          "Crypto users in MENA needed RTL. Most exchange UIs handle RTL as an afterthought, broken charts, mis-aligned numerals, reversed candles.",
        solution:
          "Designed every component twice from the outset; baked in a 'physics' rule for what flips (containers) and what doesn't (charts, numerals, timelines).",
        impact:
          "RTL shipped on day one of regional launch. Support tickets on RTL screens were lower than LTR for two months.",
      },
      {
        title: "An advanced trade view that <em>shrinks gracefully</em>",
        challenge:
          "Pro traders wanted Bloomberg-density on desktop. The same screen on a 13-inch laptop was unusable.",
        solution:
          "A modular grid where each panel knows its three minimum sizes. Below threshold, panels collapse into a stack, not a horizontal scroll.",
        impact:
          "Advanced Trade became the single highest-retention surface in the product, pros stayed in it for the whole session.",
      },
    ],
    pull: "We argued for two months about whether to ship one direction first. <em>Doing both at once turned out to be cheaper</em>, because we never had to retrofit anything.",
    tradeoff: {
      chose:
        "A heavier upfront system (tokens, theming, RTL) before any product feature shipped, six weeks of 'invisible' work.",
      cut:
        "A 'fast V0 of the marketing site to drum up interest. We knew it would have to be thrown away once the system landed.",
    },
    reflection:
      "Spending six weeks on tokens before drawing a screen is the kind of decision you can only sell to a team once. The proof was in month three, when a fifth product idea, a B2B partner widget, landed and shipped in two weeks because the system already had the answers.",
  },

  "success-factory": {
    context: `Success Factory is the back-office for a quarter-million network marketers across 90 countries. The legacy WebOffice was nine years old, written by four different teams, and looked like it. The goal was not to redesign it, it was to migrate 250k+ live users to a new platform without anyone noticing they had been migrated.`,
    role: {
      owned: [
        "Information architecture across the entire WebOffice",
        "Dashboard, Activity, Team, Awards and Income Centers",
        "Migration plan, what changes when, and how we soften it",
        "Component library and Figma governance",
        "Stakeholder reviews with 4 country leads",
      ],
      team: [
        "Brand & marketing site (creative team)",
        "Mobile companion app (separate squad)",
        "Localization across 12 languages",
        "User research panels (insights team)",
      ],
    },
    features: [
      {
        title: "A dashboard that <em>looks familiar</em> on day one",
        challenge:
          "Long-tenured members had muscle-memorized the old UI. Even a 'better' new layout was friction.",
        solution:
          "Kept the spatial logic of the old dashboard (left rail nav, top KPIs, central feed) but rebuilt every component. Familiar at a glance, different on inspection.",
        impact:
          "Day-one drop-off after migration was 0.4%, well below the 5% threshold the business had braced for.",
      },
      {
        title: "Data tables that <em>read like sentences</em>",
        challenge:
          "Members lived in dense tables, team trees, commissions, rank progress. The old tables were unreadable on anything below 1440px.",
        solution:
          "Left-aligned numerics for scanning, fixed first column on horizontal scroll, monospaced numerals, a single accent color for changes vs. baseline.",
        impact:
          "Time-on-task on the top-four reports dropped 42%. Members stopped exporting to Excel for arithmetic.",
      },
      {
        title: "An activity feed people <em>actually read</em>",
        challenge:
          "The feed was a chronological dump, 80+ items a day per member, ignored after week one.",
        solution:
          "Grouped by entity (people, ranks, events), with a small 'today's three things' digest pinned at the top, generated by simple rules, no AI.",
        impact:
          "Feed open rate went from 6% (weekly) to 41% (daily). Engagement on rank-promotion announcements 3.4×.",
      },
    ],
    pull: "Migration is a <em>design problem</em>, not a project plan. You're not shipping a product, you're shipping a memory.",
    tradeoff: {
      chose:
        "Preserving the legacy IA's broad shape, even when a cleaner reset existed. Familiarity bought us the latitude to fix everything underneath.",
      cut:
        "A radical 'inverted' dashboard that surfaced personalized next-actions, too far from muscle memory; parked for v2.",
    },
    reflection:
      "If I had a phrase I'd put over this project: 'no one should celebrate that they were migrated.' The success metric was the absence of complaints. That's an unusual thing for a designer to optimize for, and it changed how I scoped the work.",
  },

  "smart-coach": {
    context: `Smart Coach was a swing at a real problem, most people who buy a fitness program use it twice. Our bet was a camera-based AI coach that watches your form, scores it in real time, and adapts the next set. As co-founder and the only designer, I owned every surface a user touched. The interesting design problem wasn't 'show the AI feedback.' It was 'design what to do when the AI is wrong.'`,
    role: {
      owned: [
        "Brand, identity, product UI, soup to nuts",
        "User app (iOS), Coach Panel (web), marketing site",
        "All AI confidence states and failure modes",
        "First-week onboarding (the only week most users gave us)",
        "Fundraising decks and investor demos",
      ],
      team: [
        "AI / ML model and pose estimation (CTO)",
        "Native iOS engineering (1 engineer)",
        "Backend & coach panel build (1 engineer)",
        "Business development and partnerships (co-founder)",
      ],
    },
    features: [
      {
        title: "Feedback that <em>admits uncertainty</em>",
        challenge:
          "Pose estimation is noisy. A confident 'wrong squat!' two seconds late is worse than no feedback at all.",
        solution:
          "Designed three confidence bands, green (commit), amber (suggest), grey (defer). The UI shrank to a single ambient ring when uncertain. Users learned to read the ring within one set.",
        impact:
          "Trust scores in post-session surveys jumped from 41% to 78% after the redesign. Completion rates 3.2×.",
      },
      {
        title: "<em>Graceful</em> when the camera can't see",
        challenge:
          "Phones tip over. Sun glares. Pets walk past. We needed a way to fail without breaking the flow.",
        solution:
          "A 'paused, not stopped' state, the timer holds, audio cue says exactly what's wrong ('move into the frame'), and the user keeps going when ready. No modal, no penalty.",
        impact:
          "Mid-set abandonment dropped from 19% to 6% across the first 1,000 sessions.",
      },
      {
        title: "An <em>onboarding</em> that earns the camera",
        challenge:
          "Asking 'please put your phone across the room and let us watch you' on day one is a lot.",
        solution:
          "A 90-second guided tour where the camera was on but the model wasn't, just a mirror with helpful overlays. The actual training started when the user said go.",
        impact:
          "92% of users finished a full first session, most fitness apps see 50–60% at this step.",
      },
    ],
    pull: "An AI's job is to be <em>useful when right</em>, and <em>harmless when wrong</em>. Most of design is the second half.",
    tradeoff: {
      chose:
        "A narrower exercise library that the model handled at >85% accuracy, instead of a broad library with mediocre coverage.",
      cut:
        "Yoga and stretching, the pose ambiguity was beyond what the model could read reliably. We told users that on day one.",
    },
    reflection:
      "Most of what I learned at Smart Coach was about scope. As a co-founder you can design anything, but the model only does what the model does, and design's job is to make those edges feel like choices, not limits.",
  },

  snapp: {
    context: `Snapp's Driver app was four years old when I arrived, patterns layered on patterns, three different navigation models in the same flow. The product still worked because the drivers had memorized it. My job was to untangle it without breaking five million daily rides.`,
    role: {
      owned: [
        "Driver app IA and core flows",
        "Ride accept, navigation, end-of-ride and payout",
        "Cross-product consistency with Snapp Cab and Super App",
        "Design QA on a multi-week rolling release",
      ],
      team: [
        "Quantitative driver research (data team)",
        "Native Android engineering (8 engineers)",
        "Operations and driver support tooling (ops team)",
        "Localization across Farsi LTR/RTL",
      ],
    },
    features: [
      {
        title: "<em>One</em> way to accept a ride",
        challenge:
          "Three legacy variants of the ride-accept screen still shipped, depending on driver tier. Engineering wanted to delete two of them; ops feared driver pushback.",
        solution:
          "Co-designed a single accept screen with 80 drivers across two cities, then rolled it out tier-by-tier on a kill-switch.",
        impact:
          "Support tickets on the accept flow dropped 31%. The other two variants were retired within three months.",
      },
      {
        title: "End-of-ride that <em>doesn't lie</em>",
        challenge:
          "Drivers distrusted the payout summary, it didn't match what they expected after surge.",
        solution:
          "Re-designed the receipt to itemize every line, base, surge, tip, fee, using consistent monospace numerics. Total at the bottom, never the top.",
        impact:
          "Driver trust score in monthly surveys lifted 18 points. Fewer 'why did I get this much?' tickets.",
      },
    ],
    pull: "When a million people are using something, redesigning it is less <em>art</em> and more <em>archaeology</em>.",
    tradeoff: {
      chose: "Rolling tier-by-tier release with kill-switch and a slow ramp.",
      cut: "A faster 'all drivers Monday morning' cutover. The risk wasn't worth the calendar saving.",
    },
    reflection:
      "Snapp taught me to listen to ops before pixels. Drivers are not users in a lab, they are people whose income is on the line. The right design is sometimes the smallest one.",
  },
};

window.NARRATIVES = NARRATIVES;
