Por que UX Chapter?

Eduardo Horvath
Design Team Zap Viva Real
6 min readMay 6, 2016

O nome não é comum, um tanto estranho até quando traduzido, capítulo. Então afinal, de onde vem o termo UX Chapter?

O termo surge no modelo de processos do Spotify, um modelo Agile que foi construído com o objetivo de tornar os times escaláveis.

O nome Chapter pode ser dado também para qualquer outro grupo que possua competências similares ou trabalhem na mesma área de atuação, tal como Mobile Chapter, Frontend Chapter, Data Chapter, etc.

Mas o modelo vai além do Chapter, possui Squads, Tribes e Guilds, não vou entrar no mérito de explicar o modelo completo e sim como nós do UX Chapter funcionamos.

O modelo do Spotify é assim:

Até o ano passado nós UXers do VivaReal atuávamos em um modelo de time de UX, no qual sentávamos juntos e recebíamos as demandas dos demais times e tínhamos nossos próprios goals, de lá para cá muita coisa mudou, no final do ano a Startup resolveu adotar o modelo Agile do Spotify para também ganharmos mais escalabilidade. E como todos sabemos alterar modelos e implementar processos não é algo fácil, e quando isso acontece, com UX é ainda mais complicado, a nossa realidade muda, porque estamos obviamente inseridos dentro de uma cultura de engenharia, mas a forma como fazemos nossas entregas não é exatamente do mesmo jeito que fazem os engenheiros, e ainda assim precisamos estar alinhados.

Para isso, sempre aplicamos no time a metodologia Lean UX, versátil e adaptável totalmente a qualquer metodologia ágil.

No modelo apresentado do Spotify houve o desafio de crescer o time de User Experience de forma inteligente para atender todos os Squads. Os atuais UXers seriam incorporados a Squads e novos UXers precisariam ser contratados para atender a demanda.

Feito isso, o modelo inicialmente ficou assim:

A proporção real é somente dos UXers, onde temos dois UXers no primeiro Squad devido a alta demanda do mesmo, e então um UXer por Squad nos demais.
No caso dos developers a proporção é apenas ilustrativa, são fronts, backs, etc, e em alguns casos outros tipos de profissionais estão envolvidos no Squad, mas aqui vamos focar nos UXers.

Ok, agora que temos os UXers nos Squads o que muda? Tudo.

Na forma anterior conforme a demanda chegava para atender cada time, os UXers possuiam comunicação entre si, trabalhavam as vezes em pares, e em alguns casos um mesmo UXer conseguia dar conta de duas ou mais demandas ao mesmo tempo. Loucura? Sim, mas sempre foquei em criar times com bastante ownership :)

Agora vamos a análise das perdas e ganhos

Pontos negativos:
* Menor interação do UXer com outro UXer
* Menos contato com outros jobs, tornando o conhecimento mais verticalizado e por sua vez perdendo a visão do todo
* Perda de autonomia para fazer entrevistas com usuários e pesquisas, atividade associada apenas ao Roadmap do Squad

Pontos positivos:
* Maior foco
* Melhor acompanhamento dos resultados do produto
* Proximidade com o Front e com o PM (no modelo Spotify é PO) para validação do que está sendo feito
* Mais controle da qualidade

Com isso em mente o ideal foi tratar os pontos negativos e reverter o quadro para que pudéssemos nos adaptar ao modelo e agir dentro dele.

Dessa forma, a primeira estratégia a ser aplicada foi a criação de um time exclusivo de Research. Esse time é responsável por trazer insumos de pesquisas, análises, etc para os Squads, podendo assim proteger a parte de inteligência de UX, não limitando as atividades a criação de interfaces on demand.

O time de Research ganhou o nome de Research & Usability, porque o foco do time também é as análises de usabilidade, e para que o termo não fosse traduzido ao pé da letra como apenas Pesquisa, a introdução da terminologia ajuda a todos entenderem que Usabilidade faz parte, e como faz.

Feito isso, a nossa estrutura passou a ficar assim:

UX Designer: Responsável por cuidar do seu produto junto ao PM, defendendo a melhor experiência para o usuário, seus insumos são sketches, flows, wireframes (quando necessários), prototypes, e user interface.
Tem skills voltadas ao tipo de produto em que trabalha, web, apps, etc.
No caso do VivaReal, optamos por profissionais híbridos, que são capazes de gerar não somente a ideia do que foi solicitado, rabiscando etc, mas de partir para a alta fidelização de um prototype, sendo também um bom UI Designer. Com isso ganhamos agilidade utilizando ainda o modelo Lean UX.

UX Researcher: Responsável principalmente por entrevistas de usuários, quantitativas (surveys online, etc) ou qualitativas (validações com 5 ou mais usuários). Tratam os dados e disponibilizam aos Squads e em alguns casos a demais Stakeholders. Suas atividades estão intimamente ligadas aos UX Designers que por sua vez também participam de entrevistas, mas essa já previamente preparadas pelos Researchers (ligar, agendar, preparação de survey, etc)

Usability Analyst: Responsável pela qualidade, boas práticas de usabilidade, heurísticas, acompanha o trabalho que está sendo feito nos Squads junto com os UXers.

Essas responsabilidades que citei são um belo de um resumo. Mas serve para explicar o sentido de Chapter. Perceba; por mais que o UX Researcher tenha atividades diferentes do UX Designer, que por sua vez tem atividades diferentes do Usability Analyst, todos tem em comum a área de User Experience, e por isso temos o título de UX Chapter.

O Chapter precisa naturalmente de um Lead, responsável tecnicamente pelo trabalho dos que estão nele, esse por sua vez tem que cuidar do treinamento dos profissionais, garantir sua evolução, e gerar a sintonia entre todos do Chapter. No caso do UX Chapter do VivaReal é esse quem vos escreve.

O desafio de unir pessoas que por sua vez tem apenas UX em comum não é simples, mas se torna uma tarefa possível quando se tem duas coisas bem qualificadas:
Skill + Behaviour

Essas são características existentes nos UXers do VivaReal, uma excelente skill e excelente comportamento, senso de colaboração, união, compartilhamento de conhecimento.

Talvez você esteja pensando nesse momento "Mas aqui o pessoal também tem ótimas skills e excelente comportamento, porque não conseguimos aplicar UX nos projetos como gostaríamos?" São desafios à parte e também temos os nossos. Acredito que não basta isso para a roda girar, é necessário método. Com isso o UX Chapter conta com alguns ritos e métodos para manter o hub de conhecimento funcional.
São eles:

UX Talk: Bate papo toda sexta-feira onde os profissionais rapidamente narram sua experiência da semana. Gerando empatia entre todos e facilitando o conhecimento. Possibilita assim a todos terem clareza dos desafios que estão sendo enfrentados em todos os Squads.

Research Talk: Quinzenal, exclusivo do time de Research & Usability que vista revisar as estratégias do Roadmap, garantir as entregas e analisar se estamos atendendo os Squads. (demais UXers podem, mas não tem o compromisso de participar desse talk)

UX Hack: Quinzenal, tem como foco trabalhar pain points conhecidos e que não estão no Roadmap, mas que são importantes de alguma forma para o negócio e para o usuário. Aqui a dopamina rola solta, o UXer permite a sua criatividade ir ao máximo, podendo radicalizar nas propostas sem aquela restrição causada pelo compromisso das entregas e dos números. Foco exclusivo no usuário.

Peer Validation: Cada UXer do Squad valida seu trabalho com UXer de outro Squad que possui conexão na atividade, isso agiliza o trabalho e gera senso comum no produto, não sendo necessário que todos os UXers vejam o que foi feito para ser validado.

One on One: Quinzenal, bate papo do Lead com o profissional, é onde há o desenvolvimento pessoal, aconselhamento de estratégias e quando necessário até mesmo Life Coach. É a personalização da carreira, entendendo o indivíduo como alguém que tem seus próprios objetivos.

Espero ter esclarecido do que se trata um UX Chapter, e com isso inspirar ou ajudar outros times de User Experience no trabalho de Lean UX e métodos ágeis.

Em outro post vou comentar como começou a criação do time de Research & Usability e como qualquer profissional pode trabalhar de forma real User Experience (deixando de ser somente aquele que faz wireframes), entrevistando usuários e retirando insumos significativos para o seu produto e trazendo resultados de impacto para o negócio.

Fique à vontade para comentar!!!

--

--