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

Checklist para profissionais de UX manterem a sanidade em projetos complexos: imagem ilustrativa

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:

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.

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:

Aqui está como podemos pensar numa sequência de checklists para projetos digitais complexos de UX. A inteção é não impor um processo linear. Na maioria dos projetos, os requerimentos são escritos antes que os Cenários sejam documentados (quando eles são...) e os Mapas de Fluxo frequentemente vêm antes das Histórias de Usuário. Mas, independentemente da ordem em que você criar os deliverables, aqui está uma cadeia de escopo e responsabilidade.

Aqui está como podemos pensar numa sequência de checklists para projetos digitais complexos de UX. A inteção é não impor um processo linear. Na maioria dos projetos, os requerimentos são escritos antes que os Cenários sejam documentados (quando eles são…) e os Mapas de Fluxo frequentemente vêm antes das Histórias de Usuário. Mas, independentemente da ordem em que você criar os deliverables, aqui está uma cadeia de escopo e responsabilidade.

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.

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?