Antes de mais nada, este não é um texto para dizer que programadores são mais inteligentes ou que usuários são leigos. Pelo contrário: é para lembrar que ambos os lados têm seus desafios — e que, no fim, todo sistema é feito por pessoas e para pessoas.

Do lado do desenvolvedor…

Quem nunca passou por isso: você entrega o sistema funcionando, validado, com mensagens claras… e no dia seguinte recebe um chamado:

“O sistema está com bug.”

Quando, na verdade, era só uma mensagem que o usuário não leu — ou não entendeu.

Isso não é burrice. É falta de UX.

Do lado do usuário…

Tentar usar um sistema que parece ter sido feito por um alienígena também não é fácil.

Quantos já tentaram preencher um formulário, erraram uma vírgula no CPF e tiveram que recomeçar tudo do zero? Frustrante, né?

UX/UI: a ponte entre os mundos

É aqui que entra o verdadeiro herói: UX/UI. Design de interface não é sobre beleza — é sobre comunicação e usabilidade.

• Prevê erros antes que eles aconteçam.
• Mostra mensagens claras.
• Oferece caminhos lógicos.
• Respeita o tempo e a inteligência do usuário.

Conclusão

Se um sistema exige que o usuário pense como um programador, ele não é intuitivo. Se o desenvolvedor não se coloca no lugar do usuário, o sistema não é empático.

“Programar é construir pontes — não muros.”

Vamos trocar experiências? Seja como dev ou como usuário, comenta aqui e compartilha sua visão. 👇

Antes de começar o desenvolvimento, é essencial entender como o usuário vai navegar e interagir com o sistema. O User Flow garante que cada passo da jornada seja pensado para ser intuitivo e funcional.

Por que começamos pelo User Flow?

Mapear o User Flow nos ajuda a entender o que realmente importa para o usuário. Para o Mini CRM Lead Tracker, o foco está em simplicidade, eficiência e visão gerencial de qualidade.

Fluxo Principal (Atualizado para MVP Profissional):

1. Login: Usuário faz login seguro com email e senha.
2. Dashboard (Analytics):
   • Big Numbers (Total de Leads, Leads Ativos, Leads Fechados).
   • Funil Visual (Quantos leads por estágio).
   • Últimos Leads Cadastrados.
3. Página Leads (Operacional):
   • Kanban View (movimentação de leads por estágio).
   • Lista View com Filtros Inteligentes (Status, Origem, Período).
   • Histórico de Movimentações do Lead (registro de mudanças de estágio).
   • Visualizar Detalhes do Lead (dados completos do lead).
   • Adicionar Novo Lead.
   • Exportar Leads (Excel/Sheets).
4. Logout: Finalizar sessão de forma segura.

Diagrama de User Flow (Atualizado)

O que esse fluxo proporciona?

• Visão gerencial clara para gestores.
• Operação simples e ágil para o time comercial.
• Escalabilidade para integrações futuras.
• Facilidade de uso com UX pensada desde o início.

“Fluxo bem desenhado hoje, menos retrabalho amanhã.”

No próximo capítulo do Diário de Bordo, vamos modelar as entidades de dados com base nesse fluxo e preparar o diagrama ER inicial. Acompanhe!

Ser um bom desenvolvedor(a) front-end hoje vai muito além de codar com a última framework do mercado. As empresas procuram profissionais completos, que entreguem mais do que interfaces bonitas — entreguem experiências reais.

O que define o dev front-end que as empresas querem?

• UX/UI na prática: Não é só saber HTML e CSS — é entender como o usuário pensa e sente. Design não é decoração, é usabilidade e experiência.
• Domínio de Figma: Saber ler, editar e transformar protótipos em código real. Figma virou o idioma universal do design digital.
• Ferramentas além do Figma:
  • Photoshop: Para edição de imagens, mockups e tratamento visual.
  • Illustrator: Para trabalhar com vetores, ícones e logos responsivos.
  • After Effects: Para animações e microinterações modernas em UI.
• Inglês técnico: Entender documentação, Stack Overflow, bibliotecas e colaborar com times globais.
• Stack afiada: Domínio sólido da stack principal — React, Vue.js ou qualquer outra — mas com vontade de aprender novas tecnologias.
• Resolução de problemas: Mais importante do que frameworks é a capacidade de pensar, solucionar e evoluir.
• Boa comunicação: Saber colaborar com designers, produto e explicar problemas técnicos de forma simples é essencial.

Mais do que codar — é entregar

No final, o dev front-end ideal é aquele que entrega valor. Que entende o usuário, o design, o time e o produto. Que vê além da tela.

“Ferramentas mudam. Linguagens evoluem. Mas a capacidade de resolver problemas e criar boas experiências é o que fica.”

Quer saber mais sobre como se preparar para ser o dev que o mercado procura? Continue acompanhando o blog — novos artigos toda semana!

Iniciamos hoje o desenvolvimento do Mini CRM Lead Tracker, um sistema pensado para profissionais e pequenas equipes que precisam de um CRM leve, prático e objetivo.

Objetivos do Projeto

• Captura de leads via landing page integrada.
• Gerenciamento visual de leads em um Kanban (Arrastar e Soltar).
• Exportação rápida dos leads para Excel ou Google Sheets.
• Relatórios básicos para acompanhamento de vendas.

Stack Tecnológica

• Back-end: Laravel (PHP 8.x)
• Front-end: Vue.js 3 + Vite
• API REST: Documentada com Swagger (OpenAPI)
• Banco de Dados: MySQL
• Futuras Automação: Python para relatórios e follow-ups

Próximos Passos

Agora vamos avançar para a definição da arquitetura inicial e modelagem de dados, que vão sustentar a evolução do projeto.

“Cada linha de código será pensada para ser limpa, escalável e bem documentada — porque o futuro agradece.”

Quer acompanhar essa jornada? Fique de olho — novos capítulos do Diário de Bordo serão publicados toda semana!

Documentação de API não é luxo — é necessidade. Especialmente quando estamos construindo um sistema real, como o nosso Mini CRM Lead Tracker.

Para garantir que o sistema seja sustentável, optamos por usar o padrão Swagger para documentar a API RESTful do CRM.

O que é Swagger?

Swagger é um conjunto de ferramentas que usa o padrão OpenAPI Specification para definir, visualizar e interagir com APIs RESTful de maneira padronizada e automática.

Por que estamos usando Swagger no Mini CRM?

• 📚 Documentação automatizada e padronizada dos endpoints de leads.
• 🔍 Facilidade para o front-end Vue.js consumir a API.
• 🛡️ Melhora a manutenção e escalabilidade do CRM.
• 🤝 Facilita a integração com futuras automações em Python e exportações para Sheets.

Exemplo real de anotação (Laravel PHPDoc)

  /**
   * @OA\Post(
   *     path="/api/v1/leads",
   *     summary="Cria um novo lead",
   *     @OA\RequestBody(
   *         required=true,
   *         @OA\JsonContent(
   *             required={"nome", "email"},
   *             @OA\Property(property="nome", type="string"),
   *             @OA\Property(property="email", type="string")
   *         )
   *     ),
   *     @OA\Response(
   *         response=201,
   *         description="Lead criado com sucesso"
   *     )
   * )
   */
  

Conclusão

Swagger nos permite manter o nosso Mini CRM organizado, claro e fácil de integrar — o que é fundamental para qualquer sistema sério que queremos que dure e evolua.

“Se não está documentado, é como se não existisse.”

Você já documenta suas APIs assim? Ou ainda deixa tudo na mão de Deus? 😂

Quem nunca voltou para um código meses depois e pensou:

“Que inferno é esse?”

Depois de anos codando projetos de todos os tamanhos, desenvolvi um processo próprio para estruturar cada projeto que começo. Neste artigo, compartilho meu estilo de programação — da documentação inicial às boas práticas no código e gestão do projeto.

Documentação: antes de escrever a primeira linha de código

Antes de qualquer comando no terminal, eu crio um documento PDF onde descrevo o projeto:

• Visão geral do sistema
• Descrição dos fluxos principais
• Funcionalidades essenciais
• Modelagem inicial do banco de dados

Depois disso, passo para diagramas e modelagens (como ERD – Entity Relationship Diagram) e crio os protótipos das telas usando o Figma.

Back-end: organização, padrão e clareza

Sou especialista em PHP e adoto o padrão PSR-12 para manter o código limpo e consistente. Minhas práticas incluem:

• Comentários estratégicos nos pontos críticos do código, explicando decisões complexas.
• Documentação de APIs com Swagger, automatizando a geração de documentação técnica.
• Variáveis em inglês e camelCase como padrão de nomenclatura.
• Retornos em inglês ou português dependendo da necessidade do projeto (pensando em whitelabel).
• Modelagem de banco de dados relacional com relacionamentos claros e integridade referencial.
• Arquitetura MVC para organização e escalabilidade.

Front-end: organização e modularidade

No front-end, minha filosofia é separar bem os blocos de código CSS:

• Botões, títulos, formulários e animações recebem estilos específicos e modularizados.
• Uso frameworks como Vuetify ou Bootstrap quando o projeto exige agilidade e consistência visual.

Organização: produtividade e rastreabilidade

Para organizar tarefas e acompanhar o progresso do projeto, utilizo o Jira. Isso ajuda a:

• Documentar decisões tomadas.
• Organizar sprints e tarefas.
• Registrar históricos para auditorias futuras.

Repositório: controle de versão e organização

Todo projeto que desenvolvo é versionado com Git e hospedado no GitHub ou GitLab. Minhas práticas de repositório incluem:

• Commits pequenos e frequentes, sempre com mensagens claras e padronizadas ([tipo]: descrição — exemplo: feat: criar endpoint de login).
• Uso de branches para desenvolvimento de features, correções e testes (feature/, fix/, hotfix/).
• README.md completo explicando como rodar o projeto, configurações e instruções básicas de deploy.
• Licença e arquivo de contribuição (LICENSE e CONTRIBUTING.md), quando o projeto é open source ou colaborativo.
• Documentação gerada e linkada (Swagger para APIs, Storybook para front-end).

Tiago’s Code Style: meu manifesto de boas práticas

• 📚 Documentação inicial antes do primeiro commit.
• 🧠 Código seguindo PSR-12 e princípios SOLID.
• 🐫 Nomenclatura em inglês e padrão camelCase.
• 🛡️ APIs documentadas com Swagger.
• 🏛️ Modelagem e relacionamento de bancos de dados robustos.
• 🎨 CSS modularizado e organizado por componentes.
• 📋 Jira para gestão e rastreabilidade.
• 📚 Repositórios Git bem documentados e versionados.

“Código não é só para rodar. Código é para durar.”

Esse é o meu jeito de construir software. E você? Qual é o seu estilo de programação?