Todos que têm alguma experiência com Arquitetura de Informação e/ou Design de Interface sabem o quão difícil é planejar e documentar uma interface para comunicar as especificações à equipe de desenvolvimento. O fato é que esta documentação por vezes é difícil compreensão por quem precisa lê-la e interpretá-la, por ser muito extensa e cansativa.
Longe de propor um modelo metodológico complexo, recheado de diferentes diagramas de textos de especificação (casos de uso, especificações funcionais, storyboards, etc), o modelo apresentado aqui é principalmente voltado para profissionais independentes e pequenas equipes de desenvolvimento, que necessitam uma documentação consistente, de fácil compreensão, mas, ao mesmo tempo, técnica o suficiente.

1º passo: Sitemaps – Macro-arquitetura de Informação

Não há como fugir deste tipo de diagrama. Os sitemaps, elaborados durante a etapa de planejamento, assemelham-se ao formato de organogramas e sua função é definir a hierarquia, os níveis, a estrutura e a interligação entre páginas, sinalizando também os caminhos de navegação e elucidando a organização lógica entre as páginas e seções. A esta tarefa é comumente atribuído o nome de Macro-arquitetura de Informação e que pode ser elaborada conjuntamente com o cliente. O problema é que, em muitos casos, estes documentos apenas indicam a estrutura de páginas que os usuários encontrarão. O ideal é possuir também um sitemap com a estrutura de diretórios do site, informando onde encontrarão, por exemplo, diretório de imagens, scripts, códigos reutilizáveis (includes), entre outros, sendo diferente do mapa do site convencional. Ambos os documentos ajudam novos integrantes a se localizar e encontrar mais facilmente os caminhos de navegação e arquivos específicos, servindo também como referência para quem trabalha no projeto há mais tempo.

2º passo: Diagramas de Interface

Partindo do princípio de que imagens falam mais do que palavras, estes diagramas ajudam a ter uma visão objetiva da estrutura da interface, disposição dos elementos e da Arquitetura de Informação propriamente dita.

São subdivididos em três diagramas que compõem três camadas e são ligeiramente baseados no diagramas de camadas de Jesse James Garrett:

1ª camada – Wireframes: para muitos, eles já são conhecidos. Desenvolvidos também durante a etapa de planejamento, eles não especificam o design gráfico, mas são responsáveis por representar a organização e a distribuição dos elementos de interface de acordo com a relevância e o relacionamento entre os conteúdos. São fundamentais tanto para a documentação como para orientar os designers, programadores e testers durante todas as etapas de desenvolvimento, além de prover ao cliente uma visão de como a aplicação estará estruturada.

2ª camada – Diagramas Estruturais: produzidos já durante a etapa de desenvolvimento, estes diagramas são como verdadeiros esqueletos do site, ideais para indicar a estrutura física dos documentos, incluindo medidas, dimensões, tipos de elementos HTML de cada componente, nome de seletores CSS aplicados, etc. É o diagrama que possui menor número de detalhes dos elementos de interface, entretanto, é o que possui maior objetividade em termos de especificação técnica e grande capacidade de orientação nas tarefas de desenvolvimento, manutenção e treinamento.

3ª camada – Diagramas estruturais preenchidos: opcionais, são baseados nos Diagramas Estruturais, mas possuem também algumas definições de cores e bordas, indicando o valor das mesmas.

Esta metodologia, livremente baseada em alguns aspectos do artigo de Garrett Dimon, não é absoluta nem definitiva, mas com certeza oferece um bom embasamento sobre uma prática que começa a ganhar um destaque maior entre os designers de interface. Produzi um exemplo, baseado no documento da Information & Design, que pode ser adaptado livremente e possui os exemplos citados acima (com exceção do Diagrama Estrutural preenchido).
Para concluir esta parte da série, podemos dizer que documentações densas e detalhadamente explanadas tornam-se necessárias em dois momentos:

- Quando há uma grande equipe de desenvolvimento e/ou alto grau de multidisciplinaridade;
- Quando o software/website é complexo e necessita descrever adequadamente os diversos componentes da interface, evoluções, problemas, correções, compatibilidade, dúvidas e respostas freqüentes, padrões e convenções de interface, entre outros fatores, a fim de evitar ambigüidades, incoerências, dúvidas e falta de sincronia durante o desenvolvimento.

Muitas vezes, um documento que se prolonga demasiadamente em suas especificações tende a não se tornar útil, pois não facilita a busca de informações práticas e objetivas. Para quem desenvolve uma documentação deste porte sem a total necessidade, isto torna-se uma experiência traumática.

No próximo artigo, irei abordar um padrão para documentação de código, o CSSDoc.

Artigo original: Webdesign Experience: Por que documentar uma interface? - parte II