Encontrando os Elementos
Agora que temos as restrições de um apetite e o problema que estamos resolvendo, é hora de passar de uma ideia em palavras para os elementos de uma solução de software. Podem existir dezenas de maneiras diferentes de abordar a solução para um problema. Portanto, é importante que possamos nos mover rapidamente e explorar muitas ideias diferentes sem sermos arrastados.
Mova-se na Velocidade Certa
Duas coisas nos permitem avançar na velocidade certa nesta etapa.
Primeiro, precisamos ter as pessoas certas — ou ninguém — na sala. Ou estamos trabalhando sozinhos ou com um parceiro de confiança que possa acompanhar nosso ritmo. Alguém com quem possamos conversar de maneira abreviada, que tenha o mesmo conhecimento prévio, e com quem possamos ser francos enquanto pulamos entre as ideias.
Segundo, precisamos evitar o nível errado de detalhe nos desenhos e esboços. Se começarmos com wireframes ou layouts visuais específicos, ficaremos presos em detalhes desnecessários e não conseguiremos explorar tão amplamente quanto precisamos.
O desafio aqui é ser concreto o suficiente para fazer progresso em uma solução específica sem se perder nos detalhes minuciosos. As perguntas que estamos tentando responder são:
- Onde a nova funcionalidade se encaixa no sistema atual?
- Como você chega até ela?
- Quais são os componentes ou interações chave?
- Para onde isso te leva?
Para manter o nível certo de detalhe e capturar nossas ideias conforme elas surgem, trabalhamos à mão usando algumas técnicas de prototipagem: breadboarding e esboços com marcador grosso. Isso nos permite desenhar rapidamente diferentes versões de fluxos inteiros para debater os prós e contras de cada abordagem e nos manter alinhados com o que estamos discutindo enquanto avançamos.
Desenhando em Breadboards
Pegamos emprestado um conceito da engenharia elétrica para nos ajudar a projetar no nível certo de abstração. Uma breadboard é um protótipo de engenharia elétrica que tem todos os componentes e fiações de um dispositivo real, mas sem o design industrial.
Decidir incluir uma luz indicadora e um botão rotativo é muito diferente de debater o material do chassi, se o botão deve ficar à esquerda ou à direita da luz, quão afiadas as bordas devem ser, e assim por diante.
Da mesma forma, podemos esboçar e discutir os componentes chave e as conexões de uma ideia de interface sem especificar um design visual particular. Para fazer isso, podemos usar uma abreviação simples. Há três coisas básicas que vamos desenhar:
- Lugares: Estes são elementos para os quais você pode navegar, como telas, diálogos ou menus que surgem.
- Disponibilidades: Estes são elementos com os quais o usuário pode interagir, como botões e campos. Consideramos também o texto da interface como uma disponibilidade. Ler o texto é uma ação que fornece informações ao usuário para ações subsequentes.
- Linhas de conexão: Estas mostram como as disponibilidades levam o usuário de um lugar a outro.
Usaremos palavras para tudo, em vez de imagens. O importante são os componentes que estamos identificando e suas conexões. Eles nos permitem explorar uma ideia e julgar se a sequência de ações atende ao caso de uso que estamos tentando resolver.
Exemplo
Suponha que nosso produto seja uma ferramenta de faturamento. Estamos considerando adicionar um novo recurso de “Pagamento Automático” para permitir que os clientes dos nossos clientes paguem futuras faturas automaticamente.
Como ativar o Pagamento Automático? O que está envolvido? Podemos escolher um ponto de partida e dizer que o cliente acessou uma fatura. Esse é nosso primeiro lugar. Desenhamos isso escrevendo o nome do lugar e sublinhando-o.
Na fatura, estamos pensando em adicionar um novo botão para 'Ativar Pagamento Automático'. Isso é uma disponibilidade. As disponibilidades vão abaixo da linha para indicar que podem ser encontradas nesse lugar.
Onde esse botão vai levar? Algum lugar para configurar o Pagamento Automático. Não precisamos especificar se é uma tela separada ou um modal pop-up ou o que seja. Do ponto de vista de como as coisas estão conectadas (a topologia), é tudo a mesma coisa. Vamos desenhar uma linha de conexão do botão para a tela de Configuração do Pagamento Automático.
Agora podemos discutir o que deve estar nessa tela. Pedimos um cartão de crédito aqui? Já existe um cartão cadastrado? E quanto ao débito automático ou outros métodos de pagamento?
Só de tentar descobrir o que escrever sob a linha já começamos a provocar debates e discussões sobre o que construir.
Enquanto pensamos nisso, decidimos que devemos pedir os detalhes do cartão de crédito aqui e mostrar o logotipo da instituição financeira (um aspecto do domínio neste produto específico).
Simples o suficiente. Mas espere — nós realmente pagamos a fatura original ou não? Hm. Agora temos tanto perguntas funcionais quanto de interface. O que a ativação do Pagamento Automático realmente faz? Aplica-se apenas para o futuro ou o pagamento com Pagamento Automático na primeira vez também paga a fatura atual? E onde explicamos esse comportamento? Estamos começando a ter perguntas e discussões mais profundas provocadas por apenas algumas palavras e setas no breadboard.
Como estamos usando uma notação tão leve, e não estamos presos a wireframes, podemos rapidamente experimentar e considerar diferentes possibilidades.
Poderíamos adicionar uma opção na tela de Configuração…
Mas agora estamos complicando as responsabilidades da tela de confirmação. Precisaremos mostrar um recibo se você pagar seu saldo agora. A confirmação deve ter uma condição para às vezes mostrar um recibo do valor acabado de pagar?
Que tal uma abordagem completamente diferente? Em vez de começar em uma fatura, fazemos do Pagamento Automático uma opção ao fazer um pagamento. Dessa forma, não há ambiguidade sobre se o valor atual está sendo pago. Poderíamos adicionar uma mensagem extra "Pagamento Automático ativado" à página de confirmação de pagamento existente.
Esboçar isso nos lembrou que o formulário de pagamento atual suporta transferência bancária além do cartão de crédito. Discutimos e confirmamos que podemos usar transferências também.
E depois que o Pagamento Automático é ativado? Como o cliente o desativa? Até agora, muitos clientes no sistema não tinham nomes de usuário ou senhas. Eles seguiam links tokenizados para pagar as faturas uma a uma. Pode-se naturalmente supor que, agora que o cliente tem algo como Pagamento Automático, ele precisaria de um nome de usuário e senha e algum lugar para gerenciar isso.
A equipe, neste caso, decidiu que adicionar fluxos de nome de usuário/senha era muito escopo para seu apetite no momento. Refletindo estrategicamente sobre o que sabiam sobre seus clientes, acharam que seria bastante aceitável se os clientes do faturador tivessem que entrar em contato com o faturador e pedir para desativar o Pagamento Automático. Nesse caso, poderíamos adicionar uma única opção para desativar o Pagamento Automático na página de detalhes do cliente que já oferecemos aos faturadores. Desenhamos o fluxo assim:
Este exemplo ilustra o nível de pensamento e a velocidade de movimentação que devemos almejar durante a fase de breadboarding. Escrever os fluxos nos confronta com perguntas que não pensamos originalmente e estimula ideias de design sem nos distrair com escolhas visuais desnecessárias.
Quando chegamos a um ponto onde podemos simular o caso de uso e o fluxo parece adequado, temos os elementos necessários para começar a definir o projeto de forma mais clara. Estamos nos tornando mais concretos enquanto ainda deixamos de lado uma grande quantidade de detalhes.
Esboços com Marcador Grosso
Às vezes, a ideia que temos em mente é visual. Montar um protótipo em uma breadboard não ajudaria, pois a disposição dos elementos em 2D é o problema fundamental. Nesse caso, não queremos perder tempo com wireframes ou com uma fidelidade desnecessária. Em vez disso, usamos esboços com um marcador grosso.
Um esboço com um marcador grosso é feito com traços tão largos que adicionar detalhes é difícil ou impossível. Originalmente, fazíamos isso com marcadores Sharpie de ponta larga no papel. Hoje, também fazemos no iPad com o tamanho da caneta ajustado para um diâmetro grande.
Aqui está um exemplo. Frequentemente, criamos tarefas falsas em nossas listas de tarefas do Basecamp que atuavam como divisores. Criávamos um item como “––– Precisa de teste –––“ e colocávamos itens abaixo dele. Tivemos a ideia de criar algum tipo de função oficial de divisor na nossa ferramenta de listas de tarefas para transformar essa solução improvisada em uma função real das listas de tarefas.
Precisávamos entender quais eram as implicações de adicionar um divisor. Chegamos a uma ideia geral de que adicionar um divisor separa a lista em tarefas "soltas" acima do divisor e tarefas "agrupadas" abaixo.
Adicionar divisores subsequentes adiciona mais grupos abaixo dos itens "soltos" no topo.
Podíamos adicionar itens através de algum recurso dentro de cada grupo, incluindo o grupo "solto" no topo.
Ficamos um pouco preocupados de que os botões de adição pudessem quebrar a unidade da lista e que os grupos pudessem se separar demais das listas na página. Discutimos possibilidades de colocar o recurso de adição dentro de um menu que já tínhamos à esquerda de cada item da lista de tarefas.
Essa notação é muito menos restritiva do que os breaboards, o que tem desvantagens. Podemos esboçar uma barra lateral e nos apegar a um elemento de layout assim, mesmo que não seja um elemento central. Mas, desde que fiquemos atentos a isso, estamos muito melhor do que se nos perdermos nos detalhes criando wireframes muito cedo.
Pode parecer um pouco bobo chamar esboços com marcador grosso de uma técnica ou ferramenta. A razão de chamar atenção para isso é que, facilmente, pulamos para o nível errado de fidelidade. Dar um nome a esse estágio inicial e usar uma ferramenta específica para isso nos ajuda a segmentar nosso próprio processo criativo e garantir que não estamos avançando para detalhar uma ideia específica quando ainda não exploramos o campo o suficiente.
Elementos são o Resultado
No caso do exemplo do Autopay, acabamos com alguns elementos claros:
- Uma nova caixa de seleção “usar isso para Autopay?” na tela existente de “Pagar uma fatura”
- Uma opção “desabilitar Autopay” no lado do emissor da fatura
Para o projeto de Grupos de Tarefas, os elementos foram:
- Tarefas soltas acima do primeiro grupo pertencem diretamente a lista mãe
- Tarefas agrupadas aparecem abaixo das tarefas soltas
- Gostaríamos de tentar um recurso de adição dentro de cada seção, mas se isso não funcionar visualmente, estamos ok em depender do menu de ações para inserir tarefas na posição desejada.
Da mesma forma, quando esboçamos a solução simplificada para renderizar eventos em uma grade de calendário, usamos a abordagem do marcador grosso.
Isso nos permitiu trabalhar os principais elementos da solução:
- Uma grade de calendário mensal em 2 colunas
- Pontos para eventos, sem pílulas estendidas
- Lista de eventos em estilo agenda abaixo, que rola a página para a visualização do evento quando você clica em um dos pontos no calendário
Essa lista de elementos é extremamente específica e estreita em comparação a “calendário mensal.” Exatamente o tipo de foco que esperamos alcançar através do processo de modelagem.
Espaço para Designers
Mais tarde, quando for a hora de envolver um designer, você não quer ter que dizer "Eu sei que desenhei assim, mas ignore isso...". Independentemente do que você disser, qualquer mockup específico vai influenciar o que outras pessoas farão depois — especialmente se você estiver em uma posição hierárquica superior. Elas tomarão cada detalhe dos mockups iniciais como uma direção, mesmo que você não tenha essa intenção.
Trabalhar no “nível certo de abstração” não só garante que avancemos na velocidade adequada, como também deixa espaço importante para a criatividade nas fases posteriores.
Ao deixar detalhes de fora, os métodos de breadboard e esboço com marcador grosso proporcionam espaço para os designers nas fases subsequentes do projeto.
Esta é uma parte importante do processo de modelagem. Estamos tornando o projeto mais específico e concreto, mas ainda deixando muito espaço para decisões e escolhas serem feitas mais tarde. Isso não é uma especificação. É mais como os limites e regras de um jogo. Pode seguir inúmeras direções diferentes quando chegar a hora de jogar.
Sem Entregáveis Ainda
Esta etapa da modelagem ainda está muito na sua esfera privada. É normal que os artefatos neste ponto — na parede ou no seu caderno — sejam mais ou menos indecifráveis para qualquer pessoa que não estava lá com você.
Passamos de uma ideia nebulosa, como “autopay” ou “grupos de tarefas,” para uma abordagem específica e alguns elementos concretos. Mas a forma que temos ainda é muito rudimentar e basicamente um esboço.
O que fizemos foi definir uma abordagem para resolver o problema. Mas pode haver algumas incógnitas significativas ou coisas que precisamos abordar antes de considerarmos seguro entregar isso a uma equipe para construir com sucesso.
O próximo passo é realizar alguns testes de estresse e mitigar riscos. Queremos verificar possíveis falhas e desafios que possam impedir o projeto de ser concluído dentro do tempo fixo que temos em mente.
Depois disso, veremos como consolidar o conceito modelado em um documento para apresentação.
Sem Compromisso Final
Também tenha em mente que, nesta fase, podemos abandonar o projeto. Não apostamos nele. Não fizemos nenhum compromisso ou promessa a respeito. O que fizemos foi agregar valor à ideia bruta, tornando-a mais acionável. Chegamos mais perto de uma boa opção que podemos defender quando for a hora de alocar recursos.