One of the largest token distributions in blockchain history
Phase 1: Glacier Drop
Claim NIGHT tokens based off your Origin address eligibility
Non-interactive demo showing the Glacier Drop token claim flow, from checking wallet eligibility through to a completed claim.
The problem
Midnight is a data-protection blockchain. Glacier Drop is the distribution that's seeding it. Unlike a traditional airdrop, NIGHT didn't land all at once. Each claim thawed in 4 stages, unlocking a quarter at a time, on a schedule assigned per wallet over a 12-month period.
Token drops had been done before, but not like this, and not with as much public scrutiny. So the margin for error was narrow on a product that needed to take seemingly endless technical complexity and wrap it in a simple, secure, and familiar user experience.
Meet the team
Forks in the road
Four moments the project could have gone the wrong way. Each pivot pulled the work onto a better path, without them, a very different product would have shipped.
-
Team structure
ChallengeI was outsourced in the beginning
- Waterfall delivery, outsourced through IOG
- UI-only scope, no upstream input
- Limited decision-making from outside the team
Back on trackInside the team, leading end-to-end
- Moved internally to Midnight
- Planned and executed 2 crucial design sprints
- Led the design across all three phases
-
Process leadership
ChallengeEngineering making UX decisions to meet sprint deadlines
- Tech-led decisions, not grounded in user needs
- Flows over-complicated for jobs to be done
- UI patterns invented where conventions already existed
Back on trackResearch bought us the right design
- Won time for user research & usability testing
- Clear definition meant clear communication
- Patterns aligned with real user mental models
-
Mobile support
ChallengeHalf the audience locked out by tech constraints
- Mobile wallets supported only for Scavenger Mine
- Mobile design scoped, then axed
- Test cohort left on desktop-only flows
Back on trackMobile-ready by default, even when axed
- Layout future-proofed for fast mobile adaptation
- Designed mobile in one afternoon when re-prioritised
- Axed again, but the option was always there
-
Hardware wallet delays
ChallengeHardware-wallet support delayed at launch
- Ledger / Trezor support unavailable at time of launch
- Layout, journey and copy weren't aligned with delays
- Security-conscious participants would feel it most
Back on trackLayout, journey and messaging adapted in hours
- Journeys re-ordered to lead with what worked
- Honest "coming soon" state for hardware wallet path
- New messaging set clear expectations
Trade-offs
Not every problem had a clean fix. These were four moments where the work meant choosing between two imperfect paths and being honest about what the choice cost.
-
Continually shifting goalposts
ChallengeUnforeseen business requirements changed the scope mid-project
- Very little time to discover and define
- Help and support content rewritten down to the wire
- Marketing website full of gaps
AcceptedReduced definition time, adapted what we had
- Relied on fewer insights
- Removed rich contextual tutorials, relied on FAQs instead
- Marketing site followed only the user journeys we knew were shipping
-
The "null transaction" warning
ChallengeGeneric warning read as a wallet-specific error
- Same screen shown to every Cardano claimant
- Mistaken for a wallet-specific failure
- Resulted in some user drop-off
AcceptedRestructured the journey to reframe as a solution
- Copy rewritten to move away from error language
- Original journeys based on definition had to be reworked
- Generic warnings used instead of specific error messages
-
The freedom of ACE mismatch
ChallengeNew requirements added which contradicted freedom of ACE
- Email collection added at the end of each flow
- Social share button inserted at the claim overview screen
AcceptedDesigned to soften the landing
- Offered two options to download OR receive claim receipts by email
- Ensured the share button was as unobtrusive as possible
-
Unused-address requirement
Challenge"Must be unused" terminology confused users with no rationale
- New terminology with multiple meanings
- Users only cared about how to obtain an unused address
- Drop-off predicted at the address step
AcceptedMade the requirement legible at the point of entry
- Rationale added for something mandatory
- Hint explainer for the "how" when users likely already had one
- Added extra explainers to the marketing flow
Phase 2: Scavenger Mine
Anyone could now participate by solving 24 cryptographic challenges a day to claim a share of NIGHT
Non-interactive demo showing the Scavenger Mine phase-two token distribution.
Phase 3: Redeem
Redeem your claimed NIGHT in four quarterly thaws over twelve months
Non-interactive demo showing claimed tokens being redeemed to a wallet.
What didn't make the cut
An embedded claim portal
The first claim portal was designed to sit inside the Midnight Network website rather than stand on its own. As the distribution grew in scale and public scrutiny, the claim needed its own dedicated and secure home, so this embedded layout gave way to a standalone portal.
What didn't make the cut
-
An embedded claim portal
Glacier Drop v1: An earlier exploration of the claim portal layout which was originally intended to be embedded within the Midnight Network website
-
Wallet selection on mobile
Example of wallet selection on a phone
-
Fetching several addresses at once
The ability to fetch multiple addresses at once was dropped
-
Scavenger Mine on a phone
What Scavenger Mine would have looked like on a phone
-
Rich contextual help
Example of a rich contextual help card
Retro
I'd definitely have flagged me being outsourced on a waterfall methodology as an issue much sooner, but embedding into the Shielded/Midnight team happened at just the right time for the project.
When things started feeling like they were getting too complex, I'd have taken a moment to sketch out a stripped-back version of what we could deliver as an MVP solution, focussing solely on the jobs to be done as a fallback.