Luiz Feliphe Freitas Lavor
feliphelavor@gmail.com
Graduando em Engenharia de Produção pela Universidade Federal do Rio de Janeiro
Calandra Soluções

Graduando em Engenharia de Produção – UFRJ (formatura em outubro/2009). Certificado em Webdevelopment – Senac/RJ. Curso de Extensão “Empreendimentos para Indústria Criativa” – Saint Martin/Londres. Consultor de Negócios – Calandra Soluções – 1,5 anos (Rio de Janeiro/Brasil). Projetos em: Globo, BNDES, Governo do Rio de Janeiro. Atendimento de pós-venda em: Souza Cruz, Sabesp, Ipiranga, BNDES, Unimed. Trainee de Gerenciamento de Projetos – Brazilian Contemporary Arts – 1,5 anos (Londres/Inglaterra). Projetos no Barbican, The Cochrane Theatre, The Cadogan Hall. Trainee de Marketing – Aquapharm Chemicals – 6 meses (Pune, Índia). Pesquisa de mercado latino-americano. Estagiário de Marketing e Vendas – Dubas Música/Universal Music – 2 anos (Rio de Janeiro/Brasil)

Sumário

Em 2008 a Calandra Soluções, empresa de soluções para Gestão do Conhecimento sediada no Rio de Janeiro, desenvolveu um sistema interno de gestão de projetos que substituiu a ferramenta utilizada até então pela empresa. O foco da concepção dessa nova ferramenta foi a preocupação com modelo mental de seus funcionários e técnicas de interação para garantir a Usabilidade da solução. A equipe de desenvolvimento contou com um analista de negócio com formação acadêmica em Engenharia de Produção e experiência prévia em desenvolvimento web e conceitos de Usabilidade. Será observado como isso impactou em um visão focada na experiência do usuário desde as entrevistas iniciais junto aos usuários da solução e os resultados da experiência, após seis meses de utilização do sistema já implementado.

Palavras-chave

Usabilidade, Sistemas Corporativos, Engenharia de Produção, Modelos Mentais, Redes Sociais, Produtividade

1. Introdução

Desde a década de 60 o mundo corporativo observa o crescente avanço da utilização de ferramentas de tecnologia de informação apoiando os processos de seus negócios (Galitz, 2007). Um ciclo iniciado pela utilização das mainframes e cartões de comando, passando pelo desenvolvimento de ferramentas de MRP (Material Requirements Planning), CAD (Computer-Aided Design), ERP (Enterprise Resource Planning) e, finalmente, o SaaS (Software as a Service), a realidade é que os sistemas corporativos já permeiam dia-a-dia de grande parte dos funcionários de pequenas, médias e grandes empresas.

Tais sistemas, diferentemente de portais, sites e intranets, muitas vezes são desenvolvidos por profissionais sem conhecimentos práticos ou acadêmicos de design e usabilidade (James, 2007).

Isso é uma realidade, por exemplo, para os profissionais formados em Engenharia de Produção. Esta classe de engenheiros, frequentemente requisitada por consultorias de desenvolvimento de soluções corporativas, tem sua formação voltada para regras de negócio e indicadores de desempenho, sendo que por vezes a importância do bem estar cognitivo dos usuários dos sistemas desenvolvidos pode ser ignorada (Vidal, 2008). Até o momento a preocupação com Ergonomia para os Engenheiros de Produção normalmente encontra-se essencialmente limitada a fatores físicos, tornando restrito o número de profissionais dessa categoria capacitados para lidar com conceitos de Ergonomia Cognitiva.

Esse fato torna-se crítico ao se concluir que os Engenheiros de Produção participam intensivamente na elaboração de diversos sistemas gerenciais utilizados em empresas brasileiras (Quelhas, 2008). Essa omissão pode vir a acarretar em graves prejuízos na empresa para qual o sistema se destina, principalmente ao considerarmos o alto investimento necessário para o desenvolvimento de uma ferramenta de gestão corporativa.

Essa preocupação torna-se ainda mais importante no momento atual, em que muitas empresas estão substituindo sua primeira geração de sistemas gerenciais, desenvolvidas na década de 90 e sem preocupação com Usabilidade, por soluções novas, mais modernas e que inspirem uma utilização mais natural da informação (Black, 2002). Em suma, no momento que TI deixou de ser uma novidade para muitas organizações, o nível de exigência para as novas ferramentas a serem desenvolvidas será mais alto. Se o objetivo do Engenheiro de Produção é fazer uma organização produzir mais, melhor e em menos tempo, a Usabilidade é uma ciência fundamental para que esse objetivo possa ser alcançado. Isso porque será ela que viabilizará a utilização mais ágil da informação, matéria-prima fundamental da nova economia que se forma nesse início de século XXI (Howkins, 2002).

Esse estudo de caso mostrará o desenvolvimento de um sistema corporativo pela Calandra Soluções, que contou com um Engenheiro de Produção com conhecimentos de Usabilidade em sua equipe, e como isso impactou no resultado final do produto desenvolvido.

2. Usabilidade para todos os níveis hierárquicos

É notório o ganho que se tem em produtividade de uma equipe após a implementação de sistemas com alto grau de usabilidade (Marcus, 2008). Esse ganho advém de diversos fatores, como aumento de velocidade na execução de tarefas e quantidade de telas a serem acessadas para alcançar um determinado objetivo. Ao se multiplicar esses ganhos pelo tempo de trabalho total e pela quantidade de usuários de um sistema comprova-se que o ganho pode ser consideravelmente maior que os custos do investimento. Em um case produzido por Bias & Mayhew em 1994 (Marcus, 2008), uma empresa de TI investiu US$ 20.700,00 no redesign de uma de suas ferramentas internas, a fim de aumentar a usabilidade da mesma. A produtividade alcançada com a nova ferramenta já trouxe uma economia à empresa de US$ 41.700,00 no seu primeiro dia de utilização.

Se considerarmos os níveis hierárquicos da uma empresa observaremos que existem três tipos básicos de sistema: os sistemas transacionais, os gerenciais e os estratégicos (Laudon, 2004). Além da funcionalidade de cada um, outra diferença seria o volume de usuários: normalmente a quantidade de usuários de um sistema transacional é muito maior que a de usuários de um sistema estratégico, sendo que o do tipo gerencial ficaria no meio dessa escala. Porém, mesmo sendo menos usuários utilizando os sistemas estratégicos, esses formam o conjunto de mão-de-obra mais cara de uma empresa. Isso nos leva a concluir que aumentos (ou reduções) da produtividade em virtude da usabilidade do sistema é um ponto crucial para todos níveis da empresa, se consideramos o retorno (ou prejuízo) financeiro que isso resultará.

Figura 1: Retorno/Prejuízo decorrentes da usabilidade do sistema em todos os níveis da empresa (Fonte: o Autor)

Esse impacto da usabilidade nos três níveis de sistemas corporativos – Estratégicos, Táticos e Operacionais – justifica a preocupação com a experiência do usuário que deve existir no desenvolvimento desses sistemas. Também reafirma a importância de analistas de negócios, e não apenas desenvolvedores e webdesigners, possuírem conhecimento dessa necessidade e dos conceitos centrais de Usabilidade.

3. Central de Projetos Calandra: o projeto

Criada em 2003, resultado da fusão da ISM e da Newstorm, ambas empresas especialistas em Gestão de Conteúdo, a Calandra Soluções, localizada no Rio de Janeiro, vem se consolidando no mercado brasileiro de Gestão do Conhecimento. A empresa já possui mais de 200 projetos em seu histórico, possuindo atualmente uma carteira com cerca de 70 clientes.

Apesar de sua posição proeminente no mercado, a empresa possui uma equipe enxuta e composta em sua maioria de jovens, na configuração que Hayes (2004) descreve como “pessoas altamente qualificadas que trabalham juntas, porém em times semi-independente – às vezes compostos por representantes de diferentes áreas funcionais da empresa, portanto sob diferentes pessoas hierarquicamente“.

Por esse caráter flexível das equipes e pelos projetos envolverem basicamente esforço intelectual, e não ferramental, a empresa pertence ao grupo de corporações onde a passagem do conhecimento tácito para conhecimento explícito se faz mais importante (Takeuchi, 1995). Para atingir esse fim, a organização possuía um sistema web de gestão do conhecimento, onde os integrantes da equipe de consultoria deveriam diariamente reportar suas atividades nos projetos da empresa. Esperava-se assim formar uma base de conhecimento que pudesse, ao longo do tempo, montar o histórico da empresa e servir como um repositório de consulta para toda a equipe. As lições aprendidas seriam registradas naturalmente, assim como o esforço e o tempo necessários para cada tipo de tarefa, atividade e projeto.

Teoricamente o objetivo seria alcançado. Porém, conforme entrevistas junto à equipe da empresa, ele não estava sendo atingido basicamente por um motivo: o sistema era difícil de ser utilizado. Em outras palavras, faltava Usabilidade. Devido a isso muitos dos funcionários simplesmente não preenchiam o sistema, e os que preenchiam o faziam da maneira mais rápida possível, diminuindo assim a qualidade da informação.

Esse é o típico caso em que a falta de Usabilidade traz graves prejuízos para a organização:

1. Devido à dificuldade de utilização, grande parte do esforço de registro era inútil porque o preenchimento não era feito da forma correta, fazendo com que o objetivo de transformação de conhecimento tácito em conhecimento explícito não fosse alcançado;
2. Também devido à dificuldade, muito tempo era despendido pelos funcionários para o preenchimento, o que em última instância significava mais homem-hora utilizado e, consequentemente, maior valor financeiro despendido. O fato torna-se mais grave se consideramos que grande parte da informação era inútil, como visto no tópico anterior.

Tendo conhecimento desse fato a empresa decidiu reformular todo o seu sistema de report, dessa vez focando em Usabilidade, esperando assim melhorar a qualidade dos registros. Neste sentido, foi selecionado para analista de negócio responsável pela concepção conceitual do sistema um Engenheiro de Produção com conhecimentos prévios em Usabilidade e design de interfaces. A seguir será explicado como foi o processo de interações com os usuários e quais foram os resultados alcançados.

3.1. O desenvolvimento

Seguindo a metodologia de desenvolvimento adotada pela empresa, o projeto foi dividido nas etapas previstas pelo Unified Process (Jacobson, 1999), sendo elas:

• Concepção – estabelecer um entendimento comum entre os stakeholders em relação ao escopo e aos principais requisitos, viabilizar economicamente o projeto, produzir estimativas gerais para o custo e prazo do projeto e perceber os principais riscos deste;
• Elaboração – demonstrar que a arquitetura do sistema satisfaz às principais necessidades impostas e que é estável, produzir um cronograma realístico para o restante do projeto e eliminar os principais riscos remanescentes.
• Construção – construir e testar o produto de forma incremental e iterativa, revalidar o consenso entre os stakeholders com relação ao sistema e tentar otimizar custos e prazos.
• Transição – atingir níveis aceitáveis de qualidade operacional do sistema, transferir a responsabilidade sobre o sistema para o suporte e manutenção e avaliar e concluir o projeto.

Foram utilizadas nessas etapas diversas técnicas de interação com usuário, a fim de garantir a usabilidade na solução a ser desenvolvida.

A equipe de desenvolvimento foi composta por um desenvolvedor, um webdesigner e um Engenheiro de Produção com experiência em Usabilidade. Este último seria responsável por fazer a análise de negócio e, como explicado anteriormente, já possuía experiência prévia em conceitos de Usabilidade, para que sua comunicação com o webdesigner e o desenvolvedor fosse eficaz. A análise de negócio deveria ser feita voltada para a experiência do usuário.

3.1.1. O entendimento do Modelo Mental

A análise de negócio foi toda realizada a fim de que houvesse uma alta compreensão do modelo mental do usuário (Norman, 2002) por parte do analista de negócios. Para esse fim foi estipulado que seriam utilizados ao longo do processo de concepção do sistema os recursos: Focus Group, Entrevistas Individuais e Entrevistas Contextuais (Cybis, 2007).

Para os focus groups foram agendadas sessões de entrevistas para cada grupo funcional da empresa, onde foram coletadas as inconveniências do sistema anterior e as expectativas para o novo sistema, para cada área da organização. Nestas seções foram selecionadas pessoas que seriam posteriormente entrevistadas individualmente, tendo para isso os seguintes critérios:

• “Heavy users” do sistema;
• Pessoas com grande conhecimento os processos que deveriam ser executados através do sistema;
• Pessoas com perfil propício para serem multiplicadores de conhecimento, uma vez que o sistema estivesse pronto.

No geral apenas uma pessoa de cada área funcional foi entrevistada individualmente, além das entrevistas de focus group.

Após essas duas séries de entrevistas, focus e individuais, a equipe mapeou os processos executados no sistema, e também rascunhou a primeira versão da arquitetura de informação do projeto, de forma que todas as áreas funcionais pudessem utilizar a ferramenta de forma intuitiva. Buscou-se pensar em uma estrutura genérica, mas que ao mesmo tempo refletisse a terminologia e expressões utilizadas por cada área da empresa. Se houvesse novas propostas de funcionalidades elas seriam explicadas na fase de validação dos fluxos dos processos de trabalho. Se as equipes se sentissem a vontade com essas novas terminologias ela poderiam ser adotadas na ferramenta.

Com fluxos de trabalho validados, seguiu-se para as entrevistas contextuais, no ambiente de trabalho dos usuários. O objetivo foi acompanhar a utilização do sistema que seria substituído na execução dos processos levantados na fase anterior. As saídas dessas análises foram os principais problemas encontrados para execução das etapas dos processos traçados.

3.1.2. Requisitos Não-Funcionais e Usabilidade

Tendo um conhecimento maior do modelo mental dos usuários, e após documentados os processos de trabalho e as principais inconveniências do sistema utilizado pelos usuários, a equipe de desenvolvimento passou a levantar as alternativas para a nova ferramenta.

Na linguagem de software, Requisitos Não-Funcionais são as características que devem ser inerentes a todas as funcionalidades do sistema, como segurança e estabilidade (Sommerville, 1998). Foi definido que os requisitos não-funcionais a serem atendidos pela ferramenta deveriam ser a ponte entre o sistema que já existia e o modelo mental dos usuários. Como explicado anteriormente, a caracterização dos principais usuários da equipe como jovens e utilizadores intensivos de internet foi decisivo para direcionar os rumos do trabalho. Constatou-se uma forte apreciação do uso de redes sociais como Orkut e Facebook, e a equipe de desenvolvimento considerou a utilização dessa linguagem para redução de resistência por parte dos usuários, como forma de alinhar o modelo mental da ferramenta ao da equipe.

Iniciou-se uma pesquisa sobre os sistemas de redes sociais mais comumente utilizados, tentando identificar as características similares entre eles que talvez explicassem o seu sucesso entre jovens. As principais similaridades encontradas foram:

• Acesso personalizado: ao acessar o sistema o usuário observa sua tela pessoal, com informações relevantes para si próprio, não um ambiente genérico igual para todos.
• Feed/atualizações: todos os sistemas estudados trazem na tela inicial alterações de outras páginas que não a pessoal do usuário, mas que possam ser de interesse para ele, como mudanças nas páginas de amigos e atividades recentes em suas comunidades. O usuário não precisa ficar navegando de página em página para descobrir as últimas atualizações;
• Facilidade de colaboração: em todos os sistemas é fácil inserir novas informações para a rede social, como scraps, comentários e vídeos;
• Fácil acesso à página de contatos: em todos os sistemas o acesso às páginas de contatos (ou amigos) é simples e rápida;
• Ego/Auto-Estima: todos os sistemas se utilizam da vaidade do usuário, expondo informações como quantidade de amigos e avaliações pessoais.

Definiu-se que o sistema seria desenvolvido considerando essas características das redes sociais como requisitos não-funcionais. As metáforas, importantes para relacionar o produto ao modelo mental do usuário (Norman, 2002), seriam utilizadas para relacionar os recursos citados anteriormente às necessidades do sistema que estava sendo desenvolvido:

Tabela 1 – Metáforas “Redes Sociais” para sistema de gestão de projetos

3.1.3. Requisitos Funcionais e Usabilidade

Quanto aos requisitos funcionais, referentes às funcionalidades que o sistema deve ser capaz de executar (Sommerville, 1998), foram analisadas ferramentas já consagradas no mercado e idéias dos próprios analistas. Também foi tomado o cuidado para não inutilizar os recursos do sistema utilizado que agradavam os usuários. O objetivo era melhorar o que já existia.

O sistema utilizado como benchmark para o projeto foi o Highrise, produto oferecido pela empresa de SaaS 37Signals. Apesar de se tratar essencialmente de um sistema de CRM online, portanto com diferentes funcionalidades do sistema de report pretendido, considerou-se que a forma como o sistema apóia os seus requisitos funcionais seria um bom modelo para os requisitos funcionais desejados pela Calandra. Esses requisitos já tinham sido levantados na parte de mapeamento do fluxo de trabalho e análise de tarefas da equipe.

Figura 2: Exemplo de tela do Highrise (Fonte: 37Signal)

3.1.4. Os protótipos e Testes de Usabilidade

Com visibilidade melhor do que já existia no mercado para executar as funções pretendidas, e novas sugestões feitas pela equipe de desenvolvimento, o protótipo começou a ser construído.

Foi dada prioridade às tarefas mais corriqueiras dos usuários, sendo duas em destaque:

• O ato de reportar as atividades diárias, o que é feito por toda a equipe da empresa;
• O acompanhamento desses reports, feitos pelos gerentes táticos, de projeto e estratégicos da empresa.

Todos os protótipos elaborados, desde os de baixo nível (papel e wireframe) até os mais sofisticados (HTML’s funcionais) foram demonstrados para as mesmas equipes entrevistadas durante as sessões de focus groups. O design básico do primeiro protótipo foi basicamente totalmente reformulado pois, apesar da navegabilidade estar agradável, foi constatado que a visibilidade da alta gama de informações nas mesmas interfaces não estava muito clara. O fato dos protótipos serem mostrados desde o início do processo foram importantes para que esse erro não fosse enfrentado quando o projeto já estivesse muito avançado, reduzindo os custos da mudança.

Figura 3: Variação do valor dos testes de usabilidade ao longo do processo de desenvolvimento
(Fonte: TechSmith)

Figura 4: Primeira versão de interface básica do sistema (Fonte: Calandra Soluções)

Figura 8: Design de interface aprovado (Fonte: Calandra Soluções)

Com o design básico e o roteiro de navegação já aprovados, um protótipo mais abrangente foi desenvolvido. As principais funcionalidades executadas pela equipe já estavam presentes no sistema, assim como a base de dados que sustentaria a sua utilização.

A empresa decidiu liberar o sistema, ainda como teste, para uma área específica da empresa, no caso a equipe de Suporte. A área de Suporte precisou utilizar os dois sistemas, o antigo e o novo, em paralelo durante esse mês. Apesar do inconveniente para a equipe, os integrantes ficaram satisfeitos por estarem sendo pioneiros no lançamento do projeto e poderem participar ativamente dos ajustes finais da ferramenta. O que ajudou essa etapa foi o fato dos usuários se sentirem altamente envolvidos ao projeto, principalmente por terem participado do desenvolvimento desde as fases iniciais. Eles desenvolveram o sentimento de que o sistema estava sendo feito para eles, conforme suas necessidades, portanto não ofereceram muita resistência em utilizar os dois sistemas simultaneamente.

Durante esse mês mais algumas mudanças foram levantadas e rapidamente ajustadas, para que tudo estivesse pronto no lançamento oficial do sistema para toda a empresa. Por toda a preocupação em Usabilidade que guiou o desenvolvimento do sistema, quando ele foi finalmente lançado a mudança para sua utilização foi suave e eficaz.

3.2. Os resultados

No momento de elaboração desse estudo de caso o sistema já estava sendo utilizado há seis meses, sendo possível realizar uma prévia dos resultados alcançados após sua implementação. Os resultados serão analisados a partir de três perspectivas para o usuário final – Eficácia, Eficiência e Satisfação – e pelo ROI (Return On Investment) para a empresa.

Figura 6: Proposta de Métricas (Fonte: Sherman, 2006)

3.3.1. Eficácia, Eficiência e Satisfação

A fim de avaliar esses parâmetros da perspectiva dos usuários do sistema, foi repassado aos usuários do sistema um questionário com questões sobre eficácia, eficiência e satisfação ao utilizar ambos os sistemas, o antigo (Sistema A) e o novo (Sistema B). A seguir são listadas as questões, com seus respectivos resultados.

1) Parâmetro “EFICÁCIA”

Em uma escala gradual de 1 a 5, com 1 representando “Completamente Falso” e 5 “Completamente Verdadeiro”, como você classificaria as seguintes afirmações:

1. Consigo desempenhar as atividades às quais o Sistema A(antigo) se propõe de forma eficaz.
   

Figura 7: Resultado de pesquisa de “Eficácia”

b) Consigo desempenhar as atividades às quais o Sistema B (novo) se propõe de forma eficaz.

Figura 8: Resultado de pesquisa de “Eficácia”

Vemos que praticamente metade dos usuários classificou o sistema antigo como não eficaz ou indiferente, enquanto o segundo sistema foi classificado como eficaz por 97% dos usuários.

2) Parâmetro “EFICIÊNCIA”

Quanto tempo você demorava em média, proporcionalmente ao seu dia de trabalho (%), para preencher o sistema antigo? E quanto tempo em média demora no sistema atual?

Figura 9: Resultado de pesquisa de “Eficiência”

Vemos que houve um ganho de 1,12% em média do dia útil dos funcionários.

3) Parâmetro “SATISFAÇÃO”

Em uma escala gradual de 1 a 5, com 1 representando “Muito menos agradável” e 5 “Muito mais agradável”, como você compararia a utilização do sistema B (novo) em relação à utilização do sistema A (antigo)?

Figura 10: Resultado de pesquisa de “Satisfação”

Vemos que mais da metade dos usuários classificou o sistema novo como mais agradável de ser utilizado (60%), sendo que 40% o classificaram como “Muito mais agradável”. Nenhum dos entrevistados considerou-o menos agradável de ser utilizado.

Claramente houve uma considerável melhora da relação dos usuários com o sistema de report da empresa. Resta saber se o mesmo pode ser dito do retorno sobre o investimento, que será investigado no próximo tópico desse trabalho.

3.2.2. ROI: Retorno sobre o investimento

Por questões de segurança a empresa não forneceu os dados financeiros absolutos necessários para o cálculo de retorno financeiro sobre o investimento. Mas foi informado que a folha de pagamento da empresa referente à equipe de consultoria e desenvolvimento (quem de fato reporta suas atividades no sistema) corresponde a 80% de todos os custos da empresa. Se considerada a pesquisa anterior, que informa que os funcionários passaram a consumir 1,12% menos do seu tempo de trabalho reportando suas atividades, ao final do ano isso chega a representar uma economia de aproximadamente 1% do total de custos da empresa.

Além da redução de custos, é grande a possibilidade de aumento de produtividade da equipe de funcionários da empresa, pois a satisfação em utilizar o sistema aumentou consideravelmente e as informações registradas são de melhor qualidade se comparadas aos do sistema antigo, o que torna o esforço de passagem de conhecimento tácito para conhecimento explícito mais efetivo.

Por último, acredita-se que o sistema irá influenciar o aumento de faturamento da empresa também, pois os conceitos de usabilidade utilizados nele já estão influenciando na conquista de novos projetos para clientes externos. Como definido na escala de maturidade para Usabilidade Inuse, os conceitos de usabilidade passaram a permear outros processos da empresa além do desenvolvimento de sistemas propriamente dito.

4. Conclusão

Após estudar o processo de desenvolvimento adotado no estudo de caso deste trabalho, avaliando quantitativamente e qualitativamente os impactos da implementação da nova ferramenta na Calandra Soluções, é possível observar o impacto positivo de ter um analista de negócio, no caso da pesquisa um Engenheiro de Produção, também preocupado com a experiência do usuário em seu trabalho. Foi visto como um esforço ao longo de todo o projeto de desenvolvimento tende a aumentar a satisfação do usuário final e dos sponsors do projeto, visto os ganhos com produtividade alcançados após a implementação. Para que essa preocupação exista desde o início do projeto é de grande utilidade que o analista de negócio, muitas vezes o primeiro da equipe a se relacionar com os usuários finais do sistema, também possua conhecimento Usabilidade. Desta forma os testes se iniciam mais rapidamente no processo de desenvolvimento e o analista de negócio consegue dialogar mais facilmente com webdesigners e desenvolvedores da equipe, de forma que o sistema a ser concebido contemple mais fielmente ao modelo mental do usuário.

Espera-se que estudos desse tipo sejam cada vez mais freqüentes no ambiente de engenharia do mercado brasileiro, para que as ferramentas de TI desenvolvidas em nosso país possam de fato melhorar a eficiência de nossas empresas e que nossa produção tecnológica possa se tornar um player cada vez mais relevante no mercado internacional de soluções de informática.

5. Referências

Black, Jane. Usability Is Next to Profitability.
Disponível em: http://www.businessweek.com/technology/content/dec2002/tc2002124_2181.htm. Acessado em 12 de Fevereiro de 2009.

Cybis, Walter. Ergonomia e Usabilidade. São Paulo: Novatec, 2007.

Galitz, Wilbert. The Essential Guide to User Interface Design: an Introduction to GUI Design Principles and Techniques. São Francisco: Wiley, 2007.

Hayes, Robert. The Operations Edge: Strategy, Technology and Improvement. Nova York: Wiley, 2004.

Howkins, John. The Creative Economy. Londres: Penguin, 2002.

Jacobson, Ivar. The Unified Software Development Process. EUA: Addison-Wesley Professional, 1999.

James, Carol. User-centered Design Stories. Amsterdam: Elsevier, 2007.

Laudon, Kenneth. Laudon, Jane. Sistemas de Informação Gerenciais. São Paulo: Prentice Hall, 2004.

Marcus, Aaron. Return on Investment for Usable UI Design.
Disponível em: http://www.upassoc.org/usability_resources/usability_in_the_real_world/roi_of_usability.html. Acesso em: 27 de Junho de 2008.

Norman, Don. The Design of Everyday Things. Nova York: Basic Books, 2002.

Quelhas, Oswaldo. A Engenharia de Produção, eficiência e eficácia produtiva e a abordagem da sustentabilidade das organizações. Disponível em: http://www.abepro.org.br/interna.asp?un=755. Acessado em 10 de Fevereiro de 2009.

Sherman, Paul. Usability Success Stories : How Organizations Improve by Making Easier-to-use Software and Web Sites. Aldershot, Inglaterra, Burlington, VT: Gower, 2006.

Sommerville, I. e Kotonya, G. Requirements Engineering. EUA: Wiley, 1998.

Takeuchi, Hirotaka Takeuchi. The Knowledge-Creating Company. EUA: Oxford University Press, 1995.

Vidal, Carvalho. Ergonomia Cognitiva. Rio de Janeiro: Editora Virtual Científica, 2008.