Tiago Luvizoto Neves

Autor: Tiago Luvizoto Neves

Por que todo dev deveria entender UX (mesmo que nunca faça design)
Se você ainda acha que UX é só um problema do designer, sinto te informar: você está jogando contra o próprio time. Entender UX não é sobre saber usar Figma ou desenhar telas bonitas. É sobre entender como as pessoas usam aquilo que você codifica.

UX é sobre não gerar dúvida

Se o usuário não sabe onde clicar, se perde, não entende uma mensagem de erro ou abandona um formulário… isso não é um problema só de design. É um problema seu também.

O código que você escreve tem UX

Um botão mal posicionado, um input sem máscara, uma API que responde uma mensagem técnica que o usuário nunca vai entender… tudo isso é UX ruim, vindo do desenvolvimento.

Por que devs ignoram UX?
- Porque acham que “isso é coisa de design”
- Porque focam só na regra de negócio e esquecem a experiência
- Porque nunca ensinaram isso na faculdade, nem no bootcamp
O que muda quando você entende UX?
- Você começa a prever onde o usuário vai errar
- Evita que problemas de usabilidade virem tickets, bugs ou suporte
- Entrega sistemas mais claros, simples e bem pensados
- Seu código deixa de ser “funciona” e passa a ser “funciona pra quem usa”
💡 “Se ninguém entende como usar, não adianta estar funcionando.”

Conclusão

Você não precisa ser designer. Mas se você escreve código, faz API, cria backend ou front… você precisa entender experiência de usuário. Isso é o que separa quem entrega sistema… de quem entrega solução.

O código perfeito não é o que funciona.
É o que funciona… e faz sentido pra quem usa.
junho 16, 2025
O que uma empresa realmente espera de um desenvolvedor sênior?
Antes de qualquer coisa: esse texto não é sobre endeusar quem tem 10 anos de carreira ou coleciona frameworks no currículo.

É sobre o que, na prática, o mercado espera de alguém que se apresenta como desenvolvedor sênior — principalmente se você quer conquistar a confiança de empresas mais exigentes.

1. Domínio técnico consistente

Não se trata de saber tudo, mas de saber o suficiente com profundidade. Dominar a stack principal, escrever código limpo, legível e escalável. Entender arquitetura. Saber quando usar um padrão de projeto — e quando não usar.

2. Visão de produto e experiência do usuário

O dev sênior não vive em bolha. Ele entende que o que está sendo construído precisa funcionar para alguém. Participa das conversas com UX/UI, testa os fluxos com empatia, entende a jornada do usuário.

3. Comunicação clara e respeitosa

Ser direto sem ser ríspido. Saber ouvir, negociar prazos, discordar com maturidade. Muitas vezes, é mais sobre como se fala do que o que se fala. E isso impacta diretamente o clima do time.

4. Mentoria e troca

Não é só saber fazer — é saber ensinar. Empresas valorizam quem compartilha conhecimento e fortalece o time. Ser sênior é ser referência técnica, mas também humana.

5. Visão de longo prazo

Um bom sênior pensa no código que vai herdar, não só no que está escrevendo. Ele considera performance, manutenção, documentação e testes — mesmo no MVP. Entrega com responsabilidade e não deixa bombas-relógio escondidas no projeto.

6. Lidar com dis trações (e proteger o foco do time)

Ser sênior também é saber dizer “não” para o que atrapalha. Às vezes o maior desafio não está no código, mas no barulho em volta dele. Interferências, decisões apressadas e mudanças mal comunicadas geram mais bugs do que linhas ruins.

🪧 “Se não for ajudar, atrapalhe!” — disse alguém na daily. Acredite: o sênior lembra.

É papel do dev experiente manter o foco da equipe, filtrar o ruído e ajudar o time a trabalhar com consistência.

Conclusão

No fim do dia, o que as empresas esperam de um dev sênior é:
- Alguém que resolve problemas com visão ampla
- Que contribui para o crescimento do time
- E que entrega valor real — com consistência
Se você se vê nesse perfil ou está no caminho para isso, saiba: o mercado está olhando. E precisa de mais profissionais assim.
junho 11, 2025
Mini CRM Lead Tracker — Modelagem de Dados e Diagrama ER
No desenvolvimento de qualquer sistema sério, a modelagem de dados é um dos pilares. No Mini CRM Lead Tracker, essa etapa é fundamental para garantir escalabilidade, segurança e clareza nas relações entre usuários, empresas e leads.

Por que começar com um Diagrama ER?

O Diagrama Entidade-Relacionamento (ER) é a espinha dorsal do projeto. Ele ajuda a visualizar:
- Como as tabelas se conectam entre si
- As chaves primárias e estrangeiras
- A estrutura relacional do banco
- Multiplicidade (1:N, 1:1, etc.)
Estrutura atual do Mini CRM

O sistema ainda está em fase MVP, mas já conta com uma modelagem que respeita boas práticas e antecipa crescimento:
- companies: dados das empresas contratantes do sistema (modelo multitenancy)
- users: usuários da empresa com função (master ou operador)
- roles: define os tipos de permissão no sistema
- leads: contatos gerenciados no funil
- kanban_stages: estágios personalizados do funil
- activity_logs: histórico de movimentações de leads
Preview do Diagrama ER

Próximos Passos

A partir da modelagem, vamos iniciar a construção real das migrations e modelos no Laravel, garantindo que tudo seja bem tipado, documentado e validado.

“Modelar bem não é burocracia — é visão de longo prazo.”

Se quiser acompanhar todos os capítulos do Diário de Bordo, continue com a gente aqui no blog. Estamos construindo esse CRM de forma aberta, transparente e com boas práticas.
junho 10, 2025
Programadores vs. Usuários? Não. Somos todos parte da mesma interface.
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. 👇
junho 9, 2025
Mini CRM Lead Tracker — Definição de Fluxo do Usuário (User Flow)
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!
junho 9, 2025
O Que as Empresas Procuram em um Desenvolvedor Front-end em 2025
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!
junho 6, 2025
Mini CRM Lead Tracker — Diário de Bordo: Kickoff e MVP
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!
junho 5, 2025
Como documentar APIs de um Mini CRM usando Swagger
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? 😂
junho 3, 2025
Meu estilo de programação: Como penso, documento e organizo meus projetos
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?
junho 3, 2025