Desenvolvimento

20 fev, 2018

4 dicas para designers realmente pensarem produtos

Publicidade

Lá nos idos de 2007 (sim, sou velho), 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, 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 a etapa, 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 primeiro e o sistema preenche o resto todo sozinho: usabilidade agradece, ganho tempo, usuário fica feliz e job feito, certo? 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 uma média de 40 a 60 requisições por dia.”

Daí eu pensei: “Putz, UX ali na veia, contexto de uso, cenários, tempo da tarefa. É duro 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 a 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 e 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 confuso, 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 de 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 conversava 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 mais 5 anos naquela empresa. Eu me enfiava ainda mais nos projetos a fim de entender de ponta a ponta. Convenci os gerentes a participarem 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 pra minha sorte, trabalhei com duas QAs que eram exigentes de mais (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.

***

Este artigo foi publicado originalmente em: https://www.concrete.com.br/2018/02/08/quando-ux-versus-pensar-em-produto-bateram-na-minha-porta/