Apresentação da aula

Gerenciando os processos do Projeto

Introdução

Atualmente a formação dos usuários está mais ligada ao fluxo de trabalho do que à tecnologia propriamente dita. Assim, projetos de sistemas interativos devem estar baseados em cuidadosas observações dos usuários no desempenho de suas tarefas, refinados por detalhadas análises de frequência e sequência de tarefas e validado por protótipos construídos desde os primeiros estágios e em seguida por testes de usabilidade e aceitação. Os projetos da atualidade devem acomodar as habilidades, objetivos e preferências dos usuários. Projetistas procuram interação direta com os usuários durante as fases de projeto, desenvolvimento e durante todo o ciclo de vida do sistema.

Em todo mundo, a Engenharia da Usabilidade tem se firmado como uma disciplina com práticas e padrões bem estabelecidos. Gerentes de projetos são convidados a adaptar as práticas apresentadas nesse capítulo de modo a adequá-las a seus orçamentos, cronogramas e estrutura organizacional. Entretanto, é importante que as empresas deem apoio organizacional à usabilidade. Esse ponto é importante visto que as empresas dão muito mais importância aos processos de engenharia de software que aos de usabilidade.

Também discutiremos os três pilares sobre os quais o processo de desenvolvimento de sistemas interativos se assenta:

1. Um documento de guidelines para o processo propriamente dito;
2. Ferramentas de software para o desenvolvimento de interface;
3. A revisão de especialistas e os testes de usabilidade.

Apoio organizacional à usabilidade

Quando os dois produtos possuem funcionalidades semelhantes, a da usabilidade passa a ser o principal critério de comparação. Assim aquele que tiver usabilidade superior tem vantagem. Cientes disso, muitas empresas desenvolvedoras de software criaram laboratórios de usabilidade que são utilizados para revisão de especialistas e na condução de testes de usabilidade.

Especialistas de fora do projeto podem fornecer observações importantes e enriquecedoras, enquanto os testes de usabilidade realizados nas principais tarefas do domínio de aplicação implementadas em um sistema de computação são muito importantes para o entendimento de performance dos futuros usuários.

Mesmo em empresas de pequeno porte é aconselhável a existência de um pequeno grupo especializado em técnicas de projeto e teste tanto de interface como de usabilidade.

Em trabalho na IBM, Karat (1990) aponta ganhos de até cem dólares a cada dólar investido em usabilidade. Karat também identificou ganhos na redução do tempo de desenvolvimento do software, redução nos custos de manutenção, aumento de lucratividade devido a satisfação do cliente, além do aumento da produtividade e eficiência do usuário.

Para Shneiderman a atividade de projetar sistemas interativos é inerentemente criativa e imprevisível. Projetistas de sistemas interativos misturam conhecimento extenso sobre o que é possível ser desenvolvido com um “senso estético místico sobre o que atrai o usuário”.

Carroll e Rosson (1985) caracterizam o projeto como:

• um processo, ele não é um estado nem pode ser adequadamente representado estaticamente;
• “não-hierárquico”, não é nem “top-down” nem “bottom-up”;
• um processo radicalmente transformacional, envolve o desenvolvimento de soluções parciais e provisórias que podem, ao final de contas, não ter nenhum papel no projeto final;
• intrinsecamente envolve a descoberta de novos objetivos.

Essas características tornam o processo de desenvolvimento de sistemas interativos complicado em gerenciamento. Orçamentos e prazos podem facilmente serem comprometidos. Portanto, a alta administração das empresas, precisam primeiro se tornar cientes dos benefícios dos investimentos em usabilidade para em seguida apoiar as iniciativas a respeito.

Os três pilares do projeto

Os três pilares descritos abaixo foram propostos por (SHNEIDERMAN E PLAISANT (2005)) com o intuito de ajudar o projetista a “tornar boas ideias em sistemas de sucesso”. Para o autor, o uso da técnica sozinha não garante o sucesso do projeto, mas, como veremos a seguir, ela está baseada em projetos e pesquisas quem obtiveram sucesso no passado.

Guidelines e processos

Antes de mais nada, o grupo de desenvolvimento deve elaborar um documento contendo guidelines, ou seja, orientações que devem guiar todos os projetistas da organização. Um dos motivos pelos quais a Apple tem sucesso é a existência de um conjunto de princípios nos quais todos os desenvolveres devem seguir, o que assegurou a harmonia no design de todas as aplicações do sistema. Os guidelines da Microsoft tem sido refinados por anos e servem também como ferramenta educacional para os programadores que queiram desenvolver na plataforma.

Cada projeto tem necessidades distintas, mas guidelines devem considerar:

Palavras e ícones

• Terminologias (objetos e ações), abreviações, e em que circunstâncias usar letras maiúsculas;
• Tipo e tamanho de fonte e estilos (negrito, itálico e sublinhado);
• Ícones, gráficos e espessura das linhas;
• Uso de cores, inclusive cores de fundo, uso de recursos como realces e trocas de cores (piscando).

Leiautes de telas

• Seleção de menus, preenchimento de formulários e formatos de caixas de diálogos;
• Como as mensagens de erro e feedback serão construídas;
• Margens, alinhamento e espaços em branco;
• Entrada e apresentação de dados para itens e listas;
• Formatação de cabeçalhos e rodapés.

Dispositivos de entrada e saída

• Teclados, tela, controle de cursos e dispositivos de apontamento;
• Sons, feedback de voz, toque, gestos e outros modos de entrada especiais;
• Tempos de resposta para diversos tipos de tarefa.

Sequências de ação

• Clicar, arrastar e soltar ou gesticular;
• Sintaxe de comando, semântica e sequências;
• Teclas de função programáveis;
• Procedimentos de recuperação de erros.

Treinamento

• Ajuda on-line e tutoriais;
• Materiais de treinamento e de referência.

SHNEIDERMAN e PLAISANT (2005) advoga que o processo de criação dos guidelines deve ganhar visibilidade e apoio na organização. Guidelines controversas, como quando se utilizar de alerta de voz, deve ser revisto por outros colegas e testado empiricamente.

Esses documentos devem estar em constante estado de adequação, devem ser refinados para se adaptar às novas necessidades e às experiências acumuladas através do uso.

Ferramentas de software de apoio ao desenvolvimento da interface

Uma das dificuldades no projeto de sistemas interativos encontra-se no fato de que clientes e usuários normalmente não têm ideia de como o sistema ficará até que ele esteja pronto. Alguns sistemas apresentam avanços em diversas áreas e os usuários podem não entender os impactos de determinadas decisões de projeto. Em geral, as mudanças são muito mais complicadas e caras quando implementadas em estágios mais avançados do projeto.

A questão ainda não está totalmente resolvida, mas alguns problemas podem ser evitados se usuários e clientes tiverem uma visão realística do sistema ainda em seus estágios iniciais. Felizmente, atualmente existem uma pletora de ferramentas de prototipagem onde podemos construir telas, menus, formulários, simular cliques de mouse, etc.

Projetistas são aconselhados a se utilizarem desses recursos e envolverem os clientes no processo de projeto, obtendo deles o “aceite” dos protótipos antes que esses sejam encaminhados para a programação.

Na figura acima temos um protótipo de um programa feito no aplicativo Pencil (gratuito). Os “balões” em azul mostram como a interação acontecerá. Obviamente existem outros aplicativos que já permitem alguma interação do usuário com o sistema. Entretanto, vale a pena ressaltar que todos projetos tem orçamentos e que devemos encontrar equilíbrio entre o tamanho do esforço empregado na construção dos protótipos. Assim, utilizando uma ferramenta como o Pencil podemos construir protótipos rapidamente e a baixo custo. Isso além de aumentar a produtividade, fazendo com que o projetista possa construir mais protótipos diferentes ou mais versões de um mesmo protótipo.

Revisão de especialistas e testes de usabilidade

Produtores de espetáculos de teatro sabem que antes da estréia devem fazer ensaios onde todos as personagens vestem com as suas fantasias e o palco está montado exatamente da forma em que estará no primeiro dia de espetáculo. Projetistas de aeronaves testam seus protótipos em túneis de vento e em programas de computador que simulam com o máximo de precisão as mais diversas condições que o aparelho vai encontrar no mundo real.

Da mesma forma, projetistas de sistemas interativos devem realizar muitos pequenos testes piloto e além de alguns testes completos. Esses testes devem envolver usuários representativos e pessoas especialistas nas tarefas contidas no escopo do sistema.

Existe uma variedade de métodos de revisão a serem empregados com os usuários especialistas, dentre os quais podemos citar:

• Avaliação Heurística. Os revisores fazem uma crítica da interface a fim de determinar sua conformidade com uma lista de heurísticas de projeto semelhantes às oito regras de ouro. Faz uma enorme diferença se os revisores são familiarizados com as regras e se são capazes de interpretá-las e aplicá-las.
• Revisão das guidelines. Nesse tipo de revisão, a interface é checada com relação à sua conformidade com o documento de guidelines.
• Inspeção de consistência. Aqui os especialistas verificam a consistência da interface com relação às demais aplicações da organização, checando terminologia, cores, leiaute, formatos de entrada e apresentação de dados etc. Essa inspeção envolve não somente o sistema, mas também os materiais de treinamento e ajuda online.
• Passo a passo cognitivo (Cognitive Walkthrough). Esse tipo de inspeção, os especialistas testam a interface passo a passo enquanto realizam as tarefas mais importantes do sistema, principalmente aquelas de maior frequência. Simulações de erros e das rotinas de recuperação deles também são realizadas.
• Inspeção formal de usabilidade. Nessa técnica, os participantes se reúnem como se fossem julgar a interface. Existe a figura do moderador ou “juiz” que apresenta a interface e discute seus méritos e fraquezas. A equipe do projeto pode contestar a apresentação do julgador. Esse tipo de inspeção tem um apelo educacional.

Após resistência inicial, gerentes começam a entender os benefícios dos testes de usabilidade e já colocam esses testes nos cronogramas de seus projetos. Grandes empresas de computação possuem laboratórios de usabilidade. A IBM, por exemplo, possui uma elaborada instalação na Flórida com 16 laboratórios de usabilidade dispostos em formato circular e com um prédio central que abriga um banco de dados que armazena dados relativos ao uso e performance de usuários em experimentos relacionados à usabilidade.

Normalmente testes de usabilidade compreendem uma lista de tarefas, um questionário que serve para medir o nível de satisfação do usuário acrescido de perguntas que ajudam o projetista/pesquisador a entender a experiência vivida pelo usuário durante a execução das atividades previstas no teste. Deve-se pedir permissão por escrito dos usuários para filma-los durante a execução das tarefas. Nessa filmagem devemos utilizar várias câmeras posicionadas de maneira a capturar aspectos de denunciem situações como frustração, dificuldade, satisfação, etc. Para isso câmeras devem focar rosto, braços e campo de trabalho. Para ajudar no trabalho de análise dos testes, é válido pedir ao usuário que pense em voz alta, o chamado método think aloud.

É igualmente importante que se tenha dados quantitativos de performance dos usuários com relação à execução das tarefas listadas nos testes. Esses dados podem ser comparados aos qualitativos (descritos no parágrafo acima). Quando os dados qualitativos são coerentes com os quantitativos, as conclusões da avaliação ficam mais consolidadas, pois se sabe que o usuário estava sendo sincero em durante a entrevista. Os dados qualitativos ajudam o projetista a entender como o sistema impactou a forma de realizar cada uma das tarefas e o que pode levar a ajustes na interface na busca por melhores números. Dentre os dados quantitativos podemos listar os seguintes:

• Tempo que os usuários levam para aprender determinadas funções;
• Tempo que os usuários levam para executar cada uma das tarefas elencadas no teste;
• Taxas de erros na execução das tarefas do teste;
• Grau de satisfação do usuário com o uso do sistema.

Metodologias de desenvolvimento

Introdução

SHNEIDERMAN e PLAISANT (2005) estima que cerca de sessenta porcento dos projetos fracassam dos quais vinte e cinco porcento deles nunca terminam enquanto os outros trinta e cinco alcançam apenas sucesso parcial. Uma abordagem de desenvolvimento que leve considere as questões de usabilidade desde os estágios iniciais do projeto resultam em diminuição dramática de custos de desenvolvimento e manutenção. Tais abordagens produzem sistemas mais fáceis de se aprender e de se utilizar, aumentam a produtividade e diminuem as taxas de erro.

Metodologias de engenharia de software como a UML tem-se se mostrado úteis para que projetistas e gerentes mantenham seus projetos dentro dos prazos e orçamentos estimados. Entretanto, nem sempre fornecem guidelines úteis à construção de interfaces de qualidade.

Várias metodologias de projetos focadas no projeto de interfaces foram propostas, como Hix e Hartson (1993) e Nielsen (1994). A título de ilustração detalharemos a metodologia Logical User-Center design proposta por Kreitzberg (1996). Ela identifica seis estágios no processo de desenvolvimento de sistemas interativos. Tais estágios estão abaixo listados.

Estágio 1: Desenvolvimento do conceito do produto

• Propor conceito de alto nível;
• Estabelecer objetivos de negócio;
• Montar equipe de usabilidade;
• Identificar população de usuários;
• Levantar questões de âmbito técnico e ambiental;
• Propor plano envolvendo recursos humanos, cronograma e orçamento.

Estágio 2: Pesquisa e análise das necessidades

• Dividir o grupo usuários em subgrupos homogêneos;
• Dividir as atividades de trabalho em unidades de tarefa;
• Conduzir análise de necessidades através da construção de cenários e do projeto participativo;
• Propor o primeiro rascunho do fluxo de trabalho e sequência de tarefas;
• Identificar os objetivos principais e estruturas que serão utilizadas da construção da interface;
• Pesquisar e resolver questões técnicas e outras limitações relativas ao projeto.

Estágio 3: Conceitos de projeto e protótipos de telas-chave

• Propor critérios de usabilidade específicos baseados nas necessidades dos usuários;
• Iniciar a construção do documento de guidelines e de estilo;
• Identificar o conjunto de “telas-chave”, como: login, tela de entrada e telas dos principais processos;
• Desenvolver protótipos das telas-chave utilizando-se de ferramenta de prototipação rápida;
• Conduzir revisões iniciais e testes de usabilidade.

Estágio 4: Refinamento do projeto através de iterações

• Expanda os protótipos das telas-chave e programe-as;
• Conduza revisões heurísticas e revisões de especialistas;
• Conduza testes de usabilidade completos;
• Entregue protótipos e especificação para programação.

Estágio 5: Implemente o sistema

• Utilize-se de padrões;
• Administre mudanças tardias nos requerimentos;
• Desenvolva help online, manuais e tutoriais;

Estágio 6: Apoie o processo de implantação

• Forneça suporte e treinamento;
• Realize manutenção, mantenha histórico de utilização.

Técnicas mais comuns

Observação etnográfica

Praticamente todas as metodologias incluem a observação de usuários em seu ambiente de trabalho como um dos passos iniciais no processo de construção de sistemas interativos. Para esses usuários, trabalhar em uma organização e em um lugar e em uma época acabam constituindo uma cultura única. Por esse motivo métodos etnográficos de observação tendem a se tornar cada vez mais importantes. “Um etnógrafo participa, de modo explícito ou não, no cotidiano das pessoas por um período extenso de tempo, observando o que acontece, ouvindo o que é falado e fazendo perguntas”, Hammersley e Atkinson (2007). Como etnográficos, projetistas de interface ganham entendimento sobre o comportamento individual e o contexto organizacional.

O trabalho desses projetistas se diferencia do etnógrafo tradicional porque eles observam as interfaces em uso com o propósito de melhorá-la ou de construir algo inteiramente novo. Enquanto etnógrafos tradicionais entram em um processo de imersão na cultura, o que normalmente leva semanas ou meses, projetistas de interface limitam esse tempo para dias ou mesmo horas e mesmo assim ainda conseguem obter informações necessárias ao seu ofício. Métodos etnográficos já foram empregados em observações realizadas em escritório, controle de tráfego aéreo e em vários outros domínios.

Essa atividade também precisa de guidelines para diminuir as possibilidades de serem feitas observações irrelevantes ou que se deixe de perceber detalhes que devam ser considerados. ROSE et al. (1995) elaborou uma série de guidelines com objetivo de tornar o processo de observação etnográfica mais produtivo, as quais transcrevemos a seguir:

Preparação

• Entenda as políticas e cultura da organização;
• Familiarize-se com o sistema de informática e sua história;
• Proponha objetivos iniciais da observação e prepare questionário da pesquisa;
• Obtenha permissão para observar e entrevistar.

Estudo de Campo

• Estabeleça bom relacionamento com gerentes e usuários;
• Observe e/ou entreviste usuários em seu ambiente de trabalho e colete dados qualitativos e quantitativos;
• Investigue com mais profundidade pistas que tenha emergido das entrevistas;
• Grave todas as visitas e entrevistas.

Análise

• Compile os dados obtidos em bancos de dados numéricos, textuais e de multimedia;
• Quantifique os dados e realize testes estatísticos;
• Interprete os resultados dos testes estatísticos;
• Refine seus objetivos à luz dos resultados dos resultados de sua análise.

Divulgação dos resultados

• Considere relatar os achados de sua pesquisa para várias audiências;
• Prepare relatórios e apresente resultados.

À primeira vista esses guidelines parecem óbvios, mas segui-los requer dos projetistas atenção ao interpretar cada situação. A título de exemplo, um gerente pode reclamar que seus funcionários não preenchem o formulário de controle de atividades. Já os funcionários se queixam que o tal preenchimento é muito trabalhoso e leva tempo preenchê-lo.

Projeto participativo

É fácil entender por que devemos envolver os usuários nas várias fases dos projetos de sistemas interativos. Um maior envolvimento resulta em informações mais precisas acerca das tarefas pertencentes ao escopo do sistema, mais oportunidades para que eles influenciem nas decisões de projeto, facilita o processo de aceitação do sistema e aumenta a sensação de que o projeto também é deles.

A questão que se levanta é até onde esse envolvimento deve ir. Se for muito extenso, encarece o projeto e aumenta o tempo de execução. Outro potencial problema é que as pessoas que não estão envolvidas no processo podem oferecer resistência ao sistema. A participação de usuários incompetentes pode gerar interfaces de baixa qualidade uma vez que o projetista fica tentado a satisfazê-los. 

Uma das metodologias mais tradicionais de projeto de interfaces participativo é o chamado Plastic Interface for Collaborative Technology Initiative through Video Exploration (PICTIVE) de Muller (1992). Nessa abordagem, usuários usam cartolina, etiquetas ou fitas adesivas para construir um protótipo de baixa fidelidade. A cartolina é a tela em branco sobre a qual os próprios usuários vão criando os objetos que nela aparecerão. Com etiquetas e/ou fitas pode-se construir botões e outros objetos de interação.

Os usuários, após concordarem em como a interação será feita, fazem um vídeo deles mesmos interagindo com o protótipo. Segundo Muller, sob liderança adequada, a metodologia promove o surgimento de novas e interessantes formas de interação e os usuários “se divertem” com esse tipo de trabalho.

É importante lembrar que os usuários devem se comprometer com o projeto, com uma agenda de reuniões sistemáticas e, principalmente com a necessidade de se honrar prazos. Como normalmente são profissionais de outras áreas, provavelmente estão lotados em outros departamentos e possuem outras obrigações.

Desenvolvimento baseado em cenários

Nessa prática, bastante utilizada nos dias de hoje durante o processo de elicitação de requisitos. Na construção dos cenários descrevemos situações em que os usuários se utilizarão recursos fornecidos pelo sistema para resolver situações encontradas no dia a dia de suas atividades. Quando possível e especialmente quando no cenário envolve mais de um ator e um processo de colaboração entre eles, é aconselhável criar um pequeno teatro e “executar” a atividade conjunta.

Além dos usuários-chave, esses “teatrinhos” devem ser encenados nos locais de trabalho para que os atores possam utilizar o espaço e os objetos normalmente empregados na execução das tarefas encenadas, por exemplo: Recepção de hotéis, laboratórios de análises clínicas etc. Os cenários podem representar situações normais ou emergenciais. Pode-se construir cenários descrevendo a utilização do sistema por usuários novatos e outro cenário onde a mesma atividade é executada por um usuário experiente.

Impacto social

A introdução de sistemas interativos normalmente causa enorme impacto não somente nas organizações, mas também nas vidas das pessoas que as fazem. A fim de minimizar os riscos associados ao seu desenvolvimento e implantação, é interessante que se produza um documento bastante bem fundamentado antecipando os impactos que o sistema deve causar para que seja apresentado aos tomadores de decisão das empresas. A circulação desse documento, além de ser uma medida preventiva, pode elicitar sugestões produtivas por parte desse grupo. Essas sugestões podem levar a correções de rumo ainda em uma fase inicial do projeto, o que é bem mais barato do que em fases mais adiantadas.

Shneiderman e Rose (1997) sugerem um roteiro para a construção do documento de impacto social, transcrito abaixo:

Descreva o novo sistema e seus benefícios

• Transmita os objetivos de alto nível do novo sistema;
• Identifique os stakeholders;
• Identifique os benefícios específicos.

Aborde preocupações e potenciais barreiras

• Antecipe mudanças em funções de trabalho e potenciais demissões;
• Aborde questões relacionadas a segurança e privacidade;
• Discuta responsabilidades por mal uso e falha do sistema;
• Evite julgamentos direcionados;
• Discuta direitos individuais e benefícios sociais;
• Avalie questões acerca de até que ponto sistemas devem ser centralizados ou descentralizados;
• Preserve princípios democráticos;
• Assegure acessibilidade;
• Mantenha a simplicidade e preserve o que funciona

Descreva o processo de desenvolvimento

• Apresente uma estimativa de cronograma para o projeto;
• Proponha um processo de tomada de decisão;
• Discuta como será o envolvimento dos stakeholders;
• Reorganize as necessidades de aumento de pessoal, treinamento e equipamento;
• Proponha plano para backups de dados e equipamentos;
• Proponha um plano de migração para o novo sistema;
• Proponha um plano para medir o sucesso do novo sistema.

Fim da aula.