Concrete Logo
Hamburger button

4 dicas para designers realmente pensarem produto

  • Blog
  • 8 de Fevereiro de 2018

Lá nos idos de 2007 (sim, sou velho…rs), eu trabalhava em uma multinacional como designer, e quando surgia um projeto a gente vivenciava toda aquela saga 100% waterfall. Apenas o líder do projeto ia ao cliente para levantar a demanda, depois passava para os analistas de requisitos/negócios, eu via as especificações, depois eu criava a tela (e codava o front), passava para o time de desenvolvimento e depois ia para o tester (hoje QA). Teste e protótipo antes de tudo para refinar e validar ideias não existia… quiçá um wireframe. Eu já tinha visto wireframes em agências mas não nesse mundo de TI.

Em um projeto para o Ministério do Trabalho, pegamos um sistema de Seguro Desemprego para pescadores artesanais, algo bem específico quando não se pode pescar por motivos de reprodução da fauna marinha, e que envolve diversas cidades desde o interior do Acre até o sul do Brasil. Chegou para mim uma demanda de criação de 200 telas web que antes eram em mainframe (aqueles computadores grandes que piscam e aparecem nos filmes dos anos 60). Sim amigo, 200 telas! Prazo curto. Eu juro que tentei ler as mil páginas das especificações, mas preferi pular etapa e olhar a tela do mainframe e criar logo a versão web.

Ao pegar uma tela de cadastro, notei que o campo de CEP vinha depois do Logradouro, número e bairro. Ora, vamos colocar o campo de CEP em primeiro e o sistema preenche o resto todo sozinho: usabilidade agradece, ganho tempo, usuário fica feliz e job feito! ERRADO!

Dica 1: por mais que ler seja um saco, a documentação pode conter dados relevantes que certamente te ajudarão a evitar um retrabalho.

Isso vale para meus comments no Invision que sei que muitos Devs não olham 🙂

Por que eu estava errado? Eu apresentei a tela ao analista de negócios e ele quase me bateu! Mentira, a Lili não bateria em ninguém. Lili era uma pessoa ótima que estava há muitos anos no projeto Seguro Desemprego. Ela disse pra mim: “Xavier, não podemos trocar o campo de lugar.” Eu perguntei a ela qual seria o problema pois não tinha lógica em manter uma ordem nada prática. E ela disse o seguinte:

“Imagina se trocássemos o campo. O operador do sistema, além de ter que se adaptar a web, terá uma carga de aprendizagem alta para se acostumar com a troca da ordem do campo. Hoje ele faz o preenchimento no modo automático usando o TAB do teclado para pular os campos. Nem olha o monitor. E ele faz em média umas 40 a 60 requisições por dia.”

Daí eu pensei: Putz, UX ali na veia, contexto de uso, cenários, tempo da tarefa… é brabo o designer não poder acompanhar o líder do projeto e ir a campo ver o usuário final e como ele interage com o produto.

Dica 2: Vá a campo sempre! Observe, observe e observe. Anote. Pergunte. Entreviste. Sinta na pele o que o usuário passa, principalmente vivencie o problema dele.

Para minha tristeza (ou não), a Lili continuou…

“Agora imagina o operador lá no interior do Acre, com um PC antigo, mal conecta uma internet discada e salva os registros em disquete, vai começar a ter problema na troca do campo e vai perder o ritmo, logo, os pedidos do seguro vão cair. O povo vai reclamar, vai cair na ouvidoria do Ministério do Trabalho, vão abrir chamado para nós, vai entupir nosso atendimento, a gente vai ter que deslocar alguém para dar treinamento presencial, vai gerar custo para a empresa… então a minha recomendação é mexer o mínimo possível para não ter impacto.”

Na hora eu fiquei meio WTF, mas pensando melhor nos cenários de uso e até mesmo num MVP, há um organismo vivo além da tela do sistema e do seu operador. A Lili tinha razão. Como uma simples mudança de usabilidade poderia gerar um impacto no produto e tudo a sua volta. Era um projeto crítico e todo risco tinha que ser avaliado.

Daí em diante, por mais que eu não lesse as mil páginas da especificação, aprendi a filtrar o que era importante nos documentos para executar a minha tarefa. Eu sempre trocava ideia com a Lili sobre como o usuário era acostumado a operar tal interface e validava possíveis mudanças e seus impactos.

Dica 3: levante da cadeira e troque ideias com todos os envolvidos no projeto. Seja curioso. Questione.

Não precisa saber Oracle, mas entenda o fluxo da informação, de onde ela vem, como será exibida, como será usada e qual o seu objetivo final. Avalie todos os fluxos (QA pode lhe ajudar muito nisso) da jornada do usuário e seus pontos de contato.

Depois desse aprendizado, começamos a adotar wireframes nos projetos seguintes para validar cenários com TODO o time. Isso nos ajudou muito a mitigar problemas e criar saídas para conflitos de negócios e impedimentos técnicos.

Eu ainda fiquei por mais 5 anos naquela empresa. Eu me enfiava ainda mais nos projetos a fim de entender de ponta a ponta. Convenci os gerentes a participar do quick-off dos projetos e validar as entregas parciais com o cliente. Envolvi os devs no processo de pré-desenho das interfaces, os analistas de requisitos trocavam ideias comigo antes de escrever as especificações e eu acompanhava os casos de testes. E por minha sorte, trabalhei com duas QAs que eram cricris demais (obrigado Gisela e Thais) e que me relembravam do usuário final quando eu voava muito alto.

Dica 4: torne-se o melhor amigo do PO e do QA.

Almoce junto, vá comer uma nuvem de queijo com ele(a), né Andressa 🙂 Vocês três juntos podem enxergar melhor os requisitos, ver o real problema a ser resolvido, mapear cenários, descobrir o produto de fato, a fim dele ser elaborado de forma objetiva.

Demorou, mas eu começava a entender de fato na prática que design era aquela teoria que aprendi na faculdade. Design não funciona sozinho. Design é projeto. Projeto tem fases (ou releases ou sprints) e design está ali no meio de todas elas. É algo cross, bem horizontal, que deve ser envolvido desde o início até o fim… e também depois dele. E claro, deve estar presente na cultura das empresas que prestam algum tipo de serviço ou entregam algum tipo de produto, seja para a uma pessoa apenas ou para milhões de usuários.

E aí, concorda, discorda ou tem algo a acrescentar? Aproveite os campos abaixo! Até a próxima.

Quer trabalhar de fato em um time de design que pensa produto? Clique aqui!