Welcome to Part II of this series in which I will focus on the thought process I use before starting to prototype an application from zero into something tangible. If you haven’t already, you can read Part I here: Prototyping Applications using Gemini CLI & Claude Code Together – Part I.
As outlined in Part I, I have developed a framework that can be applied to any prototype build:
- Visualize – Define clearly what you want to build
- Strategize – Create a concrete plan for implementation
- Realize – Build and test your prototype
- Actualize – Deploy, validate, and collect feedback
- Crystallize – Keep what works, discard the rest
- Productionize – Hand over to Engineering
In this article, we will focus on the first step, i.e. Visualizing your application before starting to build it.
Product Discovery: Since this article focuses on application prototyping which falls within the Design phase, we shall assume that product discovery has been completed. This means you’ve analyzed a market, identified a problem to solve, conducted competitor research, defined target segments and their jobs-to-be-done, and determined application features. Only after completing these essential steps are you ready to begin building application visuals.
If you’re only just getting your feet wet into the world of rapid prototyping for upskilling, Product Discovery can be skipped. But if you’re prototyping for an application that you plan to launch or you are prototyping in an enterprise setting, the Discovery phase is absolutely critical to ensure that you build an app prototype for something that users want and will use.
Step 1: Visualize
During the Visualize stage, I focus on creating a detailed PRD that outlines my priorities and desired appearance, while also defining the fundamental non-design components of the application.
I typically divide product requirement documentation into two stages. In each stage, I task myself with answering a series of targeted questions to clarify and solidify my vision for the application I want to build.
Stage 1: Features, Workflows & Integrations
The questions in this section represent essential considerations for any competent Product Manager, regardless of whether they’re using GenAI for rapid prototyping. However, when specifically leveraging AI for prototyping, documenting all these elements becomes crucial. The resulting documentation serves as the comprehensive blueprint you’ll provide to your chosen model and tool, ensuring that the model understands your complete vision, i.e. immediate needs as well as future plans.
- What are the features I need to support at launch, i.e., what is my MVP target?
- What features will I add as future enhancements?
- What different workflows should my application support at launch?
- What user journeys need to be supported?
- Are there mandatory or regulatory workflows that must be implemented on the frontend? (Example: For a mortgage application prototype, KYC and proof of fund workflows are both mandatory and regulatory)
- Are there conditional workflows to support? (Example: Answering “yes” to a form question reveals additional fields requesting more details)
- Are there IAM (Identity Access Management) controlled workflows? (Example: On a resource management platform, only supervisors can approve paid time off)
- What workflows should I add in future phases?
- Who are my target user segments, and which segments will I focus on at launch?
- What are my different user personas, and what IAM controls need to be in place at launch?
- What minimum integrations must I support at launch? (Example: Login flows like Google, Meta, SSO integrations, payment integrations, etc.)
- What integrations should I add as future enhancements? (Example: Google Drive for file imports, data export tools, location APIs, etc.)
Tip #1: Leverage AI to identify blind spots and considerations in product requirements. If you’re working independently or working on your hobby project on personal time, AI can also help you comprehensively craft and document these requirements. I will cover this in detail in a future article.
Tip #2: Start with a comprehensive list of everything you want to include in the application, giving you a complete book of work to work from. Then use NNL (Now, Next, Later) to identify your MVP, most-mvp features and future enhancements.
And now, on to the fun stuff…
Stage 2: Look & Feel
This is where you should carefully consider your application’s visual design. While most enterprise settings provide brand guidelines and design systems to follow, if you’re working independently or building a hobby app prototype, it’s crucial to think deeply about each aspect of the look and feel and document your vision precisely. I recommend these two essential resources for anyone serious about building effective application prototypes:
- Figma Design Basics: This comprehensive guide covers every fundamental aspect of design and is invaluable for understanding product design. It explains everything from tangible assets like wireframes and mockups to design concepts like lateral thinking, design thinking, human-computer interaction, design complexity, and important design aspects like accessibility, color palettes, color theory, and typography.
- Figma Design for beginners course: This course teaches you to approach design conceptually by viewing elements as nested containers. You’ll understand how layouts work and how changes to one container affect those within it. This knowledge is essential for working with AI models and tools to fine-tune your prototypes and achieve exactly the look you want.
Another resource I strongly recommend is Excalidraw, a free web-accessible wireframing tool with virtually no learning curve. Think of it as a simplified version of Figma focused solely on rapid wireframing. AI models have gotten extremely good at processing visuals, and showing what your idea looks like helps the model better understand your expectations.
In this stage, I typically answer these questions and document them as crucial inputs for the model or tool to build a prototype that closely matches my vision:
- What design aesthetic am I going for? (e.g., playful, quirky, professional, vibrant, muted, modern). Don’t hesitate to combine multiple design aesthetics to achieve a hybrid look.
- What color palette will I use in my design system?
- What gradient palette will I use for my primary colors?
- What gradient palette will I use for my secondary colors?
- What gradients do I want for hover and click states?
- What primary and secondary colors will I use for backgrounds?
- What effects do I want to implement? This is where I consider elements such as subtle animations on hover, fade in/out effects, skeleton loading states, drop shadows or glow effects on card elements, glassmorphism or transparency effects, and background blurs. These little touches separate good designs from great ones. Tip: As always, the key is achieving the right balance. Don’t add everything simply because you can. Sometimes, less is better. After a few prototyping iterations, you’ll begin to understand the sweet spot for achieving this balance.
- Do I already have a design system that I can ask the tool to import for building a component library? Tip: Most enterprise settings have their own design systems that you can import into your VSCode project and have the model build out a full component library. If you’re building a personal project, I recommend starting with publicly available design systems such as Google’s Material Design (for fun, vibrant and professional design aesthetics) or IBM’s Carbon Design System (for muted, professional and elegant design aesthetics).
- How do I want my forms to work?
- How will my forms launch (modals / sidebars / standalone)?
- What patterns do I want to support for form elements (calendars, single-choice, multi-choice options, lists, filtered lists, toggles, etc.)?
- What validations do I need to implement, and how will they activate (inline or post submission)?
- How will my edit flows work (inline editing / quick edits / full form-based edits / field-based edits)?
- How is my application structured in terms of pages, organization of information and forms? What does my Information Architecture or Sitemap look like? Generally, I document the Information Architecture or Sitemap in an Excel document, starting with the landing page and then working top to bottom on each page. I then color code common elements (For example: a reference form that could be called from two different pages would be color-coded the same in both places).
- How does the layout of content differ between web and mobile form factors?
- Example #1: Do content cards that appear side by side on the web layout stack vertically on mobile or display in a swipeable gallery layout?
- Example #2: How do flip effects on mouse hover in the web layout translate to mobile where there is no hover? What would the mobile UX look like instead?
These questions may seem overwhelming, and it’s not necessary to address all of them when starting out. What’s more important is having fun prototyping and getting comfortable with the process. Once you’re confident, start incorporating these elements into your workflow. As mentioned before: Start Small & Level Up.
Final Prep
After completing this exercise and answering these questions, I recommend starting a new chat with your preferred AI model (Gemini, ChatGPT, or Claude) and sharing this context as a Product Brief to identify any potential gaps in your planning.
A quick note: AI models process Markdown formatting more effectively than plain text. For best results, provide your instructions in Markdown format. You can reference this Markdown cheat sheet for guidance. Alternatively, consider using tools like Obsidian or Notion, which not only support Markdown exports and copy-to-clipboard functionality but also serve as repositories for your knowledge base, giving you the best of both worlds.
Here’s the template I use to validate my application vision and figure out any potential blind spots. This helps me prepare this document for the next stage.
# Your Role
You are an experienced Product Disovery team, comprising of a highly experience UX Design Lead, a highly experienced Product Manager with specific subject matter expertise in <ENTER_APP_DOMAIN_OR_OBJECTIVE_HERE> and a highly experienced Solutions Architect well versed in using the latest technology stack and effective system design and architectural patterns.
# Objective
I want to build an application prototype using <MODELS_HERE>. To do so, I plan on providing the project context in the **Product Brief** section. I'd like you to first process the overall context and understand what I want to build. I'd like you to then step through each point and synthesize how the information pertains to the overall objective. Using step-by-step reasoning, I'd like you to review the entire context and let me know if it has all the content required for <MODEL_HERE> to build the application prototype to specifications. Feel free to suggest corrections as well as recommend additional points that I may have missed out on. Once you confirm everything looks good, I will ask you to play another role and use this context to generate a master starter prompt that will get added into a .md file as project specifications for <MODEL_HERE> to reference for building the application.
>NOTE: At this point, I am not looking to build out the backend or build any integrations end to end. This will be a frontend focused application prototype only. So, do not provide any additions to the product brief about the backend aspects or integrations.
# Output Instructions
After reviewing the entire context provided in **Product Brief**, please return the revised product brief in the same format that I have entered. Preserve the existing format and structure, but feel free to modify and enhance the content.
For example: If there are additional points that need to be added to the **Workflow** section, append the points to the appropriate section. Please feel free to convert any existing points to a tone or sequence that is more friendly to being processed by <MODEL_HERE>.
# Product Brief
## Application Overview
<INSERT_APPLICATION_OVERVIEW_HERE>
## Features
NOTE: Features marked as **Now** would be included in the first release. Features marked as **Next** would be added immediately after the initial release. Features marked as **Later** would be added in future releases.
<INSERT_APPLICATION_FEATURES_HERE>
## Workflows
NOTE: Workflows marked as **Now** would be included in the first release. Workflows marked as **Next** would be added immediately after the initial release. Workflows marked as **Later** would be added in future releases.
<INSERT_APPLICATION_WORKFLOWS_HERE>
## Target Segments & User Personas
NOTE: Target segments & personas marked as **Now** would be included in the first release. Target segments & personas marked as **Next** would be added immediately after the initial release. Target segments & personas marked as **Later** would be added in future releases.
### Target Segments
<INSERT_TARGET_SEGMENTS_HERE>
### User Personas
<INSERT_USER_PERSONAS_HERE>
## Key Jobs-To-Be-Done
<DOCUMENT_JOBS_TO_BE_DONE_HERE>
## UX Design & Design Principles
### Design Aesthetic
### Colors
### Effects
### Design System
### Information Architecture
### Form Behavior
### Validation Rules & Patterns
Concluding The Visualize Phase
Remember, AI models excel at processing visuals. Your wireframes, together with the document created during the Visualize phase, provide the model with crystal-clear understanding of what you want to build. This foundational work sets you up for success in the next stages.
For this article series, I’ve chosen to showcase the simplest prototype you can build: a personal website.
As a beginner, this is the ideal starting project for several reasons:
- No data requirements
- No complex flows to design, such as login or session management
- No rule-based or validation-based forms
- No market validation needed
- Limited number of screens, allowing for multiple iterations and valuable learning experience with your tools that you can later apply to more complex prototypes
And of course, who doesn’t want to work on their personal website?
After completing my questionnaire, I spent just a few minutes building wireframes in Excalidraw. The landing page shown below took me exactly ten minutes to create. I recommend designing multiple variations if you want to evaluate different layouts, but at minimum, create two versions of each page: one for web and one for mobile. This approach saves significant time during the visual polish phase, as your initial build already closely matches your vision.
And with that, the Visualize phase is complete! In the next article in this series, I will go over the Strategize phase, which will outline how to get that killer starter prompt to whip up a functional prototype in record time.