Skip to main content

Master Jony, Fast Product Design (PDM-A)

Intro​

Hey there, design adventurer! Welcome to the magical realm where pixels meet purpose and wireframes waltz with wonder. I'm Jony, your Product Design Master, and I'm here to turn your solution specs into something so beautiful, so functional, so delightfully clickable that users will literally want to hug their screens. (Please don't actually hug screens—fingerprints are the enemy of good design.)

Here's the truth bomb: Most products look like they were designed by a committee of nervous accountants at 3am. Functional? Maybe. Inspiring? Absolutely not. Beautiful design isn't frosting on the cake—it's the whole bakery. It's the difference between "yeah, it works" and "oh my God, where has this been all my life?" Every pixel tells a story. Every interaction is a tiny love letter to your user. And if you're not designing with that kind of emotional intention, well, you're basically making digital toast when you could be creating design soufflé.

Hyperboost Formula​

Alright, let's talk about the secret sauce—the thing that makes this whole journey work like a Swiss watch wrapped in a rainbow. Welcome to the Hyperboost Formula, or as I like to call it, "How to Build Stuff People Actually Want Without Losing Your Mind."

What is the Hyperboost Formula?​

Think of Hyperboost as the greatest hits album of product methodology. We've taken every proven framework—Lean Startup, Design Thinking, Jobs-to-be-Done, Outcome-Driven Innovation—and remixed them into something that actually works in the real world. It's not just theory; it's a battle-tested, validate-everything, ship-with-confidence system that compresses months of guesswork into weeks of smart decisions.

The DNA: Build-Measure-Learn—Relentlessly​

At the heart of Hyperboost is the Build-Measure-Learn loop, and we run it like it's going out of style (spoiler: it never will). Every step is an experiment. Every output is data. Every decision gets validated against reality, not wishful thinking. We build the smallest thing that proves something, measure what actually happens (not what we hope happens), learn ruthlessly, and repeat. No sacred cows, no "trust me, users will love it," just cold, beautiful evidence.

Integration of Methods: Lean Startup, Empathy, and AI​

Here's where it gets spicy. We blend three superpowers:

  • Lean Startup Discipline: Waste is the enemy. Every dollar, every hour, every pixel must earn its place. If the data says pivot, we pivot. If it says kill the feature, we throw a tiny funeral and move on.
  • Deep Human Empathy: Efficiency is cool, but humans aren't spreadsheets. We obsess over the user's Tuesday morning frustration, their 2am workaround, their secret wish that someone would finally just get it. Design is empathy made visible.
  • AI Acceleration: Why spend three days on something AI can nail in thirty minutes? We deploy AI for research, wireframes, technical specs, even code—so your brain can focus on the magic only humans can create: strategic insight, emotional intelligence, creative leaps.

Why Does the Hyperboost Formula Matter?​

Because hope is not a strategy, and pretty mockups don't pay rent. Hyperboost exists to de-risk every step, compress every timeline, and ensure that what you ship actually matters. You'll dodge the classic traps: building features nobody asked for, designing for yourself instead of users, scaling before you've proven anything. With Hyperboost, confidence compounds with every step. By the time you launch, you're not crossing your fingers—you're placing calculated bets backed by evidence.

Anatomy of the Hyperboost Journey​

Picture this as a relay race where every runner passes a baton of validated truth. Each phase unlocks the next, and nothing moves forward without proof. Here's the circuit:

  • 00: Context Intake & Dispatch— We gather every shred of context: who are we designing for, what solutions exist, what constraints bind us, what success looks like. No assumptions, just facts.
  • 01: Track What Matters— Build the metrics hierarchy, define the North Star Metric, connect outcomes to solutions. If we can't measure it, we don't build it.
  • 02-13: The full design gauntlet—Information Architecture, UX flows, UI wireframes, interactive prototypes, world-class design critique, build-ready PRPs, and finally, a handoff so clean the next agent could execute it in their sleep.

Every step is a logic gate. Pass with evidence, or loop back and strengthen the proof. By Step 13, you don't just have designs—you have a complete, executable design system that any builder (human or AI) can run with.

Core Principles Guiding Every Step​

  • Emotional Resonance First: Users remember how you made them feel, not your technical specs. Design for delight, not just function.
  • Ruthless Simplicity: Every element earns its place. Complexity is easy; elegant simplicity takes genius.
  • Evidence Over Ego: Personal taste is fun for dinner parties, not product design. User data wins, always.
  • Traceability: Every design decision traces back to a user need, a metric, a validated outcome. No orphan pixels.
  • Autonomous Handoff: Outputs must be so clear, so complete, that any builder can execute without hunting you down for context.

Process Overview​

  • 00: Context Intake & Dispatch
  • 01: Track What Matters (Value Tree & Metrics)
  • 02: Organize Your Product Experience (Information Architecture)
  • 03: User Experience Flows (UX)
  • 04: User-Interface Design (Design System & Component Library)
  • 05: User-Interface Design (Wireframes & Visual Templates)
  • 06: Interactive SVG Prototype (Approved UI)
  • 07: SV-Grade Design Critique & Excellence Validation
  • 08: Product Reqs Prompt (PRP)
  • 09: PRD Update (Post-Design Alignment)
  • 10: Design Package Manifesto
  • 11: AI Coder Build Manual
  • 12: User Testing Guide & Intermezzo
  • 13: Conclusion & Handoff

Phase 1: Foundation & Metrics​

Welcome to Phase 1, where we stop guessing and start knowing. Before we touch a single wireframe, we need to understand what success actually looks like. This phase is about building the measurement foundation and information backbone that keeps every downstream decision honest. If you skip this, you're basically designing in the dark with mittens on. Don't design in the dark with mittens on.

Step 00: Context Intake & Dispatch​

Intro​

Every great design journey starts with a question: "Wait, what are we actually building, and for whom?" Step 00 is where I become your friendly interrogator, gathering every piece of context that matters. Think of it as design archaeology—we're excavating the truth about your solutions, your users, your constraints, and your ambitions. No detail is too small, no assumption too sacred.

Here's the reality: most design failures happen because someone skipped the boring stuff up front. They assumed they knew the user, guessed at the constraints, winged the success criteria, and then wondered why nobody loved the final product. Not on my watch.

Product Concept​

This step is pure intake and dispatch. I'm not making design decisions yet—I'm making sure we have all the ingredients before we start cooking. We inventory solutions from your roadmap, validate user personas (HXC/ICP), confirm business goals and OKRs, and map any existing context: journey maps, pain/gain analyses, solution briefs. If it exists and it matters, I want to see it.

Think of it like a pilot's pre-flight checklist. Boring? Maybe. Essential? Absolutely. We check for completeness, flag gaps, and make sure every downstream step has the context it needs. No heroics, no shortcuts—just methodical, obsessive preparation. Because great design is 80% preparation, 20% inspired execution.

Actions​

I'm going to ask you a series of focused questions to map the landscape. What solutions are we designing? Which persona (Sage? Dani?) are we serving? What's the roadmap ID? What constraints (budget, timeline, platform) bind us? I'll validate that we have the foundational docs: JTBD maps, DOS lists, solution briefs, business goals. If anything's missing, I'll flag it early so we're not scrambling at Step 07 wondering why we don't know the target user.

Then I route us to the right workflow path. Some solutions need full-depth design (Path A), others need faster cycles (Path B/C). I match the workflow to your context, so we're running the right race, not just any race.

Deliverables​

Honestly? No artifacts here—just clarity. The "output" is a validated context map and a clear decision on which path we're taking. Think of it as the foundation that makes everything else possible. Once we're aligned, Step 01 becomes obvious instead of overwhelming.

Step 01: Track What Matters (Value Tree & Metrics)​

Intro​

Alright, design friend, buckle up. This is where we stop talking in vague terms like "user engagement" and start defining exactly what success means in cold, hard numbers. If you can't measure it, you can't improve it, and you definitely can't celebrate it when you nail it. Step 01 is where we build your metrics hierarchy—the North Star Metric at the top, the key drivers below, and the detailed signals beneath those.

Meet Sage, our case study hero. Sage is a long-time digital nomad building an AI-powered conversational app for entry-level nomads (Dani is the target user). Sage knows the what (an app that helps Dani navigate visa rules, find wifi-friendly cafes, connect with other nomads), but the how is still fuzzy. This step gives Sage the measurement blueprint—so every design decision from here forward connects to a real, trackable outcome.

Product Concept​

Welcome to the land of OKRs (Objectives and Key Results), Value Trees, and the North Star Metric (NSM). These aren't buzzwords; they're the GPS coordinates for your product. OKRs translate ambition ("we want users to love this") into measurable reality ("60% of users activate within 14 days"). The Value Tree connects your NSM to the drivers that move it, which connect to the granular metrics you'll actually track. It's beautiful, it's logical, and it's the difference between "we think it's working" and "here's the exact dashboard proving it's working."

I also layer in Outcome-Driven Innovation (ODI) here, because we're not just tracking activity ("users clicked the button"), we're tracking outcomes ("users felt confident making a decision"). Every metric must trace back to a validated user need from your DOS (Desired Outcome Statements) list. If a metric doesn't connect to a real user pain or gain, it's vanity tracking and we delete it without mercy.

For Sage's app, the NSM might be "14-day activation rate"—the percentage of new users who complete their first visa check, book their first cafe, and join one community thread within two weeks. That NSM gets broken down into drivers: onboarding completion, feature discovery, social connection. Each driver gets supporting metrics. And boom—we have a measurement machine that keeps design honest.

Actions​

I'll analyze your solutions, pull from your DOS lists and roadmaps, and build a complete metrics hierarchy. I create a visual Value Tree (yes, in beautiful SVG because aesthetics matter even in dashboards) showing how everything connects. I define your NSM, identify 3-5 key drivers, and map the supporting metrics beneath each. I also spec out the technical implementation—what events to track, what tags to use, what analytics platform integrations you'll need.

For every solution on your roadmap, I tie metrics back to user jobs and outcomes. No metric is orphaned. Every data point serves a decision. I pressure-test this with you, validate alignment with your OKRs, and lock it down before we move forward.

Deliverables​

  • mm_solutions_yaml: Updated Opportunity Solution Tree with complete metrics hierarchy, weighted priorities, NSM integration
  • support/master_jony/a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/01b_metrics_vtree_md: Complete metrics hierarchy with technical implementation framework for agentic coders
  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/01b_metrics_vtree: Full metrics documentation with visual Value Tree (HTML+SVG)

Step 02: Organize Your Product Experience (Information Architecture)​

Intro​

Okay, time to build the skeleton. Information Architecture (IA) is the invisible structure that makes your product feel intuitive instead of like a maze designed by a sadistic puzzle-maker. It's how users find what they need without cursing your name. It's navigation, content hierarchy, taxonomy, labeling—all the unsexy stuff that separates "delightful" from "I just rage-quit and downloaded your competitor."

Sage's app could have the best visa database in the world, but if Dani can't find it in under three seconds, it's useless. This step is where we architect the information flow so Dani lands on the homepage, understands what's possible, navigates confidently, and accomplishes goals without needing a PhD in your product.

Product Concept​

IA is part art, part science, and entirely user-centric. We start with cognitive load theory: human brains can hold about 7 (plus or minus 2) chunks of information at once. So if your main nav has 47 options, you've already lost. We use card sorting, tree testing, and user journey mapping to create hierarchies that match user mental models, not internal org charts.

I also bring in Technical Architecture Design here, because IA isn't just for users—it's for builders. Agentic coders need to know how routes map to features, how content types relate, how permissions layer. A good IA doc is executable by both humans and AI, with zero ambiguity.

For Sage, we might structure the app into three core sections: Explore (visa rules, city guides), Connect (community, events), and Manage (personal itinerary, bookmarks). Each section gets sub-navs, each feature gets a logical home, and Dani never has to wonder "wait, where do I find that again?"

Actions​

I'll analyze your solutions, map user jobs to content types, and build a site map that reflects user priorities, not your team's preferences. I define navigation patterns (bottom tabs? hamburger menu? wizard flow?), label everything clearly (no jargon unless your users actually use it), and create taxonomy systems for tagging, filtering, searching.

I also spec out the technical architecture: routes, data models, permission tiers, integration points. Everything is documented so a coder (human or AI) can implement without hunting for missing pieces.

Deliverables​

  • support/master_jony/a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/02_navigation_ia_md: Complete IA foundation with navigation, technical architecture, implementation specs for entire roadmap
  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/02_navigation_ia: Full IA documentation (HTML) with site maps, nav patterns, taxonomy, technical specs

Step 03: User Experience Flows (UX)​

Intro​

Now the magic starts. UX flows are the choreography of interaction—the step-by-step dance your user performs to accomplish a goal. Sign up. Onboard. Complete a task. Get delighted. Every flow is a mini-story with setup, conflict, and resolution. Done well, users feel like geniuses. Done poorly, they feel like they're trapped in an escape room designed by their worst enemy.

For Sage's app, let's map Dani's first visa check. She lands on the app, sees a clear CTA ("Check Your Visa"), taps it, selects her passport country and destination, gets instant results with next steps, and feels a wave of relief because the scary bureaucratic maze just became manageable. That emotional arc? That's UX flow design.

Product Concept​

I apply Hooked Model (trigger, action, variable reward, investment), Fogg Behavior Model (motivation + ability + prompt), and Jobs-to-be-Done orchestration. Every flow maps to a user job, hits key emotional beats, surfaces AHA moments, and builds habit loops. We're not just moving users through screens—we're creating experiences that feel effortless, rewarding, and worth repeating.

I also inject gamification and delight engineering where appropriate. Maybe Dani gets a little celebration animation when she completes her visa check. Maybe the app remembers her preferences and suggests the next logical step. These micro-moments are what separate "fine" from "I'm telling all my friends."

For every feature in your roadmap, I map the happy path, the edge cases, the error states, the recovery flows. I diagram the emotional journey alongside the functional journey, because both matter.

Actions​

I'll take each solution from your roadmap, extract the core user jobs, and map complete UX flows: entry points, decision points, success states, failure states, contextual help. I design for hooks (what brings them back?), AHA moments (when do they "get it"?), and habit formation (how do we make this part of their routine?).

Every flow gets annotated with emotional states (frustration, curiosity, delight, confidence), interaction patterns, and implementation notes for coders.

Deliverables​

  • support/master_jony/a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/03_[%feat_id%]_flow_[%unique_feat_name%]_md: UX flow per feature with emotional journey orchestration, Hook loops, AHA moments, implementation specs
  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/03_[%feat_id%]_flow_[%unique_feat_name%]: Complete UX flow documentation (HTML) with flow diagrams, interaction patterns, emotional arcs

Phase 2: Visual Design & Prototyping​

This phase is where invisible structure becomes visible beauty. We go from concepts and flows to actual pixels, colors, typography, components—all the things users see and touch. This is the "oh wow" phase, where your product stops being wireframes and starts feeling real.

Step 04: User-Interface Design (Design System & Component Library)​

Intro​

Welcome to the design system workshop, where we build the LEGO blocks of your product. A design system is a collection of reusable components, design tokens (colors, typography, spacing), patterns, and guidelines that ensure every screen feels like part of the same family. It's the difference between "professional product" and "Frankenstein's monster assembled from six different templates at 2am."

For Sage, the design system establishes the visual identity: maybe warm, approachable colors (sunset oranges, calm blues) that feel nomadic and adventurous. Clean, modern typography that's readable on phone screens in bright sunlight. Consistent button styles, form inputs, card layouts—so every feature feels native to the same product.

Product Concept​

I apply Atomic Design (atoms → molecules → organisms → templates → pages), Accessibility Standards (WCAG 2.1 AA minimum, because inclusive design isn't optional), and Design Token Architecture. Tokens are the DNA of your design: instead of hardcoding "#FF6B35" everywhere, we define a token like "color-primary" that can be updated globally. Change one value, update the entire app. That's power.

I also consider platform conventions (iOS Human Interface Guidelines, Material Design for Android, web best practices) and tailor components to match user expectations. Fighting platform conventions is a losing battle—embrace them, then add your unique flavor on top.

Actions​

I'll analyze your brand identity (if you have one; if not, we'll define it), define your design tokens, and build a component library covering all the basics: buttons, inputs, cards, navigation, modals, loaders, empty states, error states. Every component gets documented with usage guidelines, accessibility specs, and code snippets for implementation.

I create both light and dark mode variations (because users expect it now), responsive breakpoints (mobile, tablet, desktop), and state variations (default, hover, active, disabled, loading). Everything is specced for handoff to builders.

Deliverables​

  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/04a_design_system_template: Design system template (baseline for generation)
  • support/master_jony/a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/04a_design_system_md: Complete design system foundation with atomic components, design tokens, accessibility specs for entire roadmap
  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/04b_design_system: Full design system documentation (HTML) with component library, tokens, usage guidelines

Step 05: User-Interface Design (Wireframes & Visual Templates)​

Intro​

Now we get specific. Armed with our design system, we create the actual screens users will see—wireframes and visual templates for every key interface. This is where abstract concepts become concrete designs. Dani's visa check screen? We design it. The community feed? We design it. The onboarding wizard? You guessed it.

This step is iterative and collaborative. I'll generate multiple concepts, you pick favorites, we refine, we version, we approve. Every interface gets a version number (v01, v02, v03) so we can track iterations and ensure we're building the approved version, not some rogue prototype from two weeks ago.

Product Concept​

I blend UI Design Principles (visual hierarchy, contrast, whitespace, alignment) with Gestalt Psychology (how humans perceive visual patterns) and Emotional Design (aesthetic-usability effect—pretty things feel easier to use). Every screen must be functional and beautiful, clear and delightful.

I also apply F-pattern and Z-pattern reading behaviors for layouts, ensure touch target sizes meet accessibility minimums (44x44px on mobile), and use color psychology to guide attention and emotion. Yes, I'm obsessive about these details. That's the job.

For Sage's visa check screen, we might use a card-based layout, large friendly icons for passport selection, clear visual feedback when results load, and a celebratory green checkmark when everything's good. Every pixel is intentional.

Actions​

I'll take each feature from your UX flows, design 2-3 visual concepts, gather your feedback, refine the winners, and lock in approved versions. Every wireframe includes annotations: interaction states, copy suggestions, edge case handling, accessibility notes.

I version everything meticulously, archive rejected concepts (so we have a paper trail), and ensure approved designs are clearly marked and ready for prototyping.

Deliverables​

  • support/master_jony/a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/05b_[%feat_id%].v[YY]_ui_[%gen.words(max:3, 'ui_unique_name')%]_md: Source UI wireframe spec (markdown) for HTML rendering
  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/05b_[%feat_id%].v[YY]_ui_[%gen.words(max:3, 'ui_unique_name')%]: HTML/SVG wireframe version for UI interface (screen, dialog, component) extracted from flows, IA, design system

Step 06: Interactive SVG Prototype (Approved UI)​

Intro​

Static wireframes are great, but nothing beats a clickable prototype. Step 06 is where we assemble approved UI versions into an interactive SVG prototype—a navigable, semi-functional version of your product that users can actually click through. It's the "try before you buy" experience, and it's invaluable for testing flows, gathering feedback, and getting stakeholder buy-in before we write a single line of production code.

For Sage, this means Dani can tap through the visa check flow, see the screens transition, experience the interaction patterns, and provide real feedback before we commit to full development. Cheaper to fix now than after launch.

Product Concept​

Interactive prototypes bridge design and development. They're detailed enough to feel real but fast enough to iterate without developer time. We use SVG (Scalable Vector Graphics) because it's crisp at any resolution, lightweight, and can be made interactive with simple scripting.

I apply rapid prototyping principles: focus on critical flows (not every screen), make it feel real enough to test, but don't over-polish. This isn't the final product; it's a validation tool. We also enforce cleanup discipline—discarded UI versions get archived or deleted so builders don't accidentally implement the wrong design.

Actions​

I'll gather all approved UI wireframes, assemble them into logical flows, add navigation hotspots (tap here to go to next screen), and export a navigable SVG prototype. I confirm with you which versions are final, archive or delete the rejects, and package everything for testing.

You can share this prototype with users, stakeholders, or investors. It's the closest thing to a real product without writing code.

Deliverables​

  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/06_interactive_svg_prototype: Navigable SVG prototype assembled from approved UI versions, with confirmed cleanup of discarded versions

Phase 3: Validation & Refinement​

Now we shift from creation to critique. We've built the designs—are they world-class? Do they meet Silicon Valley-grade standards? This phase is where we pressure-test everything, benchmark against the best, and refine until it sings.

Step 07: SV-Grade Design Critique & Excellence Validation​

Intro​

Alright, real talk time. Your designs might look great to you, but are they actually great? Step 07 is where I put on my brutally honest critic hat and benchmark your work against world-class standards. We're talking Apple-level polish, Airbnb-level usability, Stripe-level clarity. If your designs can survive this critique, they can survive anything.

This isn't mean-spirited nitpicking; it's loving, constructive feedback designed to elevate your product from "pretty good" to "industry-leading." Sage's app deserves to compete with the best—so we hold it to the best standards.

Product Concept​

I apply Design Excellence Frameworks: heuristic evaluation (Jakob Nielsen's usability heuristics), aesthetic-usability effect validation, accessibility audits, and competitive benchmarking. I compare your designs to category leaders, identify gaps, celebrate strengths, and provide actionable recommendations.

This is hypothesis framing and decision gating in action. We set the success criteria (does it meet WCAG AA? Is visual hierarchy clear? Do CTAs pop?), test against them, and make go/no-go calls. If something fails, we iterate. If it passes, we lock it in and move forward with confidence.

Actions​

I'll conduct a comprehensive design critique covering usability, aesthetics, accessibility, brand consistency, and technical feasibility. I benchmark against 3-5 competitors or category leaders, identify best practices you're missing, and deliver a prioritized list of improvements.

Some feedback will be quick fixes (adjust button padding, increase contrast). Some will be strategic (rethink onboarding flow, add missing states). All of it will be clear, specific, and implementable.

Deliverables​

  • support/master_jony/a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/05_design_critique_md: Comprehensive SV-grade design critique with benchmarking, creative analysis, actionable recommendations
  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/05_design_critique: Full design critique documentation (HTML) with heuristics evaluation, competitive analysis, improvement roadmap

Step 08: Product Reqs Prompt (PRP)​

Intro​

Here's where design meets buildability. A Product Requirements Prompt (PRP) is a self-contained, executable spec that tells an AI coder (or human developer) exactly what to build, how to build it, and why. It's the Rosetta Stone between your design vision and working code.

For Sage's visa check feature, the PRP includes the UX flow, approved wireframes, design system specs, technical requirements, edge cases, and success criteria. A builder picks it up and runs—no hunting for context, no guessing about intent, no Slack messages at midnight asking "wait, what did you mean here?"

Product Concept​

PRPs are the ultimate handoff artifact. They combine UX flows, UI specs, IA context, metrics tracking, and implementation guidance into one markdown document. I apply Solution Ideation & Synthesis to structure the content logically, User Experience Flow Design to ensure flows are complete, and Product Requirements Prompt best practices to make it executable by agentic coders.

A good PRP is modular (focused on one feature), complete (no missing pieces), testable (clear acceptance criteria), and autonomous (no external context required). If a builder finishes reading and still has questions, the PRP failed.

Actions​

For every feature in your roadmap, I'll create a dedicated PRP. I pull from UX flows, wireframes, design system, IA, metrics, and PRD context. I write clear feature descriptions, user stories, acceptance criteria, edge case handling, and technical specs.

I also include embedded source content (copy, images, design tokens) so builders aren't hunting across five tools. Everything they need is in one place, versioned and approved.

Deliverables​

  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/06_[%feat_id%]_prp_ch:figma|{{prp_platf_slug}}_[%unique_feat_name%]: Self-contained PRP (markdown-only) with navigable prototype specs embedded with full source content

Step 09: PRD Update (Post-Design Alignment)​

Intro​

Your PRD (Product Requirements Document) started life back in the solution discovery phase, but now it needs an upgrade. We've designed the interfaces, validated the flows, defined the metrics—all of which adds critical context to the original requirements. Step 09 is where we sync the PRD with design reality.

This keeps everyone aligned: stakeholders understand the what and why, designers understand the how, builders understand the technical scope. No one's working from outdated docs or conflicting versions.

Product Concept​

I apply Opportunity Solution Tree logic to ensure solutions still map to validated outcomes, and Product Requirements Document best practices to structure the update. PRDs typically have three parts: P1 (problems, solutions, context, metrics), P2 (feasibility, dependencies, risks), and P3 (executive one-pager for quick alignment).

We update all three with design-phase learnings: revised metrics, refined user stories, updated technical considerations, new edge cases discovered during design. Everything stays traceable and version-controlled.

Actions​

I'll analyze your existing PRD (if it exists; if not, I'll create one from scratch), integrate design-phase data, and update P1, P2, and P3 sequentially. Each part gets reviewed and approved before moving to the next.

The output is a living document that evolves with the product, keeping everyone honest and aligned.

Deliverables​

  • support/master_jony/a2_solution_discovery/{{mm_session_persona}}/{{mm_session_roadmap}}/05a_prd_p1_problems_solutions_md: Source PRD P1 (markdown) - Problems, Solutions, Context, Metrics
  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/05a_prd_p1_problems_solutions: PRD Part 1 (HTML): Problem definition, solution overview, success metrics, use cases
  • support/master_jony/a2_solution_discovery/{{mm_session_persona}}/{{mm_session_roadmap}}/05b_prd_p2_feasibility_risks_md: Source PRD P2 (markdown) - Feasibility, Dependencies, Security, Risks
  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/05b_prd_p2_feasibility_risks: PRD Part 2 (HTML): Technical feasibility, dependencies, security compliance, risk assessment
  • support/master_jony/a2_solution_discovery/{{mm_session_persona}}/{{mm_session_roadmap}}/05c_prd_p3_one_pager_md: Source PRD P3 (markdown) - Executive One-Pager Summary
  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/05c_prd_p3_one_pager: PRD Part 3 (HTML): Executive one-pager summary for quick stakeholder alignment

Phase 4: Packaging & Handoff​

The final stretch. Everything's designed, validated, documented—now we package it beautifully, guide the builders, plan the testing, and hand it off with confidence.

Step 10: Design Package Manifesto​

Intro​

Imagine you're a builder landing in this project for the first time. You see 47 files, 12 folders, 83 wireframes. Where do you even start? The Design Package Manifesto is your treasure map—an index of every critical artifact, what it's for, and when to use it.

For Sage's project, the manifesto might say: "Start with 02_navigation_ia to understand structure. Review design system (04b) before coding any UI. Reference PRPs (06_*) for feature-specific specs. Check 05_design_critique before shipping to ensure quality standards." Clear, ordered, no guesswork.

Product Concept​

This is Hypothesis Framing & Decision Gating applied to documentation. We're not just dumping files; we're curating a guided experience. The manifesto organizes artifacts by role (designer, developer, PM, QA), by phase (setup, build, test, launch), and by priority (must-read vs. nice-to-have).

A good manifesto eliminates onboarding friction. New team members get productive in hours, not weeks. Agentic coders know exactly which files to parse. Everyone stays aligned.

Actions​

I'll inventory every artifact generated so far, categorize them, write descriptions and usage guidelines, and assemble a comprehensive index. I'll highlight dependencies (read this before that), critical paths (must-have for launch), and optional resources (deep dives for curious folks).

The output is a single, scannable document that answers "where do I find X?" and "what do I read first?"

Deliverables​

  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/08_design_package_manifesto: Design Package Manifesto: complete index of design artifacts, organized by role and usage context

Step 11: AI Coder Build Manual​

Intro​

We've handed off to human builders before, but agentic coders? They need different instructions. Step 11 is where we create an operations manual specifically for AI builders—setup prompts, build prompts, context files, quality gates, and troubleshooting guides. Everything an AI needs to execute the design with world-class quality.

For Sage's project, this manual ensures that whether the builder is a human contractor, an in-house dev, or an agentic coding agent like Cursor/Windsurf/Bolt, they all produce consistent, high-quality results.

Product Concept​

I apply Agentic Build Operations best practices: modular prompts (setup vs. build vs. test), memory bank context files (design system rules, coding standards), quality assurance frameworks (automated checks, manual review gates), and adaptive personalization (adjust instructions based on builder proficiency).

The manual is both human-readable and AI-parseable, with clear sections, tagged content, and executable code snippets. It's the ultimate build guide.

Actions​

I'll compile setup instructions (environment, dependencies, design system integration), build prompts (how to implement features from PRPs), memory bank files (reusable context for AI agents), and quality gates (what to check before calling a feature "done").

I'll also include troubleshooting: common issues, how to resolve them, when to escalate. The goal is autonomous, high-quality execution with minimal human intervention.

Deliverables​

  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/09_prototype_build_manual: Agentic coder operations manual with setup prompts, build prompts, memory bank context, quality gates

Step 12: User Testing Guide & Intermezzo​

Intro​

Designs are done, PRPs are ready, build manual is complete—but we're not launching blind. Step 12 is where we plan user testing: what hypotheses are we validating, what tests will we run, what success looks like, and how we'll iterate based on feedback.

For Sage, we might test: Does Dani understand the visa check flow without onboarding? Does the community feed drive engagement? Are there any "WTF" moments in the UX? We define tests, recruit testers, run sessions, gather data, and loop back to design if needed.

Product Concept​

I apply Hypothesis Validation frameworks: define testable assumptions, design experiments to prove/disprove them, set success criteria, and build feedback loops. User testing isn't "let's see if they like it"—it's "let's validate these 5 specific hypotheses with measurable outcomes."

This is also the intermezzo—a pause before full build to de-risk, refine, and ensure we're shipping the right thing, not just a thing.

Actions​

I'll extract key design hypotheses (e.g., "users will complete visa check in under 60 seconds"), design test protocols (moderated sessions, unmoderated remote tests, A/B tests), define success metrics (task completion rate, time on task, user satisfaction scores), and create a testing timeline.

I'll also draft a feedback integration plan: what changes trigger redesign vs. minor tweaks vs. post-launch iterations.

Deliverables​

  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/10_user_testing_guide: User testing guide with hypotheses, test protocols, success criteria, feedback loop integration

Step 13: Conclusion & Handoff​

Intro​

We made it, design friend! Step 13 is the victory lap and the baton pass. Everything's designed, validated, documented, and packaged. Now we hand it off to the next agent (probably ABM-A, the Agentic Builder Master) with a comprehensive summary, clear next steps, and all the artifacts they need to execute flawlessly.

For Sage, this means the entire design package—metrics, IA, UX flows, UI wireframes, prototypes, PRPs, build manuals, testing plans—is ready for builders to turn into a real, functioning product. No gaps, no ambiguity, just clean handoff.

Product Concept​

I apply Handoff & Continuity principles: explicit summaries (what we did, why it matters), artifact inventories (what's included), next-agent routing (who takes over, what they need), and context preservation (no knowledge loss in the handoff).

A great handoff means the next agent (or team) hits the ground running. They don't need you on standby; they have everything they need to succeed autonomously.

Actions​

I'll compile a completion summary: journey recap, key decisions, design highlights, validation results. I'll create a handoff checklist (✓ metrics defined, ✓ IA complete, ✓ UX flows validated, ✓ UI approved, ✓ PRPs ready, ✓ build manual delivered). I'll route to the next agent with clear instructions and contact context if needed.

I'll also archive the entire project in a structured format, ensuring nothing gets lost and future teams can reference our work.

Deliverables​

  • a3_product_design/{{mm_session_persona}}/{{mm_session_roadmap}}/11_handoff_summary: Conclusion summary with journey recap, artifact inventory, next-agent routing, and handoff checklist

Conclusion​

And that's the journey, my friend. From context intake to final handoff, we've transformed solution specs into a complete, world-class product design. Sage now has everything needed to build an app Dani will love—metrics that matter, architecture that scales, UX that delights, UI that shines, and build specs that eliminate guesswork.

Every step was evidence-backed. Every decision was intentional. Every artifact is executable.

If you followed this process, your product isn't just pretty—it's strategic, measurable, user-centered, and ready to win in the market. That's the Hyperboost Formula in action. That's design done right.

Now go build something beautiful. And remember: pixels are love letters. Make every one count.