sábado, outubro 27, 2018

Mapear diagramas de experiências

Gostei do livro "Mapping Experiences Diagrams" (2016), mas não me será útil, ou seja, considero que aquilo que James Kalbach tenta aqui fazer, mapear as experiências de uso das aplicações, pelo menos do modo como foi feito, não funciona porque peca por um excesso de formalização do conhecimento. No fundo a intenção era excelente, ajudar os designers a criar mapas de experiência, num tempo em que a experiência se assumiu como o mais importante de qualquer aplicação, mas o caminho escolhido pelo autor acaba sendo algo despropositado.


Em termos mais concretos, Kalbach procura neste livro fundir o conhecimento do Design Gráfico, da Visualização de Informação, do Design de Interação e do Design Thinking para chegar a um documento único que representaria o objeto último do trabalho de UX. Considerando que o esforço foi feito, e que não faltam recursos a Kalbach, considero que o resultado é um conjunto de ferramentas complexas, que acabam a servir mais o registo do que o design. Ou seja, os mapas apresentados são interessantes visualmente, atraem o nosso interesse, mas a sua construção acaba sendo tão detalhada que facilmente roçará a frustração, aproximando-se muito daquele tipo de ferramentas a que nos fomos habituando nos últimos anos, criadas pelos gestores da qualidade, que servem para tudo formalizar, mas que têm impacto zero na melhoria do trabalho.

Bonito para olhar, mas muito pouco útil para quem desenha a experiência.

Polanyi discutiu há muitos anos a diferença entre conhecimento tácito e conhecimento explícito, O primeiro é aquele que não podemos passar por meios verbais ou textuais, não se pode formalizar, porque contém uma miríade de detalhes que só podem ser apreendidos pela experiência no tempo. O caso mais simples e que todos conhecem é o andar de bicicleta, mas no mundo das artes, a grande maioria do conhecimento relacionado com o ato de criação é deste tipo. Neste caso, não diria que o conhecimento do Design de Experiência e UX é todo tácito, muito é explícito e utiliza imensas metodologias do design mas também da psicologia e da sociologia para atingir os seus fins. Mas no meio deste, existe muito conhecimento que se constrói a partir da relação com os dados, as pessoas e os artefactos que não é simplesmente plasmável numa folha de excel ou num gráfico.

Sei bem que é custoso admitir tal, as razões prendem-se mais com o tipo de sociedade em que vivemos, que tudo quer quantificar. Ou seja, existe uma necessidade do Designer de Experiência justificar o seu trabalho perante os outros, e sendo este trabalho ainda secundarizado, porque não imediatamente visível, nada melhor do que ter ferramentas que possam dar a ver o que representa em concreto esse trabalho. Talvez por aqui aceite as propostas de Kalbach, é preciso que os restantes membros das equipas reconheçam o trabalho realizado pelos colegas de UX, mas sinto que o investimento que se está a fazer aqui, serviria melhor se fosse colocado ao serviço das pessoas e do design.

No meio de tudo isto, existem claramente ferramentas apresentadas por Kalbach que considero particularmente relevantes para o Design de Experiência, uma delas é o User Story Mapping (p.214), que é fundamental na modelação de modelos mentais no uso de aplicações. Não é uma ideia original sua, vem de trás, de Lucy e Larry Constantine ou Jeff Patton, e gosto particularmente da proposta aqui trazida de Steve Rogalsky (ver imagem abaixo) :

Este Story Map funciona muito bem no suporte do alinhamento das tarefas com a experiência que se pretende criar com a aplicação.

Passos para a criação do User Story Map:
Frame the idea: As a team, discuss why you are building the product. Identify and record the benefits and prob- lems it solves. Also decide on who you are building the product for. Write your responses down at the top of the map.
Map the big picture: Illustrate the flow of the solution chronologically, including details about specific actions. If possible, include the pains and joys users have today to inform your development decisions.
Explore: Use the map to facilitate conversations about desired outcomes and the intended experience. Describe the features to support users and record them as stories on the map. Sketch solutions as needed, and go back and interview customers as well.
Create a release strategy: Break the user stories into different releases, starting with the minimum that’s necessary to reach the desired outcome.
Build, measure, learn: As development progresses, track the team’s learning against the user story map. Keep it in a visible place and refer back to it often.

A construção em papel físico com quadro a que todos podem aceder e discutir é muito mais interessante do que a versão meramente digital.

Outra das mais valias apresentadas neste livro é a enorme defesa da figura de workshop para desenvolver o design, ou seja, a figura participativa e colaborativa do desenhar, criar e construir. Ao longo de todo o livro são expostos vários modelos para conceber oficinas e momentos de brainstorm e colaboração, algo que é fundamental no design de UX, já que não é algo que possa ficar ao alcance do mero designer isolado.

Workshop em que se promove um jogo com Journey Maps de uma aplicação com diferentes personas usadas por múltiplos designers.

Por outro lado, uma das demonstrações do falhanço da excessiva formalização proposta surge pela referência que o autor decide fazer à estrutura sintática de Evento, proposta por Philip Johnson-Laird, a propósito da desconstrução dos eventos narrativos (p.305), que só pode ter utilidade para uma máquina, ou seja implementação em inteligência artificial, já para o ser humano é irrelevante, já que não é possível para nós construir histórias a partir daquelas modelações narrativas, por estarem completamente arredadas do nosso modo de funcionamento cognitivo, capacitador da imaginação e da criação de histórias.

Útil para que uma máquina compreenda e desconstrua uma história, irrelevante para qualquer ser-humano que tente construir uma história.

No fundo, e isso mesmo surge em alguns exemplos dados, mais parece que o autor está a tentar apresentar modelos para gestão de complexidade de informação, e não para a criação de UX. E escrito isto, fui rever a introdução do livro, e obrigo-me aqui a alguma mea culpa, aí o autor acaba por dizer que o livro era mais para gestores e responsáveis pela organização. Só não sei se assim era, se foi assim que os editores decidiram promover o livro depois de analisar o que vinha lá dentro. Por isso, designers, especialmente designers de experiência atraídos pelo título do livro, abstenham-se.

Sem comentários:

Enviar um comentário