Conclua Uma Parte
Conforme a equipe se orienta, eles começam a descobrir e acompanhar as tarefas que precisam realizar para construir o projeto. É importante, nessa fase inicial, que eles não criem um plano mestre de partes que devem se unir na última hora. Se a equipe completar muitas tarefas, mas não houver "uma coisa" para clicar e testar, é difícil sentir progresso. Uma equipe pode fazer muito trabalho, mas sentir insegurança porque ainda não tem nada concreto para mostrar. Muitas coisas estão feitas, mas nada está realmente concluído.
Em vez disso, eles devem tentar fazer algo tangível e demonstrável logo no início — na primeira semana ou algo assim. Isso exige a integração vertical de uma pequena parte do projeto, em vez de ir trabalhando nas camadas horizontais.
Integre uma Fatia
Podemos pensar nos projetos em duas camadas: front-end e back-end, design e código. Embora tecnicamente falando existam mais camadas, essas duas são o principal desafio de integração na maioria dos projetos.
Suponha que o projeto comece com muito design. A equipe poderia projetar uma variedade de telas e até implementá-las como templates ou visualizações. Mas, até que estejam conectadas a um back-end, nada faz nada. O trabalho permanece hipotético e especulativo.
O mesmo vale para o back-end. Muitas tarefas podem ser concluídas, mas sem qualquer interface de usuário — o que se pode fazer com isso? Como julgar se o trabalho em uma peça específica da lógica de negócios está realmente correto sem interagir com ela?
O que queremos, em vez disso, é escolher uma fatia do projeto para integrar. Então, quando isso estiver feito, a equipe tem algo tangível que eles provaram funcionar (ou não funcionar e reconsiderar). Qualquer pessoa pode clicar na interação e ver se a funcionalidade faz o que deveria e se o que ela faz é o que querem.
Estudo de Caso: Clientes em Projetos
Construímos um recurso no Basecamp 3 que permitia que empresas de serviços convidassem clientes para seus projetos e compartilhassem documentos, mensagens ou listas de tarefas escolhidas com eles. O conceito, definido na proposta, tinha uma variedade de partes móveis:
- Acesso de Clientes: Antes desse recurso, o modelo de acesso do Basecamp era tudo ou nada. Precisávamos de uma maneira de convidar algumas pessoas para ver apenas algumas partes de um projeto. Isso teve grandes implicações no back-end e no cache.
- Gerenciamento de Clientes: Precisávamos de uma maneira de adicionar clientes aos projetos e da capacidade de gerenciar clientes separadamente dos membros da equipe.
- Alternância de Visibilidade: Cada conteúdo de um projeto deveria ter uma opção para expô-lo ou não aos clientes.
A equipe tinha um designer e um programador. Depois de se orientarem e se familiarizarem com o funcionamento do código existente, o designer escolheu a alternância de visibilidade como o melhor lugar para integrar primeiro. Esta era a peça mais central da interface do projeto. É a que apareceria nos vídeos de demonstração e a interação que os clientes usariam mais.
O designer não fez um mockup perfeito em pixels. Em vez disso, ele experimentou diferentes funcionalidades e posicionamentos nos templates HTML do aplicativo. A alternância deveria ser dois botões de rádio, uma caixa de seleção ou um botão personalizado que muda de estado?
Enquanto isso, o programador não ficou esperando. Ele tinha orientação suficiente do pitch para começar a desenvolver o modelo de acesso.
Assim que o designer se sentiu confiante na direção básica da interface, ele chamou o programador e mostrou a alternância esboçada. Dando uma pausa no problema de acesso por um momento, o programador conectou a alternância o suficiente para que aparecesse em todos os tipos de conteúdo suportados, mudasse de estado quando clicada e salvasse seu estado no banco de dados.
Nesse ponto, a alternância não mudava realmente a visibilidade do conteúdo. Mas funcionava do ponto de vista da empresa de serviços. O designer podia clicar nela, senti-la e julgar como funcionava com dados reais em um servidor de testes.
Ainda havia mais trabalho de design a ser feito na alternância. Mas o programador não precisava mais estar envolvido. Com a funcionalidade conectada, o designer podia continuar a experimentar com textos, posicionamento, cor, renderização em visualização móvel e mais. Enquanto isso, o programador poderia voltar ao modelo de acesso ou ao que mais fosse importante abordar em seguida.
Cerca de três dias após o início do projeto, o designer apresentou a alternância funcionando a um gerente. A conversa deles levou a mais alguns ajustes e então eles puderam considerar a alternância "concluída". Uma parte importante do projeto foi projetada, implementada, demonstrada e finalizada. A equipe se sentiu bem em mostrar progresso tangível. E a equipe e a gerência sentiram confiança no projeto ao ver uma parte funcionando. Ao clicar em uma interação central logo no início, eles puderam validar que o que esperavam fazer sentido na teoria realmente parecia certo e fazia sentido na prática.
Este pequeno exemplo ilustra alguns pontos sobre como as equipes se integram em curtos períodos para finalizar uma parte do projeto de cada vez.
Programadores Não Precisam Esperar
Porque as partes móveis importantes já foram definidas no processo de modelagem, os programadores não precisam ficar ociosos esperando pelo design quando o projeto começa. Há orientação suficiente no pitch para que eles comecem a trabalhar nos problemas de back-end desde o início. Eles não conseguirão levar uma funcionalidade até a conclusão sem saber para onde ela leva no front-end, mas deve haver informação suficiente no pitch para orientar as decisões fundamentais de modelagem.
Funcionalidades Antes de Telas Perfeitas
Os programadores não precisam de um design “pixel-perfect” para começar a implementação. Tudo o que eles precisam são pontos de extremidade: elementos de entrada, botões, lugares onde os dados armazenados devem aparecer. Essas funcionalidades são o núcleo de um design de interface do usuário.
Perguntas sobre fonte, cor, espaçamento e layout podem ser resolvidas depois que as funcionalidades básicas estiverem no lugar e conectadas no código. Redação, funcionalidades básicas e alguma conexão são tudo o que precisamos para tentar uma versão funcional no navegador ou no dispositivo. Então, podemos responder às perguntas fundamentais cedo: Faz sentido? É compreensível? Faz o que queremos?
Isso significa que a primeira interface que um designer entrega a um programador pode parecer muito básica, como o exemplo abaixo. É mais parecida com uma placa de ensaio do que um design visual ou um mockup polido.
Esta captura de tela é de um aplicativo de inscrição para cursos de vários dias. O designer a fez em HTML manualmente. Há pouco estilo — apenas hierarquia visual suficiente para sentir confiança de que o layout é utilizável e favorável a futuras camadas de estilo.
Embora o design pareça simples, muitas decisões estão refletidas nele.
- A decisão de pedir o horário de chegada, mas não o de partida, veio de discussões detalhadas sobre a lógica de negócios e o modelo de cobrança.
- As opções específicas no menu suspenso de horário de chegada correspondem a regras que precisaram ser elaboradas sobre quando cobrar por refeições e pernoites.
- Os primeiros esboços do designer usavam um seletor de datas no estilo calendário para os dias de chegada e partida. Mas isso levou a problemas de UX. Alguns cursos eram longos (várias semanas) com diferentes fases. Não havia espaço em um seletor de datas no estilo calendário padrão para rotular as fases nas caixas de dias. Com um menu suspenso, ela poderia usar grupos de opções para rotular grupos de datas quando necessário. Dessa forma, os usuários não precisariam consultar uma programação em outro lugar para ter certeza de que estavam selecionando as datas corretas.
Aqui está outro exemplo. Esta é a primeira peça funcional de um aplicativo para capturar dados de entrevistas com clientes.
Nesta fase inicial, o nome do projeto (Basecamp) e o sujeito da entrevista (Jan) estavam codificados diretamente e a maioria dos links não levava a lugar nenhum.
Veja como este design é bruto. As ações são links de texto simples nas cores padrão azul e roxo do navegador. As caixas contendo os dados estão quase sem estilo, com bordas pretas simples. Por mais rudimentar que seja, este design testa alguns trade-offs importantes. O designer optou por mostrar o máximo de dados possível acima da dobra para que fosse fácil revisar as entrevistas. Isso não deixou espaço suficiente dentro de cada seção para a interface de adicionar, editar ou remover dados. Isso levou o designer a criar telas separadas para adicionar e editar dados por seção.
Este é o primeiro design para adicionar e editar "pulls" — um tipo de dado nesta técnica de entrevista. Novamente, veja como está bruto. Há apenas design suficiente aqui para conectá-lo rapidamente e testá-lo. A equipe pode clicar nisso para julgar se navegar para uma tela separada para registrar dados é aceitável ou não. Se funcionar, eles podem adicionar mais estilo posteriormente. Se não funcionar, eles não perderam muito tempo implementando um design perfeito em pixels.
Alinhamento bonito, cores e tipografia não importam na primeira tentativa. O estilo visual é importante no produto final, não nas etapas iniciais. As maiores incertezas são se funcionará, se fará sentido e quão difícil será implementar. Depois que os elementos estão conectados, eles podem ser rearranjados, restilizados e repintados para melhorar o trabalho já feito. Primeiro faça funcionar, depois faça ficar bonito.
Programe o Suficiente para o Próximo Passo
O mesmo é verdade para o trabalho de back-end. Não precisa ser tudo ou nada. Às vezes, um designer só precisa de uma estrutura básica — alguns campos que salvam dados ou algum código para navegar de uma tela esboçada para outra. Outras vezes, ela precisa preencher uma variável no template com uma coleção de dados reais para poder iterar em diferentes exibições (linhas, colunas, caixas de mídia, etc) e encontrar o melhor design.
O trabalho inicial de back-end pode ser estrategicamente fragmentado. Pode haver um controller para renderizar templates, mas sem model. Ou um controller e partes de um model com dados fictícios, mas sem suporte para criar ou atualizar os dados. Telas que ainda não estão conectadas podem pelo menos ser ligadas com rotas para navegação entre elas.
Quando chegou a hora de testar a primeira parte do aplicativo de entrevistas, a equipe sabia que haveria dados sensíveis de entrevistas reais entrando nele. Eles precisavam proteger isso com algum tipo de autenticação. Em vez de construir um suporte completo de nome de usuário e senha — ou até mesmo integrar uma solução de terceiros — eles simplesmente usaram HTTPAuth básico para codificar uma senha.
Isso permitiu que a equipe tentasse adicionar dados de entrevistas reais muito cedo no ciclo, sem perder tempo conectando um código de autenticação que não iria ensiná-los nada sobre os problemas que estavam tentando resolver.
O objetivo é criar uma interação entre design e programação na mesma parte do produto. Em vez de uma grande entrega, alternem-se adicionando funcionalidades, código e estilo visual. Passo a passo, cliquem na funcionalidade real em progresso para avaliar como está indo e o que fazer em seguida.
Comece Pelo Centro
Nos exemplos acima, a equipe não construiu o login primeiro. Eles não criaram uma maneira de criar um projeto de entrevista e um sujeito de entrevista antes de resolver o problema de adicionar dados da entrevista. Eles pularam direto para o centro, onde estava o problema interessante, e esboçaram todo o resto para chegar lá.
Para expandir isso, aqui estão três critérios a considerar ao escolher o que construir primeiro:
Primeiro, deve ser essencial. A alternância de visibilidade era essencial para o conceito de Clientes em Projetos. Sem ela, o outro trabalho não significaria nada. Em contraste com um aspecto mais periférico do projeto, como a capacidade de renomear um cliente. Ambos eram "necessários", mas um era mais central e importante para provar cedo no ciclo. No aplicativo de entrevista, registrar dados de entrevista era mais essencial — mais no centro — do que configurar um novo projeto de pesquisa.
Segundo, deve ser pequeno. Se a primeira parte do trabalho não for pequena o suficiente, não há muito benefício em separá-la do resto. O ponto é terminar algo significativo em poucos dias e ganhar tração — ter algo real para clicar que mostre que a equipe está no caminho certo.
Terceiro, deve ser novo. Se duas partes do projeto forem essenciais e pequenas, prefira a coisa que você nunca fez antes. No recurso de Clientes em Projetos, a interface para adicionar clientes era basicamente a mesma que a interface para adicionar usuários regulares. Começar com isso teria avançado o projeto, mas não teria ensinado nada à equipe. Não teria eliminado a incerteza. Começar com a alternância de visibilidade aumentou a confiança de todos porque provou que uma nova ideia funcionaria.