Princípios da Modelagem

Nível de abstração

Quando modelamos o trabalho, precisamos fazê-lo no nível certo de abstração: nem muito vago e nem muito concreto. Os gerentes de produto frequentemente erram em um desses dois extremos.

Wireframes São Muito Concretos

Quando líderes de design vão direto para wireframes ou mockups de alta fidelidade, eles definem muitos detalhes muito cedo. Isso não deixa espaço para a criatividade dos designers. Um amigo colocou desta forma:

Eu dou um wireframe para meu designer e então digo a ele: "Eu sei que você está olhando para isso, mas não é isso que eu quero que você desenhe. Quero que você repense!" É difícil fazer isso quando você está entregando algo tão concreto.

Especificar demais o design também leva a erros de estimativa. Por mais contraintuitivo que pareça, quanto mais específico o trabalho, mais difícil pode ser estimar. Isso porque fazer a interface exatamente como deve ser pode requerer a resolução de complexidades ocultas e detalhes de implementação que não estavam visíveis no mockup. Quando o escopo não é variável, a equipe não pode reconsiderar uma decisão de design que está custando mais do que vale.

Palavras São Muito Abstratas

No outro extremo do espectro, projetos muito vagos também não funcionam. Quando um projeto é definido em poucas palavras, ninguém sabe o que isso significa. "Construir uma visualização de calendário" ou "adicionar notificações em grupo" parecem sensatos, mas o que exatamente eles envolvem? Os membros da equipe não têm informação suficiente para tomar decisões. Eles não sabem o que incluir ou deixar de fora. Um programador que trabalhou nessa situação disse:

Você está resolvendo um problema sem contexto. Você tem que ser um leitor de mentes. É como: "saberemos quando virmos."

Quanto à estimativa, projetos pouco especificados naturalmente fogem de controle porque não há um limite para definir o que está fora do escopo.

Estudo de Caso: O Calendário de Grade Pontilhada

Vamos olhar para um exemplo de como estruturar um projeto com o nível certo de detalhes.

Lançamos a versão três do Basecamp sem um recurso de calendário. Ele tinha um recurso de "agenda" que apenas listava eventos um após o outro, sem qualquer tipo de grade mensal, semanal ou diária.

Logo após o lançamento, os clientes começaram a nos pedir para "adicionar um calendário" ao Basecamp. Nós já havíamos construído calendários antes e sabíamos o quão complexos eles são. Pode facilmente levar seis meses ou mais para construir um calendário adequado.

Estes são os tipos de coisas que tornam um calendário complicado:

Versões anteriores do Basecamp tinham calendários, e apenas cerca de 10% dos clientes os usavam. É por isso que não tínhamos o apetite de gastar seis meses em um calendário. Por outro lado, se pudéssemos fazer algo para satisfazer aqueles clientes que nos escreviam em um ciclo de seis semanas, estávamos abertos a isso.

Com apenas seis semanas para trabalhar, só poderíamos construir cerca de um décimo do que as pessoas imaginam quando dizem "calendário". A questão se tornou: qual décimo?

Fizemos algumas pesquisas (discutidas no próximo capítulo) e reduzimos um caso de uso que queríamos resolver. Eventualmente chegamos a um conceito promissor inspirado nos calendários dos telefones. Poderíamos construir uma visualização de grade de dois apenas para leitura, sem edição. Qualquer dia com um evento teria um ponto para cada evento. Uma lista de eventos apareceria abaixo do calendário, e clicar em um dia com um ponto faria os eventos desse dia aparecerem na visualização. Nós chamamos isso de Dot Grid, ou grade de pontos.

O Dot Grid não era um calendário completo. Não íamos permitir arrastar eventos entre dias. Não íamos abranger eventos de vários dias pela grade; apenas repetiríamos os pontos. Não haveria codificação de cores ou categorias para eventos. Estávamos confortáveis com todas as nossas escolhas por causa do nosso entendimento do caso de uso.

Este é o nível de fidelidade que usamos para definir a solução:

dot-grid-calendar.png

Observe como o esboço é rudimentar e quantos detalhes foram omitidos. O designer teve bastante espaço para interpretar como isso deveria parecer e funcionar.

Ao mesmo tempo, observe quão específica é a ideia. É muito claro como funciona, o que precisa ser construído, o que está incluído e o que está fora.

Ao final do projeto, o trabalho concluído que os designers e programadores criaram ficou assim:

dot-grid-calendar-ui.png

Este pequeno exemplo destaca algumas características do trabalho modelado.

Propriedade 1: É grosseiro

O trabalho na fase de estruturação é grosseiro. Todos podem perceber, apenas olhando, que está inacabado. Eles podem ver os espaços abertos onde suas contribuições se encaixarão. Um trabalho muito detalhado e prematuro compromete todo mundo com os detalhes errados. Designers e programadores precisam de espaço para aplicar seu próprio julgamento e expertise quando arregaçam as mangas e descobrem todas as verdadeiras decisões que surgem.

Propriedade 2: Está resolvido

Apesar de ser cru e inacabado, o trabalho estruturado foi bem pensado. Todos os principais elementos da solução estão lá no nível macro e estão conectados entre si. O trabalho não é especificado no nível de tarefas individuais, mas a solução geral está claramente delineada. Embora surpresas ainda possam ocorrer e icebergs ainda possam emergir, há uma direção clara mostrando o que fazer. Qualquer pergunta aberta ou armadilhas que poderíamos ver de antemão foram removidas para reduzir o risco do projeto.

Propriedade 3: É delimitado

Por fim, o trabalho estruturado indica o que não fazer. Ele diz à equipe onde parar. Há um apetite específico — a quantidade de tempo que a equipe pode gastar no projeto. Completar o projeto dentro desse tempo fixo requer limitar o escopo e deixar coisas específicas de fora.

Juntando tudo, a falta de acabamento deixa espaço para a equipe resolver todos os detalhes, enquanto a solução e os limites atuam como guardas-corpos. Eles reduzem o risco e canalizam os esforços da equipe, garantindo que eles não construam demais, se percam em divagações ou fiquem presos.

Quem Modela

Modelar (Shaping) é um processo criativo e integrador. Isso envolve combinar ideias de interface com possibilidades técnicas e prioridades de negócios. Para isso, você precisará incorporar essas habilidades como um generalista ou colaborar com uma ou duas outras pessoas.

Modelar é principalmente trabalho de design. O conceito modelado é um design de interação visto da perspectiva do usuário. Ele define o que a funcionalidade faz, como funciona e onde se encaixa nos fluxos existentes.

Você não precisa ser um programador para modelar, mas precisa ser alfabetizado tecnicamente. Você deve ser capaz de julgar o que é possível, o que é fácil e o que é difícil. Conhecer como o sistema funciona ajudará você a ver oportunidades ou obstáculos para implementar sua ideia.

Também é um trabalho estratégico. Definir o apetite e criar uma solução requer que você seja crítico em relação ao problema. O que estamos tentando resolver? Por que isso é importante? O que conta como sucesso? Quais clientes são afetados? Qual é o custo de fazer isso em vez de outra coisa?

Modelar é um processo criativo de portas fechadas. Você pode estar sozinho rabiscando em papel ou na frente de um quadro branco com um colaborador próximo. Haverá diagramas rústicos à sua frente que ninguém fora da sala conseguiria interpretar. Trabalhando com um colaborador, vocês se movem rápido, falam francamente e saltam de uma ideia promissora para outra. É esse tipo de trabalho inicial, privado, rudimentar.

Dois Caminhos

Você não pode realmente agendar o trabalho de modelagem porque, por sua própria natureza, o trabalho não modelado é arriscado e desconhecido. Por essa razão, temos duas trilhas separadas: uma para modelagem e outra para construção. Durante qualquer ciclo de seis semanas, as equipes estão construindo trabalhos que foram previamente modelados e os modeladores estão trabalhando no que as equipes poderão potencialmente construir em um ciclo futuro. O trabalho na trilha de modelagem é mantido em sigilo e não é compartilhado com a equipe mais ampla até que o compromisso de apostar nele seja feito. Isso dá aos modeladores a opção de colocar o trabalho em andamento na prateleira ou abandoná-lo quando não está dando certo.

Passos para Modelar

Modelar tem quatro etapas principais que vamos abordar nos próximos quatro capítulos.

  1. Definir os limites. Primeiro, descobrimos quanto tempo a ideia inicial vale e como definir o problema. Isso nos dá os limites básicos para modelar.
  2. Esboçar os elementos. Em seguida, vem o trabalho criativo de esboçar uma solução. Fazemos isso em um nível mais alto de abstração do que wireframes para mover rapidamente e explorar uma gama ampla de possibilidades. O resultado dessa etapa é uma ideia que resolve o problema dentro do apetite, mas sem todos os detalhes minuciosos trabalhados e resolvidos.
  3. Abordar riscos e armadilhas. Uma vez que achamos que temos uma solução, damos uma boa olhada nela para encontrar falhas ou perguntas sem resposta que podem atrapalhar a equipe. Emendamos a solução, cortamos coisas ou especificamos detalhes em pontos complicados para evitar que a equipe fique presa ou perca tempo.
  4. Escrever o Pitch. Quando achamos que modelamos o suficiente para potencialmente apostar, embalamos com uma redação formal chamada pitch (proposta). O pitch resume o problema, as restrições, a solução, as armadilhas e as limitações. O pitch vai para a mesa de apostas para consideração. Se o projeto for escolhido, este documento pode ser reutilizado no início do ciclo para explicar o projeto à equipe.