Multiplexado

Apresentação

Nessa série de textos, comentarei especificamente sobre Wireframes de um ponto de vista prático. Julgo mais do que pertinente falar sobre isso aqui, pois acredito que um bom Wireframe é peça chave para o tratamento da Experiência do Usuário.

Vale ressaltar que o caráter desses textos leva uma carga pessoal muito grande. Estou aqui apenas para aprender e dividir - sinta-se à vontade para concordar, discordar ou apresentar outros pontos de vista. Estou aqui de coração aberto para expor "sugestões" mesmo, e nunca tentar dizer "verdades absolutas". ;)

Obs.: Se você ainda não sabe o que é um Wireframe, recomendo visita prévia ao texto do Leonardo Oliveira no Web Insider, que é muito bacana.

O texto completo está dividido em 6 partes. A parte inicial já está embutida nesse pacote, e as outras serão colocadas aqui ao longo das próximas semanas.

Eis a lista completa das seis partes:

1. Alcance do escopo do Wireframe

a) Problemas de mau uso do prazo, com falta de dimensionamento prévio do volume de trabalho
b) Diferença de nível de detalhamento entre Interfaces
c) Ausência de telas importantes no projeto

2. Capacidade de manutenção rápida do Wireframe

a) Elementos globais desatualizados em muitas Interfaces
b) Anotações textuais desestruturadas em torno dos elementos que compõem as telas
c) Adaptação e uso de ferramentas inadequadas para o desenho das telas

3. Discrepâncias no aproveitamento de espaço da tela - fator de "acochambramento"

a) Trapaça de uso de tamanhos inadequados para caber mais informação na tela
b) Trapaça na colocação de recursos de scrolling e de previsão de rolagem de conteúdo

Bonus round!

Quiz com Wireframe tosco de exemplo - Participe!

4. Mau uso de controles de Interface

a) Uso de controles de maneiras bizarras (caso checkbox/radio button e outras loucuras)
b) Trapaça no comportamento de controles de Interface
c) Uso inadequado de controles de Interface

5. Falta de apoio a padrões e novas técnicas de construção de interfaces

a) Ausência de informações sobre hierquização absoluta de elementos
b) Ausência de descritivos textuais para informações não-textuais
c) Mau aproveitamento de recursos disponíveis em cada plataforma

6. Outros

a) Ausência de revisão dos textos embutidos no Wireframe
b) Formatos de entrega de artefato "não-seguros"
c) Problemas de recuperação de versões e controle de mudanças executadas
d) Problemas de falta de rastreabilidade entre os demais artefatos que compõem um projeto

Wireframes - Soluções para problemas comuns

Parte 1 de 6 - Alcance do escopo do Wireframe
(As coisas tristes que acontecem quando não se faz algo que deveria ter sido feito)

a) Problemas de mau uso do prazo, com falta de dimensionamento prévio do volume de trabalho

Pode acontecer quando o executor do Wireframe deixa o prazo correr sem ter noção real de todo o volume do trabalho efetivo necessário para completar as suas atividades. O uso inadequado do prazo compromete a qualidade do projeto. É importante que o projetista tenha idéia da jornada que irá percorrer antes de dar o primeiro passo.

Muitas vezes, em projetos mal planejados, as interfaces acabam "dando cria". Quando ocorre esse fenômeno, Uma tela pode virar duas, três ou mais. Seu projeto cresce em progressão assustadora, e o seu prazo, normalmente permanece fixo.

Para não haver comida de bola no desenho do wireframe, os sitegramas são artefatos de entrada fundamentais. Eles permitem planejar o desenho do wireframe para que ele ocorra sem atropelos.

Aqui nesse site tem algum material sobre o Vocabulário Visual de Jesse James Garrett, que é uma alternativa que cumpre muito bem essa coisa de se ter um padrão bacana para desenho de sitegramas.

b) Diferença de nível de detalhamento entre Interfaces (inconsistência no detalhe)

Ainda na onda da falta de noção do tamanho do projeto, muitas vezes encontramos em Wireframes uma discrepância no nível de detalhamento entre as telas. Não estou entrando no mérito se o Wireframe deve ser simples ou complexo. Estou apenas clamando pela busca da consistência em um mesmo documento, nesse primeiro momento. As interfaces que têm a mesma importância devem ter níveis de detalhamento similares.

Em alguns documentos que já recebi, os projetistas detalham muito bem as primeiras telas e fazem as últimas na correria. Isso dá um resultado terrível em todos os sentidos e ainda gera retrabalho para as outras equipes envolvidas.

Esse tipo de ocorrência deve ser evitada. Wireframes consistentes são bons também porque podem interceptar mais falhas na fase inicial dos projetos. Se as coisas são feitas na correria, o Wireframe pode até atrapalhar mais do que ajudar. Para dar tudo certo, o projetista precisa estar muito comprometido com a qualidade do trabalho

c) Ausência de telas importantes no projeto (cadê a interface?)

Eis que alguém em determinado ponto dá falta de uma tela. E isso foi notado somente lá na etapa de codificação... Aí já era: Paramos o trabalho de desenvolvimento e chamamos o prototipador para dar vida ao que foi esquecido.

As maiores vítimas da síndrome do "Esqueceram de Mim" são as telas de fluxo alternativo dos projetos. Entendamos como "fluxo alternativo" nesse contexto tudo que trata exceções ou desvios enquanto o usuário realiza uma tarefa qualquer pela interface.

Bons exemplos de esquecimento são caixas de diálogo, interfaces de erro, tratamento de entidades de apoio, operações secundárias, interfaces de confirmação para operações e outras coisas mais.

A solução de Garrett - já citada na letra "a)" - permite um belo tratamento dos fluxos alternativos de navegação. Isso estimula o projetista a pensar nisso numa visão mais holística do projeto, antes de entrar no detalhe de cada tela.

É isso, obrigado e continue a leitura no próximo texto, que fala sobre a capacidade de manutenção rápida de Wireframes.