Rafael Kiso
rafael.kiso@focusnetworks.com.br
Graduado em Publicidade e Propaganda
Focusnetworks Interactive

Paulo Robson
paulo.robson@focusnetworks.com.br
Tecnólogo em Desenvolvimento de Sistemas para Internet
Focusnetworks Interactive

Sumário

A finalidade do projeto foi desenvolver uma nova interface, com mais usabilidade, mais simples e prática dos sistemas AHEAD (Aircraft Health Analysis and Diagnosis) e FLD (Flight Line Diagnosis), com o intuito de facilitar seu uso e elevar a experiência do usuário. Foi desenvolvida uma nova interface padronizada entre os dois sistemas com o objetivo de criar um único ambiente transmitindo a sensação da existência de um sistema único para seus usuários, o que ficou conhecida então como AHEAD 2.0.

Este projeto teve por objetivo definir o desenvolvimento de um conjunto de interfaces necessárias para o uso do sistema AHEAD 2.0, considerando requisitos de usabilidade, arquitetura da informação e ergonomia. O AHEAD 2.0 agregou as funcionalidades contidas na versão 1.1 com novas funções requisitadas pelo mercado de aviação executivo.

Palavras-chave

Aviação Comercial, Aviação Executiva, Monitoramento, Diagnóstico, Rich Internet Application, FLEX, Inteligência Artificial

1.    INTRODUÇÃO

O Aircraft Health Analysis and Diagnosis (AHEAD) é uma plataforma web para monitorar a saúde da frota de aeronaves, fornecendo informação de manutenção em tempo real de maneira amigável e simples. O AHEAD foi projetado e baseado nas operações diárias de companhias aéreas, objetivando a redução do tempo de manutenções imprevistas, atrasos e cancelamentos de vôos.

O AHEAD até sua versão 2.0, case deste documento, era um sistema complexo de se utilizar. Além de se tratar de um assunto técnico, o que muitas vezes requer a utilização de manual, o sistema não era nada intuitivo. Tornar o novo AHEAD, o 2.0, num sistema amigável, intuitivo, com excelente usabilidade e experiência do usuário, se tornou uma premissa fundamental para o serviço prestado pela Embraer.

Para entender melhor a plataforma, esta seção visa passar informações básicas de como o sistema opera e a arquitetura do AHEAD.

1.1    Operação Básica do AHEAD

O AHEAD trabalha com dados enviados pelas aeronaves que estão sendo monitoradas. Esses dados são compostos por informações básicas de posicionamento da aeronave, também referido como “OOOI”, e informações do Computador Central de Manutenção (Central Maintenance Computer – CMC).

Ambos os dados são transmitidos da aeronave para o solo usando protocolos de rede. A transmissão desse tipo de informação da aeronave para as estações de solo é também referenciada como “downlink”. Os dados recebidos das estações de solo são rotados para os servidores do AHEAD usando uma série de diferentes protocolos e métodos como o FTP. Os dados são processados e hospedados nos servidores AEROChain e o resultado é disponibilizado na interface web do AHEAD.

1.1.1    Principais Funções do AHEAD

• Mostrar informações básicas de posicionamento das aeronaves (OOOI);
• Receber informações de falhas enquanto a aeronave ainda está voando;
• Antecipar a identificação de falhas;
• Gerenciar filtros de alertas;
• Gerenciar correlações de falhas;
• Gerenciar condições de despacho;
• Fornecer links para as Publicações Técnicas Digitais da Embraer;
• Permitir o encaminhamento da falha e acompanhar as atividades de manutenção;
• Manter o histórico de saúde da aeronave.

1.1.2    Arquitetura do AHEAD

Figura 1 – Arquitetura do AHEAD (clique na imagem para ampliar)

1.2    Poblemática do AHEAD 1.0

O AHEAD 1.0 foi desenvolvida por engenheiros para engenheiros, ou seja, nem todos os públicos de interesse conseguiam usar o sistema. Além de assunto tratado no sistema ser de natureza complexa, a maioria dos usuários preferiam usar os modelos tradicionais em papel para atingir os objetivos do que usar o AHEAD.

A partir do momento em que a Embraer decidiu disponibilizar o sistema para que a aviação executiva usasse, todos em comum conscenso decidiu revisar a usabilidade e a experiência do AHEAD. Aproveitando a oportunidade para lançar uma nova versão com novas funcionalidades, a Embraer decidiu dar ênfase na questão da interface e obter maior sucesso de uso pelos públicos de interesse.

O sistema sendo usado massivamente pelos clientes finais, pode-se ampliar a base de conhceimento da inteligencia artificial do sistema e ajudar na resolução de problemas e falhas mais rapidamente. Portanto, tornar o sistema mais atrativo e amigável se tornou muito importante para os negócios como um todo.

2.    O Projeto AHEAD 2.0 – Nova Interface

O objetivo do projeto, do ponto de vista de arquitetura de informação, era desenvolver uma nova interface, com mais usabilidade, mais simples e prática dos sistemas AHEAD e FLD, com o intuito de facilitar seu uso considerando requisitos de usabilidade e ergonomia da Embraer. Padronizar a interface entre os dois sistemas com o objetivo de criar um único ambiente transmitindo a sensação da existência de um só sistema para seus usuários.

Veja a definição dos módulos e escopo do projeto na Tabela 1.

Tabela 1 – Módulos do projeto que definem o escopo

2.1    Premissas, Restrições e seus Desafios

Do ponto de vista da arquitetura da informação, o principal desafio do projeto foi lidar com a questão do idioma, toda a interface foi concebida em inglês, a questão da confusão tradicional entre o que é arquitetura de informação, identidade visual e design, a interface tinha que seguir a identidade visual do novo portal FLYEMBRAER, a questão da linguagem técnica de cada tipo de usuário, e a questão da usabilidade, onde por natureza o sistema AHEAD é complexo.

2.1.1    Premissa da Usabilidade

O desenvolvimento das novas interfaces seguiu técnicas e metodologias necessárias para:

• Garantir uma boa usabilidade do sistema, considerando uma fácil e intuitiva navegação;
• Permitir ao usuário encontrar a informação necessária em no máximo 3 (três) interações (cliques do mouse);
• Interface leve e rápida, destacando as informações pertinentes na hora necessária;
• Visual adequado para utilização em desktops e notebooks;
• Flexibilidade e modularidade de forma que a inserção de novas funcionalidades e dados exija pouco esforço e poucas alterações.
• Garantir o uso de siglas/acrônimos reconhecidas no meio aeronáutico (ex:. FIM, ANN, etc.);
• Garantir o uso de siglas/ícones que facilitem a sua associação à funcionalidade (ex: o botão de SALVAR é representado por um “disquete”).

2.1.2    Premissa da Tecnologia

O desenvolvimento das novas interfaces considerou a ferramenta Adobe Flex® para a criação de componentes e comunicação dos dados do sistema, o que permitiu a integração com o back-end do sistema que utilizava a linguagem de programação Java. Isso influenciou muito a forma de estruturar as interfaces e a lógica de navegação do usuário. O conceito RIA (Rich Internet Applications) foi fundamental para essa premissa.

2.2    Produtos Liberados do Projeto para AI

Aqui estão listados os produtos construídos que serviram de entrada ou saída no processo de arquitetura da informação:

• Caso de uso do sistema
• Relatório sintético de casos de uso de sistema
• Glossário
• Especificação técnica padrão UML
• Documentos de design de interfaces e usabilidade
  • Detalhamento dos requisitos.
  • Entrevistas com stakeholders, personas e key users nacionais e internacionais
  • Teste de usabilidade no sistema AHEAD 1.0
  • Planejamento Estratégico Interativo
  • Sitemap e Diagramas de Fluxo
  • Wireframes
  • Layouts propostos para a interface baseado nos wireframes
  • Testes de usabilidade das interfaces do AHEAD 2.0
• Plano de testes da interface
• Caso de teste
• Evidências de testes
• Plano de controle de qualidade
• Plano de aceitação do produto

2.3    Metodologia da Arquitetura de Informação

A metodologia aplicada tinha a finalidade de estabelecer um planejamento estratégico interativo, para que o produto final do trabalho atendesse as expectativas tanto da Embraer quanto dos seus públicos de interesse. Era fundamental entender os objetivos de negócio da Embraer, para poder agregar valor ao AHEAD e relançar a plataforma no mercado.

O processo passou por três atividades principais: Diagnóstico, Estratégia e Especificação. Veja a Figura 2.

Figura 2 – Processo do Planejamento Estratégico Interativo (clique na imagem para ampliar)

Cada atividade principal continha sub-atividades que geravam informações de entrada para a próxima atividade. Cada sub-atividade possui uma técnica e metodologia própria. Nas subseções a seguir será descrito somente o Diagnóstico e a Estratégia, pois a Especificação poderá ser encontrada na seção de arquivos suplementares.

2.3.1    Diagnóstico

Na etapa de Diagnóstico, foram realizadas entrevistas com stakeholders, reuniões exploratórias com a área de negócios, análise de dados fornecidos pela Embraer, benchmarks de concorrentes, e efetuado testes de usabilidade com 15 key users, cada 3 (três) pessoas representando uma persona. Portanto, ao todo foram identificados 5 (cinco) personas.

Cada teste foi realizado individualmente, e o tempo médio gasto com cada um foi de 50 minutos. Esse tempo se deu, pois ao mesmo tempo em que o key user testava o AHEAD 1.0 através das taks dadas pelo moderador, o mesmo ao perceber uma dificuldade do usuário já interagia e perguntava como aquela task poderia ser mais bem realizada.

O objetivo principal era identificar a experiência dos usuários com o sistema AHEAD 1.0, qual era o processo de navegação, suas dificuldades, seus modelos mentais, seus objetivos funcionais.

Veja um exemplo de persona do teste na Tabela 2. Consulte todas as personas na seção de arquivos suplementares.

Tabela 2 – Modelo de Persona utilizado

Todos os testes foram monitorados e gravados usando a ferramenta comercial Morae da fabricante TechSmith. Veja a Figura 3 e 4.

Figura 3 – Teste de usabilidade filmada para ver a reação dos usuários (clique na imagem para ampliar)

Figura 4 - Teste de usabilidade filmada para ver a reação dos usuários (clique na imagem para ampliar)

Ao final da etapa de Diagnóstico, foi realizado um alinhamento entre a proposta de valor da Embraer e os objetivos dos key users. A partir daí, passamos para as definições estratégicas que atendessem todos os públicos de interesse.

2.3.2    Estratégia

A atividade para definir a estratégia foi desenvolvida e estruturada para responder as seguintes sub-atividades: Estratégia Interativa, Estratégia Criativa, e Modelo de relacionamento com os públicos de interesse.

A Estratégia Interativa tinha como finalidade definir a estratégia de interação receptiva e ativa. Basicamente era definir quais momentos o sistema deveria ser pró-ativo na sua interface, auxiliando o usuário numa busca ou filtro, por exemplo, e quais ele deveria ser reativo e esperar o clique do usuário.

Nesta etapa foram definidos os diversos sistemas de organização da informação, categorizando as informações e como elas deveriam ser ordenadas, dependendo do objetivo do usuário. Como é premissa do sistema que o usuário entre sabendo o que quer fazer, todo o esquema de organização da informação foi baseada em esquemas exatos, determinando tempo, localização e seqüência lógica de navegação.

Após a definição dos sistemas de organização, foi definido o sistema de navegação. Basicamente foram trabalhados 10 princípios básicos para estabelecer um sistema de navegação de qualidade:

1. Fácil de aprender;
2. Ser consistente;
3. Prover feedback;
4. Presente de diferentes formas conforme o contexto;
5. Oferecer alternativas;
6. Economizar ações e tempo de utilização;
7. Apresentar mensagens visuais claras e no momento adequado;
8. Possuir rótulos compreensíveis;
9. Estar em sintonia com o propósito do sistema;

10.  Suportar os objetivos e comportamentos de cada tipo de usuário.

A Figura 5 demonstra os princípios aplicados no modelo de navegação.

Figura 5 – Wireframe exemplo de sistema de navegação (clique na imagem para ampliar)

O que ficou claro nesta etapa de definição, é que a navegação deveria ser social, ou seja, ela deveria se utilizar de inteligência coletiva para apresentar uma navegação probabilística baseados nas estatísticas e dados de navegação dos outros usuários. Isso foi excepcionalmente aplicado no módulo chamado FLD, veja a Figura 6, no qual visa reduzir o tempo do usuário para achar a provável causa raiz de uma falha.

Figura 6 – Wireframe exemplo de navegação social baseada em estatísticas. As cores definem a ordem de navegação e a probabilidade da causa raíz (clique na imagem para ampliar)

Para melhorar a compreensão intuitiva das informações no sistema, foi definida a estratégia criativa de rótulos. Nessa estratégia, uma linguagem de comunicação baseada em rótulos não textuais foi definida para as principais telas. A finalidade era ocupar menos espaço possível para passar uma informação completa, e para isso um conjunto de símbolos e ícones foi pensado e desenhado. Veja a Figura 7.

Figura 7 – Wireframe Fleet Monitoring View. Demonstra a linguagem de símbolos e cores a-plicada para comunicar rapidamente as condições das aeronaves (clique na imagem para ampliar)

É através dos rótulos que os filtros e as informações são organizados. A linguagem se manteve consistente em todas as telas do sistema.

Nas entrevistas foram identificados os principais termos técnicos que necessitavam se manter presentes na linguagem dos rótulos. Portanto, foi definido o modelo de comunicação e relacionamento com os usuários. Conseguir falar a linguagem de cada tipo de usuário foi fundamental. Cada persona apresentou uma necessidade diferente de relacionamento e utilização do sistema. Para suprir isso, foi definido que o sistema de navegação e busca de informações tinha que ser personalizável pelos usuários. Veja a Figura 8.

Figura 8 – Wireframe Filtros para personalizar a navegação e a busca de informações. O sistema permite a opção de salvar os filtros aplicados para os próximos acessos (clique na imagem para ampliar)

Para determinado modo de visualização, modo lista ou modo mapa, foi definido um modelo de apresentação dos resultados. No modo lista, por exemplo, foi definido que em todos os momentos deveríamos apresentar as aeronaves com condições mais críticas de vôos. Veja a Figura 9.

Figura 9 – Wireframe Resultado de Busca no modo Lista. As aeronaves mais críticas continuam aparecendo mesmo sem ter relação direta com o termo buscado (clique na imagem para ampliar)

2.3.3    Especificação

Na etapa de especificação, todas as estratégias foram documentadas através sitemaps, fluxo de transações, wireframes, métricas de performance, plano de implementação e matriz de escopo.

Todos esses insumos geraram uma especificação completa de arquitetura de informação, com a finalidade de validar e formalizar o que seria implementado tanto com a Embraer como com o resto da equipe do projeto.

2.3.4    Validação das Estratégias

Em todos os momentos era mantido um diálogo constante entre os arquitetos de informação, analistas de negócio, analistas de requisitos, designers, para que todos participassem da construção da arquitetura de informação. Os principais insumos para o trabalho de arquitetura da informação foram os casos de uso do sistema desenvolvidos pelos analistas.

Após desenvolver as estratégias e especificá-las através de wireframes e diagramas, era necessário validá-las não só com a equipe, mas com todos os públicos de interesse.

Primeiramente foi verificada a viabilidade com a própria equipe do projeto, depois com os principais stakeholders da Embraer, depois foi realizado mais uma etapa de teste de usabilidade, mas agora com protótipos em papel. Para isso, os wireframes foram criados com grau de alta fidelidade. Nesse caso o arquiteto de informação tinha habilidades de designer, mas em algumas etapas os designers e o AI trabalharam juntos.

Em todo o processo de validação, o projeto contou com um consultor com vasta experiência em projetos RIA e marketing digital. Sua função foi avaliar se as estratégias e especificações seguiam os princípios de um bom projeto dessa natureza, ou seja, se não iam contra as heurísticas. A principal referência heurística usada por ele foi a da Adobe e suas referências para RIA.

Para classificação do grau de criticidade dos fatores encontrados na validação, foi utilizada a escala criada pelo Jocob Nielsen, dividida em:

• Grave: Barreira, impede o uso do sistema
• Alta: Obstáculo grave ao uso do sistema
• Média: Obstáculo médio ao uso do sistema
• Baixa: Problema cosmético

Depois da classificação, os problemas eram revistos e priorizados. Discutiam-se as formas de corrigir os problemas.

2.4    Tecnologia e Integração de Equipes

Com o resultado obtido das pesquisas e testes de Usabilidade e A.I., chegou-se a reafirmação de que deveria ser adotado no sistema o conceito de R.I.A. (Rich Internet Application)

Rich Internet Application foi um conceito lançado pela Macromedia para classificar projetos desenvolvidos em suas tecnologias Macromedia Flex e Macromedia Flash (ambos agora adquiridos pela Adobe). A proposta destas tecnologias é unificar o melhor da web e desktop, acrescentando valor à experiência do usuário através de uma navegação e interatividade mais rica.

O sistema foi planejado para o usuário chegar onde quiser com o menor número possível de cliques e subpáginas. Com a tecnologia empregada, isso foi possível, pois não há requisição no servidor para atualização da interface. Para muitas ações feitas no sistema, sempre são abertos janelas no lugar de outras páginas, o que facilita ao usuário sempre identificar o local em que ele está.

Para o desenvolvimento do projeto houve uma grande integração entre os profissionais da Embraer e Focusnetworks, que para tanto, foram selecionadas as seguintes tecnologias para aplicação no sistema:

• Adobe Flex Builder: é uma ferramenta de desenvolvimento baseada no Eclipse e possibilita a codificação inteligente, depuração passo a passo e design visual da interface. Um dos pré-requisitos de integração da interface era a linguagem de programação desenvolvida pelo cliente no back-end do sistema, que foi o Java. O Flex possui uma vasta gama de documentação e bibliotecas de desenvolvimento que viabilizaram esta integração.
• Subversion: em um projeto de tal complexidade, necessitando considerável número de profissionais, tanto da equipe de desenvolvimento da contratante como o da contratada, o subversion foi a solução encontrada. A proposta desta tecnologia é fazer o controle de versão dos arquivos do projeto, facilitando a integração das equipes e prevenindo possíveis problemas deste cenário através de várias ferramentas eficientes que possui para este controle.
• Framework Cairgorn: este framework trabalha sob o modelo de Design Patterns Singleton, e foi implementado no desenvolvimento do projeto. Sua arquitetura MVC facilitou no desenvolvimento do sistema e provou grande vantagem na integração dos dados na interface, divisão dos módulos do sistema pelas equipes e na produtividade, o que o torna uma ótima arquitetura para desenvolvimento em grandes projetos e times.
• Adobe Flash: ferramenta de desenvolvimento, animação e design de RIAs, facilitou no intermédio da integração entre as ferramentas da equipe de design e desenvolvimento na programação e vetorização de componentes de interface complexa.

Para a concepção dos protótipos do sistema foi utilizada a ferramenta Microsoft Visio, que ajudou os profissionais de AI a visualizar, explorar e comunicar informações e idéias dos protótipos. Em vez de imagens estáticas, foi possível criar protótipos que exibem dados e que são fáceis de atualizar, o que aumentou significativamente a produtividade.

Para a concepção do design e arte dos protótipos após aprovados, a equipe de design utilizou a ferramenta Adobe Photoshop, mundialmente reconhecida por seus recursos para concepção de arte digital e também por ser da mesma empresa desenvolvedora do Flash, o que facilitou na transação e integração dos trabalhos dos designers e desenvolvedores.

2.5    Dinâmica de Validação

A dinâmica para validação da interface provou a grande ênfase da Arquitetura da Informação na necessidade do envolvimento constante das equipes envolvidas.

Cada protótipo de interface planejado e definido pelo AI era validado pela equipe de desenvolvimento da empresa. Esta equipe tinha como objetivo validar a viabilização das funcionalidades que seriam implementadas na interface, sugerir novos meios e identificar outras opções que iriam facilitar a implementação do protótipo.

Após a validação da equipe de desenvolvimento, eram feitas reuniões com o cliente para apresentar os protótipos e discutir as funcionalidades. Após estas reuniões o ciclo era iniciado novamente (AI à equipe de desenvolvimento à cliente) até chegar numa especificação definitiva.

Estas etapas exigiram dos profissionais de AI habilidades e experiência de relacionamento, planejamento e análise para que fosse possível intermediar a dinâmica toda e chegar num resultado positivo. O gerente do projeto acompanhava e mediava todas as etapas, e trabalhou a questão dos prazos, custos e cultura interna da Embraer.

2.6    Implantação do Projeto

O objetivo da fase de implantação era garantir que todos os executáveis estavam de acordo com as especificações e que eles fossem implementados corretamente no ambiente da Embraer. Nessa etapa a equipe de Quality Assurance (QA) atuou intensivamente, inclusive comparando a navegação real com a navegação via wireframes em HTML.

De forma pró-ativa, parte da equipe de desenvolvimento da Focusnetworks foi internalizado no cliente para efetuar a integração tecnológica. Dessa forma foi garantida uma implantação integrada e mais prática.

Fora isso, a equipe internalizada cumpriu o papel de efetuar pequenos ajustes, tirar dúvidas, e validar com o cliente o projeto. O mais interessante a se observar nessa etapa é que não houve mudanças na arquitetura da informação, concretizando que a metodologia aplicada nas estratégias e especificações foi sucessiva.

3.    Comparativo Antes e Depois (Não Exaustivo)

Figura 10 - Comparativo Antes e Depois (clique na imagem para ampliar)

4.    Resultados

Como o projeto foi implantado recentemente, o mesmo ainda está na fase de avaliação. O objetivo dessa fase é aprender com as experiências do projeto para melhorar a qualidade das próximas atualizações.

Fez parte do escopo do projeto, a construção de manuais e bibliotecas para transferências de conhecimento à equipe responsável pela manutenção da plataforma AHEAD dentro da Embraer. Isso inclui as diretrizes de arquitetura da informação e design.

Apesar do sistema não estar em fase de produção, já foi possível efetuar uma pesquisa qualitativa prévia com usuários utilizando o sistema em ambiente de avaliação. Alguns pontos em comum foram destacados no resultado desta pesquisa:

• A identificação das aeronaves por status de vôo através da utilização de iconografia facilitou a visualização do panorama da frota;
• A maior ênfase nas aeronaves com mensagens críticas e acesso mais rápido a estas mensagens ajudou muito na produtividade e no tempo perdido em solo;
• O usuário se localiza facilmente na interface;
• Com a aplicação do bloco de notas interativo no processo de troubleshooting (FLD), foi possível transferir um método eficaz utilizado pelos usuários de forma impressa para o meio eletrônico, o que foi facilitou muito a resolução das falhas e busca de informações técnicas;
• Houve grande satisfação dos usuários em relação ao feedback da interface aos seus inputs, pois realmente ele sentiram significante melhora na experiência de utilização do sistema;
• Houve uma grande compreensão das informações, identificação dos dados (utilização inteligente de cores e ícones). O sistema ficou realmente mais intuitivo.

Depois de implementado o sistema, aplicando conceitos de usabilidade e AI, colaboradores de outras equipes de projeto da Embraer, inclusive os da mesma equipe deste projeto, deram atenção aos benefícios de se adotar esta metodologia e começaram a levantar soluções para os outros sistemas que possuem. A idéia é seguir o mesmo case do projeto AHEAD.

Foi dada maior atenção a terceirização dessas soluções, visto que ficou provado que estes problemas são melhor solucionados por empresas que possuem o foco e expertise para tal.