Get best of the week

Não é o designer que pinta lindamente, é quem ajuda a empresa a entender o usuário

imagem

No último post, eu disse em números que um bom design compensa, que as métricas podem e devem ser implementadas no processo de design e desenvolvimento, o feedback precisa ser coletado com mais frequência e o designer não deve ser considerado a pessoa que desenha as imagens.

A prática mostra que, se você precisar discutir algo substancial em TI (e em outras áreas também), estaremos falando sobre abordagens clássicas de design com o User Flow e o CJM. Ou seja, muitos processos de desenvolvimento são acelerados com a construção do processo do usuário final ao produto, e não vice-versa.

Ao longo dos anos em que construímos esses processos, na McKinsey, começamos a usar uma estrutura baseada nos paradigmas de design thinking, design baseado em zero e design de serviços. Agora, recomendamos usá-lo ao reconstruir a empresa com foco no ser humano.

O primeiro postulado é esquecer os desenvolvimentos existentes e avaliar mais uma vez o que exatamente o usuário precisa e como ele resolve suas tarefas no momento atual. Muitas vezes, é administrado com muito esforço, porque geralmente é mais fácil desenvolver um produto existente, e não pensar na perspectiva por um ou dois anos.


A diferença de receita e retorno do investimento para o quartil superior de empresas com processos de design bem estabelecidos, em média, em bens de consumo, medicamentos e bancos de varejo. Como você pode ver, na medicina, o design é inesperadamente crítico.

As principais etapas de implementação das etapas da estrutura


Analisamos a situação "como está", entendemos as necessidades dos clientes, empresas e assim por diante.

A equipe do cliente precisa ter uma idéia do caminho do cliente de destino, ou seja, como o produto será exibido a longo prazo, bem como o protótipo MVP (produto mínimo viável), ou seja, a parte do caminho do cliente que a equipe lançará em primeiro lugar. O que fazemos para chegar a isso:

  • Preparamos e conduzimos pesquisas; via de regra, são entrevistas detalhadas em que o proprietário do produto e os principais membros da equipe se reúnem com os usuários pessoalmente, aprendem sobre seus problemas e necessidades.
  • Entendemos como os processos e serviços existentes funcionam, por exemplo, nos reunimos com funcionários da agência de um banco e descobrimos como é realmente um empréstimo para os clientes, o que funciona e o que não funciona.
  • , , , .
  • , , .
  • ; , , , , , . — .
  • , , . , , : , , .

Em cada estágio, transferimos para o cliente as habilidades da abordagem correta para a criação do produto. Nossa tarefa é definir o vetor de movimento, mostrar as ferramentas e garantir que a equipe faça tudo por conta própria: para que as entrevistas com os usuários sejam conduzidas pelos participantes, os mapas do caminho do cliente sejam coletados pelo proprietário do produto, os protótipos e os testes sejam feitos pelo designer.

Por exemplo, passamos por esse processo em um banco, que decidiu introduzir contas de corretagem para pessoas físicas. Agora, esse recurso está presente em quase todos os principais aplicativos móveis, quando você pode fazer com apenas alguns cliques o que foi feito anteriormente em duas ou três viagens ao departamento e preencher vários formulários.

O processo mais simples que um banco faria de acordo com uma estrutura tradicional é transferir online uma operação física regular. No entanto, os postulados de nosso estudo dizem que não é tão importante como a operação é realizada em outro local, se você pode simplificá-la para o usuário neste canal ou neste meio. Essa é uma conseqüência direta da abordagem baseada em zero: nada é herdado. Como disse Torsten Dirks (CEO da Telefonica): "Quando você digitaliza um processo de merda, você tem um processo digital de merda" . O processo deve ser desmontado para zero, repensado e remontado de forma simplificada. Os designers chamam isso da posição do cliente.

A primeira coisa que coletamos é uma lista de requisitos, restrições e necessidades dos clientes, de acordo com a forma como eles veem o processo em um mundo ideal.

Em seguida, temos uma visão de como queremos ver um produto ou serviço no futuro. Ou seja, cruzamos restrições, padrões, recursos técnicos e assim por diante com a aparência do processo ideal. No caso de uma conta de corretagem, por exemplo, processos como “precisa de um passaporte - e o temos desde o momento da abertura de uma conta”, “precisamos de três consentimentos - vamos coletá-los todos de uma só vez”, “você precisa obter esses e esses dados - você pode oferecer insira-os manualmente ou tire-os das redes sociais ”e assim por diante.

Em seguida, assumimos o objetivo e construímos uma sequência de ações que o levam a isso. É como um problema com um bule de chá, quando "desligamos o fogão e a solução se resume em resolver o problema anterior": não devemos tentar usar as conquistas existentes, mas decidir como iremos para a meta e se algo pode ser usado. A reutilização é secundária em comparação com a importância de resolver um problema.

Nesta fase, tarefas específicas já foram gravadas. Só não preparamos a CT por seis meses, mas fazemos os ramos "hipótese - experimento", ou seja, assumimos que algo dará errado. E pense sobre a reação a isso.

O primeiro passo é sempre o MVP.

O postulado básico diz que quanto mais cedo os protótipos aparecerem, mais chances haverá de produzir um produto rapidamente para o cliente, e não para ele próprio. Portanto, estamos trabalhando constantemente com um protótipo de vários graus de desenvolvimento - do Wireframe na primeira etapa ao lançamento na etapa de lançamento do produto (continuamos a apoiar o lançamento).

Exemplo


Ajudamos a estabelecer os processos no banco, faço o design de negócios (é quando os designers ajudam a tomar decisões de negócios). Mais precisamente, ajudo a empresa a tomar decisões mais informadas (devido a mais informações sobre as necessidades dos usuários, ferramentas para analisar a situação atual e projetar a situação de destino, ferramentas para comunicação etc.).

A nova estrutura da empresa possui equipes de produtos autônomas. De fato, eles não existiam antes: a empresa anotou os requisitos do produto, enviou-os aos designers, os designers desenharam o design e entregaram aos desenvolvedores, e eles desenvolveram o produto e o lançaram.

Agora, existem equipes autônomas onde há design, desenvolvimento e entendimento da arquitetura e dos negócios de TI. Após várias iterações de perguntas: "Por que estamos fazendo exatamente isso?" - o software, os desenvolvedores e outros membros da equipe têm idéias completamente diferentes sobre o que os clientes precisam. Por "visões diferentes", quero dizer dados factuais, não intuitivos. Intuitivamente, todos têm sua própria opinião sobre o melhor: para o software, muitas vezes é a velocidade de lançamento do produto, pois o desenvolvedor - a pureza do código, o designer - gosta no portfólio.

Imagem típica: o produto tem 10 anos, "já sabemos tudo". Realizamos entrevistas com clientes e, em geral, tudo é diferente.

Nossa tarefa é mostrar que o dinheiro está onde as necessidades do cliente são satisfeitas. E quanto melhor entendermos o cliente, maior a probabilidade de uma empresa ganhar mais. Portanto, é necessário reorientar gradualmente o recebimento constante de feedback e uma abordagem científica do desenvolvimento. No nosso caso bancário, conduza entrevistas detalhadas, sintetize insights e teste diferentes soluções. Tendo entendido as necessidades do cliente, ajudamos a equipe a olhar para o futuro - estimar a visão de longo prazo do produto ou, como chamamos, a construir o caminho do cliente-alvo.

Depois, ajudamos a aumentar a visão de três a quatro meses para um ou dois anos. Isso é muito importante, porque o quadro, pelo menos na perspectiva do ano, possibilita a tomada de decisões estratégicas. Se você vive constantemente no contexto de três a quatro meses, poderá responder rapidamente às mudanças, mas nunca será o primeiro. E se você antecipar a situação e começar a vender e promover agora o que se tornará importante quando as informações chegarem ao cliente, você poderá se tornar um líder.

Antes da reconstrução dos processos, funcionava assim: o proprietário do produto entendia que algo no mundo circundante havia mudado e seria necessário mudar o produto nessa direção. Demorou três meses para ir do solicitante ao layout do design, porque o designer estava em algum lugar do departamento de design distante, e ele já tinha um turno de tarefas de tarefas técnicas de estranhos de todo o banco.

As equipes de produtos próprios reduziram o tempo de prototipagem para novas soluções para dois dias úteis. Ou seja, ajudamos a criar o modelo de uma pequena empresa autônoma que trabalha em torno do produto.

Protótipos obtidos rapidamente começaram a ser usados ​​como base para as reuniões. Anteriormente, os negócios tomavam decisões em um nível especulativo, mas agora, olhando para CJM e telas prontas, tornou-se possível entender o que exatamente deveria ser feito.

A discussão se tornou mais fácil. As decisões começaram a ser substanciais: “Aqui, vamos dar três tarifas, não duas”, “Há muito texto aqui, mas o que queremos é incompreensível”, “Aqui, está sendo coletado consentimento demais, sem necessidade”. Desde a reunião, agora você pode ligar para advogados para descobrir se esse consentimento desnecessário pode ser removido. A diferença entre as iterações era reduzida às vezes, porque o design era o mais próximo possível dos negócios, tanto fisicamente quanto no sentido da estrutura organizacional.

Pelos padrões das grandes organizações, existentes há mais de uma dúzia de anos, isso soa como ficção científica.

Por que os processos de design se tornaram a base para a tomada de decisão do produto? Porque houve reuniões sem um designer, onde soluções complexas de produtos são discutidas em palavras. Isso leva muitas horas, é repetido a cada poucos dias e a equipe não pode eventualmente concordar.

O designer vem, desenha um protótipo na reunião, a discussão se torna mais substantiva, a equipe rapidamente negocia e segue em frente. Ou seja, foi nessa situação que a prototipagem rápida por meios visuais (pelo menos manualmente em papel) ajudou a concordar mais rapidamente.

O proprietário do produto no banco está acostumado a trabalhar na estrutura Waterfall quando o designer faz parte de uma equipe separada para a qual o aplicativo para criação de layouts é enviado. Demora vários meses para concluir, e o resultado só pode ser alterado no nível de "vamos mudar a imagem no banner", e não no nível de "vamos pensar na lógica das telas e no número de campos a serem preenchidos". O designer apareceu na equipe, o trabalho iterativo começou, traduzindo as necessidades dos clientes no proprietário do produto e na equipe como um todo. O designer destaca e explica razoavelmente as áreas problemáticas da versão atual do design, o software e a equipe procuram mais rapidamente soluções para melhorá-lo.

Resultado: formulações simplificadas, o banco fala o idioma do cliente, um caminho mais curto e mais compreensível, menos campos a preencher, tarifas claras.

Princípios básicos


O designer não é quem pinta lindamente, é quem ajuda a empresa a entender o cliente (usuário) , observar o produto de ponta a ponta que está sendo criado, criar uma visão coletiva unificada (compartilhada) do produto usando ferramentas de design (cartões, protótipos) . Ou seja, um designer é um designer que pode visualizar o processo de criação de um produto. Um membro da equipe de pleno direito, defensor do usuário e facilitador de todas as discussões em andamento.

O designer diz:
— , « ». . , , 2. . , . , . User Story Map. , CJM. ? . ? . ? ? , , , , . — . 20 — , .

Portanto, o primeiro auxílio ao design é acelerar as discussões sobre produtos. E já existe uma mudança de pensamento para "o usuário precisa", e não "aqui temos".

Resolvemos o problema, partindo da compreensão das necessidades do usuário.

O design é avaliado pela satisfação e pelas conversões do cliente. Na maioria dos casos, trata-se da eficácia da solução do problema. Quanto mais rápido e com menos esforço o usuário resolver suas tarefas com a ajuda do produto, mais conveniente ele o considera. Isso geralmente significa que os produtos "bons e velhos" já familiares são subjetivamente melhores, e produtos mais simples com funcionalidade mínima são considerados pelo usuário como mais flexíveis em comparação com a funcionalidade rica (mas desconhecida para ele).

Portanto, qualquer produto não é apenas criado levando em consideração informações previamente identificadas, mas também é constantemente monitorado.

Em nosso exemplo, o designer do banco aparece na equipe e é responsável por testes regulares com os usuários pelo menos uma vez no sprint. A equipe e a gerência veem a reação dos clientes e entendem que o projeto está caminhando na direção certa. Ainda não existem estudos quantitativos, mas já qualitativos. Está claro o que o dinheiro vai para o design.

Uma nova abordagem para o trabalho muda a cultura da empresa, desenvolvendo o foco no ser humano e tornando a experiência do cliente uma responsabilidade de todos.Sem um designer, um banco se comunica com os clientes apenas por meio de agências de marketing, recebendo informações sobre pesquisas por meio de relatórios. Esta informação não gera empatia. O designer organiza entrevistas regulares e aprofundadas com os clientes, ensina software para conduzir essas entrevistas, mostra destaques (cortes de descobertas interessantes) em uma demonstração. A empatia com o cliente se desenvolve gradualmente no banco, nas discussões as pessoas começam a apelar para o que ouviram / viram na entrevista, usando essas observações como uma textura adicional para a tomada de decisões.

Estamos procurando os problemas certos a serem resolvidos ou que devem ser resolvidos em primeiro lugar (novamente, através da compreensão das necessidades do usuário).

É necessário decidir o que mais afeta a satisfação. Em algum lugar, esse é um pixel inclinado contra um recurso com uma implementação de dois meses, em algum lugar - pelo contrário. E em algum lugar, como em uma piada, é inútil mover as camas e você precisa mudar o produto.

Criamos soluções em uma equipe interdisciplinar (design + negócios + tecnologia).

Dividir essas equipes (para desenvolvimento, de preferência pelo menos para discussão) também é a base da estrutura. Cada um dos que influencia o projeto deve ver o que está acontecendo lá dentro, a fim de falar imediatamente sobre isso. O designer geralmente diz: "Eu gostaria assim", e o resto explica por que isso não é possível ou por que isso é possível. O diálogo entre o designer e o desenvolvedor às vezes se assemelha a este quadrinho do XKCD:



Além disso, isso funciona nos dois sentidos: algo muito complicado para um designer pode realmente ser algo muito simples, porque as tecnologias mudaram um pouco ao longo do ano.

Quanto mais próximo o designer estiver do negócio, mais eficiente será o processo de criação do produto e o resultado final: este é o nosso novo relatório de design. Os princípios são os mesmos em todos os níveis .

Prototipamos e visualizamos as soluções inventadas para alinhar a equipe e começar a receber feedback.

Isso é importante no desenvolvimento de software e no desenvolvimento de dispositivos. Se você fizer um aspirador de pó, um protótipo feito a tempo poderá salvá-lo da indignação dos usuários devido a um centro de gravidade incorreto ou a problemas de manutenção que surjam tarde demais.

Quanto mais próximo o designer está do negócio, mais fácil é transmitir conhecimento sobre as necessidades do cliente e acelerar a tomada de decisões em relação a essas necessidades. As boas práticas estão na transparência do processo . O designer do banco envolve toda a equipe e os líderes no processo desde o início. Todos os cartões CJM e opções de trabalho estão à vista (estão pendurados nas paredes, estão disponíveis online, são apresentados em dias de demonstração). Todos, incluindo líderes, entendem como o produto está sendo desenvolvido, podem fazer comentários e fazer perguntas a qualquer momento. Quando o processo é transparente, todos ficam mais calmos.

Quanto melhor o designer é integrado à equipe, maior o envolvimento e o senso de propriedade para o design do produto de todos os membros da equipe (todos participam do design, todos sentem a propriedade). Aqui surge a pergunta: "Por que não pode ser mais vermelho?", E a tarefa do designer não o responde "porque eu disse", mas justificando. Se não der certo, já é necessário elaborar um compromisso. A partir de algum ponto, as discussões sobre "mais vermelho" desaparecem por completo, à medida que o foco muda para a solução dos problemas dos usuários. Isso funciona para o usuário ou não? O usuário não se importa, mais vermelho ou mais verde. A questão é se é perceptível ou discreto, compreensível ou incompreensível, se há valor ou não.

Os protótipos (fotos) tornam a comunicação com advogados, conformidade e segurança mais fácil e mais eficiente. Muito melhor do que se comunicar com letras. Como regra, surgem demandas incríveis que quebram muito a experiência do cliente. Quando isso é simplesmente afirmado nas cartas - não é óbvio para todos quando é desenhado no protótipo - fica claro que não se pode viver assim. O líder vê isso, e a busca por um compromisso começa.

Referências


More articles:


All Articles