DestinySync: Designing an AI-Native Workflow
A solo AI-native sprint testing a repeatable workflow from research to deployment.
Overview
DestinySync is a bilingual AI-powered web prototype that reframes BaZi and Western astrology as a structured analytics system instead of an entertainment horoscope. I owned product design and prompting as a solo AI-native sprint, validating one repeatable workflow from research to a deployed prototype.
Problem
Most BaZi and astrology apps deliver one-off fortunes with opaque logic and often fear-based or generic language. The design opportunity was to cross-validate Eastern and Western systems, expose the reasoning, and constrain the LLM to behave like an analytical engine rather than a freeform copywriter.
Approach
Using Gemini and Perplexity, I mapped the domain, competitors, and common failure modes, then defined DestinySync’s positioning as “modern metaphysics analytics” and the core three-card UX: BaZi foundations, Astrology foundations, and a Resonance synthesis headline.
Execution
The Execution and Summary diagrams on this page show the three phases, workflow comparison, and prompt architecture in detail.
- Workflow comparison. I evaluated two AI-assisted workflows side by side before committing.
- Workflow 1 — Figma + Claude Design: I imported Figma components into Claude Design to generate UI. In practice, the AI consistently drifted from design system rules, colours and typography deviated even with explicit constraints, and correcting each issue burned significant tokens. On a Pro plan, I hit the weekly usage limit quickly, forcing multi-day interruptions. The token cost of iterating against design system constraints made continuous progress difficult.
- Workflow 2 — Lovable + structured system prompt: Rather than uploading a design system, I instructed the AI to use shadcn as the component foundation and defined constraints through structured prompting: platform, core product concept, tech stack, information architecture, and interaction rules. A fixed JSON schema constrained LLM output to a predictable structure that the UI could reliably depend on. Token consumption was meaningfully slower, and the workflow stayed uninterrupted, better suited to DestinySync’s scope.
- Prompt as infrastructure. A fixed reasoning pipeline (BaZi → Astrology → Resonance) and a strict JSON schema, including dedicated freemium fields, turned the hosted LLM into a predictable analytical service the UI could depend on.
- Bilingual UX. Localization rules live inside the prompt, so Chinese and English readings share the same psychological framing and brand voice rather than being post-translated copies.
- Freemium design. With no backend, I still prototyped monetization through a half-reveal pattern on the Resonance card: a short visible preview, a blurred premium section, and an unlock CTA that simulates payment and records intent. This kept the stack static while letting me test conversion messaging and interaction patterns on a live prototype.
Reflection
Five operational findings and three principles I now carry into other projects.
- Claude Design produces stronger results with creative freedom than with design system constraints. The more rules you add, the more tokens you spend correcting drift.
- Mobile interfaces perform better than desktop/web, which tend to introduce excessive whitespace and layout inconsistencies.
- For small, focused projects, Lovable with structured prompts is faster and cheaper.
- For complex flows requiring brand consistency, Claude Design + Claude Code → Figma MCP is the more scalable path, a workable foundation for manual refinement.
- For simple screens inside an established design system, building directly in Figma is still faster and more cost-effective than AI generation.
What I now apply
- Use AI heavily for domain mapping, but keep humans in charge of the product gap and positioning.
- Treat models, tools, prompts, and schemas as design decisions with UX consequences, not just implementation details.
- Ship with embedded LLMs (e.g. Lovable’s hosted models) first; only invest in custom APIs after the UX and business value are validated on a working prototype.
