// ============================================================
// WATER MANAGEMENT PLATFORM (Rio Tinto) — case study page.
// Copy source of truth: rio-tinto-brief.md — wording is VERBATIM,
// do not paraphrase. Components from rio-tinto-case-parts.jsx;
// placeholder screens from rio-tinto-screens.jsx.
// Colour identity scoped via .rt-theme (see rio-tinto.css) so the
// generic .cs-* article scaffolding picks up Rio Tinto's palette
// instead of Imprint's.
// ============================================================

function WaterManagementCaseStudy({ onNav }) {
  useReveal();
  return (
    <main className="cs-main rt-theme">
      {/* 1 — HERO */}
      <section className="cs-hero" data-screen-label="Water Management — Hero">
        <div className="shell">
          <a className="cs-back" href="#" onClick={(e) => { e.preventDefault(); onNav('home'); }}>← Back to work</a>
          <div className="cs-hero-titlerow reveal">
            <div className="cs-hero-title" style={{ marginBottom: 0, fontSize: 'clamp(40px, 6.4vw, 82px)' }}>Water Management Platform</div>
            <span className="rt-client-badge"><img src="images/rio-tinto-logo.svg" alt="Rio Tinto" /></span>
          </div>
          <p className="cs-hero-sub reveal">Turning weeks-delayed reporting into real-time operational visibility, across seven mine sites in the Pilbara.</p>
          <div className="chip-group reveal" style={{ marginBottom: 26 }}>
            {['Enterprise UX', 'Data Visualisation', 'Rio Tinto'].map((t, i) => <span key={i} className="chip">{t}</span>)}
          </div>
          <div className="cs-pills reveal">
            <div className="cs-pill"><span className="pk">Role</span><span className="pv">Product Designer</span></div>
            <div className="cs-pill"><span className="pk">Company</span><span className="pv rt-pill-logo"><img src="images/rio-tinto-logo.svg" alt="Rio Tinto" /></span></div>
            <div className="cs-pill">
              <span className="pk">Team</span>
              <span className="pv rt-team-list">
                {['Product Designers', 'Solution Architect', 'Software Engineers', 'Test Engineers', 'Business Analyst', 'Product Owners', 'Scrum Master'].map((r, i) => <span key={i} className="rt-team-tag">{r}</span>)}
              </span>
            </div>
            <div className="cs-pill"><span className="pk">Duration</span><span className="pv">12 months, delivered across iterative Agile Program Increments</span></div>
            <div className="cs-pill"><span className="pk">Tools</span><span className="pv">Figma, Figma Make, Miro, Maze</span></div>
          </div>
          <AtAGlance />
          <div className="cs-note reveal">
            <div className="nk"><span className="star">✦</span>A note on the visuals in this case study</div>
            <p>The Water Management Platform was an internal Rio Tinto tool, so I'm not able to share the actual production screens. Every screen below is a recreation I built to illustrate the design decisions, structure, and interaction patterns described here, they represent the work accurately, but are not the real UI.</p>
          </div>
        </div>
      </section>

      {/* 2 — OVERVIEW */}
      <section className="cs-section" data-screen-label="Water Management — Overview" style={{ paddingTop: 0 }}>
        <div className="shell cs-narrow">
          <div className="cs-kicker reveal"><span className="ln"></span>Overview</div>
          <p className="cs-body reveal">At Rio Tinto, I worked as one of two Product Designers on the Water Management Platform, used across seven mine sites in the Pilbara region of Western Australia.</p>
          <p className="cs-body reveal">The platform was originally built for basic bore monitoring. In practice, water teams had outgrown it: they were stitching together Excel spreadsheets, Power BI dashboards, and site-specific reporting processes just to understand water performance and manage operational issues. The result was inconsistent reporting across sites, duplicated effort, and downtime events that were sometimes only discovered weeks after they happened.</p>
          <p className="cs-body reveal">Over a 12-month period, I led the end-to-end UX process to redesign the platform into a real-time operational tool, one that consolidated reporting, standardised data across sites, and gave teams the ability to catch water infrastructure risks before they escalated.</p>
          <div className="cs-em-card reveal">The result: the System Usability Scale score lifted from the 50s into the 80s, next-day reporting delays were eliminated in favour of real-time field capture, and platform adoption grew from 40 to over 200 active users.</div>
        </div>
      </section>

      {/* 3 — THE PROBLEM */}
      <section className="cs-section" data-screen-label="Water Management — The problem">
        <div className="shell cs-narrow">
          <div className="cs-kicker reveal"><span className="ln"></span>The problem</div>
          <h2 className="cs-h2 reveal">Water teams lacked a consistent, real-time view of bore performance.</h2>
          <p className="cs-body reveal">Operational data was scattered across Excel, Power BI, and the existing platform, and none of these systems talked to each other.</p>
          <p className="cs-body reveal"><strong>What the platform could do at the start:</strong></p>
        </div>
        <div className="shell">
          <div className="cs-screens-2" style={{ maxWidth: 700, margin: '0 auto' }}>
            <div className="cs-shot reveal">
              <Mockup url="platform.riotinto.internal/metrics" maxScale={0.5} canvasWidth={1440} canvasHeight={900}><LegacyScreen /></Mockup>
              <div className="cs-shot-cap">Metrics page: bore abstraction values, basic bar and trend charts (daily, weekly, monthly)</div>
            </div>
            <div className="cs-shot reveal" style={{ transitionDelay: '0.08s' }}>
              <Mockup url="platform.riotinto.internal/bores/BR-0041" maxScale={0.5} canvasWidth={1440} canvasHeight={900}><LegacyBoreDetailScreen /></Mockup>
              <div className="cs-shot-cap">Bore details page: bore name, location, basic performance data</div>
            </div>
          </div>
        </div>
        <div className="shell cs-narrow" style={{ marginTop: 40 }}>
          <p className="cs-body reveal">What it couldn't do was give anyone confidence that what they were looking at reflected what was actually happening on site. Users didn't trust the data enough to make decisions on it, so they kept building their own workarounds.</p>
          <p className="cs-body reveal"><strong>Key pain points:</strong></p>
          <ul className="cs-list reveal">
            <li>Inconsistent reporting across mine sites</li>
            <li>High manual effort to produce operational reports</li>
            <li>Fragmented data spread across multiple tools</li>
            <li>Downtime events going undetected for days or weeks</li>
            <li>Low confidence in the platform as a source of truth</li>
          </ul>
          <p className="cs-body reveal">In short, the platform was functioning as a data repository, not an operational decision-making tool.</p>
        </div>
      </section>

      {/* 4 — THE OPPORTUNITY */}
      <section className="cs-section" data-screen-label="Water Management — The opportunity">
        <div className="shell cs-narrow">
          <div className="cs-kicker reveal"><span className="ln"></span>The opportunity</div>
          <p className="cs-body reveal">We had a clear mandate: make this platform the single source of truth for water operations across all seven sites. That meant:</p>
          <ul className="cs-list check reveal">
            <li>Consolidating fragmented reporting tools into one platform</li>
            <li>Standardising reporting across all sites</li>
            <li>Surfacing downtime events in real time, not weeks later</li>
            <li>Reducing reliance on Excel and Power BI</li>
            <li>Shifting teams from reactive to proactive decision-making</li>
            <li>Rebuilding trust in the platform's data</li>
          </ul>
          <div className="cs-callout reveal">
            <div className="co-k">What success looked like beyond the user experience</div>
            <p>Every hour a water engineer spent reconciling Excel against Power BI against the platform was an hour not spent on the operational risk itself. Duplicated tooling also meant duplicated maintenance overhead across seven sites for the engineering org. So the business case for this redesign wasn't just "make it easier to use", it was reducing the ongoing cost of running three parallel reporting systems, and cutting the lag between a downtime event occurring and someone being able to act on it. I kept both of those in view throughout, not just the usability side.</p>
          </div>
        </div>
      </section>

      {/* 5 — HOW I WORKED */}
      <section className="cs-section" data-screen-label="Water Management — How I worked">
        <div className="shell">
          <div className="cs-narrow">
            <div className="cs-kicker reveal"><span className="ln"></span>How I worked</div>
            <p className="cs-body reveal">I moved through several roles on this project, business analyst, software engineer, and eventually product designer, which gave me an unusually complete view of the problem before I started designing the solution. Each Program Increment (PI, a quarter-long cycle in our Agile setup) followed a two-phase rhythm, split deliberately down the middle: half the PI for discovery, half for design and validation, regardless of how much more there was left to learn.</p>
            <p className="cs-body reveal">That constraint was intentional. It's easy for discovery to expand to fill whatever time you give it, so I treated the halfway point as a hard cutoff: whatever I'd learned by then had to be enough to move into wireframes and a testable prototype. If a question was still open at that point, it became something to validate through usability testing rather than a reason to extend research further.</p>
          </div>
          <ProcessRhythm />
          <WorkPhases />
        </div>
      </section>

      {/* 6 — DISCOVERY */}
      <section className="cs-section" data-screen-label="Water Management — Discovery">
        <div className="shell cs-narrow">
          <div className="cs-kicker reveal"><span className="ln"></span>Discovery</div>
          <h2 className="cs-h2 reveal">It wasn't a data problem.</h2>
          <p className="cs-body reveal">I ran discovery workshops with hydrogeologists, water engineers, site supervisors, and operational managers. All of them were looking at the same underlying data, but their needs diverged sharply, from day-to-day operational diagnostics to long-term environmental reporting.</p>
          <p className="cs-body reveal">The insight that shaped everything downstream, surfaced through affinity mapping in Miro:</p>
        </div>
      </section>

      <section className="cs-quote-band">
        <div className="shell">
          <span className="cs-quote-mark reveal">"</span>
          <p className="cs-quote reveal">Users weren't struggling because of <span className="hl">a lack of data</span>. They were struggling because of fragmented systems and inconsistent interpretation of operational metrics across sites.</p>
        </div>
      </section>

      <section className="cs-section" data-screen-label="Water Management — Reframe" style={{ paddingTop: 0 }}>
        <div className="shell cs-narrow">
          <p className="cs-body reveal">That reframed the brief. This wasn't an "add more charts" problem. It was a <strong>"give people one place to trust"</strong> problem.</p>
        </div>
      </section>

      {/* 7 — EXPLORING DESIGN DIRECTIONS */}
      <section className="cs-section" data-screen-label="Water Management — Exploring design directions">
        <div className="shell">
          <div className="cs-narrow">
            <div className="cs-kicker reveal"><span className="ln"></span>Exploring the design directions</div>
            <p className="cs-body reveal">Before landing on a final approach, I explored two other directions, and I think it's worth showing why they didn't survive testing.</p>
          </div>
          <div className="cs-mrow reveal">
            <div className="txt">
              <span className="cs-dir-tag fail">✕ Rejected</span>
              <h4 className="cs-dir-h">One comprehensive dashboard</h4>
              <p className="cs-body">A single unified view combining every operational metric. Everything visible in one place, but the cost was high cognitive load, unworkable for a platform with multiple distinct user roles. Rejected after usability testing surfaced how much it overwhelmed users.</p>
            </div>
            <div className="vis"><Mockup url="platform.riotinto.internal/dashboard" canvasWidth={1440} canvasHeight={900}><ConceptAllInOneScreen /></Mockup></div>
          </div>
          <div className="cs-mrow flip reveal">
            <div className="txt">
              <span className="cs-dir-tag mid">~ Not pursued</span>
              <h4 className="cs-dir-h">Role-specific dashboards</h4>
              <p className="cs-body">Separate dashboards tailored to engineers, managers, and hydrogeologists. Each experience tailored precisely to its user, but at the cost of high maintenance overhead, and logic that would drift out of sync across views over time. Not pursued, largely on scalability grounds.</p>
            </div>
            <div className="vis"><Mockup url="platform.riotinto.internal/dashboard/hydrogeologist" canvasWidth={1440} canvasHeight={900}><ConceptRoleSpecificScreen /></Mockup></div>
          </div>
          <div className="cs-mrow reveal">
            <div className="txt">
              <span className="cs-dir-tag win">✓ Chosen</span>
              <h4 className="cs-dir-h">A configurable single experience</h4>
              <p className="cs-body">One reporting system, with user-controlled customisation: toggle metrics on or off, reorder the visual hierarchy, adapt the view without forking the platform. This balanced flexibility against consistency, and it's what we built.</p>
            </div>
            <div className="vis"><Mockup url="platform.riotinto.internal/dashboard" canvasWidth={1440} canvasHeight={900}><FinalDashboardScreen /></Mockup></div>
          </div>
          <div className="cs-callout reveal">
            <div className="co-k">The riskiest assumption</div>
            <p>That one configurable experience could genuinely serve hydrogeologists, engineers, and site supervisors without either overwhelming them (Option 1's failure mode) or fragmenting into three products wearing one skin (Option 2's failure mode). Rather than committing engineering time to build that out fully, I tested it cheaply: a Figma Make prototype of the toggle-and-reorder interaction, validated through moderated Maze sessions before a single line of production code was written. That's what gave the team confidence to commit to the harder, more flexible build over the two safer, more conventional options.</p>
          </div>
        </div>
      </section>

      {/* 8 — INFORMATION ARCHITECTURE */}
      <section className="cs-section" data-screen-label="Water Management — Information architecture">
        <div className="shell cs-narrow">
          <div className="cs-kicker reveal"><span className="ln"></span>Redesigning the information architecture</div>
          <p className="cs-body reveal">I restructured the platform to support far richer operational data:</p>
          <DataChips />
          <p className="cs-body reveal" style={{ marginTop: 28 }}>The centrepiece of this was the Bore Detail page, which I transformed from a static metadata page into a dynamic operational workspace.</p>
          <DecPair
            from={{ t: 'Static metadata page', d: 'Bore name, location, and basic performance data, read-only, disconnected from live operational risk.' }}
            to={{ t: 'Dynamic operational workspace', d: 'Asset info, equipment health, geographic context, historical performance, and live downtime events, in one place.' }}
          />
        </div>
        <div className="shell" style={{ marginTop: 32 }}>
          <div className="reveal">
            <Mockup url="platform.riotinto.internal/bores/BR-0341" canvasWidth={1440} canvasHeight={900}><BoreDetailScreen /></Mockup>
          </div>
          <div className="cs-shot-cap" style={{ textAlign: 'center', marginTop: 14 }}>Bore Detail (after): the redesigned, dynamic operational workspace</div>
        </div>
      </section>

      {/* 9 — DOWNTIMES EXPERIENCE */}
      <section className="cs-section" data-screen-label="Water Management — Downtimes experience">
        <div className="shell">
          <div className="cs-narrow">
            <div className="cs-kicker reveal"><span className="ln"></span>Building the Downtimes experience</div>
            <h2 className="cs-h2 reveal">Surfacing operational issues as they happen, not after the fact.</h2>
            <p className="cs-body reveal">The biggest structural addition was a dedicated Downtimes module, built to surface operational issues as they happened rather than after the fact.</p>
          </div>
          <DowntimesShowcase />
          <div className="cs-narrow" style={{ marginTop: 40 }}>
            <p className="cs-body reveal"><strong>What users could do inside it:</strong></p>
            <ul className="cs-list reveal">
              <li>Drill into individual downtime events</li>
              <li>Update downtime reason codes</li>
              <li>Jump directly to the affected bore</li>
              <li>Track recurring patterns across sites</li>
            </ul>
            <p className="cs-body reveal">This is what connected day-to-day operational monitoring with longer-term reporting in a single workflow, instead of two separate systems that never quite agreed with each other.</p>
            <p className="cs-body reveal"><strong>Scoping the smallest shippable version:</strong> these three views weren't designed and shipped as one block.</p>
          </div>
          <ShipTimeline />
          <div className="cs-narrow" style={{ marginTop: 40 }}>
            <p className="cs-body reveal">That got real-time visibility into users' hands faster, rather than holding the whole module back until every view was polished.</p>
            <p className="cs-body reveal">I also replaced hours of weekly manual data collation with custom in-platform visualisations, line charts, bar charts, and treemaps, so patterns that used to take an analyst a full afternoon to compile were visible at a glance.</p>
          </div>
          <ChartRow />
        </div>
      </section>

      {/* 10 — USABILITY TESTING */}
      <section className="cs-section" data-screen-label="Water Management — Usability testing">
        <div className="shell cs-narrow">
          <div className="cs-kicker reveal"><span className="ln"></span>Usability testing</div>
          <h2 className="cs-h2 reveal">Dense data, not missing data.</h2>
          <p className="cs-body reveal">I ran moderated usability testing in Maze, giving users realistic reporting tasks to complete.</p>
          <p className="cs-body reveal"><strong>What we learned:</strong></p>
          <ul className="cs-list reveal">
            <li>Users could find the data they needed, but struggled to interpret dense visualisations once they had it</li>
            <li>Different user groups consistently prioritised different metrics</li>
            <li>A single static chart couldn't support that range of workflows</li>
          </ul>
          <p className="cs-body reveal">This confirmed something the discovery phase had hinted at: the problem wasn't access to information, it was how much interpretive work was being asked of the user.</p>
        </div>
      </section>

      {/* 11 — ITERATING */}
      <section className="cs-section" data-screen-label="Water Management — Iterating on the design">
        <div className="shell">
          <div className="cs-mrow reveal">
            <div className="txt">
              <div className="cs-kicker" style={{ marginBottom: 14 }}><span className="ln"></span>Iterating on the design</div>
              <p className="cs-body">Off the back of testing, I introduced interaction-driven customisation:</p>
              <ul className="cs-list">
                <li>Toggleable data series via interactive legends</li>
                <li>Drag-and-drop legend ordering, so users could control their own visual hierarchy</li>
                <li>The ability to focus on role-relevant metrics without losing the rest</li>
                <li>Reduced visual noise, without sacrificing data depth</li>
              </ul>
              <p className="cs-body">This is what let one interface genuinely serve multiple user types, rather than splintering into three disconnected experiences that all needed separate upkeep.</p>
            </div>
            <div className="vis"><Mockup url="platform.riotinto.internal/dashboard/edit" canvasWidth={1440} canvasHeight={900}><DashboardConfigScreen /></Mockup></div>
          </div>
        </div>
      </section>

      {/* 12 — AI IN THE PROCESS */}
      <section className="cs-section" data-screen-label="Water Management — AI in the process">
        <div className="shell cs-narrow">
          <div className="cs-kicker reveal"><span className="ln"></span>Bringing AI into the process</div>
          <p className="cs-body reveal">With delivery timelines tight, I used Figma Make to rapidly prototype interaction variations after usability testing. This let me:</p>
          <ul className="cs-list check reveal">
            <li>Explore alternative interaction patterns faster</li>
            <li>Validate complex chart behaviour without waiting on a full build</li>
            <li>Cut down significantly on time spent manually rebuilding prototypes by hand</li>
          </ul>
          <p className="cs-body reveal">The resulting interactive prototype was embedded directly into Figma, so engineers had an exact reference for behaviour during development, not just static screens and a written description. That closed a lot of the ambiguity that usually creeps in between design handoff and implementation.</p>
        </div>
      </section>

      {/* 13 — COLLABORATION */}
      <section className="cs-section" data-screen-label="Water Management — Collaboration">
        <div className="shell cs-narrow">
          <div className="cs-kicker reveal"><span className="ln"></span>Collaboration</div>
          <p className="cs-body reveal">None of this happened in isolation. Throughout the project I was in:</p>
          <ul className="cs-list reveal">
            <li>Regular design critiques with designers and engineers</li>
            <li>Stakeholder reviews with product owners and operational teams</li>
            <li>Cross-functional alignment sessions during PI planning</li>
          </ul>
          <p className="cs-body reveal">Feedback from these sessions directly shaped iteration priorities. I also designed a structured feedback form that categorised user input and fed into a FAQ resource, which cut duplicate support tickets by 70% and built trust in the platform as users saw their feedback actually land somewhere.</p>
        </div>
      </section>

      {/* 14 — OUTCOME AND IMPACT */}
      <section className="cs-outcome-band" data-screen-label="Water Management — Outcome and impact">
        <div className="shell">
          <div className="cs-kicker reveal"><span className="ln"></span>Outcome and impact</div>
          <div className="cs-outcomes">
            <div className="cs-outcome reveal"><span className="star">✦</span><p>SUS score lifted from the 50s into the 80s, with real-time visibility of downtime events across all seven mine sites</p></div>
            <div className="cs-outcome reveal"><span className="star">✦</span><p>Adoption grew from 40 to over 200 active users, a direct return on the time invested in the redesign</p></div>
            <div className="cs-outcome reveal"><span className="star">✦</span><p>Downtime events that used to surface weeks late now surface in real time, materially reducing unmanaged operational risk</p></div>
          </div>
        </div>
      </section>

      <section className="cs-section" data-screen-label="Water Management — Outcome detail" style={{ paddingTop: 60 }}>
        <div className="shell">
          <OutcomeColumns />
        </div>
      </section>

      <section className="cs-section" data-screen-label="Water Management — Field capture" style={{ paddingTop: 0 }}>
        <div className="shell cs-narrow">
          <p className="cs-body reveal">Part of eliminating next-day reporting delays was giving field teams a way to log downtime the moment it happened, from a phone, on site, not back at a desk hours later.</p>
        </div>
        <div className="shell" style={{ marginTop: 20 }}>
          <div className="reveal">
            <RTPhoneCrop><FieldCaptureScreen /></RTPhoneCrop>
          </div>
          <div className="cs-shot-cap" style={{ textAlign: 'center', marginTop: 14 }}>Field capture, logging a downtime event from a mobile device, on site</div>
        </div>
      </section>

      {/* 15 — TRADE-OFFS */}
      <section className="cs-section" data-screen-label="Water Management — Trade-offs">
        <div className="shell cs-narrow">
          <div className="cs-kicker reveal"><span className="ln"></span>Trade-offs I'd make differently</div>
          <p className="cs-lead reveal">If I were running this again, I'd push to timebox the <em>implementation</em> phase as tightly as I timeboxed discovery. Design and validation were disciplined, but build phases still had a tendency to stretch once engineering got into the detail of the configurable interaction model. Next time, I'd want to define the smallest version of "configurable" that ships in week one, then treat every extra toggle or customisation option as something earned through evidence, not assumed as required scope from the start.</p>
        </div>
      </section>

      {/* 16 — WHAT I LEARNED */}
      <section className="cs-section" data-screen-label="Water Management — What I learned" style={{ paddingTop: 0 }}>
        <div className="shell cs-narrow">
          <div className="cs-kicker reveal"><span className="ln"></span>What I learned</div>
          <div className="cs-build">
            <div className="cs-build-item reveal"><span className="star">✦</span>Enterprise UX success is driven more by decision-making clarity than by data volume</div>
            <div className="cs-build-item reveal"><span className="star">✦</span>Flexible interaction models can outperform role-specific dashboards, if you design the flexibility well</div>
            <div className="cs-build-item reveal"><span className="star">✦</span>Usability testing pays off most when it's validating interaction behaviour, not just checking the UI</div>
            <div className="cs-build-item reveal"><span className="star">✦</span>Embedding design artefacts directly into developer workflows removes a surprising amount of ambiguity</div>
            <div className="cs-build-item reveal"><span className="star">✦</span>A hard timebox on discovery is more useful than more time in discovery: it forces the riskiest assumptions to the surface early, when they're still cheap to test</div>
          </div>
        </div>
      </section>

      {/* 16.5 — FULL PROTOTYPE */}
      <section className="cs-section" data-screen-label="Water Management — Full prototype" style={{ paddingTop: 0 }}>
        <div className="shell">
          <div className="cs-narrow">
            <div className="cs-kicker reveal"><span className="ln"></span>The full prototype</div>
            <h2 className="cs-h2 reveal">Walk the whole set, screen by screen.</h2>
            <p className="cs-body reveal">Every screen in this case study, live and clickable, from the legacy metrics page through to the final configurable dashboard, the Downtimes module, and field capture.</p>
          </div>
          <div style={{ marginTop: 36 }} className="reveal">
            <WaterManagementPrototype />
          </div>
        </div>
      </section>

      {/* 17 — REFLECTION */}
      <section className="cs-section" data-screen-label="Water Management — Reflection">
        <div className="shell cs-narrow">
          <div className="cs-kicker reveal"><span className="ln"></span>Reflection</div>
          <p className="cs-lead reveal">This project reinforced how I think about UX: holding user needs and business constraints in the same frame, not sequentially. By timeboxing discovery, testing the riskiest assumption before committing engineering effort, and shipping the highest-value view first rather than waiting for the full module to be polished, I helped turn a fragmented reporting system into a unified operational platform, one that paid back the investment in adoption, reduced duplicated tooling cost, and materially cut the time it took to catch a problem on site.</p>
        </div>
      </section>

      {/* 18 — NEXT PROJECT */}
      <section className="cs-next">
        <div className="shell">
          <a className="cs-next-link" href="#" onClick={(e) => { e.preventDefault(); onNav('dearly'); }}>
            <div>
              <div className="nl-k">Next · back to work</div>
              <div className="nl-t">Dearly</div>
            </div>
            <span className="cs-next-arrow">→</span>
          </a>
        </div>
      </section>

      <Footer onNav={onNav} />
    </main>
  );
}

Object.assign(window, { WaterManagementCaseStudy });