Você provavelmente já ouviu falar de desenvolvimento de software Ágil , Gestão de processos Kanban e Lean UX . O design colaborativo é uma abordagem filosófica e tática diferente para o design de produtos de negócios.
O design colaborativo é o processo de design em um ambiente participativo, envolvente e realista com todas as mãos ou confiança no cérebro . Você NÃO está projetando no vácuo; Em vez disso, como o nome indica, o design colaborativo coloca o designer no centro de diversas equipes e departamentos para trabalhar com todos para criar um produto coeso. Dessa forma, ninguém fica de fora e o produto pode ser construído com todos os stakeholders envolvidos.
Cada organização empresarial é diferente, e agrupar as partes interessadas em torno de qualquer ideia ou tarefa pode parecer como pastorear gatos. Neste guia, veremos dicas e truques para trabalhar com os principais participantes, não apenas para obter sua opinião, mas para incorporá-los a essa nova abordagem centrada no design.
! [colaboração empresarial] (https://uploads.toptal.io/blog/image/125053/toptal-blog-image-1514836432132-062b9a075d6f3eee95274d0d83903f76.jpg)
Os designers Eles são ótimos em muitas coisas, mas seu papel começa na solução de problemas. Isso requer saber quem são os especialistas e trabalhar com eles. Cada membro da equipe de desenvolvimento de produto tem suas próprias necessidades e responsabilidades, por isso conhecê-los é tão importante quanto concluir a tarefa atribuída.
Então, sem mais delongas, vamos conhecer a equipe:
Gerentes de produto definir o escopo, requisitos e ciclos de iteração de desenvolvimento para produtos e recursos; Freqüentemente, são os guardiões das características antes de um sim / não final e têm prática para se comunicar com toda a organização, incluindo executivos.
Engenheiros Eles criam o produto, para que entendam as capacidades e limitações técnicas. Isso os torna um recurso crítico para determinar as principais preocupações, incluindo cronogramas de desenvolvimento, tecnologias a serem usadas, escopo e, muitas vezes, viabilidade de design (se nossos conceitos são possíveis devido às limitações de tecnologia e tempo).
Arquitetos de banco de dados e sistema eles sabem como os dados são integrados e têm uma compreensão profunda do que é necessário para manter o desempenho enquanto continuam a desenvolver o produto / plataforma existente.
Especialistas internos no assunto (PMEs) eles estão intimamente familiarizados com os processos de negócios, casos de uso, histórico e política, bem como com as expectativas gerais de gerenciamento, clientes e usuários.
Vendas concentra-se em apresentar o produto a clientes potenciais. Isso torna as vendas o primeiro ponto de contato, portanto, sua compreensão do produto é crítica para fechar (e frequentemente criar) leads.
Treinadores (ou em SaaS, agentes de sucesso do cliente ) têm exposição direta à equipe de vendas e aos usuários novos ou de teste, e podem fornecer muitas informações úteis sobre o desempenho do produto em vitro e além.
Quando todas as partes que trabalham no produto participam do processo de design (um dos princípios fundamentais do Metodologia ágil , o produto resultante tem uma chance significativamente maior de sucesso, não porque os designers trabalham com os stakeholders, mas porque os stakeholders, na maioria das vezes, entendem as necessidades específicas dos usuários e empresas de uma forma que nós não. Trabalhar colaborativamente sempre parece ser a melhor opção, mas como fazemos isso?
Os gerentes de produto costumam ter um vínculo pessoal com o produto e corresponder às expectativas da empresa. Eles também devem responder aos usuários ou clientes de seus produtos quando houver problemas, promessas não cumpridas ou solicitações de novas funcionalidades.
Eles valorizam muito a comunicação simples e precisam se manter atualizados sobre o progresso, os problemas e quaisquer alterações. Eles gostam de ver os rascunhos primeiro e com frequência, e porque podem trabalhar em várias escalas (vários níveis, desde o desenvolvimento direto do produto até práticas com pequenas alterações), suas interações com eles podem variar muito.
Como os gerentes de projetos passam muito tempo se comunicando com várias partes interessadas (interna e externamente), é importante mantê-los informados sem esperar que consultem você. Defina verificações regulares com seus PMs para enviar rascunhos iterativos, ouvir seus comentários e sempre terminar com uma lista de itens de ação para a próxima reunião.
Não demorará muito para aprender quais são seus objetivos para a funcionalidade do produto. PMs sabem disso os designers eles resolvem problemas, então os designers devem fornecer dados e análises para demonstrar seu raciocínio. Se você está certo ou não, não importa. Mostre que o objetivo é construir o melhor produto e você ganhará a confiança de um PM!
Engenheiros (também chamados de desenvolvedores) são as pessoas mais próximas do produto; eles o constroem! Isso lhes dá uma vantagem porque podem experimentar e testar diretamente os componentes individuais do produto. em ação . Isso é ótimo porque eles sem dúvida encontrarão os pontos fracos de qualquer design, às vezes antes de construir qualquer coisa, o que é duplamente ótimo porque é uma grande vantagem em muitos níveis encontrar as falhas antes de o software ser codificado.
A melhor maneira de ganhar a confiança de um grupo de engenharia é produzir especificações de produto completas e abrangentes ou envolvê-los desde o início ... ou ambos.
Quando os desenvolvedores são considerados verdadeiros 'atores', eles estão mais do que dispostos a discutir casos de uso, cenários, desafios técnicos e as opções para superá-los. É fácil esquecer que os engenheiros são verdadeiros arquitetos de produtos; Eles têm um grande interesse em resolver problemas com o designer, especialmente quando o desafio é difícil ou pode ser tratado de forma diferente.
Os arquitetos de banco de dados e sistema sabem como o produto funciona nos bastidores. Eles sabem tudo sobre como os dados são armazenados e estruturados, o que pode ser integrado e como todos os sistemas se comunicam entre si. Eles tendem a se preocupar menos com como o produto funciona para os usuários do que como ele interage com vários sistemas (que é o que eles são responsáveis em última instância).
Eles podem ser especialmente difíceis para designers centrados no usuário . É importante lembrar que mesmo que um arquiteto de banco de dados / sistema nunca interaja com os usuários finais, seu foco é sempre beneficiar esses usuários, seja por meio da confiabilidade, velocidade ou simplicidade do produto.
Seu conhecimento de como as estruturas de dados funcionam - e as ramificações de qualquer mudança na funcionalidade do produto - são muito fáceis de detectar sem a contribuição de um especialista. É importante convidar e incluir arquitetos de sistema em reuniões e discussões sobre mudanças no produto, mesmo que sua posição não pareça estar diretamente relacionada. Uma maneira de colaborar com um arquiteto de sistemas é criar uma lista de verificação com as seguintes questões:
Esta lista simples irá apontar a direção certa, mesmo sem uma compreensão clara de como as estruturas de dados monolíticas preexistentes (e possivelmente) funcionam. Qualquer coisa verificada é uma área que deve ser investigada com uma discussão simples.
Os especialistas na área são devidamente nomeados; Eles são especialistas na área e podem ser uma mina de ouro de informações exclusivas e valiosas. Freqüentemente, eles obtiveram diplomas de especialização na área ou passaram a maior parte de suas vidas trabalhando em seu setor. Eles têm experiência prática em como o negócio deve operar e se lembram da longa e dolorosa história e da política que os levou aonde estão hoje. Um analista de negócios conhece os meandros de como a organização opera e muitas vezes desempenha a mesma função de uma PME se os dados estiverem disponíveis, mas não há especialista interno.
Envolva-se com as PMEs para saber como o projeto é percebido pela administração para garantir que as expectativas internas sejam atendidas e que não esteja em um território perigoso. Convide analistas para sessões de design, dizendo-lhes com antecedência que eles são os especialistas e pedindo-lhes que compartilhem suas percepções sobre falhas históricas, conflitos políticos e outras questões que podem ser críticas para o lançamento de um produto bem-sucedido.
Quando as vendas acabam conquistando novos clientes, treinadores ou, para empresas de SaaS, Gerentes de sucesso de clientes (CSM), avance para ensinar aos novos usuários como realmente usar o produto. Portanto, nem é preciso dizer que os treinadores passam muito tempo conversando com usuários novatos. Um CSM tem uma perspectiva única porque interage com clientes que muitas vezes não estavam envolvidos na decisão de compra da empresa.
Com essa perspectiva única, os treinadores / CSMs podem fornecer informações valiosas para decisões de design, tanto para integração do cliente quanto para o comportamento do novo usuário. Muitas organizações comerciais rastreiam e monitoram como seus novos clientes usam vários produtos e registram tudo, desde ligações até reclamações, mas os coaches têm uma ideia do que os clientes estão realmente lutando.
Inclua um coach sênior em todas as principais reuniões de design e pergunte sobre quaisquer decisões com ele. Faça perguntas como 'Quais são as três principais reclamações dos clientes?' e 'Os novos clientes estão satisfeitos com o produto, em média?' e 'Quais mudanças você acha que proporcionarão o maior impacto positivo para você e sua equipe?' Desta forma, todos nós aprendemos qual é o caminho feliz; Os coaches são nossos olhos e ouvidos para todas as maneiras como os clientes realmente usam o produto.
Vendas e design costumam estar em conflito. Algumas organizações são movidas por vendas, enquanto outras não, mas não importa o que aconteça, há uma clara diferença de objetivos: a equipe de vendas quer aumentar as vendas, enquanto o design quer melhorar a experiência do usuário. Eles nem sempre se alinham.
Isso não tem que ser o caso. A maioria dos vendedores tem reclamações muito razoáveis: eles têm pouco ou nenhum controle sobre as decisões de produtos, são solicitados a assumir compromissos que não podem realmente prometer e são levados a atingir metas específicas de receita de qualquer maneira. Não é de se admirar que as equipes de vendas e produtos tenham esquentado discussões regularmente!
No entanto, como os treinadores, a organização de vendas tem uma perspectiva única sobre as necessidades do cliente e, muitas vezes, essa perspectiva é a diferença entre fazer uma pequena venda e trazer uma baleia. Compreenda as diferentes áreas com as quais a equipe de vendas tem dificuldade. Experimente ouvir qualquer tipo de chamada e aprenda como esses clientes em potencial se comunicam.
Isso abrirá a conversa com vendas. Não se trata apenas de suas necessidades serem ouvidas; trata-se de melhorar a experiência dos usuários em potencial em todas as fases, desde a primeira comunicação até após a integração. Descubra o que os vendedores mais ouvem dos clientes em potencial, quais são os desafios que eles enfrentam para fechar o negócio e quais são as maiores preocupações quando ele é fechado.
Como designer, todas essas partes móveis podem ser difíceis de gerenciar, especialmente quando você não é considerado um “gerente” no sentido oficial do termo. Como um participante chave na comunicação entre equipes, coleta de requisitos e feedback de design, você precisa ter acesso a todos esses profissionais em algum nível.
A maneira mais crítica e simples de fazer isso é ouvir todas as partes e levar seus comentários a sério. Na maioria das organizações, a próxima etapa é obter esse feedback e trabalhar com o gerente de produto para organizar os requisitos em um trabalho acionável.
A partir daí, depende das prioridades e do preenchimento das lacunas. Em última análise, o objetivo é projetar o melhor produto e precisamos da ajuda de toda a equipe de desenvolvimento de produtos. Reconhecer que cada função é importante e tornar essas pessoas cientes de seu valor no ciclo de desenvolvimento do produto abre-as para fornecer as informações de que o designer precisa para tomar melhores decisões sobre o design do produto.