Increasing Reward Adoption and Engagement Through an AI Creation Layer
From a single AIGC emoji initiative to a shared creation hub for AIGC character, image, and video generation.
I led the end-to-end product design strategy that turned fragmented AIGC feature ideas into one reusable creation system across teams.
An AIGC Creation Layer for Reward Adoption and Engagement
This project began as a domain-team OKR: lower the creation barrier for streamer-customized rewards through AIGC emoji generation and increase custom reward adoption.
As product discovery expanded, we found multiple teams were planning different AIGC use cases in parallel. Building standalone features for each use case would create duplicated logic, inconsistent quality, and fragmented user entry points.
I drove the shift from a feature-first plan to a system-first strategy: a shared AIGC creation layer with a centralized hub for asset management and contextual entry points embedded within each feature, so streamers can access and generate assets wherever they need them, and apply them across emoji, image, and short-video experiences.
Why Personalized Rewards Needed a Scalable Creation Foundation
The platform is a creator ecosystem where streamer identity and visual expression directly influence interaction quality and monetization outcomes.
At the same time, AIGC capability demand was growing across product teams, but each team had different goals, timelines, and constraints. Without a shared layer, AIGC generation risked becoming siloed into disconnected flows.
This made the challenge both product and platform-level: build an experience simple enough for streamers, while creating a scalable architecture that multiple features could plug into.
We delivered a cross-product AIGC creation layer centered on one hub, including:
I was the lead designer for this initiative, from early opportunity framing through system architecture and prompt workflow design.
Two-Stage Character-First Pipeline
I shifted generation to a two-stage flow: generate character first, then generate derivative images from that character.
One-shot text prompt generation cannot maintain style consistency across outputs. The two-stage model adds flow complexity, but it is the only reliable path to visual coherence.
A stable character identity that can be reused and remixed into emojis and other assets with coherent visual language.
Guided Paths to Reduce Learning Cost
I added predefined guided paths to critical steps in the two-stage generation flow.
If users face too many open-ended choices, they cannot access the quality advantage of staged generation. Friction collapses before the value is felt.
Lower onboarding friction while preserving controllability and output consistency.
Full Architecture Before Phased Delivery
I planned the complete AIGC Hub architecture first, then split it into phased delivery across teams.
Hub, emoji, and feature teams needed to build in parallel without breaking the same user flow and page architecture. Shared structure had to precede parallel execution.
Scoped development, clearer team division, and consistent cross-feature UX during parallel implementation.
Dual-Entry Asset Access
I designed two complementary access paths into the asset system: a centralized hub for creating and managing the full asset library, and contextual entry points embedded within individual features.
Centralized management assumes users will build assets before they need them. But most streamers only think about a reward image when they are about to set one up. Without an in-context entry point, reuse would require a behavioral shift that most users would not make. Supporting both patterns is what makes the shared asset library actually useful, not just well-organized.
Streamers can browse and filter existing assets (by type, style, or character) directly from within the feature they are configuring, or generate new ones on the spot without leaving that context. The hub handles lifecycle. The contextual entry handles intent.
Internal Prompt QA Tooling
I treated prompt QA as part of the product itself and built a lightweight internal workflow for batch validation before feature integration.
Manual one-by-one testing was too slow and too subjective once output volume increased. Without a shared evaluation method, quality discussions would default to taste and opinion.
Repeatable quality checks, LLM-as-judge-based judgment, and a Slack-native QA loop that reduced review friction before launch.
Discovery and Alignment
I did not start from screens. I started from alignment. Before I could design any flow, I needed to know which AIGC capabilities were actually shared across teams and which ones were feature-specific. That line mattered because it defined what the hub should own and what downstream teams should keep for themselves. So I ran workshops with PM and design stakeholders first. The point was not to collect ideas. It was to force one shared map of the problem before everyone built their own version.
Hub Architecture and Asset Lifecycle
Once that was clear, I designed the asset system around two complementary access paths. The hub is where streamers manage their full asset library: creating characters, organizing outputs, and building a reusable pool over time. But I also needed each feature to have its own contextual entry point, so streamers could filter and browse existing assets (by type, style, or character) or generate new ones on the spot, directly from within the feature they were configuring.
This dual-entry structure matters because centralized management assumes a “build first, use later” mindset. Most streamers only think about a reward image when they are actively setting one up. The in-context entry point closes that gap: it meets the user where intent already exists, instead of asking for a behavioral shift first. Reuse becomes a natural byproduct of the workflow, not a separate task.
I also had to define how generated assets were organized and handed off across features, because “shared hub” sounds clean until each team needs a different output shape. To keep this shippable, I split hub capabilities into phases so teams could build in parallel under one page and flow framework instead of blocking each other.
Core Generation Flows
The core flow followed the same logic. I chose a two-stage generation model: character first, derivative image second. It is a longer flow, but it was the only way to protect style continuity across outputs. That trade-off is also where the UX gets harder. A staged model gives better results, but only if streamers can actually get through it without getting lost. So I added guided routes at the decision-heavy moments and defined reusable prompt structures for both character and remix paths. I was trying to preserve quality without turning the flow into homework.
The second half of the work was making sure those outputs did not die at creation. I designed the application path so generated assets could move into emoji and reward-related use cases naturally, instead of becoming a dead-end gallery of things users made once and never used again.
Prompt Quality Tooling
I also treated prompt QA as part of the product work, not a side task for later. One-by-one validation was too slow and too subjective once output volume increased, so I built a lightweight internal workflow for batch prompt runs and added an LLM-as-judge evaluation layer using criteria around consistency, style fit, and usability signals. That gave us one shared way to judge whether the system was ready, instead of everyone eyeballing outputs and arguing from taste.
To make the workflow usable in day-to-day collaboration, I also simplified the review loop through n8n automation and brought QA into Slack. Instead of asking teams to open a separate tool for every check, I routed prompt runs, LLM-as-judge results, and review outputs into a shared Slack workflow, making QA faster and easier to operationalize across PM, design, and related stakeholders.
What worked well
Using emoji as the entry use case turned out to be the right product bet. Without that wedge, it would have been much harder to justify consolidating AIGC generation into one hub, and we likely would not have pushed as clearly on ideas like shared IP style continuity across generated outputs. Starting from a concrete, shippable use case made the larger platform direction easier to align and easier to build toward.
What was challenging
The hardest trade-off was that different features wanted AI generation to produce different kinds of outputs, while the system still needed enough shared structure to stay reusable and consistent. Preserving style continuity pushed the flow toward a longer, more guided experience, but that also increased learning cost. The real design challenge was deciding where to keep flexibility open and where to preset the flow so streamers could still move through character creation and reuse paths without getting lost.
What to improve next
If I revisited this next, I would focus less on the core workflow itself and more on the access and monetization model around it. Once the foundation exists, the bigger product question becomes whether AIGC generation should stay limited to a whitelist because of budget, or evolve into a monetizable system with trial and paid expansion paths. A clearer “try first, then pay for more” model would make it possible to open the workflow to more streamers while still managing generation cost responsibly.
