Guias de estilo: ações

As atividades abaixo são relacionadas à criação das especificações dos guias de estilo de mídias digitais:

■ Verificar se a criação do guia de estilos será feita por um núcleo centralizado de profissionais que emana soluções para uma equipe ampla ou se será desenvolvido de maneira descentralizada por um conjunto designado da equipe para essa tarefa.

A criação sistemática de guias de estilos em equipe tem aumentado muito nos últimos anos. A Google mantem um grupo de designers num comitê responsável pelas especificações e sua atualização em caráter permanente.

Comissões de designers podem estar relacionadas a diferentes produtos da mesma empresa, e sua articulação ajuda a legitimar a relevância das plataformas utilizadas e das linhas comerciais presentes, bem como a diminuir as soluções arbitrárias tomadas por pessoas/equipes isoladas, e a divulgar as soluções adotadas para todas os profissionais diretamente envolvidos no dia a dia.

■ Agrupar e selecionar informações sobre a atualização e a produção de conteúdo produzidas nos registros de projeto e nas decisões tomadas em reuniões ou via emails e conversas.

■ Criar e atualizar gradual e constantemente as especificações ao longo do projeto, para documentar todas as decisões sobre a atualização do conteúdo tomadas em cada etapa.

É comum os colaboradores acharem, durante o projeto, que parar o trabalho para escrever especificações é perda de tempo. Mas algum tempo depois do lançamento do projeto, estas informações se revelam uma fonte valiosa de referências práticas para a tomada de decisões em situações novas.

■ Inventariar todo o material produzido durante o projeto e o produto antes de ser lançado, para dispor de uma visão geral das questões a abordar.

Na criação do documento é importante:

◊ Considerar as características e funções do público que vai consultar e usar a documentação. Algumas pessoas preferem um formato “como fazer”, mais pragmático, simples de seguir. Outros demandam explicações mais detalhadas sobre configurações técnicas e sobre o funcionamento do sistema. Para atendê-los, eventualmente pode ser necessário escrever um documento para a equipe técnica e outro para a equipe editorial, que têm necessidades e perfis bastante diferentes.

Caso a equipe seja segmentada em diversas funções, é preciso segmentar os assuntos, para que contemplem gestores, designers, programadores, editores, de maneira direcionada.

◊ Estruturar o texto em pequenos módulos, mais fáceis de redigir, consultar e atualizar, bem como de reutilizar em outros módulos. Textos em tom coloquial mas não muito informal, não comprometem a confiança no conteúdo.

◊ Usar linguagem simples e clara, sem jargões, mesmo para o público especializado. A cada primeira vez que uma sigla for citada, esta deve ser inteiramente descrita por extenso.

As especificações dos guias de estilo devem ser compreendidas para que seu público as compreenda. Caso precisem ser seguidas em caráter obrigatório, os verbos devem ser usados no infinitivo ou no imperativo. Caso sejam opcionais, podem ser usadas no condicional: “Podem ser usados marcadores para sinalizar os itens de uma lista”.

(No caso do presente texto, o infinitivo foi usado para manter a consistência em relação ao restante do site, não com caráter “imperativo”)

A linguagem deve procurar ser neutra em relação à criada durante a realização do projeto, sem uso de termos de reconhecimento restrito, pois estes com o tempo serão esquecida e/ou reinventados.

◊ Em documentos com mais de 10 páginas, incluir um índice, para que o usuário encontre rapidamente o assunto de seu interesse.

◊ Incluir exemplos e imagens para facilitar a compreensão dos conceitos. Exemplos, analogias e exposição de casos ilustrados por imagens (em gráficos, tabelas), facilitam a demonstração de procedimentos, a compreensão das informações e aumentam o interesse do leitor.

◊ Não nomear explicitamente os responsáveis pelos processos descritos, mas os departamentos a que pertencem, seus cargos. Da mesma forma, ao citar informações de contato, é melhor prover o email geral de um departamento, ou apresentar uma página com formulário de contato.

■ Realizar diversas revisões antes da publicação. Embora esta atividade possa parecer evidente, é muitas vezes negligenciada. Diversas revisões aumentam a qualidade do texto, reduzem a incidência de erros de digitação e aumentam as chances das informações serem úteis para quem as consulta.

Neste processo de releitura, é importante o redator se colocar no lugar de quem está lendo as especificações, ou então consultar um futuro leitor para verificar as suas reações ao ler o texto.

■ Distribuir o arquivo impresso em formato de uso universal não editável (PDF, por exemplo). No caso de um ambiente participativo, a publicação de um wiki que possa ser sempre atualizado funciona em conjunto com a versão inicial impressa ou em PDF, para o registro das melhores práticas que vão aos poucos sendo implementadas no veículo ou ambiente web.

■ Preparar a equipe para aplicar e revisar as especificações. Uma apresentação presencial, com reuniões e discussões, é tão necessária quanto a disseminação do documento escrito.

■ Designar o(s) responsável(eis) pela atualização e distribuição das especificações, em que a atualização do guia de estilos é parte das suas atribuições cotidianas formais, para:

◊ Realizar a alteração dos documentos, quando necessário.

◊ Adaptá-los a novas situações e necessidades, de acordo com seus próprios critérios ou o de um conselho designado especialmente para isto

Caso as especificações sejam publicadas em wiki, a atualização é colaborativa e a responsabilidade é compartilhada pelos integrantes da equipe de atualização e suporte.

■ Integrar o guia de estilos aos processos diários de manutenção evolutiva e atualização, o que é uma tarefa bastante difícil, pois a maioria dos documentos permanece esquecido, mesmo que publicado online e atualizado regularmente.

■ Criar um documento com opiniões/anotações sobre alterações estruturais para uma reestruturação futura mais abrangente do canal. Quando algumas situações demandam a realização de alterações estruturais no projeto, que não podem ser implementadas devido à sua abrangência, devem ser registradas para consideração em um futuro projeto de redesenho.

Outras atividades da elaboração das especificações

■ Consultar outros manuais ou especificações editoriais e de layout, para avaliar os tópicos abordados e o modo de tratamento do conteúdo. A consulta é um trabalho crítico e referencial que ajuda o aperfeiçoamento do produto.

■ Apresentar formalmente as especificações iniciais para o público interno, para que todos os integrantes da equipe (mesmo os que não lerem as especificações) tenham conhecimento dos seus aspectos mais importantes.

■ Se o guia de estilo for feito por empresa externa, combinar como será a participação da equipe interna de atualização e suporte na sua elaboração e aprovação. Quanto maior a atuação da equipe interna, mais chances do manual ser realmente utilizado e atualizado.

■ Propor uma lista de itens a desenvolver nas especificações e submeter esta lista aos clientes internos, para evitar o desenvolvimento de conteúdo desnecessário.

■ Entrevistar as equipes de atualização de conteúdo, desenvolvimento de interfaces e serviços, manutenção e atendimento ao cliente e gestores, para examinar suas dúvidas e demandas em relação ao manual.

■ Deixar alguns aspectos abertos para que a equipe interna tome decisões de acordo com as circunstâncias. Isto permite que as pessoas façam as coisas certas caso encontrem circunstâncias imprevistas no manual.

■ Atualizar o veículo automaticamente quando as especificações forem alteradas, ou seja, se um botão tem a cor/fonte alterada, mudanças no guia de estilos engendram mudanças automáticas no site ou aplicativo.

■ Publicar o guia de estilo para o público aberto, de modo a que fique visível a política de manutenção da qualidade e permanente aperfeiçoamento do produto.

■ Estabelecer procedimentos para o arquivamento das especificações antigas, para que todos os colaboradores envolvidos no site possam acessá-las, no caso de haver necessidade de avaliar sua evolução ao longo do tempo.

(Atualizado em 15.5.2015)
 

 

Referências

→ Team models for scaling a design system, Nathan Curtis (User Interface Engeneering, acesso em 25.9.2015)

→ Style guide best practices, Brad Frost (User Interface Engeneering, acesso em 15.5.2015) indica → Website Style Guide Resources. Demonstra também exemplos de produtos

→ 5 ways you can avoid FOMO when developing a website, Brittney Sheffield (Search Engine Watch, acesso em 4.9.2014)

→ 10 things to consider when creating policies, Scott Lowe (TechRepublic, acesso em 30.7.2012)

→ Tips for writing good documentation, Audrey Watters (ReadWriteWeb, acesso em 21.8.2010)

→ Help! User documentation that works, Georgina Laidlaw (SitePoint, acesso em 3.7.2010)