TI Corporativa

Ξ 2 comentários

Imagens valem mais que mil palavras… será?

publicado por Sarah Siqueira

Houve um tempo em que eu produzia por volta de 60-80 páginas de documentação por semana. Eram páginas e mais páginas que descreviam reuniões de levantamento de escopo de software com clientes. Normalmente pessoas de várias nacionalidades, todas juntas numa sala de reunião debatendo “o que eu tenho hoje” versus “ o que nós podemos fazer por vocês”. O idioma eleito era quase sempre o inglês, embora apenas 10-15% dos presentes fossem nativos.

Agora, imaginem a quantidade de mal-entendidos que se pode gerar a partir de reuniões como estas? Pois é, por conta disto, a redatora técnica era convocada, e eu passava horas tomando nota, resumindo, construindo infográficos, tabelas, fluxos, ilustrações, enfim, tudo que pudesse auxiliar aquelas 50-60 pessoas a chegarem num consenso.

Naquelas circunstâncias, produzir uma ilustração, um gráfico que ilustrasse o processo de negócio do cliente, era praticamente obrigatório. Mesmo porque, impossível explicar todos os detalhes do business simplesmente com palavras.

Meus gráficos e ilustrações faziam muito sucesso, uma vez que meu background como desenhista facilitava o processo de captação das informações e conseqüente transformação delas em tabelas, desenhos e fluxos. Por conta delas fui chamada especificamente para cobrir reuniões de definição de escopo de projetos de tecnologia de ponta, como foi a implantação da portabilidade numérica em operadoras celulares norte-americanas.

Mas esse post não se presta a falar dos meus dotes como ilustradora. Ele pretende discutir até que ponto uma ilustração faz sentido em documentação. Tem gente que acredita que um bom manual precisa incluir cada uma das telas do software, ilustrar todos os ícones e botões, exibir todas as mensagens de erro em suas respectivas telinhas. Outros defendem que o usuário não precisa de nada disso e que devemos erradicar todo e qualquer tipo de ilustração num manual técnico.

Eu digo – sigamos o caminho do meio. Como em tudo na vida, o equilíbrio e o bom senso devem prevalecer. Eu já revisei documentos que continham, por exemplo, um screenshot da tela de login do software, mostrando que onde estava escrito “Nome”, o usuário deveria digitar seu username; e onde estava escrito “Senha”, o usuário deveria digitar sua password. Desnecessário dizer que eu marquei o texto todo, e a figura, para ser removido, certo? Qualquer usuário de internet que tenha uma conta de email sabe para que servem aqueles dois campos na tela de login.

É importante avaliar que um screenshot é um objeto estático na documentação. Todas as vezes que um campo mudar de nome, ou de posição, ou se cores forem alteradas, ou o tipo de letra, você deverá investir para que aquela ilustrção seja trocada. Sem falar nos processos de globalização, que exigirão de cada um dos tradutores que eles naveguem pelo sistema em sua língua natal e capturem os mesmos objetos do original – ou seja, a mudança de uma única tela pode significar muito, mas muito tempo e dinheiro gasto.

A mesma coisa vale para seus ícones preferidos. Aquelas pequenas ilustrações de lupas, binóculos, folhinhas de calendário, etc., definitivamente não precisam fazer parte do seu documento. Eles são ícones já aceitos pelo mercado, são ícones padrão – todo mundo sabe que a lupa é um ícone de busca, que o binóculo significa filtro e que a folhinha com números é um calendário.

Então, o que ilustrar? Em documentação técnica, menos é mais, sempre. Sua equipe de documentação deve ser orientada a ater-se àquilo que não é padrão de mercado; que façam fluxos dos procedimentos complexos e pouco usuais; ilustrem ícones diferentes e específicos do seu produto; ao invés de ilustrarem uma tela inteira para mostrar um pequeno campo, que façam “cortes” da tela e exibam com orgulho aquilo que somente seu software tem ou faz.

Não caia na armadilha do “uma imagem vale mais que mil palavras”. Elas podem falar mais do que deveriam…

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

Autor

Sou pós-graduada pela FGV em Gerência de TI. Já fui programadora, tradutora, revisora, e atualmente sou redatora técnica há mais de 11 anos. Aprendi inglês muito nova, e descobri a redação técnica meio que por acaso, através de um anúncio de multinacional que precisava de alguém que escrevesse bem em português e inglês e tivesse disponibilidade para viagens. Lá trabalhei por 7 anos, viajei por todos os continentes, aprimorei técnicas, e entrei em contato mais profundo com o ciclo de vida do desenvolvimento de software no Brasil. Hoje sou líder de desenvolvimento de informações na IBM, onde planejo os projetos de documentação do produto sob minha responsabilidde, desenvolvo conteúdo, reviso materiais, dou treinamentos, mentorizo equipes mais novas e auxilio no processo de globalização e de teste da interface com os usuários finais. Espero trazer a vocês bons insights sobre o mundo da documentação em TI.

Sarah Siqueira

Comentários

2 Comments

  • Prezada Sarah,

    Este é o terceiro tópico seguido que eu leio, de tua autoria, sobre documentação. É mais do que suficiente. Tu virastes a minha musa!

    Abraço,
    Rodrigo

    • Ahaha… “musa” é ótimo, Rodrigo…
      Venha sempre nos visitar, e comente!
      Profissionais de documentação como nós são muito poucos no país, e a minha “briga” sempre foi no sentido de criar uma cultura geral sobre o assunto. Sabe aquela coisa? As pessoas perguntam: “O que vocês faz?”, e eu respondo: “Sou redatora técnica.” Daí há sempre aquela pausa emblemática e por fim ninguém faz comentário nenhum porque ninguém tem a mínima idéia do que seja isso.
      Hoje em dia eu respondo: “Trabalho na IBM”, e a resposta é sempre: “Que legal!”… rs…
      Então, vamos fazer barulho!
      Abraço!

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade




Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.