Desenvolver um site, app ou webapp não é um processo simples. Porém, é possível utilizarmos algumas metodologias para produzir entregáveis em um espaço de tempo menor.

O segredo está em algumas siglas utilizadas no desenvolvimento de software, como LEAN, MVP, DRY, KIS. Todas são métodos para nos ajudar a ter entregáveis menores, frequentes e de melhor qualidade.

Entregas menores, testes, validações e discussões podem ser aplicados nas fases iniciais de cada etapa, observando a necessidade de mudança logo no começo. Quando os problemas ou incertezas de um projeto são identificados logo no início, é certo que teremos entregas mais assertivas e um menor desgaste durante a produção. É como evitar que um pequeno problema torne-se um grande desastre.

Trago aqui apenas algumas anotações e técnicas que acho interessante para um processo de desenvolvimento produtivo e confortável, além de links para quem quer se aprofundar em cada um dos assuntos. Algumas destas técnicas eu utilizo no meu trabalho e outras venho pesquisando e me interessando cada vez mais.

Análise de grandeza (OG)

Todo projeto precisa de um norte, um ponta pé inicial e um dimensionamento. Além do propósito bem fundamentado sobre porque devemos fazer tal projeto, é importante ter em mente os limites que esse projeto deve respeitar – mais conhecidos como prazos.

Mesmo com um fluxo contínuo, é bom entender da capacidade do seu time e da sua disponibilidade.

Uma das primeiras etapas no desenvolvimento de um projeto é levantar a Ordem de Grandeza, isto é, fazer a estimativa de quanto tempo, superficialmente, o projeto demandaria para ser executado.

Com o levantamento da ordem de grandeza, é possível entender quanto o projeto custará, quais recursos devem ser alocados, qual sua prioridade nas esteiras de projetos (qual projeto será feito primeiro) e até mesmo sua viabilidade —  um projeto pode custar menos se for entregue a uma consultoria de TI ou fábrica de software (body shopping) para desenvolvimento terceirizado, por exemplo.

A ordem de grandeza é feita com arquitetos de software e a consultoria de times de UX, UI, desenvolvedores, e coachs de metodologias ágeis, as quais seu projeto utiliza (Agile, Scrum, SAFE, Lean, Kanban, etc)

Cuidado nesta fase: não superestime nem subestime prazos — você e seu time serão cobrados por estas estimativas.

Vale lembrar que essa fase é opcional — muitas empresas conseguem ser extremamente ágeis e não formulam a grandeza de projetos  – elas simplesmente definem um backlog de atividades e vão entregando tarefa por tarefa, simples assim. Esta facilidade, porém, depende muito da maturidade do seu time, e só a prática leva a perfeição.

LEAN UX

O entendimento da Experiência do Usuário (User Experience — UX) é uma das partes mais importantes no desenvolvimento de interfaces. É nesta fase onde definimos o que será efetivamente (ou não) produzido.

Tradicionalmente, o User Experience Design (e suas variáveis Design de Interação, User Interface Design, Arquitetura de Informação, etc.) é uma disciplina baseada em entregáveis: Wireframes, sitemaps, fluxos, taxonomia e mais uma lista enorme de entregáveis.

O problema é que algumas vezes o profissional de UX fica preso demais a esses entregáveis, e o esforço de mantê-los atualizados e consistentes acaba tomando um tempo precioso do seu dia.

Um tempo que poderia ser usado para fazer o que o profissional de UX faz melhor: pensar no projeto e em todas as suas variáveis. Fonte.

Uma solução para menos entregáveis e validações mais rápidas com o público interno e externo, é o conceito de LEAN aplicado ao UX.

• Poucos entregáveis
• Metodologia Magra de UX
• UX: pensa no projeto e todas as sua variáveis
• Valida primeiro com o cliente apenas usando um concept board, rascunho, (MVP)
• Se preocupa menos com o design
• Valida mais rápido e muda o processo assim que percebe incertezas
• Após conversas com os stakeholders apenas em cima de esboços, faz-se um wireframe simples
• Valida com cliente interno (chefe, front-end, designer)
• Testa externamente (grupo focal, testr.com.br, testaisso.com.br, qualifiqueux.com.br, whatusersdo.com)
• Se precisar, é possível fazer fluxograma, sitemaps ou apenas sentar-se com o dev e prototipar um MVP, mas não perca tempo com todos estes entregáveis
• O importante é entregar rápido, validar rápido e testar a aderência rápido, para não emperrar o processo de entregáveis da equipe de desenvolvimento de software. Se a equipe de software entregar um MVP rapidamente, é possível identificar e corrigir erros no processo logo no começo
• Documente os entregáveis e compartilhe em ferramentas de fácil acesso (Invision, Sketch, Figma, Zeplin)
• Gaste mais do seu tempo com SEO e acessibilidade, e se possível, indique o que deve ser H1, H2… roles semânticos (dialog, link, navigation, etc.), além de navegação por Tabs e leitores de tela (Jaws) — 25% de toda a população mundial tem alguma deficiência! Preocupe-se!
• Siga DRY (Dont Repeat Yourself), KIS (Keep it Simple), assim você terá itens entregues com “definição de pronto” sempre aceitos
• Entenda o tamanho do seu time e o prazo do projeto: não peça uma BMW, se não haverão braços ou conhecimento técnico para desenvolvê-la. Não frustre suas expectativas: se o time só consegue entregar um Fusca com uma porta, foque em entregar o melhor Fusca de uma porta que já se viu.
• Volte ao começo do processo, analise, reveja erros e acertos e faça melhorias contínuas — acompanhe o processo ativamente, ajude e incentive para que todos alcancem os resultados.

Não adianta apresentar um projeto e dizer que a equipe de front, ou de design, ou de UX prejudicou o resultado final.

Se alguém errou ou se perdeu, a culpa é de cada um que não acompanhou o processo de perto e não foi resiliente ao ponto de sugerir mudanças a tempo junto ao cliente para que evitasse problemas.

Para quem quer saber mais de Lean e UX, veja alguns links:

Artigos

Retirado do meetup Front UX #9 sobre LEAN UX

• Lean Manufacturing
• What’s the difference between Agile Development and Lean UX? What does Lean UX bring?
• Produtos Enxutos e o Pensamento Lean

• The Case of the Disappearing Design Phase
• Continuous Design and the NoPSD Movement
• Lean UX & Organization Design with Jeff Gothelf (Author of Lean UX & Sense and Respond)
• Spotify engineering culture (part 1)
• Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable
• A diferença entre Lean UX e Agile UX (e a importância dos protótipos no design)
• Leansoftwaredevelopment
• Lean timeline
• O que é Lean UX?
• What is Lean?

Links e gráficos sobre UX/UI/UXD no Pinterest:

• https://www.pinterest.co.uk/pin/195836283775027009

Mobile First, User First e Progressive Enhancement

Sabemos que é difícil pensar em mobile first se você é designer/UX desde a época que só existia desktop, mas hoje é mais fácil focar em um MVP se entregarmos primeiro uma solução responsiva que se encaixa primeiro na menor resolução de tela.

Nunca, mas nunca mesmo desenvolva primeiro a versão desktop e depois tente criar a chamada “versão responsiva“. Se sua tela precisa funcionar também em mobile, comece por ele.

Estamos em 2018 – já faz mais de 10 anos que os celulares tornaram-se onipresentes em nossas vida, e hoje, há mais gente usando smartphones do que os grandalhões desktops.

Ao desenvolver primeiro o desktop, você certamente vai entregar uma interface pesada, sobrecarregando o recurso de renderização do DOM com diversos display:none, além de não criar uma interface fluída, prendendo-se desnecessariamente aos já quase desnecessários breakpoints ou media queries.

Grandes empresas tem conseguido entregar interfaces únicas, que ficam incríveis do mobile até uma SmartTV de 55″ sem utilizar uma media query sequer, sem nenhum breakpoint e sem dar repaint ou reflow na timeline do DOM.

Sobre repaint e reflow do DOM:

• Otimizando a manipulação do DOM – Repaint e Reflow
• Minimizar o reflow do navegador

Desenvolver mobile first não é desenhar primeiro as telas mobile, e sim pensar em Atomic Design, começando a entender o fluxo do menor elemento de uma interface, do menor dispositivo até o seu estado maior.

Você desenvolve o menor elemento (como um átomo) e vai crescendo, expandindo, agrupando, incrementando, até chegar na sua maior resolução/composição. Isso é mobile first e atomic design, pois o componente foi pensado para crescer de forma fluida e natural.

Evite quebras e mudanças muito bruscas e não fluidas entre breakpoints mobile e desktop. Um componente que muda completamente de mobile para o desktop provavelmente precisa ser repensado, já que sua codificação trará certamente problemas de performance e ficará pesado, cheio de media queries que ajustam propriedades problemáticas do CSS, como float, margin, padding, align e tantas outras.

Prefira um crescimento da interface fluído e não atrelado em medidas de tela fixas — esqueça um pouco os 768px, 1024px, 1200px. Pense em porcentagem, viewport, etc.

Para um componente crescer fluído do mobile até grandes desktops, utilize ferramentas como Storybook, e veja se cada componente passa nos testes conhecidos popularmente como sanfonize (esticar e reduzir a tela do navegador como uma sanfona, testando a responsividade) – clientes adoram fazer isso, em IE11 ainda por cima.

Sobre Atomic Design veja estes slides:

• https://speakerdeck.com/mjcoffeeholick/componentes-pra-que

Sobre Mobile e Offline First (PWA), veja:

• 02 – Mobile First & Online First

Nunca esqueça das métricas

Analise o comportamento do seu público, conheça seus usuários, mas também inove e os ofereça novos caminhos e interfaces que ele nem sabia que precisava. O conceito de User-First prega algumas máximas que podem ser bem úteis, como para você tentar simplificar seus entregáveis:

• pixel perfect é uma mentira: não se prenda em reproduzir uma tela exatamente como feita pelo UX/UI, e isso não é um problema, desde que não comprometa o foco da interface e sua utilização. Respeite a identidade visual e preserve a interação, mas sempre negocie e opte pelo mais simples primeiro.
• evite Photoshop ao pensar em UX, um pedaço de papel às vezes lhe trará mais agilidade na hora de validar um componente
• visualize as variações do seu conteúdo: não desenvolva um componente com um título de uma linha e obrigue o seu cliente a reduzir o texto; pense que ele é fluído e pode crescer invariavelmente. É melhor se preparar para isso logo no começo do que ter que resolver depois.

Mais informações sobre User First aqui:

• Designing digital products “User First”

Progressive Enhancement

Sobre Progressive Enhancement, a dica é simples:

• Entregue o mais simples primeiro e rápido. Vá melhorando e incrementando progressivamente. Você evita grandes entregas, grandes validações e minimiza erros de compatibilidade de versões.

Quando apenas um botão da sua interface estiver inquebrável, mas da maneira mais simples, pense em passar para o próximo componente ou em incrementar o componente atual com efeitos, variações, etc.

DESIGN/UI/LOOK AND FEEL

Conceitos validados, MVP testado, protótipo básico discutido e estressado: é hora de aplicar a identidade visual da marca ou do produto.

Cores, fontes e imagens, também chamados de assets, não só ajudam o usuário a identificar o serviço como também são grandes responsáveis por performance e acessibilidade.

• Utilize softwares como Zeplin, que já entregam guidelines de cores e fontes prontinhos aos devs, além do CSS com tamanhos e medidas que eles sozinhos, dificilmente conseguiriam descobrir a partir de um jpeg ou pdf estático.
• Não perca tempo fazendo guidelines, estas ferramentas existentes hoje geram guias automaticamente, diminuindo assim a margem de erro e o tempo do seu trabalho. Utilize softwares de análise de cores WCAG, padrões de cores (fundo e fontes).
• Teste o layout para daltonismo e alto contraste (preto e branco). O Google melhora o posicionamento de sites que se preocupam com padrões AA e AAA de deficiência visual

Sobre acessibilidade:

• Diretrizes de Acessibilidade para Conteúdo Web (WCAG) 2.0

Devs, Front-end UI/UX, Front-end Fullstack

• Desenvolva mobile first (você escreve menos código e renderiza menos tela se a menor versão for seu default)
• Se force a usar ao menos o mínimo de TDD (Test Driven Development): escreva o teste do componente/tela primeiro, assim você não vai esquecer do que deve ser feito
• Escreva os testes baseado nos concepts que forem entregues e discutidos com UX logo inicialmente. Os considere como entregáveis importantes. É garantia da integridade da interface!
• Antes de codar, vá desenhando o fluxo da interface, workflows de mensagens, erros e/ou requests de APIs e dados (draw.io)
• Digramas de classe e mapas mentais também são úteis para serem desenhados em aplicações componentizadas como React, por exemplo
• Utilize softwares de teste em vários dispositivos e resoluções, como: lambdatest.com, saucelabs.com, browserstack.com
• Evite muitos fallbacks — discuta com UX/stakeholders a possibilidade de criar interfaces modern-first, se for necessário dar suporte a versões antigas use graceful degradation

Esqueci de alguma coisa? Achou algum erro? Mande uma mensagem no privado. Quer fazer um elogio? Poste nos comentários.

Até breve!