Prévia do material em texto

<p>www.it-ebooks.info</p><p>Traduzido do Inglês para o Português - www.onlinedoctranslator.com</p><p>https://www.onlinedoctranslator.com/pt/?utm_source=onlinedoctranslator&utm_medium=pdf&utm_campaign=attribution</p><p>www.it-ebooks.info</p><p>Louvor paraExperiência do usuário enxuta</p><p>“O Desenvolvimento de Clientes e a Lean Startup mudaram a forma como as empresas</p><p>são construídos, porque mesmo as equipes mais inteligentes não conseguem prever o</p><p>comportamento do mercado e do usuário. Este livro traz ambas as metodologias para UX para que</p><p>você possa criar experiências mais baratas, mais rápidas e, o mais importante, melhores.”</p><p>Alex Osterwalder – Autor e Empreendedor;</p><p>Cofundador, Business Model Foundry GmbH</p><p>“Muitos designers de UX que conheço temem as palavras 'Ágil' ou 'Lean' por causa de</p><p>temem que ameacem o seu processo criativo e baixem os padrões de</p><p>qualidade do seu trabalho. Mas com cada vez mais equipes de</p><p>desenvolvimento de software adotando essas metodologias, é importante</p><p>que a equipe de UX adote essa mudança e encontre maneiras de usar o</p><p>sistema em seu benefício. Neste livro, Jeff Gothelf e Josh Seiden explicam o</p><p>que é Lean UX, por que você deve praticá-lo e como ele pode ajudar você e</p><p>sua equipe a construir produtos melhores (que é disso que se trata, certo?).</p><p>Usando esses princípios, a equipe do RunKeeper quebrou as barreiras</p><p>tradicionais entre engenharia e UX e tornou todos responsáveis pela criação</p><p>de uma experiência de usuário incrível.”</p><p>Tom Boates — vice-presidente, experiência do usuário, RunKeeper</p><p>“Há uma revolução em andamento. É o afastamento do grande design</p><p>equipes especializadas e isoladas jogando documentos uns para os outros por</p><p>cima do muro. Aplicando os princípios das startups Lean, Jeff e Josh expõem os</p><p>princípios do Lean UX, que podem literalmente transformar a maneira como você</p><p>dá vida às experiências. Tenho experiência em primeira mão na aplicação de sua</p><p>sabedoria e estou entusiasmado em levar o Agile para o próximo nível. Pegue</p><p>este livro. Mas o mais importante é colocar este livro em prática.”</p><p>Bill Scott—Sr. Diretor, Engenharia de Interface do Usuário, PayPal, Inc.</p><p>www.it-ebooks.info</p><p>“Se você deseja oferecer ótimas experiências com desenvolvimento ágil</p><p>métodos, pegue este livro! Jeff e Josh compartilham métodos comprovados para</p><p>idealização criativa, planejamento e solução de problemas sem muita bagagem de</p><p>entrega.”</p><p>Christian Crumlish—Diretor de Produto, CloudOn</p><p>“Embora não haja dúvida de que grandes equipes de produtos devem colocar a experiência do usuário</p><p>Com foco no design, muitas equipes têm lutado para conciliar as técnicas e os</p><p>objetivos do design da experiência do usuário com o ritmo e ritmo das</p><p>equipes modernas de desenvolvimento ágil. Lean UX é a coleção de técnicas e</p><p>mentalidade que defendo para equipes de produtos modernas que sabem</p><p>que precisam dos benefícios de ambas.”</p><p>Marty Cagan — Fundador, Grupo de Produtos do Vale do Silício;</p><p>Ex-vice-presidente sênior de produto e design, eBay</p><p>“A paixão de Jeff e Josh por obter UX (e realmente todo o desenvolvimento de produtos)</p><p>mento) aparece poderosamente neste livro detalhado, mas</p><p>eminentemente legível. Os estudos de caso, exemplos e pesquisas servem</p><p>para destacar o poder de construir um processo Lean UX, e há muitos</p><p>conselhos práticos extraídos deles. Estou solicitando uma cópia para</p><p>todos em nossas equipes de design, UX e produto na Moz.”</p><p>Rand Fishkin – CEO e cofundador, Moz</p><p>“Uma combinação fantástica de estudos de caso e conselhos práticos que o seu</p><p>equipe pode usar hoje. Esteja você em uma startup ou em uma empresa Fortune</p><p>500, este livro mudará a maneira como você cria produtos.”</p><p>Laura Klein — Diretora, Usuários Sabem</p><p>“Lean UX fornece uma estrutura prescritiva sobre como construir melhor</p><p>produtos, afastando o design da perfeição de pixels por causa disso, em direção ao</p><p>aprendizado iterativo, esforço mais inteligente e resultados baseados em resultados.</p><p>Gerentes de produto, proprietários de empresas e funcionários de startups – junto com</p><p>designers – podem se beneficiar muito com o Lean UX.”</p><p>Ben Yoskovitz – vice-presidente de produto, GoInstant</p><p>www.it-ebooks.info</p><p>Experiência do usuário enxuta</p><p>Aplicando Princípios Lean a</p><p>Melhore a experiência do usuário</p><p>Jeff Gothelf</p><p>Josh Seiden, editor</p><p>Pequim·Cambridge·Farnham·Colônia·Sebastopol·Tóquio</p><p>www.it-ebooks.info</p><p>Experiência do usuário enxuta</p><p>por Jeff Gothelf</p><p>Direitos autorais © 2013 Jeff Gothelf. Todos os direitos reservados.</p><p>Impresso nos Estados Unidos da América.</p><p>Publicado por O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA</p><p>95472.</p><p>Os livros da O'Reilly podem ser adquiridos para uso educacional, comercial ou promocional de vendas. Edições</p><p>online também estão disponíveis para a maioria dos títulos (http://my.safaribooksonline.com). Para mais</p><p>informações, entre em contato com nosso departamento de vendas corporativo/institucional: (800) 998-9938 ou</p><p>corporativo@oreilly.com.</p><p>Editor de Aquisições:Maria Treseler</p><p>Editor de Desenvolvimento:Josh</p><p>Seiden Editor de produção:Holly</p><p>Bauer Editor de cópia:Nancy Kotari</p><p>Revisor:Jilly Gagnon</p><p>Indexador:Lucie Haskins</p><p>Compositor:Holly Bauer Designer</p><p>de capa:Marcos Paglietti Designer</p><p>de interiores:Ron Bilodeau</p><p>Ilustrador:Kara Ebrahim</p><p>Março de 2013: Primeira edição.</p><p>Histórico de revisões da primeira edição:</p><p>08/02/2013 Primeiro lançamento</p><p>Verhttp://oreilly.com/catalog/errata.csp?isbn=0636920021827para detalhes do lançamento.</p><p>Nutshell Handbook, o logotipo Nutshell Handbook e o logotipo O'Reilly são marcas registradas da</p><p>O'Reilly Media, Inc.Experiência do usuário enxutae imagem comercial relacionada são marcas</p><p>registradas da O'Reilly Media, Inc.</p><p>Muitas das designações utilizadas pelos fabricantes e vendedores para distinguir os seus produtos são</p><p>reivindicadas como marcas comerciais. Onde essas designações aparecem neste livro, e a O'Reilly Media, Inc.</p><p>estava ciente de uma reivindicação de marca registrada, as designações foram impressas em letras maiúsculas</p><p>ou iniciais.</p><p>Embora a editora e o autor tenham tomado cuidado razoável na preparação deste livro, as</p><p>informações nele contidas são distribuídas “como estão” e sem garantias de qualquer tipo. Este</p><p>livro não pretende ser um aconselhamento jurídico ou financeiro e nem todas as</p><p>recomendações podem ser adequadas à sua situação. Consultores jurídicos e financeiros</p><p>profissionais devem ser consultados, conforme necessário. Nem a editora nem o autor serão</p><p>responsáveis por quaisquer custos, despesas ou danos resultantes do uso ou da confiança nas</p><p>informações contidas neste livro.</p><p>ISBN: 978-1-449-31165-0</p><p>[CW]</p><p>www.it-ebooks.info</p><p>Para Carrie, Grace e Sophie</p><p>www.it-ebooks.info</p><p>www.it-ebooks.info</p><p>Conteúdo</p><p>Prefácio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX</p><p>Prefácio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII</p><p>SEÇÃO I: INTRODUÇÃO E PRINCÍPIOS</p><p>Capítulo 1</p><p>Por que Lean UX? . . . . . . . . . . . . . . . . . . . . . . . . . . . 3</p><p>Capítulo 2</p><p>Princípios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5</p><p>SEÇÃO II: PROCESSO</p><p>Capítulo 3</p><p>Visão, enquadramento e resultados . . . . . . . . . . . . . . 17</p><p>Capítulo 4</p><p>Design Colaborativo. . . . . . . . . . . . . . . . . . . . . 33</p><p>capítulo 5</p><p>MVPs e experimentos. . . . . . . . . . . . . . . . . . . . 55</p><p>Capítulo 6</p><p>Feedback e pesquisa . . . . . . . . . . . . . . . . . . . 73</p><p>VII</p><p>www.it-ebooks.info</p><p>SEÇÃO III: FAZENDO FUNCIONAR</p><p>Capítulo 7</p><p>Integrando Lean UX e Agile. . . . . . . . . . . . . . . 95</p><p>Capítulo 8</p><p>Fazendo mudanças organizacionais. . . . . . . . . . . . . . . 109</p><p>Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125</p><p>VIII Conteúdo</p><p>www.it-ebooks.info</p><p>Prefácio</p><p>Em leituraExperiência do usuário enxuta, você está prestes a embarcar em um tour por uma</p><p>nova maneira de trabalhar. Para aqueles de nós imersos em técnicas tradicionais de gestão,</p><p>pode parecer um pouco desorientador. Às vezes gosto de imaginar como seria ter uma</p><p>visão panorâmica de uma típica empresa moderna. Do alto,</p><p>modelo e preenchê-lo:</p><p>Nós acreditamos que</p><p>criando um sistema de comunicação eficiente dentro da experiência do</p><p>produto TheLadders</p><p>para recrutadores e empregadores</p><p>alcançará uma taxa mais alta de sucesso de contato e um aumento na satisfação</p><p>do produto.</p><p>Saberemos que isto é verdade quando observarmos um aumento no número de</p><p>respostas de candidatos a emprego a contactos de recrutadores e um aumento no</p><p>número de mensagens iniciadas por recrutadores no nosso sistema.</p><p>24 Capítulo 3</p><p>www.it-ebooks.info</p><p>A importância dos benchmarks</p><p>Lembre-se de que nenhuma de suas métricas será significativa se você não tiver um benchmark</p><p>definido antes de escrever suas hipóteses. Esse benchmark – o estado atual das métricas que você</p><p>está usando para determinar o sucesso da sua ideia – precisa ser capturado com antecedência</p><p>para garantir que a equipe saiba o que está almejando.</p><p>Completando suas declarações de hipóteses</p><p>Para criar suas declarações de hipóteses, comece a montar os blocos de construção.</p><p>Monte uma lista deresultadosvocê está tentando criar, uma definição do</p><p>personalidadesvocê está tentando atender e um conjunto decaracterísticasvocê</p><p>acredita que pode funcionar nesta situação. Depois de obter toda essa matéria-prima,</p><p>você poderá reuni-la em um conjunto de declarações. Vamos dar uma olhada em cada</p><p>um desses elementos.</p><p>resultados</p><p>Ao criar hipóteses para testar, você deve tentar ser muito específico em relação aos</p><p>resultados que está tentando alcançar. Discuti anteriormente como as equipes Lean</p><p>UX se concentram menos nos resultados (os documentos, os desenhos, até mesmo os</p><p>produtos e recursos que criamos) e mais nos resultados que esses resultados criam:</p><p>podemos facilitar o login das pessoas em nosso site? Podemos encorajar mais pessoas</p><p>a se inscreverem? Podemos encorajar uma maior colaboração entre os usuários do</p><p>sistema?</p><p>Junto com sua equipe, analise o problema que você está tentando resolver. Você</p><p>provavelmente tem alguns resultados de alto nível que espera alcançar (por exemplo,</p><p>aumentar as inscrições, aumentar o uso, etc.). Considere como você pode dividir esses</p><p>resultados de alto nível em partes menores. Que comportamentos irão prever uma</p><p>maior utilização: mais visitantes ao site? Maior click-through em email marketing?</p><p>Aumentando o número de itens no carrinho de compras? Às vezes é útil realizar um</p><p>brainstorming em equipe para criar uma lista de resultados individuais que, em</p><p>conjunto, você acredita que irão prever o resultado maior que você busca.</p><p>A Figura 3-3 mostra um exemplo de Giff Constable, no qual uma equipe de</p><p>liderança executiva fez um brainstorming e depois votou sobre quais</p><p>indicadores-chave de desempenho (KPIs) a empresa deveria buscar em seguida.</p><p>Após consolidar na lista mostrada na foto, cada executivo recebeu quatro M&Ms.</p><p>Desde que conseguissem não comer os seus votos, estes executivos podiam</p><p>votar (com doces) em cada métrica que considerassem mais importante. Os laços</p><p>foram rompidos pelo CEO.</p><p>VISÃO, ENQUADRAMENTO E RESULTADOS 25</p><p>www.it-ebooks.info</p><p>Figura 3-3.Priorização de KPI com doces</p><p>Personagens</p><p>Os designers costumam criar modelos chamados personas para representar os</p><p>usuários de seus sistemas. Se sua equipe já possui um conjunto bem definido de</p><p>personas, a única coisa que você precisa considerar neste momento é quais você</p><p>usará em suas declarações de hipóteses. Se você ainda não possui personas, esta</p><p>seção explica como criar personas para o processo Lean UX.</p><p>Proto-personas</p><p>Os designers há muito defendem o usuário final. Lean UX não é diferente. À medida</p><p>que fazemos suposições sobre nosso negócio e os resultados que gostaríamos de</p><p>alcançar, ainda precisamos manter o usuário no centro de nosso pensamento.</p><p>A maioria de nós aprendeu a pensar nas personas como uma ferramenta para</p><p>representar o que aprendemos em nossa pesquisa. Muitas vezes criamos</p><p>personas como resultado de estudos de pesquisa longos e caros. O problema</p><p>com personas criadas desta forma é a suposição de que esta é a única maneira</p><p>de criar personas, bem como a tendência de considerar as personas criadas</p><p>através deste processo como intocáveis devido a todo o trabalho necessário</p><p>para criá-las.</p><p>No Lean UX, alteramos a ordem das operações no processo persona. Ao criar</p><p>personas nesta abordagem, começamos com suposições e depois fazemos</p><p>pesquisas para validar nossas suposições. Em vez de passar meses em</p><p>campo entrevistando pessoas, passamos algumas horas criando</p><p>26 Capítulo 3</p><p>www.it-ebooks.info</p><p>protopersonas. Protopersonas são nosso melhor palpite sobre quem está usando (ou</p><p>usará) nosso produto e por quê. Nós os esboçamos no papel com a contribuição de</p><p>toda a equipe – queremos capturar as suposições de todos. Então, à medida que</p><p>aprendemos com nossa pesquisa contínua, descobrimos rapidamente quão precisas</p><p>são nossas suposições iniciais e como precisaremos ajustar nosso público-alvo (e</p><p>persona) – e, portanto, nosso design.</p><p>Usando protopersonas</p><p>Uma equipe com a qual trabalhávamos em Nova York estava criando um aplicativo que melhorava</p><p>a experiência da Agricultura Apoiada pela Comunidade (CSA) para os residentes da cidade de</p><p>Nova York. O CSA é um programa que permite que os moradores da cidade juntem seu dinheiro e</p><p>comprem produtos de uma temporada inteira de um fazendeiro local. O agricultor entrega então</p><p>a sua colheita, semanalmente, aos membros do CSA. Muitos assinantes do CSA são homens e</p><p>mulheres na faixa dos vinte e trinta e poucos anos que precisam conciliar uma vida profissional</p><p>ocupada, uma vida social ativa e o desejo de participar do CSA.</p><p>A equipe presumiu que a maioria dos consumidores do CSA eram mulheres que gostavam de</p><p>cozinhar. Eles passaram cerca de uma hora criando uma persona chamada Susan. Mas quando</p><p>saíram a campo para fazer pesquisas, rapidamente aprenderam que a esmagadora maioria dos</p><p>cozinheiros e, portanto, os potenciais usuários de seu aplicativo, eram homens jovens. Eles</p><p>retornaram ao escritório e revisaram sua persona para criar Timothy (Figura 3-4).</p><p>Figura 3-4.Exemplo de protopersona</p><p>Timothy provou ser um usuário-alvo muito mais preciso. A equipe não perdeu mais tempo</p><p>refinando ideias para o público errado. Eles agora estavam focados em um público que,</p><p>embora ainda não fosse perfeito, era muito mais correto do que suas suposições iniciais.</p><p>VISÃO, ENQUADRAMENTO E RESULTADOS 27</p><p>www.it-ebooks.info</p><p>Formato de Personagem</p><p>Gostamos de esboçar protopersonas no papel usando um quadrante desenhado à</p><p>mão, como nas Figuras 3-5 e 3-6 (comece dobrando uma folha de papel em quatro</p><p>caixas). O quadrante superior esquerdo contém um esboço da persona, seu nome e</p><p>função. A caixa superior direita contém informações demográficas básicas. Tente se</p><p>concentrar nas informações demográficas que preveem um tipo específico de</p><p>comportamento. Por exemplo, pode haver casos em que a idade da persona é</p><p>totalmente irrelevante, mas o acesso a um dispositivo específico, como um iPhone,</p><p>mudará completamente a forma como ela interage com o seu produto.</p><p>Figura 3-5.Modelo de persona em branco</p><p>A metade inferior da protopersona é onde colocamos a essência da informação. O</p><p>quadrante inferior esquerdo contém as necessidades e a frustração do usuário com o</p><p>produto ou situação atual, os pontos problemáticos específicos que seu produto está</p><p>tentando resolver e/ou a oportunidade que você está tentando abordar. O quadrante</p><p>inferior direito contém soluções potenciais para essas necessidades. Você usará o</p><p>quadrante inferior direito para capturar ideias de recursos e soluções.</p><p>28 Capítulo 3</p><p>www.it-ebooks.info</p><p>Figura 3-6.Modelo de persona preenchido</p><p>Processo de Criação de Personagem</p><p>Tal como acontece com os outros elementos da declaração de hipótese, gostamos de</p><p>iniciar o processo de criação da persona com um brainstorming. Os membros da</p><p>equipe oferecem suas opiniões sobre quem o projeto deve ter como alvo e como isso</p><p>afetaria o uso do produto por cada usuário potencial. Assim que o brainstorming for</p><p>concluído, a equipe deve restringir</p><p>as ideias a um conjunto inicial de três ou quatro</p><p>personas que eles acreditam serem mais prováveis de serem o público-alvo. Tente</p><p>diferenciar as personas em torno de necessidades e funções, e não por dados</p><p>demográficos.</p><p>VISÃO, ENQUADRAMENTO E RESULTADOS 29</p><p>www.it-ebooks.info</p><p>Características</p><p>Depois de ter uma lista de resultados em mente e focar em um grupo de usuários, é</p><p>hora de começar a pensar sobre quais táticas, recursos, produtos e serviços você pode</p><p>implementar para alcançar os resultados desejados. Normalmente, todos na equipe</p><p>têm uma opinião forte nesse estágio – afinal, os recursos são as coisas mais concretas</p><p>com as quais trabalhamos, por isso geralmente é mais fácil expressarmos nossas</p><p>ideias em termos de recursos. Muitas vezes, porém, nosso processo de design começa</p><p>quando alguém tem uma ideia de recurso e acabamos trabalhando de trás para frente</p><p>para tentar justificar o recurso. No Lean UX, existem recursos para atender às</p><p>necessidades do negócio, do cliente e do usuário.</p><p>Processo de brainstorming de recursos</p><p>Empregando as mesmas técnicas descritas anteriormente, gostamos de criar listas de</p><p>recursos fazendo brainstorming sobre eles em equipe. Procuramos recursos que</p><p>acreditamos que irão direcionar o comportamento do cliente na direção desejada. Peça a</p><p>cada membro da equipe que escreva cada ideia, usando um marcador grosso, em um post-</p><p>it. Quando o tempo acabar, peça a todos que postem suas anotações na parede e peça ao</p><p>grupo que as organize em temas.</p><p>Montando suas subhipóteses</p><p>Com toda a sua matéria-prima criada, você está pronto para organizar esse material em um</p><p>conjunto de hipóteses testáveis. Gostamos de criar uma tabela como a que está em</p><p>Figura 3-7 e complete-a usando o material que discutimos.</p><p>Ao escrever suas hipóteses, considere quais pessoas você está servindo com as</p><p>soluções propostas. Não é incomum encontrar soluções que atendam mais de uma</p><p>pessoa ao mesmo tempo. Também não é incomum criar uma hipótese em que um</p><p>recurso conduz a mais de um resultado. Quando você perceber isso acontecendo,</p><p>divida a hipótese em duas partes – você deseja que cada afirmação se refira a apenas</p><p>um resultado. O importante a lembrar em todo esse processo é manter suas ideias</p><p>específicas o suficiente para que você possa criar testes significativos para ver se cada</p><p>uma de suas ideias é válida.</p><p>Figura 3-7.Tabela de criação de hipóteses</p><p>30 Capítulo 3</p><p>www.it-ebooks.info</p><p>Quando sua lista de hipóteses estiver completa, você estará pronto (finalmente!) para</p><p>passar para a próxima etapa: projetar. Se você fez o processo até agora com toda a</p><p>sua equipe (e eu recomendo fortemente que o faça), você estará em uma ótima</p><p>posição para avançarmos juntos. Este processo é uma forma muito eficaz de criar um</p><p>entendimento e uma missão compartilhados por toda a equipe.</p><p>Conclusão</p><p>Neste capítulo, discutimos como podemos reformular nosso trabalho em termos de</p><p>resultados, o que é uma técnica Lean UX de vital importância: enquadrar nosso trabalho</p><p>com resultados nos liberta (e às nossas equipes) para buscar as melhores soluções para o</p><p>problema em questão. . Também analisamos o processo de declaração de resultados. Para</p><p>alcançar estes objectivos, começamos com as declarações do problema do projecto e depois</p><p>reconhecemos os nossos pressupostos e depois transformamos estes pressupostos em</p><p>hipóteses. Também mostramos como escrever declarações de hipóteses que capturem os</p><p>recursos, o público e os objetivos pretendidos e que sejam específicas o suficiente para</p><p>serem testadas. Você terminará com declarações que servirão como roteiro para a próxima</p><p>etapa do processo Lean UX: design colaborativo.</p><p>No próximo capítulo, definimos o design colaborativo e como ele difere do</p><p>design de produto tradicional. Discutiremos ferramentas e técnicas específicas</p><p>que capacitam as equipes a projetar juntas e demonstraremos como projetar</p><p>juntas é o início do processo de validação de hipóteses.</p><p>VISÃO, ENQUADRAMENTO E RESULTADOS 31</p><p>www.it-ebooks.info</p><p>Traduzido do Inglês para o Português - www.onlinedoctranslator.com</p><p>https://www.onlinedoctranslator.com/pt/?utm_source=onlinedoctranslator&utm_medium=pdf&utm_campaign=attribution</p><p>www.it-ebooks.info</p><p>Capítulo 4</p><p>Design Colaborativo</p><p>Ao navegar pelo resto da sua vida, esteja aberto à colaboração</p><p>ção. As ideias de outras pessoas e de outras pessoas costumam ser melhores que</p><p>as suas. Encontre um grupo de pessoas que desafie e inspire você,</p><p>passe muito tempo com eles e isso mudará sua vida.</p><p>Amy Poehler</p><p>Lean UX é um processo colaborativo. Reúne designers e não designers em</p><p>cocriação. Produz ideias maiores e melhores do que as dos contribuidores</p><p>individuais. Mas não é projeto por comitê. Em vez disso, o Lean UX aumenta o</p><p>controle da equipe sobre o trabalho, proporcionando uma oportunidade para</p><p>que todas as opiniões sejam ouvidas muito mais cedo no processo. Neste</p><p>capítulo, exploramos os muitos benefícios decorrentes dessa colaboração</p><p>estreita e multifuncional. Especificamente, analisamos:</p><p>• Por que todo mundo pode projetar</p><p>• Como os artefatos de baixa fidelidade aumentam a colaboração</p><p>• Construindo um entendimento compartilhado por toda a sua equipe</p><p>Também nos aprofundaremos em uma série de técnicas que permitem essa forma mais</p><p>produtiva de trabalhar, incluindo:</p><p>33</p><p>www.it-ebooks.info</p><p>• Estúdio de design — um exercício de esboço colaborativo para toda a equipe</p><p>• Guias de estilo e bibliotecas de padrões – repositórios vivos de todos os elementos do</p><p>seu produto voltados para o cliente</p><p>• Técnicas de colaboração para equipes distribuídas geograficamente</p><p>No capítulo anterior, discutimos hipóteses de características do produto. A primeira parte</p><p>de uma declaração de hipótese de característica do produto descreveo queconstruiremos</p><p>para resolver os problemas de nossos clientes. Esses recursos podem ser projetados de</p><p>várias maneiras. Navegar por essas opções pode ser difícil para as equipes. Com que</p><p>frequência você enfrentou conflitos de equipe por causa de escolhas de design?</p><p>Figura 4-1.Você escreveu a hipótese. Agora é hora de determinar o que você precisa para testar</p><p>suas suposições.</p><p>A maneira mais eficaz que encontrei de reunir uma equipe em torno de uma direção</p><p>de design é por meio da colaboração. No longo prazo, a colaboração produz melhores</p><p>resultados do que o design baseado em heróis (a prática de chamar um designer ou</p><p>equipe de design para aparecer, criar algo bonito e partir para resgatar o próximo</p><p>projeto). As equipes raramente aprendem ou melhoram trabalhando com heróis. Em</p><p>vez disso, projetar em conjunto aumenta o QI de design de toda a equipe. Permite que</p><p>cada membro da equipe articule suas ideias. Ele oferece aos designers um conjunto</p><p>muito mais amplo de ideias para aproveitar à medida que refinam a experiência do</p><p>usuário. Essa colaboração, por sua vez, gera maiores sentimentos de propriedade</p><p>sobre o trabalho realizado por toda a equipe. Finalmente, o design colaborativo</p><p>constrói um entendimento compartilhado por toda a equipe. É esse entendimento</p><p>compartilhado que é a moeda do Lean UX. Quanto mais a equipe entende</p><p>coletivamente, menos precisa documentar para seguir em frente.</p><p>O design colaborativo é uma abordagem que permite que uma equipe crie conceitos de</p><p>produtos em conjunto. Ajuda as equipes a construir uma compreensão compartilhada do</p><p>problema e da solução de design. Isso permite que eles trabalhem juntos para decidir quais</p><p>funcionalidades e elementos de interface melhor implementam o recurso em suas</p><p>hipóteses.</p><p>34 Capítulo 4</p><p>www.it-ebooks.info</p><p>O design colaborativo ainda é uma atividade liderada pelo designer. É</p><p>responsabilidade do designer não apenas convocar essas reuniões, mas também</p><p>facilitá-las. Às vezes, você terá sessões individuais com um desenvolvedor em um</p><p>quadro branco. Outras vezes, você reunirá toda a equipe para um exercício de Design</p><p>Studio. A chave é colaborar com um grupo diversificado de membros da equipe.</p><p>Em uma típica sessão de design colaborativo, as equipes esboçam</p><p>juntas, criticam o</p><p>trabalho à medida que ele surge e, por fim, convergem para uma solução que consideram</p><p>ter maior chance de sucesso. O designer, ao mesmo tempo que produz projetos, assume o</p><p>papel adicional de facilitador para liderar a equipe através de uma série de exercícios.</p><p>O resultado dessas sessões normalmente consiste em esboços e wireframes de baixa</p><p>fidelidade. Esse nível de fidelidade é fundamental para manter a maleabilidade do trabalho,</p><p>o que permite que a equipe mude rapidamente se os testes revelarem que a abordagem</p><p>não está funcionando. É muito mais fácil sair de uma abordagem fracassada se você não</p><p>gastou muito tempo documentando e detalhando laboriosamente essa abordagem.</p><p>Conversa: sua ferramenta mais poderosa</p><p>Lean UX promove a conversa como principal meio de comunicação entre os membros da equipe.</p><p>Desta forma, está muito alinhado com o Manifesto Ágil, que promove “indivíduos e interações em</p><p>vez de processos e ferramentas”. A conversa une uma equipe em torno de uma visão</p><p>compartilhada. Também traz insights de diferentes disciplinas para o projeto muito antes do que</p><p>um ciclo de design tradicional permitiria. À medida que novas ideias são formadas ou mudanças</p><p>são feitas no design, o insight de um membro da equipe pode rapidamente desafiar essas ideias</p><p>de uma forma que o designer sozinho talvez não tenha reconhecido.</p><p>Ao ter essas conversas desde o início e com frequência, a equipe fica ciente das ideias de todos e</p><p>pode começar seu próprio trabalho mais cedo. Se souberem que a solução proposta requer uma</p><p>determinada infraestrutura de back-end, por exemplo, os engenheiros da equipe podem iniciar</p><p>esse trabalho enquanto o design é refinado e finalizado. Caminhos paralelos para</p><p>desenvolvimento e design de software são o caminho mais rápido para uma experiência real.</p><p>Estas conversas podem parecer estranhas no início; afinal, você está derrubando barreiras</p><p>testadas pelo tempo entre as disciplinas. À medida que a conversa evolui, no entanto, os</p><p>designers fornecem aos desenvolvedores informações sobre a implementação de determinados</p><p>recursos, garantindo a evolução adequada de sua visão. Essas conversas promovem a</p><p>transparência do processo e do progresso. Essa transparência cria laços entre os membros da</p><p>equipe. Colegas de equipe que confiam uns nos outros ficam mais motivados a trabalhar juntos</p><p>para produzir um trabalho de maior qualidade.</p><p>DESIGN COLABORATIVO 35</p><p>www.it-ebooks.info</p><p>Design Colaborativo na Prática</p><p>Em 2010, eu estava projetando um painel para um aplicativo da web direcionado ao</p><p>público recrutador e empregador do TheLadders. Havia muitas informações para</p><p>caber em uma tela e eu estava lutando para fazer tudo funcionar. Em vez de gastar</p><p>muito tempo na minha mesa empurrando pixels, peguei um quadro branco e chamei</p><p>o desenvolvedor líder. Esbocei minha ideia original sobre como organizar todo o</p><p>conteúdo e funcionalidades deste painel. Discutimos o assunto e então entreguei-lhe</p><p>o marcador. Ele esboçou suas ideias no mesmo quadro branco. Fomos para frente e</p><p>para trás, convergindo finalmente para um esquema de layout e interação que não</p><p>era apenas utilizável, mas viável, dados os prazos de sprint de duas semanas (veja a</p><p>Figura 4-2). Ao final daquela sessão de duas horas, voltamos às nossas mesas e</p><p>começamos a trabalhar. Refinei nosso esboço em um wireframe e fluxo de trabalho</p><p>mais formais e ele começou a escrever o código de infraestrutura necessário para</p><p>levar os dados de que precisávamos para a camada de apresentação.</p><p>Construímos um entendimento compartilhado por meio de nossa sessão de design</p><p>colaborativo. Ambos sabíamos o que iríamos construir e o que precisava ser feito. Não</p><p>precisamos esperar para documentar isso. Essa abordagem nos permitiu construir a</p><p>primeira versão dessa ideia dentro do nosso prazo de duas semanas.</p><p>Figura 4-2.Esboço no quadro branco que chegamos juntos.</p><p>36 Capítulo 4</p><p>www.it-ebooks.info</p><p>Estúdio de design</p><p>Quando sua equipe se sente confortável em colaborar, sessões informais como a</p><p>que acabei de descrever acontecem o tempo todo. Mas às vezes você precisará</p><p>reunir todos para uma sessão formal de trabalho. Design Studio é uma forma</p><p>popular de fazer isso. Design Studio (às vezes chamado de Design Charrette) é</p><p>uma forma de reunir uma equipe multifuncional para visualizar soluções</p><p>potenciais para um problema de design. Ele quebra silos organizacionais e cria</p><p>um fórum para os pontos de vista de seus colegas de equipe. Ao reunir</p><p>designers, desenvolvedores, especialistas no assunto, gerentes de produto,</p><p>analistas de negócios e outras competências no mesmo espaço e focar todos no</p><p>mesmo desafio, você cria um resultado muito maior do que o trabalho em silos</p><p>permite. Um Design Studio tem outro benefício: ele começa a construir a</p><p>confiança que sua equipe precisará para passar dessas sessões formais para</p><p>colaborações mais frequentes e informais.</p><p>Administrando um estúdio de design</p><p>Embora a técnica descrita abaixo seja muito específica, você deve se sentir confortável para</p><p>administrar Estúdios de Design menos ou mais formais, conforme sua situação e momento</p><p>o justifiquem. As especificidades do ritual não são o objetivo final: em vez disso, você deve</p><p>ter como objetivo resolver problemas com seus colegas e clientes.</p><p>Processo</p><p>O Design Studio segue este caminho:</p><p>1. Definição do problema e restrições</p><p>2. Geração de ideias individuais (divergência)</p><p>3. Apresentação e crítica</p><p>4. Iterar e refinar (emergir)</p><p>5. Geração de ideias em equipe (convergência)</p><p>Suprimentos</p><p>Aqui está o que você precisa:</p><p>• Lápis</p><p>• Canetas</p><p>• Marcadores permanentes (várias cores/espessuras)</p><p>• Marcadores (várias cores)</p><p>DESIGN COLABORATIVO 37</p><p>www.it-ebooks.info</p><p>• Modelos de esboço (você pode usar modelos pré-impressos de 1 e 6 páginas ou</p><p>pode usar folhas em branco de papel de 11"×17" divididas em seis caixas)</p><p>• Almofadas de cavalete autoadesivas de 25"×30,5"</p><p>• Pontos de desenho (ou qualquer tipo de adesivo pequeno)</p><p>O processo funciona melhor para uma equipe de cinco a oito pessoas. Se você tiver</p><p>mais pessoas, crie mais equipes e faça com que elas comparem os resultados no final</p><p>do processo.</p><p>Definição do problema e restrições (15–45 minutos)</p><p>O primeiro passo no Design Studio é garantir que todos estejam cientes do problema</p><p>que você está tentando resolver, das suposições que você declarou (incluindo</p><p>personas, conforme explicado em outra parte deste capítulo), das hipóteses que você</p><p>gerou e das restrições. dentro do qual você está trabalhando. Esta etapa pode ser</p><p>qualquer coisa, desde uma apresentação formal com slides até uma discussão em</p><p>grupo, com base no nível de conforto da equipe.</p><p>Geração de ideias individuais (10 minutos)</p><p>Você trabalhará individualmente nesta etapa. Dê a cada membro da equipe um</p><p>modelo de 6 páginas – uma folha de papel com seis caixas vazias (Figura 4-3). Você</p><p>pode fazer um dobrando uma folha em branco de papel de 11"×17" (ou pode usar um</p><p>modelo pré-impresso).</p><p>Figura 4-3.Um modelo de 6 páginas.</p><p>38 Capítulo 4</p><p>www.it-ebooks.info</p><p>Opcional: às vezes, as pessoas acham difícil encarar uma página em branco. Se for esse o</p><p>caso, tente o seguinte passo (5 minutos): peça a cada pessoa para rotular cada caixa de sua</p><p>planilha com uma de suas personas e o ponto problemático ou problema específico que ela</p><p>abordará para essa persona. Escreva o nome da persona e o ponto problemático no topo de</p><p>cada uma das seis caixas. Os membros da equipe podem escrever o mesmo par persona/</p><p>ponto problemático quantas vezes tiverem soluções para esse problema, ou podem</p><p>escrever uma combinação diferente de persona/ponto problemático para cada caixa.</p><p>Qualquer combinação funciona.</p><p>Em seguida, com suas folhas de 6 páginas em branco (ou opcionalmente etiquetadas) à sua</p><p>frente, dê a todos cinco minutos para gerar seis esboços de soluções de baixa fidelidade</p><p>para cada par de persona/ponto problemático em suas 6 páginas. Devem ser articulações</p><p>visuais (esboços de UI, fluxos de trabalho, diagramas, etc.), não palavras</p><p>escritas. Incentive</p><p>sua equipe revelando o segredo sujo do design de interação para nivelar o campo de jogo:</p><p>se você consegue desenhar um círculo, um quadrado e um triângulo, você pode desenhar</p><p>todas as interfaces. Tenho certeza de que todos em sua equipe conseguem desenhar essas</p><p>formas.</p><p>Apresentação e crítica (3 minutos por pessoa)</p><p>Quando o tempo acabar, compartilhe e critique o que você fez até agora (veja a Figura</p><p>4-4). Contornando a mesa, dê a cada participante três minutos para segurar seus</p><p>esboços e apresentá-los à equipe. Os apresentadores devem declarar explicitamente</p><p>para quem estavam resolvendo um problema (persona), qual ponto problemático</p><p>estavam abordando (hipótese) e, em seguida, explicar o esboço. Cada membro da</p><p>equipe deve fornecer críticas e feedback ao apresentador. A crítica deve se concentrar</p><p>em esclarecer as intenções do apresentador. Perguntas como “Como esse recurso</p><p>aborda o problema específico da persona?” são muito úteis. Comentários como “Não</p><p>gosto dessa ideia” fornecem pouco valor e não dão ao apresentador ideias concretas</p><p>para iteração.</p><p>Certifique-se de que cada membro da equipe apresente e receba críticas.</p><p>DESIGN COLABORATIVO 39</p><p>www.it-ebooks.info</p><p>Figura 4-4.Exemplo de saída típica do Design Studio.</p><p>Iterar e refinar (5–10 minutos)</p><p>Agora peça a todos que trabalhem individualmente mais uma vez. Peça a cada</p><p>participante que pegue nas suas seis ideias originais e, usando a crítica que acabou de</p><p>receber, refine o seu pensamento numa grande ideia numa única folha de papel de</p><p>11"×17". O objetivo aqui é escolher a ideia que tenha mais mérito e desenvolver uma</p><p>versão mais evoluída dessa ideia.</p><p>Quando o tempo acabar, peça à equipe que repita o processo de apresentação e</p><p>crítica.</p><p>40 Capítulo 4</p><p>www.it-ebooks.info</p><p>geração de ideias em equipe (45 minutos)</p><p>Agora que todos na equipe têm feedback sobre suas ideias individuais, a</p><p>equipe deve convergir para uma ideia. Nesta etapa, a equipe tenta convergir</p><p>para a ideia que considera ter maior chance de sucesso. Essa ideia servirá de</p><p>base para a próxima etapa do processo Lean UX: criar um MVP e executar</p><p>experimentos (ambos abordados no próximo capítulo).</p><p>Peça à equipe para usar um cavalete grande autoadesivo de 2' × 3' ou um quadro</p><p>branco para esboçar os componentes e o fluxo de trabalho de sua ideia. Haverá</p><p>muitos compromissos e disputas nesta fase; para chegar a um consenso, a equipe</p><p>precisará priorizar e reduzir os recursos. Incentive a equipe a criar um</p><p>“estacionamento” para boas ideias que não sejam aprovadas, o que tornará mais fácil</p><p>abandonar as ideias.</p><p>Se você tiver várias equipes no estúdio de design, peça a cada equipe que</p><p>apresente sua ideia final à sala quando terminar, para uma rodada final de</p><p>críticas e feedback.</p><p>Os artefatos criados no estúdio de design agora são usados para criar</p><p>wireframes refinados, protótipos e códigos iniciais que impulsionarão a equipe</p><p>na prova de suas hipóteses.</p><p>Guias de estilo</p><p>Uma ferramenta que facilita o design colaborativo é o guia de estilo. Um guia de estilo é</p><p>uma biblioteca de padrões amplamente aceita que codifica os elementos interativos, visuais</p><p>e de cópia de uma interface de usuário e sistema. Os guias de estilo (também conhecidos</p><p>como bibliotecas de padrões) são uma coleção viva de todos os componentes do seu</p><p>produto voltados para o cliente. Se for feito de pixels, vai para o guia de estilo. Cabeçalhos,</p><p>rodapés, grades, formulários, rótulos, lógica de botões e tudo o mais que envolve a</p><p>experiência do usuário do seu produto estão no guia de estilo.</p><p>Algumas empresas usam wikis para seus guias de estilo, o que permite que a coleção</p><p>permaneça atualizada e acessível a todos da equipe. Outras equipes optam por criar</p><p>guias de estilo “ao vivo”. Esses são repositórios de código e design de front-end que</p><p>não apenas definem a aparência e o comportamento do produto, mas também</p><p>funcionam como marcação e folhas de estilo subjacentes para essa experiência. Se</p><p>você alterar o guia de estilo, você altera o produto.</p><p>Guias de estilo criam eficiência. Eles fornecem um repositório de componentes de interface</p><p>aprovados e prontos para uso que podem ser montados e alinhados para formar um fluxo</p><p>de trabalho. Ao minimizar o debate sobre elementos mundanos, como a colocação de</p><p>rótulos em formulários ou o debate interminável sobre a colocação esquerda/direita</p><p>DESIGN COLABORATIVO 41</p><p>www.it-ebooks.info</p><p>do botão de ação “positiva”, os desenvolvedores podem começar a criar componentes</p><p>principais da UI sem esperar que um designer defina e especifique esses ativos. Os</p><p>ativos já estão desenhados, definidos e coletados em um só lugar.</p><p>Os designers visuais e de interação também se beneficiam. Eles não precisam mais</p><p>recriar representações de experiências que já existem. Eles ficam livres para se</p><p>concentrar em novos desafios de design – novos problemas de interação ou extensão</p><p>do sistema visual para novos elementos. Os ciclos de aprovação são simplificados</p><p>porque os elementos repetitivos (por exemplo, o tratamento da navegação global)</p><p>não estão mais em debate. As análises tornam-se mais focadas no desafio principal do</p><p>produto e em visões mais amplas da solução proposta.</p><p>Criando um guia de estilo</p><p>Existem duas abordagens básicas para criar um guia de estilo:</p><p>Big Bang</p><p>Nessa abordagem, sua equipe dedica um tempo limitado (por exemplo, uma a</p><p>duas semanas ou, às vezes, meses) de seus esforços atuais para documentar</p><p>todos os elementos de UI do seu produto em um guia de estilo. A vantagem aqui</p><p>é que o guia de estilo é criado em um período de tempo relativamente curto. O</p><p>negativo é que sua equipe não está aprendendo nada de novo sobre seu produto</p><p>durante esse período.</p><p>Gotejamento lento</p><p>Nessa abordagem, sua equipe adiciona um elemento ao guia de estilo cada</p><p>vez que cria ou altera um para o projeto. O maior benefício aqui é que a</p><p>equipe continua trabalhando no projeto. No entanto, a desvantagem é que</p><p>o guia de estilo raramente é concluído e, portanto, não fornece algumas das</p><p>eficiências que um guia completo oferece.</p><p>Manter um guia de estilo</p><p>Ao planejar seu guia de estilo, é importante planejar a manutenção. Você</p><p>precisará criar um processo e dedicar pessoas para manter seu guia de estilo</p><p>atualizado. Pense em um guia de estilo como um processo vivo que você</p><p>inicia e mantém, em vez de algo estático que você cria. Quando você tem um</p><p>guia de estilo atualizado e fácil de usar, você torna mais fácil para a equipe</p><p>realmente usar o guia de estilo – e seu objetivo deve ser facilitar o uso do</p><p>guia de estilo do que evitá-lo . Você quer facilitar a conformidade! Portanto,</p><p>planeje dedicar tempo e pessoas para manter seu guia de estilo atualizado.</p><p>42 Capítulo 4</p><p>www.it-ebooks.info</p><p>Estudo de caso</p><p>Neste estudo de caso, veremos como a equipe de UX da General Electric (GE) criou um</p><p>guia de estilo de nível empresarial.</p><p>Quando Greg Petroff assumiu o comando da prática global de UX da GE no final de</p><p>2011, ele herdou uma equipe distribuída globalmente que lutava para trazer</p><p>excelentes experiências de produtos para uma das maiores organizações do mundo.</p><p>Acontece que a GE é o décimo quarto maior produtor de software do mundo, criando</p><p>sistemas para monitorar, gerenciar e compreender os equipamentos industriais que</p><p>constrói. Com 500 desenvolvedores para cada designer, a equipe achou um desafio</p><p>alcançar os resultados de design desejados para satisfazer as enormes demandas da</p><p>organização. Contratar mais designers não era uma opção, e a ampla defesa</p><p>corporativa para uma maior consideração dos métodos de design UX mudaria as</p><p>bases culturais – incluindo processos, valores, práticas de comunicação, atitudes e</p><p>suposições – muito lentamente. Além disso, o recém-criado Centro de Excelência UX</p><p>rapidamente se viu sobrecarregado com solicitações de trabalho. A revisão de cada</p><p>projeto de UX que passou pela empresa os transformou no gargalo que eles tentavam</p><p>remover.</p><p>Tinha que haver uma maneira melhor. A equipe inicialmente tentou construir uma comunidade</p><p>UX</p><p>em toda a empresa por meio de uma plataforma de rede social centralizada. Embora essa</p><p>abordagem tenha começado a criar camaradagem, ela não foi suficiente para socializar uma</p><p>estética de design consistente ou permitir que equipes de desenvolvimento sem capacidade de UX</p><p>fizessem um bom trabalho.</p><p>Depois de executar alguns projetos piloto em diversas linhas de negócios, a equipe de</p><p>Petroff rapidamente percebeu casos de uso, personas e padrões de design recorrentes.</p><p>Com linhas de negócios individuais focadas em suas necessidades de negócios e não no</p><p>todo, havia naturalmente uma enorme quantidade de trabalho duplicado sendo feito na GE,</p><p>à medida que cada organização separada recriava elementos semelhantes repetidas vezes.</p><p>Pior ainda, a qualidade desse trabalho não progrediu de acordo com o que os clientes de</p><p>smartphones estavam começando a exigir. O método da GE não era apenas ineficiente, mas</p><p>também aumentava o tempo que cada projeto levava para chegar ao mercado. E quando os</p><p>projetos chegaram ao mercado, as experiências nas linhas de negócios da GE eram díspares</p><p>e inconsistentes.</p><p>A equipe fez um brainstorming ao longo de uma semana e descobriu como seria</p><p>um ambiente social para diretrizes de UX consistentes. Seu público-alvo eram os</p><p>8.000 engenheiros de software da GE em todo o mundo. A equipe percebeu que,</p><p>ao capacitar os desenvolvedores com modelos, diretrizes, ativos e trechos de</p><p>código, eles poderiam ter uma ótima experiência do usuário em suas próprias</p><p>mãos, sem esperar pela assistência ou aprovação do design.</p><p>DESIGN COLABORATIVO 43</p><p>www.it-ebooks.info</p><p>Com essa iniciativa nasceu o Industrial Internet Design System (IIDS). O</p><p>espantalho recebeu luz verde da administração e foi implementado</p><p>durante o verão de 2012.</p><p>O IIDS é baseado em estruturas HTML5 modernas, como Bootstrap, jQuery e outras,</p><p>mas não se parece em nada com elas (veja as Figuras 4-5 e 4-6). É uma biblioteca de</p><p>padrões de design de UI funcional e de marca. Ele fornece ativos gráficos, trechos de</p><p>código e regras de uso para cada uma das experiências de produto modeladas da GE.</p><p>A equipe também construiu aplicativos de exemplo para auxiliar outras equipes na</p><p>composição de aplicativos. O IIDS também inclui personas típicas de clientes para que</p><p>as equipes de projeto possam ter uma noção clara de seus clientes-alvo e como o</p><p>cliente pretendido afeta as escolhas de padrões de design que fazem.</p><p>A equipe de Petroff identificou dois públicos distintos para o IIDS. O primeiro foram os</p><p>desenvolvedores da GE que precisam de recursos para construir sites e produtos. O</p><p>segundo foi formado pelos gestores e proprietários do programa que precisam</p><p>decidir que tipo de aplicativo criar. O IIDS atende bem a ambas as comunidades, com</p><p>feedback positivo chegando regularmente, estatísticas de uso disparando e métricas</p><p>de sucesso de projetos subindo e indo para a direita.</p><p>O IIDS está capacitando equipes que buscam se tornar mais ágeis e mergulhar no</p><p>Lean Startup. Ele permite que as equipes de projeto construam protótipos de</p><p>experiências com muito mais rapidez do que nunca. Esses protótipos chegam aos</p><p>estágios de validação meses antes dos projetos anteriores, permitindo que as equipes</p><p>provem seu valor bem antes da integração pesada de back-end. Os ciclos de vida</p><p>médios dos projetos foram reduzidos em até seis meses, com economias estimadas</p><p>no uso de recursos na casa dos milhões por ano.</p><p>Mais importante ainda, todas as equipes da GE agora têm a capacidade de obter uma</p><p>versão clicável de sua experiência em dias, em vez de meses. Eles são capazes de levar</p><p>essas ideias às partes interessadas internas e aos clientes externos muito antes de</p><p>comprometerem mais recursos. Além disso, as equipes estão muito mais bem</p><p>equipadas para avaliar o sucesso do lançamento de um novo produto. O desperdício</p><p>que outrora assolou o ciclo de concepção de produtos na GE está lentamente a ser</p><p>aliviado através dos recursos cada vez melhores disponíveis no IIDS.</p><p>44 Capítulo 4</p><p>www.it-ebooks.info</p><p>Figura 4-5.Um exemplo de página de modelo do IIDS.</p><p>DESIGN COLABORATIVO 45</p><p>www.it-ebooks.info</p><p>Figura 4-6.Um layout de tabela no IIDS.</p><p>O que entra em um guia de estilo?</p><p>Se for feito de pixels, vai para o guia de estilo. Todosdesign de interação os elementos</p><p>devem ser definidos e adicionados ao guia de estilo. Use padrões de design que</p><p>funcionem bem em seu produto existente como base de seu guia de estilo. Campos</p><p>de formulário, rótulos, menus suspensos, posicionamento e comportamento de</p><p>botões de opção, eventos Ajax e jQuery, botões – todos devem ser incluídos no guia</p><p>de estilo.</p><p>46 Capítulo 4</p><p>www.it-ebooks.info</p><p>Figura 4-7.Exemplo de guia de estilo do TheLadders.</p><p>Forneça três pontos de dados para cada elemento de design de interação:</p><p>Qual é a aparência do elemento</p><p>Inclua detalhes sobre os tamanhos mínimo e máximo do elemento,</p><p>restrições verticais e horizontais e quaisquer exigências de estilo do</p><p>elemento.</p><p>Onde geralmente é colocado na tela</p><p>Deixe claro se um elemento deve ser colocado de forma consistente em</p><p>determinadas áreas da tela, bem como quaisquer exceções que possam anular</p><p>esse padrão de design.</p><p>Quando deve ser usado</p><p>É fundamental que sua equipe saiba quando usar um menu suspenso em vez de</p><p>um botão de opção e outros fatores que determinariam a seleção de um</p><p>elemento da UI em detrimento de outro.</p><p>DESIGN COLABORATIVO 47</p><p>www.it-ebooks.info</p><p>Figura 4-8.Outro exemplo de página de guia de estilo do TheLadders.</p><p>A seguir, inclua todosdesign visualelementos. Comece com a paleta geral de cores do seu</p><p>produto. Certifique-se de que cada cor primária esteja disponível com valores hexadecimais,</p><p>bem como opções de cores complementares e secundárias. Se determinados elementos,</p><p>como botões, tiverem cores diferentes com base no estado, certifique-se de que essas</p><p>informações sejam incluídas. Outros elementos a serem incluídos aqui são logotipos,</p><p>cabeçalhos, rodapés, estruturas de grade e opções tipográficas (ou seja, quais fontes usar,</p><p>onde e com que tamanho/peso). Os mesmos atributos de o que, onde e quando fornecidos</p><p>para os elementos de design de interação também devem ser incluídos aqui.</p><p>Por fim, certifique-se de quedireitos autoraisestilos também são codificados.</p><p>Capture o tom da sua marca, palavras específicas que você usará ou não,</p><p>escolhas gramaticais, coloquialismos tolerados (e não tolerados), junto com o</p><p>idioma dos botões (OK? Sim? Ir? etc.) e outro idioma de navegação (anterior/</p><p>próximo , mais/menos, etc.).</p><p>Características de um guia de estilo de sucesso</p><p>Um guia de estilo de sucesso tem três características importantes: éacessível, isso é</p><p>continuamente melhorado(também conhecido como documento vivo), e éacionável.</p><p>Acessível</p><p>Acessibilidade significa que o guia de estilo está disponível para todos na sua</p><p>organização. Os guias de estilo acessíveis são:</p><p>48 Capítulo 4</p><p>www.it-ebooks.info</p><p>Facilmente encontrado</p><p>Use um URL memorável e certifique-se de que todos estejam cientes dele.</p><p>Facilmente distribuído</p><p>Garanta que suas equipes possam acessar os guias de estilo conforme sua</p><p>conveniência (no escritório, fora do escritório, no celular, etc.).</p><p>Fácil de pesquisar</p><p>Um recurso de pesquisa abrangente e preciso no guia de estilo aumenta</p><p>muito seu uso.</p><p>Fácil de usar</p><p>Trate isso como faria com qualquer outro projeto de design. Se não for utilizável, não será</p><p>utilizado muito rapidamente.</p><p>Melhorado continuamente</p><p>O guia de estilo deve ser considerado um documento vivo. Sim, os elementos contidos</p><p>nele garantem uma experiência consistente para seus clientes, mas seu produto (e</p><p>seus clientes) evoluirão. O guia de estilo deve ser maleável o suficiente para adicionar</p><p>essas atualizações facilmente. Além disso, à medida que seus designers criam novos</p><p>elementos, eles exigirão uma maneira fácil de adicioná-los ao guia de estilo.</p><p>Eu recomendo usar um wiki. Aqui está o porquê:</p><p>• Wikis são lugares familiares para desenvolvedores. Isso significa que fazer com que seus</p><p>colegas de engenharia participem</p><p>desta ferramenta não envolverá forçá-los a</p><p>aprender uma nova ferramenta ou uma que foi desenvolvida especificamente para</p><p>designers.</p><p>• Os wikis mantêm históricos de revisões (pelo menos os bons mantêm). Essa prática</p><p>é crucial porque haverá momentos em que você desejará reverter as atualizações</p><p>da IU. Os históricos de revisão evitam que você tenha que recriar estados</p><p>anteriores do guia de estilo.</p><p>• Os wikis monitoram quem mudou o quê e fornecem funcionalidade de</p><p>comentários. Esse recurso é ideal para manter um registro de quais decisões</p><p>foram tomadas, quem as tomou e a justificativa e até mesmo a discussão sobre</p><p>como fazer essa mudança. À medida que você traz novos membros para a</p><p>equipe, esse tipo de captura histórica pode atualizá-los com muito mais rapidez.</p><p>Em outras palavras, os wikis são a sua documentação.</p><p>Acionável</p><p>Seu guia de estilo não é apenas uma biblioteca ou museu para componentes de interação. Deveria</p><p>ser uma “fábrica de widgets” que pudesse produzir qualquer elemento de interface sob demanda.</p><p>À medida que cada novo elemento é adicionado ao guia de estilo, disponibilize-o</p><p>DESIGN COLABORATIVO 49</p><p>www.it-ebooks.info</p><p>para download em qualquer formato que sua equipe precise. Certifique-se de que não</p><p>apenas o código esteja disponível, mas também os recursos gráficos e de wireframe.</p><p>Isso permite que cada designer tenha uma paleta completa de elementos de interface</p><p>para criar protótipos a qualquer momento.</p><p>Como você cria um guia de estilo?</p><p>Existem duas partes na criação de um guia de estilo:</p><p>1. Crie um índice analítico (TOC)—o sumário determina como seu guia de estilo</p><p>será estruturado e fornece grupos nos quais você pode começar a inserir</p><p>elementos de design. Separe seu sumário em design de interação, design</p><p>visual, redação, diretrizes de marca, necessidades de acessibilidade e</p><p>quaisquer outras seções de alto nível que façam sentido para o seu negócio.</p><p>2. Preencha o conteúdo—Conforme mencionado anteriormente, existem duas maneiras</p><p>de fazer isso: a abordagem do big bang e o gotejamento lento.</p><p>OBig Bangabordagem (na qual sua equipe cria todo o guia de estilo antes de</p><p>qualquer projeto) funciona bem se você tiver um produto jovem ou</p><p>relativamente simples.</p><p>Ogotejamento lentoabordagem funciona bem se você tiver um produto legado ou</p><p>complexo.</p><p>Manter um guia de estilo</p><p>Seu guia de estilo deve permanecer atualizado para permanecer relevante e útil. Adicione</p><p>novas experiências à medida que são criadas e remova recursos desatualizados à medida</p><p>que são obsoletos.</p><p>Atribua um proprietário ao guia de estilo. Essa pessoa não precisa ser a única</p><p>responsável pela criação do conteúdo do guia de estilo em si, mas deve ser</p><p>responsável por garantir o estado atual do guia. O curador do seu guia de estilo</p><p>deve entrar em contato com os criadores de conteúdo e garantir que os</p><p>elementos sejam inseridos à medida que são criados. Em essência, essa pessoa</p><p>funciona como editor da biblioteca de padrões. É uma posição nada invejável,</p><p>então considere alternar essa função regularmente a cada três meses.</p><p>não apenas para designers</p><p>Seu guia de estilo não deve conter informações relevantes apenas para designers. Ele</p><p>também deve abrigar trechos de código. Os desenvolvedores têm então um balcão</p><p>único para obter todas as orientações de design, bem como peças básicas de código</p><p>que os levarão a algum tipo de experiência exponencialmente mais rápido do que</p><p>antes.</p><p>50 Capítulo 4</p><p>www.it-ebooks.info</p><p>Uma palavra sobre guias de estilo ao vivo</p><p>As equipes que trabalham na Web começaram recentemente a adotar uma nova</p><p>abordagem aos guias de estilo – o guia de estilo ao vivo. Essencialmente, eles são idênticos</p><p>aos guias de estilo baseados em wiki, com uma diferença fundamental: o código em um</p><p>guia de estilo ativo é o mesmo que o aplicativo usa. As equipes ganham eficiência com essa</p><p>abordagem, mas assumem alguns encargos adicionais de infraestrutura e processos.</p><p>Os guias de estilo ao vivo são basicamente uma parte do seu produto que fica visível</p><p>apenas para a equipe do produto. É uma parte da sua aplicação que gera uma página</p><p>“um de cada” que exibe todos os estilos e widgets que estão sendo usados no site.</p><p>Tem a vantagem de estar muito mais próximo da automanutenção.</p><p>À medida que você faz alterações no HTML e CSS subjacentes do seu site, essas alterações</p><p>são exibidas nas páginas do guia de estilo. Alguém ainda precisa prestar atenção a esta</p><p>página para garantir que ela seja organizada e mantida e que os conflitos sejam resolvidos.</p><p>Mas o movimento em direção a uma aplicação autodocumentada é estimulante e promete</p><p>ser tremendamente promissor.</p><p>Colaborando com equipes distribuídas geograficamente</p><p>A distância física é um dos maiores desafios para uma colaboração forte. Alguns dos</p><p>métodos que discuti neste capítulo — especialmente o Design Studio — tornam-se</p><p>mais difíceis quando a equipe não está toda no mesmo local. Mas você ainda pode</p><p>encontrar maneiras de colaborar.</p><p>Aqui estão algumas técnicas que podem ajudar a diminuir a distância para equipes</p><p>distribuídas geograficamente. Ferramentas como Skype, Google Docs (incluindo</p><p>Google Draw), wikis e um telefone com câmera tornam a colaboração entre fusos</p><p>horários eficaz e permitem que as equipes se sintam virtualmente conectadas por</p><p>longos períodos durante o dia.</p><p>Sessão Mundial de Design Colaborativo</p><p>Equipes distribuídas geograficamente dificultam o design colaborativo. Mas os</p><p>benefícios compensam o esforço extra. Vamos dar uma olhada em como uma</p><p>equipe com quem trabalhei superou uma separação em todo o continente e</p><p>projetou soluções em conjunto.</p><p>Essa equipe foi dividida em dois grupos em duas cidades: a equipe de produto e experiência</p><p>do usuário estava em Nova York e a equipe de desenvolvimento estava em Vancouver. Meu</p><p>objetivo era realizar um Design Studio e uma sessão de mapeamento de afinidades com</p><p>toda a equipe.</p><p>DESIGN COLABORATIVO 51</p><p>www.it-ebooks.info</p><p>Configurar</p><p>Pedimos aos dois grupos que se reunissem em suas salas de conferência individuais</p><p>com seus próprios laptops. Cada sala de conferência tinha um Mac com uma conta do</p><p>Skype específica para o local (ou seja, não era a conta de um indivíduo específico, era a</p><p>conta daquele escritório). Os dois escritórios se conectaram por meio de suas contas</p><p>do Skype para que pudéssemos nos ver como um grupo. Essa etapa foi crítica, pois foi</p><p>o mais próximo que pudemos chegar de estar fisicamente na mesma sala.</p><p>Preparamos uma breve apresentação de configuração (cerca de 10 slides) que explicava a</p><p>definição do problema que estávamos abordando. Incluía depoimentos de clientes, dados e</p><p>uma breve recapitulação das necessidades de nossos clientes. A apresentação também</p><p>incluiu as restrições do espaço de solução.</p><p>Preparando a bomba com mapeamento de afinidade</p><p>Começamos com um exercício de mapeamento de afinidades. Normalmente, isso é</p><p>feito com post-its e um quadro branco. Nesse caso, utilizamos uma planilha</p><p>compartilhada do Google Docs para realizar o exercício. Pedimos a todos em ambos</p><p>os escritórios que assinassem a planilha compartilhada. A planilha em si tinha uma</p><p>coluna rotulada para cada pessoa. O Google Docs permite que vários editores</p><p>trabalhem no mesmo documento. Nesse caso, tínhamos oito membros da equipe no</p><p>documento ao mesmo tempo!</p><p>Pedimos à equipe que apresentasse tantas ideias quanto pudessem para resolver o</p><p>problema que apresentamos. Cada membro da equipe escreveu uma ideia por célula</p><p>na coluna marcada com seu nome. Demos a eles cinco minutos para gerar o máximo</p><p>de ideias que pudessem.</p><p>Para garantir que todos em cada local estivessem cientes de todas as propostas,</p><p>em seguida pedimos a cada membro da equipe que lesse suas ideias para a</p><p>equipe distribuída. Algumas ideias passaram rapidamente e outras geraram mais</p><p>discussão.</p><p>Para simular o agrupamento por afinidade na planilha compartilhada, o facilitador (eu,</p><p>neste caso) iniciou uma segunda planilha do documento usando um laptop pessoal.</p><p>Criei alguns cabeçalhos de coluna iniciais na</p><p>segunda folha que refletiam os temas</p><p>que eu ouvia enquanto o grupo lia suas ideias.</p><p>Depois pedi à equipe que pegasse cada ideia e a copiasse no tema</p><p>correspondente na segunda folha. Se não coubesse, pedia que criassem seu</p><p>próprio tema. Também os incentivei a mudar a redação dos temas à medida que</p><p>avançávamos, caso achassem que o nome do tema não era representativo ou era</p><p>enganoso.</p><p>52 Capítulo 4</p><p>www.it-ebooks.info</p><p>Ao final desse processo, tínhamos uma planilha repleta de ideias que foram</p><p>ordenadas por temas. Alguns temas tiveram apenas algumas ideias; outros</p><p>tinham até oito.</p><p>Figura 4-9.Saída de uma sessão de mapeamento de afinidade remota.</p><p>Design Studio com equipes remotas</p><p>Para preparar a próxima etapa, uma sessão do Design Studio, tentamos imitar o</p><p>máximo possível uma versão co-localizada da atividade. Distribuímos papel e</p><p>canetas para cada local. Criamos uma configuração de monitor duplo em cada</p><p>sala de conferência para que cada sala pudesse ver os esboços em um monitor e</p><p>ainda pudesse ver seus colegas de equipe via Skype no segundo monitor (como</p><p>mostrado na Figura 4-10). Pedimos a cada equipe que usasse um iPhone para</p><p>fotografar seus esboços e enviá-los por e-mail para todos os demais. Essa</p><p>configuração ajudou a conectar o diálogo e os artefatos à conversa.</p><p>Após essa configuração inicial, pudemos prosseguir com o processo do Design</p><p>Studio normalmente. Cada membro da equipe pôde apresentar suas ideias em</p><p>ambas as salas e receber críticas transcontinentais. As duas equipes conseguiram</p><p>refinar suas ideias juntas e, eventualmente, convergiram em uma ideia para levar</p><p>adiante.</p><p>DESIGN COLABORATIVO 53</p><p>www.it-ebooks.info</p><p>Figura 4-10.Configuração de monitor duplo durante o Design Studio remoto.</p><p>Concluindo: Design Colaborativo</p><p>O design colaborativo é a evolução da UX. Neste capítulo, discuti como o “código</p><p>aberto” do processo de design aprofunda toda a equipe no projeto. Falei sobre</p><p>como os desenhos de baixa fidelidade criados nas sessões do Design Studio</p><p>podem ajudar as equipes a gerar muitas ideias e então convergir para um</p><p>conjunto que toda a equipe pode apoiar. Mostrei técnicas práticas que você pode</p><p>usar para criar um entendimento compartilhado, a moeda fundamental do Lean</p><p>UX. Usando ferramentas como guias de estilo, Design Studio e conversas</p><p>simples, os membros da sua equipe podem construir um entendimento</p><p>compartilhado que lhes permite avançar em um ritmo muito mais rápido do que</p><p>em ambientes tradicionais.</p><p>Agora que todas as nossas suposições foram declaradas e nossas hipóteses de design</p><p>criadas, você pode realmente entrar no processo de aprendizagem. No próximo</p><p>capítulo, abordo o Produto Mínimo Viável (MVP) e como usá-lo para planejar</p><p>experimentos. Usaremos esses experimentos para testar a validade de nossas</p><p>suposições e decidir como avançar com nosso projeto.</p><p>54 Capítulo 4</p><p>www.it-ebooks.info</p><p>Capítulo 5</p><p>MVPs e experimentos</p><p>Toda vida é um experimento. Quanto</p><p>mais experimentos você fizer, melhor.</p><p>Ralph Waldo Emerson</p><p>Com as partes da sua hipótese agora definidas, você está pronto para determinar</p><p>quais ideias de produtos são válidas e quais você deve descartar. Neste capítulo,</p><p>discutimos o Produto Mínimo Viável (MVP) e o que ele significa no Lean UX. Além</p><p>disso, abordaremos:</p><p>• Determinar o foco do produto (entregar valor ou aumentar o aprendizado?)</p><p>usando MVP</p><p>• Usando protótipos e ferramentas de prototipagem</p><p>• Executando experimentos sem protótipos</p><p>Sobre MVPs e experimentos</p><p>Lean UX faz uso intenso da noção de MVP. Os MVPs ajudam a testar nossas suposições –</p><p>essa tática alcançará o resultado desejado? – ao mesmo tempo em que minimizam o</p><p>trabalho que colocamos em ideias não comprovadas. Quanto mais cedo descobrirmos em</p><p>quais recursos vale a pena investir, mais cedo poderemos concentrar nossos recursos</p><p>limitados nas melhores soluções para nossos problemas de negócios. Este conceito é uma</p><p>parte importante de como o Lean UX minimiza o desperdício.</p><p>55</p><p>www.it-ebooks.info</p><p>Sua lista priorizada de hipóteses lhe deu vários caminhos para explorar. Para</p><p>fazer essa exploração, você vai querer criar a menor coisa possível para</p><p>determinar a validade de cada uma dessas declarações de hipóteses. Esse é</p><p>o seu MVP. Você usará seu MVP para realizar experimentos. O resultado dos</p><p>experimentos lhe dirá se sua hipótese estava correta e, portanto, se a</p><p>direção que você está explorando deveria ser seguida, refinada ou</p><p>abandonada.</p><p>o foco de um MVP</p><p>A frase MVP causou muita confusão em sua curta vida. O problema é que ele é usado</p><p>de duas maneiras diferentes. Às vezes, as equipes criam um MVP principalmente para</p><p>aprender alguma coisa. Eles não estão preocupados em entregar valor ao mercado;</p><p>eles estão apenas tentando descobrir o que o mercado deseja. Em outros casos, as</p><p>equipes criam uma versão pequena de um produto ou recurso porque desejam</p><p>começar a entregar valor ao mercado o mais rápido possível. Nesse segundo caso, se</p><p>você projetar e implantar o MVP corretamente, também poderá aprender com ele,</p><p>mesmo que esse não seja o foco principal. Consulte a Figura 5-1.</p><p>Figura 5-1.Você criará MVPs depois de definir e priorizar um conjunto de hipóteses.</p><p>Tomemos como exemplo uma empresa de médio porte que consultei recentemente. Eles</p><p>estavam explorando novas táticas de marketing e queriam lançar um boletim informativo</p><p>mensal. A criação de boletins informativos não é uma tarefa fácil. Você precisa preparar</p><p>uma estratégia de conteúdo, calendário editorial, layout e design, bem como uma estratégia</p><p>de marketing contínua. Você precisa de escritores e editores para trabalhar nisso. Em suma,</p><p>é um grande gasto para a empresa realizar. A equipe decidiu tratar a ideia do boletim</p><p>informativo como uma hipótese.</p><p>A primeira pergunta que tiveram de responder foi se havia demanda suficiente dos clientes</p><p>por um boletim informativo para justificar o esforço. O MVP que eles usaram para testar a</p><p>ideia foi um formulário de inscrição em seu site atual. O formulário de inscrição promoveu o</p><p>boletim informativo e solicitou o endereço de e-mail de um cliente. Essa abordagem ainda</p><p>não agregaria nenhum valor ao cliente. Em vez disso, o foco estava em</p><p>56 Capítulo 5</p><p>www.it-ebooks.info</p><p>ajudando a equipe a aprender o suficiente para tomar uma boa decisão sobre</p><p>prosseguir.</p><p>Eles passaram meio dia projetando e codificando o formulário e puderam lançá-lo</p><p>naquela mesma tarde. A equipe sabia que seu site recebia uma quantidade</p><p>significativa de tráfego todos os dias: eles poderiam saber muito rapidamente se</p><p>houvesse interesse em seu boletim informativo.</p><p>Neste ponto, a equipe não fez nenhum esforço para projetar ou construir o boletim</p><p>informativo real. Isso aconteceria mais tarde, depois que a equipe tivesse reunido dados</p><p>suficientes para tomar uma decisão Avançar/Não Avançar. Depois que a equipe coletasse</p><p>dados suficientes e se os dados mostrassem que seus clientes queriam o boletim</p><p>informativo, a equipe passaria para o próximo MVP, que começaria a agregar valor e</p><p>aprendizado. Eles planejaram experimentar versões MVP do próprio boletim informativo</p><p>que lhes permitiriam testar a estratégia de conteúdo, o design e outros recursos do boletim</p><p>informativo.</p><p>Criando um MVP</p><p>Ao começar a planejar seu MVP, a primeira coisa que você precisa fazer é</p><p>considerar o que está tentando aprender. É útil pensar sobre estas três questões</p><p>básicas:</p><p>1. A solução que estou projetando é necessária?</p><p>2. Há valor na solução e nos recursos que ofereço?</p><p>3. Minha solução é utilizável?</p><p>Embora você possa construir um MVP para ajudá-lo a responder a qualquer uma dessas</p><p>perguntas, a primeira pergunta provavelmente será melhor respondida com métodos</p><p>tradicionais de pesquisa em design. (No próximo capítulo, discutiremos as abordagens Lean</p><p>para esta pesquisa.) Mas para a segunda e terceira questões, usar um MVP agrega muito</p><p>valor.</p><p>Se você estiver tentando responder à pergunta dois, provavelmente acabará</p><p>criando um MVP otimizado para aprendizado. Se a sua dúvida é sobre a</p><p>usabilidade</p><p>da sua solução, você vai querer enfatizar a entrega de valor no seu</p><p>produto. Esta etapa permitirá “lançar” um produto no mercado e “observar” os</p><p>usuários interagindo com ele em contextos realistas.</p><p>Aqui estão algumas diretrizes a serem seguidas se você estiver tentando maximizar seu</p><p>aprendizado:</p><p>Seja claro e conciso</p><p>Gaste seu tempo destilando sua ideia até sua proposta de valor central e</p><p>apresentando-a aos seus clientes</p><p>mVPs e EXPERImEnts 57</p><p>www.it-ebooks.info</p><p>Priorize implacavelmente</p><p>As ideias, assim como os artefatos, são transitórias. Deixe os melhores provarem seu valor.</p><p>Mantenha-se ágil</p><p>As informações chegarão rapidamente, portanto, certifique-se de estar trabalhando</p><p>em um meio que permita fazer atualizações facilmente.</p><p>Medir o comportamento</p><p>Crie MVPs que permitam observar e medir o que as pessoas realmentefazer, não</p><p>apenas o que as pessoas dizem. No design de produtos digitais, o comportamento</p><p>supera a opinião.</p><p>Use uma frase de chamariz</p><p>Você saberá que as pessoas valorizam sua solução quando demonstrarem que a estão</p><p>usando. Um call to action é uma frase clara, às vezes complementada por uma</p><p>imagem, que pede ao usuário uma ação específica: “inscreva-se” ou “compre agora”.</p><p>Oferecer às pessoas uma maneira de aceitar ou se inscrever em um serviço é uma</p><p>ótima maneira de saber se estão interessadas.</p><p>Aqui estão algumas diretrizes a serem seguidas se você estiver tentando agregar valor aos seus</p><p>clientes:</p><p>Seja funcional</p><p>Algum nível de integração com o restante do seu aplicativo deve estar</p><p>implementado para criar um cenário de uso realista.</p><p>Integre-se com análises existentes</p><p>A medição do desempenho do seu MVP deve ser feita dentro do contexto dos</p><p>fluxos de trabalho de produtos existentes.</p><p>Seja consistente com o resto da aplicação</p><p>Para minimizar qualquer preconceito em relação à nova funcionalidade, projete</p><p>seu MVP para se adequar ao seu guia de estilo e marca atuais.</p><p>Claro, você descobrirá que está tentando aprender e agregar valor ao</p><p>mesmo tempo. Manter essas diretrizes em mente ao planejar seus MVPs o</p><p>ajudará a navegar pelas compensações e compromissos que terá de fazer.</p><p>Independentemente do resultado desejado, crie o menor MVP possível. Lembre-</p><p>se de que é uma ferramenta de aprendizagem. Você estará iterando. Você irá</p><p>modificá-lo. Você pode muito bem estar jogando tudo fora.</p><p>E tenha uma última coisa em mente: em muitos casos, seu MVP não envolverá</p><p>nenhum código. Em vez disso, você contará com muitas das ferramentas existentes do</p><p>designer UX: esboço, prototipagem, redação e design visual.</p><p>58 Capítulo 5</p><p>www.it-ebooks.info</p><p>Prototipagem</p><p>Uma das maneiras mais eficazes de criar MVPs é prototipar a experiência.</p><p>Um protótipo é uma aproximação de uma experiência que permite simular</p><p>como é utilizar o produto ou serviço em questão. Ele precisa ser clicável (ou</p><p>tocável). Ao mesmo tempo, seu objetivo deve ser despender o mínimo de</p><p>esforço possível para criar o protótipo, o que torna importante a escolha da</p><p>ferramenta de prototipagem.</p><p>A escolha de qual ferramenta usar para seu protótipo depende de:</p><p>• Quem irá interagir com ele</p><p>• O que você espera aprender</p><p>• Quanto tempo você tem para criá-lo</p><p>É fundamental especificar o público-alvo do seu protótipo. Conhecer o seu</p><p>público permite que você crie o menor protótipo possível que irá gerar um</p><p>feedback significativo desse público. Por exemplo, se você estiver usando o</p><p>protótipo principalmente para demonstrar ideias aos engenheiros de software da</p><p>sua equipe, o protótipo poderá ignorar em grande parte áreas primárias do</p><p>produto que não estão sendo afetadas pelo protótipo, como a navegação global.</p><p>Seus desenvolvedores sabem que esses itens estão lá e não serão alterados,</p><p>então você não precisa ilustrar esses itens para eles.</p><p>As partes interessadas, muitas vezes menos familiarizadas com o seu próprio produto do que</p><p>alguma vez admitirão, provavelmente necessitarão de um maior nível de fidelidade no protótipo</p><p>para realmente compreenderem o conceito. Para atender às diversas necessidades desses</p><p>públicos díspares, seu kit de ferramentas de prototipagem deve ser bastante amplo. Você desejará</p><p>uma ampla variedade de métodos para comunicar suas ideias. Vamos dar uma olhada em</p><p>algumas maneiras de criar protótipos e os prós e contras de cada uma.</p><p>Protótipos de Baixa Fidelidade: Papel</p><p>Feitos com os componentes mais acessíveis – papel, canetas e fita adesiva – os protótipos de</p><p>papel (Figura 5-2) permitem simular experiências de maneira rápida, engenhosa e divertida.</p><p>Nenhum investimento digital é necessário. Usar táticas como flaps para mostrar e ocultar</p><p>diferentes estados em uma página ou até mesmo criar uma “janela” para uma apresentação</p><p>de slides de imagens dá à equipe uma noção de como o produto deve funcionar. Você</p><p>poderá ter uma noção imediata do que está disponível na experiência e do que está</p><p>faltando. A prototipagem em papel pode dar uma ideia de como o fluxo de trabalho está</p><p>começando a se unir em torno dos elementos da interface que você montou. A</p><p>prototipagem em papel é especialmente útil com interfaces sensíveis ao toque que exigem</p><p>que o usuário manipule elementos em uma tela.</p><p>mVPs e EXPERImEnts 59</p><p>www.it-ebooks.info</p><p>Figura 5-2.Exemplo de protótipo de papel.</p><p>Prós</p><p>• Pode ser criado em uma hora</p><p>• Facilmente organizado e reorganizado</p><p>• Barato</p><p>• Pode ser montado com materiais já encontrados no escritório</p><p>• Atividade divertida que muitas pessoas gostam</p><p>Contras</p><p>• A rápida iteração e duplicação do protótipo podem se tornar</p><p>demoradas e tediosas</p><p>• A simulação é muito artificial, porque você não está usando os mecanismos de</p><p>entrada reais (mouse, trackpad, teclado, tela sensível ao toque, etc.)</p><p>• O feedback é limitado à estrutura e fluxo de alto nível do produto</p><p>60 Capítulo 5</p><p>www.it-ebooks.info</p><p>Protótipos de baixa fidelidade: wireframes clicáveis</p><p>Criar uma experiência com wireframes clicáveis (Figura 5-3) permite levar um</p><p>protótipo ao próximo nível de fidelidade. Seu investimento em pixels proporciona uma</p><p>sensação um pouco mais realista ao fluxo de trabalho. Os participantes do teste e</p><p>membros da equipe usam mecanismos de entrada digital para interagir com o</p><p>protótipo, o que oferece melhor percepção e feedback sobre a maneira como</p><p>interagirão com o produto no nível do clique, toque ou gesto.</p><p>Figura 5-3.Exemplo de protótipo de wireframe clicável.</p><p>Prós</p><p>• Fornece uma boa noção da duração do fluxo de trabalho</p><p>• Revela grandes obstáculos à conclusão da tarefa primária</p><p>• Permite avaliar a localização dos elementos principais</p><p>• Pode ser usado para criar rapidamente “algo clicável” para que sua equipe</p><p>aprenda com seus ativos existentes, em vez de forçar a criação de novos</p><p>Contras</p><p>• A maioria das pessoas que irão interagir com esses ativos são experientes o suficiente para</p><p>reconhecer um produto inacabado</p><p>• É dada mais atenção do que o normal à rotulagem e cópia</p><p>mVPs e EXPERImEnts 61</p><p>www.it-ebooks.info</p><p>ferramentas para criar wireframes clicáveis de baixa fidelidade</p><p>Aqui estão algumas das ferramentas que funcionam bem para esse tipo de prototipagem:</p><p>Balsâmico</p><p>Uma ferramenta de wireframing barata que fornece resultados com aparência</p><p>“esboçada”. É o que há de mais próximo do esboço digital de interfaces e tem uma</p><p>comunidade robusta de suporte. Suas limitações são o que o tornam poderoso; você</p><p>não pode gastar seu tempo ajustando os pontos mais delicados da interface, então</p><p>você gasta mais tempo revisando as revisões. A capacidade de vincular páginas</p><p>facilmente o torna uma excelente ferramenta de prototipagem inicial.</p><p>Microsoft Visio</p><p>Este programa, o avô das ferramentas de wireframing, ainda pode ser usado</p><p>para vincular suas telas para criar algo clicável. Porém, é difícil trabalhar</p><p>rapidamente com o Visio: os desafios gerais de usar este produto tornam-no</p><p>cada vez menos atraente à medida que produtos mais modernos, tanto para</p><p>desktop quanto para web, entram no mercado.</p><p>OmniGraffle (somente Mac)</p><p>Em muitos aspectos, este é o equivalente do Visio</p><p>para Mac, embora seja mais fácil de</p><p>usar, tenha recursos mais robustos e forneça artefatos com melhor aparência. Você</p><p>pode usar imagens em seus desenhos para criar artefatos bonitos. Ainda assim, seu</p><p>principal poder está na diagramação, não na simulação de fluxos de trabalho e</p><p>interação.</p><p>PowerPoint</p><p>Em caso de emergência, ainda é possível confiar no PowerPoint para falsificar</p><p>algum nível de interatividade. Você pode usar as ferramentas de desenho nativas</p><p>para desenhar wireframes e vinculá-los, ou pode importar modelos, wireframes</p><p>ou capturas de tela que você criou em outra ferramenta. Ao clicar</p><p>sequencialmente em seus slides ou usar pontos de acesso vinculados, você pode</p><p>fornecer um nível mínimo de interatividade falsa. No Mac, o Keynote pode ser</p><p>usado da mesma maneira. Você também pode comprar bibliotecas de imagens</p><p>da Keynotopia que permitem montar modelos de aparência realista. A</p><p>manutenção desses protótipos pode acabar sendo muito demorada.</p><p>Fluid Designer/Protótipo Pop em Papel</p><p>Essas ferramentas de prototipagem móvel (e outras semelhantes, que estão surgindo muito</p><p>rapidamente) permitem construir rapidamente protótipos que rodam em um smartphone.</p><p>Você importa imagens (ou esboços de fotografias) e vincula-as rapidamente usando pontos</p><p>de acesso. Você pode simular fluxos de trabalho simples muito rapidamente.</p><p>62 Capítulo 5</p><p>www.it-ebooks.info</p><p>Observação</p><p>Estou ciente de que existem muitas opções no mercado para criação de wireframes e protótipos.</p><p>A lista de ferramentas que menciono nesta seção não pretende de forma alguma ser abrangente.</p><p>Na verdade, é altamente recomendável que você experimente o máximo possível dessas</p><p>ferramentas. Veja como eles se adaptam à maneira como você e sua equipe trabalham juntos. A</p><p>maioria dos produtos tem uma avaliação gratuita para que você possa fazer um teste de campo</p><p>antes de comprá-lo.</p><p>Protótipos de média e alta fidelidade</p><p>Protótipos de média e alta fidelidade (veja a Figura 5-4) têm significativamente mais</p><p>detalhes do que protótipos baseados em wireframe. Você os usará para demonstrar e</p><p>testar designs desenvolvidos com um nível de interação, visual e/ou design de</p><p>conteúdo semelhante (ou indistinguível) à experiência do produto final. O nível de</p><p>interatividade que você pode criar nesse nível varia de ferramenta para ferramenta;</p><p>no entanto, a maioria das ferramentas nesta categoria permite representar</p><p>simulações perfeitas da experiência final. Você poderá criar elementos de interface</p><p>como formulários, campos, menus suspensos que funcionam e botões de formulário</p><p>que simulam ações de envio. Algumas ferramentas permitem ramificações lógicas e</p><p>operações básicas de dados. Muitos permitem alguns tipos de pequenas animações,</p><p>transições e mudanças de estado. Além disso, o custo de criação deste nível de</p><p>fidelidade é significativamente reduzido com o uso destas ferramentas.</p><p>Figura 5-4.Exemplo de protótipo de fidelidade média.</p><p>mVPs e EXPERImEnts 63</p><p>www.it-ebooks.info</p><p>Prós</p><p>• Produz protótipos realistas e de alta qualidade</p><p>• O design visual e os elementos da marca podem ser testados</p><p>• O fluxo de trabalho e as interações da interface do usuário podem ser avaliadas</p><p>Contras</p><p>• A interatividade ainda é mais limitada do que os protótipos totalmente nativos</p><p>• Os usuários normalmente não conseguem interagir com dados reais, portanto há um limite para os</p><p>tipos de interações com produtos que você pode simular</p><p>• Dependendo da ferramenta, pode ser demorado criar e manter estes</p><p>protótipos; manter um protótipo de alta fidelidade e sincronizá-lo</p><p>com o produto real geralmente envolve esforço duplicado</p><p>ferramentas para criar wireframes clicáveis de média e alta fidelidade</p><p>Aqui estão algumas das ferramentas que funcionam bem para esse tipo de prototipagem</p><p>(novamente, esta é apenas uma lista parcial):</p><p>Axure RP</p><p>Esta ferramenta de prototipagem cada vez mais popular permite criar páginas da web</p><p>realistas com telas e formulários e enviar fluxos de trabalho. Os modelos Axure rodam</p><p>em qualquer navegador e fazem um excelente trabalho de simulação de páginas da</p><p>web. Por importar bem imagens e suportar elementos de interface de usuário HTML</p><p>nativos, é uma ferramenta de prototipagem de média fidelidade muito eficaz (embora</p><p>você também possa usá-la para protótipos de baixa e alta fidelidade). Possui uma boa</p><p>lógica condicional, para que você possa simular uma boa variedade de interações.</p><p>Uma comunidade crescente de suporte está surgindo em torno do Axure, e muitos</p><p>designers de interação começaram a usá-lo como ferramenta principal. Sua</p><p>capacidade de gerar especificações a partir do protótipo é um bônus adicional para</p><p>organizações que ainda fazem essas demandas às suas equipes.</p><p>Adobe Fireworks</p><p>Uma antiga aquisição da Macromedia, o Fireworks tenta combinar o melhor do Adobe</p><p>Illustrator com o melhor do Photoshop e misturá-lo em uma mistura de pseudo-</p><p>interatividade que o torna uma poderosa ferramenta de prototipagem quando a fidelidade</p><p>visual é importante. Você pode criar telas e gerenciar diversos estados de elementos</p><p>específicos. Você pode adicionar componentes de formulário de trabalho. Você pode vincular</p><p>elementos por meio de pontos de acesso simples. Você pode criar bibliotecas de ativos</p><p>personalizados que tornam eficiente a reutilização de elementos de interface e incentivam o</p><p>uso da ferramenta.</p><p>64 Capítulo 5</p><p>www.it-ebooks.info</p><p>Protótipos Codificados</p><p>Os protótipos codificados oferecem o mais alto nível de fidelidade para</p><p>experiências simuladas. Para todos os efeitos, as pessoas que interagem com</p><p>este tipo de protótipo não devem ser capazes de distingui-lo do produto final, a</p><p>menos que esbarrem nos limites do seu âmbito (ou seja, cliquem num link para</p><p>uma página que não foi prototipada). . Os protótipos codificados existem no</p><p>ambiente nativo (o navegador, o sistema operacional, o dispositivo, etc.) e fazem</p><p>uso de todos os elementos interativos esperados. Botões, menus suspensos e</p><p>campos de formulário funcionam conforme o usuário espera. Esses protótipos</p><p>recebem informações do mouse, teclado e tela. Eles criam um padrão de</p><p>interação o mais natural possível para os avaliadores do protótipo.</p><p>Protótipos codificados manualmente e com dados ao vivo</p><p>Existem dois níveis de fidelidade para protótipos codificados: dados codificados manualmente e</p><p>dados ao vivo. Os protótipos codificados manualmente parecem e funcionam como o produto</p><p>final, mas não levam em conta nenhum tipo de entrada, processamento ou saída de dados em</p><p>tempo real. Eles ainda são apenas simulações. Os protótipos de dados ao vivo se conectarão com</p><p>dados em tempo real e processarão a entrada do usuário. Eles geralmente são implantados em</p><p>clientes reais e oferecem um nível de percepção analítica sobre o uso do protótipo pelos clientes</p><p>que não está disponível em protótipos codificados manualmente. Eles também podem ser usados</p><p>em testes A/B de determinados recursos ou alterações no fluxo de trabalho atual.</p><p>Prós</p><p>• Potencial para reutilizar código para produção</p><p>• A simulação mais realista para criar</p><p>• Pode ser gerado a partir de ativos de código existentes</p><p>Contras</p><p>• A equipe pode ficar atolada em debater os pontos mais delicados do protótipo</p><p>• Demorado para criar um código funcional que ofereça a experiência</p><p>desejada</p><p>• Tentação de aperfeiçoar o código antes de liberá-lo para os clientes</p><p>• Atualizar e iterar pode levar muito tempo</p><p>mVPs e EXPERImEnts 65</p><p>www.it-ebooks.info</p><p>O que deve entrar no meu protótipo?</p><p>Você escolheu a ferramenta para criar seu MVP e está pronto para começar. Não</p><p>há necessidade de prototipar toda a experiência do produto. Em vez disso,</p><p>simule a parte mais importante da experiência para seu cliente e sua empresa.</p><p>Concentre-se nos principais fluxos de trabalho que ilustram seu MVP.</p><p>Concentrar-se nos fluxos de trabalho primários do seu MVP dá à equipe uma sensação</p><p>de visão temporária (no bom sentido!), permitindo que eles se concentrem em uma</p><p>parte específica da experiência e avaliem sua validade e</p><p>eficácia.</p><p>Figura 5-5.Onde a prototipagem se encaixa no ciclo Lean UX</p><p>Demonstrações e prévias</p><p>Teste seu MVP prototipado com seus colegas de equipe, partes interessadas e</p><p>membros de outras equipes. Leve para a área de almoço e compartilhe com</p><p>colegas que trabalham em diversos projetos. Certifique-se de que as pessoas</p><p>dentro da empresa forneçam à equipe insights sobre como funciona bem, como</p><p>irão utilizá-lo e se vale a pena investir adicional. Deixe as partes interessadas</p><p>clicarem nele e fornecerem suas idéias e opiniões.</p><p>Os protótipos ajudam a mostrar às partes interessadas do projeto que estão</p><p>sendo feitos progressos. Se sua equipe tiver um dia de demonstração (e se não</p><p>tiver, deveria), leve o protótipo para lá para mostrar o progresso do projeto.</p><p>Quanto mais exposição o MVP obtiver, mais insights você terá sobre sua</p><p>validade. Em seguida, leve seu protótipo para clientes e potenciais clientes.</p><p>Deixe-os clicar na experiência e coletar seus comentários.</p><p>Juntando tudo: usando um protótipo MVP</p><p>Veja como uma equipe com quem trabalhei recentemente usou um protótipo de MVP.</p><p>Neste estudo de caso, a equipe estava pensando em fazer uma mudança significativa em</p><p>sua oferta. Utilizamos um protótipo MVP para apoiar o processo de pesquisa e tomada de</p><p>decisão.</p><p>66 Capítulo 5</p><p>www.it-ebooks.info</p><p>Esta startup estabelecida estava enfrentando dificuldades com seu produto atual: uma</p><p>comunidade exclusiva baseada em assinatura para colaboração em grupo. Ele estava</p><p>no mercado há alguns anos e ganhou força, mas a adoção atingiu um patamar –</p><p>novos usuários não estavam se inscrevendo. Percebendo que era necessária uma</p><p>mudança radical, especialmente à luz da concorrência crescente, consideraram</p><p>renovar o seu modelo de negócio e abrir o produto a um segmento de mercado</p><p>significativamente mais amplo. A preocupação deles era dupla:</p><p>• Os usuários atuais aceitariam esta mudança, visto que alteraria a</p><p>natureza exclusiva da comunidade?</p><p>• Será que o novo segmento de mercado estaria interessado neste tipo de</p><p>produto?</p><p>A equipe estava preocupada com a possibilidade de sofrer um golpe duplo. Eles</p><p>temiam que os usuários existentes abandonassem o produto e que não</p><p>houvesse novos usuários suficientes para compensar a deficiência.</p><p>Trabalhei com a equipe para definir nosso plano como uma hipótese. Definimos o</p><p>novo segmento de mercado e definimos o conjunto principal de funcionalidades que</p><p>queríamos fornecer a esse segmento. Era apenas um subconjunto da visão final, mas</p><p>poderia ser articulado em cinco wireframes.</p><p>Passamos uma semana criando wireframes usando Balsamiq para garantir que</p><p>nossos desenvolvedores, profissionais de marketing e executivos concordassem</p><p>com a nova direção. Mostramos os wireframes aos clientes atuais (duas vezes!)</p><p>ao longo desses cinco dias e terminamos com um protótipo clicável – nosso MVP.</p><p>O momento da nossa experiência foi fortuito: havia uma conferência cheia de</p><p>potenciais clientes marcada para a semana seguinte no Texas. A equipe voou até</p><p>a conferência e percorreu os corredores do centro de convenções com o</p><p>protótipo em nossos iPads.</p><p>Os modelos funcionaram muito bem nos iPads: os clientes tocaram, deslizaram e</p><p>conversaram conosco sobre a nova oferta. Três dias depois, voltamos a Nova</p><p>York com comentários escritos em todos os post-its e pedaços de papel</p><p>disponíveis.</p><p>Reunimos as notas em grupos e surgiram alguns temas claros. O feedback</p><p>dos clientes fez-nos perceber que, embora houvesse mérito neste novo</p><p>plano de negócios, precisaríamos de maior diferenciação dos produtos</p><p>existentes no mercado se quiséssemos ter sucesso.</p><p>Ao todo, passamos oito dias úteis desenvolvendo nossas hipóteses, criando nosso MVP e obtendo</p><p>feedback do mercado. Este trabalho nos colocou em uma excelente posição para refinar o produto</p><p>para se adequar ao nosso segmento de mercado de forma mais eficaz.</p><p>mVPs e EXPERImEnts 67</p><p>www.it-ebooks.info</p><p>MVPs sem protótipo</p><p>Para muitas equipes, a abordagem padrão para criar um MVP é criar um protótipo –</p><p>para começar imediatamente a projetar e escrever código. É fácil entender essa</p><p>abordagem: somos treinados para testar nossos designs e nosso código, então</p><p>quando pensamos em validação, naturalmente pensamos em criar um mockup de</p><p>produto para testar. Há muitas ocasiões em que esta etapa não é necessária e pode</p><p>até ser prejudicial. Por mais valiosa que seja a prototipagem, ela não é o único</p><p>caminho a seguir.</p><p>Às vezes faz sentido criar um MVP que não simule seu produto e, em vez</p><p>disso, permita testar algo relacionado ao seu produto. Por exemplo, quando</p><p>sua equipe está tentando determinar o valor de um novo recurso ou</p><p>produto, muitas vezes faz sentido usar um MVP sem protótipo para saber se</p><p>você está no caminho certo.</p><p>O mantra a ter em mente ao criar MVPs sem protótipo é este: você</p><p>sempre pode ficar mais magro. Para planejar seu MVP, pergunte-se o</p><p>seguinte:</p><p>1. O que estou tentando aprender?</p><p>2. Quais são os principais sinais do mercado que preciso para validar minha</p><p>hipótese?</p><p>3. Existem outros sinais que eu possa testar e que servirão como indicadores para</p><p>meu sinal principal?</p><p>4. Qual é a maneira mais rápida de encontrar essas informações?</p><p>Como exemplo, vamos responder a estas perguntas para uma solução que uma empresa de</p><p>comércio eletrônico deseja testar:</p><p>1.O que estou tentando aprender?Estamos tentando saber se esta nova solução de</p><p>comércio eletrônico aumentará as compras.</p><p>2.Quais são os principais sinais que preciso do mercado para validar</p><p>minha hipótese?O principal sinal que buscamos do mercado é o</p><p>aumento nas compras concluídas.</p><p>3.Há algum sinal que eu possa testar que servirá como indicador do meu sinal</p><p>principal?Em vez de compras concluídas, podemos testar a intenção do</p><p>cliente e usá-la como proxy para compras?</p><p>4.Qual é a maneira mais rápida de encontrar essas informações?Vamos enviar um e-mail</p><p>para um subconjunto de nossos usuários oferecendo alguns itens à venda e contar os</p><p>cliques para essa frase de chamariz. Isso nos ajudará a determinar o interesse e a</p><p>intenção de compra.</p><p>68 Capítulo 5</p><p>www.it-ebooks.info</p><p>tipos de MVPs não protótipos</p><p>Vamos dar uma olhada rápida em algumas técnicas para criar MVPs sem protótipo.</p><p>E-mail</p><p>O e-mail é uma ferramenta muito poderosa quando se trata de aprender sobre</p><p>seus clientes. Taxas de abertura, cliques e taxas de conclusão de tarefas para</p><p>destinatários fornecem informações sobre se sua ideia tem valor.</p><p>Google AdWords</p><p>Uma experiência muito barata é comprar anúncios do Google Ad Words que</p><p>direcionam pesquisas relevantes para o seu negócio. Ao monitorar o que as</p><p>pessoas estão procurando, você começará a receber feedback sobre que</p><p>tipo de linguagem repercute em seu público. Ao medir os cliques, você pode</p><p>ver quanto interesse existe nas palavras e mensagens que você propõe.</p><p>Página inicial</p><p>Uma página de destino para tráfego de cliques de anúncios do Google pode validar</p><p>ainda mais seu pensamento. Uma landing page é o equivalente online a um estúdio de</p><p>cinema do Velho Oeste. É apenas uma fachada do seu serviço, construída com uma</p><p>frase de chamariz muito específica e óbvia. Seja Inscreva-se, Compre agora ou</p><p>Compartilhe com um amigo, cada usuário que conclui a tarefa em sua página de</p><p>destino conta como validação da ideia de seu produto.</p><p>O botão para lugar nenhum</p><p>Um recurso pode ser testado em seu site adicionando um botão à interface</p><p>que divulga a nova funcionalidade. Esse botão nada mais faz do que medir</p><p>o número de vezes que foi clicado. Cada clique indica o desejo do cliente</p><p>por esse recurso. Com interesse mensurável suficiente, o desenvolvimento</p><p>do recurso pode continuar. Claro, você deve dar ao usuário alguma</p><p>explicação sobre por que o recurso não está funcionando. Você pode usar</p><p>essa interação adicional como uma chance de capturar um endereço de e-</p><p>mail ou outro feedback.</p><p>Híbridos e Criatividade</p><p>Quando converso com equipes e empreendedores, muitas vezes fico impressionado com o</p><p>quão criativos eles podem ser em sua abordagem para criar MVPs. Projetar</p><p>você poderia examinar cada silo</p><p>de excelência funcional, um de cada vez. Veja-os com os olhos da sua mente: Marketing,</p><p>Operações, Manufatura, TI, Engenharia, Design e assim por diante, em uma fileira</p><p>organizada de silos nítidos e bem administrados.</p><p>Vamos imaginar que você se abaixou para pegar um desses silos e abriu a tampa para</p><p>ver o interior. O que você veria? Sendo uma empresa moderna, você veria cada silo</p><p>projetado para máxima eficiência. Para alcançar essa eficiência, você provavelmente</p><p>encontrará uma abordagem altamente iterativa e centrada no cliente para a solução</p><p>de problemas. Na Manufatura, você encontrará o pensamento Lean tradicional. Em</p><p>Engenharia ou TI, talvez alguma variação no desenvolvimento ágil. Em Marketing,</p><p>desenvolvimento de clientes. Em Operações, DevOps. E, claro, em Design, o que há de</p><p>mais moderno em design thinking, design de interação e técnicas de pesquisa de</p><p>usuário.</p><p>Voltando à nossa posição elevada, podemos ser perdoados por pensar “Esta empresa</p><p>usa uma variedade de metodologias rigorosas, baseadas em hipóteses, centradas no</p><p>cliente e iterativas. Certamente, deve ser uma empresa extremamente ágil, capaz de</p><p>reagir rapidamente às mudanças nas condições do mercado e inovar continuamente!”</p><p>Mas aqueles de nós que trabalham em empresas modernas sabem o quanto isso está</p><p>longe da verdade.</p><p>IX</p><p>www.it-ebooks.info</p><p>Como é possível que os nossos silos departamentais operem com agilidade, mas as</p><p>nossas empresas sejam irremediavelmente rígidas e lentas? Do nosso ponto de vista</p><p>distante, perdemos algo essencial. Embora nossos departamentos possam valorizar a</p><p>agilidade, ointerconexõesentre eles ainda estão atolados em um passado industrial</p><p>antiquado.</p><p>Consideremos apenas um exemplo, que espero que lhe pareça familiar. Uma empresa</p><p>decide que deve inovar para sobreviver. Contrata uma equipa de design (interna ou</p><p>externa) para investigar o futuro da sua indústria e recomendar novos produtos</p><p>inovadores que possam garantir o seu futuro. Começa um período de grande</p><p>excitação. Os clientes são entrevistados, observados, analisados. Experimentos,</p><p>pesquisas, grupos focais, protótipos e testes de fumaça seguem um após o outro. Os</p><p>conceitos são rapidamente concebidos, testados, rejeitados e refinados.</p><p>E o que acontece no final desse processo? Os designers apresentam com orgulho</p><p>– e as empresas comemoram com entusiasmo – um enorme documento de</p><p>especificações com suas descobertas e recomendações. A iteração,</p><p>experimentação e descoberta cessam. Agora a engenharia é chamada para</p><p>executar esse plano. E embora o processo de engenharia possa ser ágil, o</p><p>documento de especificação é rigidamente fixado. O que acontece se os</p><p>engenheiros descobrirem que a especificação era impraticável ou mesmo</p><p>ligeiramente falha? E se os conceitos funcionassem muito bem no laboratório,</p><p>mas não tivessem apelo comercial? E se as condições de mercado tiverem</p><p>mudado desde que ocorreu a “aprendizagem” original?</p><p>Certa vez, conversei com uma empresa que havia encomendado – com custos terríveis</p><p>– um estudo de vários anos sobre seu setor. O resultado foi um impressionante</p><p>display de “visão do futuro” personalizado em sua sede corporativa. Dentro desta sala,</p><p>você poderia ver uma extrapolação de como seriam os próximos 10 anos em sua</p><p>indústria, completa com demonstrações funcionais de conceitos de produtos</p><p>futuristas. Você pode adivinhar o que aconteceu nos 10 anos seguintes:</p><p>absolutamente nada. A empresa fez circular centenas ou milhares de executivos,</p><p>gerentes e trabalhadores nesse vislumbre do futuro. E, de facto, 10 anos depois, a sala</p><p>já não parece futurista. Contra todas as probabilidades, as suas previsões revelaram-</p><p>se bastante precisas. E ainda assim, a empresa não conseguiu comercializar nem</p><p>mesmo uma das recomendações do documento de especificações correspondente.</p><p>Então perguntei à empresa o que eles planejavam fazer a seguir; eles me disseram</p><p>que voltariam aos designers originais e pediriam que fizessem previsões para os</p><p>próximos 10 anos! A empresa culpou seus engenheiros e gerentes pelo fracasso na</p><p>comercialização, e não os designers.</p><p>Quando conto essa história para quem não é designer, eles ficam horrorizados e</p><p>querem me convencer de que a culpa é da empresa de design chique. Quando conto</p><p>isso para executivos seniores – tanto de grandes empresas quanto de startups – eles</p><p>X Prefácio</p><p>www.it-ebooks.info</p><p>desgosto. Eles são constantemente inundados com reclamações de todas as</p><p>funções de que são rápidos e inovadores, mas são os outros departamentos que</p><p>atrasam a empresa. Quando toda a empresa não consegue encontrar novas</p><p>fontes de crescimento, há muita culpa para todos.</p><p>Mas a culpa não é dos designers, nem dos engenheiros, nem mesmo dos</p><p>executivos. O problema são os sistemas que usamos para construir empresas.</p><p>Ainda estamos construindo organizações lineares num mundo que exige</p><p>mudanças constantes. Ainda estamos construindo silos num mundo que exige</p><p>colaboração completa. E continuamos a investir em análise, a discutir</p><p>especificações e a produzir resultados de forma eficiente num mundo que exige</p><p>experimentação contínua para alcançar inovação contínua.</p><p>Já se passaram cerca de quatro anos desde que comecei a escrever e falar sobre um</p><p>novo conceito chamado Lean Startup.,e apenas um ano desde que publiquei A startup</p><p>enxuta: como os empreendedores de hoje usam a inovação contínua para alcançar</p><p>negócios radicalmente bem-sucedidos(Negócios da Coroa). Nesse período, vi as ideias</p><p>crescerem e se espalharem – de indústria em indústria, de setor em setor e de função</p><p>em função. Sempre que encontramos novos terrenos, contamos com líderes</p><p>clarividentes para ajudar a traduzir os princípios fundamentais e desenvolver novos</p><p>processos para implementá-los.</p><p>Experiência do usuário enxutaé um passo importante nessa evolução. Pela primeira vez,</p><p>temos uma visão abrangente de como os princípios da Lean Startup se aplicam em um</p><p>contexto de design. Ao longo do caminho, introduz novas ferramentas e técnicas</p><p>importantes para alcançar colaboração superior, entrega mais rápida e, o mais importante,</p><p>produtos dramaticamente melhores.</p><p>Lean Startup é uma grande tenda. Baseia-se em ideias estabelecidas de muitas</p><p>disciplinas, desde a manufatura enxuta até o design thinking. Isso nos dá um</p><p>vocabulário comum e um conjunto de conceitos que podem ser usados para acelerar</p><p>resultados em toda a empresa. Podemos parar de perder tempo discutindo sobre</p><p>quem é o culpado e qual departamento deveria governar o dia.</p><p>Espero que todos nós nos lembremos de atender ao chamado de Jeff Gothelf</p><p>para “sair do negócio de entregas” e retornar nosso foco para onde ele pertence,</p><p>recrutando toda a empresa em sua tarefa mais urgente: encantar os clientes.</p><p>É hora de quebrar os silos, unir os clãs e começar a trabalhar.</p><p>Eric Ries</p><p>30 de janeiro de 2013</p><p>São Francisco, Califórnia</p><p>Prefácio XI</p><p>www.it-ebooks.info</p><p>www.it-ebooks.info</p><p>Prefácio</p><p>A maior mentira no software é a Fase II.</p><p>Se você passou algum tempo construindo produtos digitais nos últimos 20 anos,</p><p>independentemente de sua função, você sentiu a dor dessa mentira. Você deixa de</p><p>lado recursos e ideias para a próxima fase do trabalho e então eles desaparecem, para</p><p>nunca mais serem ouvidos. Como designer, centenas, senão milhares, de wireframes</p><p>e fluxos de trabalho acabaram no mesmo balde.</p><p>Mas será que essas ideias desapareceram porque eram falhas? Os recursos fornecidos</p><p>realmente atendiam às metas do cliente e do negócio, de modo que as ideias da Fase II</p><p>nunca foram necessárias? Ou a equipe simplesmente ficou sem tempo? A equipe nunca</p><p>chegou à Fase II.</p><p>EmA startup enxuta, Eric Ries expõe sua visão sobre como garantir que as</p><p>ideias que têm mais valor obtenham mais recursos. O método que Ries</p><p>promove depende de experimentação, iteração rápida de ideias e processos</p><p>evolutivos. Para Ries, todo o conceito da Fase II torna-se discutível.</p><p>A junção do Lean Startup e do design baseado na experiência do usuário (UX) e sua</p><p>coexistência</p><p>testes é um</p><p>processo criativo e você deve usar os métodos listados neste capítulo como inspiração para</p><p>sua criatividade. A melhor abordagem para você geralmente será um mashup de muitas</p><p>abordagens.</p><p>mVPs e EXPERImEnts 69</p><p>www.it-ebooks.info</p><p>Aqui está um exemplo de como Cheryl Yeoh lançou o CityPockets usando uma abordagem</p><p>híbrida chamada Concierge MVP para descobrir se sua ideia resolveu um problema real e se</p><p>havia demanda suficiente para justificar sua construção de verdade.</p><p>Cheryl Yeoh iniciou o CityPockets com a hipótese de que as pessoas tinham</p><p>dificuldade para gerenciar, acompanhar e resgatar todas as ofertas diárias e</p><p>cupons que compravam online. Ela entrevistou clientes para validar se realmente</p><p>havia uma necessidade, mas não tinha certeza se sua solução – uma carteira on-</p><p>line para todos esses cupons – traria o tipo de valor que esses clientes</p><p>precisavam. Para validar sua hipótese, ela lançou uma versão MVP do</p><p>CityPockets.com que apresentava apenas um front-end. Construir o</p><p>processamento e a integração de back-end de que ela precisaria custaria caro;</p><p>ela não queria gastar seu dinheiro a menos que tivesse certeza de que seus</p><p>clientes considerariam seu serviço valioso.</p><p>Em vez de criar um back-end, Cheryl atribuiu um endereço de e-mail exclusivo a</p><p>cada cliente que se inscreveu no serviço. Ela instruiu seus clientes a encaminhar</p><p>todos os e-mails de cupons para esse endereço. Nos bastidores, Cheryl inseria</p><p>manualmente cada cupom em um banco de dados. Ela estabeleceu uma meta</p><p>arbitrária para si mesma: 500 e-mails por dia. Se os clientes lhe enviassem 500 e-</p><p>mails por dia, ela se sentia confiante ao concluir que haveria demanda suficiente</p><p>pelo serviço para merecer mais investimento. Ela estaria pronta nesse ponto para</p><p>construir um back-end para assumir o processamento.</p><p>Essa abordagem – embora envolvesse algum design e codificação – deixou de lado o</p><p>trabalho pesado. Em vez disso, permitiu que Cheryl concentrasse seu investimento no</p><p>menor conjunto possível de recursos de que precisava para apoiar seu aprendizado. No</p><p>final das contas, esta é a essência da abordagem Lean UX. Projete apenas o que você</p><p>precisa. Entregue rapidamente. Crie contato suficiente com o cliente para obter feedback</p><p>significativo rapidamente.</p><p>70 Capítulo 5</p><p>www.it-ebooks.info</p><p>Conclusão</p><p>Neste capítulo, definimos o Produto Mínimo Viável como a menor coisa que você</p><p>pode fazer para saber se sua hipótese é válida. Além disso, discutimos as diversas</p><p>formas que um MVP pode assumir, analisamos mais de perto a prototipagem e</p><p>discutimos táticas de aprendizagem que não exigem a construção de protótipos.</p><p>No Capítulo 6, daremos uma olhada em vários tipos de pesquisa que você pode</p><p>usar para garantir que seus projetos estejam atingindo o alvo. Também veremos</p><p>como sua equipe pode entender todo o feedback que sua pesquisa irá gerar.</p><p>mVPs e EXPERImEnts 71</p><p>www.it-ebooks.info</p><p>www.it-ebooks.info</p><p>Capítulo 6</p><p>Feedback e pesquisa</p><p>Pesquisa é curiosidade formalizada. Está cutucando e</p><p>espionando com um propósito.</p><p>Zora Neale Hurston</p><p>Agora é hora de testar nosso MVP. Todo o nosso trabalho até agora foi</p><p>baseado em suposições; agora devemos iniciar o processo de validação.</p><p>Usamos técnicas de pesquisa leves, contínuas e colaborativas para fazer isso.</p><p>A pesquisa com usuários está no centro da maioria das abordagens de UX. Muitas</p><p>vezes, as equipes terceirizam o trabalho de pesquisa para equipes de pesquisa</p><p>especializadas. E muitas vezes, as atividades de pesquisa ocorrem apenas em raras</p><p>ocasiões – seja no início ou no final de um projeto. O Lean UX resolve os problemas</p><p>que essas táticas criam, tornando a pesquisa contínua e colaborativa. Vamos nos</p><p>aprofundar para ver como fazer isso.</p><p>Neste capítulo, abordamos:</p><p>• Técnicas de pesquisa colaborativa que permitem construir um entendimento</p><p>compartilhado com sua equipe</p><p>• Técnicas de pesquisa contínua que permitem construir estudos de pesquisa</p><p>qualitativa pequenos e informais em cada iteração</p><p>73</p><p>www.it-ebooks.info</p><p>• Quais artefatos testar e quais resultados você pode esperar de cada um</p><p>desses testes</p><p>• Como incorporar a voz do cliente em todo o ciclo Lean UX</p><p>• Como usar testes A/B (descritos posteriormente neste capítulo) em sua pesquisa</p><p>• Como conciliar feedback contraditório de múltiplas fontes</p><p>Contínuo e Colaborativo</p><p>Lean UX utiliza técnicas básicas de pesquisa de UX e sobrepõe duas ideias importantes.</p><p>Primeiro, a pesquisa Lean UX é contínua; isso significa que você incorpora atividades de</p><p>pesquisa em cada sprint. Em vez de um processo big bang dispendioso e perturbador,</p><p>fazemos pesquisas pequenas para que possamos encaixá-las em nosso processo contínuo.</p><p>Em segundo lugar, a pesquisa Lean UX é colaborativa: você não depende do trabalho de</p><p>pesquisadores especializados para entregar aprendizado à sua equipe. Em vez disso, as</p><p>atividades e responsabilidades de pesquisa são distribuídas e compartilhadas por toda a</p><p>equipe. Ao eliminar a transferência entre pesquisadores e membros da equipe,</p><p>aumentamos a qualidade do nosso aprendizado. Nosso objetivo em tudo isso é criar um</p><p>rico entendimento compartilhado por toda a equipe. Consulte a Figura 6-1.</p><p>Figura 6-1.Coletar feedback por meio de pesquisa é a etapa final do ciclo Lean UX.</p><p>Descoberta Colaborativa</p><p>O design colaborativo (abordado no Capítulo 4) é uma das duas principais</p><p>maneiras de unir funções dentro de uma equipe Lean UX.Descoberta</p><p>colaborativa— trabalhar em equipe para testar ideias no mercado — é a outra. A</p><p>descoberta colaborativa é uma abordagem de pesquisa que tira toda a equipe do</p><p>prédio – literal e figurativamente – para se reunir e aprender com os clientes. Isso</p><p>dá a todos na equipe a chance de ver como as hipóteses estão sendo testadas e,</p><p>o mais importante, multiplica o número de informações que a equipe pode usar</p><p>para coletar insights do cliente.</p><p>74 Capítulo 6</p><p>www.it-ebooks.info</p><p>É essencial que você e sua equipe conduzam pesquisas juntos; é por isso que eu</p><p>chamo issocolaborativodescoberta. Terceirizar essa tarefa reduz drasticamente seu</p><p>valor: desperdiça tempo, desperdiça a formação de equipes e filtra as informações por</p><p>meio de entregas, transferências e interpretação. Não faça isso.</p><p>Os pesquisadores às vezes se opõem a essa abordagem de pesquisa. Como profissionais</p><p>capacitados, eles têm razão em ressaltar que possuem conhecimentos especiais e</p><p>importantes para o processo de pesquisa. Concordo. É por isso que você deve incluir um</p><p>pesquisador em sua equipe, se puder. Apenas não terceirize o trabalho para essa pessoa.</p><p>Em vez disso, use o pesquisador como treinador para ajudar sua equipe a planejar e</p><p>executar suas atividades.</p><p>Descoberta colaborativa no campo</p><p>A descoberta colaborativa é uma forma de sair em campo com sua equipe. Veja</p><p>como você faz isso:</p><p>• Em equipe, revise suas perguntas, suposições, hipóteses e MVPs. Decidam em</p><p>equipe o que vocês precisam aprender.</p><p>• Trabalhando em equipe, decida com quem você precisará falar para atingir seus</p><p>objetivos de aprendizagem.</p><p>• Crie um guia de entrevista (veja a barra lateral a seguir) que todos vocês possam</p><p>usar para orientar suas conversas.</p><p>• Divida sua equipe em pares de entrevistadores, misturando as diversas funções e</p><p>disciplinas dentro de cada par (ou seja, tente não ter designers emparelhados com</p><p>designers).</p><p>• Equipe cada par com uma versão do MVP.</p><p>• Envie cada equipe para se reunir com clientes/usuários.</p><p>• Peça a um membro da equipe que conduza entrevistas enquanto o outro faz anotações.</p><p>• Comece com perguntas, conversas e observações.</p><p>• Demonstre o MVP posteriormente na sessão e permita que o cliente</p><p>interaja com ele.</p><p>• Colete notas à medida que o cliente fornece feedback.</p><p>• Quando o entrevistador principal terminar, troque de papéis para dar ao anotador a oportunidade de</p><p>fazer perguntas de acompanhamento.</p><p>• No final da entrevista, peça ao cliente referências de outras pessoas</p><p>que também possam fornecer feedback útil.</p><p>FEEDBACK E PESQUISA 75</p><p>www.it-ebooks.info</p><p>O guia da entrevista</p><p>Para se preparar para o trabalho de campo, crie uma pequena folha de dicas que caiba em seu</p><p>caderno. Em sua folha de dicas, escreva as perguntas e os tópicos que você decidiu abordar com</p><p>este guia, você estará sempre preparado para prosseguir com a entrevista.</p><p>Ao planejar suas perguntas, pense em um funil sequencial: primeiro, tente identificar se o</p><p>cliente faz parte do seu público-alvo. Em seguida, tente confirmar quaisquer hipóteses de</p><p>problema que você tenha para este segmento. Por fim, se você tiver um protótipo ou</p><p>maquete, mostre-o por último ao cliente para evitar limitar a conversa à sua visão da</p><p>solução.</p><p>Descoberta colaborativa: um exemplo</p><p>Uma equipe com quem trabalhei no PayPal criou um protótipo Axure para conduzir</p><p>uma sessão de descoberta colaborativa. A equipe era formada por dois designers, um</p><p>pesquisador de UX, quatro desenvolvedores e um gerente de produto; eles se</p><p>dividiram em equipes de dois e três. Cada desenvolvedor foi emparelhado com um</p><p>não desenvolvedor. Antes de começar, a equipe debateu o que gostaria de aprender</p><p>com seu protótipo e usou o resultado dessa sessão para escrever breves guias de</p><p>entrevistas. Seu produto era direcionado a um amplo mercado consumidor, então eles</p><p>decidiram ir aos shoppings próximos ao escritório. Cada par tinha como alvo um</p><p>shopping diferente. Eles passaram duas horas em campo parando estranhos, fazendo</p><p>perguntas e demonstrando seus protótipos. Para desenvolver seu conjunto de</p><p>habilidades, eles mudaram de função (de entrevistador principal para anotador) após</p><p>uma hora de pesquisa.</p><p>Quando se reuniram novamente, cada dupla leu suas anotações para o restante da</p><p>equipe. Quase imediatamente, começaram a ver surgir padrões, provando algumas</p><p>das suas suposições e refutando outras. Usando essas novas informações, eles</p><p>ajustaram o design do protótipo e partiram novamente no final da tarde. Depois de</p><p>um dia inteiro de pesquisa de campo, ficou claro quais ideias tinham fundamento e</p><p>quais precisavam de poda. Quando começaram o próximo sprint no dia seguinte,</p><p>todos os membros da equipe estavam trabalhando a partir da mesma linha de base</p><p>de clareza, tendo estabelecido um entendimento compartilhado por meio da</p><p>descoberta colaborativa no dia anterior.</p><p>Descoberta Contínua</p><p>Uma prática recomendada crítica em Lean UX é construir uma cadência regular de</p><p>envolvimento do cliente. Conversas agendadas regularmente com clientes minimizam</p><p>o tempo entre a criação de hipóteses, o design do experimento e o feedback do</p><p>usuário, permitindo que você valide suas hipóteses rapidamente. Em geral, saber que</p><p>você nunca estará a mais do que alguns dias do feedback do cliente</p><p>76 Capítulo 6</p><p>www.it-ebooks.info</p><p>tem um efeito poderoso nas equipes. Isso tira a pressão da sua tomada de</p><p>decisão porque você sabe que nunca demorará mais do que alguns dias</p><p>para obter dados significativos do mercado.</p><p>Descoberta contínua no laboratório: três usuários todas as quintas-feiras</p><p>Embora você possa criar um cronograma permanente de trabalho de campo</p><p>com base nas técnicas descritas neste capítulo, é muito mais fácil trazer</p><p>clientes para o prédio – você só precisa ser um pouco criativo para envolver</p><p>toda a equipe.</p><p>Gosto de usar um ritmo semanal para trazer clientes ao prédio para participarem de</p><p>pesquisas. Chamo isso de “3-12-1”, porque se baseia nas seguintes diretrizes: três</p><p>usuários, até o meio-dia, uma vez por semana (Figura 6-2).</p><p>Figura 6-2.O calendário de atividades 3-12-1.</p><p>Veja como as atividades da equipe se dividem:</p><p>Segunda-feira: Recrutamento e planejamento</p><p>Decidam, em equipe, o que será testado esta semana. Decida quem você</p><p>precisa recrutar para os testes e inicie o processo de recrutamento. Terceirize</p><p>este trabalho, se possível; é muito demorado.</p><p>Terça-feira: Refinando os componentes do teste</p><p>Com base no estágio em que seu MVP se encontra, comece a refinar o design, o</p><p>protótipo ou o produto até um ponto que lhe permitirá contar pelo menos uma</p><p>história completa quando seus clientes a virem.</p><p>Quarta-feira: Continue refinando, escrevendo o roteiro e finalizando o</p><p>recrutamento</p><p>Dê os retoques finais em seu MVP. Escreva o roteiro do teste que seu</p><p>moderador seguirá com cada participante. (Seu moderador deve ser</p><p>alguém da equipe, se possível.) Finalize o recrutamento e agende os</p><p>testes de quinta-feira.</p><p>FEEDBACK E PESQUISA 77</p><p>www.it-ebooks.info</p><p>Quinta-feira: Teste!</p><p>Passe a manhã testando seu MVP com os clientes. Não gaste mais do que</p><p>uma hora com cada cliente. Todos na equipe devem fazer anotações. A</p><p>equipe deve planejar assistir em um local separado. Revise as descobertas</p><p>com toda a equipe do projeto imediatamente após a conclusão do último</p><p>participante.</p><p>Sexta-feira: Planejamento</p><p>Use seu novo insight para decidir se suas hipóteses foram validadas</p><p>e o que você precisa fazer a seguir.</p><p>Simplifique seu ambiente de teste</p><p>Muitas empresas estabeleceram laboratórios de usabilidade internamente; costumava ser que</p><p>você precisava de um. Hoje em dia, você não precisa de um laboratório – tudo que você precisa é</p><p>de um local tranquilo em seu escritório e de um computador com conexão de rede e uma webcam.</p><p>Uma ferramenta especializada que recomendo é um software de gravação e transmissão de</p><p>desktop, como Morae, Silverback ou GoToMeeting.</p><p>O software de transmissão é um elemento chave. Ele permite que você leve as sessões</p><p>de teste para membros da equipe e partes interessadas que não podem estar</p><p>presentes. Este método tem um enorme impacto na colaboração porque espalha a</p><p>compreensão dos seus clientes profundamente na sua organização. É difícil exagerar</p><p>o quão poderosa é essa abordagem.</p><p>Quem deve assistir?</p><p>A resposta curta é: toda a sua equipe. Como quase todos os outros aspectos do Lean</p><p>UX, o teste de usabilidade deve ser uma atividade em grupo. Com toda a equipe</p><p>observando os testes, absorvendo o feedback e reagindo em tempo real, você</p><p>precisará de menos interrogatórios subsequentes. A equipe aprenderá em primeira</p><p>mão onde seus esforços estão dando certo e falhando. Nada é mais humilhante (e</p><p>motivador) do que ver um usuário lutando com o software que você acabou de criar.</p><p>Uma palavra sobre o recrutamento de participantes</p><p>Recrutar, agendar e confirmar participantes exige muito tempo. Evite essa</p><p>sobrecarga adicional transferindo o trabalho para um recrutador</p><p>terceirizado. O recrutador faz o trabalho e é pago por cada participante que</p><p>traz. Além disso, o recrutador cuida da triagem, agendamento e substituição</p><p>de não comparecimentos no dia do teste. Esses recrutadores podem custar</p><p>entre US$ 75 e US$ 150 por participante recrutado.</p><p>78 Capítulo 6</p><p>www.it-ebooks.info</p><p>Estudo de caso: três usuários todas as quintas-feiras no Meetup</p><p>Uma empresa que elevou o conceito de “três usuários todas as quintas-feiras” a</p><p>um novo nível é a Meetup. Com sede em Nova York e sob a orientação do vice-</p><p>presidente de Produto, Estratégia e Comunidade Andres Glusman, o Meetup</p><p>começou com o desejo de testar cada um de seus novos recursos e produtos.</p><p>Depois de avaliar algumas opções terceirizadas, eles decidiram manter as coisas</p><p>internamente e adotar uma abordagem iterativa na busca pelo que chamaram de</p><p>“processo minimamente viável”. Inicialmente, tentaram testar com o usuário,</p><p>moderador e equipe, todos na mesma sala. Eles obtiveram alguns resultados decentes</p><p>com essa abordagem – e havia muito o que aprender com essa técnica, inclusive que</p><p>ela pode ser ampliada – mas descobriram que os participantes do teste ficariam um</p><p>pouco assustados com tantas pessoas na sala.</p><p>Com o tempo, eles evoluíram para a realização dos testes em uma sala, com apenas o</p><p>moderador se juntando ao usuário. O restante da equipe assistia ao vídeo em uma sala de</p><p>conferência separada (o Meetup originalmente usava o Morae para compartilhar o vídeo;</p><p>hoje eles estão usando o GoToMeeting).</p><p>O Meetup não escreve scripts de teste porque não tem certeza do que será testado a</p><p>cada dia. Em vez disso, os gerentes de produto interagem com os moderadores de</p><p>teste, usando</p><p>mensagens instantâneas para ajudar a orientar as conversas com os</p><p>usuários. A equipe se informa imediatamente após a conclusão dos testes e pode</p><p>avançar rapidamente.</p><p>Meetup recrutado diretamente da comunidade Meetup desde o primeiro dia. Para</p><p>participantes fora de sua comunidade, a equipe utilizou um recrutador terceirizado.</p><p>No final das contas, eles decidiram trazer essa responsabilidade internamente,</p><p>atribuindo o trabalho ao pesquisador dedicado que contrataram para lidar com todos</p><p>os testes.</p><p>A equipe passou de três usuários uma vez por semana para testes todos os dias,</p><p>exceto às segundas-feiras. Seu principal objetivo era minimizar o tempo entre o</p><p>conceito e o feedback do cliente.</p><p>A orientação prática do processo mínimo viável do Meetup também pode ser vista em sua</p><p>abordagem aos testes móveis. À medida que o número de uso de dispositivos móveis crescia, a</p><p>Meetup não queria atrasar os testes em plataformas móveis enquanto esperava por</p><p>equipamentos de teste móveis sofisticados. Em vez disso, eles construíram os seus próprios – por</p><p>US$ 28 (veja a Figura 6-3).</p><p>FEEDBACK E PESQUISA 79</p><p>www.it-ebooks.info</p><p>Figura 6-3.Plataforma de testes de usabilidade móvel do Meetup.</p><p>A partir de 2012, o Meetup escalou com sucesso seu processo de teste de usabilidade</p><p>mínimo viável para um programa impressionante. Eles realizam aproximadamente</p><p>600 sessões de teste por ano a um custo total de cerca de US$ 30.000 (sem incluir</p><p>custos de pessoal). Este custo inclui 100% de cobertura de vídeo e notas para cada</p><p>sessão. Quando você considera que isso equivale aproximadamente ao custo de</p><p>execução de um grande estudo de usabilidade terceirizado, essa conquista é</p><p>realmente incrível.</p><p>80 Capítulo 6</p><p>www.it-ebooks.info</p><p>Entendendo a pesquisa – uma atividade em equipe</p><p>Quer sua equipe faça trabalho de campo ou de laboratório, a pesquisa gera muitos dados</p><p>brutos. Compreender estes dados pode ser demorado e frustrante, por isso o processo é</p><p>muitas vezes entregue a especialistas que são solicitados a sintetizar os resultados da</p><p>investigação. Você não deveria fazer as coisas dessa maneira. Em vez disso, trabalhe o</p><p>máximo que puder para entender os dados em equipe.</p><p>Assim que possível após o término das sessões de pesquisa – de preferência no</p><p>mesmo dia ou pelo menos no dia seguinte – reúna a equipe para uma sessão de</p><p>revisão. Quando a equipe estiver reunida, peça a todos que leiam suas descobertas</p><p>uns para os outros. Uma maneira eficiente de fazer isso é transcrever as notas que as</p><p>pessoas lêem em voz alta em fichas ou post-its e, em seguida, classificar as notas por</p><p>temas. Esse processo de leitura, agrupamento e discussão coloca a opinião de todos</p><p>na mesa e constrói o entendimento compartilhado que você busca. Com os temas</p><p>identificados, você e sua equipe podem determinar as próximas etapas do seu MVP.</p><p>Confusão, contradição e (falta de) clareza</p><p>À medida que você e sua equipe coletam feedback de diversas fontes e tentam</p><p>sintetizar suas descobertas, inevitavelmente se depararão com situações em que</p><p>seus dados apresentarão contradições. Como você entende tudo isso? Aqui estão</p><p>algumas maneiras de manter seu ímpeto e garantir que você está maximizando</p><p>seu aprendizado:</p><p>Procure padrões</p><p>Ao revisar a pesquisa, fique atento aos padrões nos dados. Esses padrões revelam</p><p>múltiplas instâncias da opinião do usuário que representam elementos a serem</p><p>explorados. Se algo não se enquadrar em um padrão, provavelmente é um valor</p><p>atípico.</p><p>Estacione seus valores discrepantes</p><p>Por mais tentador que seja ignorar valores discrepantes (ou tentar atendê-los em sua</p><p>solução), não faça isso. Em vez disso, crie um estacionamento ou pendências para eles. À</p><p>medida que sua pesquisa avança ao longo do tempo (lembre-se, você faz isso toda</p><p>semana), você poderá descobrir outros valores discrepantes que correspondam ao padrão.</p><p>Ser paciente.</p><p>Verifique com outras fontes</p><p>Se você não está convencido de que o feedback que recebe por meio de um</p><p>canal é válido, procure-o em outros canais. Os e-mails de suporte ao cliente</p><p>refletem as mesmas preocupações dos seus estudos de usabilidade?</p><p>O valor do seu protótipo é ecoado pelos clientes dentro e fora do seu</p><p>escritório? Caso contrário, sua amostra pode ter sido desproporcionalmente</p><p>distorcida.</p><p>FEEDBACK E PESQUISA 81</p><p>www.it-ebooks.info</p><p>Traduzido do Inglês para o Português - www.onlinedoctranslator.com</p><p>https://www.onlinedoctranslator.com/pt/?utm_source=onlinedoctranslator&utm_medium=pdf&utm_campaign=attribution</p><p>Identificando padrões ao longo do tempo</p><p>A maioria dos programas de pesquisa UX são estruturados para obter uma resposta conclusiva.</p><p>Normalmente, você planejará fazer pesquisas suficientes para responder definitivamente a uma</p><p>pergunta ou conjunto de perguntas. A pesquisa Lean UX prioriza a continuidade, o que significa</p><p>que você está estruturando suas atividades de pesquisa de maneira muito diferente. Em vez de</p><p>realizar grandes estudos, você verá um pequeno número de usuários todas as semanas. Portanto,</p><p>algumas questões podem permanecer em aberto durante algumas semanas. Outro resultado é</p><p>que padrões interessantes podem revelar-se ao longo do tempo.</p><p>Por exemplo, as nossas sessões regulares de testes no TheLadders revelaram uma</p><p>mudança interessante nas atitudes dos nossos clientes ao longo do tempo. Em 2008,</p><p>quando começámos a reunir-nos regularmente com candidatos a emprego, discutíamos</p><p>várias formas de comunicar com os empregadores. Uma das opções que propusemos foi o</p><p>SMS. Como o nosso público era normalmente composto por pessoas com rendimentos</p><p>elevados, entre os quarenta e os cinquenta e poucos anos, as suas primeiras respostas</p><p>mostraram um forte desdém pelo SMS como método de comunicação legítimo. Para eles,</p><p>era algo que os filhos faziam (e talvez fizessem com os filhos), mas certamente não era uma</p><p>forma “adequada” de conduzir a procura de emprego.</p><p>Em 2011, porém, as mensagens SMS decolaram nos Estados Unidos. À medida que as mensagens</p><p>de texto ganharam aceitação na cultura empresarial, esta atitude começou a abrandar. Semana</p><p>após semana, enquanto nos reunimos com os candidatos a emprego, começamos a ver essas</p><p>opiniões mudarem. Vimos que os candidatos a emprego se tornaram muito mais propensos a usar</p><p>SMS na procura de emprego no meio da carreira do que teriam feito apenas alguns anos antes.</p><p>Nunca teríamos reconhecido isso como uma tendência que abrange todo o público se não</p><p>estivéssemos falando com uma amostra desse público semana após semana. Como parte</p><p>de nossa interação regular com os clientes, sempre fizemos um conjunto regular de</p><p>perguntas de definição de nível para capturar os “sinais vitais” da procura do candidato,</p><p>independentemente de outras perguntas, recursos ou produtos que estivéssemos testando.</p><p>Curiosamente, estas descobertas não teriam influenciado as nossas crenças sobre o nosso</p><p>público-alvo. Agregados ao longo do tempo, eles se tornaram muito poderosos e moldaram</p><p>nossas futuras discussões e considerações sobre produtos.</p><p>testar tudo</p><p>Para manter uma cadência regular de testes de usuários, sua equipe deve adotar</p><p>uma política de “testar tudo”. O que estiver pronto no dia do teste é o que</p><p>aparece na frente dos usuários. Esta política libera sua equipe da pressa em</p><p>cumprir os prazos dos dias de teste. Em vez disso, você aproveitará as sessões de</p><p>teste semanais para obter insights em cada estágio de design e</p><p>desenvolvimento. Você deve, no entanto, definir expectativas adequadamente</p><p>para o tipo de feedback que será capaz de gerar com cada tipo de artefato.</p><p>82 Capítulo 6</p><p>www.it-ebooks.info</p><p>Esboços</p><p>O feedback coletado nos esboços (Figura 6-4) ajuda a validar o valor do seu</p><p>conceito. O que vocênão vaiobter neste nível é feedback tático passo a passo</p><p>sobre o processo, insights sobre elementos de design ou até mesmo feedback</p><p>significativo sobre opções de cópia. Você não poderá aprender muito (ou nada)</p><p>sobre a usabilidade do seu conceito.</p><p>Figura 6-4.Exemplo de esboço que pode ser usado com clientes.</p><p>Wireframes estáticos</p><p>Mostrar wireframes aos participantes do teste (Figura 6-5) permite avaliar a hierarquia</p><p>de informações e o layout de sua experiência. Além disso, você receberá feedback</p><p>sobre taxonomia, navegação e arquitetura da informação.</p><p>Você receberá os primeiros comentários sobre o fluxo de trabalho, mas neste ponto os</p><p>participantes do teste estão focados principalmente nas palavras da página e nas seleções</p><p>que estão fazendo. Wireframes oferecem uma boa oportunidade para começar a testar</p><p>opções de cópia.</p><p>FEEDBACK E PESQUISA 83</p><p>www.it-ebooks.info</p><p>Figura 6-5.Exemplo de wireframe.</p><p>Mockups visuais de alta fidelidade (não clicáveis)</p><p>Passando para ativos de design visual de alta fidelidade, você recebe muito mais</p><p>feedback tático. Os participantes do teste serão capazes de responder à marca,</p><p>estética e hierarquia visual, bem como aspectos de relações figura/fundo,</p><p>agrupamento de elementos e clareza de suas frases de chamariz. Os</p><p>participantes do teste também (quase certamente) avaliarão a eficácia de sua</p><p>paleta de cores.</p><p>Os modelos não clicáveis ainda não permitem que seus clientes reajam naturalmente</p><p>ao design ou às etapas subsequentes da experiência. Em vez de perguntar a seus</p><p>clientes como eles se sentem em relação ao resultado de cada clique, você deve</p><p>perguntar o que eles esperariam e então validar essas respostas em relação à</p><p>experiência planejada.</p><p>Maquetes (clicáveis)</p><p>Um conjunto de modelos clicáveis — essencialmente um protótipo criado no Axure,</p><p>Fireworks, ProtoShare ou qualquer outra ferramenta de prototipagem viável (veja a Figura</p><p>6-6) — evita as armadilhas de mostrar telas que não se conectam entre si. Os usuários veem</p><p>os resultados reais de seus cliques. Esse tipo de maquete não permitirá avaliar as interações</p><p>com os dados (portanto, você não pode testar o desempenho da pesquisa, por exemplo),</p><p>mas ainda poderá aprender muito sobre a estrutura do seu produto.</p><p>84 Capítulo 6</p><p>www.it-ebooks.info</p><p>Figura 6-6.Exemplo de maquete clicável do Skype no Classroom. (Design feito por</p><p>muitos.)</p><p>Protótipos Codificados</p><p>O código ao vivo é a melhor experiência que você pode apresentar aos participantes do</p><p>teste. Ele replica o design, o comportamento e o fluxo de trabalho do seu produto. O</p><p>feedback é real e você pode aplicá-lo diretamente à experiência. Você pode simular uma</p><p>conexão de dados em tempo real ou realmente conectar-se a dados em tempo real; se você</p><p>projetar bem sua experiência de teste, os usuários não saberão, mas seus</p><p>FEEDBACK E PESQUISA 85</p><p>www.it-ebooks.info</p><p>as reações fornecerão uma visão direta sobre como os dados reais afetam a</p><p>experiência (Figura 6-7).</p><p>Figura 6-7.Os clientes podem fornecer feedback por meio de vários canais.</p><p>Técnicas de monitoramento para descoberta contínua e</p><p>colaborativa</p><p>Nas discussões anteriores deste capítulo, procurei maneiras de usar a</p><p>pesquisa qualitativa regularmente para avaliar suas hipóteses. Mas assim</p><p>que você lançar seu produto ou recurso, seus clientes começarão a lhe dar</p><p>feedback constante – e não apenas sobre seu produto. Eles vão falar sobre si</p><p>mesmos, sobre o mercado, sobre a concorrência. Esse insight é inestimável e</p><p>chega à sua organização de todos os cantos. Procure esses tesouros de</p><p>inteligência do cliente em sua organização e aproveite-os para impulsionar o</p><p>design e a pesquisa contínua de seus produtos.</p><p>Atendimento ao Cliente</p><p>Os agentes de suporte ao cliente conversam com mais clientes diariamente do que você</p><p>conversaria ao longo de um projeto inteiro. Existem várias maneiras de aproveitar seu</p><p>conhecimento:</p><p>86 Capítulo 6</p><p>www.it-ebooks.info</p><p>• Entre em contato com eles e pergunte o que estão ouvindo dos clientes</p><p>sobre as seções do produto em que você está trabalhando.</p><p>• Realize reuniões mensais regulares com eles para compreender as tendências.</p><p>O que os clientes adoram este mês? O que eles odeiam?</p><p>• Aproveite o profundo conhecimento deles sobre o produto para saber como eles resolveriam</p><p>os desafios nos quais sua equipe está trabalhando. Inclua-os em sessões de design e revisões</p><p>de design.</p><p>• Incorpore suas hipóteses nos roteiros de chamada — uma das maneiras mais baratas de</p><p>testar suas ideias é sugeri-las como uma solução para os clientes que ligam com uma</p><p>reclamação relevante.</p><p>Em meados dos anos 2000, dirigi a equipe de UX em uma empresa de tecnologia de</p><p>médio porte em Portland, Oregon. Uma das formas de priorizarmos o trabalho foi</p><p>verificando regularmente o pulso da base de clientes. Fizemos isso com uma reunião</p><p>mensal permanente com nossos representantes de atendimento ao cliente. Todos os</p><p>meses, eles nos forneciam as 10 principais reclamações dos clientes. Utilizamos essas</p><p>informações para concentrar nossos esforços e posteriormente medir a eficácia do</p><p>nosso trabalho. Se tentássemos resolver um destes pontos problemáticos, esta</p><p>conversa mensal dava-nos uma indicação clara de se os nossos esforços estavam a</p><p>dar frutos; se o problema não estivesse diminuindo na lista dos 10 principais, nossa</p><p>solução não funcionou.</p><p>Um benefício adicional desse esforço foi que a equipe de atendimento ao cliente percebeu</p><p>que alguém estava ouvindo seus insights e começou a nos fornecer feedback dos clientes</p><p>de forma proativa fora de nossa reunião mensal. O diálogo que se seguiu nos proporcionou</p><p>um ciclo de feedback contínuo para usar com muitas de nossas hipóteses de produto.</p><p>Pesquisas de feedback no local</p><p>Configure um mecanismo de feedback em seu produto que permita que os clientes enviem</p><p>suas opiniões regularmente. Algumas opções incluem:</p><p>• Formulários de e-mail simples</p><p>• Fóruns de suporte ao cliente</p><p>• Sites de comunidades de terceiros</p><p>Você pode redirecionar essas ferramentas para pesquisa fazendo coisas como:</p><p>• Contar quantos e-mails recebidos você recebe de uma seção</p><p>específica do site</p><p>• Participar de discussões on-line e sugerir algumas de suas hipóteses</p><p>FEEDBACK E PESQUISA 87</p><p>www.it-ebooks.info</p><p>• Solicitação de sites comunitários para participantes de testes difíceis de encontrar</p><p>Esses canais de feedback de clientes fornecem feedback do ponto de</p><p>vista de seus clientes mais ativos e engajados. Aqui estão algumas</p><p>táticas para obter outros pontos de vista:</p><p>Registros de pesquisa</p><p>Os termos de pesquisa são indicadores claros do que os clientes procuram no seu</p><p>site. Os padrões de pesquisa indicam o que estão encontrando e o que não estão</p><p>encontrando. Consultas repetidas com pequenas variações mostram o desafio do</p><p>usuário em encontrar determinadas informações.</p><p>Uma maneira de usar logs de pesquisa para validação de MVP é lançar uma página</p><p>de teste para o recurso que você está planejando. Seguir os registros de pesquisa</p><p>informará se o conteúdo de teste (ou recurso) dessa página está atendendo às</p><p>necessidades do usuário. Se eles continuarem pesquisando variações desse</p><p>conteúdo, sua experiência falhou.</p><p>Análise de uso do site</p><p>Logs de uso do site e pacotes de análise – especialmente análises de funil –</p><p>mostram como os clientes estão usando o site, onde estão parando e</p><p>como tentam manipular o produto para fazer o que precisam ou esperam</p><p>que ele faça. A compreensão desses relatórios fornece um contexto real</p><p>para as decisões que a equipe precisa tomar.</p><p>Além disso, use ferramentas analíticas para determinar o sucesso de</p><p>experimentos lançados publicamente. Como o experimento mudou o uso do</p><p>produto? Seus esforços estão alcançando o resultado que você definiu? Essas</p><p>ferramentas fornecem uma resposta imparcial.</p><p>Teste A/B</p><p>O teste A/B é uma técnica, originalmente desenvolvida por profissionais de</p><p>marketing, para avaliar qual de dois (ou mais) conceitos relativamente semelhantes</p><p>atingem um objetivo de forma mais eficaz. Quando aplicado na estrutura Lean UX, o</p><p>teste A/B se torna uma ferramenta poderosa para determinar a validade de suas</p><p>hipóteses. Aplicar testes A/B é relativamente simples, uma vez que suas hipóteses</p><p>evoluem para um código funcional.</p><p>Funciona assim: pegue a experiência proposta (sua hipótese) e publique-a para</p><p>o seu público. No</p><p>entanto, em vez de permitir que todos os clientes vejam,</p><p>libere-o apenas para um pequeno subconjunto de usuários. Em seguida, meça</p><p>seus critérios de sucesso para esse público. Compare-o com o outro grupo (sua</p><p>coorte de controle) e observe as diferenças. Sua nova ideia moveu a agulha na</p><p>direção certa? Se sim, você tem uma hipótese vencedora. Caso contrário, você</p><p>terá um público de clientes do qual recorrer e interagir diretamente para</p><p>entender por que seu comportamento permaneceu inalterado.</p><p>88 Capítulo 6</p><p>www.it-ebooks.info</p><p>Existem várias empresas que oferecem suítes de testes A/B, mas todas funcionam</p><p>basicamente da mesma maneira. O nome sugere que você só pode testar duas coisas,</p><p>mas na verdade você pode testar quantas permutações de sua experiência desejar</p><p>(isso é chamado de A/B/nteste). O truque é garantir que as mudanças que você está</p><p>fazendo sejam pequenas o suficiente para que qualquer mudança de comportamento</p><p>possa ser atribuída diretamente a elas. Se você mudar muitas coisas, qualquer</p><p>mudança comportamental não poderá ser atribuída diretamente a qualquer uma de</p><p>suas hipóteses.</p><p>As empresas que oferecem ferramentas de teste A/B incluem Unbounce para teste</p><p>de landing page, Google Content Experiments (anteriormente Site Optimizer), Adobe</p><p>Test&Target (anteriormente Omniture) e Webtrends Optimize.</p><p>Conclusão</p><p>Neste capítulo, abordei muitas maneiras de começar a validar os MVPs e os</p><p>experimentos que você construiu em torno de suas hipóteses. Analisei a</p><p>descoberta contínua e as técnicas de descoberta colaborativa. Discuti como</p><p>construir um processo enxuto de teste de usabilidade todas as semanas e</p><p>abordei o que você deve testar e o que esperar desses testes. Também procurei</p><p>maneiras de monitorar a experiência do cliente em um contexto Lean UX e</p><p>abordei o poder dos testes A/B.</p><p>Essas técnicas, usadas em conjunto com os processos descritos nos Capítulos 3 a</p><p>5, constituem o ciclo completo do processo Lean UX. Seu objetivo é percorrer</p><p>esse ciclo com a maior freqüência possível, refinando seu pensamento a cada</p><p>iteração.</p><p>Na próxima seção, deixo o processo e dou uma olhada em como o Lean UX se integra</p><p>à sua organização. Quer você seja uma startup, uma grande empresa ou uma agência</p><p>digital, abordarei todas as mudanças organizacionais que você precisará fazer para</p><p>apoiar a abordagem Lean UX. Essas ideias funcionarão na maioria dos processos</p><p>existentes, mas no Capítulo 7 abordarei especificamente como fazer o Lean UX e o</p><p>desenvolvimento ágil de software funcionarem bem juntos.</p><p>FEEDBACK E PESQUISA 89</p><p>www.it-ebooks.info</p><p>www.it-ebooks.info</p><p>SEC t I em III:</p><p>Fazendo funcionar</p><p>De 2007 a 2011, liderei a equipe de UX do TheLadders, um quadro de empregos online com</p><p>sede na cidade de Nova York. Durante minha gestão, a empresa iniciou sua transição de</p><p>Waterfall para Agile. Foi um esforço conduzido pelo desenvolvedor, mas a empresa</p><p>reconheceu que, a menos que a UX fosse incluída, a transição falharia. Coube a mim</p><p>descobrir como integraríamos o Lean UX a esse novo estilo de trabalho. Em 2007, se você</p><p>pesquisasse “Agile UX” no Google, a página de resultados estaria repleta de postagens de</p><p>blogs, artigos e estudos de caso que documentavam fracassos e frustrações. Os temas</p><p>principais pareciam ser gritos de “Ágil é uma merda!” e argumentos afirmando que “UX não</p><p>tem por que trabalhar dessa maneira”.</p><p>Implacável, continuei a procurar ideias de colaboração e integração. Me deparei com o</p><p>modelo de “sprint escalonado” de Lynne Miller e Desiree Sy – no qual a equipe de UX</p><p>trabalha em um sprint à frente dos desenvolvedores – e tentei. Embora tenha sido útil</p><p>para nos fazer pensar sobre nosso trabalho em etapas menores, não fez nada para</p><p>aumentar a colaboração entre as disciplinas ou para reduzir o esforço desperdiçado</p><p>em especificações de recursos que nunca seriam construídos.</p><p>www.it-ebooks.info</p><p>Estávamos convencidos de que havia um caminho melhor, então, como bons Agilistas,</p><p>continuamos afinando nosso processo. Depois de vários meses, senti que tínhamos atingido</p><p>o nosso ritmo. Aumentamos a colaboração, começamos a produzir menos documentos e</p><p>aumentamos nossos esforços de validação do cliente. Os gritos internos de “Agile é uma</p><p>merda” e “Eu odeio isso” também diminuíram. Eu estava me sentindo muito bem com nossa</p><p>pequena equipe.</p><p>Certa manhã de segunda-feira, entrei no escritório pronto para começar a semana e</p><p>encontrei o diagrama da Figura III-1 impresso e colocado ordenadamente em minha mesa.</p><p>Figura III-1.A equipe de UX da TheLadders expressou seus sentimentos sobre nossos esforços de</p><p>integração Agile/UX.</p><p>Acontece que as coisas não eram tão boas quanto eu pensava. Minha equipe realizou sua</p><p>própria retrospectiva (leia-se: sessão de desabafo) e produziu este diagrama como seu</p><p>“entregável” para mim. Isso me pegou um pouco de surpresa, mas conforme me aprofundei</p><p>nos detalhes do documento e discuti os principais pontos problemáticos com a equipe, as</p><p>lacunas em nosso processo tornaram-se evidentes.</p><p>www.it-ebooks.info</p><p>Observe o diagrama: se você tentou integrar Agile e UX, talvez reconheça alguns</p><p>desses problemas. A equipe sentiu que não havia tempo suficiente para fazer o</p><p>trabalho da “medalha de ouro”. Eles sentiram que seu trabalho não era de missão</p><p>crítica. Eles sentiram que não tinham tempo para iterar. A lista continua. Quando</p><p>mostro este diagrama para outras equipes que estão lutando para integrar Agile e UX,</p><p>sempre há muitos sorrisos tristes de reconhecimento.</p><p>Encontrar esse diagrama em minha mesa foi uma experiência humilhante, mas</p><p>desencadeou um diálogo e envolveu o processo de aprendizagem que está no cerne</p><p>das abordagens Agile. O diálogo nos permitiu iniciar um processo de descoberta que</p><p>resultou na colaboração multifuncional que tornou nosso processo Ágil um sucesso,</p><p>conforme descrito na Seção II.</p><p>Sobre a Seção III</p><p>Como você pode integrar o processo Lean UX em sua organização? Essa é a</p><p>pergunta que responderei na Seção III.</p><p>No Capítulo 7, “Integrando Lean UX e Agile”, pegarei as táticas discutidas na</p><p>Seção II e mostrarei exatamente como elas se encaixam em um processo Scrum</p><p>típico e como o tornam mais eficaz.</p><p>No Capítulo 8, “Fazendo mudanças organizacionais”, examinarei as mudanças</p><p>organizacionais específicas que precisam ser feitas para apoiar essa forma de trabalhar.</p><p>Não são apenas os desenvolvedores e designers de software que precisam encontrar uma</p><p>maneira de trabalhar juntos. Gerentes de produto, gerentes de projeto – em suma, todo o</p><p>seu mecanismo de desenvolvimento de produto – precisarão mudar se você quiser criar</p><p>uma organização verdadeiramente ágil.</p><p>www.it-ebooks.info</p><p>www.it-ebooks.info</p><p>Capítulo 7</p><p>Integrando Lean UX e Agile</p><p>Os métodos ágeis agora são populares. Ao mesmo tempo, graças ao enorme sucesso</p><p>de produtos como o Kindle e o iPhone, o mesmo ocorre com o design da experiência</p><p>do usuário. Mas fazer o Agile funcionar com UX sempre foi um desafio. Neste capítulo,</p><p>reviso como os métodos Lean UX podem se encaixar no sabor mais popular do Agile –</p><p>o processo Scrum – e discuto como a combinação de Lean UX e Agile pode criar uma</p><p>equipe mais produtiva e um processo mais colaborativo. Vou cobrir:</p><p>Definição de termos</p><p>Só para ter certeza de que estamos todos de acordo sobre certas palavras como</p><p>“sprint” e “story”.</p><p>Sprints escalonados</p><p>O antigo salvador da integração Agile/UX agora é apenas um trampolim para a</p><p>verdadeira coesão da equipe.</p><p>Ouvindo os ritmos do Scrum</p><p>As cadências de reunião do Scrum são guias claros para a integração</p><p>Lean UX.</p><p>Participação</p><p>Um processo verdadeiramente multifuncional exige que todos façam parte dele.</p><p>Design como esporte coletivo</p><p>Garantir que o processo de design, antes fechado, agora esteja aberto a todos os membros da</p><p>equipe é a chave para o seu sucesso.</p><p>95</p><p>www.it-ebooks.info</p><p>Gerenciando para cima e para fora</p><p>Elimine obstáculos ao progresso de sua equipe sendo proativo em sua</p><p>comunicação.</p><p>Algumas definições</p><p>Os processos ágeis, incluindo Scrum, usam muitos termos</p><p>proprietários. Com o</p><p>tempo, muitos desses termos ganharam vida própria. Para garantir que estou usando-</p><p>os com clareza, reservei um tempo para definir alguns deles aqui (se você estiver</p><p>familiarizado com Scrum, pode pular esta seção).</p><p>Scrum</p><p>Uma metodologia ágil que promove ciclos time-boxed, auto-organização</p><p>da equipe e alta responsabilidade da equipe. Scrum é a forma mais popular</p><p>de Agile.</p><p>História do usuário</p><p>A menor unidade de trabalho expressa como um benefício para o usuário final.</p><p>Histórias de usuário típicas são escritas usando a seguinte sintaxe:</p><p>Como um[tipo de usuário]</p><p>Eu quero[realizar algo]</p><p>Para que[algum benefício acontece]</p><p>Pendências</p><p>Uma lista priorizada de histórias de usuários. O backlog é a ferramenta de</p><p>gerenciamento de projetos mais poderosa do Agile. É através da preparação ativa do</p><p>backlog que a equipe gerencia sua carga de trabalho diária e reorienta seus esforços</p><p>com base no conhecimento recebido. É assim que a equipe se mantém ágil.</p><p>Corrida:</p><p>Um único ciclo de equipe. O objetivo de cada sprint é entregar software funcional. A maioria</p><p>das equipes Scrum trabalha em sprints de duas semanas.</p><p>Ficar de pé:</p><p>Uma curta reunião diária de equipe na qual cada membro aborda os desafios do</p><p>dia – uma das ferramentas de auto-responsabilidade do Scrum. Cada membro</p><p>deve declarar a todos os companheiros, todos os dias, o que está fazendo e o</p><p>que está atrapalhando.</p><p>Retrospectivo</p><p>Uma reunião no final de cada sprint que analisa honestamente o que deu</p><p>certo, o que deu errado e como a equipe tentará melhorar o processo no</p><p>próximo sprint. Seu processo é tão iterativo quanto seu</p><p>96 Capítulo 7</p><p>www.it-ebooks.info</p><p>produtos. As retrospectivas dão à sua equipe a oportunidade de otimizar seu</p><p>processo a cada sprint.</p><p>Reunião de planejamento de iteração</p><p>Uma reunião no início de cada sprint na qual a equipe planeja o</p><p>próximo sprint. Às vezes, esta reunião inclui estimativa e coleta de</p><p>histórias. Esta é a reunião que determina a priorização inicial do</p><p>backlog.</p><p>Além dos Sprints Escalonados</p><p>Em maio de 2007, Desiree Sy e Lynn Miller publicaram “Adaptando Investigações de</p><p>Usabilidade para Design Ágil Centrado no Usuário” noRevista de Estudos de</p><p>Usabilidade(http://www.upassoc.org/upa_publications/jus/2007may/agile-ucd. pdf). Sy</p><p>e Miller foram algumas das primeiras pessoas a tentar combinar Agile e UX, e muitos</p><p>de nós ficamos entusiasmados com as soluções que propuseram. No artigo, Sy e</p><p>Miller descrevem em detalhes sua ideia de uma integração produtiva entre Agile e</p><p>design centrado no usuário. Eles usam uma técnica chamada Ciclo 0 (você deve ter</p><p>ouvido falar também como “Sprint Zero” ou “Sprints Escalonados”).</p><p>Resumindo, Sy e Miller descrevem um processo no qual a atividade de design ocorre</p><p>um sprint antes do desenvolvimento (Figura 7-1). O trabalho é projetado e validado</p><p>durante o “design sprint” e depois repassado para o fluxo de desenvolvimento para</p><p>ser implementado durante o sprint de desenvolvimento.</p><p>Figura 7-1.O modelo de “sprints escalonados” de Sy e Miller.</p><p>Muitas equipes interpretaram mal esse modelo. Sy e Miller sempre defenderam uma</p><p>forte colaboração entre designers e desenvolvedores durante os sprints de design e</p><p>desenvolvimento. Muitas equipes não perceberam esse ponto crítico e, em vez disso,</p><p>criaram fluxos de trabalho nos quais designers e desenvolvedores se comunicam por</p><p>transferência, criando uma espécie de processo em mini-cascata.</p><p>Integrando LEAN UX e AGILE 97</p><p>www.it-ebooks.info</p><p>Sprints escalonados podem funcionar bem para algumas equipes. Se o seu ambiente</p><p>de desenvolvimento não permitir lançamentos frequentes (por exemplo, você trabalha</p><p>em software empacotado, ou software incorporado, ou entrega software em um</p><p>ambiente no qual a implantação contínua é difícil ou impossível), o prêmio em obter o</p><p>design correto é maior. Nesses casos, o Lean UX pode não ser uma boa opção para</p><p>sua equipe, pois você terá que trabalhar duro para obter o feedback do mercado</p><p>necessário para fazer muitas dessas técnicas funcionarem.</p><p>Para essas equipes, sprints escalonados podem permitir mais validação do trabalho de</p><p>design, desde que você ainda esteja trabalhando de maneira bastante colaborativa. E as</p><p>equipes que fazem a transição do Waterfall para o Agile também podem se beneficiar</p><p>trabalhando dessa forma, porque isso ensina você a trabalhar em ciclos mais curtos e a</p><p>dividir seu trabalho em partes sequenciais.</p><p>No entanto, este modelo funciona melhor como uma transição. Não é onde você</p><p>quer que sua equipe chegue. Eis o porquê: torna-se muito fácil criar uma situação</p><p>em que a equipe inteira nunca trabalhe na mesma coisa ao mesmo tempo. Você</p><p>nunca percebe os benefícios da colaboração multifuncional porque as diferentes</p><p>disciplinas estão focadas em coisas diferentes. Sem essa colaboração, você não</p><p>constrói um entendimento compartilhado e acaba dependendo muito de</p><p>documentação e transferências para comunicação.</p><p>Há outra razão pela qual esse processo não é o ideal: ele pode criar resíduos</p><p>desnecessários. Você perde tempo criando documentação para descrever o que</p><p>aconteceu durante os design sprints. E se os desenvolvedores não participaram do</p><p>design sprint, eles não tiveram a chance de avaliar a viabilidade ou o escopo do</p><p>trabalho. Essa conversa não acontece até a transferência. Eles poderão realmente</p><p>construir os projetos especificados nas próximas duas semanas? Caso contrário, o</p><p>trabalho necessário para projetar esses elementos será um desperdício.</p><p>Construindo Lean UX no ritmo do Scrum</p><p>Como eu disse na abertura deste capítulo, tentamos usar Staggered Sprints no</p><p>TheLadders. E quando tivemos problemas, continuamos a melhorar nosso</p><p>processo, terminando com uma rotina profundamente colaborativa que seguia</p><p>os ritmos do Scrum. Vamos dar uma olhada em como você pode usar a estrutura</p><p>de reunião do Scrum e o Lean UX para construir um processo eficiente.</p><p>temas</p><p>Scrum tem muitas reuniões. Muitas pessoas desaprovam as reuniões, mas se</p><p>você usá-las como marcos durante seu sprint, poderá criar um processo Lean UX</p><p>e Agile integrado no qual toda a equipe está trabalhando na mesma coisa ao</p><p>mesmo tempo.</p><p>98 Capítulo 7</p><p>www.it-ebooks.info</p><p>Vamos pegar um modelo de sprint de duas semanas e supor que podemos unir uma</p><p>série desses sprints sob um único guarda-chuva, que chamaremos de tema (Figura</p><p>7-2).</p><p>Figura 7-2.Sprints vinculados a um tema.</p><p>Sessões iniciais para esboços e idealização</p><p>Cada tema deve ser iniciado com uma série de exercícios de brainstorming e</p><p>validação como os descritos na Secção II. Essas atividades podem durar</p><p>apenas uma tarde ou até uma semana. Você pode fazê-los com sua equipe</p><p>imediata ou com um grupo mais amplo. O escopo do tema determinará</p><p>quanta participação e tempo essas atividades iniciais exigirão. O objetivo</p><p>desse pontapé inicial é reunir toda a equipe para esboçar e idealizar, criando</p><p>um acúmulo de ideias para testar e aprender.</p><p>Depois de iniciar seus sprints, essas ideias serão testadas, validadas e desenvolvidas,</p><p>novos conhecimentos surgirão e você precisará decidir o que fazer com eles. Você</p><p>toma essas decisões executando sessões subsequentes de brainstorming mais curtas</p><p>que ocorrem antes do início de cada novo sprint, o que permite que a equipe use os</p><p>insights mais recentes para criar o backlog para o próximo sprint. Consulte a Figura</p><p>7-3.</p><p>Figura 7-3.Tempo e escopo das sessões de esboço, idealização e brainstorming.</p><p>Reunião de planejamento de iteração</p><p>O resultado da sessão inicial deve ser levado aoreunião de planejamento de</p><p>iteração(IPM). Sua bagunça de post-its, esboços, wireframes, protótipos de papel</p><p>e quaisquer outros artefatos pode parecer inútil para observadores externos,</p><p>mas será significativa para sua equipe. Vocês criaram esses artefatos juntos e,</p><p>por isso, têm o entendimento compartilhado necessário para extrair</p><p>Integrando LEAN UX e AGILE 99</p><p>www.it-ebooks.info</p><p>histórias deles. Use-os em seu IPM (Figura 7-4) para escrever histórias de</p><p>usuários juntos e depois avaliar e priorizar</p><p>as histórias.</p><p>Figura 7-4.Realize reuniões de planejamento de iteração imediatamente após as sessões de brainstorming.</p><p>Cronograma de validação do usuário</p><p>Finalmente, para garantir um fluxo constante de opiniões dos clientes para</p><p>validação, planeje sessões de usuários todas as semanas (Figura 7-5). Sua equipe</p><p>nunca estará a mais de cinco dias úteis da validação do cliente, mas ainda assim</p><p>suas ideias terão tempo suficiente para reagir antes do final do sprint. Use os</p><p>artefatos criados nas sessões de idealização como material base para seus testes</p><p>de usuário. Lembre-se de que quando as ideias são cruas, você está testando o</p><p>valor (ou seja, as pessoas querem usar meu produto?). Depois de estabelecer o</p><p>desejo pelo seu produto, testes subsequentes com artefatos de maior fidelidade</p><p>revelarão se sua solução é utilizável.</p><p>Figura 7-5.As conversas com os usuários acontecem todas as semanas.</p><p>100 Capítulo 7</p><p>www.it-ebooks.info</p><p>Participação</p><p>Uma das grandes lições que tirei do diagrama que mostrei no início da Seção III foi</p><p>que os designers precisam de tempo para serem criativos. Ciclos de duas semanas de</p><p>desenvolvimento e design simultâneos oferecem poucas oportunidades para tempo</p><p>criativo. Alguns métodos Ágeis adotam uma abordagem de tempo mais flexível do</p><p>que o Scrum. (Por exemplo, Kanban acaba com a noção de um lote de trabalho de</p><p>duas semanas e coloca ênfase no fluxo de peça única.) Mas você ainda pode reservar</p><p>tempo dentro de um sprint Scrum no qual atividades criativas podem ocorrer.</p><p>O motivo pelo qual minha equipe de UX na TheLadders não encontrou esse tempo foi</p><p>porque não estávamos participando totalmente do processo Scrum. A culpa não foi</p><p>inteiramente nossa: o conteúdo de muitas reuniões Scrum ofereceu pouco valor aos</p><p>designers de UX. Contudo, sem a nossa participação, as nossas preocupações e</p><p>necessidades não foram tidas em conta nos planos do projeto. Como resultado, não</p><p>estávamos criando tempo nos sprints para que o trabalho criativo ocorresse – o restante da</p><p>equipe não entendia que esse tempo era necessário.</p><p>Para que o Lean UX funcione no Agile, toda a equipe deve participar de todas as</p><p>atividades – standups, retrospectivas, IPMs, sessões de brainstorming – todas elas</p><p>exigem a presença de todos para serem bem-sucedidas. Além de negociar a</p><p>complexidade de determinados recursos, a participação multifuncional permite que</p><p>designers e desenvolvedores criem uma priorização eficaz do backlog.</p><p>Por exemplo, imagine no início de um sprint que a primeira história que uma</p><p>equipe prioriza tem um forte componente de design. Imagine que o designer</p><p>não estivesse lá para expressar sua preocupação. Essa equipe irá falhar assim</p><p>que se reunir para a trocação no dia seguinte. O designer anunciará que a</p><p>história não foi projetada. E ele dirá que levará pelo menos dois ou três dias para</p><p>concluir o design antes que a história esteja pronta para desenvolvimento.</p><p>Imagine, em vez disso, que o designer tivesse participado da priorização do</p><p>backlog. Sua preocupação teria sido levantada no momento do planejamento. A</p><p>equipe poderia ter selecionado um cartão de história que precisasse de menos</p><p>preparação de design para trabalhar primeiro, o que teria proporcionado ao</p><p>designer o tempo necessário para concluir o trabalho.</p><p>A outra vítima da escassa participação é o entendimento partilhado. As equipes</p><p>tomam decisões em reuniões. Essas decisões são baseadas em discussões.</p><p>Mesmo que 90% de uma reunião não seja relevante para a sua necessidade</p><p>imediata, os 10% que são relevantes economizarão horas explicando o que</p><p>aconteceu na reunião e por que certas decisões foram tomadas.</p><p>A participação permite que você negocie o tempo necessário para realizar seu trabalho. Isso é</p><p>verdade tanto para designers de UX quanto para todos os outros membros da equipe.</p><p>Integrando LEAN UX e AGILE 101</p><p>www.it-ebooks.info</p><p>Design é um esporte de equipe: estudo de caso conhecido</p><p>Neste estudo de caso, a designer e treinadora Lane Halley detalha como ela reuniu</p><p>todos os participantes – desenvolvimento, design, marketing e partes interessadas –</p><p>para criar um jogo para tablet.</p><p>Em meu trabalho como designer de produto, utilizo práticas Lean UX em diversos</p><p>projetos. Recentemente trabalhei em produtos de entretenimento, comércio</p><p>eletrônico e mídia social para diferentes plataformas, incluindo iPad, iPhone e Web. As</p><p>equipes têm sido pequenas, variando de três a sete pessoas. A maioria dos meus</p><p>projetos também compartilham as seguintes características:</p><p>• O projeto é executado dentro de uma estrutura Ágil (foco no cliente,</p><p>entrega contínua, reunião da equipe, documentação leve, propriedade</p><p>da equipe nas decisões, rituais compartilhados como standups,</p><p>retrospectivas, etc.).</p><p>• A equipe contém pessoas com uma combinação de habilidades (desenvolvimento</p><p>front-end e back-end, experiência do usuário e arquitetura da informação, gestão</p><p>de produtos e marketing, design gráfico, copywriting).</p><p>• As pessoas da equipe geralmente atuavam em sua área de especialização/ponto</p><p>forte, mas apoiavam outras especialidades e estavam interessadas em aprender</p><p>novas habilidades.</p><p>A maioria das equipes com as quais trabalho cria produtos ou serviços inteiramente</p><p>novos. Eles não estão trabalhando dentro de uma estrutura ou estrutura de produto</p><p>existente. Em projetos “green field” como estes, tentamos simultaneamente descobrir</p><p>como este novo produto ou serviço será utilizado, como se comportará e como o</p><p>vamos construir. É um ambiente de mudanças contínuas e não há muito tempo ou</p><p>paciência para planejamento ou design inicial.</p><p>a empresa de jogos de inovação</p><p>A Innovation Games Company (TIGC) produz jogos sérios – online e presenciais – para</p><p>pesquisas de mercado. O TIGC ajuda as organizações a obter insights práticos sobre</p><p>as necessidades e preferências dos clientes para melhorar o desempenho por meio de</p><p>jogos colaborativos. Em 2010, fui convidado para ajudar a TIGC a criar um novo jogo</p><p>para o mercado consumidor.</p><p>Fiz parte da equipe que criou o Knowsy para iPad, um jogo pass-and-play cujo objetivo</p><p>é aprender o que você sabe sobre seus amigos, familiares e colegas de trabalho e, ao</p><p>mesmo tempo, testar o quão bem eles o conhecem. A pessoa que melhor conhece os</p><p>outros jogadores ganha o jogo. É um jogo rápido, divertido e verdadeiramente “social”</p><p>para até seis jogadores.</p><p>102 Capítulo 7</p><p>www.it-ebooks.info</p><p>Foi nosso primeiro aplicativo para iPad e tínhamos um prazo ambicioso: um mês</p><p>para criar o jogo e aceitá-lo na App Store. Nossa pequena equipe tinha uma</p><p>combinação de experiência no assunto e habilidades em desenvolvimento front e</p><p>back-end, bem como design visual e de interação. Também pedimos a outras</p><p>pessoas que nos ajudassem a testar o jogo em vários estágios de</p><p>desenvolvimento.</p><p>Uma visão compartilhada capacita o trabalho independente</p><p>Até que um novo produto seja codificado, é difícil para as pessoas trabalharem com a</p><p>mesma visão de produto. Você pode reconhecer a falta de visão compartilhada quando a</p><p>equipe discute quais recursos são importantes ou o que deve ser feito primeiro. Também</p><p>pode haver uma sensação geral de que a equipe não está “se movendo rápido o suficiente”</p><p>ou que está repassando os mesmos problemas continuamente.</p><p>Enquanto trabalhava no Knowsy, procurei maneiras de tornar minha prática</p><p>de UX mais colaborativa, visual, leve e iterativa. Procurei oportunidades de</p><p>trabalhar em tempo real com outras pessoas da equipe (como</p><p>desenvolvedores e o gerente de produto) e resolver as coisas o mais rápido</p><p>possível com o menor nível responsável de fidelidade.</p><p>À medida que encontramos as soluções certas e a equipe entendeu e aceitou o</p><p>conceito de design, consegui aumentar a fidelidade dos artefatos de design, confiante</p><p>de que compartilhávamos uma visão de produto (Figura 7-6).</p><p>Figura 7-6.A equipe Knowsy com a parede de artefatos atrás deles.</p><p>Integrando LEAN UX e AGILE 103</p><p>www.it-ebooks.info</p><p>Quebrando o gargalo do design</p><p>No início do projeto, conversei com o desenvolvedor front-end para</p><p>conversar sobre o</p><p>design do jogo. Criamos juntos um fluxo de jogo de alto nível no papel, passando o</p><p>marcador para frente e para trás enquanto conversávamos. Esta foi minha</p><p>oportunidade de ouvir e aprender o que ele estava pensando. Conforme esboçamos,</p><p>consegui apontar inconsistências fazendo perguntas como: “O que fazemos quando</p><p>isso acontece?” Esta abordagem teve a vantagem de mudar o diálogo de “Estou certo</p><p>e você errado” para “Como podemos resolver este problema?”</p><p>Figura 7-7.O protótipo de papel começa a tomar forma.</p><p>Depois de termos esse acordo básico, consegui criar um protótipo de papel</p><p>(Figura 7-7) do jogo com base no fluxo e testá-lo com a equipe. O efeito na equipe</p><p>foi imediato. De repente, todos “entenderam” e ficaram entusiasmados com o</p><p>que estávamos fazendo. As pessoas começaram a contribuir com ideias que se</p><p>encaixavam bem e fomos capazes de identificar em quais partes cada um</p><p>poderia trabalhar para apoiar o todo.</p><p>Quando estávamos todos na mesma página, foi mais fácil para mim me afastar um</p><p>pouco da equipe e documentar o que havíamos combinado em um protótipo clicável.</p><p>Consulte a Figura 7-8.</p><p>104 Capítulo 7</p><p>www.it-ebooks.info</p><p>Figura 7-8.Lane atualizando o protótipo e a parede do artefato em tempo real.</p><p>o resultado</p><p>A incursão de Knowsy no Lean UX foi um sucesso. Entregamos o aplicativo na loja da Apple</p><p>dentro do prazo. Fui chamado de volta mais tarde para ajudar a equipe a fazer outra</p><p>variante do produto. Para essa rodada, usei um processo semelhante. Como eu estava</p><p>trabalhando remotamente e a equipe de desenvolvimento não estava tão disponível para</p><p>colaborar, tive que fazer entregas mais pesadas. No entanto, o princípio básico de iterar o</p><p>nosso caminho para uma maior fidelidade continuou.</p><p>Além da equipe Scrum</p><p>Os check-ins da gestão são um dos maiores obstáculos para manter o ímpeto da equipe. Os</p><p>designers estão acostumados a fazer análises de design, mas, infelizmente, os check-ins não</p><p>param por aí. Proprietários de produtos, partes interessadas, CEOs e clientes querem saber</p><p>como as coisas estão indo. Todos eles querem abençoar o plano do projeto daqui para</p><p>frente. O desafio para as equipes focadas em resultados é que seus planos de projeto</p><p>dependem do que estão aprendendo. Eles são responsivos, portanto, seu plano típico</p><p>apresenta apenas pequenos lotes de trabalho por vez. No máximo, essas equipes planejam</p><p>uma ou duas iterações com antecedência. Esta percepção de “miopia” tende a não satisfazer</p><p>a maioria dos gestores de alto nível. Como então você mantém os check-ins sob controle</p><p>enquanto mantém o ritmo de seus processos Lean UX e Scrum?</p><p>Integrando LEAN UX e AGILE 105</p><p>www.it-ebooks.info</p><p>Duas palavras: comunicação proativa.</p><p>Certa vez, gerenciei uma equipe que alterou radicalmente o fluxo de trabalho de um</p><p>produto existente que tinha milhares de clientes pagantes. Ficamos tão</p><p>entusiasmados com as mudanças que fizemos que prosseguimos com o lançamento</p><p>sem alertar ninguém na organização. Uma hora depois de o novo produto ser</p><p>lançado, a vice-presidente de atendimento ao cliente estava na minha mesa, furiosa e</p><p>exigindo saber por que não foi informada sobre essa mudança. Acontece que quando</p><p>os clientes têm problemas com o produto, eles pedem ajuda. Os representantes de</p><p>call center usam scripts para solucionar problemas das necessidades dos clientes e</p><p>oferecer soluções, e eles não tinham um script para esse novo produto... porque não</p><p>sabiam que isso iria mudar.</p><p>Esta fatia saudável de torta humilde serviu como uma lição valiosa. Se você deseja que seus</p><p>stakeholders – tanto aqueles que gerenciam você quanto aqueles que dependem de você – fiquem</p><p>fora do seu caminho, certifique-se de que eles estejam cientes de seus planos. Aqui estão algumas</p><p>dicas:</p><p>• Entre em contato proativamente com os proprietários de produtos e executivos.</p><p>• Deixe eles saberem:</p><p>– Como está indo o projeto</p><p>– O que você tentou até agora e aprendeu</p><p>– O que você tentará a seguir</p><p>• Mantenha as conversas focadas em resultados (como você está se aproximando de seu</p><p>objetivo), e não em conjuntos de recursos.</p><p>• Certifique-se de que os departamentos dependentes (atendimento ao cliente, marketing, operações,</p><p>etc.) estejam cientes das mudanças futuras que podem afetar seu trabalho.</p><p>• Dê-lhes bastante tempo para atualizar seus fluxos de trabalho, se necessário.</p><p>106 Capítulo 7</p><p>www.it-ebooks.info</p><p>Conclusão</p><p>Este capítulo analisou mais de perto como o Lean UX se encaixa em um processo Scrum.</p><p>Além disso, falei sobre como a colaboração multifuncional permite que uma equipe avance</p><p>em ritmo acelerado e como lidar com os incômodos stakeholders e gerentes que sempre</p><p>querem saber o que está acontecendo. Discuti por que é fundamental que todos participem</p><p>de todas as atividades e por que o modelo de sprint escalonado é apenas um ponto de</p><p>referência no caminho para a verdadeira agilidade.</p><p>No próximo e último capítulo, daremos uma olhada nas mudanças organizacionais que</p><p>precisam ser feitas para apoiar o Lean UX. Este capítulo pode servir de guia para os</p><p>gerentes sobre o que eles precisarão fazer para preparar as equipes para o sucesso.</p><p>Integrando LEAN UX e AGILE 107</p><p>www.it-ebooks.info</p><p>www.it-ebooks.info</p><p>CAPÍTULO 8</p><p>Fazendo mudanças organizacionais</p><p>No início deste livro, discuti os princípios por trás do Lean UX. Espero que você</p><p>entenda nessa seção que Lean UX é uma mentalidade. Também discuti alguns</p><p>dos principais métodos do Lean UX, porque o Lean UX também é um processo. À</p><p>medida que trabalhei com clientes e ensinei esses métodos às equipes, ficou</p><p>claro que Lean UX também é um método de gestão. Por esse motivo, você</p><p>precisará fazer algumas mudanças em sua organização para aproveitar ao</p><p>máximo o trabalho dessa forma.</p><p>Quando treino equipes, às vezes me perguntam: “Como posso colocar esses métodos</p><p>em prática aqui?” Neste ponto, estou um pouco hesitante. Embora eu esteja confiante</p><p>de que a maioria das organizações pode resolver estes problemas, também estou</p><p>ciente de que cada organização é diferente. Encontrar a solução certa exigirá muito</p><p>trabalho próximo e colaboração com seus colegas.</p><p>Para prepará-lo para esse trabalho, usarei este capítulo para compartilhar com</p><p>você algumas das mudanças que as organizações precisam fazer para adotar o</p><p>Lean UX. Não vou lhe dizer como fazer essas mudanças. Esse é o seu trabalho.</p><p>Mas espero que esta discussão o ajude a pesquisar a paisagem para encontrar as</p><p>áreas que você irá abordar.</p><p>Neste capítulo, discutiremos as seguintes mudanças que sua organização pode</p><p>precisar fazer nessas áreas:</p><p>• Mudança de produção para resultados</p><p>• Passando de funções limitadas para capacidades colaborativas</p><p>• Adotar novas habilidades</p><p>109</p><p>www.it-ebooks.info</p><p>• Criação de equipes multifuncionais</p><p>• Criação de equipes pequenas</p><p>• Criação de espaços de trabalho abertos e colaborativos</p><p>• Não depender de heróis</p><p>• Eliminando “Grande Design Inicial”</p><p>• Colocar a velocidade em primeiro lugar e a estética em segundo</p><p>• Valorizar a resolução de problemas</p><p>• Abraçando a dívida UX</p><p>• Mudança na cultura da agência</p><p>• Trabalhar com fornecedores terceirizados</p><p>• Navegando pelos padrões de documentação</p><p>• Ser realista sobre o seu ambiente</p><p>• Gerenciando para cima e para fora</p><p>SHIFt: resultados</p><p>No Capítulo 3, discuti o papel dos resultados no Lean UX. As equipes Lean UX medem</p><p>seu sucesso não em termos de recursos concluídos, mas em termos de progresso em</p><p>direção a resultados específicos. Determinar resultados é uma atividade de liderança,</p><p>na qual muitas organizações não são boas ou nem fazem. Muitas vezes, a liderança</p><p>orienta a equipe de produto através de um roteiro de produto – um conjunto de</p><p>resultados e recursos que exigem que a equipe de produto produza</p><p>As equipes que tentam usar o Lean UX devem ser capacitadas para projetar soluções</p><p>para os problemas de negócios que lhes são atribuídos. Em outras palavras, eles</p><p>devem ter autonomia para decidir por si próprios quais recursos criarão os resultados</p><p>que suas organizações exigem.</p><p>Para fazer isso, as equipes devem mudar sua conversa</p><p>com a liderança de uma conversa baseada em recursos para uma centrada em</p><p>resultados, e essa mudança de conversação é radical. Os gerentes e proprietários de</p><p>produtos devem determinar quais métricas de negócios requerem mais atenção. Por</p><p>sua vez, eles devem conversar sobre resultados com seus gestores. Desta forma, a</p><p>mudança irá inevitavelmente atingir os níveis mais elevados da organização.</p><p>A liderança deve definir esta direção e as equipas devem exigir esta mudança da liderança.</p><p>Os gerentes precisam ser treinados novamente para dar às suas equipes liberdade para</p><p>experimentar. As conversas sobre os requisitos do produto devem então ser baseadas nos</p><p>resultados de negócios: o que estamos tentando alcançar ao construir este produto? Esta</p><p>regra também se aplica a decisões de design. Os critérios de sucesso devem</p><p>110 CAPÍTULO 8</p><p>www.it-ebooks.info</p><p>ser redefinidos e os roteiros devem ser eliminados. Em seu lugar, as equipes criam</p><p>listas de pendências de hipóteses que gostariam de testar e priorizam-nas com base</p><p>no risco, na viabilidade e no sucesso potencial.</p><p>MUDANÇA: Funções</p><p>Na maioria das empresas, o trabalho que você realiza é determinado pelo seu cargo. Esse</p><p>cargo vem com uma descrição do cargo. Muitas vezes, as pessoas nas organizações</p><p>desencorajam outras pessoas a trabalharem fora dos limites de suas descrições de trabalho</p><p>(por exemplo, “Você não é um desenvolvedor, o que você pode saber sobre JavaScript?”).</p><p>Esta abordagem é profundamente anticolaborativa e significa que toda a gama de aptidões,</p><p>talentos e competências dos trabalhadores não é utilizada.</p><p>Desencorajar a contribuição multifuncional incentiva silos organizacionais. Quanto</p><p>mais discreto for o trabalho de uma pessoa, mais fácil será recuar para os limites</p><p>seguros dessa disciplina. Como resultado, a conversa entre disciplinas diminui e a</p><p>desconfiança, as acusações e o comportamento de “cubra o traseiro” (CYA) aumentam.</p><p>Silos são a morte de equipes colaborativas.</p><p>Para que o Lean UX tenha sucesso, sua organização precisa adotar um mantra de</p><p>“competências em vez de funções”. Cada membro da equipe possui uma competência</p><p>essencial em design, desenvolvimento de software, pesquisa, etc. – e deve entregar esse</p><p>conjunto de habilidades. No entanto, ele ou ela também pode possuir competências</p><p>secundárias que fazem a equipe trabalhar com mais eficiência.</p><p>Permita que seus colegas contribuam em quaisquer disciplinas nas quais tenham</p><p>experiência e interesse. Você descobrirá que trabalhar dessa forma cria uma equipe mais</p><p>engajada, que pode concluir tarefas com mais eficiência. Você também descobrirá que isso</p><p>cria camaradagem entre cargos, à medida que pessoas de diferentes disciplinas</p><p>demonstram interesse no que seus colegas estão fazendo. Equipes que gostam de trabalhar</p><p>juntas produzem um trabalho melhor.</p><p>SHIFt: novas habilidades para designers UX</p><p>Muitas empresas contratam designers para criar wireframes, especificações e mapas</p><p>de sites. Essa contratação é feita para preencher a fase de “design” do processo</p><p>cascata. Conectar designers de interação a esses fluxos de trabalho existentes limita</p><p>sua eficácia, limitando o escopo de seu trabalho, o que tem o efeito colateral de</p><p>reforçar um modelo de equipe isolado.</p><p>O sucesso de uma equipe colaborativa exige mais. Embora as equipes ainda precisem de</p><p>habilidades básicas de UX, os designers devem adicionar a facilitação como uma de suas</p><p>competências essenciais. Esta mudança requer duas mudanças significativas na forma como</p><p>trabalhamos até agora:</p><p>FAZENDO MUDANÇAS ORGANIZACIONAIS 111</p><p>www.it-ebooks.info</p><p>Os designers devem abrir o processo de design.</p><p>A equipe – e não o indivíduo – deve ser responsável pelo design do produto. Em</p><p>vez de se esconderem atrás de um monitor durante dias seguidos, os designers</p><p>devem trazer as equipes para o processo de design, buscar sua opinião e</p><p>incorporar essa visão no design. Isso começará a quebrar silos e permitirá que</p><p>ocorra uma conversa mais multifuncional.</p><p>Os designers devem assumir um papel de liderança em sua equipe.</p><p>Seus colegas estão acostumados a criticar seu trabalho de design. O que eles não</p><p>estão acostumados a fazer é co-criar esse design com você. Sua liderança e</p><p>facilitação em atividades de brainstorming em grupo, como o Design Studio,</p><p>podem criar fóruns seguros para toda a equipe conceituar seu produto.</p><p>SHIFt: equipes multifuncionais</p><p>Para muitas equipes, a colaboração é uma atividade unidisciplinar. Os desenvolvedores</p><p>resolvem problemas com outros desenvolvedores, enquanto os designers sentam-se em</p><p>pufes, acendem as lâmpadas de lava e “ideam” com seus irmãos de gola alta preta (estou</p><p>brincando... eu adoro designers!).</p><p>As ideias nascidas de colaborações unidisciplinares são unifacetadas. Eles não</p><p>refletem a perspectiva mais ampla da equipe, que pode iluminar uma gama mais</p><p>ampla de necessidades, como as do cliente, do negócio ou da tecnologia. Pior</p><p>ainda, trabalhar desta forma exige que equipes disciplinadas expliquem seu</p><p>trabalho umas às outras. Muitas vezes, o resultado é uma forte dependência de</p><p>documentação detalhada.</p><p>Lean UX requer colaboração multifuncional. Ao criar interação entre gerentes de produto,</p><p>desenvolvedores, engenheiros de controle de qualidade, designers e profissionais de</p><p>marketing, você coloca todos na mesma página. Igualmente importante: você coloca todos</p><p>no mesmo nível. Nenhuma disciplina determina a outra. Todos estão trabalhando em</p><p>direção a um objetivo comum. Permita que seus designers participem de “reuniões de</p><p>desenvolvedores” e vice-versa. Na verdade, basta fazer reuniões de equipe.</p><p>Há muito tempo que sabemos quão importante é a colaboração multifuncional. O estudo de</p><p>Robert Dailey do final da década de 1970, “O papel das características da equipe e da tarefa</p><p>na solução colaborativa de problemas e produtividade da equipe de P&D”,1encontrou uma</p><p>ligação entre a produtividade de resolução de problemas de uma equipe e o que ele</p><p>chamou de “quatro preditores”: certeza da tarefa, interdependência de tarefas, tamanho da</p><p>equipe e coesão da equipe. Mantenha sua equipe coesa, quebrando os limites baseados na</p><p>disciplina.</p><p>1Dailey, 1978,Ciência da Gestão, vol. 24, não. 15, 1579–1588.</p><p>112 CAPÍTULO 8</p><p>www.it-ebooks.info</p><p>SHIFt: Equipes pequenas</p><p>Grupos maiores de pessoas são menos eficientes do que grupos menores. Isso faz</p><p>sentido intuitivamente. Mas isto é menos óbvio: uma equipe menor deve trabalhar em</p><p>problemas menores. Esse tamanho pequeno facilita manter a disciplina necessária</p><p>para produzir produtos mínimos viáveis. Divida suas grandes equipes no que o</p><p>fundador da Amazon.com, Jeff Bezos, chamou de “equipes de duas pizzas” (http://</p><p>www.fastcompany.com/50106/inside-mind-jeff-bezos). Se a equipe precisar de mais de</p><p>duas pizzas para fazer uma refeição, é muito grande.</p><p>MUDANÇA: Espaço de trabalho</p><p>Quebre as barreiras físicas que impedem a colaboração. Coloque suas equipes</p><p>no mesmo local e crie espaços de trabalho para elas que mantenham todos</p><p>visíveis e acessíveis. Abra espaço para sua equipe colocar seus trabalhos nas</p><p>paredes e outras superfícies de trabalho. Nada é mais eficaz do que ir até um</p><p>colega, mostrar algum trabalho, discutir, esboçar, trocar ideias, compreender as</p><p>expressões faciais e a linguagem corporal e chegar a uma resolução sobre um</p><p>tema espinhoso.</p><p>Ao posicionar pessoas, crie agrupamentos multifuncionais. Isso significa retirar</p><p>os membros da equipe do conforto do “esconderijo” de sua disciplina. É incrível</p><p>como até mesmo a parede de um cubículo pode atrapalhar a conversa entre</p><p>colegas.</p><p>Os espaços de trabalho abertos permitem que os membros da equipe se vejam e entrem</p><p>em contato facilmente quando surgirem dúvidas. Algumas equipes chegaram ao ponto de</p><p>colocar suas mesas sobre rodas para que possam se mudar para mais perto dos membros</p><p>da equipe com quem estão colaborando naquele dia específico. Aumente esses espaços</p><p>abertos com salas de descanso onde as equipes podem debater.</p><p>Quadros brancos do</p><p>tamanho de uma parede ou pintar as paredes com tinta para quadro branco proporcionam</p><p>muitos metros quadrados de espaço para discussão. Resumindo, remova os obstáculos</p><p>físicos entre os membros da sua equipe. Seus planejadores de espaço podem não gostar no</p><p>início, mas as partes interessadas agradecerão.</p><p>Se a co-localização não for uma opção, forneça às equipes as ferramentas necessárias para</p><p>se comunicarem. Isso inclui software de videoconferência (por exemplo, Skype) e quadros</p><p>inteligentes, mas também passagens aéreas para nos encontrarmos pessoalmente de vez</p><p>em quando. É incrível o que uma ou duas reuniões presenciais por ano farão com o moral</p><p>da equipe.</p><p>FAZENDO MUDANÇAS ORGANIZACIONAIS 113</p><p>www.it-ebooks.info</p><p>SHIFt: não há mais heróis</p><p>Nas equipes com as quais trabalhei até agora, não foram os</p><p>desenvolvedores que recuaram no Lean UX. Foram os designers que mais</p><p>resistiram. O maior motivo? Muitos designers querem serHeróis.</p><p>Num ambiente em que os designers criam belos resultados, eles podem adquirir uma</p><p>aura heróica. Os requisitos vão para uma extremidade da máquina de design e lindas</p><p>obras de arte saem. As pessoas “ooh” e “aah” quando o design é revelado. Os</p><p>designers têm prosperado com essas reações (tanto informais quanto formalizadas</p><p>como prêmios) há muitos anos.</p><p>Não estou sugerindo que todos esses designs sejam superficiais. Escolaridade, treinamento</p><p>formal, experiência e uma boa dose de inspiração estão presentes em todos os documentos</p><p>criados pelos designers do Photoshop - e muitas vezes os resultados são inteligentes, bem</p><p>considerados e valiosos. No entanto, esses resultados brilhantes podem levar a decisões</p><p>corporativas erradas. Eles podem influenciar o julgamento especificamente porque sua</p><p>beleza é muito persuasiva. Os prêmios são baseados na estética dos designs (e não no</p><p>resultado do trabalho), as decisões de contratação são tomadas com base na nitidez dos</p><p>wireframes e a remuneração depende das marcas associadas a cada uma das peças do</p><p>portfólio.</p><p>Os criadores desses documentos são considerados líderes inovadores e elevados ao</p><p>topo no campo do design de experiência. Mas será que um único herói do design</p><p>pode ser responsável pelo sucesso da experiência do usuário, do negócio e da equipe?</p><p>Deveria uma pessoa ser anunciada como a única razão do sucesso de uma iniciativa?</p><p>Resumindo, não!</p><p>Para que o Lean UX tenha sucesso em sua organização, todos os tipos de</p><p>colaboradores (designers e não designers) devem colaborar amplamente. Essa</p><p>mudança pode ser difícil para alguns, especialmente para designers visuais com</p><p>experiência em agências interativas. Nesses contextos, o Diretor Criativo é</p><p>intocável. No Lean UX, a única coisa intocável é a percepção do cliente.</p><p>Lean UX literalmente não tem tempo para heróis. Todo o conceito de design como</p><p>hipótese destrona imediatamente as noções de heroísmo; como designer, você deve</p><p>esperar que muitas de suas ideias falhem nos testes. Heróis não admitem o fracasso.</p><p>Mas os designers Lean UX adotam isso como parte do processo.</p><p>chega de BDUF, querido</p><p>Na comunidade Agile, às vezes você ouve pessoas falando sobre Big</p><p>Design Up Front, ou BDUF. Há anos que defendo o afastamento do</p><p>BDUF. Mas nem sempre foi assim.</p><p>114 CAPÍTULO 8</p><p>www.it-ebooks.info</p><p>No início dos anos 2000, eu era designer de interface de usuário na AOL, trabalhando em</p><p>um novo navegador. A equipe estava trabalhando para encontrar maneiras de inovar nos</p><p>conjuntos de recursos existentes do navegador. Mas eles sempre tinham que esperar para</p><p>implementar qualquer coisa até que eu criasse os modelos, as especificações e os</p><p>diagramas de fluxo apropriados que descreviam essas novas ideias.</p><p>Um desenvolvedor se cansou de esperar por mim e começou a implementar algumas</p><p>dessas ideias antes que os documentos estivessem completos. Rapaz, eu estava chateado!</p><p>Como ele poderia ter seguido em frente sem mim? Como ele poderia saber o que construir?</p><p>E se estivesse errado ou não funcionasse? Ele teria que reescrever todo o código!</p><p>Acontece que o trabalho que ele fez nos permitiu ver algumas dessas ideias muito mais</p><p>cedo do que antes. Isso nos deu uma ideia da experiência real do produto e nos permitiu</p><p>iterar rapidamente nossos designs para torná-los mais utilizáveis e viáveis. Daquele</p><p>momento em diante, relaxamos nossos requisitos de BDUF, especialmente à medida que</p><p>introduzimos recursos que exigiam animações e novos padrões de UI.</p><p>A ironia da dependência documental da equipe e a “inspiração” que ela desencadeou</p><p>naquele desenvolvedor não passou despercebida para nós. Na verdade, no final do projeto,</p><p>recebi um prêmio simulado por inspirar “criatividade não documentada” em um colega de</p><p>equipe.</p><p>Figura 8-1.Meu “prêmio” por inspirar criatividade não documentada em engenheiros.</p><p>FAZENDO MUDANÇAS ORGANIZACIONAIS 115</p><p>www.it-ebooks.info</p><p>MUDANÇA: Velocidade em primeiro lugar, Estética em segundo</p><p>Jason Fried, CEO da 37Signals, disse uma vez “Velocidade primeiro, estética</p><p>depois” (https://twitter.com/jasonfried/status/23923974217). Ele não estava</p><p>falando sobre comprometer a qualidade. Ele estava falando sobre editar suas</p><p>ideias e processos até o âmago. No Lean UX, trabalhar rapidamente significa</p><p>gerar muitos artefatos. Não perca tempo debatendo que tipo de artefato criar e</p><p>não perca tempo aprimorando-os até a perfeição. Em vez disso, use aquele que</p><p>levará menos tempo para ser criado e comunicado à sua equipe. Lembre-se de</p><p>que esses artefatos são uma parte transitória do projeto — como uma conversa.</p><p>Faça. Divulgue isso. Discutir. Ir em frente.</p><p>A estética – no sentido do design visual – é uma parte essencial de um produto acabado e</p><p>de uma experiência. O ajuste e o acabamento desses elementos contribuem</p><p>fundamentalmente para a marca, a experiência emocional e o profissionalismo. No estágio</p><p>de refinamento do design visual do processo, fazer um esforço para ficar obcecado com</p><p>essa camada de apresentação faz muito sentido. No entanto, colocar esse nível de</p><p>polimento e esforço nos artefatos do estágio inicial – wireframes, mapas de sites e</p><p>diagramas de fluxo de trabalho – é uma perda de tempo.</p><p>Ao sacrificar a perfeição dos artefatos de design intermediários, sua equipe chegará</p><p>ao mercado mais rapidamente e aprenderá mais rapidamente quais elementos de</p><p>toda a experiência (design, fluxo de trabalho, cópia, conteúdo, desempenho,</p><p>propostas de valor, etc.) estão funcionando para os usuários e quais não são. E você</p><p>estará mais disposto a mudar e retrabalhar suas ideias se tiver se esforçado menos</p><p>para apresentá-las.</p><p>SHIFt: Solução de problemas de valor</p><p>Lean UX nos faz fazer perguntas difíceis sobre como valorizamos o design.</p><p>Se você é um designer que está lendo isto, provavelmente já se fez uma pergunta que</p><p>costuma surgir quando a velocidade supera a perfeição estética:</p><p>Se meu trabalho agora é apresentar conceitos em vez de ideias acabadas, cada</p><p>ideia que produzo parece incompleta. Na verdade, sinto que estou “buscando o</p><p>bronze”. Nada que eu produzo está terminado. Nada indica o tipo de produtos</p><p>que sou capaz de projetar. Estou realizando um trabalho de medalha de bronze</p><p>– de propósito! Como posso sentir orgulho e propriedade por projetos que</p><p>simplesmente não foram feitos?</p><p>Para alguns designers, o Lean UX ameaça o que eles consideram o seu corpo coletivo</p><p>de trabalho, o seu portfólio e talvez até a sua empregabilidade futura. Essas emoções</p><p>baseiam-se naquilo que muitos gerentes de contratação valorizam até o momento:</p><p>resultados atraentes. Esboços, a “versão um” de um projeto e outros artefatos de</p><p>baixa fidelidade não são os ingredientes de um “portfólio matador”, mas tudo isso</p><p>está mudando agora.</p><p>116 CAPÍTULO 8</p><p>www.it-ebooks.info</p><p>Embora sua organização deva continuar a valorizar a estética, o polimento e a atenção aos</p><p>detalhes, a capacidade de pensar rápido e construir um entendimento compartilhado deve</p><p>ser promovida. Os designers podem demonstrar suas habilidades de resolução de</p><p>problemas ilustrando o caminho que</p><p>simbiótica éExperiência do usuário enxuta.</p><p>O que é Lean UX e como ele é diferente?</p><p>Os princípios Lean subjacentes ao Lean Startup se aplicam ao Lean UX de três maneiras. Primeiro,</p><p>eles nos ajudam a remover desperdícios do nosso processo de design UX. Afastamo-nos de</p><p>transferências altamente documentadas para um processo que cria apenas os artefatos de design</p><p>necessários para levar adiante o aprendizado da equipe. Segundo, eles nos levam a harmonizar</p><p>nosso “sistema” de designers, desenvolvedores, gerentes de produto, engenheiros de garantia de</p><p>qualidade, profissionais de marketing e outros.</p><p>XIII</p><p>www.it-ebooks.info</p><p>em uma colaboração transparente e multifuncional que traz não-designers para o nosso</p><p>processo de design. Por último, e talvez o mais importante, é a mudança de mentalidade</p><p>que ganhamos com a adoção de um modelo baseado na experimentação. Em vez de confiar</p><p>em um designer heróico para adivinhar a melhor solução a partir de um único ponto de</p><p>vista, usamos experimentação e medição rápidas para aprender rapidamente até que ponto</p><p>(ou não) nossas ideias atendem aos nossos objetivos. Em tudo isto, o papel do designer</p><p>começa a evoluir para a facilitação do design e com isso assumimos um novo conjunto de</p><p>responsabilidades.</p><p>Além do Lean Startup, o Lean UX tem outros dois fundamentos: design thinking e filosofias de</p><p>desenvolvimento Agile. O design thinking adota uma abordagem focada na solução para a</p><p>resolução de problemas, trabalhando de forma colaborativa para iterar um caminho interminável</p><p>e mutável em direção à perfeição. Ele trabalha em direção aos objetivos do produto por meio de</p><p>etapas específicas de idealização, prototipagem, implementação e aprendizado para trazer à luz a</p><p>solução apropriada. Agile redireciona o desenvolvimento de software para o valor. Ela busca</p><p>entregar software funcional aos clientes rapidamente e ajustar-se regularmente a novos</p><p>aprendizados ao longo do caminho.</p><p>O Lean UX usa essas bases para quebrar o impasse entre a velocidade do Agile e a</p><p>necessidade de design no ciclo de vida de desenvolvimento do produto. Se você tem</p><p>dificuldade para descobrir como o design UX pode funcionar em ambientes Agile, o</p><p>Lean UX pode ajudar.</p><p>O Lean UX quebra as barreiras que mantiveram os designers de software isolados das</p><p>necessidades reais do negócio, por um lado, e da implementação real, por outro. Lean</p><p>UX não apenas traz designers de software para a mesa, mas também traz nossos</p><p>parceiros de negócios e tecnologia para o quadro branco para trabalhar conosco nas</p><p>melhores soluções de forma contínua.</p><p>Certa vez, tive um grande cliente farmacêutico que contratou a agência para a qual</p><p>trabalhava para redesenhar sua plataforma de comércio eletrônico com o objetivo de</p><p>aumentar as receitas em 15%. Eu era o designer-chefe de interação de nossa equipe.</p><p>No vácuo do nosso escritório, passamos meses pesquisando o sistema atual, a cadeia</p><p>de suprimentos, os concorrentes, o público-alvo e os cenários de uso contextual.</p><p>Pesquisamos personas e montamos modelos estratégicos. Projetei uma nova</p><p>arquitetura de informações para o catálogo de produtos e criei uma experiência de</p><p>compra e checkout totalmente nova.</p><p>O projeto durou meses. Quando o trabalho foi concluído, empacotamos tudo em</p><p>um conjunto de PowerPoint. Este era um deck formidável – teria que ser,</p><p>considerando o preço de US$ 600 mil! Fomos até o escritório do cliente e</p><p>passamos um dia inteiro de oito horas analisando cada pixel e palavra daquele</p><p>deck. Quando acabou, o cliente bateu palmas (de verdade). Eles adoraram.</p><p>Ficamos aliviados. E nunca mais olhamos para aquele baralho.</p><p>XIV Prefácio</p><p>www.it-ebooks.info</p><p>Seis meses depois daquela reunião, nada havia mudado nas instalações do cliente.</p><p>Acho que eles nunca mais olharam para aquele baralho.</p><p>A moral desta história: construir uma especificação perfeita pode ser um caminho para arrecadar</p><p>honorários de consultoria de seis dígitos, mas não é uma maneira de fazer uma diferença</p><p>significativa em um produto real que é crucial para usuários reais. Também não é a razão pela qual</p><p>qualquer designer entrou no ramo de design de produtos. Entramos para construir produtos e</p><p>serviços valiosos, não para escrever especificações.</p><p>Algumas equipes com as quais trabalho hoje criam produtos ou serviços inteiramente</p><p>novos. Eles não estão trabalhando dentro de uma estrutura ou estrutura de produto</p><p>existente. Em projetos “green-field” como estes, tentamos simultaneamente descobrir</p><p>como este novo produto ou serviço será utilizado, como se comportará e como o</p><p>iremos construir. É um ambiente de mudanças contínuas e não há muito tempo ou</p><p>paciência para planejamento ou design inicial.</p><p>Outras equipes trabalham com produtos estabelecidos que foram criados com métodos</p><p>tradicionais de design e desenvolvimento. O desafio deles é diferente. Eles precisam</p><p>aproveitar as plataformas existentes e, ao mesmo tempo, aumentar a receita e o valor da</p><p>marca. Estas equipas normalmente têm mais recursos à sua disposição do que uma startup</p><p>de base, mas ainda assim têm de utilizar os seus recursos de forma eficiente para construir</p><p>produtos e serviços que os seus clientes realmente desejam.</p><p>À medida que aprendi a praticar o Lean UX, tive que superar a sensação de que</p><p>estava mostrando um trabalho “feio”, “inacabado” ou “não pronto”. Trabalhar</p><p>desta forma requer o apoio de uma equipe de alto desempenho. Você precisa</p><p>saber – como equipe – que não vai acertar na primeira vez e que todos estão</p><p>trabalhando juntos para iterar o caminho a seguir. Quero que você ganhe essa</p><p>confiança também. Nas páginas deste livro, resumi os insights e as táticas que</p><p>me permitiram criar verdadeiro sucesso para as equipes de produtos e negócios</p><p>e verdadeira satisfação para os clientes.</p><p>Para quem é o Lean UX?</p><p>Este livro é para designers de interação que sabem que podem contribuir mais e ser</p><p>mais eficazes com suas equipes. É também para gerentes de produto que precisam de</p><p>melhores maneiras de definir seus produtos com suas equipes e de validá-los com</p><p>seus clientes. É também para desenvolvedores que entendem que um ambiente de</p><p>equipe colaborativo leva a um código melhor e a um trabalho mais significativo. E,</p><p>finalmente, é para gerentes – gerentes de equipes de experiência do usuário, equipes</p><p>de projeto, linhas de negócios, departamentos e empresas – que entendem a</p><p>diferença que uma excelente experiência do usuário pode fazer.</p><p>Prefácio XV</p><p>www.it-ebooks.info</p><p>O que tem para você?</p><p>O livro está organizado em três seções.</p><p>• A Seção I fornece uma visão geral e introdução ao Lean UX e seus princípios</p><p>fundadores. Apresento as razões pelas quais a evolução do processo de</p><p>design UX é tão crítica e descrevo o que é Lean UX. Também discuto os</p><p>princípios subjacentes que você precisa entender para tornar o Lean UX um</p><p>sucesso.</p><p>• A Secção II centra-se no processo. Cada capítulo aborda uma etapa do ciclo Lean UX e</p><p>detalha claramente como executar cada etapa e por que ela é importante. Também</p><p>compartilho exemplos de como eu e outras pessoas fizemos essas coisas no passado.</p><p>• A Seção III aborda a integração das práticas Lean UX em sua organização.</p><p>Discuto o papel do Lean UX em um ambiente típico de desenvolvimento</p><p>Agile. Também discuto as mudanças organizacionais que precisam ocorrer</p><p>no nível corporativo, no nível da equipe e no nível dos colaboradores</p><p>individuais para que essas ideias realmente se consolidem.</p><p>Minha esperança é que este livro seja um alerta para os designers de experiência do</p><p>usuário que ainda aguardam a Fase II. Embora o livro esteja repleto de táticas e</p><p>técnicas para ajudar a evoluir seus processos, gostaria que você lembrasse que Lean</p><p>UX é, em sua essência, uma mentalidade.</p><p>Uma nota de Jeff</p><p>Muitas pessoas foram pacientes, solidárias e inspiradoras na redação</p><p>deste livro. Josh e eu queríamos reservar um momento para agradecê-</p><p>los.</p><p>Em primeiro lugar, gostaria de agradecer a Eric Ries por impulsionar o movimento</p><p>Lean Startup e por me incentivar a escrever este</p><p>percorreram para passar da ideia ao aprendizado</p><p>validado e à experiência. Ao fazer isso, eles demonstrarão seu profundo valor como</p><p>designers. As organizações que procuram e recompensam os solucionadores de problemas</p><p>atrairão — e serão atraídas por — esses designers.</p><p>Mudança: dívida UX</p><p>Muitas vezes acontece que as equipes que trabalham em processos ágeis não voltam</p><p>para melhorar a interface do usuário do software. Mas, como diz o ditado, “não é</p><p>iterativo se você fizer isso apenas uma vez”. As equipes precisam se comprometer com</p><p>a melhoria contínua, e isso significa não apenas refatorar o código e resolver</p><p>problemas técnicos, mas também retrabalhar e melhorar as interfaces do usuário. As</p><p>equipes devem abraçar o conceito de dívida UX e assumir o compromisso com a</p><p>melhoria contínua da experiência do usuário.</p><p>James O'Brien, designer de interação que trabalha em Londres, descreve o que aconteceu</p><p>quando sua equipe começou a monitorar a dívida de UX da mesma forma que a equipe</p><p>monitorava a dívida técnica: “O efeito foi dramático. Assim que apresentamos [o retrabalho]</p><p>como dívida, toda a oposição desapareceu. Não só não havia dúvida de que a dívida não</p><p>seria paga, mas ela foi consistentemente priorizada.”2</p><p>Para usar o conceito de dívida UX, escreva histórias para capturar uma análise da</p><p>lacuna entre onde a experiência está hoje e onde você gostaria que ela estivesse.</p><p>Adicione essas histórias ao seu backlog. Defenda-os.</p><p>SHIFt: as agências estão no negócio de entregas</p><p>Aplicar Lean UX em uma agência interativa não é um desafio fácil. A maioria das</p><p>agências é configurada de forma que dificulta a implementação do Lean UX, que se</p><p>baseia na colaboração multifuncional e no gerenciamento focado em resultados.</p><p>Afinal, o modelo básico de negócios da agência é simples: os clientes pagam pelas</p><p>entregas, não pelos resultados. Mas a cultura da agência também é um enorme</p><p>obstáculo. A cultura do design de heróis é forte em locais que elevam indivíduos a</p><p>cargos como Diretor Executivo de Criação. A colaboração interdisciplinar também</p><p>pode ser difícil em grandes agências, onde os processos e as “fases do projeto”</p><p>incentivam resultados e silos departamentais.</p><p>Talvez o obstáculo mais desafiador seja a expectativa do cliente de “jogar tudo</p><p>por cima do muro” para a agência e ver os resultados quando estiver pronto. A</p><p>colaboração entre cliente e agência, neste caso, pode ser limitada a</p><p>2 Correspondência privada</p><p>FAZENDO MUDANÇAS ORGANIZACIONAIS 117</p><p>www.it-ebooks.info</p><p>crítica desinformada e improdutiva baseada em preconceitos pessoais,</p><p>política e CYA.</p><p>Para fazer o Lean UX funcionar em uma agência, todos os envolvidos em um</p><p>projeto devem se concentrar em maximizar dois fatores: aumentar a colaboração</p><p>entre cliente e agência e trabalhar para mudar o foco dos produtos para os</p><p>resultados.</p><p>Algumas agências tentam concentrar-se nos resultados, experimentando afastar-se dos</p><p>contratos de âmbito fixo e baseados em resultados. Em vez disso, os seus compromissos</p><p>baseiam-se em simples acordos de tempo e materiais ou, mais radicalmente, em contratos</p><p>baseados em resultados. Em ambos os casos, a equipe fica livre para gastar seu tempo</p><p>iterando em direção a uma meta específica, não apenas a uma entrega. Os clientes</p><p>desistem da ilusão de controle que um contrato baseado em resultados oferece, mas</p><p>ganham a liberdade de buscar soluções significativas e de alta qualidade, definidas em</p><p>termos de resultados e não de listas de recursos.</p><p>Para aumentar a colaboração, as agências podem tentar derrubar as barreiras que as</p><p>separam de seus clientes. Os clientes podem ser envolvidos no processo mais cedo e</p><p>com mais frequência. Os check-ins podem ser construídos em torno de marcos menos</p><p>formais. E sessões de trabalho colaborativo podem ser organizadas para que tanto a</p><p>agência quanto o cliente se beneficiem de insights, feedback e colaboração adicionais</p><p>entre si.</p><p>Não são transformações fáceis – nem para a agência nem para o cliente que a</p><p>contrata – mas é o modelo sob o qual se constroem os melhores produtos.</p><p>Uma nota rápida sobre parceiros de desenvolvimento</p><p>Nos relacionamentos de agência, as equipes de desenvolvimento de software (seja na</p><p>agência, no cliente ou em uma equipe terceirizada) são frequentemente tratadas como</p><p>externas e frequentemente contratadas no final de uma fase de design. É imperativo que se</p><p>mude esta tradição: os parceiros de desenvolvimento devem participar durante a vida do</p><p>projecto – e não como observadores passivos. Em vez disso, você deve procurar que o</p><p>desenvolvimento do software comece o mais cedo possível. Novamente, você está</p><p>procurando criar uma colaboração profunda e significativa com toda a equipe do projeto – e</p><p>para fazer isso, você deve realmente trabalhar lado a lado com os desenvolvedores.</p><p>SHIFt: Trabalhando com fornecedores terceirizados</p><p>Fornecedores terceirizados de desenvolvimento de software representam um grande</p><p>desafio para os métodos Lean UX. Se uma parte do seu trabalho for terceirizada para</p><p>um fornecedor terceirizado – independentemente da localização do fornecedor – o</p><p>processo Lean UX terá maior probabilidade de falhar. A relação contratual com esses</p><p>fornecedores pode dificultar a flexibilidade que o Lean UX exige.</p><p>118 CAPÍTULO 8</p><p>www.it-ebooks.info</p><p>Ao trabalhar com fornecedores terceirizados, tente criar projetos com base em</p><p>tempo e materiais. Isso permitirá que você crie um relacionamento flexível com</p><p>seu parceiro de desenvolvimento, necessário para responder às mudanças que</p><p>fazem parte do processo Lean UX. Lembre-se de que você está construindo</p><p>software para aprender e esse aprendizado fará com que seus planos mudem.</p><p>Planeje essa mudança e estruture seus relacionamentos com fornecedores em</p><p>torno dela.</p><p>SHIFt: Padrões de Documentação</p><p>Muitas organizações têm padrões rígidos de documentação que as ajudam a</p><p>cumprir a conformidade regulatória interna e externa. Independentemente do</p><p>valor que esses documentos trazem para a equipe, a organização exige que estes</p><p>sejam elaborados de uma determinada forma e dentro de determinadas</p><p>diretrizes. A tentativa de contornar esta etapa levará inevitavelmente a</p><p>retrabalho, atrasos e insatisfação com seu desempenho no trabalho.</p><p>Essa situação ocorre exatamente quando, como disse o designer e treinador Lane</p><p>Halley, você “lidera com a conversa e segue com a documentação”. As filosofias e</p><p>conceitos básicos do Lean UX podem ser executados nesses ambientes – conversa,</p><p>resolução colaborativa de problemas, esboços, experimentação e assim por diante –</p><p>durante as primeiras partes do ciclo de vida do projeto. À medida que as hipóteses são</p><p>comprovadas e as instruções de design se solidificam, faça a transição do Lean UX</p><p>para o padrão de documentação que sua empresa exige. Use esta documentação</p><p>exatamente pelo motivo que sua empresa exige: para capturar o histórico de decisões</p><p>e informar futuras equipes que trabalharão neste produto. Não deixe que isso o</p><p>impeça de tomar as decisões corretas sobre o produto.</p><p>SHIFt: seja realista sobre o seu ambiente</p><p>A mudança é assustadora. A abordagem Lean UX traz consigo muitas mudanças. A</p><p>mudança pode ser especialmente desconcertante para gestores que já estão no cargo</p><p>há algum tempo e se sentem confortáveis em sua função atual. Alguns gestores</p><p>podem ser ameaçados por propostas para trabalhar de uma nova forma, o que</p><p>poderá resultar em consequências negativas para você. Nessas situações, tente pedir</p><p>perdão em vez de permissão. Experimente algumas ideias e prove o seu valor através</p><p>de sucessos quantificáveis. Quer você tenha economizado tempo e dinheiro no</p><p>projeto ou lançado uma atualização com mais sucesso do que nunca, essas conquistas</p><p>podem ajudar a defender seu caso. Se o seu gestor ainda não vê valor em trabalhar</p><p>desta forma e você acredita que a sua organização está progredindo num caminho de</p><p>“design cego” contínuo, talvez seja hora de considerar empregos alternativos.</p><p>FAZENDO MUDANÇAS ORGANIZACIONAIS 119</p><p>www.it-ebooks.info</p><p>SHIFt: Gerenciando</p><p>para cima e para fora</p><p>Lean UX dá às equipes muita liberdade para buscar soluções eficazes. Isso é feito</p><p>afastando-se de uma abordagem de roteiro de produto e, em vez disso, capacitando</p><p>as equipes a descobrir os recursos que elas acham que melhor atenderão ao negócio.</p><p>Mas abandonar o roteiro do produto tem um custo: remove uma ferramenta</p><p>fundamental que a empresa utiliza para coordenar a atividade das equipes. Assim,</p><p>com a liberdade de prosseguir a sua agenda vem a responsabilidade de comunicá-la.</p><p>Você deve entrar em contato constantemente com os membros de sua organização que não</p><p>estão atualmente envolvidos em seu trabalho para garantir que eles estejam cientes do que</p><p>está por vir. Esta comunicação também o alertará sobre o que os outros estão planejando e</p><p>o ajudará a coordenar. Gerentes de atendimento ao cliente, profissionais de marketing,</p><p>unidades de negócios paralelas e equipes de vendas se beneficiam ao saber o que a</p><p>organização do produto está fazendo. Ao contatá-los de forma proativa, você permite que</p><p>façam melhor seu trabalho. Em troca, eles serão muito menos resistentes às mudanças que</p><p>os designs de seus produtos estão fazendo.</p><p>Duas lições valiosas para garantir ciclos de validação mais tranquilos:</p><p>• Há sempre outros departamentos que são afetados pelo seu trabalho. Ignore-</p><p>os por sua conta e risco.</p><p>• Garantir que os clientes estejam cientes de quaisquer mudanças significativas futuras e permitir que</p><p>eles optem por não participar (pelo menos temporariamente).</p><p>Uma última palavra</p><p>No momento em que estávamos dando os retoques finais neste capítulo,</p><p>recebemos um e-mail de um colega. Às vezes pode parecer impossível mudar os</p><p>hábitos arraigados de uma organização. Fiquei muito feliz em receber este e-</p><p>mail, que extraí para vocês aqui, no qual Emily Holmes, Diretora de K12 UX da</p><p>Hobsons, descreve as mudanças que fez em sua organização:</p><p>120 CAPÍTULO 8</p><p>www.it-ebooks.info</p><p>Acho que muitas empresas lutam para descobrir a melhor maneira de</p><p>implementar essas técnicas. Inicialmente, tivemos muita resistência de</p><p>que não poderíamos fazer Lean UX porque “não somos uma startup”, mas</p><p>é claro que isso não é verdade.</p><p>Trouxemos um coach para ajudar a reforçar com a equipe nosso objetivo de</p><p>mover nosso processo de desenvolvimento em direção a uma metodologia Lean</p><p>UX (pode ajudar ter uma voz externa para reforçar o que está sendo dito</p><p>internamente) e, desde então, fizemos bons progressos. Em menos de um ano,</p><p>a estrutura da nossa equipe mudou desta:</p><p>Para isso:</p><p>FAZENDO MUDANÇAS ORGANIZACIONAIS 121</p><p>www.it-ebooks.info</p><p>122 CAPÍTULO 8</p><p>www.it-ebooks.info</p><p>Introduzi o seguinte sistema para ajudar nossas equipes a internalizar o que</p><p>precisa acontecer à medida que avançamos na fase de descoberta de um</p><p>projeto, para que não pulemos nenhuma etapa e todos possam começar a</p><p>entender por que esse processo de pensamento precisa acontecer.</p><p>Requer treinamento contínuo da minha parte, e ainda não o dominamos</p><p>completamente, mas está realmente ajudando a manter toda a equipe</p><p>sincronizada e falando a mesma língua. Isso não é pouca coisa, pois nossa equipe</p><p>inclui pessoas acostumadas com análise de negócios, especificações técnicas e</p><p>desenvolvimento em cascata. É um pouco divertido, para que as pessoas não</p><p>fiquem muito ressentidas por terem que mudar velhos hábitos. E definitivamente</p><p>nos ajuda a combater os “monstros” que tradicionalmente têm sido</p><p>problemáticos para a nossa organização.</p><p>Acredito que muitas das coisas que estão funcionando para nós poderiam ser</p><p>aplicadas a outras organizações empresariais com bastante sucesso.</p><p>Acredito nisso também e espero que as mudanças e os princípios que descrevi neste</p><p>capítulo ajudem a orientá-lo.</p><p>FAZENDO MUDANÇAS ORGANIZACIONAIS 123</p><p>www.it-ebooks.info</p><p>Conclusão</p><p>Lean UX é a evolução do design de produto. Ele combina as melhores técnicas de</p><p>design de interação com o método científico para criar produtos fáceis de usar,</p><p>bonitos e de sucesso mensurável. Ao combinar as ideias por trás do Lean Startup, do</p><p>desenvolvimento ágil de software e do design thinking, essa abordagem elimina o</p><p>inchaço e a incerteza do design do produto e o leva a um resultado objetivamente</p><p>fundamentado. Espero que as táticas, estratégias e estudos de caso deste livro</p><p>tenham sido úteis para você. Estou ansioso para continuar a conversa além do livro e</p><p>adoraria ouvir sua opinião enquanto você se propõe a construir suas equipes Lean UX.</p><p>Se você tiver sucesso e falhar, me avise. Quero tratar este livro como um instantâneo</p><p>do tempo e usar todos os seus insights para continuar buscando um melhor design,</p><p>dinâmica de equipe e sucesso. Envie-me um e-mail parajeff@jeffgothelf.com ou envie</p><p>um e-mail para Josh emjosh@joshuaseiden.com com suas histórias. Estamos ansiosos</p><p>para ouvir de você.</p><p>124 CAPÍTULO 8</p><p>www.it-ebooks.info</p><p>Índice</p><p>números B</p><p>37Sinais, 116 backlog, definido, 96</p><p>Ferramenta Balsamiq, 62</p><p>conceito de tamanho de lote, 9</p><p>BDUF (Big Design Up Front), 114–115</p><p>benchmarks, 25</p><p>Abordagem do Big Bang para guias de estilo, 42,</p><p>50</p><p>Big Design Up Front (BDUF), 114–115 em</p><p>branco, Steve, 9</p><p>debate</p><p>características, 30</p><p>no estudo de caso da GE,</p><p>43 pessoas, 29</p><p>software de transmissão, 78</p><p>Brown, Tim, 5</p><p>ciclo de feedback construir-medir-aprender, 7</p><p>planilha de suposições de negócios, 21 botão</p><p>para lugar nenhum, 69</p><p>A</p><p>Teste A/B, 65, 88 Programa</p><p>Adobe Fireworks, 64 Adobe</p><p>Test&Target, 89</p><p>estética em mudanças organizacionais, 116</p><p>exercício de mapeamento de afinidades, 52–53</p><p>agências, interativo, 117–118</p><p>Desenvolvimento ágil de software</p><p>sobre, XIV, 6</p><p>comunicação em equipes, 35</p><p>tempos de ciclo e, 3, 6</p><p>integrando Lean UX e terminologia</p><p>95–107 para 96–97</p><p>ferramentas analíticas, 88</p><p>premissas</p><p>Planilha de suposições de negócios,</p><p>21</p><p>declarando, 18–22</p><p>definido, 17</p><p>formular declarações de problemas,</p><p>19–20</p><p>priorizando, 22</p><p>teste, 22–25</p><p>Ferramenta Axure RP, 64</p><p>C</p><p>apelo à ação, 58</p><p>estudos de caso</p><p>feedback e pesquisa, 79–86 Guia de</p><p>estilo da General Electric, 43–46</p><p>Knowsy, 102–105</p><p>mudar ambiente, 119</p><p>125</p><p>www.it-ebooks.info</p><p>protótipos de wireframe clicáveis</p><p>cerca de, 84</p><p>baixa fidelidade, 61-63</p><p>média e alta fidelidade, 64-65</p><p>protótipos codificados, 65, 85</p><p>design colaborativo</p><p>cerca de, 33-35</p><p>estudo de caso em, 43–51</p><p>exemplo de, 36</p><p>para distribuição geográfica</p><p>equipes, 51-54</p><p>administrando um Design Studio, guias</p><p>de estilo 37–41, 41–42</p><p>descoberta colaborativa</p><p>cerca de, 74-76</p><p>técnicas de monitoramento para, 86–89</p><p>comunicação em equipes, 35, 106</p><p>Agricultura Apoiada pela Comunidade</p><p>(CSA) exemplo, 27</p><p>MVPs de concierge, 70</p><p>Constable, Giff, 21, 25</p><p>descoberta contínua</p><p>cerca de, 9, 76-78</p><p>técnicas de monitoramento para, 86–89</p><p>estilos de redação em guias de estilo, 48</p><p>comportamento de cobertura (CYA), 111</p><p>crítica (Design Studio), 39</p><p>equipes multifuncionais</p><p>cerca de, 7–8</p><p>mudanças organizacionais em, 112</p><p>CSA (Apoiado pela Comunidade</p><p>Agricultura) exemplo, 27</p><p>atendimento ao cliente, 86–87</p><p>Comportamento CYA (cubra sua bunda), 111</p><p>parceiros de desenvolvimento, 118</p><p>descobertas</p><p>colaborativo, 74–76, 86–89</p><p>contínuo, 76–78, 86–89 padrões</p><p>de documentação, 119 configurações</p><p>de monitor duplo, 53</p><p>E</p><p>email como MVP não protótipo, 69</p><p>Emerson, Ralph Waldo, 55</p><p>experimentação, cultura de, 11</p><p>experimentos e MVPs.VerMVPs</p><p>(Produtos Mínimos Viáveis)</p><p>externalizando trabalho, 10-11</p><p>F</p><p>falhar, permissão para, 11–12</p><p>recursos</p><p>Teste A/B, 65</p><p>botão para lugar nenhum, 69 identificando</p><p>em declarações de hipóteses,</p><p>25, 30</p><p>feedback e pesquisa</p><p>cerca de, 73-74</p><p>estudo de caso, 79-86</p><p>descoberta colaborativa, 74-76,</p><p>86–89</p><p>descoberta contínua, 76–78, 86–89</p><p>técnicas de monitoramento para, 86–89</p><p>recrutamento de participantes, 78</p><p>simplificando o ambiente de teste, 78</p><p>Feynman, Richard, 17</p><p>Ferramenta Fluid Designer,</p><p>62 Fried, Jason, 116</p><p>D</p><p>Dailey, Robert, 112</p><p>demonstrações de protótipos,</p><p>66 Design Studio</p><p>cerca de, 34, 37</p><p>geração de ideias de equipe, 41 geração</p><p>de ideias individuais, 38–39 iteração e</p><p>refinamento de ideias, 40 apresentação e</p><p>crítica, 39 definição de problemas</p><p>e</p><p>restrições,</p><p>38</p><p>fluxo do processo, 37–41</p><p>suprimentos necessários, 37-38</p><p>pensamento de design.Veja tambémcolaborativo</p><p>projeto</p><p>sobre, XIV, 5–6</p><p>reorientando o processo de design,</p><p>12–13 lotes pequenos, 9</p><p>g</p><p>Estudo de caso da General Electric, 43–46</p><p>equipes distribuídas geograficamente</p><p>exercício de mapeamento de afinidade,</p><p>52–53 colaborando com, 51–54</p><p>apresentação de configuração</p><p>para, 52 Glusman, Andres, 79</p><p>Acrônimo GOOB, 9–10</p><p>Google Ad Words, 69 experiências de</p><p>conteúdo do Google, 89 Google Docs,</p><p>51–52</p><p>projetos green-field, XV</p><p>crescimento, aprendizado, 11</p><p>126 Índice</p><p>www.it-ebooks.info</p><p>H k</p><p>protótipos codificados à mão, 65 heróis,</p><p>designers como, 114 protótipos de alta</p><p>fidelidade, 63–64, 84 Holmes, Emily, 120</p><p>Hurston, Zora Neale, 73</p><p>hipóteses</p><p>definido, 18</p><p>subhipóteses, 23–26, 30–31</p><p>formato típico para, 22–23</p><p>declarações de hipóteses</p><p>cerca de, 17</p><p>montagem de subhipóteses, 30–31</p><p>suposições em, 17, 18–22</p><p>completando, 25–29</p><p>elementos em, 17–18</p><p>características em, 25, 30</p><p>hipóteses em, 18, 22–25</p><p>resultados em, 18, 25–26</p><p>pessoas em, 25, 26–29</p><p>principais indicadores de desempenho (KPIs),</p><p>25–26</p><p>Estudo de caso conhecido, 102–105 KPIs</p><p>(indicadores-chave de desempenho),</p><p>25–26</p><p>eu</p><p>páginas de destino, 69</p><p>Método Lean Startup, XIII, 7</p><p>Lean UX</p><p>sobre, XIII–XV, 3–4</p><p>fundamentos de, 5–7</p><p>integrando o desenvolvimento ágil e,</p><p>95–107</p><p>princípios por trás, 7–12 anos</p><p>aprendendo sobre o crescimento, 11</p><p>protótipos de dados ao vivo, 65</p><p>guias de estilo ao vivo, 51</p><p>protótipos de baixa fidelidade</p><p>wireframes clicáveis, papel</p><p>61–63, 59–60EU</p><p>ideias e ideação</p><p>indivíduo gerador, 38–39</p><p>equipe geradora, 41</p><p>iteração e refinamento, 40</p><p>sessões iniciais para, 99</p><p>apresentações e críticas, 39</p><p>priorização, 58</p><p>Empresa de design IDEO, 5</p><p>IIDS (Sistema de Design de Internet Industrial</p><p>tem), 44–46</p><p>Sistema de design de Internet industrial</p><p>(IIDS), 44-46</p><p>integrando Lean UX e Agile</p><p>cerca de, 95-96</p><p>Estudo de caso conhecido, 102–105</p><p>considerações de participação, 101</p><p>metodologia Scrum e, 98–100 sprints</p><p>escalonados e, 95, 97–98</p><p>terminologia para, 96–97</p><p>elementos de design de interação com estilo</p><p>guias, 46</p><p>agências interativas, guia de</p><p>entrevista 117–118, 76</p><p>IPM (reunião de planejamento de iteração), 97,</p><p>99–100</p><p>reunião de planejamento de iteração (IPM), 97,</p><p>99–100</p><p>M</p><p>análise de revisão, 11 gerenciamentos,</p><p>120 reuniões, metodologia Scrum,</p><p>estudo de caso Meetup 98–100, 79–80</p><p>métricas e medição</p><p>benchmarks em, 25</p><p>medindo o comportamento, 58</p><p>medir o progresso, 8</p><p>Programa Microsoft PowerPoint, 62</p><p>programa Microsoft Visio, 62</p><p>protótipos de fidelidade média, 63–64</p><p>Miller, Lynn, 91, 97</p><p>Produtos Mínimos Viáveis (MVPs)</p><p>cerca de, 7, 55-56</p><p>criando, 57-65</p><p>foco de, 56-57</p><p>híbridos, 69</p><p>não protótipo, 69</p><p>protótipos, 66-69</p><p>maquetes.Vertécnicas de monitoramento de</p><p>protótipos para continuidade</p><p>descoberta colaborativa,</p><p>86-89</p><p>Índice 127</p><p>www.it-ebooks.info</p><p>MVPs (produtos mínimos viáveis)</p><p>cerca de, 7, 55-56</p><p>criando, 57-65</p><p>foco de, 56-57</p><p>híbridos, 69</p><p>não protótipo, 69</p><p>protótipos, 66-69</p><p>personalidades</p><p>cerca de, 25, 26</p><p>brainstorming, 29</p><p>protopersonas, 26–29</p><p>Petroff, Greg, 43-44</p><p>Poehler, Amy, 33</p><p>Ferramenta Pop Prototyping on Paper,</p><p>62 apresentações e críticas (Design</p><p>Estúdio), 39</p><p>visualizações de protótipos, 66</p><p>princípios do Lean UX</p><p>conceito de tamanho de lote, 9</p><p>descobertas contínuas, 9 equipes</p><p>multifuncionais, 7–8 trabalho de</p><p>externalização, 10–11 GOOB, 9–10</p><p>aprendizagem em vez de crescimento, 11</p><p>análise em vez de análise, 11 permissão para</p><p>falhar, 11–12 equipes focadas no problema, 8</p><p>progresso é igual a resultados, 8</p><p>reorientação do processo de design, 12–13</p><p>remoção de desperdícios, 8–9</p><p>compreensão compartilhada, 10</p><p>mentalidade baseada em equipe, 10</p><p>tamanhos de equipe, 8</p><p>priorizando</p><p>suposições, 22</p><p>ideias, 58</p><p>comunicação proativa, 106</p><p>definição de problemas e restrições</p><p>(Estúdio de Design), 38</p><p>equipes focadas no problema, 8</p><p>declarações de problemas</p><p>cerca de, 19</p><p>elementos de, 20</p><p>modelos de declaração de problema, 20 ciclo</p><p>de vida de desenvolvimento de produto</p><p>Método Lean Startup e, 7</p><p>Lean UX in, XIV</p><p>distribuição de software em, 3</p><p>roteiros de produtos, 120</p><p>protopersonas</p><p>cerca de, 26-27</p><p>processo de criação para, 29</p><p>formatos para desenho, 28–29</p><p>protótipos de MVPs</p><p>testes, 66</p><p>considerações de uso, 66–67</p><p>protótipos</p><p>cerca de, 59</p><p>escolhendo ferramentas para, 59</p><p>wireframe clicável, 61–65, 84</p><p>n</p><p>MVPs sem protótipo</p><p>cerca de, 68-69</p><p>tipos de, 69</p><p>ó</p><p>O'Brien, James, 117</p><p>Programa OmniGraffle, 62 pesquisas</p><p>de feedback no local, 87–89 mudanças</p><p>organizacionais</p><p>cerca de, 109-110</p><p>BDUF, 114–115</p><p>ambiente de mudança e, 119</p><p>equipes multifuncionais, 112</p><p>habilidades de designer, 111–112</p><p>parceiros de desenvolvimento, 118</p><p>padrões de documentação, 119</p><p>heróis, 114</p><p>agências interativas, 117–118</p><p>resultados, 110–111</p><p>roteiros de produtos, 120</p><p>papéis, 111</p><p>equipes pequenas, 113</p><p>velocidade e estética, 116</p><p>fornecedores terceirizados, 118–</p><p>119 dívida UX, 117</p><p>valor resolução de problemas, 116–117</p><p>espaço de trabalho, 113</p><p>equipes focadas em resultados, 105</p><p>resultados</p><p>criando, 17, 25–26</p><p>definido, 8, 18</p><p>Estudo de caso conhecido, 105 mudanças</p><p>organizacionais, 110–111 valores</p><p>discrepantes, estacionamento para, 81 resultados,</p><p>definidos, 8</p><p>P</p><p>protótipos de papel, 59–60, 104</p><p>estacionamento para outliers, 81</p><p>padrões, identificação, 81, 82</p><p>permissão para falhar, 11–12</p><p>128 Índice</p><p>www.it-ebooks.info</p><p>codificado, 65, 85</p><p>demonstrações e visualizações, 66</p><p>conteúdos determinantes de, 66 de</p><p>alta fidelidade, 63–64, 84 de baixa</p><p>fidelidade, 59–63</p><p>meia fidelidade, 63-64</p><p>artigo, 59–60, 104</p><p>considerações de uso, 50</p><p>wikis como, 41, 49</p><p>subhipóteses</p><p>montagem, 30–31</p><p>dividindo hipóteses em, 23–26</p><p>pesquisas, feedback on-line, 87–89 Sy,</p><p>Desiree, 91, 97</p><p>R t</p><p>pesquisar.Verreuniões de feedback e</p><p>retrospectivas de pesquisa, 96</p><p>Ries, Eric, XIII, 7</p><p>roteiros, produto, 120</p><p>funções, mudanças organizacionais em, 111</p><p>índice (TOC), 50 equipes.Veja</p><p>tambémdesign colaborativo</p><p>comunicação em, 35, 106</p><p>multifuncional, 7–8, 112 distribuído</p><p>geograficamente, 51–54 focado em</p><p>resultados, 105</p><p>focado no problema, 8</p><p>considerações de tamanho, 8.113</p><p>mentalidade baseada em equipe, 10</p><p>testes</p><p>A/B, 65, 88</p><p>suposições, 22–25</p><p>características, 65</p><p>protótipos, 66</p><p>simplificação do ambiente, 78</p><p>política de testar tudo, 82</p><p>usabilidade, 78, 80</p><p>A Empresa de Jogos de Inovação</p><p>(TIGC), 102</p><p>temas, sprints e, 98</p><p>fornecedores terceirizados, 118–</p><p>119 37Signals, 116</p><p>TIGC (Os Jogos de Inovação</p><p>Empresa), 102</p><p>TOC (índice), 50</p><p>S</p><p>cronogramas, validação de usuário,</p><p>metodologia 100 Scrum</p><p>construindo Lean UX em, 98–100</p><p>definido, 96</p><p>reuniões e, 98–100</p><p>participação em, 101</p><p>registros de pesquisa, 88</p><p>configurar apresentações para geograficamente</p><p>equipes distribuídas, 52</p><p>entendimento compartilhado, 10, 36 turnos,</p><p>organizacional.Verorganização</p><p>turnos nacionais</p><p>análise de uso do site, 88</p><p>Sivers, Derek, 12</p><p>desenhando</p><p>feedback coletado em 83 sessões iniciais</p><p>para 99 abordagens de gotejamento</p><p>lento para guias de estilo,</p><p>42, 50</p><p>distribuição de software, 3</p><p>velocidade e estética em organizações</p><p>turnos, 116</p><p>você</p><p>laboratórios de usabilidade, 78</p><p>testes de usabilidade, 78, 80 histórias de</p><p>usuário, definidas, 96 cronogramas de</p><p>validação de usuário, 100 dívidas de UX, 117</p><p>corrida</p><p>definido, 96</p><p>escalonado, 91, 95, 97–</p><p>98 temas e, 98–99</p><p>modelo de sprint escalonado, 95, 97–98</p><p>reuniões stand-up, 96</p><p>wireframes estáticos, guias de</p><p>estilo 83–84</p><p>cerca de, 41-42</p><p>características de sucesso, 48–50</p><p>componentes de, 46–47</p><p>criando, 42, 50</p><p>ao vivo, 51</p><p>mantendo, 42, 50</p><p>V</p><p>validação</p><p>agendamento para usuários, 100</p><p>ciclos mais suaves para, 120 solução</p><p>de problemas de valor, 116–117</p><p>fornecedores, terceiros, 118–119</p><p>verificação de dados, 81</p><p>elementos de design visual em guias de estilo,</p><p>48–49</p><p>Índice 129</p><p>www.it-ebooks.info</p><p>C</p><p>remoção de resíduos, 8–9, 55</p><p>modelo cascata, 8, 98</p><p>Webtrends Optimize, 89</p><p>wikis como guias de estilo, 41, 49</p><p>wireframes</p><p>clicável, 61–65, 84</p><p>protótipos de baixa fidelidade, 61-63</p><p>protótipos de média e alta fidelidade,</p><p>64–65</p><p>estático, 83-84</p><p>trabalho, externalização, 10–11 espaço de</p><p>trabalho em turnos organizacionais, 113</p><p>S</p><p>Sim, Cheryl, 70</p><p>130 Índice</p><p>www.it-ebooks.info</p><p>“Leitura obrigatória para empreendedores.”</p><p>- Dan HeaTH, co-autor detrocarefeito para colar</p><p>“O modelo essencial para compreender a liderança crucial</p><p>desafio do nosso tempo: iniciar e gerir o crescimento!”</p><p>— Warren Bennis, ilustre professor de negócios,</p><p>Universidade do Sul da California</p><p>“Muda a forma como pensamos sobre inovação e empreendedorismo.”</p><p>–Os tempos financeiros</p><p>@LEANSTARTUP FACEbOOk.COM/ERiCRIES</p><p>THELEANSTARTUP.COM</p><p>SAIBA MAIS SOBRE COMO O DROPbox, WEALTHFRONT E OUTRAS</p><p>STARTUPS DE SUCESSO ESTÃO CONSTRUINDO SEUS NEGÓCIOS.</p><p>www.it-ebooks.info</p><p>livro. Seu apoio veio de diversas</p><p>formas, incluindo perspectivas sobre o papel do design na Lean Startup e experiência</p><p>com o processo de redação de livros. Ele serviu como um proverbial ombro para</p><p>chorar, em mais de uma ocasião.</p><p>Em seguida, gostaria de agradecer a Mary Treseler, minha editora na O'Reilly.</p><p>Passamos muitas horas em e-mails, telefonemas e reuniões pessoais ocasionais</p><p>trabalhando em estratégias editoriais, táticas de redação e resenhas para chegar</p><p>- triunfantemente, devo acrescentar - ao livro que temos hoje. Obrigado.</p><p>Ao longo do caminho, me juntei a Matthew Rothenberg para superar o problema das</p><p>avaliações intermediárias. Sua camaradagem, humor, inteligência e orientação</p><p>editorial ajudaram a moldar a versão final do livro e acrescentaram uma humanidade</p><p>muito necessária às palavras.</p><p>XVI Prefácio</p><p>www.it-ebooks.info</p><p>Gostaria de agradecer ao meu parceiro de redação, Josh Seiden. Passamos muito</p><p>tempo trabalhando, ensinando, viajando e saindo juntos em 2012, então fazia</p><p>todo o sentido que ele se juntasse ao projeto e ajudasse a levá-lo até a linha de</p><p>chegada. O livro não seria o que é hoje sem seu estilo de edição perspicaz e duro.</p><p>Sou um escritor melhor por isso e este é um livro melhor por causa dele.</p><p>Obrigado, Josh.</p><p>Gostaria de agradecer especialmente às muitas pessoas que contribuíram com</p><p>material para o livro. No final do projeto, tínhamos mais estudos de caso e</p><p>contribuições do que podíamos usar, por isso parte do material maravilhoso que</p><p>nossos colegas compartilharam não cabia no manuscrito. Esta questão reflete</p><p>mais no nosso processo de escrita do que na qualidade da contribuição. Dito isto,</p><p>obrigado a Stuart Eccles, Ian Collingwood, Lane Halley, James O'Brien, Adam</p><p>Silver, Antoine Veliz, Anders Ramsay, Desiree Sy, Zach Larson, Emily Holmes, Greg</p><p>Petroff e Duane Bray.</p><p>Muitas das equipes com as quais trabalhei ao longo dos anos inspiraram as</p><p>ideias abordadas no livro. Aprendemos juntos e ajudamos a construir produtos</p><p>melhores juntos, bem como equipes mais felizes e produtivas. Sei que você verá</p><p>sua influência nos estudos de caso, histórias e anedotas destas páginas.</p><p>Por fim, quero agradecer o amor, a paciência e o apoio que recebi da minha</p><p>família durante os 18 meses que levei para chegar ao manuscrito final. Minha</p><p>esposa Carrie passou muitas horas trancado em meu escritório digitando no</p><p>teclado. Esse sacrifício não está perdido para mim. Minhas filhas Grace e Sophie</p><p>também observaram o pai encolhido demais na frente do laptop. Tenho certeza</p><p>de que eles estão ansiosos para me ter de volta em suas vidas. Eu amo vocês,</p><p>caras. Obrigado.</p><p>Uma nota de Josh</p><p>Neste livro, Jeff e eu descrevemos um estilo de trabalho profundamente</p><p>colaborativo. Esse é o meu estilo preferido de trabalho – sempre sinto que</p><p>aprendo mais e sou mais eficaz quando estou colaborando. Tudo o que pude</p><p>contribuir para este livro é resultado das incríveis colaborações que tive a sorte</p><p>de desfrutar em minha carreira.</p><p>Há algumas pessoas que eu gostaria de destacar, no entanto. Alan Cooper me ensinou</p><p>pela primeira vez o que significa projetar software. Trabalhando com Alan, conheci</p><p>Jeanine Harriman, que (muitos anos depois) abriu meus olhos pela primeira vez para</p><p>muitas das técnicas informais e colaborativas que descrevemos neste livro. Janice</p><p>Fraser me apresentou ao Lean Startup e me deu a oportunidade de explorar essas</p><p>técnicas na LUXr (Lean UX Residency). Lauralee Alben me deu coragem para abrir um</p><p>estúdio para perseguir essas ideias, e Giff Constable me deu um chute na bunda para</p><p>realmente abrir esse estúdio. Meus amigos em</p><p>Prefácio XVII</p><p>www.it-ebooks.info</p><p>a equipe equilibrada (http://www.balancedteam.org) tiveram uma influência profunda</p><p>em meu pensamento.</p><p>Agradecimentos especiais vão para Lane Halley, que é um dos praticantes mais</p><p>talentosos que já conheci e um amigo querido. Sempre que estou confuso, me</p><p>pergunto: “O que Lane faria?” e geralmente encontro um caminho a seguir.</p><p>Quero agradecer a Jeff por me convidar para acompanhá-lo na comercialização deste</p><p>livro. O livro está em sua voz porque esta é sua história. Também tem sido seu bebê,</p><p>sua paixão e seu fardo há muito tempo, então estou grato por ele ter aberto a porta</p><p>para eu me juntar a ele. Fico continuamente impressionado com sua capacidade de</p><p>colaborar com graça. Jeff e eu passamos muito tempo trabalhando juntos este ano e</p><p>estou muito orgulhoso dessa colaboração.</p><p>Obrigado, finalmente, a Vicky, Naomi e Amanda. Eu te amo.</p><p>De Jeff e Josh</p><p>Este livro é nossa tentativa de capturar o que sabemos sobre Lean UX neste momento. Os</p><p>métodos Lean são métodos de aprendizagem e esperamos aprender e descobrir mais à</p><p>medida que continuamos nossa jornada. À medida que você percorre esse caminho,</p><p>adoraríamos ouvir sobre sua jornada – seus sucessos, desafios e fracassos – para que</p><p>possamos continuar aprendendo por meio de nossa colaboração com você. Por favor,</p><p>mantenha contato conosco e compartilhe suas idéias. Você pode entrar em contato conosco</p><p>emjeff@jeffgothelf.com ejosh@joshuaseiden.com. Estamos ansiosos para ouvir de você.</p><p>XVIII Prefácio</p><p>www.it-ebooks.info</p><p>SEC tI em I:</p><p>Introdução</p><p>E PRINCÍPIOS</p><p>Nesta primeira seção, apresento uma introdução ao Lean UX e seus princípios</p><p>fundadores. Discuto por que a evolução do processo de design UX é tão crítica e</p><p>descrevo o que é Lean UX. Também discuto os princípios subjacentes que você precisa</p><p>entender para tornar o Lean UX um sucesso.</p><p>Capítulo 1, “Por que Lean UX?” fornece uma breve história do design UX e por que é o</p><p>momento certo para a evolução desse processo de design.</p><p>No Capítulo 2, “Princípios”, apresento uma visão detalhada dos princípios-chave que</p><p>orientam o processo Lean UX. Esses princípios oferecem uma estrutura para um</p><p>processo de design de produto mais enxuto e também fornecem diretrizes básicas de</p><p>gerenciamento para equipes de design de produto. Eles são fundamentais para o</p><p>sucesso do Lean UX e, se incorporados à sua organização, terão um impacto profundo</p><p>na sua cultura e na produtividade e no sucesso das suas equipes.</p><p>www.it-ebooks.info</p><p>www.it-ebooks.info</p><p>Capítulo 1</p><p>Por que Lean UX?</p><p>Ao trazer nossa arte para o software nas décadas de 1980 e 1990, os designers</p><p>abordaram o software da mesma forma que abordamos os materiais anteriores</p><p>com os quais trabalhamos. No design industrial, no design de impressão, no</p><p>design de moda e em qualquer área que envolva resultados físicos, a etapa de</p><p>fabricação é uma restrição crítica. Ao projetar materiais físicos, os designers</p><p>precisam descobrir o que estamos fazendo antes de iniciar a produção, porque a</p><p>produção é cara. É caro montar uma fábrica para produzir bens duráveis ou</p><p>roupas. É caro configurar uma impressora para uma tiragem.</p><p>Trabalhando com software, os designers enfrentaram novos desafios. Tivemos que</p><p>descobrir a gramática desse novo meio e, ao fazê-lo, vimos surgir novas</p><p>especialidades, como design de interação e arquitetura da informação. Mas o</p><p>processo pelo qual os designers praticavam permaneceu praticamente inalterado.</p><p>Ainda projetávamos os produtos com grande detalhe e antecedência, porque ainda</p><p>tínhamos que lidar com um processo de “fabricação”: nosso trabalho tinha que ser</p><p>duplicado em disquetes e CDs, que eram então distribuídos ao mercado exatamente</p><p>da mesma forma que os produtos físicos eram. distribuído. O custo de errar</p><p>permaneceu alto.</p><p>Hoje, enfrentamos uma nova realidade. A Internet mudou a distribuição de software de</p><p>forma radical. A maior parte do software agora é distribuída online. Não estamos mais</p><p>limitados por um processo de fabricação física e estamos livres para trabalhar em ciclos de</p><p>lançamento muito mais curtos.</p><p>Mas “grátis” realmente subestima esta nova realidade. As equipes agora enfrentam</p><p>intensa pressão de concorrentes que usam técnicas como desenvolvimento ágil de</p><p>software, integração contínua e implantação contínua para</p><p>3</p><p>www.it-ebooks.info</p><p>reduzir radicalmente seus tempos de ciclo. As equipes estão enviando novos códigos</p><p>para</p><p>produção tão rápido quanto você pode salvar um arquivo do Photoshop. E estão a utilizar estes</p><p>ciclos curtos como uma vantagem competitiva – lançando antecipadamente e com frequência,</p><p>obtendo feedback do mercado e iterando com base no que aprendem – e (talvez</p><p>inadvertidamente) aumentando as expectativas dos clientes em termos de qualidade e tempos de</p><p>resposta.</p><p>Nesta nova realidade, as abordagens tradicionais de “resolver tudo primeiro” não são</p><p>viáveis. Então, o que os designers devem fazer?</p><p>É hora de mudar.Experiência do usuário enxuta(UX = experiência do usuário) é a evolução</p><p>do design de produto. Ele pega as melhores partes do kit de ferramentas do designer e as</p><p>recombina de uma forma que as torna relevantes para esta nova realidade.</p><p>Lean UX é profundamente colaborativo e multifuncional, porque não podemos mais</p><p>nos dar ao luxo de trabalhar isolados do resto da equipe de produto. Não podemos</p><p>continuar a pedir às nossas equipes que esperem que resolvamos tudo. Precisamos</p><p>de um envolvimento diário e contínuo com as nossas equipas se quisermos ser</p><p>eficazes. Este envolvimento contínuo permite-nos eliminar entregas pesadas em favor</p><p>de técnicas que nos permitem construircompreensão compartilhada com nossos</p><p>companheiros de equipe.</p><p>Lean UX também nos permite mudar a forma como falamos sobre design. Em vez de</p><p>falar sobre recursos e documentos, podemos falar sobre o que funciona. Nesta nova</p><p>realidade, temos mais acesso ao feedback do mercado do que nunca. Esse feedback</p><p>nos permite reformular as conversas sobre design em termos de metas comerciais</p><p>objetivas. Podemos medir o que funciona, aprender e ajustar.</p><p>Lean UX é três coisas. É mais fácil entender como uma mudança de processo para</p><p>designers. Mas é mais do que isso. É uma mentalidade que nos permite abordar nosso</p><p>trabalho de novas maneiras. É também uma forma de pensar sobre o gerenciamento de</p><p>software. Vou me aprofundar em cada um desses conceitos ao longo do livro. No próximo</p><p>capítulo, daremos uma olhada nos princípios que estabelecem as bases para o design Lean</p><p>UX.</p><p>4 Capítulo 1</p><p>www.it-ebooks.info</p><p>Capítulo 2</p><p>Princípios</p><p>No cerne do Lean UX, você encontrará um conjunto básico de princípios. Esses</p><p>princípios abrangem processo, colaboração, gerenciamento e muito mais. As equipes</p><p>guiadas por todos esses princípios tirarão o máximo proveito da abordagem Lean UX.</p><p>Comece com esses princípios para direcionar suas equipes na direção certa e</p><p>mantenha-os em mente ao começar a implementar os processos Lean UX que</p><p>descrevo mais adiante neste livro. Você inevitavelmente terá que ajustar os processos</p><p>Lean UX para adequá-los à sua organização, e os princípios explicados neste capítulo</p><p>fornecerão orientação para esse trabalho.</p><p>Em última análise, se você conseguir colocar esses princípios em prática, descobrirá</p><p>que mudará a cultura da sua organização. Alguns terão mais impacto do que outros e</p><p>serão mais difíceis de implementar. Outros serão mais fáceis de agir.</p><p>Independentemente disso, cada princípio detalhado aqui o ajudará a construir uma</p><p>organização de design de produto que seja mais colaborativa, mais multifuncional e</p><p>mais útil para a realidade atual.</p><p>os três fundamentos do Lean UX</p><p>Lean UX se baseia em três fundamentos. A primeira fundação épensamento de</p><p>design.</p><p>Tim Brown, CEO e presidente da lendária empresa de design IDEO, descreveu o design</p><p>thinking como “inovação alimentada por… observação direta do que as pessoas querem e</p><p>precisam em suas vidas e o que elas gostam ou não gostam na maneira como</p><p>determinados produtos são feitos, embalados, comercializados, vendido e apoiado…[É] uma</p><p>disciplina que usa a sensibilidade e os métodos do designer para combinar as necessidades</p><p>das pessoas com o que é tecnologicamente viável e o que</p><p>5</p><p>www.it-ebooks.info</p><p>uma estratégia de negócios viável pode se converter em valor para o cliente e oportunidade</p><p>de mercado.”1</p><p>O design thinking é importante para o Lean UX porque assume a posição explícita de</p><p>que todos os aspectos de um negócio podem ser abordados com métodos de design.</p><p>Dá aos designers permissão e precedentes para trabalhar além de seus limites típicos.</p><p>Também incentiva os não-designers a usar métodos de design para resolver os</p><p>problemas que enfrentam em suas funções. O design thinking é uma base crítica que</p><p>incentiva as equipes a colaborar entre funções e a considerar o design do produto a</p><p>partir de uma perspectiva holística.</p><p>A segunda base do Lean UX éDesenvolvimento ágil de software. Os desenvolvedores</p><p>de software usam métodos ágeis há anos para reduzir os tempos de ciclo e agregar</p><p>valor ao cliente de maneira contínua. Embora os métodos Ágeis possam representar</p><p>desafios de processo para os designers (as soluções são fornecidas na Seção III), os</p><p>valores fundamentais do Ágil estão no cerne do Lean UX. Lean UX aplica os quatro</p><p>princípios básicos do desenvolvimento ágil ao design de produtos:</p><p>1.Indivíduos e interações acima de processos e ferramentas.Para gerar as</p><p>melhores soluções rapidamente, é preciso engajar toda a equipe. As ideias</p><p>devem ser trocadas livre e frequentemente. As restrições dos processos e</p><p>ferramentas de produção atuais são evitadas em favor da conversa com</p><p>colegas.</p><p>2.software que trabalha sobre uma documentação completa.Todo problema de</p><p>negócio tem infinitas soluções e cada membro da equipe terá uma opinião sobre</p><p>qual é a melhor. O desafio é descobrir qual solução é mais viável. Ao construir</p><p>software funcional mais cedo, as soluções podem ser avaliadas quanto à</p><p>adequação e viabilidade do mercado.</p><p>3.Colaboração do cliente na negociação de contratos.Colaborar com seus</p><p>colegas de equipe e clientes cria uma compreensão compartilhada do</p><p>espaço do problema e das soluções propostas. Cria consenso por trás das</p><p>decisões. O resultado? Iterações mais rápidas, envolvimento real na</p><p>fabricação de produtos e investimento da equipe em aprendizagem</p><p>validada. Também diminui a dependência de documentação pesada, pois</p><p>todos da equipe já participaram da tomada de decisões que antes exigiam</p><p>comunicação e defesa por escrito.</p><p>4.Responder à mudança em vez de seguir um plano.A suposição no Lean UX é que os</p><p>designs iniciais dos produtos estarão errados, então o objetivo deve ser descobrir o</p><p>que há de errado com eles o mais rápido possível. Depois de descobrirmos o que</p><p>funciona e o que não funciona, ajustamos nossas propostas e testamos novamente.</p><p>Essa contribuição do mercado nos mantém ágeis, nos empurrando constantemente na</p><p>direção “mais certa”.</p><p>1 http://hbr.org/2008/06/design-thinking/ar/1</p><p>6 Capítulo 2</p><p>www.it-ebooks.info</p><p>A terceira base do Lean UX é oMétodo de inicialização enxutafundada por Eric Ries. O</p><p>Lean Startup usa um ciclo de feedback chamado “build-measurelearn” para minimizar</p><p>o risco do projeto e fazer com que as equipes construam e aprendam rapidamente.</p><p>Construção de equipesProdutos Mínimos Viáveis(MVPs) e enviá-los rapidamente para</p><p>iniciar o processo de aprendizagem o mais cedo possível.</p><p>Como diz Eric, “Lean Startup inicialmente defende a criação de protótipos rápidos</p><p>projetados para testar suposições de mercado e usa o feedback do cliente para</p><p>desenvolvê-los muito mais rápido do que as práticas mais tradicionais de engenharia</p><p>de software… Os processos de Lean Startup reduzem o desperdício, aumentando a</p><p>frequência de contato com clientes reais. , testando e evitando suposições de mercado</p><p>incorretas o mais cedo possível.”2Lean UX é uma aplicação direta desta filosofia à</p><p>prática de design de produto.</p><p>Cada projeto é uma solução de negócios proposta – uma hipótese. Seu objetivo é</p><p>validar a solução proposta da forma mais eficiente possível usando o feedback do</p><p>cliente. A menor coisa que você pode construir para testar cada hipótese é o seu</p><p>MVP. O MVP não precisa ser feito de código; pode ser uma aproximação da</p><p>experiência final. Você coleta o que aprende com seu MVP e então desenvolve</p><p>suas ideias. Então você faz isso de novo.</p><p>A prática do Lean UX é:Lean UX é a prática de trazer à luz a verdadeira</p><p>natureza de um</p><p>produto com mais rapidez, de uma forma colaborativa e multifuncional que reduz a</p><p>ênfase na documentação completa e, ao mesmo tempo, aumenta o foco na</p><p>construção de um entendimento compartilhado da experiência real do produto que</p><p>está sendo projetado.</p><p>Princípios</p><p>No restante deste capítulo, exporei os princípios por trás do Lean UX. Ao explorar a</p><p>abordagem Lean UX, mantenha esses princípios em mente. Pense na sua experiência</p><p>com Lean UX como uma jornada de aprendizado. Use esses princípios para manter</p><p>você e sua equipe no caminho certo.</p><p>Princípio: Equipes multifuncionais</p><p>O que é?As equipes multifuncionais são formadas pelas diversas disciplinas</p><p>envolvidas na criação do seu produto. Engenharia de software, gerenciamento de</p><p>produtos, design de interação, design visual, estratégia de conteúdo, marketing e</p><p>garantia de qualidade (QA) devem ser incluídos em uma equipe Lean UX. Lean UX</p><p>exige um alto nível de colaboração entre essas disciplinas. O seu envolvimento</p><p>deve ser contínuo, desde o primeiro dia do projeto até ao final do envolvimento.</p><p>2A startup enxuta(Negócios da Coroa, 2011).</p><p>Princípios 7</p><p>www.it-ebooks.info</p><p>Por que fazê-lo?A criação dessas equipes diversas destrói o processo de transferência</p><p>fechado conhecido comocachoeira. A visão sobre cada ideia é trazida de todas as</p><p>disciplinas relevantes no início do processo. A conversa é incentivada entre silos</p><p>funcionais, o que aumenta a eficiência da equipe.</p><p>Princípio: Pequeno, Dedicado, Colocado</p><p>O que é?Mantenha suas equipes pequenas – não mais do que 10 pessoas</p><p>principais no total. Dedique-os a um projeto e equipe tudo no mesmo local.</p><p>Por que fazê-lo?O benefício das equipes pequenas se resume a três palavras:</p><p>comunicação, foco e camaradagem. Equipes menores são mais fáceis de manter</p><p>atualizadas sobre o status do projeto, mudanças e novos aprendizados. Dedicar sua</p><p>equipe a um projeto mantém todos na equipe focados nas mesmas prioridades o</p><p>tempo todo. Ter a equipe reunida em um só lugar permite que o relacionamento</p><p>entre colegas cresça.</p><p>Princípio: Progresso = resultados, não produção</p><p>O que é?Recursos e serviços sãosaídas. Os objetivos de negócios que eles pretendem</p><p>alcançar sãoresultados. Lean UX mede o progresso em termos de resultados de</p><p>negócios explicitamente definidos.</p><p>Por que fazê-lo?Quando tentamos prever quais características alcançarão resultados</p><p>específicos, estamos principalmente envolvidos em especulação. Embora seja mais</p><p>fácil gerenciar o lançamento de conjuntos de recursos específicos, não sabemos de</p><p>forma significativa se um recurso é eficaz até que esteja no mercado. Ao gerenciar os</p><p>resultados (e o progresso feito em direção a eles), obtemos insights sobre a eficácia</p><p>dos recursos que estamos construindo. Se um recurso não estiver funcionando bem,</p><p>podemos tomar uma decisão objetiva sobre se ele deve ser mantido, alterado ou</p><p>substituído.</p><p>Princípio: Equipes Focadas no Problema</p><p>O que é?Uma equipe focada no problema é aquela à qual foi atribuído um problema</p><p>de negócios para resolver, em vez de um conjunto de recursos para implementar. Esta</p><p>é a extensão lógica do foco nos resultados.</p><p>Por que fazê-lo?Atribuir problemas às equipes para resolver mostra confiança nessas</p><p>equipes. Isso permite que eles criem suas próprias soluções e gera um sentimento mais</p><p>profundo de orgulho e propriedade nas soluções que a equipe implementa.</p><p>Princípio: Removendo Resíduos</p><p>O que é?Um dos princípios fundamentais da manufatura enxuta é a</p><p>remoção de tudo que não leva ao objetivo final. Em Lean UX, o melhor</p><p>8 Capítulo 2</p><p>www.it-ebooks.info</p><p>o objetivo é melhorar os resultados; portanto, tudo o que não contribui para isso</p><p>é considerado desperdício e deve ser retirado do processo da equipe.</p><p>Por que fazê-lo?Os recursos da equipe são limitados. Quanto mais desperdício a equipe</p><p>conseguir eliminar, mais rápido ela poderá se mover. As equipes querem trabalhar nos</p><p>desafios certos. Eles querem ser eficazes. Uma disciplina de remoção de resíduos pode</p><p>ajudar as equipes a manter o foco onde ele pertence.</p><p>Princípio: tamanho de lote pequeno</p><p>O que é?Outro fundamento da manufatura enxuta é o uso de lotes pequenos. A</p><p>manufatura enxuta usa essa noção para manter o estoque baixo e a qualidade</p><p>alta. Traduzido para Lean UX, este conceito significa criar apenas o design</p><p>necessário para fazer a equipe avançar e evitar um grande “inventário” de ideias</p><p>de design não testadas e não implementadas.</p><p>Por que fazê-lo?O design de lotes grandes torna a equipe menos eficiente. Isso força a</p><p>equipe a esperar por grandes resultados de design. Isso evita que a equipe aprenda se suas</p><p>ideias são válidas. Isso mantém alguns colegas de equipe ociosos e inevitavelmente resulta</p><p>em recursos de design que não são utilizados. Essa abordagem é um desperdício e não</p><p>maximiza todo o potencial de aprendizagem da equipe.</p><p>Princípio: Descoberta Contínua</p><p>O que é?A descoberta contínua é o processo contínuo de envolvimento do cliente</p><p>durante o processo de design e desenvolvimento. Este envolvimento é feito</p><p>através de atividades programadas regularmente, utilizando métodos</p><p>quantitativos e qualitativos. O objetivo é entender o que os usuários estão</p><p>fazendo com seus produtos e por que estão fazendo isso. A pesquisa é feita em</p><p>horários frequentes e regulares. A pesquisa envolve toda a equipe.</p><p>Por que fazê-lo?Conversas regulares com os clientes oferecem oportunidades</p><p>frequentes para validar ideias de novos produtos. Ao trazer toda a equipe para o ciclo</p><p>de pesquisa, a equipe desenvolverá empatia pelos usuários e pelos problemas que</p><p>enfrentam. Por fim, à medida que a equipe aprende junta, você reduz a necessidade</p><p>de futuras conversas e documentação.</p><p>Princípio: gooB: a nova centralização no usuário</p><p>O que é?Pode parecer a primeira palavra de um bebê, mas GOOB é na verdade um</p><p>acrônimo para o que o professor, empresário e autor de Stanford, Steve Blank, chama</p><p>de “sair do prédio”. É a constatação de que os debates nas salas de reunião sobre as</p><p>necessidades dos usuários não serão resolvidos de forma conclusiva em seu</p><p>escritório. Em vez disso, as respostas estão no mercado, fora do seu prédio.</p><p>Princípios 9</p><p>www.it-ebooks.info</p><p>Depois de anos defendendo a pesquisa de clientes, a comunidade UX tem um</p><p>campeão do mundo dos negócios: Steve Blank. A receita de Blank: dê aos clientes em</p><p>potencial a oportunidade de fornecer feedback sobre suas ideias mais cedo do que</p><p>você faria no passado. Muito mais cedo. Teste suas ideias com uma forte dose de</p><p>realidade enquanto elas ainda são jovens. É melhor descobrir que suas ideias estão</p><p>errando o alvo antes de gastar tempo e recursos construindo um produto que</p><p>ninguém deseja.</p><p>Por que fazê-lo?Em última análise, o sucesso ou o fracasso do seu produto não é</p><p>uma decisão da equipe – é dos clientes. Eles terão que clicar no botão “Comprar</p><p>agora” que você criou. Quanto mais cedo você lhes der voz, mais cedo saberá se</p><p>tem uma ideia pronta para ser construída.</p><p>Princípio: Entendimento Compartilhado</p><p>O que é?O entendimento compartilhado é o conhecimento coletivo da equipe que se</p><p>acumula ao longo do tempo à medida que a equipe trabalha junta. É uma</p><p>compreensão rica do espaço, do produto e dos clientes.</p><p>Por que fazê-lo?O entendimento compartilhado é a moeda do Lean UX. Quanto mais uma</p><p>equipe entender coletivamente o que está fazendo e por quê, menos terá que depender de</p><p>relatórios de segunda mão e documentos detalhados para continuar seu trabalho.</p><p>Princípio: Antipadrão: Rockstars, gurus e ninjas</p><p>O que é?Lean UX defende uma mentalidade baseada em equipe. Rockstars, gurus,</p><p>ninjas e outros especialistas de elite em seu ofício quebram a coesão da equipe e</p><p>evitam a colaboração.</p><p>Por que fazê-lo?Rockstars não compartilham – nem suas ideias nem os holofotes. A</p><p>coesão da equipe se desfaz quando você adiciona indivíduos com egos grandes que</p><p>estão determinados a se destacar e ser estrelas. Quando a colaboração é</p><p>interrompida, você perde o ambiente necessário para criar o entendimento</p><p>compartilhado</p><p>que lhe permite [evitar repetições] avançar com eficácia.</p><p>Princípio: externalizando seu trabalho</p><p>O que é?Exteriorizar significa tirar o seu trabalho da cabeça e do computador e</p><p>colocá-lo à vista do público. As equipes usam quadros brancos, quadros de</p><p>espuma, paredes de artefatos, impressões e post-its para expor o trabalho em</p><p>andamento aos colegas de equipe, colegas e clientes.</p><p>Por que fazê-lo?A externalização tira ideias da cabeça dos colegas de equipe e as</p><p>coloca na parede, permitindo que todos vejam a posição da equipe. Ele cria um fluxo</p><p>passivo e ambiental de informações em toda a equipe. Inspira novas ideias que se</p><p>baseiam naquelas que já foram compartilhadas. Permite que todos os membros</p><p>10 Capítulo 2</p><p>www.it-ebooks.info</p><p>da equipe – mesmo os mais quietos – para participar de atividades de</p><p>compartilhamento de informações. Seus post-its ou esboços no quadro branco são</p><p>tão barulhentos quanto os da pessoa mais importante da equipe.</p><p>Princípio: Fazendo sobre a análise</p><p>O que é?Valores Lean UX fazendo análise. Há mais valor em criar a primeira</p><p>versão de uma ideia do que passar meio dia debatendo seus méritos em</p><p>uma sala de conferências.</p><p>Por que fazê-lo?A resposta às questões mais difíceis que a equipe enfrentará</p><p>não será respondida em uma sala de conferências. Em vez disso, eles serão</p><p>respondidos por clientes em campo. Para obter essas respostas, você precisa</p><p>tornar as ideias concretas – você precisa criar algo que as pessoas possam</p><p>responder. Debater ideias é um desperdício. Em vez de analisar cenários</p><p>potenciais, faça algo e saia do prédio com isso.</p><p>Princípio: Aprendizagem acima do crescimento</p><p>O que é?É difícil descobrir a coisa certa para construir e expandir um negócio em</p><p>torno disso ao mesmo tempo. São atividades contraditórias. O Lean UX favorece</p><p>o foco no aprendizado primeiro e depois na expansão.</p><p>Por que fazê-lo?Dimensionar uma ideia que não foi comprovada é arriscado. Pode</p><p>funcionar. E pode não ser. Se não funcionar e você expandiu para toda a sua base de</p><p>usuários, sua equipe desperdiçou tempo e recursos valiosos. Garantir que uma ideia</p><p>esteja correta antes de expandi-la reduz o risco inerente à implantação ampla de</p><p>recursos.</p><p>Princípio: Permissão para Falhar</p><p>O que é?Para encontrar a melhor solução para os problemas de negócios, as</p><p>equipes Lean UX precisam experimentar ideias. A maioria dessas ideias falhará. A</p><p>equipe deve estar segura de falhar se quiser ter sucesso.Permissão para falhar</p><p>significa que a equipe tem um ambiente seguro para experimentar. Essa filosofia</p><p>aplica-se tanto ao ambiente técnico (eles podem divulgar ideias de forma segura)</p><p>como ao ambiente cultural (eles não serão penalizados por tentarem ideias que</p><p>não tenham sucesso).</p><p>Por que fazê-lo?A permissão para falhar gera uma cultura de experimentação. A</p><p>experimentação gera criatividade. A criatividade, por sua vez, produz soluções</p><p>inovadoras. Quando as equipes não temem por seu trabalho caso façam algo errado,</p><p>elas estão mais propensas a assumir riscos. É desses riscos que surgem as grandes</p><p>ideias. Finalmente, como a anedota a seguir ilustra tão bem, os fracassos frequentes</p><p>levam a um maior domínio das habilidades.</p><p>Princípios 11</p><p>www.it-ebooks.info</p><p>Em um vídeo chamado “Por que você precisa falhar” (http://www.youtube.com/</p><p>watch?v=HhxcFGuKOys), o fundador da CD Baby, Derek Sivers, descreve os</p><p>resultados surpreendentes de uma aula de cerâmica. No primeiro dia, o instrutor</p><p>anunciou à turma que os alunos seriam divididos em dois grupos. Metade dos</p><p>alunos precisaria fazer apenas uma panela de barro durante o semestre. Suas</p><p>notas dependeriam da perfeição daquele pote solitário. A outra metade da turma</p><p>seria avaliada simplesmente pelo peso dos potes feitos durante o semestre. Se</p><p>ganhassem 50 libras em potes ou mais, obteriam um A. Quarenta libras dariam</p><p>um B; 30 libras, um C; e assim por diante. O que eles realmente fizeram foi</p><p>irrelevante. O instrutor disse que nem olhava para as panelas. Ele trazia sua</p><p>balança de banheiro para o último dia de aula e pesava o trabalho dos alunos.</p><p>No final do semestre, algo interessante aconteceu. Observadores externos da turma</p><p>notaram que os potes da mais alta qualidade foram feitos pelo “grupo da quantidade”.</p><p>Eles passaram o semestre inteiro trabalhando o mais rápido que puderam para fazer</p><p>panelas. Às vezes eles tiveram sucesso e às vezes falharam. Com cada iteração, cada</p><p>experimento, eles aprenderam. A partir desse aprendizado, eles se tornaram mais</p><p>capazes de atingir o objetivo final: fabricar potes de barro de alta qualidade.</p><p>Por outro lado, o grupo que fez um objeto não teve o benefício dessas iterações</p><p>fracassadas e não aprendeu rápido o suficiente para ter um desempenho no</p><p>mesmo nível que o “grupo de quantidade”. Eles passaram o semestre teorizando</p><p>sobre o que faria um pote de barro de “grau A”, mas não tinham experiência para</p><p>executar essa visão grandiosa.</p><p>Princípio: sair do negócio de entregas</p><p>O que é?Lean UX redireciona o processo de design dos documentos que a equipe está</p><p>criando para os resultados que a equipe está alcançando. Com o aumento da</p><p>colaboração multifuncional, a conversa entre as partes interessadas passa a ser</p><p>menos sobre qual artefato está sendo criado e mais sobre qual resultado está sendo</p><p>alcançado.</p><p>Por que fazê-lo?Documentos não resolvem os problemas dos clientes – bons</p><p>produtos sim. O foco da equipe deve ser aprender quais recursos têm maior</p><p>impacto nos clientes. Os artefatos que a equipe usa para obter esse</p><p>conhecimento são irrelevantes. Tudo o que importa é a qualidade do produto,</p><p>medida pela reação do mercado a ele.</p><p>12 Capítulo 2</p><p>www.it-ebooks.info</p><p>Concluindo: Princípios</p><p>Este capítulo apresentou um conjunto de princípios fundamentais para Lean UX. Esses são</p><p>os principais atributos que qualquer equipe Lean UX deve incorporar. À medida que você</p><p>começa a formar sua prática Lean UX, encorajo você a usar esses princípios para definir a</p><p>composição, localização, objetivos e práticas de sua equipe.</p><p>Na Seção II, colocarei esses princípios em ação ao detalhar todo o processo</p><p>Lean UX.</p><p>Princípios 13</p><p>www.it-ebooks.info</p><p>www.it-ebooks.info</p><p>SEC t I em II:</p><p>Processo</p><p>É terça-feira e Rick, Mark, Olga e Arti estão diante do quadro branco,</p><p>olhando para uma estrutura de arame que desenharam. Arti tem um</p><p>marcador na mão, mas não está desenhando. “Rick, não entendo o que</p><p>você quer dizer. Você pode explicar o problema?</p><p>Rick pega o marcador, limpa uma seção do tabuleiro e explica o regulamento</p><p>novamente. A equipe está projetando um aplicativo para corretores de ações, e o</p><p>aplicativo deve obedecer a um conjunto rígido de regulamentos. Rick, o analista</p><p>de negócios, é responsável por garantir que os projetos da equipe atendam às</p><p>regras.</p><p>Depois de um tempo, o time balança a cabeça e Arti pega novamente o marcador. Ela</p><p>sugere uma mudança no design do wireframe do aplicativo no quadro e a equipe</p><p>concorda novamente. Todos pegam seus iPhones, tiram fotos do conselho e</p><p>concordam em se reunir novamente no dia seguinte. Eles estão confiantes de que o</p><p>que concordaram estará pronto para teste de usuários na quinta-feira.</p><p>www.it-ebooks.info</p><p>Arti, a designer, volta à sua mesa para começar a detalhar o design que</p><p>esboçaram. Mark, o desenvolvedor front-end, começa a construir a página – ele</p><p>usa componentes pré-fabricados do guia de estilo de vida que a equipe</p><p>implementou, então ele não precisa esperar por Arti antes de colocar as peças</p><p>básicas no lugar. Rick abre o wiki do projeto e começa a documentar as decisões</p><p>que a equipe tomou sobre o comportamento do aplicativo. Ele revisará essas</p><p>escolhas com o proprietário do produto no final do dia. E Olga, a testadora de</p><p>controle de qualidade, inicia o processo de redação de testes para a nova seção</p><p>do aplicativo.</p><p>Este é o ritmo diário do Lean UX: uma equipe trabalhando de forma colaborativa,</p><p>iterativa e paralela, com poucas transferências, entregas mínimas e foco em</p><p>software funcional e feedback do mercado. Nesta seção, você verá como</p><p>isso é</p><p>feito.</p><p>Na seção anterior, mostrei as ideias por trás do Lean UX – os princípios que</p><p>orientam o trabalho. Nesta seção, sou muito prático e descrevo</p><p>detalhadamente o processo de implementação do Lean UX.</p><p>O Capítulo 3, “Visão, enquadramento e resultados”, descreve como o Lean UX muda</p><p>radicalmente a forma como estruturamos nosso trabalho. Nosso objetivo não é criar</p><p>uma entrega, é mudar algo no mundo – criar um resultado. Neste capítulo descreverei</p><p>a principal ferramenta que usamos para fazer isso: declarações de hipóteses.</p><p>O Capítulo 4, “Design Colaborativo”, descreve a mudança em nosso processo de design. Lean UX</p><p>usa muitas técnicas familiares aos designers, mas muda a ênfase do nosso trabalho. Tornamo-nos</p><p>mais colaborativos. Nosso objetivo é a velocidade primeiro. Priorizamos o aprendizado. Utilizamos</p><p>uma ferramenta fundamental para conseguir isso: o MVP.</p><p>O Capítulo 5, “MVPs e experimentos”, é sobre experimentos. Lean UX é baseado na</p><p>ideia de que começamos nosso trabalho com uma suposição. Usamos experimentos</p><p>para testar nossas suposições e depois desenvolvemos o que aprendemos nesses</p><p>experimentos. Este capítulo mostra como orientar seu processo de design em torno</p><p>de experimentos e aprendizado.</p><p>O Capítulo 6, “Feedback e Pesquisa”, trata do feedback. O trabalho de experiência do</p><p>usuário em qualquer formato requer boas contribuições dos usuários. Lean UX valoriza o</p><p>feedback contínuo para nos ajudar a orientar nosso processo de design. Este capítulo</p><p>mostra técnicas que as equipes Lean UX usam para obter feedback antecipadamente e com</p><p>frequência, e como incorporar esse feedback em futuras iterações de produtos.</p><p>www.it-ebooks.info</p><p>Capítulo 3</p><p>Visão, enquadramento e resultados</p><p>Se discordar do experimento, está errado.</p><p>Dr.Richard Feynman</p><p>Tradicionalmente, os projetos de design UX são enquadrados por requisitos e</p><p>resultados; as equipes recebem requisitos e esperam que produzam resultados.</p><p>O Lean UX muda radicalmente a forma como estruturamos nosso trabalho.</p><p>Nosso objetivo não é criar uma entrega, é mudar algo no mundo – criar um</p><p>resultado. Começamos com suposições em vez de requisitos. Criamos e testamos</p><p>hipóteses. Medimos para ver se alcançamos os resultados desejados.</p><p>Este capítulo aborda a principal ferramenta do trabalho focado em resultados: a declaração</p><p>de hipóteses. A declaração de hipótese é o ponto de partida para um projeto. Ele estabelece</p><p>uma visão clara para o trabalho e muda a conversa entre os membros da equipe e seus</p><p>gerentes de resultados (por exemplo, “criaremos um recurso de logon único”) para</p><p>resultados (por exemplo, “queremos aumentar o número de novos sinais -ups para o nosso</p><p>serviço”).</p><p>A declaração de hipótese é uma forma de expressar suposições de forma</p><p>testável. É composto pelos seguintes elementos:</p><p>Premissas</p><p>Uma declaração de alto nível do que acreditamos ser verdade.</p><p>17</p><p>www.it-ebooks.info</p><p>Hipóteses</p><p>Descrições mais granulares de nossas suposições que visam áreas específicas de</p><p>nosso produto ou fluxo de trabalho para experimentação.</p><p>Resultados</p><p>O sinal que procuramos do mercado para nos ajudar a validar ou invalidar as</p><p>nossas hipóteses. Muitas vezes são quantitativos, mas também podem ser</p><p>qualitativos.</p><p>Personagens</p><p>Modelos de pessoas para quem acreditamos estar resolvendo um problema.</p><p>Características</p><p>As alterações ou melhorias no produto que acreditamos que irão gerar os</p><p>resultados que buscamos.</p><p>Vamos dar uma olhada em cada um desses elementos com mais detalhes.</p><p>Premissas</p><p>A primeira etapa no processo Lean UX é declarar suas suposições. Todo projeto</p><p>começa com suposições, mas geralmente não reconhecemos explicitamente esse</p><p>fato. Em vez disso, tentamos ignorar as suposições ou, pior, tratá-las como fatos.</p><p>Declarar suas suposições permite que sua equipe crie um ponto de partida</p><p>comum. Ao fazer isso em equipe, você dá a cada membro da equipe – designers</p><p>e não designers – a oportunidade de expressar sua opinião sobre a melhor forma</p><p>de resolver o problema. Fazer um exercício de declaração de suposições coloca</p><p>as ideias de todos no quadro branco. Revela a divergência de opiniões da equipe</p><p>e também expõe um amplo conjunto de soluções possíveis.</p><p>Declarar suposições é a primeira etapa do processo Lean UX; veja a Figura 3-1.</p><p>Figura 3-1.O processo Lean UX, etapa 1</p><p>18 Capítulo 3</p><p>www.it-ebooks.info</p><p>Método: declaração de suposições</p><p>Quem</p><p>Declarar suposições é um exercício de grupo. Reúna sua equipe, certificando-se de que</p><p>todas as disciplinas estejam representadas, incluindo quaisquer especialistas no assunto</p><p>que possam ter conhecimentos vitais sobre o seu projeto. Por exemplo, se você estiver</p><p>lidando com uma reclamação frequente de um cliente, pode ser benéfico incluir um</p><p>representante de atendimento ao cliente da sua central de atendimento. Os representantes</p><p>de call center falam com mais clientes do que qualquer outra pessoa na organização e</p><p>provavelmente terão insights que o restante da equipe não terá.</p><p>Preparação</p><p>Avise a equipe com antecedência sobre o problema que eles enfrentarão para dar a todos a</p><p>chance de preparar qualquer material necessário ou fazer qualquer pesquisa relacionada</p><p>antes de começar. Coisas importantes para preparar com antecedência incluem:</p><p>1. Relatórios analíticos que mostram como o produto atual está sendo usado</p><p>2. Relatórios de usabilidade que ilustram por que os clientes estão realizando</p><p>determinadas ações em seu produto</p><p>3. Informações sobre tentativas anteriores de corrigir esse problema e seus sucessos e</p><p>fracassos</p><p>4. Análise das partes interessadas do negócio sobre como a solução deste problema</p><p>afetará o desempenho da empresa</p><p>5. Análises competitivas que mostram como os concorrentes estão lidando com os mesmos problemas</p><p>Método: Declaração do Problema</p><p>A equipe precisa ter um ponto de partida para o exercício. Achei útil começar com</p><p>uma declaração do problema. (Veja o modelo desta declaração mais adiante nesta</p><p>seção.) A declaração do problema dá à sua equipe um foco claro para seu trabalho. Ele</p><p>também define quaisquer restrições importantes. Você precisa de restrições para o</p><p>trabalho em grupo. Eles fornecem as proteções que mantêm a equipe fundamentada</p><p>e alinhada.</p><p>VISÃO, ENQUADRAMENTO E RESULTADOS 19</p><p>www.it-ebooks.info</p><p>Modelo de declaração de problema</p><p>As declarações do problema são compostas por três elementos:</p><p>1. Os objetivos atuais do produto ou sistema</p><p>2. O problema que as partes interessadas da empresa desejam resolver (ou seja, onde as metas</p><p>não estão sendo alcançadas)</p><p>3. Uma solicitação explícita de melhoria que não determina uma solução</p><p>específica</p><p>Modelo</p><p>[Nosso serviço/produto]foi projetado para alcançar[esses objetivos].</p><p>Observamos que o produto/serviço não está atendendo[esses objetivos], o que</p><p>está causando[este efeito adverso]para o nosso negócio. Como podemos</p><p>melhorar[serviço/produto]para que nossos clientes tenham mais sucesso com</p><p>base em[estes critérios mensuráveis]?</p><p>Por exemplo, aqui está uma declaração de problema que usamos para iniciar um</p><p>projeto na TheLadders, uma empresa de recrutamento online onde trabalhei. (Você</p><p>verá muitos outros exemplos de TheLadders ao longo deste livro.)</p><p>Nosso serviço oferece um canal entre quem procura emprego e empregadores que</p><p>tentam contratá-los. Através do nosso serviço, os empregadores podem chegar aos</p><p>candidatos a emprego no nosso ecossistema com oportunidades de emprego.</p><p>Observamos que um fator crítico que afeta a satisfação do cliente é a frequência com</p><p>que os candidatos a emprego respondem às mensagens dos empregadores.</p><p>Atualmente, os candidatos a emprego respondem a estas comunicações a uma taxa</p><p>muito baixa. Como podemos melhorar a eficácia dos nossos produtos de comunicação,</p><p>tornando assim os empregadores mais bem sucedidos nos seus empregos e os</p><p>candidatos a emprego mais satisfeitos com o nosso serviço?</p><p>As declarações de problemas estão cheias de suposições. O trabalho da equipe é dissecar a</p><p>definição do problema em suas suposições centrais. Você pode fazer isso usando a</p><p>seguinte</p><p>planilha de premissas de negócios. Observe que algumas equipes – especialmente aquelas</p><p>que começam do zero – podem não ter uma definição clara do problema. Tudo bem. Você</p><p>ainda pode experimentar a planilha. Você apenas terá que esperar que demore mais para</p><p>chegar a um consenso sobre algumas das questões.</p><p>20 Capítulo 3</p><p>www.it-ebooks.info</p><p>Planilha de premissas de negócios</p><p>Gosto de usar esta planilha (criada pelo meu parceiro Giff Constable) para facilitar a discussão de</p><p>suposições. Há muitas maneiras de preencher esta planilha. Você pode responder às perguntas</p><p>em equipe, simplesmente discutindo cada resposta. Ou você pode realizar um exercício</p><p>estruturado de brainstorming/mapeamento de afinidade para cada pergunta. Seja como for,</p><p>lembre-se de que é importante dar a todos a chance de contribuir. Além disso, não se preocupe se</p><p>chegar ao final da planilha sem um acordo claro sobre todas as respostas. O objetivo é coletar</p><p>declarações que reflitam o que você e sua equipe acham que pode ser verdade. Se você tiver um</p><p>forte desacordo sobre um ponto, capture as diferentes perspectivas.</p><p>Planilha de suposições</p><p>Suposições de negócios Suposições do usuário</p><p>1. Acredito que meus clientes</p><p>precisam _______.</p><p>1. Quem é o usuário?</p><p>2. Onde nosso produto se enquadra no trabalho ou</p><p>na vida dele?2. Essas necessidades podem ser resolvidas com</p><p>_______. 3. Que problemas nosso produto</p><p>resolve?3. Meus clientes iniciais são (ou serão)</p><p>_______. 4. Quando e como nosso produto é</p><p>usado?4. O valor nº 1 que um cliente deseja</p><p>obter com meu serviço é _______. 5. Quais recursos são importantes?</p><p>5. O cliente também pode obter esses</p><p>benefícios adicionais _______.</p><p>6. Qual deve ser a aparência e o comportamento do nosso</p><p>produto?</p><p>6. Adquirirei a maioria dos meus</p><p>clientes por meio de _______.</p><p>7. Ganharei dinheiro até _______.</p><p>8. Meu principal concorrente no</p><p>mercado será _______.</p><p>9. Iremos vencê-los devido a _______.</p><p>10. Meu maior risco de produto é _______.</p><p>11. Resolveremos isso através de _______.</p><p>12. Que outras suposições temos que, se</p><p>provadas falsas, causarão o fracasso</p><p>do nosso negócio/projeto? _______.</p><p>Você pode descobrir que algumas dessas questões não se aplicam ao seu projeto. Tudo bem –</p><p>você pode adaptar as perguntas à sua situação conforme achar adequado. Se estiver no início da</p><p>vida do seu produto, você provavelmente gastará mais tempo nas premissas do negócio. Se você</p><p>tiver um produto maduro, provavelmente concentrará suas energias nas suposições do usuário. O</p><p>objetivo é lançar uma rede ampla e procurar suposições em todas as dimensões do seu projeto.</p><p>Ao concluir a planilha, você terá uma lista de afirmações de suposições.</p><p>Sua próxima etapa é priorizar essas suposições.</p><p>VISÃO, ENQUADRAMENTO E RESULTADOS 21</p><p>www.it-ebooks.info</p><p>Priorizando suposições</p><p>A razão pela qual declaramos suposições no início do nosso trabalho é para que</p><p>possamos identificar os riscos do projeto. Depois de ter uma lista de suposições, você</p><p>precisa descobrir quais são as mais arriscadas para poder trabalhar nelas primeiro.</p><p>Lean UX é um exercício de priorização implacável. Compreendendo que não é</p><p>possível testar todas as suposições, como decidir qual delas testar primeiro?</p><p>Gosto de criar um gráfico como o da Figura 3-2 e usá-lo para mapear a lista de</p><p>suposições.</p><p>O objetivo é priorizar um conjunto de suposições a serem testadas com base no seu</p><p>nível de risco (ou seja, quão ruim seria se estivéssemos errados sobre isso?) e em</p><p>quanto entendimento temos da questão. Quanto maior o risco e mais incógnitas</p><p>envolvidas, maior será a prioridade para testar essas suposições.</p><p>Isso não significa que as suposições que não fazem parte do primeiro corte</p><p>desaparecem para sempre. Mantenha um registro das outras suposições que você</p><p>identificou para que possa voltar a elas e testá-las se e quando fizer sentido fazê-lo.</p><p>Figura 3-2.Matriz de priorização</p><p>Hipóteses</p><p>Com sua lista priorizada de suposições em mãos, você está pronto para passar para a</p><p>próxima etapa: testar suas suposições. Para fazer isso, transforme cada declaração de</p><p>suposição em um formato que seja mais fácil de testar: uma declaração de hipótese.</p><p>Geralmente, as declarações de hipóteses usam o formato:</p><p>Acreditamos[esta afirmação é verdadeira].</p><p>Nós saberemos que estamos[certo errado]quando vemos o seguinte</p><p>feedback do mercado:</p><p>22 Capítulo 3</p><p>www.it-ebooks.info</p><p>[feedback qualitativo]e/ou[feedback quantitativo]e/ou[mudança no</p><p>indicador chave de desempenho].</p><p>Você pode ver que este formato tem duas partes. Uma declaração do que você acredita ser</p><p>verdade e uma declaração do feedback do mercado que você está procurando para</p><p>confirmar que está certo.</p><p>Expressar suas suposições dessa forma acaba sendo uma técnica realmente</p><p>poderosa. Retira grande parte da conversa subjetiva e política do processo</p><p>de tomada de decisão e, em vez disso, orienta a equipe para o feedback do</p><p>mercado. Também orienta a equipe para usuários e clientes.</p><p>Sub-hipóteses: dividindo a hipótese em</p><p>partes menores</p><p>Às vezes – se não na maioria das vezes – você descobrirá que sua hipótese é</p><p>grande demais para ser testada com um único teste. Ela conterá muitas partes</p><p>móveis, muitas sub-hipóteses. Quando isso acontece, acho útil dividir a hipótese</p><p>em partes menores e mais específicas. Embora existam muitas maneiras de fazer</p><p>isso, para o trabalho do produto descobri que este formato é muito útil:</p><p>Nós acreditamos que</p><p>[fazendo isso/construindo este recurso/criando esta experiência]</p><p>para[essas pessoas/personas]</p><p>conseguirá[este resultado].</p><p>Saberemos que isso é verdade quando virmos</p><p>[este feedback do mercado, medida quantitativa ou percepção qualitativa].</p><p>O primeiro campo é preenchido com o recurso ou melhoria que você está</p><p>pensando em fazer em seu produto. O segundo campo descreve exatamente</p><p>quais dos seus clientes-alvo se beneficiarão desse recurso. O último campo fala</p><p>do benefício que esses clientes obterão com esse recurso. A declaração final une</p><p>tudo. Esta é a afirmação que determina se sua hipótese era verdadeira. Que</p><p>feedback do mercado você buscará para indicar que sua ideia está correta? Esse</p><p>feedback pode ser um uso medido quantitativamente de um recurso, um</p><p>aumento em uma métrica de negócios ou algum tipo de avaliação qualitativa.</p><p>VISÃO, ENQUADRAMENTO E RESULTADOS 23</p><p>www.it-ebooks.info</p><p>Nem tudo são números! É importante notar que tem havido muita reação no mundo do</p><p>design contra o design orientado por medição. O argumento é que, ao reduzir todas as</p><p>decisões de design a fatores que podem ser medidos, retiramos o encanto e a alma dos</p><p>nossos produtos. Na verdade, concordo com essa perspectiva, e é por isso que acho tão</p><p>importante incluir feedback qualitativo em seus critérios de sucesso. As pessoas ficam</p><p>encantadas com um design? Eles recomendam seu produto para amigos? Eles tweetam</p><p>sobre isso? Ao procurar métricas de sucesso, lembre-se de que nem tudo são números.</p><p>Vamos dar uma olhada em um exemplo de como isso funciona, voltando à</p><p>definição do problema que vimos anteriormente em TheLadders:</p><p>Nosso serviço oferece um canal entre quem procura emprego e empregadores que tentam</p><p>contratá-los. Através do nosso serviço, os empregadores podem chegar aos candidatos a</p><p>emprego no nosso ecossistema com oportunidades de emprego. Observamos que um fator</p><p>crítico que afeta a satisfação do cliente é a frequência com que os candidatos a emprego</p><p>respondem às mensagens dos empregadores. Atualmente, os candidatos a emprego</p><p>respondem a estas comunicações a uma taxa muito baixa. Como podemos melhorar a</p><p>eficácia dos nossos produtos de comunicação, tornando assim os empregadores mais bem</p><p>sucedidos nos seus empregos e os candidatos a emprego mais satisfeitos com o nosso</p><p>serviço?</p><p>Uma suposição que fazemos nesta definição do problema é que os recrutadores</p><p>usarão um novo canal (TheLadders) para interagir com os candidatos. Este não é um</p><p>fato comprovado e precisa ser testado. Como escreveríamos a hipótese para essa</p><p>afirmação? Vamos pegar nosso</p>