fbpx

Arquitetura de informação em produtos digitais

Durante o desenvolvimento de produtos digitais é importante conhecer as necessidades do usuário e, a partir delas, criar trajetos, caminhos e formas de “conduzir o usuário da melhor maneira” até que os objetivos sejam alcançados. Reforçamos que a melhor maneira não é fixa e eternamente correta, a medida que a tecnologia avança ou os conhecimentos/necessidades do usuário evoluem é importante sempre revisitar. 

Se por um lado, entender as necessidades do usuário é importante, saber tangilibizar o processo é imprescindível. Para muitas pessoas as coisas existem a partir do momento em que elas podem ver, por isso uma boa arquitetura é aquela que os usuários entendem e experimentam. No entanto, as pessoas não conseguem ver toda a estrutura que construimos para que o usuário entenda e experimente a interface. O que torna o processo um pouco mais trabalhoso do que deveria ser.

Aqui no Ideativo, sempre iniciamos entendendo o objetivo do produto e depois da funcionalidade. Desmembramos em etapas nas quais o usuário deve percorrer para finalizar uma tarefa. Para isso, utilizamos a jornada do usuário. Em paralelo, analisamos o sistema. Como trabalhamos com sistemas legados, levamos em consideração o framework utilizado pela empresa.

 


1. Jornada do usuário

Essa ferramenta é muito comum e um dos objetivos é explicitar os conhecimentos e as ações do usuário, organizando e encadeando uma ação após a outra. Esse exercício nos ajuda a identificar os pontos mais sensíveis da jornada, momentos que devemos trabalhar feedbacks ou conteúdos direcionados. Estudamos maneira de oferecer performance e otimizar o processo do usuário.

Jornada do usuário, marcando os pontos sensíveis e as ações possíveis em cada etapa do processo

As jornadas são construídas com os usuários e tem objetivo de entender quais as ações são executadas dentro do sistema. Para explorar o contexto de uso, trocamos uma ideia sobre a rotina de trabalho. Esse mergulho no contexto do usuário é super importante, pois com as informações coletadas criamos a estratégia de atuação. Existem outras questões de estratégia que aplicamos, no entanto o foco desse artigo é mostrar como construimos a arquitetura de informação a partir das necessidades do usuário. Abaixo algumas imagens das interações que já fizemos para mergulhar no contexto dos projetos.

Dinâmicas presenciais e remotas para construção de jornadas, tanto da parte de vista dos stakeholders, desenvolvedores e usuários finais.

2. Análise do sistema e contexto de desenvolvimento

Em paralelo a construção da jornada, analisamos o sistema e as possibilidades que o framework utilizado pode nos oferecer. Nos exemplos abaixo, trabalhamos em uma plataforma de hospedagem e um módulo de faturamento de um ERP, neles destacamos os componentes, entendemos os comportamentos e como são as conduções do usuário. Geralmente, para explicitar a estrutura, separamos cada item com cores diferentes para verificar a consistência, aplicamos as heurísticas e, a partir, disso conseguimos ter um panorama do comportamento do sistema. 

Vida real

Nesse momento, designers que estão iniciando se perdem, porque existe um excesso de informação para assimilar. Quem já passou pela experiência de iniciar em uma empresa e ter aquele overload de funcionalidades, processos e de um sistema gigantesco cheio de oportunidades para trabalhar? Então, vem a pergunta… por onde começar?Que tal começar pelo começo? Entender melhor o contexto dá bagagem para argumentar e priorizar as atividades e seguir por partes para não ficar doido, rs.

 

2.1 Avaliação do wireframe 

Iniciamos identificando a estrutura do sistema por meio da análise do wireframe – caso não conheça o wireframe, dá uma olhada no conteúdo que a Eduarda fez sobre isso 😉 –Acessamos a Demo ou a versão dos DEVs para ter a experiência de navegação. Durante essa exploração, começamos a levantar dados, tiramos fotos, anotamos os problemas e analisamos cada etapa e regras de negócio. As regras são os requisistos obrigatórios para o negócio funcionar – aqui é importante ressaltar os requisitos funcionais, aqueles que o usuário vê e interage; requisitos não funcionais, são aqueles que o sistema executa sem que o usuário saiba. Por exemplo: uma requisição ao banco de dados.

Exemplo

Imagine uma ferramenta de assinaturas digitais, a regra aqui é entregar um documento assinado. Então, as perguntas são, quais são as etapas obrigatórias ou regulamentações que devem ser cumpridas para entregar a assinatura digital?

Abaixo, apresentamos uma interface de um sistema de hospedagem, analisamos a estrutura inicial. A ideia era de entender os pontos positivos existentes e quais os fluxos mais assertivos. Por isso, analisamos o wireframe e o fluxo do sistema para entender como ele operava.

Análise de estrutura da página e componentes. Entender como são distruibuidos na interface

 

Esse segundo exemplo é o módulo de faturamento de um ERP.

 

Também criamos uma hierarquia de navegação das interfaces para analisar como o usuário navega e interage entre uma interface e outra. Para deixar o exemplo mais organizado, limpamos os nossos comentários, mas geralmente, falamos muito e discutimos em cima dessas questões. Criamos uma matriz CSD e buscamos responder as nossas dúvidas junto aos envolvidos no projeto (stakeholders, DEVs, POs e usuários)

 

2.2 Avaliação do fluxo de navegacao 

Os fluxos tem o objetivo de apresentar as relações hierarquicas de navegação e os relacionamentos que existem entre uma etapa e outra. No livro Designing Interfaces, a Jenifer Tidwell apresenta diversos tipos de fluxos, o que estamos trabalhando é o hieráquico linear.

Visão geral de um único módulo, nesse cenário, misturado com a quantidade de informações coletadas. É o momento de constuir análises e priorizar, isso só acontece com o cruzamento dos dados coletados na pesquisa.

Para a priorização utilizamos os dados da pesquisa e criamos uma estratégia de atuação. Alinhamos as entregas e o escopo, somente depois disso, partimos para a estruturação de novas propostas. Portanto, nesse case, mergulhamos apenas na parte de faturamento. Como já tínhamos essa parte do fluxo desenhada, só partimos para verificação das regras de negócio que ainda estavam ativas, nesse momento buscamos simplificar a distribuição da informação.

Estrutura do fluxo de navegação identificado e sintetizado pela equipe do Ideativo

Após essas etapas é que iniciamos as propostas de fluxos e wireframes, utilizamos muitos assets que nos ajudam a agilizar o processo. Para nós, o mais importante é entender bem o que estamos fazendo, essa etapa de Ideação – para quem não sabem o nome Ideativo veio da junção dos conceitos de ideia e ativo, ou seja, ideias em ação em atividade. Ideativo ♥.

3.Aplicação dos resultados das pesquisas em fluxos e wireframes para validação com os usuários

Esse processo de construção de interface foi desenvolvido durante anos de atuação – claro, com uma ajudinha do Garret –  às vezes, é necessário ajustar algumas ferramentas e incluir etapas, mas no geral fazemos esse processo antes de efetivamente sair desenhando telas. Isso é importante para construir propostas viáveis e, com certeza, muito melhor do que ir apenas desenhando telas. Nós sempre cruzamos os dados de negócio, tecnologia e usuário para propor algo equilibrado e consistente. 

Recapitulando os tópicos…

UX research

  • Entender a necessidade do usuário e construção de jornadas;
  • Em paralelo, estudar o sistema e as regras de negócios aplicadas e ainda vigentes;

Planejamento

  • Reunir a equipe e apresentar os resultados e, em conjunto, priorizar;

Operação

  • Com os conhecimentos adquiridos, construir uma proposta de fluxo e wire;
  • Validar com o usuário;
  • Aplicar camada de UI e validar novamente 😉

Agora, depois de discutir cada pedacinho, bom ver os resultados, né?

Trabalhamos com dois cases, um de hotelaria, e outro um ERP no módulo de faturamento. Durante as pesquisas muitos problemas foram mapeados, e com ajuda do pessoal da tecnologia conseguimos propor novas formas de interação, mantendo as regras de negócio. Conseguimos trabalhar com os fluxos de navegação tornando mais claro e, deixamos o workspace de trabalho sempre à mostra. Outra questão, foi a sintetização do excesso de informações que a tela oferecia. Trabalhamos em diversos outros pontos, mas esses foram os mais evidentes.

Sistema de hotelaria

ERP – Faturamento

Esse conteúdo foi bastante denso, mas gostaríamos de mostrar o processo que fica intangível para os usuários e como ele é relevante para a construção de uma proposta. Dica, nunca desenhe a interface para ela ser bonita, busque entender como ela funciona, para que serve, quem vai usar e acrescente essas variáveis no seu processo, você vai enriquecer muito a entrega.

Pensando nisso, construimos um workshop voltado para o treinamento dessa parte do desenvolvimento do sistema. Se interessou, vem com a gente!

VOCÊ É DESIGNER OU UX DESIGNER E ESTÁ NO CORRE PARA CONSEGUIR ORGANIZAR O CAOS QUE SÃO OS SISTEMAS EM QUE ESTÁ TRABALHANDO?

De 23 de novembro a 7 de dezembro, vamos treinar a construção da arquitetura de informação em sistemas complexos. Vem com a gente em um curso que tem o objetivo de praticar o “real-oficial” do que acontece no dia a dia do UX design. Se chegou até aqui é porque você tem interesse, então aproveite e se cadastre na Lista VIP e receba as informações de primeira mão 😉

Patricia Prado
patricia@ideativodesign.com.br

Co-fundadora do Ideativo Design e do UX Overtake. Doutoranda em Linguística (UFSC), mestre em Interfaces e Interações Comunicacionais (UDESC), especialista em UX Design (UFSC). Trabalha com design há mais de 15 anos, já foi líder local do IxDA, Diretora da ADG Brasil e organizadora geral do Interaction South America - Florianópolis.

Saiba tudo sobre UX design e como aplicar na sua equipe. Então, cadastre-se na nossa news ;)