Redesenhando o sistema de navegação de sete níveis da SGS: um estudo de caso

A SGS (anteriormente Société Générale de Surveillance ) é uma organização global de serviços e fornecedora de serviços de inspeção, verificação, teste e certificação em 14 indústrias. O site da SGS (junto com 60 sites localizados) promove principalmente os principais serviços da organização, além de fornecer acesso a uma variedade de serviços úteis, conteúdo complementar e ferramentas. Nosso objetivo era transformar o sgs.com de ser apenas desktop para responsivo.

Isso apresentou um conjunto único de desafios, especialmente em torno do sistema de navegação legado, que em áreas tinha até sete níveis de profundidade (dividido em duas partes) e que consistia em cerca de 12.000 itens navegáveis ​​individuais .

Leitura adicional no SmashingMag: Link

• Projetando estudos de caso: apresentando um processo de design centrado no ser humano
• Adaptando-se a um design responsivo
• Estudo de caso de unificação de design de produto
• 75 Estudos de Casos Instrutivos – Foi Assim que Construímos

Nossa reação natural ao ver e usar o sistema de navegação da SGS pela primeira vez foi que certamente a arquitetura da informação (IA) teve que ser simplificada devido ao grande volume de links e conteúdo navegáveis. No entanto, considerando que a navegação já havia sido otimizada para mecanismos de busca e IA antes deste projeto e considerando que a SGS oferece uma ampla seleção de serviços em muitos setores (refletidos no volume de conteúdo), ficou evidente que a refatoração do IA não Seja parte da solução.

Simplificando, a estrutura da árvore de navegação tinha que permanecer intacta. Mesmo assim, isso não nos impediu de fazer alguns pequenos ajustes no AI. Por exemplo, “News, Media & Resources” e “SGS Offices & Labs” foram movidos para o nível superior, para maior visibilidade. Com o primeiro, era importante refletir com mais clareza que a SGS publica regularmente notícias e realiza eventos. Com este último, era vital que ele, juntamente com a página de contato, fosse facilmente acessível de qualquer lugar na estrutura do site. Portanto, a questão-chave era como um sistema de navegação tão gigante poderia ser feito para fazer a transição facilmente entre diferentes janelas de visualização enquanto ainda era utilizável?

Estabelecendo Políticas do Projeto

Uma relação cliente-designer saudável é essencial para o sucesso de cada projeto. Definir expectativas claras, bem como fornecer orientação eficaz, garante não apenas que as principais partes interessadas permaneçam focadas, mas também que a confiança se desenvolva entre todas as partes à medida que o projeto avança. Este foi definitivamente o caso deste projeto; a colaboração entre todas as partes e a apreciação mútua dos papéis e conhecimentos de cada um foram verdadeiramente notáveis.

No entanto, para garantir que todas as partes se mantivessem focadas, estabelecemos no kick-off atendendo a uma série de diretrizes e requisitos importantes dentro dos quais também poderíamos exercitar a criatividade (algumas insistimos, outras insistimos pelo cliente):

• Paridade de conteúdo . O conteúdo deve ser acessível em todos os dispositivos e plataformas e, sob nenhuma circunstância, deve ser ocultado em dispositivos móveis.
• Desempenho . O site deve ter um desempenho pelo menos 20% mais rápido do que os sites concorrentes. Isso foi particularmente útil ao decidir quanta informação deveria ir em cada página.
• Acessibilidade . O site deve aderir às diretrizes de acessibilidade WCAG 2.0 nível-AA. Conseguimos atingir esse objetivo, além de um problema de contraste de cores limítrofe, devido à marca da empresa.
• Usabilidade . A equipe interna teve que validar amplamente os conceitos e realizar testes de usabilidade presenciais e remotos.
• Negócios ininterruptos . O redesenho não deve atrapalhar em nada os negócios da empresa. Claramente, a tarefa não era otimizar os serviços da empresa, mas sim otimizar o site, levando em consideração os processos de negócios estabelecidos. Por exemplo, tínhamos a liberdade de otimizar formulários da web, mas a estrutura dos dados no CRM precisava permanecer intacta.

Os três grandes desafios

Com as principais diretrizes estabelecidas e sabendo que o redesenho da navegação não exigiria uma revisão significativa do IA, subdividimos o redesenho em três conjuntos de atividades principais, mas interdependentes:

• Colocação de layout . Isso foi tratado principalmente pela equipe interna, conosco sugerindo melhorias e garantindo que quaisquer decisões não tivessem implicações radicais para outros aspectos do novo design responsivo.
• Interação e usabilidade . Estes foram trabalhados em colaboração com a equipe de design da SGS. As ideias foram trocadas por e-mail e em workshops no local e foram validadas regularmente em relação aos usuários, partes interessadas e aos requisitos gerais do negócio.
• Desempenho . Isso foi tratado exclusivamente por nós, porque era mais um desafio técnico e não exigia nenhuma tomada de decisão estratégica além de tornar o novo site responsivo rápido.

Posicionamento de layout

A navegação é um elemento fundamental do layout da página, independentemente do tamanho ou complexidade do site. Embora um padrão fora da tela possa parecer atraente quando você está lidando com um sistema de navegação de grande escala, lembre-se de que pode haver problemas quando a navegação não estiver visível para o usuário.

A equipe de design da SGS testou inicialmente uma variedade de conceitos, porque eles tinham que não apenas avaliar a interação de navegação, mas também criar o equilíbrio certo com o resto da página e evitar confusão.

Decidindo sobre o conceito

Dada a complexidade do website, era fundamental que a navegação permanecesse sempre visível e informasse o utilizador onde se encontra dentro da estrutura em árvore. Em vez de dividir a navegação em duas partes na interface do usuário, queríamos que o novo sistema de navegação fosse perfeito (do nível superior até os níveis inferiores). Portanto, ele tinha que permitir que o usuário navegasse facilmente para cima e para baixo na árvore de navegação, bem como lateralmente nas seções principais.

Para testar e validar todas essas combinações, desenvolvemos um protótipo para cada um dos oito conceitos iniciais de navegação. Os protótipos confirmaram o que a equipe interna já suspeitava: a opção mais viável em termos de usabilidade, manutenção, experiência cross-screen, desordem visual e apelo era que a navegação fosse colocada na barra lateral em telas grandes e aparecesse como um menu suspenso em telas pequenas. Essencialmente, o módulo de navegação seria funcional e visualmente independente, independentemente do tamanho da tela.

Embora nos concentremos em decisões de interação específicas em um minuto, vale a pena ressaltar que os protótipos interativos não precisam necessariamente ser descartados uma vez que um conceito prototipado tenha sido testado e validado.

Prototipagem Inteligente

Sempre desenvolvemos protótipos diretamente em HTML, CSS e JavaScript usando marcação semântica, acessível e robusta, porque muitas vezes podemos reutilizar os protótipos iniciais posteriormente no processo de design. Isso significou que nosso protótipo inicial para o novo sistema de navegação se tornou a pedra angular para o eventual protótipo de site completo, que incluía todos os modelos de página e módulos.

Ao entregar o protótipo completo, também garantimos que o guia de estilo fosse gerado automaticamente para a equipe da SGS. Ao fazer com que a equipe de design da SGS pensasse em termos de design e desenvolvimento de módulos, em vez de páginas completas, o guia de estilo gerado exigiria pouca manutenção contínua. O próprio guia de estilo refere-se a todos os módulos distintos usados, com cada módulo contendo uma descrição precisa, exemplo de código e link gerado automaticamente para o modelo de página em que é usado. Nossa tecnologia de escolha para automatizar tarefas e recursos é PHP, mas a automação pode ser obtida usando qualquer linguagem do lado do servidor, desde que a saída seja HTML semântico. (Desenvolvemos uma estrutura de sistema de arquivos específica para nossos protótipos, mas isso é assunto para outra ocasião.) Mais adiante neste artigo, explicaremos como os scripts do lado do servidor nos ajudaram a manter e testar várias versões da navegação.

Embora começar com HTML semântico, acessível e robusto seja vital, o princípio de “conteúdo em primeiro lugar, navegação em segundo” é igualmente importante porque ajuda você a considerar possíveis exceções futuras. Houve uma exceção à regra “conteúdo em primeiro lugar, navegação em segundo” neste projeto: a página inicial. Descobrimos, com base em análises, que a navegação era vista como o elemento mais importante na página inicial, o que significava que ela tinha que vir antes de qualquer conteúdo principal da página.

Interação e usabilidade

Uma vez tomada a decisão de projetar e desenvolver um módulo de navegação independente do tamanho da tela, era hora de focar nas interações de navegação. Considerando que adotamos uma abordagem mobile-first para projetar a navegação, o próprio módulo de navegação não apenas funcionaria naturalmente como esperado em pequenas janelas, mas também seria dimensionado facilmente para funcionar em grandes janelas.

Três versões interativas

Devido ao tamanho da navegação e ao número potencial de níveis aninhados, tivemos que eliminar alguns dos padrões de navegação móvel mais comuns como opções — por exemplo, selecionar menus suspensos e o padrão prioridade+. Nós nos concentramos na prototipagem de três versões interativas da navegação: um controle deslizante, um acordeão e um acordeão e controle deslizante. Cada um tem seus prós e contras, o que naturalmente influenciou nossa decisão.

Acordeão

O acordeão é provavelmente o padrão mais comum no celular. Ele divulga progressivamente, revelando informações mais detalhadas à medida que o usuário avança no tópico ou ação. Ele também garante que o usuário não fique sobrecarregado, e é por isso que queríamos usá-lo como uma solução de linha de base.

Aqui estão os prós do acordeão:

• Os usuários estão familiarizados com isso.
• Os usuários podem expandir toda a árvore de navegação para visualizar várias opções (afinal, sete níveis de navegação podem ser um pouco esmagadores).
• Funciona sem JavaScript, usando a pseudo-classe :target .
• Desenvolvê-lo é fácil.

E os contras do acordeão:

• Os ancestrais expandidos de uma categoria de nível profundo empurrariam o escopo atual para muito longe do topo da tela, exigindo muita rolagem.
• Sete níveis de navegação requerem sete graus da sugestão visual escolhida, sejam sete tons de uma cor básica (cinza), sete níveis de hierarquia tipográfica ou sete níveis de recuo.

Controle deslizante

Esta foi inicialmente a nossa solução favorita, mas falta um elemento importante: permitir uma navegação verdadeiramente lateral nas seções principais. Não seria um problema se o usuário sempre começasse a navegar a partir da página inicial, porque se familiarizaria cada vez mais com as seções principais. No entanto, para usuários que acessam uma página profunda na árvore de navegação, definitivamente teria sido um problema de usabilidade. Por exemplo, os usuários que pousam no terceiro, quarto ou quinto nível teriam que percorrer a árvore para chegar à página de contato. Atravessar sete níveis não é divertido, não importa o quão motivado o usuário possa estar.

Prós do slider:

• A hierarquia é clara.
• A animação é manhosa.
• Segue as convenções móveis.
• É relativamente fácil de desenvolver.

Contras do controle deslizante:

• Não é possível navegar de lado.
• A animação não é performática.

Híbrido (acordeão e controle deslizante)

Nós realmente queríamos manter a atratividade do controle deslizante, enquanto ainda permitia a navegação lateral. Assim, desenvolvemos uma solução híbrida combinando os melhores elementos dos dois padrões de navegação. Aliás, foi também a solução que escolhemos.

Prós do híbrido:

• A navegação lateral é possível.
• A animação é manhosa.
• A hierarquia é clara.

Contras híbridos:

• Requer algum aprendizado inicial.
• É complexo de desenvolver, com muitas partes móveis a serem consideradas.
• Tem alguns problemas de desempenho.

Como mencionado, o usuário deve poder navegar para cima e para baixo na árvore de navegação, sempre ciente de onde veio e para onde a navegação o levará a seguir. No entanto, essa é apenas a interação básica - tivemos que resolver alguns problemas adicionais para desenvolver um sistema de navegação utilizável.

Oito tipos distintos de links

Além dos itens de navegação atuais e ancestrais serem distintos em design (o que agora é, felizmente, uma prática bem estabelecida), melhoramos ainda mais a navegação e a usabilidade geral, ajudando o usuário a entender onde está e o que está explorando. Ajudar o usuário a entender a página atual e seus pais, bem como qualquer relacionamento infantil relevante, estava longe de ser suficiente. Outras ações importantes foram necessárias:

• poder ir diretamente para a página pai;
• ser capaz de visualizar os níveis pai e filho, enquanto permanece no URL original;
• entender rapidamente sua posição de navegação atual, enquanto pode explorar a navegação.
• compreender rapidamente sua posição atual na página.

Observação: usamos breadcrumbs para garantir que a posição da página atual esteja sempre clara para o usuário. Como queríamos evitar pular níveis completamente, as informações nas trilhas de navegação e na navegação tinham que corresponder uma a uma, mesmo com pseudo-níveis (ou seja, níveis que não têm uma página real).

Os requisitos do usuário acima resultaram em cinco tipos de itens de navegação semanticamente diferentes, com links auxiliares adicionais que permitiriam ao usuário percorrer a árvore para cima e para baixo sem precisar sair da página atual. Você pode imaginar a complexidade e as interdependências que vêm com tantas partes móveis.

Detalhes da animação

Todos os elementos na navegação são animados usando CSS, com cada animação tendo duas partes distintas:

• níveis animados horizontalmente,
• wrappers animados verticalmente.

Primeiro, os diferentes níveis de árvore no controle deslizante são alternados alterando a classe do wrapper mestre. Por exemplo, o wrapper de navegação fechado tem uma classe de .depth-0 . Quando um item de nível superior é expandido, a classe muda para .depth-1 . Quando um item de segundo nível desse item de nível superior é selecionado, a classe muda para .depth-2 e assim por diante. Isso resulta em um conjunto bastante simples de regras CSS que são aplicadas a um único elemento - a lista mais ordenada em um controle deslizante:

 .depth-1 .l-0.nav-open > ol { left: 0; } .depth-2 .l-0.nav-open > ol { left: -100%; } .depth-3 .l-0.nav-open > ol { left: -200%; }

No exemplo acima, .l-0 corresponde a um item de lista de nível zero e .nav-open é alternado sempre que o acordeão é definido como open . Isso significa que a lista ordenada de um filho direto em um item de lista de acordeão open é absolutamente deslocada para a posição negativa-esquerda.

Em segundo lugar, considerando que cada nível contém um número variável de itens da lista, a transição entre quaisquer dois níveis adjacentes deve ser suave.

Para conseguir isso, garantimos que sempre haja espaço vertical suficiente para que a animação horizontal seja executada sem problemas. A altura é calculada e aplicada em tempo real, recuperando o deslocamento vertical do elemento prestes a entrar na tela. Isso significa que tivemos que considerar um total de quatro cenários possíveis, mas na verdade só precisávamos resolver dois, cada um com uma ordem de execução ligeiramente diferente:

• Item de lista curta para um item de lista mais longo . A animação horizontal e vertical começam ao mesmo tempo.
• Item de lista longa para um item de lista mais curto . Depois que a navegação parar de deslizar horizontalmente, a animação vertical será iniciada.

Ambas as animações são iniciadas ao mesmo tempo, mas a segunda animação é iniciada após um atraso de 300 milissegundos, que é exatamente a duração da primeira animação (especificada em CSS usando a propriedade transition-duration ). A razão para isso é o desempenho de animação abaixo do ideal em dispositivos menos capazes quando várias camadas se sobrepõem antes de desaparecer “atrás da cortina”. O código simplificado fica assim:

 if (newHeight < oldHeight) { heightTimeout = 300; } else { heightTimeout = 0; } setTimeout(function() { $('.l-0.nav-open').css('height', newHeight); }, heightTimeout);

Outras melhorias

Já diante de um conjunto complexo de interdependências, percebemos ao testar a navegação que havia espaço para melhorias.

Primeiro, porque as fontes da web às vezes carregam um pouco mais tarde do que o resto da página, algumas sequências de texto na navegação que deveriam estar em uma linha se expandiriam para uma segunda linha antes que a fonte da web fosse totalmente carregada. Por exemplo, o link da seção de nível superior “News, Media and Resources” cai em duas linhas quando renderizado na fonte de fallback.

Como tudo tinha que ser muito compacto (já que tínhamos que usar posicionamento absoluto para a animação deslizante), a única solução era redefinir a altura do elemento afetado após o carregamento da fonte da web. Isso foi feito usando o Web Font Loader, desenvolvido por Bram Stein para Adobe Typekit e Google Fonts.

 WebFont.load({ custom: { families: ['FONT_NAME_1', 'FONT_NAME_2'] }, active: function() { // recalculate things here }, timeout: 5000 });

Observação: você notou como usamos um tempo limite de 5 segundos? Em nossos testes, descobrimos que esse foi o ponto ideal que fez funcionar em nossa linha de base “boa conexão 2G” (450 KB por segundo)!

Em segundo lugar, porque decidimos carregar condicionalmente os nós de navegação para melhorar o desempenho do carregamento inicial (mais sobre isso na próxima seção), queríamos que o usuário ficasse ciente de quantos itens de navegação estão disponíveis, caso haja um atraso ao carregar uma ramificação da árvore de navegação. Fizemos isso repetindo uma imagem de fundo de espaço reservado que se assemelha a uma sequência de texto.

Por fim, anexamos o código de espaço reservado no DOM com JavaScript antes de solicitar a ramificação de navegação. Isso mantém o DOM o mais limpo possível.

 element.append('<ol class="nav-loading"><li class="nav-placeholder"></li></ol>'); $.get('NAVIGATION_BRANCH_URL', function(data){ // replace the loader with the branch element.find('ol').replaceWith(data); });

atuação

Se você se lembra, uma de nossas principais metas no projeto era que o site tivesse um desempenho pelo menos 20% melhor do que os sites dos concorrentes. Não apenas alcançamos essa meta, mas ao fazê-lo ajudamos a SGS a reduzir significativamente o peso geral da página e os tempos de carregamento. Dê uma olhada nas seguintes estatísticas de antes e depois:

Você sabia que 12.000 links equivalem a 3 MB de HTML?

Está correto! Quando renderizamos a árvore de navegação completa pela primeira vez em nosso protótipo, ela somava 3 MB de HTML simples. Sem cabeçalho, rodapé e conteúdo – apenas a árvore de navegação composta por 12.000 links individuais.

Antes do redesenho, cada página continha a árvore de navegação principal e cada página do setor também incluía uma árvore de navegação específica do setor, implementada como um módulo separado. No entanto, o design otimizado para desktop tornou a navegação central ou específica do setor não apenas difícil de usar em pequenas janelas de visualização, mas também difícil de manter. É por isso que um dos principais objetivos do redesenho foi consolidar a árvore em um módulo único e de fácil manutenção.

Explorando opções para melhorar o desempenho

Para testar minuciosamente cada uma das três versões interativas da navegação, bem como avaliar seu desempenho, um ambiente de teste flexível era essencial. Isso nos permitiria fazer alterações rapidamente, bem como manter versões simultâneas para que pudéssemos compará-las facilmente umas com as outras.

Considerando o tamanho da árvore de navegação completa (até sete níveis de profundidade e 12.000 links navegáveis), era importante poder testar partes da árvore de navegação, bem como a própria árvore completa. Os desenvolvedores internos da SGS conseguiram exportar a árvore de navegação completa como um arquivo CSV de seu sistema de gerenciamento de conteúdo, o que nos permitiu criar uma função PHP facilmente configurável para gerar a árvore completa ou parte dela, dependendo do que precisávamos testar.

Nossa função PHP também simplificou a manutenção HTML da estrutura da árvore de navegação, porque a marcação de link e os nomes de classe mencionados podem ser facilmente alterados em um único local. Usar uma linguagem do lado do servidor para evitar ter que repetir o código pode parecer óbvio, mas criar esse tipo de ambiente não foi apenas uma adição bem-vinda, mas também uma missão crítica, porque era o pré-requisito para experimentação e testes ágeis.

Links de carregamento condicional

Mencionamos que precisávamos carregar condicionalmente os nós de navegação para melhorar o desempenho do carregamento inicial. A pergunta que precisava ser respondida era: quanto da árvore de navegação deve ser carregado inicialmente e quanto deve ser carregado mais tarde, e quando? Depois de testar e comparar os pesos e tamanhos dos diferentes ramos da árvore de navegação, bem como estudar o comportamento do usuário no site ao vivo existente, surgiram algumas conclusões interessantes.

Primeiro, os visitantes que estavam interessados ​​em apenas um tipo de indústria raramente visitavam outras indústrias. Depois de navegar na categoria de setor selecionada, cada visitante normalmente explora apenas algumas outras páginas.

Em segundo lugar (e como havíamos pensado inicialmente), os ramos específicos do setor causavam a maior parte da sobrecarga de desempenho. Quando removemos completamente as ramificações da indústria, o HTML foi reduzido para 70 KB, o que é muito melhor do que 3 MB! Ainda assim, isso significava que cada uma das 14 filiais da indústria pesava entre 300 e 500 KB. Quando fragmentamos ainda mais cada ramificação de serviço, descobrimos que cada nível subsequente pesaria cerca de 24 KB em média.

Embora estivéssemos cientes de que o HTML poderia ser ainda mais reduzido otimizando os nomes das classes e adicionando nós DOM via JavaScript (mais sobre isso em um minuto), ainda tínhamos que determinar se era melhor iniciar uma única solicitação HTTP em cerca de 300 a 500 KB ou para iniciar uma solicitação HTTP de cerca de 24 KB em cada nível. Inicialmente, parecia que enviar uma solicitação de 24 KB cada vez que o usuário avançasse mais abaixo na árvore de navegação seria mais benéfico. No entanto, isso resultaria no envio de várias solicitações HTTP pela rede, o que estava longe de ser o ideal, considerando que a latência da rede geralmente é um dos maiores gargalos para o desempenho do site. Também não fazia sentido prever o carregamento de nenhuma ramificação do setor, exceto quando o usuário mostrava intenção ao passar o mouse sobre um link do setor.

Devido à complexidade da navegação e à quantidade de links, o seguinte arranjo ofereceu de longe o melhor compromisso:

• Carregue os três primeiros níveis por padrão em HTML.
• Carregue a navegação do setor com JavaScript quando a intenção for mostrada, detectada usando o evento mouseover .
• Ramos carregados em cache para acelerar o carregamento em carregamentos de página consecutivos.

A lógica para páginas mais profundas era um pouco diferente, porque a navegação precisa ser acessível sem o JavaScript habilitado. Portanto, se um usuário (ou mesmo um bot de mecanismo de pesquisa) chegar a uma página profunda, o seguinte aconteceria:

1. Renderize os três primeiros níveis e a ramificação ancestral da página atual e os irmãos da página em HTML, permitindo assim que o usuário acesse facilmente as páginas pai, ancestral e irmã, além de poder acessar outras partes do site seguindo a mesma lógica.
2. Carregue a ramificação atual com JavaScript e substitua a ramificação ancestral da página atual inicialmente carregada.

Otimizando HTML

Se você realmente deseja otimizar seu HTML, todos os itens não essenciais devem ser transferidos para CSS e JavaScript. Nós podamos rigorosamente tudo, exceto a lista ordenada, seus itens de lista e seus respectivos links. Todos os links não essenciais (ou seja, ajudas de navegação) também foram removidos do HTML e reinseridos no DOM usando JavaScript (porque eles são ineficazes sem JavaScript de qualquer maneira). Esses links não essenciais permitem que o usuário faça algumas coisas:

• abra o próximo nível (internamente, chamamos esses “expansores”);
• subir um nível (chamamos esses “apoiadores” – mostrando falta de imaginação).

Embora o DOM resultante ainda fosse imenso, os auxílios à navegação não precisavam mais ser transferidos individualmente pela rede.

Finalmente, a última otimização que fizemos foi reduzir o número de classes, bem como encurtar o comprimento dos nomes das classes; por exemplo, .very-long-class-name tornou-se .vlcn . Enquanto o último rendeu os maiores ganhos, essa otimização é difícil de justificar porque geralmente não reduz significativamente o tamanho do arquivo HTML e, mais importante, reduz a clareza do código, possivelmente dificultando a manutenção. No entanto, cortar até mesmo um único byte de cada um dos 12.000 itens da lista tornou um exercício que valeu a pena e uma troca aceitável.

O resultado? Cerca de 40 KB ou mais de HTML inicial (8 a 9 KB quando compactado e transferido pela rede) e 200 a 300 KB de HTML para cada setor (15 a 25 KB quando compactado e transferido).

Conclusão: os ganhos marginais são importantes

Gostamos de usar uma analogia do mundo dos esportes: melhorar cada pequena coisa em 1% melhora drasticamente o desempenho. Isso se aplica ao que fizemos no projeto SGS e sua intrincada navegação. Ao focar nos detalhes mais sutis, melhorando cada detalhe um pouquinho, reduzimos significativamente a complexidade da navegação e melhoramos os tempos de carregamento, mantendo a navegação atraente e envolvente para os usuários. O que poderia ter sido um pesadelo e um osso duro de roer se transformou em uma solução técnica e interativamente relevante, flexível o suficiente para acomodar melhorias adicionais.

Acima de tudo, o processo de design de prototipagem contínua, investigação de opções e refinamento das melhores soluções provou ser extremamente eficaz - tanto que forneceu um forte argumento para a equipe interna aplicar os mesmos princípios fundamentais ao desenvolver outros produtos na organização, sem contar que ajudará a equipe a continuar refinando e otimizando o novo sistema de navegação. Nenhum projeto web é realmente completo; sempre há mais algumas coisas na lista de tarefas. Tudo bem, desde que continuemos testando, refinando e fornecendo a melhor experiência para os usuários.