TL;DR
I was the sole product designer and full-stack (AI-assisted) developer on a critical-thinking poll web app for Swire Coca-Cola Taiwan's outdoor public-education event, run live across two weekends in Taipei and Kaohsiung.
The web app was the hinge of an offline-to-online journey: visitors learned a 3-step thinking framework at the booth, scanned one of nine topic QR codes, then practised on the app: judging which keyword in a statement was biased, voting, seeing how others answered, and redeeming a prize. Under huge one-shot social exposure (seeded KOLs, organic social, press), the app had one job and no second chance.
It went well. 100% uptime through the event, 4,000+ votes, and 91.3% of voters carried through to redeem. The event ran on the app without a hitch, and the client, a first-time client, flagged UX care beyond their expected scope.
Context
Coca-Cola planned a public event promoting critical thinking in two cities in Taiwan.
The event lasted two weekends in two cities. Making sure visitors learned a 3-step thinking framework was the main objective of the whole event.
The event booth (image: WoWoNews)
The 3-step thinking framework Coca-Cola wanted to promote:
- Yes, and no: is the claim fair or biased?
- What's wrong: what wrong assumption does the statement make?
- Why it's wrong: why is the assumption wrong?
Role of the web app
The web app was the hinge between the physical event and the online practice.
It was the touchpoint that turned learning into practising.
The web app sat between two booth stepsThe web app also had operational objectives:
- Zero errors under huge social exposure
- Optimised for mobile users outdoors
- Future-proof for later expansion
Event journey
Five major steps took visitors from learning to redeeming.
Key objective
How might visitors practise, remember and reflect on the 3-step framework, then redeem the prize?
Solutions
Three design solutions that address "practise", "remember" and "reflect".
Practise: one step per page, or one page with three steps?
Paging away destroyed the context of the previous step, so I went with the final version, which keeps the context and emphasises the 3-step framework.
Remember: less disruptive, or protect the outcome?
At first I prioritised a smooth flow. Exploration 1 used a staggered animation with a short pause when the step title shows; exploration 2 used a full-page text transition that emphasised the step title. But both sacrificed the most important objective of the event: remembering the framework.
In the end I chose a tooltip that interrupts the flow but forces attention on the 3-step framework. It costs more reading time, but it's best for the event's outcome.
Reflect: one button per keyword, or one dedicated sheet?
I first explored one explanation button per keyword, assuming people would only check one keyword. Guerrilla testing showed people wanted explanations for more than one, so the final version shows them in a dedicated bottom sheet.
Prototyping explorations with Claude Code and the existing components
During exploration I wanted to prototype different interactions along with different UI variations. With the existing components in the codebase, I used Claude Code to visualise the explorations and to evaluate them against my own criteria. It didn't override my decisions; it was a reference that widened my thinking.
Accessibility for the outdoor environment
- AA colour contrast and large touch targets for one-handed outdoor use; screen-reader navigation.
- Loading optimised for slow mobile data with caching and a chosen CDN.
Role of builder
Being the builder let me solve problems from a wider perspective, with a hard line where I don't trust AI.
Text truncation was the perfect example. During development, some words and punctuation marks broke across lines unusually. AI proposed a font size per media query. I thought word and punctuation encapsulation rules (which tokens must break together) were better, so the layout wraps meaningfully rather than by character, and it follows Mandarin Chinese conventions more closely.
Overall, I specified the business logic, APIs, functions and design as fully as I could, and left code implementation and automated tests to Claude. I decided the caching mechanism, trading off for faster pages and less drop-off, and handled extreme cases such as concurrent voting load and bot-like traffic.
Impact
The web app didn't just go live across two cities: visitors engaged, and it never fell over.
The event ran smoothly, and the client was satisfied with the overall work.
91.3%
key-flow conversion rate
100%
uptime during the event
4,000+
votes across both weekends
