Com as imagens e textos produzidos durante a etapa de criação da atmosfera visual, a dupla Front-end & Designer abre o editor de código e iniciam mais uma etapa do processo de redesign do site da Taller.
Preparando a transição de protagonistas
Até o momento, a maioria das atividades do projeto dependiam das orientações do designer. E esse é o ponto da virada. O protagonismo será dividido com os desenvolvedores.
Em um processo tradicional o designer se mantém isolado, criando telas e pensando interações em seus mínimos detalhes. Isso pode acontecer em ciclos, ou de uma só vez, que geralmente termina com a clássica frase:
“Acabei! Vou te mandar por e-mail as interfaces, as imagens recortadas e as especificações das telas. Mando junto o .psd para vocês consultarem.”
Há relatos de designers que ainda enviam interfaces como imagem dentro do Word. Socorro!
No processo de redesign do nosso site a etapa de construção passa por um momento de trabalho paralelo, que é uma preparação para o front-end developer assumir o manche do projeto.
Falamos sobre a Matriz de Conteúdo nos episódios anteriores. Agora é a hora de usá-la pra valer. Com ela o front já pode começar a criar o protótipo vivo do novo site.
Protótipo vivo – It’s alive!
Seguindo a lógica da nossa filosofia de trabalho, (Transição gradual e uma página por vez) decidimos pensar a tela inicial como grandes blocos de conteúdo com mínimo de CSS, por enquanto.
Essas macroestruturas de conteúdo, organizadas e hierarquizadas, são feitas com o intuito de conduzir a leitura dos usuários para os objetivos estabelecidos durante a etapa da arquitetura da informação.
Essa estrutura, ainda em fase embrionária, é útil e já pode ir pro ar (ainda que feia). Inclusive, quanto mais feio um protótipo, melhor. O designer Dan Mall orienta os desenvolvedores do seu time a prototiparem com Comic Sans e cores neon. Isso os força a pensarem em cada elemento da interface quando forem dar o acabamento final. Muitas vezes, as bibliotecas de estilo prontas – como o Bootstrap – acabam acomodando os front-ends já que: “tá bonito assim”.
Não fomos tão radicais.
E este é o nosso Protótipo Vivo:
Enquanto isso, no computador ao lado…
Release the Kraken!
Agora o papo é com você, designer.
Se ao longo da jornada você se dedicou para alinhar as expectativas com os gestores, e fez o possível para dar autonomia para os desenvolvedores, chegou tua hora.
Prepare-se, pois:
Está
liberado o
surto
criativoooo-ø-o-\o/-o-º-o!
(Trilha sonora para o momento.)
Abra o moleskine, Sketch, Photoshop, Corel Draw, Paint Brush, ou seja-lá-o-que-você-usa para dar personalidade ao projeto.
Tire alguns dias para ficar imerso na atomosfera visual criada na etapa anterior. Permita-se ousar. Você merece. Seu time precisa.
**
Nesse período de exploração aproveitamos para tirar algumas fotos da nossa sede. A ideia era usar imagens próprias e evitar um banco de imagens padrão. Até porque a casa é a nossa cara. Tem o toque de ateliê que prezamos em nosso dia-a-dia.
Fotaller, nosso próprio banco de imagens:
http://tallerws.tumblr.com
Revisitamos nossa dinâmica inicial para montarmos painéis (dentro do Sketch) com as melhores referências que nos inspiram.
No embalo, deu até pra refinar o ícone da nossa marca gráfica.
Depois de alguns esboços, chegamos em uma Composição de Referência que contemplava os principais objetivos que buscávamos atingir:
Look & Feel: sim! Pixel Perfect: não!
Nesse período de piração é comum o designer ficar abatido, afinal, ao compararmos o nosso trabalho em andamento com cases super detalhados que encontramos no Dribbble rola aquele choque de realidade. Bate até uma deprê.
A alta expectativa no acabamento das formas, fomentada pela cultura do pixel perfect, somada à necessidade de pensar na adaptação para os diversos tamanhos de tela gera um cansaço mental capaz de desgastar o relacionamento entre as pessoas do time. E é aí que está o pulo do gato do Lean Redesign: não precisamos criar interfaces perfeitas. O importante agora é encontrar consistência visual alinhada com o propósito da empresa.
Alguns chamam esse processo de Look & Feel. Demos o nome Composição de Referência.
“E as milhares de dúvidas que surgirão na hora da implementação?”
Essas serão decididas em conversas e atividades de pareamento (pair designing ou pair programming).
Resolver problemas em pares reforça o laço de cooperação entre designers e desenvolvedores, além de nivelar o conhecimento técnico da dupla e ampliar o entendimento das limitações e possibilidades de execução.
**
A ideia ganhou corpo. Estávamos próximos de concluir o trabalho. Faltava juntar a estrutura que o front montou com a composição que o designer sugeriu.
Até que,
aconteceu o que temíamos:
Um projeto com prioridade máxima surgiu no meio do caminho. E era dos grandes. Precisaria de todos os devs da equipe.
Corríamos o risco de deixar todo o processo na geladeira por tempo indeterminado.
Mas não isso não poderia acontecer!
Diante de tal cenário só nos restou usar o nosso recurso especial:
o chamado para uma força-tarefa coletiva.
O Hackataller!
Este será o tema do próximo episódio.
Até breve!