Bright Disputes
Zero-knowledge proofs, made usable by non-technical people.
Web
Blockchain
MVP
UI
Role
UI Designer
Timeline
Jan – May 2023
Stage
MVP
Domain
Blockchain
Outcome
4 steps
linear voting flow distilled from the cryptographic process
Ahead of schedule
Polkadot.js integration, unblocked by the prototypes
Testnet
privacy-preserving voting demoed live on AlephZero
Encrypted votes as locked cards — privacy you can see.
Overview
Making invisible cryptography feel trustworthy to people who will never read the math.
Bright Disputes is a dispute-resolution dApp built as an R&D project at Bright Inventions (now Framna) — juries vote on high-stakes disputes and votes are encrypted with Zk-SNARKs. As the sole product designer I took the five-month MVP end to end — from translating the cryptographic logic into a linear voting interface, down to mapping every input field to the Ink! smart contract.
Problem
People were asked to stake real money on a vote they couldn't see.
Jurors staked actual funds on disputes, but the technology securing their votes was mathematically complex and — by design — invisible. That created one blunt friction: if I can't see my vote, how do I know it's counted? The privacy that made the system valuable was the same thing that made it feel untrustworthy. If the interface read as opaque, users wouldn't stake funds, and the product would fail before the cryptography ever got a chance to matter.
The core tension — the vote is provably private, and therefore invisible.
Key decisions
Trust is a UI problem before it’s a math problem.
Decision 01 · Visibility
Visualizing the black box with locked cards
The core challenge was displaying votes the user is not allowed to see yet. I designed a locked card state to represent encrypted votes — a visual metaphor that shows privacy as something actively happening, not something absent.
Why
Users don't need to understand encryption to trust it — they need to see that it's on. The locked card turns an invisible guarantee into a visible state.
Trade-off
⚠️ Q2a MISSING — candidates: (a) the metaphor hides info people may want mid-vote — no running tally, deliberate blindness as a feature; (b) trust rides on the metaphor, not understanding — if the card ever mislabels what is encrypted, trust breaks harder. Confirm or replace.
Decision 02 · Latency
Humanizing the CLI integration
The verify button isn't a toggle — it fires a heavy off-chain proof calculation through a CLI. I designed explicit feedback states (loading → verified) to bridge the browser and the command line, so a long silence reads as work in progress, not as failure.
Why
During proof generation nothing visible happens for seconds at a time. Nielsen's first heuristic — visibility of system status — is the difference between 'it's working' and 'it's broken' when the real work is off-chain.
Trade-off
⚠️ Q2b MISSING — candidate: the two-state feedback hides real progress — users can't distinguish slow from stuck, and there's no percentage or step detail to offer because the CLI doesn't report any. Confirm or replace.
Decision 03 · Integrity
Mapping the UI 1:1 to the smart contract
Every input field maps directly to the Ink! smart contract constructor. The interface validates wallet address formats and strictly separates staking fees, so the payload a user submits matches the chain's validation logic exactly — failed transactions get prevented in the form, not explained after the fact.
Why
On a blockchain a failed transaction isn't a validation error — it costs the user gas and confidence. The cheapest place to catch a mismatch is before it leaves the browser.
Trade-off
⚠️ Q2c MISSING — candidate: mapping 1:1 means the form follows the contract's structure, not the user's mental model — and every contract change forces a UI change. You bound the interface to the engineers' data structures on purpose. Confirm or replace.
Outcome
From cryptographic complexity to a 4-step flow.
The high-fidelity prototypes did double duty: they specified the interface and they documented the logic, which let the team finish the Polkadot.js integration ahead of schedule. The MVP ran a working demonstration of privacy-preserving voting on the AlephZero testnet.
⚠️ Q6: Was there any user-facing validation — even informal? If not, we say so honestly rather than imply testing; the testnet demo carries the section alone.
Reflection
⚠️ Q3 MISSING — the live site never had a reflection; the structure requires one.
Answer any one of these from memory, then we draft:
What did mapping UI to a smart contract teach you that you'd apply earlier next time?
Did the locked-card metaphor survive contact with anyone unfamiliar with the project — and would you validate it differently now?
You designed for trust with zero access to actual jurors — same pattern as POS. Knowing that, what would you demand up front?