O trabalho e processos que envolvem User Expericente, ou UX, não são nada simples de se fazer, mas, felizmente, existem propostas e exemplos de como é possível realizar as coisas de uma maneira mais clara, limpa e organizada. Uma dessas maneiras é usar checklists para ter certeza de que todos os deliverables possam ser correlacionados uns com os outros e os clientes estão entendendo todas as etapas do processo.
É de conhecimento comum (ou deveria ser) que a descoberta de requisitos durante o design de uma página é a receita para a loucura. Mas não importa o quanto acreditamos nisso e nos esforçamos para evitar essa situação: continua acontecendo… É comum clientes solicitarem característica raramente usadas ou casos extremos quando vêem o design de uma página. Neste caso, é fácil culpar o cliente por não ter seus requisitos definidos e comunicados.
Mas a verdade é que o problema é nosso! Temos pressa para o processo criativo sem entender tudo o que a nossa solução tem de fazer e prover. Se nosso objetivo é sermos bem-sucedidos, é preciso descobrir como manter nossa criatividade responsável perante as exigências completas (e complexas) dos projetos. A menos que tomemos a iniciativa de definir o escopo total desses projetos, estes nunca serão bem-sucedidos.
Pensamento em checklist e prestação de contas
Para nossa criatividade auxiliar na produção de uma solução realmente viável, nossos resultados não podem ficar sozinhos, eles devem trabalhar juntos como um conjunto relacionado de listas de verificação ou checklists. “Pensamento em checklist” faz com que os sistemas digitais complexos de toda a empresa sejam muito mais “manejáveis”.
Em um processo Agile, por exemplo, tudo o que acontece em um sprint é referenciado de volta para uma ou mais Histórias de Usuário (User Stories). Esboços devem abordar todas as histórias do usuário no sprint. Em outras palavras, esboços e fluxos de página são responsabilizados a essas histórias de usuários. Da mesma forma, muitos projetos de software envolvem algumas listas de exigências e histórias de usuários devem ser de responsabilidade desses requisitos.
Checklists ajudam com essa “responsabilização” entre entregas (deliverables). Pensar nas entregas como checklists ajuda com 3 coisas:
- Guiar clientes através do processo de definição de escopo completo dos complexos projetos digitais
- Manter nossa criatividade a par e atuando em tudo o que é necessário e que ela é “chamada” a ajudar
- “Segurar” o cliente na prestação de contas sobre suas (quase sempre) inevitáveis mudanças. É possível voltar e dizer: “Essa é uma nova história que ainda não discutimos. Vamos colocar em nossa lista.”
Essa “prestação de contas” permite que nossa criatividade seja, verdadeiramente, eficaz.
Tipos de checklists para projetos digitais complexos de UX
Uma checklist pode assumir muitas formas, mas há 5 consideradas cruciais para garantir que os projetos não fiquem fora de controle e que as partes interessadas (stakeholders) e clientes sejam responsáveis por suas decisões anteriores.
- Checklist #1: Cenários
- Checklist #2: Requisitos de Negócio
- Checklist #3: Casos de Uso (ou User Stories se você estiver usando Agile)
- Checklist #4: Mapas de Fluxo
- Checklist #5: Wireframes (ou Protótipos ou Sketches ou o que você usa para definir o que acontece em uma página)
Estes não são novos deliverables e alguns deles certamente não são do domínio de um Designer de Interação; o truque é tratar cada um como seqüência de checklists e não apenas como um exercício de documentação. Por exemplo:
- Os Requisitos (Checklist #2) são levados em conta em todos os Cenários (Checklist #1)?
- Os Casos de Uso (Checklist #3) levam em conta todos os Requisitos (Checklist #2) e Cenários (Checklist #1)?
- Será que os Mapas de Fluxo (Checklist #4) resolvem todos os Casos de Uso (Checklist #3)?
- Criei todos os Wireframes necessários (Checklist #5) refletidos nos Mapas de Fluxo (Checklist # 4)?
- Meus protótipos (Checklist #5) ilustram todos os Casos de Uso (Checklist #3) e Cenários (Checklist #1)?
A chave para o sucesso é a visibilidade pública das conexões entre os resultados. Por exemplo, ao mostrar os fluxos de página, começar mostrando as Histórias de Usuário como uma “configuração” para os fluxos. Ou, se você está desenvolvendo Histórias de Usuário, comece recordando a todos as Personas e Cenários. Isso garante que você tenha uma chance melhor de garantir que a entrega (deliverable) seguinte é tão completa quanto possível.
Você também pode identificar mais facilmente novos Cenários, Requisitos e Histórias de Usuário sem se sentir na defensiva ou como se tivesse perdido alguma coisa. Se você estiver fazendo a coisa certa, deve começar a ouvir seus clientes dizerem “Isso soa como uma nova História de Usuário!” quando uma nova funcionalidade, inevitavelmente, vem à tona.
Exemplo de Histórias de Usuário
Cenário: a pessoa com privilégios de Admin precisa mover informações importantes e ordens pendentes de uma conta desativada para uma nova conta. Isso pode acontecer quando um Admin desativa uma conta ou quando um Admin está vendo a lista de contas desativadas.
- UC 1: Admin vê lista de contas desativadas:
- Sistema tem um filtro para isso na Busca
- Novo: a pessoa precisa estar habilitada a ver contas desabilitadas com ordens em aberto
- Pode ser executado o UC 3
- Referência de Fluxo: Mover e Copiar Dados
- Páginas: ADM-00
- UC 2: Admin desativa uma conta
- Sistema pergunta se dados devem ser movidos para outra conta
- A pessoas responde “Sim” ou “Não”
- Sistema ativa o UC 3
- Referências de Fluxo: Mover e Copiar Dados
- Páginas: ADM-00, ADM-01, ADM-02, ADM-03, ADM-04
- UC 3: Pessoa move dados de uma conta para outra
- Pessoa entra com uma conta de destino (#)
- Pessoa especifica os dados a serem movidos (nova função)
- Pessoas
- Contatos T/C e A/P
- Ordens pendentes ou pré-venda
- Sistema mostra confirmação de que dados foram movidos (nova função)
- Referência de Fluxo: Mover e Copiar Dados
- Páginas: ADM-00, ADM-02, ADM-03, ADM-04
Nessas Histórias de Usuário, foram vinculados um Mapa de Fluxo específico (Mover e Copiar Dados), Histórias de Usuário e Wireframes específicos (ADM-00, ADM-01, etc). Criar identificadores únicos é uma maneira fácil de ter certeza de que deliverables se tornarão checklists. Isso também ajuda a ter certeza que uma equipe está compartilhando os mesmos pontos de referência através dos processos.
A maneira mais fácil de criar uma checklist é ter certeza de que cada deliverable possui elementos que podem ser referenciados em outros deliverables (subsequentes). Como citado, uma ótima maneira é usar identificadores únicos (#) para isso.
Considerações finais
O trabalho que fazemos ainda não tem um lugar claro nos processos de sistemas digitais complexos e, já que é provável que outros não o definirão para nós, é noss obrigação fazê-lo! Abrar a arte das checklists significa descobrir como os resultados se encaixam uns com os outros. Tratar deliverables como checklists para outros deliverables é uma forma de garantir que o que você faz contempla não somente o trabalho que foi realizado antes, mas informar e molda o trabalho que ainda está para ser feito.
Tudo isso é um processo; e não é um processo já definido e “consagrado”. Essas são sugestões de uso ainda em desenvolvimento, não somente no que concerne ao desenvolvimento web nacional, mas o desenvolvimento web mundial. Portanto, tome isso como sugestões de uso e, por que não, criar e divulgar sua própria maneira de fazer as coisas?