Os projetos Hashrocket começam em grande estilo: o cliente vem à cidade (ou ocasionalmente vamos até ele), todos nós nos sentamos em uma grande sala e fazemos wireframes e escrevemos cartões de história por até 3 dias sólidos. Mas nem sempre foi assim.
The 5-day Slog
Nos primeiros dias de Hashrocket, wireframing e story carding aconteciam em sessões independentes. Quando as sessões foram finalmente combinadas em uma sessão híbrida – algo que eu pessoalmente empurrei em meus primeiros projetos aqui, já que não conseguia imaginar não ser capaz de me comunicar visualmente com o cliente ao discutir a funcionalidade – as reuniões eram monstros, geralmente durando 4 5 dias.
Como você pode imaginar, após o terceiro dia ou mais, os níveis de energia caíram, o esgotamento começou e – o mais importante – nos encontraríamos mergulhando em recursos que estavam muito distantes: aprendemos desde então que, inevitavelmente, os requisitos e os recursos mudarão e amadurecerão, tornando os cartões de história definidos de 2 a 3 meses no futuro completamente obsoletos quando forem necessários.
Então, aqui está o que fazemos hoje em dia: nossa equipe (designer, desenvolvedores, gerente de projeto) e sua equipe, 3 dias, uma sala, procurando fazer o hash do MVP (produto mínimo viável) do aplicativo do cliente. Temos uma grande TV conectada a um Mac Mini, com metade da tela mostrando a janela VIM do gerente de projeto enquanto ele escreve cartões de história, e a outra metade mostrando nossa ferramenta de wireframe de escolha, Balsamiq , instável, mas adorável .
1. Interações de wireframe, não layout.
A primeira coisa que digo ao cliente quando chegamos ao ponto de realmente iniciar o Balsamiq e construir nosso primeiro wireframe (geralmente na metade do primeiro dia) é que o Balsamiq é deliberadamente feio . Seriamente. O tipo de letra é algo apenas Balsamiq bastardizado que substituiu Comic Sans / Chalkboard nas versões anteriores.
Não tenho ideia se a equipe Balsamiq pretende que tratemos a “feiura” como uma característica da maneira como o tratamos, mas: com todas as suas falhas de design, adoro que Balsamiq seja feio e lo-fi. Isso me ajuda (e ao cliente) a focar no que os wireframes estão representando do ponto de vista da funcionalidade e não entrar em discussões sobre se o nav deve estar à esquerda ou no topo, ou se o título deve ser centralizado, ou se deveria haver a … essa é a ideia. Estamos em uma sessão de cardagem de história para aprimorar o que seu aplicativo faz – não queremos sair por uma tangente visual sobre como isso deve parecer .
Essa regra não é imutável – às vezes, conversas de design visual são absolutamente necessárias no carding de histórias. E às vezes é difícil para mim apenas criar um wireframe para uma tabela simples quando meu senso de designer sabe que a solução final será muito mais interessante do que isso. Mas o papel do designer no carding da história é ajudar com o conceito, o fluxo e as interações do aplicativo, e permanecer focado nisso é o que ajuda a manter a sessão nos trilhos.
2. Apenas wireframe o que existe
Veja como não começar um wireframe: logotipo, elemento de navegação e perguntando ao cliente “ok, quais são os itens que entram na navegação aqui?” – porque o nav deve estar vazio no início do dia: ele está lá para oferecer suporte à navegação entre recursos e esses recursos ainda não existem.
Sempre fazemos wireframes da perspectiva de um conjunto de recursos e deixamos que ditem a estrutura externa do aplicativo. Por exemplo, em um aplicativo que permite o gerenciamento simples de clientes e empresas, percorreremos os wireframes para listar, criar e visualizar uma empresa primeiro, momento em que adicionarei um item à navegação: “Empresas”. E então faremos o mesmo para os clientes e adicionarei isso – ou talvez não, porque talvez os clientes pertençam a empresas, nesse caso adicionaremos um subnav à página de uma empresa e partiremos daí. Veja o que quero dizer? Os recursos ditam a estrutura. E se precisarmos criar um wireframe para um painel, ou página inicial, ou outra página que dependa de outro conteúdo, faremos o wireframe por último.
Isso faz sentido o suficiente para o design, mas é absolutamente essencial para o carding de histórias, pois tentamos escrever histórias na ordem em que precisam ser entregues (por exemplo, os desenvolvedores não podem entregar uma história de “visão do usuário da empresa” até que eles ‘ feito a história do “usuário cria empresa”). Essa abordagem também pode ser um desafio para o design, porque você tem que deixar ir e relaxar sobre a aparência das páginas com mais design (painel, página inicial, etc.) até que você tenha passado pelas páginas de suporte.
Essa abordagem inevitavelmente levará (em Balsamiq, pelo menos) a um monte de inconsistências entre os arquivos: navegação e outros elementos compartilhados em vários estados de conclusão. Contudo:
3. Faça bagunça – você pode arrumar mais tarde.
Cardar histórias com um cliente pode e deve ser um processo confuso, em que conjuntos de recursos são alterados, wireframes são descartados, as conversas voltam para o quadro branco e (isso já aconteceu várias vezes) a equipe permite que uma ideia seja gerida durante a noite e volte na próxima dia com uma mudança fundamental no conceito do aplicativo. Nós rolamos com os golpes – quando algo muda o nav, por exemplo, o wireframe atual é ajustado e nós atualizamos o resto depois, após o término da sessão.
Olha, a última coisa que eu, como designer, quero é 8 pares de olhos olhando para mim enquanto eu mexo com os últimos 15 arquivos wireframe e me certifico de que tudo está atualizado. Eu ainda sou culpado disso ocasionalmente (me dê uma folga, eu sou um designer e aquele botão estava desalinhado e estava literalmente me matando), mas o nome do jogo no story carding é não deixar o processo atrapalhar da discussão. Assim, os arquivos são descartados, notas adesivas rápidas são jogadas no canto dos wireframes, e quando o cliente não está fisicamente presente na sala, eu volto, arrumo a junta e postarei um conjunto profissional e organizado de wireframes no Basecamp.
Agora vá em frente!
Lo-fi agora, high-fi depois! Depois que a cardagem da história está completa, podemos cavar esses wireframes feios e simplistas e trabalhar em maquetes reais, e é sempre incrível. Os wireframes fizeram seu trabalho – eles forneceram uma representação visual de todas aquelas longas conversas de recursos – e quando o cliente vir as composições reais, as únicas surpresas serão as boas (é tão bonito agora!) Em vez das ruins (o que é este botão está fazendo aqui?) e o projeto terá dado os primeiros passos para o sucesso.
(postado originalmente no The Hashrocket Blog )