Como conduzir uma auditoria de arquitetura de informação baseada em tarefas

Antes de redesenhar menus ou aprovar um novo mapa do site, audite tarefas representativas e todos os percursos plausíveis que conduzem ao resultado pretendido. Um menu sobrecarregado, páginas com muitas saídas ou comentários vagos sobre informação difícil de encontrar são sinais para investigar, não diagnósticos. O problema real pode estar no conteúdo em falta, num rótulo ambíguo, numa ligação contextual ausente, em resultados de pesquisa fracos ou num controlo que impede a conclusão. Seguir tarefas concretas mantém o investimento ligado ao que as pessoas precisam de conseguir.

Que decisão deve a auditoria ajudar a tomar?

A auditoria deve começar por uma decisão delimitada: reparar uma secção, rever rótulos, preparar uma migração ou determinar se há evidência suficiente para uma reformulação mais ampla. Registe quem decidirá, que alternativas estão realmente disponíveis e que evidência será necessária para escolher entre elas. Esta formulação impede que a equipa transforme uma inspeção aberta num catálogo interminável de preferências e faz com que cada observação possa ser relacionada com uma escolha operacional concreta.

Defina também os públicos, objetivos, pontos de entrada, tipos de página, dispositivos, idiomas, permissões e estados de jornada abrangidos. As conclusões serão válidas para esses contextos, não para um utilizador médio abstrato. A arquitetura de informação abrange a organização, os rótulos e a navegação que ajudam as pessoas a encontrar informação, perceber onde estão e concluir tarefas; a auditoria observa como esse sistema existente suporta os resultados selecionados.

• Factos conhecidos: elementos confirmados sobre conteúdo, tecnologia, permissões ou funcionamento.
• Comportamentos observados: ações e explicações registadas durante tarefas ou investigação anterior.
• Achados de inspeção: riscos identificados por especialistas, ainda não observados com utilizadores.
• Hipóteses: explicações ou soluções que precisam de validação antes de orientar investimento.

Mantenha o âmbito distinto de trabalhos vizinhos. Um inventário descreve o conteúdo existente; uma auditoria técnica de SEO examina sinais para motores de pesquisa; uma avaliação de conformidade de acessibilidade tem critérios e procedimentos próprios; uma reformulação já envolve conceber mudanças. A auditoria baseada em tarefas diagnostica se o sistema atual oferece percursos compreensíveis e utilizáveis para tarefas escolhidas. Pode revelar questões para esses outros trabalhos, mas não os substitui.

Como construir um conjunto representativo de tarefas a partir de evidência?

Construa o conjunto de tarefas como resultados reconhecíveis pelos utilizadores, sem revelar o nome da página ou a opção de navegação que a equipa espera que escolham. Em vez de pedir para «ir à área de recursos», descreva a necessidade e a condição de conclusão. A orientação do GOV.UK recomenda investigar o que as pessoas tentam fazer, como procedem atualmente, que problemas encontram e de que resultado necessitam. Esta formulação reduz pistas artificiais e permite observar percursos genuínos.

Reúna candidatos a partir de analítica, pesquisas internas, pedidos de apoio, comentários, estudos anteriores, entrevistas, observação e equipas em contacto direto com utilizadores. Estes materiais não têm todos o mesmo peso. Dados de analítica, pesquisas internas, saídas e contactos de apoio são sinais úteis, mas não provam isoladamente a intenção do utilizador, a causa do problema ou a solução estrutural correta. Opiniões de intervenientes e avaliações especializadas devem permanecer identificadas como hipóteses até encontrarem apoio em evidência sobre utilizadores.

1. Equilibre tarefas frequentes com tarefas de consequência elevada, difíceis ou relevantes para públicos mal servidos.
2. Registe o público, o motivo que desencadeia a tarefa e os pontos de partida realistas.
3. Defina o conteúdo ou a ação que constitui sucesso sem impor um único percurso.
4. Associe cada tarefa à fonte de evidência e indique a confiança que essa fonte permite.

Um estudo documentado pela Digital.gov derivou cenários realistas de investigação anterior e reviu a cobertura das tarefas antes dos testes. A lição transferível é a proveniência, não as contagens usadas nesse caso. Reveja o conjunto com pessoas que conheçam públicos diferentes e confirme se cada tarefa serve a decisão da auditoria. Elimine duplicações, preserve necessidades distintas que pareçam semelhantes e não deixe que o conteúdo já existente determine automaticamente aquilo que merece ser testado.

O que deve registar a folha de tarefas e percursos?

A folha deve ligar cada tarefa, público e origem da evidência ao resultado esperado, aos percursos plausíveis, aos sinais inspecionados, ao comportamento observado, ao diagnóstico e ao novo teste. Use o mesmo registo desde a inspeção até à decisão final. Assim, uma recomendação não aparece como preferência isolada: é possível seguir a cadeia entre uma necessidade demonstrada, um ponto de decisão concreto, a falha encontrada e a alteração proposta.

Comece por vários contextos realistas: uma página chegada através de pesquisa externa, uma página de secção, uma área autenticada ou a pesquisa interna. Mapeie navegação global e local, páginas agregadoras, ligações contextuais e resultados de pesquisa, sem presumir que todas as pessoas começam na página inicial. Em cada escolha, registe a pista visível, a expectativa criada, o destino alcançado e a possibilidade de reconhecer e recuperar de um engano.

Uma auditoria baseada em tarefas não pergunta se o mapa do site parece arrumado; pergunta se as pessoas chegam ao resultado por percursos realistas e com evidência acionável.

Ao inspecionar percursos alternativos, considere o critério 2,4,5 das WCAG 2,2: exige mais do que uma forma de localizar uma página num conjunto, exceto quando essa página é um resultado ou uma etapa de um processo. Ligações relacionadas, mapas do site, pesquisa e navegação abrangente são técnicas documentadas. Esta verificação tem alcance específico; não converte a folha numa avaliação completa de acessibilidade nem obriga processos sequenciais a oferecer atalhos inadequados.

Como inspecionar o percurso completo sem analisar apenas os menus?

Inspecione todos os componentes materiais entre a entrada e a conclusão: páginas de chegada, navegação global e local, páginas agregadoras, agrupamentos, cabeçalhos, pistas de localização, ligações contextuais, pesquisa interna e conteúdo ou ação final. A orientação da Microsoft recomenda planear a navegação a partir das perspetivas, tarefas comuns e modelos mentais dos utilizadores. A estrutura organizacional interna pode ajudar a governar conteúdos, mas não deve ser tomada como prova de que as categorias fazem sentido para quem chega de fora.

Em cada ponto de decisão, pergunte que promessa faz o rótulo e se o destino a cumpre. Os termos devem ser específicos, familiares no contexto, concisos o suficiente para serem percorridos visualmente e distinguíveis das escolhas vizinhas. O critério 2,4,6 das WCAG 2,2 exige que os cabeçalhos e rótulos disponibilizados descrevam o respetivo tema ou propósito. Ser breve não basta: uma palavra curta mas vaga pode transferir o esforço de interpretação para o utilizador.

• É evidente onde a pessoa se encontra e que nível da estrutura alcançou?
• As escolhas seguintes são visíveis no momento em que se tornam relevantes?
• Um destino inesperado permite regressar, reformular ou seguir outro percurso?
• A página final contém a informação, o estado ou a ação necessária para concluir?
• O percurso mantém-se compreensível noutros dispositivos, permissões, idiomas e estados relevantes?

Compare ainda mecanismos repetidos entre tipos de página. O critério 3,2,3 das WCAG 2,2 requer que mecanismos de navegação repetidos mantenham a mesma ordem relativa, salvo quando a mudança é iniciada pelo utilizador; não proíbe navegação local ou secundária. A pesquisa interna pode ser um percurso alternativo válido e a sua utilização não demonstra, por si só, que a navegação falhou. Observe consultas, reformulações, relevância dos resultados, confiança no destino e conclusão antes de atribuir a causa.

Que método deve validar cada percurso incerto?

Escolha o método de acordo com a incerteza que precisa de resolver, não segundo a ferramenta disponível. A inspeção especializada e os dados existentes ajudam a localizar pontos suspeitos, mas um risco identificado pelo auditor não deve ser apresentado como falha observada num utilizador. Escreva primeiro a pergunta de evidência: pretende compreender agrupamentos, avaliar rótulos numa hierarquia, observar controlos renderizados ou confirmar se a pessoa conclui o resultado através de vários percursos?

• Use ordenação de cartões quando a dúvida incide sobre agrupamentos esperados ou linguagem de categorias.
• Use testes de árvore quando pretende isolar a encontrabilidade proporcionada pela hierarquia e pelos rótulos.
• Use testes de usabilidade baseados em tarefas quando a pergunta inclui páginas renderizadas, controlos, ligações, pesquisa, recuperação ou conclusão.
• Use inspeção e dados comportamentais para formular hipóteses, escolher cenários e concentrar investigação posterior.

A ordenação de cartões permite investigar como os participantes agrupam conteúdos e, na modalidade aberta, como nomeiam os grupos criados; não valida um percurso completo. O teste de árvore pode isolar a encontrabilidade através de uma hierarquia e revelar categorias ou rótulos confusos, mas exclui grande parte da interface renderizada. Percursos divergentes e explicações dos participantes podem revelar ambiguidades mesmo quando alguns chegam ao destino previsto, desde que sejam interpretados perante a tarefa e os percursos alternativos válidos.

A NIST descreve testes de usabilidade com utilizadores e tarefas representativos, recorrendo potencialmente a conclusão, erros, tempo, comentários qualitativos e satisfação. Selecione apenas medidas que esclareçam a decisão: necessidade de ajuda, escolhas erradas, retrocessos, reformulações da pesquisa, confiança no destino e raciocínio verbalizado podem ser mais reveladores do que uma pontuação agregada. Não existe uma tabela universal que transforme automaticamente estes dados numa aprovação de reformulação.

Como transformar achados em reparações delimitadas ou num caso de reformulação?

Transforme os achados em decisões classificando primeiro a natureza da falha e escolhendo depois a menor alteração sustentada pelo registo. Uma pessoa que não conclui uma tarefa não demonstra automaticamente que a navegação inteira está errada. Pode faltar conteúdo, não existir uma entrada plausível, o rótulo criar uma expectativa incorreta, o agrupamento ser inesperado, a orientação desaparecer, uma ligação contextual estar ausente, a pesquisa devolver resultados fracos ou o controlo renderizado impedir a utilização.

• Cobertura: o conteúdo, a ação ou o estado necessário não existe ou está incompleto.
• Entrada: um ponto de partida provável não oferece qualquer percurso plausível.
• Rótulo ou agrupamento: a promessa é enganadora ou a localização contraria a expectativa.
• Orientação ou ligação contextual: falta contexto para perceber a posição ou continuar.
• Pesquisa ou consistência: resultados e mecanismos repetidos são fracos, variáveis ou difíceis de interpretar.
• Interação: a estrutura é plausível, mas o controlo ou a apresentação impede o uso.

Priorize com entradas visíveis: importância da tarefa, públicos afetados, frequência observada da falha, consequências, força da evidência e dependências de correção. Discuta estes fatores diretamente, em vez de os ocultar num índice universal ponderado. A solução pode ser corrigir conteúdo, reparar um rótulo ou uma ligação, reagrupar páginas, ajustar a pesquisa, reestruturar uma secção ou, no limite, reformular o sistema. A escala da intervenção deve acompanhar a escala da evidência.

Atribua um responsável, execute a alteração e repita as tarefas e os percursos afetados antes de declarar sucesso. A reformulação ampla só fica sustentada pelo registo quando falhas importantes são repetidas, observadas nos contextos relevantes, estruturais e pouco suscetíveis de reparação local. Se a definição das tarefas, o desenho da investigação ou os compromissos estruturais excederem a capacidade da equipa, envolva um profissional experiente em arquitetura de informação ou investigação UX.

Quando os achados levantarem dúvidas de acessibilidade, encaminhe-as para um especialista qualificado e realize a avaliação apropriada. Uma auditoria baseada em tarefas e a verificação dos critérios WCAG citados não demonstram conformidade de acessibilidade do website inteiro. O resultado final da auditoria deve ser uma decisão de novo teste: que reparação será validada, com que tarefas, públicos e contextos, e que evidência futura justificaria manter, ampliar ou abandonar a intervenção.