Muitas equipes de software lutam para integrar efetivamente o design em um processo ágil. Designers que não trabalham em estreita colaboração com o resto da equipe tendem a gerar trabalho extra para todos (incluindo eles mesmos) e podem criar silos prejudiciais de conhecimento dentro da equipe de produto.
Na Atlassian, trabalhamos de forma colaborativa para incorporar toda a equipe ágil no processo de design. Garantindo que todos estão envolvidos no processo de design, ganhamos várias perspectivas sobre um problema e não dependemos de documentação para compartilhar ideias. Esta apresentação explora como:
- Envolver toda a equipe no processo de design
- Integrar design em um processo ágil
- Obter insights do cliente para criação de ideias e testes mais rápidos
P & R
Essas perguntas e respostas variam de quais ferramentas de design a Atlassian usa a como a Atlassian lida com o feedback dos clientes.
P1: Os designers e desenvolvedores são sempre pessoas diferentes? Com HTML5 e técnicas modernas de interface do usuário, é difícil para os designers não ter habilidades básicas de codificação?
R1: A linha entre designer e desenvolvedores está se tornando menos delineada. Há designer na Atlassian com muita experiência em engenharia e outros que não conseguiam escrever nenhuma linha de código. Temos ótimos designers visuais, arquitetos de informação e facilitadores. Todos têm habilidades diferentes e é importante reconhecer e usar essas habilidades em sua equipe.
P2: As pessoas de fora da equipe de produto participam de workshops de projeto, por exemplo, de marketing?
R2: Nossos workshops abrangem pessoas de diferentes áreas, mas todos estão lá por uma razão. Normalmente, estarão presentes representantes das áreas de PM, engenharia e design, mas podemos encontrar pessoas do departamento de suporte ou marketing se eles puderem incluir outras perspectivas.
Workshops podem durar vários dias, o que pode ser um tempo de comprometimento muito longo. Gostaria de compartilhar a agenda com antecedência para que as pessoas saibam onde podem agregar valor e para onde podem sair por algumas horas. No entanto, você deve ter a participação de um grupo principal durante todo o tempo.
P3: Como você conseguiu que sua equipe trabalhasse no esboço, participasse do desenho e tivesse ideias? Acho que POs e devs estão relutantes em trabalhar nisso, por medo ou outros motivos.
R3: Já é intimidador ter que compartilhar ideias com um grupo, mas fazer esboços em público pode ser ainda pior. É por isso que divido o grupo em duplas para essa etapa do workshop. Isso elimina a pressão de ter uma folha em branco na sua frente. Também permite que as pessoas troquem ideias e mantém o dinamismo.
Achei que depois de participar de uma dessas sessões, todo mundo ficaria confortável com o processo e realmente gostasse de participar. Há sempre um burburinho na sala, com muitas conversas.
Também é importante que todos saibam que você não está procurando por obras-primas. Tudo o que você procura é uma visualização das ideias — isto pode ser um esboço de uma interface, um diagrama ou simplesmente uma lista com marcadores — qualquer coisa que ajude o restante do grupo a chegar a um entendimento comum. Se estiver em papel você também pode mantê-lo para referência após o workshop.
P4: Como manter os novos membros da equipe de design atualizados?
R4: Temos um processo de ambientação para novos membros da equipe de design. Ele começa com uma apresentação sobre design na Atlassian, o processo que a gente segue, e como a gente trabalha com o restante da equipe de produtos. Ele fala também sobre os princípios de design que a gente desenvolveu e mostra exemplos de como isso é colocado em prática. Ele traz treinamentos para aprender mais sobre os recursos de design: uso de personas, as Diretrizes de Design da Atlassian e o Esquema Tático.
Também formamos duplas de novos designers durante as primeiras semanas para mostrar o processo e apresentar mais responsabilidade.
Outra maneira de fazer com que novos designers entrem no ritmo é reuni-los em um workshop durante a primeira semana. É uma ótima maneira de conhecer a equipe de produto e ver, em primeira mão, como trabalhamos juntos. Há muito o que aprender durante os primeiros meses, mas um workshop é um ótimo lugar para aprender e ver um pouco como é um problema grande.
P5: Quais são os métodos de pesquisa de cliente que você acha mais útil? Pesquisa de campo, observação, usabilidade, outros?
R5: Acho que todos os tipos de pesquisa de cliente são úteis, mas tipos diferentes de pesquisa devem ser usados em etapas diversificadas de um projeto.
Por exemplo, no início de um projeto, você deseja obter um completo entendimento do problema e o contexto no qual as pessoas estão trabalhando. Consultas contextuais são realmente úteis para isso — você visita uma equipe no local de trabalho e fala sobre o processo, como o problema afeta a equipe e no que eles precisam ser mais eficazes. É ótimo ver em primeira mão como eles tentam solucionar as tarefas e os problemas que encontram.
Testes de usuário e entrevistas com os clientes são ótimos para quando você desenvolveu um pouco mais suas ideias. Você pode obter insights valiosos observando as pessoas passarem por fluxos usando um protótipo simples ou apenas ao ter uma conversa sobre uma solução proposta.
Por outro lado, o teste A/B é uma maneira impressionante de avaliar como sua solução é eficaz.
P6: Quais ferramentas os designers da Atlassian usam?
A6: Os Designers da Atlassian usam a ferramenta certa para o trabalho. Às vezes, isso pode ser caneta e papel, outras vezes, HTML e CSS.
Para a criação de designs de alta fidelidade, a maioria da equipe usa o Sketch, mas também usamos o Adobe Suite. Todos os elementos de interface do usuário da biblioteca de padrões da Atlassian foram criados como objetos vetoriais, então é muito simples montar um layout básico para a criação. Para prototipagem simples, usamos o InVision ou o Marvel. Para interações mais complexas usaremos o Framer Studio, o Origami, o Axure ou códigos escritos à mão.
Também trabalhamos com muitos post-its e marcações em quadro branco. :)
P7: Quais são alguns dos desafios que você enfrenta trabalhando dentro de uma estrutura ágil?
R7: Aprender a abrir mão da perfeição para fazer um trabalho rápido e iterativo é o maior desafio. Como designer, você quer sempre fazer um trabalho de alta qualidade, mas precisa conseguir enviar algo que está 90% pronto para melhorar depois.
P8: Você mencionou várias maneiras de reduzir a documentação. Que forma de documentação você mantém? Você eliminou toda a documentação?
R8: usamos o Confluence para compartilhar o trabalho em andamento e reunir feedback de uma equipe mais ampla. Uma página comum incluirá contexto sobre o problema que estamos tentando solucionar e o valor que a solução proposta oferece. Haverá fotos de esboços, maquetes de alta fidelidade ou links para protótipos anexados na página para ilustrar uma solução. As pessoas adicionarão comentários e farão perguntas, e o designer publicará designs atualizados à medida que o projeto progride. Não se trata realmente de um local para "manter a documentação", mas sim de uma página em desenvolvimento que coleta feedback e ativos de design.
P9: Como você aborda design distribuído quando uma equipe não está no mesmo local?
R9: A Atlassian é uma empresa global, então trabalhar com equipes distribuídas é algo que vemos todos os dias. No Jira Software, temos equipes em Sydney, Gdansk e Saigon e estamos sempre procurando modos de conectar essas equipes. A tecnologia ajuda muito—usamos o Hipchat para videoconferências e troca de mensagens, o Confluence para publicar, compartilhar e fazer comentários sobre o trabalho e o Jira Software para organizar todo o trabalho. Não é ideal e nada pode substituir a comunicação face a face. Quando possível, tentamos colocar as pessoas na mesma sala para partes cruciais de um projeto. Caso contrário, uma boa prática é comunicar tudo aos colegar remotos e fazer o melhor para mantê-los informados.
P10: Como você controla e filtra "ruídos" que se passam por "feedback do cliente"?
R10: Recebemos vários feedbacks de clientes, o que é ótimo! Temos uma ferramenta de feedback que coleta comentários de usuários e salva esses feedbacks como problemas em um projeto do Jira Software. Passo a primeira parte do meu dia lendo as questões mais recentes ao tomar um café. Enquanto leio os comentários, anoto os padrões ou temas comuns que estão emergindo e adiciono rótulos para agrupá-los. Consigo filtrar todos os feedbacks usando esses rótulos para descobrir quantas pessoas tiveram um problema similar. Então, assim que um padrão é estabelecido, posso levar o problema para a equipe de produtos com casos de uso específicos que podem abordar isso.
