Sobre Menus (gigantes), relevância e usabilidade

Escrito por Ivan Henrique Tavares Pauletti


Aviso: Este é um post escrito originalmente em 2014 para o blog interno dos desenvolvedores da então Direct Talk (hoje DT+Seekr) e foi repostado agora em 2017 para efeitos "históricos". =)


Uma das coisas que me fazem ser apaixonado por interfaces é, mais do o apelo visual e criatividade, a dificuldade de resolver alguns desafios de maneira correta.

Pense nos desafios de uma equipe que teve que criar o primeiro mouse, a primeira tela touchscreen. Pense nos desafios que temos que enfrentar, como um exemplo que gosto bastante de pensar: “O que falta para leitores de ebooks serem 100% melhores do que um livro de papel?”.

Na minha opinião é o fator “folhear” é um deles. A ocasionalidade de abrir em uma página qualquer e se lembrar do ocorrido ou ir saltando rapidamente de 10 em 10 páginas para se fazer lembrar de onde parou. Se você fechar um livro e desligar um Kindle, sem marcação de páginas e precisar voltar onde parou, o livro físico vai tornar sua tarefa mais rápida. Esse é um desafio interessantissimo de pensar.

“Bom, estamos em uma empresa que faz soluções para atendimento, é mais entediante e não temos desafios divertidos assim”.

Eu lhe digo “the hell we don’t have”! E que desafios.

Estou há algumas semanas trabalhando no menu do nosso querido supervisor basicamente em todas as partes dele: no visual, refatorando a lógica javascript que monta o menu na tela, ajudando a definir o objeto que o backend irá fornecer e participando de regras sobre permissões e customizações de clientes. Com base nesse longo trabalho gostaria de descompromissadamente compartilhar alguns pensamentos sobre boas práticas em comportamentos de menus baseado em tendências e ir além e tecer minha própria sugestão para algo que há pouquíssimo material de pesquisa: usabilidade em menus XICANTES (nosso caso).

Disclaimer

Para começar e estabelecer expectativas, vamos falar sobre Usabilidade que hoje é uma área nova e partindo disso quero conceituar o termo “nova” em:

  1. Adoção recente do mercado nesse ramo de estudo/trabalho
  2. Relativamente pouco material de consulta
  3. Apesar de necessitar, não é ainda uma ciência exata (muito interpretativa e com base em experimentos)
  4. Às vezes é mal priorizada (justamente por ser nova e desconhecida).

Isso quer dizer que o que vou falar abaixo se baseia em que pouca coisa foi encontrada a respeito de menus grandes (item 1 e 2); muito do que vou dizer é opinativo e interpretado por MIM (item 3); e possivelmente não vão ser feitas por limitações de tempo e tecnologia de forma que é um caminho arriscado investir recursos em algo nessas condições, justo (item 4).

Tá bom, vai direto ao ponto!

Trabalhar com menus basicamente é listar de maneira organizada divisões de uma árvore para otimizar o acesso do usuário em tempo, facilidade de acesso ao item desejado e performance.

Partindo desse conceito vamos tentar aplicar os comportamentos no seguinte sentido: É maravilhoso entrarmos em sites de inspiração de menus e ver coisas enxutas e bonitas como estas:

A maioria das fontes visa organizar os items afim de aumentar a taxa de conversão deles. Basicamente é aumentar o acesso e as quantidade de cliques.

Isso se aplica muito bem no meio de sites comerciais (blogs, lojas virtuais como os exemplos acima) mas quando falamos de aplicação não faz muito sentido querer que todos os items do menu tenham taxas de conversão altas. Por exemplo, organizar o menu para que os relatórios de Visão Geral que são extremamente utilizados tenham uma taxa de conversão tão grande quando a Customização da Aparência do Chat, que só deve ser mexida uma ou outra vez vira um padrão pouquíssimo eficaz.

Sendo assim tentarei aplicar o primeiro conceito genérico da organização de menus: Relevância. Como nosso menu é extremamente grande não vou fazer uma organização global mas vamos pegar uma amostragem de 5 items (um por sessão) e dividi-los pela relevância da seguinte forma.

Bom, vamos deixar essa divisão de lado por enquanto e vamos analisar outro cenário em paralelo:

Utilizando um navegador com um dos menores menus, o Chrome, em uma resolução ligeiramente generosa (1200×850) temos um espaço constantemente visível de 29% da página (menu+rodapé) somente para navegação, e apenas 63% do site para layout.

Lembrando que este é um cenário extremamente otimista. Se o usuário utilizar Internet explorer cuja barra de menus é maior ainda e dispuser de um monitor com menor resolução, o espaço do menu não irá mudar já que é fixo, mas o do conteúdo sim já que é elástico e tenderá a encolher ainda mais.

Pela complexidade e tamanho do nosso menu, temos que dedicar uma parte enorme(!) da área útil do site exclusivamente para navegação. O menu ocupa uma área privilegiada do site (segundo a premissa da usabilidade o primeiro “palmo” de tela é o mais relevante). É como se considerássemos que o usuário passassem mais tempo olhando e trocando de menus do que analisando conteúdo e informações!

Tentando deixar o conteúdo em primeiro plano, mas criando um menu contextual em segundo plano, teríamos algo assim:

Antes de chamar o menu:

Depois:

Com padrão da relevância poderíamos trabalhar com o máximo de 2 planos e relevaríamos o conteúdo com pequenos ajustes. Casos mostram escondendo e mostrando elementos conseguiríamos aumentar a relevância em mais de 100% (via [WWO][2] via [Unbounce][3]).

Vamos voltar agora ao menu. Lembrem-se que peguei uma das páginas de cada sessão e coloquei no termômetro, mas vamos visualizar como é a divisão atual das páginas.

Exatamente um conceito de árvore, onde a opção foi prevalecer as Funcionalidades sobre os produtos (note que produtos se repetem pois são filhos de funcionalidades). Parece ótimo mas pela quantidade de itens é extremamente pesado para o cliente e “labirintoso” para se navegar.

Mas isso tudo é suposição

Sim, por enquanto é. Quando digo que a área é nova realmente é porque TUDO tem que ser testado para ser comprovado e quando digo que é pouco priorizado é que há MUITO POUCO interesse em fazer estes testes! É um paradoxo incrível (risos). É extremamente importante desenvolvermos sugestões a clientes abertos a novidades (talvez uma lista de clientes beta) e fazermos testes A/B e heatmaps para testar essa aceitação.

Vejam este caso do Unbounce. ht que eu recomendo muito a leitura.

Utilizando um objetivo simples, testes a/b com usuários e ferramentas de métricas, conseguiram aumentar em 336%. a conversão e utilização dos usuários.

Há muitos pontos de choque em meus argumentos que não pretendo defender aqui, mas é injustos negá-los sem testá-los. Os pontos de choque principais que encontrei trabalhando em agências, startup e até mesmo trabalhando na faculdade eram:

“Mas nosso cliente é diferente.”

Não não é. Ele tem suas particularidades, mas todo o “Seu cliente” ESTENDE A CLASSE USUÁRIO! Lembre-se disso (por mais nerd que possa parecer).

“Nossos usuários estão acostumados.

Por natureza o ser humano é resistente a mudanças. Facebook, Twitter, Youtube, Microsoft e Apple sempre são extremamente criticados a cada mudança nova, mas todas são baseadas em estudos nos próprios usuários .Não é fácil mas ouvindo feedbacks e sendo corajoso e firme é possível transitar para o foco: o bem do próprio usuário.

“Você não entende nada sobre o nosso mercado.”

Já ouvi isso quando trabalhava em uma startup do meio de resíduos sólidos. Na DT não, inclusive eu preciso aprender! Mas pode parecer arrogante mas com 4 alterações no layout no início de 2013 aumentamos em 25% a acessibilidade do usuário nos relatórios da plataforma (carece de fontes, não tenho mais acesso ao analytics da empresa)*.

“Mas isso tudo é gosto”

Tentei escrever todo o texto até aqui somente falando em conceito e estrutura, sem sequer falar de design. Interface apesar de fazer parte de UX, é discutível, há preferências de cores, tamanhos fontes e debater isso é extremamente improdutivo: é escolher alguém talentoso e fazer, Usabilidade não. Ela precisa de métricas e exaaaatamente ao contrário de Interface, busca ser uma ciência exata.

O que você sugere

Bom, vou tentar sugerir algo baseado no que disse acima, mas agora com uma interpretação minha de layout, tentando ir para um lado mais flat inspirado no Design Material do Google, não se apeguem nisso.

Aqui temos, como planejado um menu acessível somente após uma interação o deixando em segundo plano. Em contrapartida temos muito mais espaço para conteúdo relevante além da limpeza de elementos, dando foco à página atual.

Vejamos como ficaria a área de menu:

Aqui abandonamos a divisão por funcionalidades e focamos nos canais. Colocando o menu em contexto, por mais estranho que isso possa parecer, conseguimos dar mais espaço que antes para ele! Agora temos itens mais espaçados, de forma que a os canais ficam sempre visíveis e a metade direita do menu se atualiza com os menus de cada produto.

Não nos esqueçamos que há nó raiz dos deparatamentos, que agora fica através de um ícone no canto superior direito. A idéia é que a cada departamento o topo roxo adquira uma tonalidade diferente, realçando a individualidade de cada apartamento.

O rodapé colocamos abaixo dentro do menu, unindo as informações da DT com o usuário. É isso. =)

Conclusão?

Posso exemplificar na nossa rotina mesmo. Tivemos uma intervenção chamada “Mega Menu” (que pra mim já é um nome que evoca algo como um Tiranossauro Rex ou Transformer, enfim..) cuja proposta era organizar os items do menu. Mas brincadeiras a parte, mega menu é UM PADRÃO REAL DE UX, maaas não por ironia, se digitarmos o termo no Google recebemos isso. (risos).

Vamos a como adotamos uma solução do mega Menu no supervisor.

Assim.. criando um novo Nó dentro dessa árvore. Ora. Se já temos uma estrutura extremamente complexa, a solução de fato é adicionar uma divisão a mais dessa estrutura? Por mais nobre que seja a mudança ou por mais que o cliente goste disso, isso não resolveria.

Estamos criando uma justificativa pra arrumar um problema maior que nós mesmos criamos. Pense no seguinte: o desktop do seu computador está cheio de pastas, com elementos em sub pastas de forma que é difícil você encontrar algo ali. Quando você acha que o último nivel de uma pasta já está com elementos demais, o que você faz? Cria novas pastas e joga as coisas ali dentro. Voilá,

Quando eu disse que na literatura não há exemplos e nem ajudas com o que fazer com menus extremamente grandes é porque a resposta está logo abaixo dos nossos narizes: NÃO DEVEMOS NUNCA TER MENUS GRANDES.

“Mas esse cara é um babaca, olha a solução que ele dá..” Não meu querido pequeno gafanhoto, é possível sim reduzir a quantidade de items. A melhor delas é condensar informação.

Lembra nosso exemplo? A sugestão foi dar uma área maior ainda pra conteúdo né? Exato! Podemos jogar mais informação ali dentro e matar relatórios simples.

Hoje em dia o supervisor tem páginas que mostram um gráfico simples ou até mesmo tabelas minúsculas de 5 ou 10 linhas. Porque não criar dashboards contextualizados que mostrem essas informações juntas.

Um esforço orgulhoso que entregamos foi remodelar as páginas de Visão Geral. O que fizemos basicamente foi condensar informação nesta tela, possibilitando matar as vezes até duas páginas.

Entenderam o caminho? condensar informação é perigoso se você tem pouco espaço na tela, pode ficar confuso e poluído, mas liberando espaço para uma área branca maior, dá pra condensar informação sem encavalar um monte de coisa.

Bom, essa é minha contribuição para o post, por favor vamos conversar sobre isso! Concordam, discordam, sugestões? Gostaria muito de falar sobre as métricas para medirmos os nossas intervenções nas ferramentas, mas isso vai ficar para outro post…