Esta pesquisa, realizada tendo como base artigos, vídeos e palestras a respeito de estruturação e microgerenciamento, tem como objetivo mostrar um pouco como áreas de Product Design e UX Design são organizadas em diferentes empresas nacionais e internacionais.
3. Integração entre áreas
O que PD/UX faz impacta outras áreas
Fonte: Itaú - Itaú Design System
Sim, é importante reunir toda a equipe
para, de maneira conjunta, auxiliar na
definição da organização interna
(handoff, descrições e níveis de cargos,
metodologias, etc.)
Contudo, o maior erro ao realizar essas
definições é pensar apenas em melhorar
ou agradar a equipe de design, deixando
de lado quem é cliente da equipe (POs,
PMs, TI, RH, entre outros).
Google, Slack, Mercado Livre, Itaú, entre
outras empresas, trazem esse alerta para
que equipes de PD/UX/Design não criem
algo de maneira isolada, com uma visão
afunilada sobre o que acreditam ser o
caminho certo.
4. Maturidade da empresa
Nem sempre as pessoas/empresas estão prontas
Fonte: UX Design Blog - UX Maturity
Fonte: NNGorup - DesignOps Maturity
Criar algo para satisfazer o que a equipe de
PD/UX deseja, sem antes medir a maturidade
da empresa pode levar a altos níveis de
decepção a longo prazo.
Empresas que dizem não para um processo
de design ops, mostram que ainda não existe
maturidade para esse tipo de implementação.
Uma maneira de identificar falta de
maturidade é pela falta de integração entre
Produtos e desig
Desenvolvimento e desig
Desenvolvimento e produto
RH e desig
Dados e desig
Entre outros
5. Sair copiando
A grama mais verde do outro lado pode murchar do seu lado
Fonte: Slack - Making a Design Super Team
Fonte: iFood - Design Meetups - DesignOps
Realizar pesquisas para saber como
outras empresas e áreas se organizam ou
quais metodologias usam é o começo,
não a resposta.
Implementações dependem, além da
maturidade, da realidade da empresa.
Ao copiar totalmente o que é feito por
outras empresas, as chances de dar
errado ou das pessoas rejeitarem os
direcionamentos é grande.
O ideal é definir algo específico para
saciar as necessidades, dentro do
possível, para que a equipe atue onde
precisa e não em todas as frentes.
No Slack, por exemplo, usam
primariamente o Double Diamond.
6. Inovação demasiada
Reinventar a roda pode ser uma armadilha
Imagem: Lexica - Futuristic organic shape building
Ter uma identidade própria para a equipe
é interessante, mas isso não pode
extrapolar.
Criar novas estruturas de dinâmicas, tipos
de heurísticas, formatações de abertura
de pedidos, metodologias, etc. para
simplesmente tentar ser diferente, sendo
que já existe algo que funciona, acaba
sendo algo que só toma tempo
desnecessário.
O ideal é, com base na maturidade e
realidade, remover o que não funciona do
que já existe e realizar ajustes pontuais
para saciar as necessidades.
7. Instrumentalidade das formas
A forma é apenas um meio para um resultado
Fonte: Sky - Design System
Fonte: Loft - Design Team
Como apontado por José dos Santos
Carvalho Filho, a existência de um
procedimento formal previamente
organizado (handoff, laudo jurídico, etc.) é
apenas um instrumento utilizado para se
alcançar determinado objetivo.
Assim, não existe só uma maneira ou um
único caminho no processo, mas vários
caminhos que levam à mesma finalidade.
Nesse sentido, o que vale mais é o conteúdo e
não a forma como é apresentado.
Ex.: para tirar um parafuso, você precisa de
uma chave de fenda, pedindo, então, uma
para alguém. Enquanto espera, você usa uma
faca e tira o parafuso. Quando a pessoa volta
com a chave de fenda, você vai apertar o
parafuso novamente apenas para utilizar a
ferramenta correta?
8. Instrumentalidade das formas
A forma é apenas um meio para um resultado
Fonte: Sky - Design System
Fonte: Loft - Design Team
Logo, ainda que um handoff não esteja
preenchido de forma 100% correta, mas
todo o processo de desenvolvimento foi
alcançado como esperado, isso não quer
dizer, necessariamente, que exista uma
falha no processo. Ao mesmo tempo, a
escolha de como entregar algo é
indiferente, desde que o conteúdo seja
válido e a forma realmente estritamente
necessária.
Ex.: PD decide que a entrega de texto vai
ser por Notion, mas TI e POs querem que
seja por Word. Se não existirem diferenças
funcionais no recebimento e compreensão
do conteúdo, a forma é indiferente. Mas ao
mesmo tempo, atualmente é necessário
usar o Figma para entregar os fluxos,
porque é a ferramenta técnica adquirida
para UX, mas poderia ter sido o Zeplin.
10. Design Ops
De acordo com o Nielsen Norman Group
Fonte: NN Group - 3 Steps for Getting Started with DesignOps
Para medir a maturidade e realizar as
aplicações, o NN Group aconselha que sejam
seguidos esse três passos:
1 - Pesquisar o espaço do problema:
identificar pontos problemáticos operacionais
na equipe de design e nas áreas parceiras
2- Definir o valor do DesignOps: definir o
significado e a função do DesignOps
específico para o conjunto exclusivo de pontos
problemáticos da organização
3- Priorizar e traçar um roteiro: priorizar
metas e planejar atividades táticas iniciais
dentro de um cronograma gerenciável
O iFood é uma das muitas empresas que
seguiram esse processo.
11. 1 - Pesquisar
Para entender a maturidade
Antes de qualquer coisa, é preciso dar um
passo atrás e entender como PD/UX
É visto por outras área
Integra-se com outras área
Identifica-s
Organiza-s
Atua atualment
Pode auxiliar outras área
Pode deixar de atuar em algumas área
Compartilha conhecimento
Compartilha resultado
Entre outros
Para isso, é recomendado realizar uma
pesquisa internamente e também com
áreas clientes e correlatas para identificar
esses e outros pontos.
Fonte: NN Group - 3 Steps for Getting Started with DesignOps
12. União
De acordo com o Nielsen Norman Group
Fonte: NN Group - DesignOps: Study Guide
Como trabalhamos de maneira conjunta:
como as equipes se organizam e se
alinham em torno de responsabilidades
compartilhadas, estabelecem medidas
eficazes de colaboração e permitem o
desenvolvimento das pessoas
funcionárias.
Isso inclui:
Estruturas de relatórios e modelos de
equipe da equipe de U
Processos de contratação e integração
para membros da equipe de U
Reuniões e colaboração de UX
13. Processo
De acordo com o Nielsen Norman Group
Fonte: NN Group - DesignOps: Study Guide
Como realizamos o trabalho: como as
equipes usam processos para alcançar
uma qualidade de design consistente,
estabelecer repositórios para
compartilhamento de conhecimento e
eficiência e priorizar projetos de forma
eficaz.
Isso inclui
Recursos centralizados de UX, como
sistemas de design e repositórios de
pesquis
Métodos para priorizar projetos,
solicitações e o que UX estiver devendo
de entrega
O processo de design de UX e os
métodos de pesquisa usados
14. Impacto
De acordo com o Nielsen Norman Group
Fonte: NN Group - DesignOps: Study Guide
Como nosso trabalho cria impacto: como
as equipes medem o trabalho de design,
partilham e recompensam o sucesso da
equipe e permitem que outras pessoas,
mesmo de fora da equipe, aprendem e
utilizam os processos e pesquisa de
design.
Isso inclui
Acompanhamento de melhorias de UX
ao longo do temp
Calculando o ROI de U
Comunicando o valor de UX para outras
pessoas
15. 2 - Definir
Nada de abraçar o mundo Com base na pesquisa, é possível encontrar
os principais pontos de dificuldade e os
potenciais de PD/UX na organização.
Importante: encontrar vários pontos de atrito
é normal, enquanto encontrar nenhum é sinal
de que a pesquisa não foi feita corretamente.
Com essas descobertas, é preciso selecionar
aquelas que tenham maior preocupação ou
importância, de maneira a não marcar tudo
como definição.
Em seguida, é recomendado atribuir um mais
aspectos para pessoas específicas. Isso ficará
a cargo da liderança? Dividido dentro da
equipe? Será contratada uma pessoa
específica para isso?
Fonte: iFood - Design Meetups - DesignOps
Fonte: NN Group - 3 Steps for Getting Started with DesignOps
16. 3 - Priorizar
Traçando o caminho para um futuro melhor Por fim, é hora de separar os pontos críticos,
analisar o que pode ser feito para melhorá-los
e em quanto tempo se espera que os
resultados comecem a transparecer.
Ex.
Problema: páginas sobem com
formatação (cores, fontes, transições, etc.)
diferentes do que foi entregue no handoff,
porque a equipe de TI não consegue
encontrar ou aplicar esses detalhe
Solução: entender as dificuldades de TI,
rever estruturação do handoff, trazer TI
para mais perto de PD/UX durante as fases
iniciais de ideaçã
Tempo: em 3 meses entender os detalhes
dos problemas, em 6 meses ter um handoff
que funciona para ambas as áreas, em 12
meses ter união total entre TI e PD/UX
Fonte: NN Group - 3 Steps for Getting Started with DesignOps
17. Design Leadership Framework
Desenvolvimento de equipe, cultura e organização
Fonte: Katharina Weber - The Design Leadership Framework
Notando que muitas empresas lutam para
realmente unir as “forças” de design para
oferecer uma experiência holística de ponta
a ponta dentro da organização, Khatarina
Weber, professora universitária e especialista
em UX, desenvolvou esse framework.
Ele oferece uma visão geral concisa dos
aspectos mais importantes a serem
observados ao liderar e gerenciar uma equipe
de design.
Serve como uma bússola prática numa era
digital, quando o design precisa ser tanto um
motor de inovação quanto um suporte
eficiente para o desenvolvimento de produtos.
18. Design Leadership Framework
Desenvolvimento de equipe, cultura e organização
Fonte: Katharina Weber - The Design Leadership Framework
De maneira semelhante ao framework do NN
Group, a proposta da Katherine serve para
identificar os pontos críticos que merecem
atenção e maturidade da empresa, assim
como assegurar que as pessoas estão nos
cargos certos de acordo com suas
capacidades e desejos.
19. PD e UX em Big Techs
Como é a organização lá fora
21. Slack
Processos asssícronos agilizam o dia a dia
Fonte: Slack - Meetings that work (and don’t) in Slack
Daily
As equipes, incluindo PD, não realizam
reuniões presenciais ou on-line para a daily.
Todo o processo é feito de maneira
assíncrona, com o auxílio do Slackbot.
A ideia é economizar tempo, que sejam 15
minutos ou 1h, dependendo do tamanho da
equipe, assim como desviar demais o foco da
equipe.
Revisão e aprovação
Dependendo do escopo, realizam apenas o
envio da URL ou fazem upload de mockups e
artes para que a equipe envie comentários
por texto ou reaja por emojis.
A ideia é proporcionar uma rápida discussão
a respeito de refinamentos e, então, seguir em
frente, ao invés de realizr longas reuniões para
fazer a mesma coisa.
22. Slack
Processos asssícronos agilizam o dia a dia
Fonte: Slack - Meetings that work (and don’t) in Slack
Brainstorming
Reunião de 30 minutos, feita totalmente
por texto, para que as pessoas escrevam
todas as ideias que tiverem a respeito do
assunto.
A ideia é evitar momentos em que as
pessoas falam por cima umas das outras,
assim como auxiliar pessoas que
naturalmente não se sentem confortáveis
em falar tanto. Quem perde a reunião,
pode ler o que o restante enviou, podendo
enviar suas próprias ideias.
As ideias mais votadas podem então ser
compiladas em uma ata antes de dar
continuidade no processo.
23. Slack
Deixar tudo para depois só traz prejuízos
Fonte: Slack - Sweating the small stuff
Customer love sprint
Para que correções de bugs e refinos não
acabem sempre ficando para depois,
reservam duas semanas a cada trimestre
para que POs, Devs e UX tratem apenas de
pequenos problemas e necessidade de
melhorias que foram se acumulando.
Criaram um canal próprio para que
enviem bugs detectados. Estes são então
analisados e priorizados de maneira
conjunta para essa próxima sprint
especial.
24. Apple
Menos é mais a longo prazo
Fonte: Inc. - Steve Job’s 3-Point formula
3-point formula
Para Steve Jobs, o trabalho é o que faz os
negócios funcionarem, considerando-o prioridade
número 1. As reuniões devem apoiar o trabalho e
quando não fazem isso, tornam-se uma perda de
tempo que prejudica a produtividade.
Essa fórmula segue as seguintes diretrizes
Mantenha a lista de convite pequena, com três
a cinco pessoas: isso evita que pessoas falem
por cima umas das outra
Mantenha a agenda curta, com não mais do
que três itens: isso evita que os assuntos
acabem se dispersando demai
Mantenha a duração até 30 minutos: isso
porque nossa resistência mental é incapaz de
sustentar uma discussão analítica significativa
por muito tempo
Com base nessa perspectiva, Steve Jobs recusou
diversas reuniões, inclusive com o então
presidente Barack Obama.
25. iFood
Facilitando a colaboração em menos reuniões
Fonte: iFood - Design Meetups - DesignOps
Antes, cada encontro era utilizado para para
realizar o acompanhamento das demandas e
discutir assuntos de interesse de cada contexto.
Notaram que era preciso trabalhar em unidade
sob uma visão mais sólida, eficiente e eficaz.
Com isso, uniram as tribos internas, centralizando
os assuntos apenas em “web e mobile”, onde, em
1h ou 1h30, todas as pessoas falam aquilo que
impacta no todo, mesmo que façam parte de
squads separadas.
Esses encontros também deixaram de ser apenas
sobre falar de algo, para realmente ser um hands-
on e as pessoas trabalhem no projeto com
participação de toda a equipe.
No processo de reestruturação também
eliminaram a daily e a weekly, para reduzir o
tempo em que as pessoas ficavam passando
updates para realmente focarem no trabalho.
26. iFood
Facilitando a colaboração em menos reuniões
Fonte: iFood - Design Meetups - DesignOps
Substituíram o tempo de troca de updates de
projetos para focar em trabalhar em priorizações
de projetos, construir roadmap, melhorar
organização interna e definir objetivos
profissionais.
Além disso, onboarding, apresentações,
compartilhamento de conhecimento, vídeos
tutoriais, etc., são feitos de maneira assíncrona,
com a pessoa gravando seu próprio vídeo ou
compartilhando artigos dentro de uma
plataforma específica, tipo EAD, que pode ser
acessada por qualquer pessoa da empresa
quando quiser.
27. Loft
Diversão tem que estar presente de algum jeito
Na Loft, separam os ritos que tem participação apenas
da equipe de design da seguinte maneira:
Segund
Critiqu
Touchpoint: falar sobre novidades da empresa, tirar
dúvidas de projetos, dizer coisas que estão
incomodando, etc.
Terç
Reunião pontual para falar sobre algum projeto
Quart
Reunião pontual para falar sobre algum projet
DesignFlix: assistem algum filme ou documentário
sobre design e comentam a respeito
Quint
Design Talks: momento para compartilhar
conhecimento entre a equipe
Sext
Reunião pontual para falar sobre algum projet
1:1: marcado entre liderança e entre pessoas da
equipe, caso queiram participar
Fonte: Loft - Design Team
28. Loft
Diversão tem que estar presente de algum jeito
Na Loft, separam os ritos que tem participação
da equipe de design, POs e TI da seguinte
maneira:
Segund
Weekly
Terç
Retr
Mortgagner: conversa para falar do
andamento de algum projeto
Quart
Critique
Quint
Mortganning: planning da próxima sprint
Sext
Mortgagner: conversa para falar do
andamento de algum projeto
Fonte: Loft - Design Team
29. Mercado Livre
Autonomia + responsabilidade = aprendizado
No Mercado Livre, a equipe de design não
trabalha em squads e tem dois ritos principais
Planning: feito na sexta antes do início da
sprint, que tem duração de uma seman
Retro: feita na sexta, ao final da sprint
De resto, com participações externas, possuem
Reuniões de kick-off com POs e TI: participam
desde o começo para saberem os detalhes
de novos projetos que estão por vi
Definição de cronograma com POs e TI: de
acordo com as prioridades, definem em qual
trimestre vão se dedicar a cada projet
Entendimento de problema com pessoas
usuárias: entrevistas para entender os
problemas enfrentado
Definição e validação com pessoas usuárias
e POs: criam e então apresentam a solução
para quem vai utilizar conseguir testar e para
requisitantes aprovare
Acompanhar resultados: todas as equipes
conversam entre si para compartilharem os
resultados identificados
Fonte: UX Team Summit - Palestra | Time Mercado Livre
30. Google
Ouvir as pessoas para criar uma cultura forte
Após pesquisas internas e externas, o Google
notou que as pessoas da equipe de design
ficavam mais tempo em reuniões do que
realmente criando as soluções que estudaram
por tanto tempo para fazer em empresas.
Com isso, dividiram internamente a equipe em
especializações, que serão apresentadas
adiante.
As pesquisas também mostraram que uma
cultura forte, assim como liberdade no uso de
determinadas ferramentas e flexibilizações são
mais atraentes do que um salário alto.
Fonte: Design MBA - Breaking into Design Ops | Google
31. Google
Ouvir as pessoas para criar uma cultura forte
Practice operations (Designer): é quem realmente
faz o design e planeja como pode otimizar a
eficiência do trabalho. Pensa em formas de
garantir que POs e Devs recebam os handoffs da
melhor maneira possível para que os entenda
Product management (Liderança): é quem
organiza as demandas e garante que a equipe
está alcançando os objetivos. Abre e organiza o
Jira para verificar se não existem demandas
demais para a equipe no geral ou para uma
pessoa específica. Conversa com requisitantes
para organizar as demandas, organiza a
quantidade de reuniões com POs e Devs, marca e
reorganiza os ritos e faz feedback
Organization operations (Org Ops): é quem dá
suporte para a liderança. Trata de cultura
(contratação, demissão, onboarding, experiência
de equipe, newsletter, AMAs, fireside panel). No
Google isso não fica exclusivamente com o RH
Fonte: Design MBA - Breaking into Design Ops | Google
32. Stripe
Foco no desenvolvimento e integração
Na Stripe, a equipe de design separa vários horários
de “heads down” para focar apenas no trabalho.
Como as sprints são semanais, a Weekly é realizada
na segunda para que as pessoas digam como foi a
semana anterior.
Critiques são feitos nas terças, quartas e quintas.
Realizam “syncs”, que são reuniões de updates, com
participação de POs, Devs ou até mesmo com
pessoas do jurídico, caso seja necessário.
Por fim, na Stripe a equipe de design não realiza
daily.
Fonte: A day in the life of a UX Designer
33. Zendesk
Um pouco de flexibilidade na agenda
O Zendesk também é uma das empresas que
eliminou a daily na rotina de trabalho.
Na segunda, que é início de uma nova sprint, ou na
terça, realizam a Weekly Design Standup para falar
sobre o que aconteceu na semana anterior, tirar
dúvidas de projetos em aberto, se é necessário
marcar reunião de alinhamento com POs, etc.
Além dessa weekly, fazem outra com participação de
Devs para mostrar o que design está preparando no
Figma ou para Devs tirem dúvidas sobre a
implementação do projeto.
Em projetos longos ou complexos, realizam uma série
de reuniões, que podem levar o dia inteiro, com
participação de diversas áreas para que todas as
pessoas estejam alinhadas.
Quarta-feira é o dia proibido de marcar reuniões,
independentemente do assunto que precise ser
tratado.
Uma vez por semana realizam critique com
participação de POs e Devs.
Fonte: A day in the life of a UX Designer in San Francisco
35. Ter uma identidade
A melhor forma de se destacar
Imagem: Lexica - Artwork of human-computer interaction
Algo em comum entre as equipes de PD/
UX de várias empresas e que todas
possuem seus valores, princícios, desejos,
etc., bem definidos para mostrar sua
própria personalidade.
Isso faz com que tenham um
reconhecimento mais rápido
internamente, considerando a maneira
como se comunicam e organizam, e
ampliam a maneira como recrutam novos
talentos, considerando como
compartilham suas derrotas e vitórias.
36. Slack
Slack Kit
Fonte: Slack - The Gradual Design System: How We Built Slack Kit
No Slack, seguem a diretriz de “impacto por
processo”, que engloba componentes e
entregas, para mostrar o valor de PD. O Slack Kit
tem como objetivo ser
Robusto: devem ter uma ótima aparência,
representando os altos padrões que
estabelecemos para o design de nossos
produto
Acessível: devem funcionar para todas os
pessoas usuárias, independentemente de
como navegam e interagem com nosso
softwar
Flexível: devem suportar uma variedade de
casos de uso em nosso produto, ao mesmo
tempo que oferecem suporte à
extensibilidade futur
Confiável: devem ser bem testados,
confiáveis e responder imediatamente à
interação do usuário
37. Slack
Os pilares de Product Design
Fonte: Slack - Pillars of Digital Product Design
No Slack, a equipe de PD definiu três grandes
direcionamentos que são subdividos em ideias
menores:
1 - Resolução de problemas centrada no pessoa
usuári
Empatia: pensar em todas as pessoas e não
só no público principa
Metas e anti-metas: pensar no que quer
alcançar e o que quer evita
Enquadramento do problema: descobrir de
verdade os motivos das falhas e não supo
Geração de ideias: trabalhar em conjunto,
mesmo que envolva pessoas de squads
diferentes, traz ideias melhore
Testes, feedback e validação: ter
compreensão de para quem você está
projetando, os problemas que enfrentam e as
oportunidades para resolvê-los, como
escolher o caminho certo e se vai funcionar
ou não (usam muito os formulários de
pesquisa da Amazon)
38. Slack
Os pilares de Product Design
Fonte: Slack - Pillars of Digital Product Design
2 - Interface de uso e design de experiênci
Design de experiência (UX) e fluxos: pensar
primeiro nos múltiplos fluxos de navegação
par depois desenvolver tela
Design de marca, visual e interface: pensar
nas cores, fontes, tom de voz, público, etc.,
para criar algo unificad
Design de movimento e interação: pensar
como hovers, cliques, transições, animações,
etc., comportam-se em fluxos de diferentes
tamanho
Design de conteúdo: pensar em como ajudar
a orientar, explicando coisas que podem ser
confusas e ajudando a informar sobre erros
importantes ou estados de sucesso após a
conclusão da taref
Acessibilidade: pensar no uso por pessoas
com deficiências (visuais, auditivas, motoras,
cerebrais), assim como neurodivergências e
temporárias
39. Slack
Os pilares de Product Design
Fonte: Slack - Pillars of Digital Product Design
3 - Colaboração e comunicaçã
Documentação: quando PDs pensam em
ideias, esboçam e iteram, tomam muitas
decisões implícitas em suas cabeças. É
importante ser capaz de narrar
explicitamente essas decisões de uma forma
que faça sentido para as pessoas que, sem
dúvida, serão impactadas por essas decisões,
como a equipe de desenvolviment
Feedback e alinhamento: realizar critique de
projetos, não apenas internamente, para
desenvolver projetos ainda mais alinhados
com os objetivos da empres
Colaboração com TI: trabalhar em parceria
com equipe de desenvolvimento desde o
começo para que ambas as partes saibam o
que é possível ou não de fazer e a entrega
seja mais assertiva
40. Slack
Os pilares de Product Design
Fonte: Slack - Making a Design Super Team
Além disso, os valores que definem a equipe de PD são:
1 - Facilitaçã
Ajudar a equipe, fazendo com que ideias se tornem
tangívei
Deixar claro quais são as metas e não-meta
Conferir o entendiment
Mensagem: PD traduz ideias por meio de telas e fluxos
2 - Administraçã
Proteger e promover processos criativo
Proteger ideias nascentes (patinho feio
Espalhar a perspectiva da pessoa usuári
Mensagem: criar ideações antes de ter o produto final
é ok
3 - Conheciment
Eleve o nível da equip
Mantenha o nível de qualidad
Conheça o mei
Mensagem: não existe o melhor design, mas sim o
que é mais apropriado para o produto e/ou momento,
com o correto sendo pensar primeiro em qualidade
para a pessoa usuária, depois nos benefícios para a
empresa e depois em beleza
41. Airbnb
Como fazer um design eficaz em escala
Fonte: Airbnb - DesignOps at Airbnb
No Airbnb, sintetizaram os valores e organização
interna da equipe de PD em uma declaração ao
invés de apresentar uma lista.
Nossa missão é proporcionar agilidade a toda a
organização do produto por meio de
ferramentas, sistemas e serviços centralizados
que melhorem a velocidade e a qualidade da
execução.
Nossas funções incluem gerenciamento de
programas de design, ferramentas de design,
localização, design de produção e coordenação
de equipe.
Trabalhamos em estreita colaboração com
Marketing, Produto, Design e Desenvolvimento
para criar as melhores experiências possíveis.
42. iFood
Desenvolvendo a receita da organização
Fonte: iFood - Design Meetups - DesignOps
No iFood, possuem 10 práticas que guiam
a equipe e que sintetizaram em uma
declaração.
Trabalhamos para atender Tech (design,
dev e produto) a partir das frentes de
Consistência, Organização de processos,
Estratégia de design e Governança de
ferramentas e assim, entregar como valor
retenção de pessoas, uma otimização de
trabalho de design, uma maior
consistência de design, mais qualidade
de vida para profissionais de tech, além de
fomentar uma cultura de design dentro
da empresa.
43. Loft
Uma visão baseada em respeito mútuo
Na Loft, no topo de qualquer contexto, o que mais
priorizam é essa mentalidade:
“Pessoas acima de processos
Priorizamos as pessoas acima de processos.
Dentro e fora do time.”
Ou seja, caso algum processo funcione apenas
para a equipe de design, mas exista dificuldade
em seguir dessa forma por parte de POs, Devs,
etc., ou mesmo se algum rito gera desconforto,
pensam em uma maneira de reestruturar e
acomodar da melhor maneira possível.
Ao mesmo tempo, possuem uma série de
valores que direcionam a forma como
trabalham.
Fonte: Loft - Design Team
44. Loft
Uma visão baseada em respeito mútuo
Os valores da equipe de UX da Loft são
Curiosidade: sempre querendo saber mai
Pensamento holístico: focando no todo, não
só em parte
Humildade: abandonar o ego (tem foco um
pouco maior para a liderança
Construir comunidade: apoiar ativamente
colega
Saber ouvir: tirando você da equação (tem
ligação com empatia com pessoa usuária e
não supor sem ter dados
Senso de humor: habilidade mais
subestimada, porém precisa ter equilíbri
Procrastinar: item polêmico, porém
necessário (nem quem você idolatra, de
qualquer área de atuação, faz tudo a todo
momento, então cobrar e colocar pressão
não é saudável, porque cada pessoa tem seu
estilo de trabalho e entrega, desde que não
prejudique o prazo final)
Fonte: Loft - Design Team
45. Spotify
O básico que se espera de UX
No Spotify, a equipe de PD segue três valores
Colaboração: PD não faz o trabalho de
maneira isolada, precisando ter apoio de POs
e Devs quando necessário, assim como ter
consciência que seu trabalho pode impactar
no trabalho de outras pessoa
Curiosidade: querer aprender e também
vontade de entender como diferentes
pessoas usuárias usam o mesmo produto em
locais, sistemas, horas diferentes, etc
Empatia: principalmente para explicar as
motivações de design em seguir pelo
caminho de usabilidade, em detrimento de
certos pedidos específicos que podem ir por
um caminho contrário às necessidades da
pessoa usuária
Fonte: Spotify - Product Design at Spotify
Imagem: Lexica - Music notes
46. Google
Cuidado com a palavra com P
No Google, existe uma piada interna de que
muitas pessoas não gostam da palavra
processo, por acharem que burocratização mais
atrapalha do que ajuda.
Ainda assim, a equipe de design se baseia em
alguns pilares, chamados de “tags”
System thinking: pensar no todo e não em
momentos individuai
Trabalho em equipe: saber ouvir, saber usar
dados para tomar decisões, saber fazer
pesquisa
Design system: aplicar design thinking,
double diamond, etc., para padronizar a
forma de trabalh
Empatia: pensar sempre primeiro nas
necessidades de quem vai utilizar a soluçã
Saber dizer não: algumas ideias podem não
ser corretas ou não é o momento certo para
aplicá-las
Fonte: Design MBA - Breaking into Design Ops | Google
Imagem: Lexica - A phone on a table
47. Slack, Loft, Google, Spotify...
Mesmo pensamento em diferentes locais
Fonte: Slack - Making a Design Super Team
Um senso comum é que as equipes de PD/UX/
Design precisam participar das conversas
sobre projeto, solução, etc., desde o começo.
O maior erro é ativar essas equipes apenas por
meio de briefings, depois que tudo foi decidido,
para que simplesmente executem determinada
ação.
Quanto maior for o contexto e mais cedo ele for
repassado, melhor. Dessa forma, essas equipes
conseguem sair de uma reunião inicial já
sabendo de decisões, objetivos e expectativas.
Todas as equipes envolvidas, idealmente, devem
pensar se
Essa é a melhor implementação
Essa é a melhor solução
Esse é o melhor caminho
Esse é o real problema?
48. Slack, iFood, Google, Spotify...
Alocar talentos de acordo com seus talentos
Para várias Big Techs, a ideia de ter pessoas
generalistas nas equipes vem perdendo peso.
Durante o processo de integração e aprendizado,
tudo bem ser generalista temporariamente, mas
depois o ideal é se especializar em algo que
mais gosta.
Pensamento: “se você faz bem alguma coisa,
mas não gosta, então não é uma especialização.
É algo que vai gerar burnout.” - Kyle Turman,
Diretor de Infraestrutura de Design
Fonte: Katharina Weber - The Design Leadership Framework
50. Estruturação final
Documentar tudo para organizar
Fonte: Guide - UX Product Design Playbook
Fonte: Valve - New Employee Handbook
Fonte: iFood - Deck de Cultura
Com todas as descobertas, diretrizes,
direcionamento e valores definidos, é preciso
colocar tudo em um registro, que pode ser
chamado de Handbook, Playbook, Guidelines,
ou como a equipe achar melhor.
Retomando a ideia da instrumentabilidade
das formas, muitas vezes o ideal é não se
prender no preciosismo do local onde isso
será publicado, desde que o conteúdo possa
ser entendido e o material cumpra seu
propósito.
Algumas áreas publicam no Notion ou em
seus próprios sites (nesse formato costumam
ter mais de 300 páginas), fechado em PDF
como apresentação ou formatado como
ebook (de maneira resumida), etc., assim
como podem aplicar um layout todo
customizado ou seguir com algo mais
simples.
51. Estruturação final
Documentar tudo para organizar
Fonte: PD Team - Encontros PD Team
Hoje, muitas equipes, sejam PD ou UX,
utilizam do Confluence, que é uma
plataforma totalmente válida para esses
registros.
Se a intenção é que isso seja algo
totalmente interno, essa é uma escolha
perfeita.
Agora, caso a vontade seja compartilhar
isso além da empresa, como outras
equipes de UX fazem, pode ser que isso
precise ser revisto, considerando que o
Confluence tem travas de acesso externo.