Como Planejar seu App | As 7 Fases Pré Desenvolvimento

Main ideas / lessons

• A common (costly) mistake is starting development immediately—without doing initial project planning—whether using no-code tools or traditional code.
• Good projects (including personal ones) need upfront planning to avoid rework, flaws, delays, and performance/security problems later.
• The video presents a no-code startup methodology for pre-development planning, organized into 7 phases (Phase 0 through Phase 6). These phases can (and should) be done before opening any development tool.
• Each phase can function as a validation checkpoint with stakeholders so you don’t discover major misalignment only after development begins.

---

Methodology: the 7 pre-development planning phases (detailed)

Phase 0 — General conceptualization (requirements + scope)

• Define the application at a high level:
  • What the app is
  • Its objective
  • What it must do
  • Core functions/features
  • Pages/screens
  • User types and overall structure
• Align the concept with all stakeholders (clients, partners, internal team).
• Perform requirements gathering (the speaker references it as a key activity):
  • Gather/clarify software requirements carefully.
• Produce a clear functional baseline:
  • List all functionalities
  • Define pages
  • Define user types
  • Define permissions/roles for each user type

Example used in the video: a multi-company project management app

• Projects broken down into 3 levels: projects → stories → tasks.

---

Phase 1 — Seek inspiration (usability, not copying)

• Look for inspiration from analogous products to improve usability.
• Apply Jacob’s Law conceptually:
  • Users spend time on other websites and expect similar UI/behavior patterns.
  • Users expect familiar interactions (e.g., buttons trigger expected outcomes; menus open as users anticipate).
• Rule of thumb:
  • Inspire and adapt, don’t copy.
• Do inspiration per page/flow:
  • Example pages considered: login, dashboard, etc.
  • Compare with known tools (the video mentions examples below).
• Mentioned inspiration sources/products:
  • ClickUp
  • Asana

Output:

• A broader view of usability patterns across screens and workflows, enabling better UX decisions.

---

Phase 2 — Wireframes (low-fidelity designs)

• Create wireframes / low-fidelity designs:
  • Focus on layout and element arrangement
  • Focus on usability and interaction structure
  • Avoid colors and visual polish for now
• Document and map flows between screens.

Purpose:

• Get an early, visual-yet-neutral version that stakeholders can validate.
• Validate without distractions from design aesthetics.

Example outputs described:

• Login page wireframe including registration area
• Company registration portion
• Dashboard wireframe

---

Phase 3 — Map user flows (actions by screen and by user type)

• Document user flows as the detailed actions possible on each screen.
• Consider differences between user roles:
  • Different users may perform different actions or follow different paths.
• Tie flows to specific screens and include observations/rules.

Example flows on login/registration screens:

1. New registration flow

   • Company owner registers on the platform
   • First registration grants an administrator profile for that company
   • Includes an onboarding process (e.g., provide company name)
   • After onboarding:
     • user is directed to that company’s dashboard
     • user begins using the app
   • Notes generated for implementation:
     • Creates a new administrator user
     • Creates a new company record in the database

2. Login flow

   • Users click “Log in” to reach the login form
   • Existing users log in with email/password
   • If onboarding isn’t complete for the company:
     • onboarding becomes mandatory (required onboarding flow)

---

Phase 4 — Create an excellent data model (database structure)

• Design the database before development.
• Build an initial (but solid) data model:
  • This is described as the “heart” of the application.

Why it matters:

• Good modeling prevents performance and scalability issues.
• Without good modeling, applications can require major refactoring later.

Example entities mentioned in the video:

• user
• company
• project
• story
• task

Model tables/fields and relationships:

• Example: company fields include name and logos (small + large)
• Example: an onboarding indicator (e.g., yes/no field) to enforce the mandatory onboarding flow
• Example: user fields include user ID, email, first name, last name, photo, profile, company

Video references additional learning resources:

• Separate relational vs non-relational data modeling courses (mentioned as available on the channel).

---

Phase 5 — Security and privacy rules

• Create security/privacy rules (mainly for the database).
• Based on what you already defined:
  • Who the users are
  • What they can do
  • What data exists (from the data model)

Rule structure concept:

• For each data table/field, define what a given user type can access.

Tool-agnostic concept:

• Implementation varies by platform (Bubble, others), but the principle is the same.

Example rules described:

• A user can see the relevant data in the database.
• Users should only see data for their own company, not data belonging to other companies.
• Extend the restrictions across tables and fields.

---

Phase 6 — Add design (high-fidelity UI) + optional prototype

• Apply visual identity:
  • Color palettes
  • Styles
  • Fonts
  • UI design characteristics
• Convert wireframes into high-fidelity designs:
  • You now know positioning and flows; you add visual polish.
• Optional but recommended:
  • Create a clickable prototype using a tool like Figma.

Purpose of prototypes:

• Show stakeholders a more realistic feel of the app.
• Communicate “this is almost ready,” while noting the prototype may have no logic (design-only).

---

Validation strategy (cross-cutting idea)

• Each phase can serve as a stakeholder validation point, reducing costly late changes:
  • Validate Phase 0 (concept)
  • Validate Phase 1 (inspiration direction)
  • Validate Phase 2 (wireframes)
  • Continue validating through later phases (as implied)

The video emphasizes: without these checkpoints, clients may reject expectations after development is already underway—causing delays and rework.

---

Tool tips mentioned (mapped to phases)

• Planning/documentation tool:
  • Miro (used for planning and wireframes; praised for simplicity/no distractions)
• Inspiration/design references:
  • Behance
  • Dribbble
  • Web design/wireframe inspiration tools
• High-fidelity design + prototypes:
  • Figma (more robust for design + prototyping)
• User flow documentation:
  • Page Flows (paid; documents flow patterns, including onboarding processes)

---

Speakers / sources featured

Speaker

• Neto Camarano (host; introduces “nocode Startup” channel and the 7-phase methodology)

Referenced external products/apps (as inspiration examples)

• ClickUp
• Asana

Referenced concepts / laws

• Jacob’s Law (usability expectation regarding how users behave across websites)

Referenced tools/resources (mentioned)

• Miro
• Behance
• Dribbble
• Figma
• Page Flows

Referenced training content (channel internal)

• Videos/courses on:
  • Software requirements gathering
  • Data modeling for relational databases
  • Data modeling for non-relational databases
  • A Bubble training program walkthrough that applies these phases step-by-step