16º Simpósio Nacional de Geometria Descritiva e Desenho Técnico

V International Conference on Graphics Engineering for Arts and Design

Santa Cruz do Sul, RS - Brasil - 08 - 11 Setembro de 2003

UM MÉTODO DE WEB DESIGN BASEADO EM

USABILIDADE
Maria Laura Martinez1
Universidade de São Paulo, Brasil
Departamento de Jornalismo e Editoração - Escola de Comunicações e Artes
Departamento de Sistemas Eletrônicos - Escola Politécnica

RESUMO

Como atestam numerosos estudos de usabilidade, perde-se muito com web

sites mal feitos. Pode parecer fácil desenvolver um web site: qualquer um
com ferramentas modernas de edição HTML pode publicar informação.
Contudo, fazer um site eficiente e profissional, que realmente atenda ao
usuário, é uma tarefa complexa. A Web introduziu uma complexidade nova
para a usabilidade nunca vista antes no software tradicional. A usabilidade
em web sites é uma área importante, em plena expansão, com características
particulares que dificultam sua pesquisa. Este artigo apresenta um método
para desenvolvimento de web sites baseado em engenharia de usabilidade,
tema central da tese da autora. O método aborda o web design respeitando a
percepção do usuário, otimizando a comunicação e atingindo o público de
forma mais eficiente.

Palavras Chaves: Web design; usabilidade; metodologia; engenharia de

software.

ABSTRACT

As demonstrated by numerous usability studies, a lot is lost with poorly

developed web sites. It seems to be easy to develop a web site: anyone with
modern HTML edition tools can publish information. However to make an
efficient and professional site is a complex task. The Web introduced a new
complexity for the usability, never seen before in traditional software. Web
site usability is an important growing research area with particular
characteristics that make its study difficult. This paper presents a method for
web sites development based on usability engineering, central subject of the
author's thesis. The method approaches web design respecting the user's
perception, optimizing the communication and reaching the public in a more
efficient way.

Key-words: Web design; usability; methodology; software engineering.

1
E-mail: martinez@lsi.usp.br
1 Introdução
A palavra design abrange mais do que a idéia da representação pictórica ou de leiaute
gráfico. Engloba todo o processo no qual se insere a representação ou o
desenvolvimento do leiaute, processo este que não pode ser dissociado do elemento
humano que o concebe, que o produz ou que se relaciona com o seu resultado.
1.1 O problema
A HTML é uma linguagem de descrição de páginas e não de programação, o que a torna
relativamente fácil de utilizar. Hoje existem ferramentas que permitem compor com
facilidade páginas Web, sem necessidade de se conhecer o código. Estas ferramentas,
apesar de permitirem a produção de páginas simples, muitas vezes dificultam a
implementação de um leiaute mais elaborado, impedindo ao designer, desconhecedor
da HTML, ter um controle maior do visual da sua obra. Outras vezes inserem um
grande volume de código espúrio, que aumenta o tamanho da página (em bytes) e torna
sua visualização mais lenta. Outras ainda, inserem código das últimas versões da
linguagem HTML, somente interpretado pelos browsers mais novos, prejudicando uma
parcela do público que ainda utiliza navegadores de versões mais antigas.
Por outro lado, saber fazer uma página ou um site não garante o sucesso na
comunicação da informação ou do uso da aplicação, como constataram diversos autores.
Conforme ROCHA (2000): "Dados disponíveis apontam que em 1998, cerca de três
bilhões de dólares deixaram de ser ganhos na Web norte-americana por causa de
design mal feito de páginas, que dificultava a compra em vez de facilitar.” [a IBM]
“...constatou que o recurso mais popular em seu site era a função de busca, porque as
pessoas não conseguiam descobrir como navegar, e o segundo mais popular era o
botão ajuda. A solução foi um amplo processo de redesign, envolvendo centenas de
pessoas e milhões de dólares. Resultado: na primeira semana depois do redesign, em
fevereiro de 1999, o uso do botão de ajuda caiu 84% enquanto as vendas aumentaram
400%.”
Para NIELSEN (1999), nem sempre o meio está sendo usado para facilitar a vida do
usuário e não é raro ver pessoas frustradas ou perdidas em sites mal feitos.
Sites mal projetados têm conseqüências de grande impacto que trazem perda de
dinheiro e de credibilidade. Sites comerciais perdem seus clientes frustrados, antes que
efetuem a compra. Leitores desnorteados em sites noticiosos o abandonam antes de
encontrar a informação procurada. Alunos em sites educacionais mal projetados não
conseguem atingir seus objetivos de aprendizagem. E pessoas frustradas migram com
facilidade ao site do concorrente, que está apenas a um clique do mouse.
A questão que surge é: como fazer um web site eficiente que realmente atenda ao
usuário?
1.2 A Usabilidade
A norma ISO 9241-11, define a usabilidade como: a efetividade, a eficiência e a
satisfação com que usuários específicos atingem objetivos específicos em ambientes
particulares.
Mesmo sendo um conceito conhecido desde a década de 80, somente nos últimos
anos a palavra 'usabilidade' começou a ser melhor investigada e tornou-se crítica com o
surgimento da Web. Conforme NIELSEN (1999), as conseqüências de uma interface
gráfica pobre em usabilidade são muito piores quando esta é implementada na Web do
que quando é implementada em software tradicional.
Curiosamente, apesar da Web ter popularizado a usabilidade, acrescentou-lhe novos
e grandes desafios. A Web constitui um novo meio de comunicação e tem uma

2
linguagem própria construída sobre um espaço hipermídia complexo, com
características particulares de acesso remoto a dados, publicação dinâmica de
informações, interfaces gráficas mutantes, velocidades de conexão variáveis, rápida
absorção de novidades tecnológicas, entre outras (MARTINEZ 2000).
Em projetos de software, a usabilidade é mais eficiente quando aplicada logo no
começo do ciclo de desenvolvimento. Os primeiros 10% do processo de design
determinam 90% do produto e é quando são tomadas as decisões-chave do projeto.
Conforme GILB (1988), não corrigir um problema de usabilidade na fase de design
custa 10 vezes mais se o sistema está em desenvolvimento e 100 vezes mais se o
sistema já foi lançado.
Entre as principais razões para adotar a usabilidade desde cedo em um projeto pode-
se citar: redução de erros e de procedimentos de correção; redução do tempo de
operação da interface; redução de custos de treinamento, de manutenção e de suporte ao
usuário e, como conseqüência, o aumento da eficiência e da efetividade da interface
para o seu público.
1.3 À procura de soluções
O processo genérico de desenvolvimento hipermídia, tem sido abordado por alguns
métodos como HDM: Hypertext Design Model (GARZOTTO, 1993), RMM:
Relationship Management Methodology (ISAKOWITZ, 1995) y OOHDM: Object-
Oriented Hypertext Design Model (SCHWABE, 1995). Estes métodos requerem que o
domínio a aplicação seja abstraído em forma de entidades (ou classes) e de relações e,
segundo LOWE (1999), tendem a ser mais prescritivos, no sentido em que guiam o
processo mas não fornecem indicações de como adaptá-lo aos diferentes domínios de
aplicação. Lowe et al. propõem um modelo de referência para o desenvolvimento
hipermídia que pode ser instanciado tanto como prescritivo quanto descritivo, no
sentido em que também descreve o processo.
MAYHEW (1999), apresenta um modelo descritivo do processo genérico de
desenvolvimento de software em Engenharia de usabilidade que consta de três etapas: a
análise de requisitos, o design/testes/desenvolvimento e a instalação. Mayhew faz
algumas breves observações sobre as possibilidades de aplicação do método para a Web,
mas estas não são desenvolvidas nem especializadas. Por outro lado, os outros métodos
de desenvolvimento de aplicações hipermídia, listados anteriormente, não são centrados
em usabilidade nem levam em conta as particularidades do processo de
desenvolvimento Web.
A seguir, são apresentadas as principais características do método de
desenvolvimento de web sites baseado em usabilidade proposto como tese da autora que
aperfeiçoa e enriquece o método publicado em MARTINEZ (2001).
O método foi utilizado e avaliado com sucesso no projeto do web site da Agência
Universitária de Notícias do curso de Jornalismo da USP2. Os resultados deste estudo de
caso (muito extensos para este artigo), estão documentados em MARTINEZ (2002).
O método estende e especializa para a Web o método de MAYHEW (1999). Adota o
ciclo estrela de HIX (1989), baseado em avaliação de usabilidade, pelo dinamismo e
maior flexibilidade que propicia a todo o processo. Por fim, baseia-se na experiência da
autora no desenvolvimento de web sites, área na qual trabalha desde 1995.
2 O método
O diagrama da figura 1, a seguir, apresenta o método proposto. Os retângulos
representam as tarefas, ou módulos, do ciclo de Engenharia de Usabilidade. As setas
representam a ordem mais provável de realização de tarefas. Algumas das seqüências de
2
http://www.lsi.usp.br/aun

3
tarefas são iterativas e os lugares onde estas iterações normalmente ocorrem são
representados por setas pontilhadas retornando a pontos anteriores do ciclo de vida.
No método proposto, os principais grupos foram rotulados por um retângulo
deformado em onda (e.g. 'Análise de Requisitos', 'Especificação de Conteúdo',
'Especificação de Layout', e assim por diante).
A seta pontilhada na horizontal, entre as etapas de Especificação de Conteúdo e de
Implementação indica um atalho para o projeto de web sites simples.
O método proposto distingue três etapas principais:
• o Planejamento (que contém a análise de requisitos, as especificações de conteúdo,
de leiaute gráfico, de implementação e de distribuição);
• a Implementação (que é formada pelo 'dadoduto' de implementação)
• a Distribuição. (que é formada pela publicação e pela divulgação)

Todas as etapas são permeadas e intermediadas por avaliação de usabilidade3.

melho-
[MARTINEZ,01] Distribuição rias
Análise de
Requisitos Planejamento Publicação Divulgação

Instalação e Estratégias
Análise Análise de Guidelines e
de Plataforma Princípios de configuração Estatísticas
Tarefas Cliente server-side
Webdesign Análise de Feedback
tudo
Sites similares Avaliação resolvido?
Perfil do Metas de
Usuário Usabilidade Análise tudo FEITO
funcional resolvido? Manutenção
Análise de
Guia necessidades Atend. público
de atende a todas as
funcionalidades?
Estilo
Especific.
Especific. Especific. distribuição Implementação
de conteúdo implement Guia
Especific. Restrições Prototipação de
Planejamento Análise acesso/ segu. Estilo
de layout client side e HTML
de Tarefas server side Estimativa Coleta e criação
Definição Padrões de Demanda e de conteúdo
de Metáforas de Design Restrições de Plataforma Preparação
Arquitetura da Tela implement. servidora dos dados
Informação Protótipo Guia Especifica
Armazena- Mapeam.Arquitet.
Gráfico de mento manutenção de Informação
Maquete Estilo
Guia Avaliação lógico
Avaliação de Especifica Lapidação
Estilo
Iterativa atendimento
Iterativa Avaliação
elimina atende Guia Estratégias
às metas de Iterativa
os principais de divulgação atende
defeitos? usabilidade?
Estilo às metas de
usabilidade?

Figura 1: As etapas do método proposto.

3 Breve descrição das etapas do método4
3.1 Análise de Requisitos
O objetivo da Análise de Requisitos é fazer o modelamento das metas de usabilidade
do web site, em função das análises do usuário, da aplicação e de princípios gerais de
web design.

3
Para uma descrição de técnicas de avaliação de usabilidade consultar (WINCKLER,1999),
(NIELSEN,1993), (RUBIN,1994), (IVORY,2001), (MAYHEW,1999) e (RAVDEN,1989).
4
Para informações mais detalhadas aconselha-se a consulta de MARTINEZ(2002).

4
 A realização de cada módulo do método é intermediada por algum tipo de avaliação,
muitas vezes embutida na própria técnica de execução.
Assim, a análise de perfil e de tarefas do usuário pode ser realizada através de
entrevistas, questionários, avaliações remotas ou testes em laboratório. A análise de
plataforma cliente é baseada no feedback do usuário fornecido em resposta a
questionários. O mesmo ocorre com a análise funcional e de necessidades da aplicação,
baseadas no conhecimento de especialistas e na análise de sites similares, baseada em
avaliação heurística e empírica dos mesmos. Recomendações e princípios de web
design, como as 10 heurísticas de NIELSEN (1994), são incorporados ao projeto e
também guiam a inspeção de usabilidade de sites similares. No fim desta etapa são
estabelecidas metas de usabilidade baseadas nos cinco atributos de NIELSEN (1993)5,
que guiam o restante do desenvolvimento.
Em projetos de web sites de grande porte, todas as decisões e resultados de cada
etapa do método devem ser incorporadas à documentação de um Guia de Estilo que dará
homogeneidade e consistência ao trabalho da equipe.
3.2 Especificação de conteúdo
A etapa de especificação de conteúdo preocupa-se em melhorar o modelo de tarefas do
usuário, incorporando as funcionalidades definidas anteriormente e tornando mais
eficientes suas práticas de trabalho. Preocupa-se também em aproximar ao seu modelo
mental (sobre como realizar tarefas), o modelo conceitual da aplicação que será definido
em termos da reengenharia de tarefas, da especificação de metáforas e de arquitetura de
informação.
No fim desta etapa obtém-se recomendações de alto nível sobre as funcionalidades
da aplicação, sobre a escolha de metáforas e sobre as informações das principais telas da
aplicação. Também obtém-se um esboço da rede de nós e links que forma o esqueleto
hipermídia do site.
Toda a Especificação de conteúdo é independente de plataforma cliente. As
metáforas são regras genéricas de apresentação, que consideram somente o nível mais
alto do design da interface. Somente na próxima etapa de Especificação de layout
gráfico, a interface receberá um design detalhado em sintonia com a análise de
plataforma cliente e com as metas de usabilidade.
A avaliação de usabilidade nesta etapa é feita sobre os esboços das telas e do
esqueleto hipermídia, procurando determinar se estão de acordo com as especificações
do guia de estilo e se os principais problemas conceituais foram eliminados. As técnicas
(e os critérios de avaliação) devem ser escolhidos em conformidade com o tipo de
projeto e suas necessidades.
3.3 Especificação de layout
A Web introduziu uma necessidade maior de imagem, diferenciação de mercado e
marcas corporativas do que no software tradicional.
Alguns autores (como BLACK,1997), apontam que uma página na Web deve se
parecer a um outdoor de estrada no sentido em que deve conseguir brevemente
comunicar sua mensagem e deixar sua marca ('a apenas um olhar') quando o usuário
está de passagem. Isto porque usuários são infrequentes, têm muitas opções e,
normalmente, pouco tempo para explorá-las.
A habilidade de se trabalhar a imagem desta forma não é comumente encontrada em
Designers de Interface de Usuário, nem em Engenheiros de Usabilidade. Designers

5
São eles: facilidade de aprendizagem, eficiência de uso, facilidade de memorização, baixa taxa de
erros e satisfação subjetiva.

5
gráficos são mais qualificados para trabalhar a comunicação através da imagem e definir
a apresentação visual dos modelos de trabalho, o que torna sua participação
fundamental nesta etapa do projeto.
Esta etapa basicamente se preocupa em definir como será a apresentação gráfica da
aplicação, em sintonia com os resultados da análise de plataforma cliente (e.g. resolução
da tela em pixels, resolução de cor, fator gama das plataformas, entre outros), de acordo
com as metáforas escolhidas e com os tipos de telas definidos durante a arquitetura de
informação.
O resultado é um conjunto de protótipos gráficos dos principais tipos de páginas do
site, que podem ser desenhados com editores de imagens.
Somente na atividade de 'Implementação', as páginas serão prototipadas em HTML e
os protótipos gráficos, desenvolvidos nesta etapa, serão utilizados posteriormente para
gerar as imagens (geralmente GIFs), que comporão as telas.
Para interfaces simples e que não precisam de um tratamento gráfico diferenciado,
não há necessidade da prototipação gráfica utilizando um editor de imagens, pode-se
passar diretamente para a prototipação HTML que caracteriza a atividade de
Implementação.
A definição de padrões de design de tela, é refinada iterativamente a partir de
avaliação de usabilidade.
3.4 Especificação de implementação
Antes da implementação do site planejado nas etapas anteriores, é necessário tomar
decisões que fazem grande diferença para o sucesso do desenvolvimento. Elas são
relacionadas à lógica do armazenamento dos arquivos em disco (a organização dos
mesmos em diretórios e subdiretórios e a definição de regras para seus nomes), às
restrições de implementação e às soluções do lado do cliente e do lado do servidor
(client-side e server-side), a ser adotadas.
As restrições de implementação, são muito importantes para garantir o bom
funcionamento do sistema em diferentes plataformas cliente, atendendo às diversas
demandas de desempenho. Estas podem ser elaboradas com a ajuda de um especialista
em web design e conhecedor das tecnologias online. São algumas delas: restrições ao
formato e tamanho dos arquivos, ao armazenamento em cache (definidas pela data de
validade do conteúdo), e à forma de referenciar os links (de forma absoluta ou relativa).
Soluções do lado do cliente e do lado do servidor (client-side e server-side), devem
ser escolhidas cuidadosamente para garantir o bom funcionamento da aplicação online.
Programas JavaScript ou Applets são essencialmente executados do lado do cliente,
assim como plug-ins; enquanto programas CGI, API's, middlewares (como PHP ou
ASP) e Sistemas Gerenciadores de Banco de Gados são executados do lado do servidor.
Quando um programa muito solicitado é executado do lado do servidor pode
sobrecarregar o processamento da máquina ou ainda comprometer a segurança do
sistema. Por outro lado, um programa projetado para rodar do lado do cliente pode não
encontrar as condições adequadas para ser processado naquela plataforma.
3.5 Especificação de distribuição
Nesta etapa devem ser definidas: as restrições de acesso e segurança, como será feita a
manutenção, o atendimento ao usuário e as estratégias de divulgação que deverão ser
adotadas.
Em web sites nos quais se espera grande tráfego, também deve ser feita uma
estimativa de demanda do sistema no lado do servidor. Isto permite fazer uma seleção
adequada da plataforma servidora a partir da qual será distribuído o web site e adotar
estratégias que diminuam a sobrecarga de processamento. Na estimativa de demanda

6
deve-se analisar que programas rodam simultaneamente, quantos usuários simultâneos
se espera na pior situação de uso e quais as exigências de desempenho impostas por este
processamento, estabelecendo o quanto de degradação de performance poderá ser
admitida.
As restrições de acesso e segurança permitirão garantir a correta distribuição do
conteúdo. Podem ser elaboradas com a ajuda de especialistas em segurança na Internet e
devem atender às outras especificações do projeto. A especificação destas restrições é
utilizada na configuração do servidor Web, na implementação de programas de bloqueio
de acesso, de encriptação de dados ou de filtros para robots (i.e. programas indexadores
dos mecanismos de busca).
Normalmente ao se publicar um site se esquece da importância de manter as
informações atualizadas e do atendimento ao público... e muitos sites que têm potencial
para sucesso acabam falindo. Por isto é importante de antemão definir estratégias para
abordar estas duas questões.
Na Internet existem milhões de web sites e esse número cresce com o tempo. Um
site a mais não terá visibilidade a não ser que adote algumas estratégias simples de
divulgação para sua distribuição. São alguns exemplos: solicitar a catalogação por
mecanismos de busca, divulgar sua existência através de listas de e-mail, colocar links
em outros sites visíveis (conhecidos) para o web site em questão, inserir meta-tags de
palavras chave e descrição de conteúdo nas páginas HTML, participar de concursos de
web sites conhecidos pelo público e divulgados pela mídia, ou ainda, utilizar os métodos
tradicionais de divulgação como TV, radio, outdoors.
3.6 Implementação
Esta atividade depende das decisões de projeto tomadas na etapa anterior. Pode ocorrer
que, durante a implementação, se encontrem falhas no projeto inicial e este tenha que
ser modificado novamente, seguindo a liberdade de se movimentar no ciclo estrela.
Quanto melhor seja feito o projeto inicial, menor o tempo que deverá ser gasto durante
esta etapa.
Implementação
Coleta e
criação
de conteúdo
Dados Iniciais

Preparação
dos dados
Dados
Mapeamento Derivados
da Arquitetura de
Informação WSA /
Protótipo
HTML
Avaliação
Lapidação
Iterativa
Protótipo
HTML
Avaliação
Iterativa

Figura 2: O dadoduto para a atividade de Implementação.

Uma vez coletado ou criado um dado, ele passará por uma seqüência de etapas, de
transformações e relacionamentos, que o prepara para sua publicação. Observa-se a
formação de um duto de dados (que será chamado de 'dadoduto'6) que se inicia com sua
coleta e termina com a implementação do protótipo HTML, conforme esquematizado
pela figura 2, anterior. A identificação do dadoduto permite um melhor gerenciamento
dos recursos do projeto e da equipe, conforme é explicado adiante.

6
Termo 'emprestado' da área de visualização científica: 'pipeline' ou 'dadoduto'.

7
 As funcionalidades são implementadas em camadas (primeiro as mais prioritárias) e
cada funcionalidade pode ser refinada passando mais de uma vez através do dadoduto.
Na implementação de web sites podem ser identificados alguns níveis característicos
de passagem pelo dadoduto, que foram representados na figura 3, a seguir.
No nível (a) são criados os templates HTML das páginas que são baseados nos
templates gráficos identificados na Especificação de conteúdo e desenhados na
Especificação de layout. Estes templates serão linkados conforme o esqueleto
hipermídia definido na etapa de Arquitetura de Informação. Obtém-se finalmente um
Web site Abstrato (WSA), ainda sem nenhum conteúdo de informação, formado pelos
templates das principais categorias de páginas que serão relacionados pela estrutura de
navegação definida pela Especificação de conteúdo.
O nível (b) é seguido somente por sites que integram a publicação Web com
servidores de Banco de Dados (BD). Nele é implementado o modelo físico do BD
projetado durante a Especificação de implementação. Os programas middleware (que
fazem a 'ponte' entre o servidor Web e o de BD), são codificados e otimizados, e então
são relacionados ao esqueleto de templates HTML, desenvolvido no nível (a), anterior.
No fim obtém-se um WSA relacionado ao banco de dados, mas ainda sem conteúdo de
informação. Durante a avaliação iterativa, é verificado se os programas middleware
estão funcionando corretamente, introduzindo dados para teste.
nível (a) nível (b) nível (c)
• Templates Implementa:
Coleta e Coleta / Cria
Gráficos. • BD
criação conteúdo de
• Recorta GIFs • middleware
de conteúdo informação
• Codifica
Dados BD e
Iniciais Template Conteúdo
programas
HTML
Otimiza •Transforma
Preparação Otimiza código Otimiza / Trata
imagens e • Otimiza / Trata
dos dados middleware Conteúdo
HTML Conteúdo
Template
Dados HTML programas Conteúdo
Derivados Otimizado otimizados Otimizado
Associa Embute
Mapeamento Linka
código middleware Cadastra em
da Arquitetura Templates
aos templates no BD template
Informação WSA / HTML
HTML HTML
Protótipo
WSA Protótipo
HTML WSA
HTML
•Transformações
Lapidação de comunicação
•Ajuste fino
Protótipo Protótipo
HTML HTML
Templates Integração
linkados com BD Conteúdo

Figura 3: O dadoduto sendo aplicado em diferentes níveis.

No nível (c) o conteúdo de informação do web site é coletado, tratado e anexado aos
templates HTML. Este relacionamento entre conteúdo e páginas HTML pode ser feito
de forma direta (embutindo o conteúdo diretamente no código HTML dos templates) ou
de forma indireta (cadastrando o conteúdo no Banco de Dados, que fará a publicação
automática). No fim deste processo o web site passa pela lapidação onde são aplicadas
técnicas de visualização ou de design de informação 7 para melhor representar o
conteúdo e é feito o ajuste fino da diagramação (e.g. alinhamentos, espaçamentos, etc).
Finalmente obtém-se o protótipo HTML.
Durante a avaliação iterativa, são verificados os padrões de design de tela, se a
funcionalidade implementada nessa passagem pelo dadoduto está completa e operando,
se os links estão corretamente conectados, se foram utilizadas as restrições de
7
Técnicas de visualização ou design de informação podem ser encontradas em (BERTIN,1983)
(MACKINLAY,1986) (TUFT,1990) (ZIMMERMAN,1997) ou (JACOBSON,1999).

8
implementação definidas anteriormente e se o armazenamento lógico dos arquivos em
disco foi feito conforme especificado. No caso de integração com Banco de dados, deve
ser feito um teste de como um determinado template gerencia diferentes conteúdos (e.g.
como fica a aparência da página quando um campo textual inclui seu maior e seu menor
texto).
3.6.1 A gerência dos recursos do projeto
A observação dos três níveis de passagem pelo dadoduto, permite gerenciar melhor os
recursos do projeto e da equipe.
Conforme mostra a figura 4, a seguir, pode ocorrer de se ter mais de um nível, sendo
implementado em paralelo. O eixo horizontal da figura representa as etapas do dadoduto
(tarefas) distribuídas no tempo. O eixo vertical à esquerda representa os três níveis
descritos anteriormente (a, b e c).
(tarefas no/ tempo)
ão
/ ra ç o to
eta pa ent en
col ção pre tam pe
am
tempo
cria tra ma

designer gráfico
templates linkados (a) & programador
programador
integração BD (b) & administrador

conteudista
conteúdo (c) & programador

níveis equipe
Figura 4: Distribuição no tempo de tarefas, níveis e equipe, permitida pelo dadoduto.
Percebe-se que no nível a tem-se basicamente tarefas de design gráfico e
codificação HTML e o mesmo pode ser executada por um designer gráfico e um
programador. Para desenvolver o nível b (i.e. implementar os bancos de dados e os
programas de integração) bastam as habilidades do programador e do administrador de
rede. No nível c, é importante o papel do conteudista (i.e. um especialista na aplicação)
que pode ser ajudado por um programador e um especialista em design de informação.
Os três níveis podem ser executados no tempo em paralelo, tomando o cuidado de
sincronizar as atividades. Por exemplo: os templates HTML do nível a já devem ter sido
finalizados quando os programas middleware do nível b estiverem sendo concluídos
(para que possam ser integrados).
Pode-se tirar vantagem das características do dadoduto principalmente ao se
desenvolver web sites que envolvem uma equipe de produção (i.e web sites médios e
grandes), de forma a gerenciar melhor a alocação dos recursos computacionais e de
equipe. Esta qualidade do dadoduto, não deve ser notada na produção de web sites
muito simples com um único desenvolvedor.
3.7 Distribuição
A distribuição é a terceira atividade do método e compreende a publicação (a
implantação do sistema) e a divulgação do site.
Durante a etapa de publicação o protótipo HTML final é colocado online. Para isto,
os arquivos são copiados para um diretório reconhecido pelo servidor Web, é feita a
configuração da plataforma servidora e são instalados e configurados os outros
programas server-side, como servidor FTP, programas que executam as restrições de
acesso e segurança (e.g. senhas), servidor Banco de Dados e programas middleware.
Ao se copiar os arquivos para baixo do servidor Web, podem ser introduzidos novos

9
problemas não detectados durante as avaliações de usabilidade feitas no fim da
implementação (sobre o protótipo rodando nas máquinas locais). Assim, é necessário
fazer uma nova avaliação local (checando se todos os links e as funcionalidades
implementadas estão operando corretamente e se as imagens e demais mídias estão
sendo carregadas) e outra remota (checando a velocidade de transmissão das páginas).
Durante a etapa de divulgação são executadas as estratégias definidas anteriormente
durante a Especificação de distribuição.
Algum tempo após executar as estratégias de divulgação do site é útil gerar
estatísticas de acesso para saber qual o retorno obtido, confirmando se as metas
definidas para a divulgação do site foram atingidas. Caso contrário, novas medidas de
publicidade devem ser adotadas. Existem muitos programas de domínio público que
fazem a análise estatística. Entre as medidas mais importantes das estatísticas de acesso,
estão os hits, pageviews sessões e usuários únicos8, mas também podem ser extraídas
outras informações como número médio de pedidos atendidos (e não atendidos) em um
dado período e o tráfego médio em bytes por período. Existem alguns problemas que
podem comprometer as estatísticas de acesso, em especial, o uso de cache pelo browser
e/ou pelo servidor de proxy.
Uma vez que esteja tudo resolvido, o web site está pronto para ser submetido aos
processos de manutenção e de atendimento ao usuário definidos anteriormente e que
serão repetidos durante toda a sua vida útil. O contato com o usuário tem que ser
incentivado. Um canal de comunicação bem atendido dá credibilidade ao web site e
permite identificar problemas novos ou que não tenham sido detectados anteriormente.
No fim, o web site implementa uma versão da aplicação ou um "protótipo pronto" ou
ainda uma camada de funcionalidades. Novas camadas do projeto anterior podem ser
implementadas em sucessivos ciclos de implementação / distribuição.
4 Conclusões
O método proposto se baseia e modifica aquele de usabilidade de [MAYHEW,00].
Introduz as análises funcional, de necessidades e de web sites similares, que fornecem
indicações de como adaptá-lo aos diferentes domínios de aplicação. Introduz a definição
de metáforas e a especificação da arquitetura de informação, que procuram definir e
organizar o conteúdo do site de forma consistente com o modelo mental do usuário.
Introduz o planejamento da implementação e da distribuição, fundamentais para prever
e evitar muitos dos problemas do desenvolvimento de web sites. Contribui com a idéia
de 'dadoduto' que estabelece etapas claras para o processo de implementação Web
permitindo a otimização da gerência do projeto. Também identifica processos
importantes no ciclo de publicação e introduz a etapa de divulgação, necessários para a
existência e a sobrevivência de um web site.
Muitos exemplos podem ser extraídos do estudo de caso em MARTINEZ(2002) e
fazem acreditar que o método tornou-se realmente um diferencial durante o ciclo de
desenvolvimento, conseguindo-se resultados que dificilmente teriam sido atingidos sem
ele. As reflexões levantadas durante este trabalho fazem acreditar que o método se
revela útil tanto para web sites complexos quanto simples. No entanto, para web sites
muito simples é necessário que se escolham atalhos e técnicas simplificadas, para não se
correr o risco de transformar o desenvolvimento em algo demorado e complicado além
do necessário. Técnicas como análise heurística e pequenos testes com usuários podem
ser muito reveladores para qualquer desenvolvedor, principalmente em projetos de
pequeno porte.

8
unique users

10
Agradecimentos
Ao LSI-Poli-USP e ao CJE-ECA-USP por todo o apoio. Em especial, ao Prof. João
Antônio Zuffo pela confiança, incentivo e orientação. Ao Prof. Proença, pela essencial
cooperação e pelo entusiasmo com que estimulou o estudo de caso. À Profa. Roseli de
Deus Lopes, ao Prof. Sérgio Leal e à Profa. Ana Magda pelo importante encorajamento
e colaboração. À Profa. Lúcia Filgueiras e aos colegas e mentores do ILCE (Instituto
Latinoamericano de la Comunicación Educativa) pelos valiosos ensinamentos. À OEA
pela bolsa que permitiu que fosse ao México realizar o curso no ILCE. Ao Prof. Romero
Tori e ao Prof. Eduardo Toledo Santos, pelas sugestões.

Referências
[1] BERTIN,J. Semiology of graphics. The University of Wisconsin Press, Madison,
Wisconsin, 1983.
[2] GARZOTTO,F.; PAOLINI,P.; SCHWABE,D. HDM: a model based approach to
hypermedia application design. ACM Transactions on Information Systems, 11(1):
pg.1-26. 1993.
[3] HIX,D; HARTSON,R. Human-computer interface development: concepts and systems for
Its management. ACM Computing Surveys 21(1): 5-92. 1989.
[4] ISAKOWITZ,T.; STOHR,E., BALASUBRAMANIAN,P. RMM: a methodology for
structured hypermedia design. Comm.of the ACM, V.38, N.8, pg.34-44. August, 1995.
[5] IVORY,M.Y.; HEARST,M.A. The state of the art in automating usability evaluation of
user interfaces. ACM Computing Surveys, V.33, N.4, pg.470-516. December, 2001.
[6] JACOBSON,R. editor. Information Design. The MIT Press, London, England. 1999. 357p.
[7] LOWE,D.B.; BUCKNELL,A.J.; WEBBY,R. Improving hypermidia development: a
reference model-based process assessment method. In: 10th. ACM Conference on
Hypertext and Hypermedia, Proceedings. Darmstat, Germany, pg.139-146. 1999.
[8] MACKINLAY,J. Automating the design of graphical presentations of relational
information, ACM Transactions on Graphics, v.5, n.2, pg.110-1, 1986.
[9] MARTINEZ,M.L. Usabilidade no design gráfico de Web sites. In: GRAPHICA'2000 III
International Conference on Graphics Engineering for Arts and Design & 14o Simpósio
Nacional de Geometria Descritiva e Desenho Técnico. Anais em CD-ROM, Ouro Preto -
MG - Brasil. Jun./2000.
[10] MARTINEZ,M.L. Un método de diseño Web basado en usabilidad para la
comunicación efectiva de la información. In: GRAPHICA'2001 IV International
Conference on Graphics Engineering for Arts and Design & 15o Simpósio Nacional de
Geometria Descritiva e Desenho Técnico. Anais em CD-ROM. São Paulo, SP, Brasil.
Nov./2001.
[11] MARTINEZ,M.L. Um método de webdesign baseado em usabilidade.
São Paulo, 2002. 301p. Tese (Doutorado) - Escola Politécnica. Universidade de São Paulo,
Brasil.
[12] MAYHEW,D.J. The usability engineering lifecycle (formerly managing the design of
the user interface). In: ACM CHI’98, Proceedings, 18-23, pg. 127-128. April, 1998.
[13] MAYHEW,D.J. The usability engineering lifecycle: a practitioner’s handbook for
user interface design. Morgan Kaufmann Publishers. Março, 1999.
[14] NIELSEN, J. Usability engineering. Academic Press Inc., Boston, USA. 1993.
[15] NIELSEN,J. Ten usability heuristics. In. NIELSEN,J.;MACK,R. (eds) Usability
inspection methods. New York, John Wiley & Sons, 1994.
http://www.useit.com/papers/heuristic/heuristic_list.htm.
[16] NIELSEN, Jacob. Web usability: past, present and future. 8/Ago. 1999.
http://webword.com/interviews/nielsen.html.
[17] RAVDEN,S.; JOHNSON,G. Evaluating usability of human-computer interfaces: a
practical method. Ellis Horwood Ltd., UK. 1989.

11
[18] ROCHA, H.V.; BARANAUSKAS,M.C.C. Design e avaliação das interfaces
humano-computador. 12ª Escola de Computação, São Paulo, IME-USP, 2000.
[19] RUBIN,J. Handbook of usability testing: how to plan, design and conduct effective
tests. John Wiley & Sons, Inc. 1994.
[20] SCHWABE,D.; ROSSI,G. The object-oriented hypermedia design model. . Comm.of
the ACM, V.38, N.8, pg. 45-46. August, 1995.
[21] TUFTE,E.R. Envisioning information. Graphics Press. May, 1990.
[22] WINCKLER,M.A.A. Proposta de uma metodologia para avaliação de usabilidade
de interfaces www. Porto Alegre, março de 1999. Dissertação (Mestrado) - Instituto de
Informática. Universidade Federal do Rio Grande do Sul.
[23] ZIMMERMAN,B.B. Applying Tufte’s principles of information design to creatin
effective Web sites. In: The 15th Annual International Conference on Computer
Documentation, Proceedings, pg.309-317. 1997.

12