Quer pagar / projetar duas vezes? – Design por documentação.

Halyna Kovalisko Blocked Desbloquear Seguir Seguindo 9 de janeiro

O artigo trata do risco de projetar com base apenas na documentação e no valor da pesquisa. A história é baseada em exemplos da vida real e dor real. E sim, realmente doeu.

O design centrado no ser humano está fazendo muito barulho recentemente. Mas o que é o design centrado no humano (HCD) e por que você deve pagar por ele?

Bem, você pode decidir não, mas esteja ciente das conseqüências. Mais tarde, falarei sobre um de nossos casos tristemente conhecidos quando não fomos suficientemente assertivos, cedemos à pressão do cliente e concordamos em projetar com base na documentação.

Mas vamos começar um pouco mais.

Segundo a IDEO, uma empresa de design global, um design centrado no ser humano é uma abordagem criativa para a solução de problemas. É um processo que começa com as pessoas para as quais você está projetando e termina com novas soluções sob medida para atender às suas necessidades.

A essência da HCD é estudar nossos clientes, nossos usuários, seres humanos que usarão nosso serviço.

Trata-se de uma investigação minuciosa de suas necessidades e acima de todas as suas dores. O conhecimento do que nossos clientes potenciais e existentes carecem e o que realmente os atormenta nos dá chances de entregar um produto que efetivamente irá aliviar essa dor tanto para os usuários quanto para os negócios.

Se quisermos ser realmente competitivos, precisamos ter mais do que um Business Analytic inteligente que entrevistará especialistas em conhecimento, proprietários de negócios e documentará os requisitos expressos. Por quê? Primeiro de tudo, por causa das necessidades surdas que são mais valiosas do que conhecidas e expressas uma vez. Em segundo lugar, porque é mais importante entrevistar os usuários finais que realmente usarão o serviço do que os especialistas. Entrevistar especialistas em assuntos de negócios e assuntos é bom, mas não é bom o suficiente. Esta é uma visão superficial e pode e será muito vago. Essa abordagem provou estar errada em nosso século centrado no homem.

Deixe-me contar uma história notória, mas valiosa, que aconteceu comigo há algum tempo. A história que nós e até mesmo nosso cliente gostaria de esquecer. A história que nos deu uma lição valiosa.

“Em Deus nós confiamos, o resto nós testamos”

Nós começamos a trabalhar com um novo cliente. Era um serviço de usuário final B2C. Como de costume, começamos nosso trabalho a partir de pesquisa de mercado, visão geral de concorrentes, entrevistas com stakeholders, estudo de soluções atuais, análise de dados, entrevistas com usuários, esboços, wireframing, testes com usuários, validação e assim por diante. Nós tínhamos uma documentação, mas a usamos apenas como dados de entrada. Nós checamos. Você sabe, "Em Deus nós confiamos, o resto nós testamos" abordagem. Nós passamos com sucesso em várias fases do projeto. O cliente estava mais do que feliz. Nós nos mudamos da parte principal e em algum momento BANG! A URGÊNCIA surgiu em nosso trabalho iterativo bem equilibrado. Recebemos uma solicitação explicitamente urgente apenas algumas semanas antes de nossa viagem de negócios ao cliente, onde planejamos validar nossas soluções com usuários reais. “Precisamos de um novo módulo. Urgentemente. Aqui estão os requisitos. ”Nós os estudamos, eles pareciam… bem. Estranho? Muito abstrato? Não é realmente ao ponto? Decidir?

Precisávamos finalizar todos os trabalhos para estarmos prontos para a validação e projetar uma nova base de módulos sobre os requisitos 🙂 Paz de bolo! Mas não…

Após uma análise cuidadosa dos requisitos, tentamos convencer o cliente a questioná-lo. Também tentamos discutir a possibilidade de postergar um novo design de módulo até a visita ao cliente. Isso nos daria a chance de entrevistar o novo usuário potencial do módulo. Mas não. Ou não éramos suficientemente assertivos ou nosso cliente estava confiante demais em sua documentação, mas nos rendemos.

Nós concordamos, nós projetamos por documentação, nós preparamos um protótipo, fizemos uma viagem de negócios, visitamos nosso futuro cliente para validar nossas novas soluções de módulo, conversamos com eles logo antes de mostrar a eles nossa solução e durante esse curto período conversa apareceu … o processo deles era absolutamente diferente, eles estavam fazendo tudo de maneira diferente do que o nosso autor de documentação de requisitos descrevia, eles não precisavam desses relatórios, precisavam de outro relatório … Eles não precisavam da nossa solução. Não resolverá o problema deles. Eles tinham outros problemas. Eles precisavam de uma solução diferente.

Foi uma pena. Isso machuca. Nós ficamos arrasados. Nós saímos. Nós tivemos outro encontro com outro cliente em potencial e… sim. A falha repetida. O gerente do cliente tentou nos animar no elevador dizendo que há outras empresas que precisarão da nossa solução. Tem…

Mas por que projetar algo e depois procurar clientes que provavelmente gostariam de usar a solução? Por que não estudar as necessidades e dores de nossos clientes atuais e projetar um produto que satisfaça SUAS necessidades ?!

Seja esperto. Não pague duas vezes. Respeite seus usuários. Estude suas necessidades. Seja enfático com a dor deles. Design para humanos.