After defining that the product would be designed primarily for tablet use, my first step was to study in detail the workflow of an aesthetic doctor’s consultation.

This analysis was essential to understand how to adapt Symphon AI to the real context of use in clinics, considering not only the dimensions and weight of the tablet but also how it could naturally integrate into the professional’s routine, minimizing any friction in adoption.

Thus, the main strategy was to align the digital experience with the user’s real behavior, ensuring that technology acted as a facilitator rather than an obstacle.

“If i'm building an AI product, why not building if an AI Product?”

During the development of Symphon AI, the first AI agents focused on creating code and digital products began to emerge. It was during this period that tools like Lovable and Vercel’s v0 were released.

This context marked a turning point for me: it was my first project where AI was not limited to generating text or images, but was also used as part of the design and product-building process.

Because of this, I had to iterate extensively with different tools and research workflows from industry professionals, understanding how each structured their processes. The goal was to find ways to raise the quality of the interfaces, which at that point were still below the level expected for a finalized product ready to be presented to the client.

Garbage in, garbage out

During my research, I came across several workflows and methodologies for building AI-supported products. Despite their differences, they all shared the same premise: the importance of building a solid Knowledge Base, fueled by reference files.

This knowledge base became the fundamental starting point to ensure that the agent could generate more reliable and contextualized responses, reducing the risk of hallucinations and increasing the accuracy of the results.

What worked for me

After exploring several different workflows, I defined the one that made the most sense in terms of fundamentals and logical sequence for planning and building the project.

This workflow served as a guide to structure each stage of the work: from defining the Masterplan to organizing the documents that would guide both design and development.

Wearing multiples Hats at the same time

For the project to make sense and for all documents to be built consistently, I realized I couldn’t act solely as a designer, limited to thinking about color palettes, typography, and visual patterns. It was necessary to take on different roles throughout the process.

• PM Hat (Product Manager): I defined the product roadmap, mapping the user journey screens, their relationships, the target audience, and the main flows.

• Engineering Hat: I thought like a software engineer, defining which UI libraries would be used and how they would integrate with the chosen technologies. At this stage, I established the use of:

  • Shadcn as the UI library;

  • React + Typescript as the front-end languages (native to v0);

  • Supabase as the backend.

This multiplicity of roles was essential to bring consistency to the project, ensuring that design, product, and technology were aligned from the very beginning.

Agents working together

Since the most efficient formats for uploading files to the AI’s Knowledge Base were .pdf or .md, I used Notion as the central documentation tool.

I organized the project information into existing folders in Notion and leveraged the native GPT integration on Mac so the AI could access this material. From there, GPT generated the necessary documents to feed the agent in v0, ensuring it had a solid knowledge base to operate effectively.