⚡ The conflict nobody anticipated
Viewer interviews produced an emoji wishlist: +1, heart, thumbs up, thumbs down, laughter, thank you, applause, celebration. Organizer interviews came back with a veto: no negative emojis. "Business leaders will not be happy seeing thumbs down from audiences during their presentation." Two legitimate user groups. Completely opposing needs. No obvious right answer.
Decision process: what was tried, what failed, and what unlocked the solution
Research: interviewed viewers first
Ran user interviews with livestream viewers. Asked which emojis they would actually use during a business presentation, not which ones looked nice. Result: eight emoji types including both positive and negative sentiment options. Thumbs down was explicitly requested.
User interviews · n=viewers
Validation: interviewed event organizers (unexpected finding)
Brought the proposed emoji set to event organizers for validation. Surprising rejection: organizers opposed all negative emojis. Their reasoning was not about UX; it was about organisational politics. Business leaders presenting would experience thumbs-down reactions as a public embarrassment, regardless of whether that was the viewer's intent.
Organizer interviews · Unexpected stakeholder constraint surfaced
First instinct: impose a global rule
Initial reflex was to pick a side: either include all emojis (viewer preference) or restrict to positive only (organizer preference). Both choices would have failed: one group would have a legitimate complaint about something completely solvable.
❌ Rejected: false binary, neither side needed to lose
The pivot: reframe the problem
The real insight: organizers know their event context better than the platform does. A large all-hands with executives has different norms than a small internal team call. Instead of a platform-wide policy, give organizers control at the event level: let them select the emoji set during the event intake process.
Reframe: platform policy → per-event configuration
Solution shipped: configurable emoji set per event
Added an emoji selector to the Livestream request intake form. Organizers choose which emojis are available for their specific event. Both user groups get what they need: organizer autonomy, viewer expressiveness.
✓ Shipped: configurable per event
Trade-off captured: what was gained and given up
Viewer gets requested emojis
Partial
Yes
Organizer controls audience signals
No
Yes
Platform remains context-neutral
No
Yes
Increased intake form complexity
None
One extra step, accepted
Post-launch data confirmed the hypothesis: large event organizers (200+ viewers) consistently selected positive-only emoji sets. Regular organizers (small teams, <200 viewers) opted in to the full set including thumbs-down. The data validated the design assumption: context determines norms, and organizers are the right person to make that call.
Post-launch analytics · Segmented by event size
The constraint that shaped everything
Reaction stream intentionally capped at 15% width / 25% height of the video player. The video content was the product; reactions were a layer, not a feature. Every throttling decision needed to serve that principle.
Edge Case 1
Viral moment: hundreds of emojis in one second
Presenter shares a joke. Everyone laughs at once. The reaction stream could become a wall of emoji flooding the video frame, defeating its entire purpose. The system needed a way to represent crowd sentiment without visually overwhelming the viewer.
→ Required a solution that captured mood without multiplying clutter
Options tested for Edge Case 1: how to represent 10+ same emojis per second
Option A: Rejected
25% larger emoji
Scale up the emoji size to visually indicate volume: one large emoji represents many.
Tested poorly. Feels arbitrary. Size scaling didn't map to any natural visual metaphor. Users didn't understand what the size meant.
Option B: Rejected
Plus sign counter
Show the emoji with a "+47" counter badge indicating how many were sent simultaneously.
Added visual complexity. Badge competes with the emoji itself. Still felt disruptive when numbers were large.
✓ Option C: Shipped
Single instance only
Show one emoji per type per second, regardless of how many were sent. Volume is implicit: the single emoji signals the sentiment of the moment.
Chosen by viewers in testing. Least distracting. Still communicated the crowd sentiment. Simple, invisible logic.
Edge Case 2: per-user rate limiting
Edge Case 2
Bad actor: continuous emoji spam
A disgruntled attendee could hold down send and flood the stream intentionally. Even with throttled display, a single user gaming the system to disrupt a business presentation was a real organisational risk that needed a hard backstop.
→ Required a per-user rate limit independent of display logic
The decision
A viewer can only send one emoji per 10-second window. This breaks the momentum of intentional flooding without penalising normal use; the average viewer would never notice the limit. The 10-second window was chosen to be undetectable in natural use but decisive as a hard stop against abuse.
Post-launch: zero complaints about the reaction stream being distracting. Zero incidents of emoji flooding. The edge cases were never triggered in production, but designing for them meant the feature could be shipped with confidence, and the team had documented answers if they ever were.
Post-launch monitoring · 0 edge case incidents reported
Outcome
📈 What changed
+30%
Viewer engagement vs chat alone
0
Distraction complaints post-launch
0
Emoji flooding incidents
Large event organizers adopted positive-only emoji sets. Smaller teams used the full set. Both groups got the experience appropriate to their context. The configurable approach proved that the right architecture was more valuable than the right default.
🔍 Reflection: what I would do differently
The stakeholder conflict between viewers and organizers was only discovered late in the process because I interviewed the two groups sequentially rather than together. Earlier cross-stakeholder testing, showing organizer-selected emoji sets to viewers before finalising, would have surfaced the political dimension faster and might have revealed other context-specific norms I did not anticipate.
Back to Amazon case study
Decision process: prototype failure, field research, and the insight that changed everything
Engineering's initial approach: a full 50+ field intake form
The development team's default assumption: build a form where the Fulfillment team fills in all product details (name, description, version, SKU number, and 46+ other fields) for each product entry. Logical from a data completeness standpoint. The form would replace the spreadsheet by capturing the same data in a structured interface.
Engineering assumption: complete data capture per entry
First prototype: rejected immediately in testing
I built a prototype of the 50+ field intake form and tested it with the Fulfillment team. Immediate, unambiguous rejection. "Too cumbersome." Users refused to engage with it. The problem was not a UX detail to fix; the entire approach was wrong. Filling 50+ fields per product was not how anyone actually wanted to work, even if it mapped to the underlying data model.
❌ Form prototype rejected: approach invalidated, not iterated
Field research: observing actual work, not assumed work
Instead of iterating on the failed form, I went back upstream. Ran user interviews and work observations, watching the team use their actual spreadsheets in context. This is where the critical insight surfaced.
Method change: moved from prototype testing to contextual observation
The insight that unlocked everything
95% of all data maintenance is software product upgrades. And upgrades only touch two fields: product status (New/Deprecated) and SKU number (incremented by 1). The team was not filling 50+ fields for each update; they were copying existing rows and changing two values. The spreadsheet was not inefficient because of the spreadsheet. It was inefficient because the replacement hadn't understood what the work actually was.
Key insight: 95% of work = 2 field changes, not 50+
Solution shipped: copy/paste rows, update 2 fields, done
Designed a system that replicated the mental model users already had, but without the spreadsheet's reliability and maintenance problems. Select rows of existing product data → copy → paste → update the two relevant fields. Three steps. The interaction pattern was identical to what they already knew how to do. The system was new; the mental model was not.
✓ Shipped: 3-step flow built on existing mental model
The trade-off: completeness vs adoption
50+ field form (rejected)
High
Very low
No
Copy-row + 2 fields (shipped)
Sufficient (95% of cases)
High
Yes
Full form for new products only
High (5% of cases)
High (rare use)
Yes
The 50-field form was not a bad idea poorly executed; it was a correct answer to the wrong question. The question engineering was solving was "how do we capture all product data?" The question the users needed solved was "how do we handle product upgrades faster and more reliably?" Field research is what identified the gap between those two questions.
Contextual observation finding · Reframed the problem statement
Outcome
📈 What changed
80%
Faster than manual spreadsheet method
Management visibility into product repository
The Fulfillment team completed tasks 80% faster. Downstream errors into Sales and Fulfillment systems dropped. Management gained a live, centralised view of the product repository that replaced fragmented spreadsheet repositories. A 15-year manual process was replaced without requiring the team to learn a new mental model; the interaction pattern was already familiar.
🔍 Reflection: what I would do differently
The 50-field prototype should never have been built; contextual observation should have come before prototyping, not after. If I had watched the team use their spreadsheets before accepting the engineering team's framing of the problem, I would have discovered the 95%/2-field insight at the start. Prototype testing confirmed a problem I could have found faster through observation. In complex enterprise contexts where the team has 15 years of embedded practice, observation should precede prototyping by default.
Back to TIBCO case study