DEV Community: Constanza Diaz

From Prompt to Practical: Evolving HandyFEM’s User Flow with Claude.ai + Mermaid.live

Constanza Diaz — Wed, 15 Oct 2025 12:14:42 +0000

In my previous post about HandyFEM user flow I used Figma and ChatGPT to create a user flow for may app. This time I asked claude.ai, and I've got a much more complete version.
First of all I explained Claude all about my app, and I tried creating a prompt to create my chart in RapidChart, because I saw a post about it, but unfortunately it didn't work as expected, the chart was never built, and I tried several times, I even tried to make a smaller one, but nothing was built at all.

So I asked claude.ai for alternatives to RapidChart, and I decided to give a try to Mermaid.

It gave me a good enough result, already more complete than what I've done before, but with less visual references... so I copy/pasted my previous diagram and suggested to integrate both ideas.

new diagram:

Color-coded:
Yellow = Buttons
Light blue = Forms
Teal = Screens
Purple = Decision points
Blue = Professional UI
Green = Client UI
Red = Admin UI
Gray = System processes

The diagram shows the actual interface elements and navigation flow, making it practical for your developers to reference when building the app!

(Disclaimer: I had to iterate a few times in Claude, to get the correct flow, as the admin flow was incomplete).

The following image is just an unreadable screenshot for a reference, it was too large to attach in real size:

UI/Navigation flow and User journey flow:

View fullsize.

From Prompt to Practical: Evolving HandyFEM’s User Flow with Claude.ai + Mermaid.live

Constanza Diaz — Tue, 14 Oct 2025 21:43:23 +0000

I’m building HandyFEM, a directory + marketplace connecting women professionals in construction and repairs with clients. In my previous post, I sketched an initial user flow using Figma and ChatGPT. This time I pushed further: I briefed Claude with the full app context and iterated toward a color-coded, developer-ready UI/navigation diagram using Mermaid.

This post documents what I tried, what failed, and what finally worked—so you can reproduce the setup without losing hours to tooling dead ends.

Goal

Create a single source of truth for HandyFEM’s navigation and user journeys—clear enough for stakeholders, and concrete enough for developers to implement screens, forms, and decisions.

Attempt 1: RapidChart (didn’t pan out)

I first tried to auto-generate the diagram via RapidChart prompts. Multiple attempts—including smaller subsets—didn’t render a chart at all. Interesting idea, but in my case it wasn’t reliable enough to ship.

Tooling takeaway: if your diagram generator is brittle, switch to a text-based standard you can version-control.

Pivot: Mermaid for reproducible, versioned diagrams

Claude suggested alternatives, and I decided to give Mermaid a try. It immediately produced a decent first draft—already more complete than my earlier diagram, even if it lacked some visual cues.

To enrich it, I pasted my previous flow and asked Claude to integrate both. That gave me structure + detail.

The final diagram (color-coded for quick scanning)

Legend:

Yellow = Buttons.
Light blue = Forms.
Teal = Screens.
Purple = Decision points.
Blue = Professional UI.
Green = Client UI.
Red = Admin UI.
Gray = System processes.

This mapping keeps discussions concrete. Designers and developers can point to the exact element in the flow and agree on behavior.

Note: I iterated a few times in Claude to complete the admin path.

The image below is a small screenshot just for reference.

UI/Navigation flow and User journey flow:

Full size:

Minimal, reproducible snippet (Mermaid)

Here’s a simplified fragment that captures the pattern I used—screens, forms, decisions, and role-scoped branches. You can drop this into any Mermaid-enabled markdown and expand it for your app.

flowchart TD
  %% Legend-inspired classes
  classDef screen fill:#0fb,stroke:#066;       %% Teal
  classDef form fill:#b3e5fc,stroke:#0288d1;   %% Light blue
  classDef decision fill:#b39ddb,stroke:#512da8; %% Purple
  classDef button fill:#ffeb3b,stroke:#f57f17; %% Yellow
  classDef pro fill:#90caf9,stroke:#1565c0;    %% Blue (Professional UI)
  classDef cli fill:#a5d6a7,stroke:#2e7d32;    %% Green (Client UI)
  classDef admin fill:#ef9a9a,stroke:#c62828;  %% Red (Admin UI)
  classDef system fill:#bdbdbd,stroke:#616161; %% Gray (System)

  %% Entry
  A[Landing Screen]:::screen --> B{Choose role}:::decision

  %% Client path
  B -->|Client| C[Client Dashboard]:::screen
  C --> D[Search Professionals Form]:::form
  D --> E[Results Screen]:::screen
  E --> F[Request Quote Button]:::button
  F --> G[Request Form]:::form
  G --> H[System: Notify matched pros]:::system

  %% Professional path
  B -->|Professional| P[Pro Dashboard]:::screen
  P --> Q[Complete Profile Form]:::form
  Q --> R[Verify Identity Button]:::button
  R --> S[System: KYC check]:::system
  S --> T{Approved?}:::decision
  T -->|Yes| U[Receive job requests]:::screen
  T -->|No| V[Manual review]:::admin

  %% Admin path
  B -->|Admin| A1[Admin Panel]:::admin
  A1 --> A2[Moderate Listings]:::admin
  A1 --> A3[Resolve Disputes]:::admin

Why this helps:

Text-as-diagram means you can version the flow in Git, review it in pull requests, and co-edit with your team.
Color classes encode semantics you can reuse across large diagrams.
Branching by role makes gaps obvious and audit-able.

Practical notes

Prompt shape matters. My best results came from supplying Claude with the app glossary, roles, and UI primitives (screen, form, decision, button, system).
Iterate role by role. I filled Client and Professional paths first, then Admin.
Keep it modular. Break huge flows into linked sub-diagrams per feature if your tool or host chokes on size.
Treat it like code. Store the .md or .mmd in your repo and make changes via PRs.

What I’ll do next

Split the mega-diagram into feature-level Mermaid files.
Connect each node to issue links or Figma frames for implementation hand-off.
Add acceptance criteria to decisions and forms to reduce ambiguity during dev.

If you’re mapping a complex app, pairing a capable LLM with Mermaid gives you speed, structure, and a durable artifact your team can actually build from.

Lovable vs V0 - Vibe coding a Single Landing page

Constanza Diaz — Thu, 02 Oct 2025 15:47:55 +0000

Today I am testing Lovable and V0 to create the website for Oriana Di Guida, a Image consultant for men.

I have to say that I like working on V0 better than Lovable, especially because it allows to edit the code in the browser... but the results were so much better in Lovable for the first attempt this time. This is the result from the prompt that I will provide at the end of this article, although I did make a few little tweaks:

and this is the first attempt of V0, you will see that the design is so much simpler and didn't mathe the colors I wanted:

On the other hand, now V0 has a new feature for creating Design Systems, so I created my own DS with my desired colors, for light and dark mode:

And now... after applying a customized DS/theme... The page looks much more professional and elegant than Lovable. Although I am having troubles to update the fonts, which I still don't love.

Building a Full Stack Web App from scratch: First Steps

Constanza Diaz — Mon, 29 Sep 2025 22:23:35 +0000

Introduction

I am Constanza Díaz, Web developer, industrial designer, UX/UI enthusiast, aspiring entrepreneur, and self-taught digital product creator — currently building my own web application and documenting the process.

I've been working as a front end developer for the last 6 years and now I'm planning to develop my own web application named HandyFEM, a digital platform designed to connect women professionals in skilled trades with clients.

I am doing this as a way to learn by doing, as artificial intelligence is evolving so quickly and becoming a must for every developer and digital product creator and owner. At the same time, I will build my own personal project, which I am developing as a business project at Innoemprèn Sostenible, a program for entrepreneurs at Tecnocampus University in Barcelona, Spain.

Building this app will be a good way to create a very complete application where multiple features can be added — this is a very big challenge as a designer-developer-entrepreneur and a true one-woman band, but also a great way to show all my multiple skills in one place :D.

After a few attempts of "vibe coding" without a plan using Vercel v0 and Lovable, I realized my app is too ambitious to be done in only one prompt :D. So I decided to create a professional approach and document it, so that I can learn everything during the process and get feedback from other devs and designers.

I'm documenting every step — from mapping the app structure to experimenting with AI-driven prototyping.

For this project, I will start with Vercel v0 as an AI assistant for generating frontend components, with Supabase as the backend layer. This blog series will serve both as a technical journal and a record of decisions that shape the MVP.

Starting with a Map

AI tools like Vercel v0 can generate impressive amounts of code quickly. The risk? Losing track of fundamentals if the product lacks a clear structure.

To avoid gaps, I started by outlining the navigation map of HandyFEM: a high-level diagram of screens, user flows, and connections. This ensures that all the important features won’t be overlooked later.

HandyFEM Navigation Map (MVP)

Here’s the first structural map created in FigJam. It defines the scope of the MVP and keeps development aligned:

Caption: HandyFEM Navigation Map (MVP) — Yellow: buttons | Green: components (will develop more detail later).

Key sections:

Landing Page: entry point with signup, login, and directory access.
Auth: client and professional signup, plus login.
Role-Based Dashboards: tailored panels for clients and professionals.
Public Directory: searchable list of professionals with filters.
Professional Profiles: detailed pages with contact options.
Messaging System: list of conversations and direct chat.

Lessons from the Process

Dashboard ≠ Profile

Dashboards serve as control centers. Profiles are just editable data. Keeping them separate opens room for metrics, history, or verification in the future.
Roles must be explicit

Defining client vs. professional flows early makes the product scalable without major refactors.
Planning is leverage

One diagram clarified priorities and prevented the common trap of coding first and restructuring later.

What’s Next

The next step is translating this map into Jira epics and tasks, preparing a Sprint 0 focused on:

Setting up Supabase tables and relationships.
Configuring authentication (email + password).
Establishing the initial Next.js + Tailwind architecture.

This structured approach allows me to integrate AI tools without sacrificing control or long-term scalability.

👉 This post opens the series on building HandyFEM from scratch. The upcoming entries will cover Jira planning, Sprint 0 setup, and the integration of Vercel v0 into the workflow. Follow the hashtag #HandyFEMapp if you don’t want to miss the progress!

📎 For those who want to dive deeper or leave comments on my board, the full navigation map is available here: Open FigJam Board

📚 HandyFEM App Series

🔗 Previous: none (this is the first post)

🔗 Next: From Prompt to Practical: Evolving HandyFEM’s User Flow with Claude + Mermaid