Design Colaborativo - Um Guia para o Design de Produto Empresarial de Sucesso
Publicados: 2022-03-11Você provavelmente já ouviu falar de desenvolvimento de software ágil, gerenciamento de processos Kanban e Lean UX. O design colaborativo é uma abordagem filosófica e tática diferente do design de produtos corporativos .
O design colaborativo é o processo de projetar em um ambiente de confiança participativo, envolvente e realista. 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 um rebanho de gatos. Neste guia, revisaremos dicas e truques para trabalhar com os principais players, não apenas para obter suas opiniões, mas também para trazê-los a bordo com essa nova abordagem centrada no design.
Conheça os jogadores
Designers são ótimos em muitas coisas, mas seu papel começa com a resoluçã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 realmente concluir a tarefa determinada.
Então, sem mais delongas, vamos conhecer a equipe:
- Os gerentes de produto definem o escopo, os requisitos e os ciclos de iteração de desenvolvimento para produtos e recursos; eles costumam ser os guardiões dos recursos antes de um sim/não final e têm prática na comunicação com toda a organização, incluindo executivos.
- Os engenheiros constroem 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 projeto (se nossos conceitos forem possíveis, dadas as limitações de tecnologia e tempo).
- Arquitetos de banco de dados e sistemas 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 construir sobre o produto/plataforma existente.
- Os especialistas internos no assunto (SMEs) estão intimamente familiarizados com os processos de negócios, casos de uso, histórico e política, bem como as expectativas gerais de gerenciamento, clientes e usuários.
- As vendas se concentram em apresentar o produto a clientes em potencial. Isso torna as vendas o primeiro ponto de contato, portanto, sua compreensão do produto é fundamental para fechar (e muitas vezes criar) leads.
- Os instrutores (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 volumes de informações úteis sobre o desempenho do produto in 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 Agile), o produto resultante tem uma chance significativamente maior de alcançar o sucesso – não porque os designers estão trabalhando com os stakeholders, mas porque os stakeholders, mais frequentemente do que não, entender as necessidades específicas do usuário e da empresa de uma forma que não podemos. Trabalhar de forma colaborativa sempre parece ser a melhor opção, mas como fazer isso?
Como colaborar com as partes interessadas
Gerentes de produto, guardiões do portão e do tempo do produto
Os gerentes de produto geralmente têm um apego pessoal ao produto e têm expectativas muito altas dentro da empresa. Eles também precisam responder aos usuários ou clientes de seu(s) produto(s) quando houver problemas, promessas não cumpridas ou solicitações de uma nova funcionalidade.
Eles valorizam muito a comunicação simples e precisam ser mantidos atualizados sobre o progresso, problemas e quaisquer alterações. Eles gostam de ver os rascunhos primeiro e com frequência e, como podem trabalhar em várias escalas (vários níveis, desde o desenvolvimento direto do produto até a prática com pequenas alterações), suas interações com eles podem variar muito.
Como os PMs gastam 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 saber quais são seus objetivos para a funcionalidade do produto. Os PMs sabem que os 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 constroem! Isso lhes dá uma vantagem porque eles experimentam e testam diretamente componentes individuais do produto em ação . Isso é ótimo porque, sem dúvida, eles encontrarão as fraquezas em qualquer projeto – às vezes antes de construir qualquer coisa – o que é duplamente ótimo porque é uma grande vantagem em tantos 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 produtos abrangentes e completas ou envolvê-los desde o início... ou ambos.
Quando os desenvolvedores são considerados verdadeiros interessados , 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 interesse em resolver problemas com o designer, especialmente quando o desafio é difícil ou pode ser tratado de outra maneira.
Arquitetos de banco de dados e sistemas, guardiões de estruturas de dados
Arquitetos de banco de dados e sistemas 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 responsáveis).
Eles podem ser especialmente difíceis para designers centrados no usuário lidarem com eles. É 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 entrada 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 entra em conflito com alguma entrada/saída do usuário existente?
- Algum serviço externo é afetado pelo recurso X?
Esta lista simples o direcionará na direção certa, mesmo sem uma compreensão clara de como funcionam as estruturas de dados monolíticas pré-existentes (e possivelmente). 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ções
Especialistas no assunto são apropriadamente nomeados; eles são especialistas no assunto e podem ser uma mina de ouro de informações únicas e valiosas. Muitas vezes, eles obtiveram diplomas especializados 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 lembram a longa e dolorosa história e 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 cumpre 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 gerência para garantir que as expectativas internas estejam sendo atendidas e que você não esteja 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 que compartilhem seu conhecimento sobre falhas históricas, conflitos políticos e outros problemas que podem ser críticos para o lançamento de um produto bem-sucedido.
Gerentes de sucesso do cliente, o ponto de contato de um novo cliente
Quando novos clientes são finalmente integrados pelas vendas, os treinadores – ou, para empresas de SaaS, os gerentes de sucesso do cliente (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 iniciantes. 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 instrutores/CSMs podem fornecer informações valiosas para decisões de design, tanto para integração do cliente quanto para o comportamento de novos usuários. Muitas organizações empresariais rastreiam e monitoram como seus novos clientes usam vários produtos e registram tudo, desde chamadas a 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 principais reclamações de clientes mais sérias?” e "Os novos clientes estão, em média, satisfeitos com o produto?" e "Que mudanças você acha que trarão o maior impacto positivo para você e sua equipe?" Dessa forma, todos aprendemos sobre o que é o caminho feliz; os treinadores são nossos olhos e ouvidos para todas as maneiras pelas quais os clientes realmente usam o produto.
Vendas, o primeiro contato do produto com os clientes
Vendas e design geralmente estão em desacordo. Algumas organizações são orientadas para as vendas, enquanto outras não, mas não importa o que aconteça, há uma clara diferença de objetivos: a equipe de vendas deseja aumentar as vendas, enquanto o design deseja melhorar a experiência do usuário. Nem sempre se alinham.
Isso não tem que ser o caso. A maioria dos vendedores tem queixas muito razoáveis para enfrentar: 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 de receita específicas apesar de tudo. Não é 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, muitas vezes, essa perspectiva é a diferença entre fazer uma pequena venda e trazer uma baleia! Entenda as diferentes áreas com as quais a equipe de vendas luta. Tente participar de todos os tipos de chamadas e aprenda como esses clientes potenciais se comunicam.
Isso abrirá a conversa com as vendas. Não se trata apenas de ouvir suas necessidades; trata-se de melhorar a experiência dos usuários em potencial em todas as etapas, desde a primeira comunicação até a integração. Descubra o que os vendedores mais ouvem dos clientes em potencial, quais desafios eles enfrentam ao finalizar o negócio e quais são as maiores preocupações após o fechamento.
O design na empresa não precisa ser um pesadelo
Como designer, todas essas partes móveis podem ser muito difíceis de gerenciar, especialmente quando você não é considerado um “gerente” no sentido oficial do termo. Como uma das principais partes interessadas na comunicação entre equipes, na coleta de requisitos e no feedback do projeto, 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 seus comentários a sério. Na maioria das organizações, o próximo passo é 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 esse pessoal de seu valor no ciclo de desenvolvimento do produto os abre para fornecer as informações que um designer precisa para tomar melhores decisões de design de produto.
• • •
Leia mais no Blog Toptal Design:
- Práticas recomendadas de design de interface do usuário e erros comuns
- Estados vazios – o aspecto mais negligenciado do UX
- Simplicidade é a chave - Explorando o design mínimo da Web
- Princípios heurísticos para interfaces móveis
- Projetando para legibilidade - um guia para tipografia da Web
