Anjelika Tan

Overview

As product work scaled, handoff depended heavily on me translating between leadership, UX, and engineering. Once I also took on more client and operational responsibilities, that became a bottleneck. Direct UX-to-dev handoff looked faster, but business logic and edge cases were often lost, creating rework and too much dependency on PM review before implementation.

What I built

I helped build an internal AI-assisted PRD workflow for the UX team. It was grounded in our GitHub repo, feature-directory notes, AWS schema references, and design-system guidance, and it was designed to ask logic questions first before generating the PRD.

AI workflow design

• Prompt engineering and iteration
• Grounded context from repo, schema, and internal docs
• Retrieval-style setup across internal references
• Human review before PRD generation
• Structured markdown output for implementation

Key decisions

• Grounded the workflow in repo, schema, and design-system context instead of generic prompting
• Used markdown PRDs because they worked better downstream
• Added a preview layer so non-engineers could review output more easily

Outcome

The workflow is now used for logic-heavy features. It helped UX validate logic earlier without always waiting on PM availability, improved component reuse, and gave engineering a stronger starting point for AI-assisted implementation.

Proof points

• In a milestone-reset use case, it surfaced a flaw in start-date logic that delayed rewards while still evaluating all-time data, exposing a design issue early.
• I also used the same workflow to design, spec, code, and ship a Trustpilot integration to production.

Overview

The store began as a simple voucher redemption feature inside the platform, where users earned client-specific coins through actions, CRM-linked events, milestones, social quests, and bulk updates. As client needs expanded, the real challenge became turning a basic voucher flow into reusable product capability instead of letting every new requirement become one-off custom logic.

What I owned

I was involved from the first version and later owned major logic decisions across Stripe, WooCommerce, redemption methods, permissions, statuses, refunds, and supporting workflows. A big part of the role was deciding when a client request should stay custom and when it needed to become reusable platform capability.

Outcome

Over time, the store became the platform’s most-used feature. What started as a simple voucher page grew into a configurable redemption system that could support different reward types, access patterns, eligibility checks, refund rules, and fulfilment-aware workflows on the same foundation.

What I learned

This project taught me that commerce features become much more interesting when the hard part is not payment, but the logic around access, redemption, eligibility, and operations.

Overview

Milestone started as a simple gamification flow for awarding coins and XP when users met certain conditions. Over time, it became much more than a reward feature. As the platform gained access to richer data through integrations, webhooks, bulk updates, and CRM systems, milestone evolved into a flexible rules engine for progression, role assignment, submissions, approvals, resets, and repeatable engagement logic. Importantly, milestone was not always a visible user-facing feature. In many cases, it operated in the background to assign roles, control permissions, and trigger access changes elsewhere in the product.

What I owned

I was involved in milestone from the beginning and shaped it across its full evolution. That included core condition logic, reward behavior, role assignment, progression models, approval flows, user-facing rule phrasing, resets, start dates, and newer urgency mechanics such as limited redemption windows. It was one of the systems that came most directly out of my hands.

Core capabilities

Milestone became useful because it could combine product rules, external data, hidden backend logic, and user-facing progression in the same system.

Data-driven conditions

As integrations expanded, milestone stopped depending on in-platform actions alone and became a broader rules layer that could react to external signals.

• Used custom fields and external system data as milestone conditions
• Enabled reward logic from CRM, webhook, and bulk-update data
• Supported use cases where users were rewarded when tracked business events occurred

Rewards and role logic

Milestone eventually supported tiers, access changes, and backend control, not just visible reward mechanics. I also used hidden milestone logic to award regional roles that determined access to the store.

• Awarded coins and XP when conditions were met
• Added role assignment, removal, and overwrite behavior
• Enabled hidden milestones that ran purely as backend permission logic

Progression models

Different campaigns needed different progression behavior, so milestone had to support both sequential and independent completion models without assuming one default structure.

• Added progressive logic where later stages stayed locked until earlier ones were cleared
• Added non-progressive logic where tasks could be completed independently
• Supported more flexible campaign structures such as multi-platform review actions

Submission and approval workflows

This pushed milestone beyond automated tracking and into hybrid workflows where platform logic and operational review had to work together.

• Added support for text and image submissions
• Allowed required fields and admin-configured submission instructions
• Added approval and rejection workflows for actions that could not be validated automatically
• Introduced custom conditions around review-based milestone handling

Recurring and urgency mechanics

As milestone grew more complex, it also had to become easier to understand and more reusable over time, especially for recurring engagement and time-based reward behavior.

• Improved user-facing condition phrasing without changing admin setup logic
• Added start-date and reset logic for recurring milestone use cases
• Added limited-redemption windows to create urgency and support repeatable engagement loops
• Used milestone as the basis for the Trustpilot review flow once completion conditions were met

Outcome

Milestone grew from a simple reward mechanic into one of the platform’s most flexible backend systems. It powered coins, XP, role assignment, approvals, hidden access control, recurring campaigns, and integration-driven rewards. In practice, it became just as important as the store and, in some ways, more widely used because it controlled the logic behind how progression, access, and reward behavior worked across the product.

What I learned

This project taught me that gamification becomes much more powerful when it stops being about points alone and starts acting as a reusable system for progression, permissions, behavior, and structured business logic.