Você provavelmente já ouviu falar de Ágil desenvolvimento de software, gerenciamento de processos Kanban e Lean UX . O design colaborativo é uma abordagem filosófica e tática diferente para design de produto empresarial .

O design colaborativo é o processo de design participativo, envolvente e realista em todas as mãos ou cérebro confiável meio Ambiente. NÃO está projetando no vácuo; em vez disso, como o nome indica, o design colaborativo coloca o designer no centro das várias equipes e departamentos para trabalhar com todos a fim de construir 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 encurralar as partes interessadas em torno de qualquer ideia ou tarefa pode parecer como pastorear gatos. Neste guia, revisaremos dicas e truques para trabalhar com os principais participantes, não apenas para obter sua opinião, mas também para trazê-los a bordo com esta nova abordagem centrada no design.

Conheça os jogadores

Designers 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, portanto, conhecê-los é tão importante quanto concluir a atribuição dada.

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; eles costumam ser os guardiões de recursos antes de um sim / não final e têm prática na comunicação com toda a organização, incluindo executivos.
• Engenheiros construir o produto, para que eles 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, a viabilidade do projeto (se nossos conceitos são possíveis devido às limitações de tecnologia e tempo).
• Arquitetos de banco de dados e sistema saber como os dados são integrados e ter um entendimento profundo do que é necessário para manter o desempenho enquanto continua a construir sobre o produto / plataforma existente.
• Especialistas no assunto interno (PMEs) estão intimamente familiarizados com os processos de negócios, casos de uso, história e política, bem como com as expectativas gerais de gerenciamento, clientes e usuários.
• Vendas concentra-se em apresentar o produto a clientes em potencial. Isso faz com que as vendas sejam o primeiro ponto de contato, portanto, a 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 usuários novos ou de teste, e podem contribuir com grandes quantidades de informações úteis sobre o desempenho do produto em vitro e além.

Quando todas as partes que trabalham no produto estão envolvidas no processo de design (um dos princípios fundamentais da Metodologia ágil ), o produto resultante tem uma chance significativamente maior de alcançar o sucesso - não porque os designers estejam trabalhando com as partes interessadas, mas porque as partes interessadas, na maioria das vezes, entendem as necessidades específicas do usuário e do negócio de uma forma que talvez não. Trabalhar colaborativamente sempre parece a melhor opção, mas como fazemos isso?

Como colaborar com as partes interessadas

Gerentes de produto, guardiões e cronometristas do produto

Os gerentes de produto costumam ter um apego pessoal ao produto e são considerados expectativas muito altas dentro da empresa. Eles também devem responder aos usuários ou clientes de seus produtos quando houver problemas, promessas não atendidas ou solicitações de uma nova funcionalidade.

Eles valorizam a comunicação simples e precisam ser mantidos 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 além do desenvolvimento direto do produto até a prática com até mesmo pequenas alterações), suas interações com eles podem variar muito.

Como os PMs passam muito tempo se comunicando com várias partes interessadas (interna e externamente), é importante mantê-los informados sem esperar que eles entrem em contato com você. Defina check-ins regulares com seus PMs para apresentar 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 designers são solucionadores de problemas, portanto, os designers precisam fornecer dados e análises para provar seu raciocínio. Se você está certo ou não, não importa. Prove que construir o melhor produto é o objetivo e você ganhará a confiança de um PM!

Engenharia: responsável por dar vida aos projetos

Engenheiros (também chamados de desenvolvedores) são as pessoas mais próximas do produto; eles o constroem! Isso dá a eles uma vantagem porque eles experimentam e testam diretamente os componentes individuais do produto em ação . Isso é ótimo porque, sem dúvida, eles 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 que o software seja codificado.

A melhor maneira de ganhar a confiança de um grupo de engenharia é produzir especificações de produto abrangentes e completas ou envolvê-los desde o início ... ou ambos.

Quando os desenvolvedores são considerados verdadeiros acionistas , 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 produto; eles têm interesse em resolver problemas com o designer, especialmente quando o desafio é difícil ou pode ser tratado de outra forma.

Arquitetos de banco de dados e sistemas, guardiães das estruturas de dados

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. Eles tendem a se preocupar menos com a forma como o produto funciona para os usuários do que como ele interage com vários sistemas (que é o que eles são, em última análise, responsáveis).

Eles podem ser especialmente difíceis para designers centrados no usuário lidar com. É 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 operam - e as ramificações de quaisquer alterações na funcionalidade do produto - são muito fáceis de perder sem a contribuição de especialistas. É 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 sistema é criar uma lista de verificação com as seguintes perguntas:

• O recurso X afeta a estrutura de dados atual?
• Existe algum trabalho adicional de design / desenvolvimento considerando a arquitetura atual?
• O design Y está em conflito com alguma entrada / saída de usuário existente?
• Algum serviço externo é afetado pelo recurso X?

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 marcada é uma área que deve ser investigada com uma discussão simples.

Especialistas no assunto e analistas de negócios, os assistentes de informação

Os especialistas no assunto são adequadamente nomeados; eles são especialistas no assunto 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 sobre como o negócio deve operar e se lembram da longa e dolorosa história e da política que levaram todos 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 houver um especialista interno.

Envolva-se com as PMEs para saber como o projeto é percebido pela administração para se certificar de que as expectativas internas estão sendo atendidas e que você não está pisando em território perigoso. Convide analistas para as sessões de design, dizendo-lhes com antecedência que eles são os especialistas e pedindo-lhes que compartilhem seu conhecimento de falhas históricas, conflitos políticos e outras questões que podem ser críticas para o lançamento de um produto bem-sucedido.

Gestores de sucesso do cliente, um novo ponto de contato do cliente

Quando novos clientes são finalmente integrados por vendas, treinadores - ou, para empresas de SaaS, gerentes de sucesso de clientes (CSMs) - assumem o controle 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 de sua 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 empresariais rastreiam e monitoram como seus novos clientes usam vários produtos e registram tudo, desde ligações até reclamações, mas os treinadores têm uma noção do que os clientes realmente enfrentam.

Inclua um instrutor 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 reclamações mais sérias dos clientes?' e “Os novos clientes estão, em média, satisfeitos com o produto?” e 'Quais mudanças você acha que proporcionarão o maior impacto positivo para você e sua equipe?' Assim, todos nós aprendemos sobre o que é o caminho da felicidade; os treinadores são nossos olhos e ouvidos para todas as maneiras como os clientes realmente usam o produto.

Vendas, o primeiro contato do produto com os clientes

Vendas e design costumam estar em conflito. Algumas organizações são voltadas para as vendas, enquanto outras não, mas não importa o que aconteça, há uma diferença clara nas metas: a equipe de vendas deseja aumentar as vendas, enquanto o design deseja 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 problemas muito razoáveis ​​para enfrentar: eles têm pouco ou nenhum controle sobre as decisões do produto, são solicitados a assumir compromissos que não podem realmente prometer e são levados a atingir metas de receita específicas apesar de tudo. Não é nenhuma surpresa que as equipes de vendas e produtos tenham discussões acaloradas regularmente!

No entanto, como os treinadores, a organização de vendas tem uma perspectiva única sobre as necessidades do cliente e, frequentemente, 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. Tente atender a todos os tipos de ligações e aprenda como esses clientes em potencial se comunicam.

Isso abrirá a conversa com vendas. Não se trata apenas de ter suas necessidades 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 ao finalizar o negócio e quais são as maiores preocupações depois que ele é fechado.

Design na empresa não precisa ser um pesadelo

Como designer, todas essas partes móveis podem ser muito desafiadoras de gerenciar, especialmente quando você não é considerado um “gerente” no sentido oficial do termo. Como um dos principais interessados ​​na comunicação entre equipes, na coleta de requisitos e no feedback de design, você deve ter acesso a todos esses profissionais em algum nível.

A maneira mais crítica, porém mais simples, de fazer isso é ouvir todas as partes e levar seu feedback a sério. Na maioria das organizações, a próxima etapa é receber 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 conscientizar o pessoal de seu valor no ciclo de desenvolvimento do produto abre-o para fornecer as informações de que um designer precisa para tomar melhores decisões de design de produto.

• • •

Leituras adicionais no Blog de design do ApeeScape:

• Práticas recomendadas de design de interface do usuário e erros comuns
• Estados vazios - o aspecto mais negligenciado da experiência do usuário
• Simplicidade é a chave - Explorar o design mínimo da Web
• Princípios heurísticos para interfaces móveis
• Projetando para facilitar a leitura - um guia para tipografia da Web

Compreender o básico

O que é uma estrutura colaborativa?

Uma estrutura colaborativa é o método no qual os designers estruturam o processo de design e desenvolvimento do produto com todas as partes interessadas e equipes da organização diretamente envolvidas ou associadas ao uso e / ou desenvolvimento do produto.

O que é design por comitê?

Design por comitê é quando todas as partes interessadas têm responsabilidade igual pelo design do produto. Esse método, típico de organizações empresariais, é lento e costuma causar complexidade significativa (e muitas vezes hostilidade) entre várias partes interessadas e equipes.

O que é desenvolvimento de produto colaborativo?

O desenvolvimento de produto colaborativo é o processo em que os designers promovem métodos centrados no design para as equipes de desenvolvimento de produto, garantindo que todos os membros e partes interessadas tenham a oportunidade de contribuir com seu conhecimento para trabalhar no produto.

Por que é importante colaborar com outras pessoas?

A colaboração dentro do ambiente corporativo remove ineficiências no processo de design e desenvolvimento e economiza tempo significativo ao incluir todas as partes interessadas e equipes de desenvolvimento de produto, eliminando a comunicação de ida e volta e a contabilidade de dados de todas as fontes valiosas.

Qual é a importância da aprendizagem colaborativa?

O aprendizado colaborativo oferece a muitas áreas do negócio uma oportunidade de se envolver diretamente no ciclo de vida de desenvolvimento do produto, aumentando as chances de sucesso a longo prazo. Mais funcionários entendem o produto e esse conhecimento é transferido para novos recursos e produtos futuros.

O que é design colaborativo?

O design colaborativo é um processo de design inclusivo onde os designers trabalham com várias equipes dentro da organização (vendas, especialistas no assunto, etc.) para melhorar o desenvolvimento do produto e o desempenho geral da empresa.