Maio de 2016

Volume 31 - Número 5

Visual Studio - Promovendo as Práticas do Lean UX

Por Karl Melder | Maio de 2016

No Visual Studio 2015, a Microsoft forneceu diversos novos recursos de depuração e diagnóstico que são detalhados por Andrew Hall no artigo de maio de 2016 da MSDN Magazine, “Debugging Improve­ments in Visual Studio 2015” (Visual Studio - Aprimoramentos de depuração no Visual Studio 2015) (msdn.com/magazine/mt683794). Para as funcionalidades que representam mudanças significativas para o UX, a Microsoft adotou uma abordagem “Lean UX” usando experimentos iterativos com comentários diretos do usuário para conceder informações ao design.

Quero compartilhar com vocês o processo que foi usado para projetar uma dessas funcionalidades, o PerfTips, bem como as práticas recomendadas, dicas e truques que aprendemos pelo caminho. A meta é inspirar e permitir que você e suas equipes apliquem com eficiência os comentários dos clientes diretamente nos processos de desenvolvimento.

Lean UX

O Lean UX é um complemento para as práticas de desenvolvimento lean que são tendência na nossa indústria. Eric Ries definiu lean como a prática de “Criar, medir e aprender” em seu livro de 2011, “The Lean Startup” (“O Startup Lean”) (Crown Business), em que ele descreve uma abordagem de “experimentação controlada por hipótese de negócios”. De forma semelhante, o Lean UX é um conjunto de princípios e processos que se concentra na validação de cliente contínua e muito antecipada, no qual você realiza experimentos para validar sua hipótese de design de usuário e de produto em ciclos extremamente breves. Iterações de design são realizadas rapidamente concentrando-se em solucionar problemas reais dos usuários. Uma boa referência é o livro de 2013 de Jeff Gothelf, “Lean UX” (O’Reilly Media), em que ele fornece diretrizes e planilhas para ajudar a esclarecer melhor no que eles acreditam ou esperam alcançar.

Para a equipe que fornece experiência de depuração no Visual Studio, o Lean UX é uma abordagem altamente colaborativa na qual toda a equipe, incluindo os gerentes de programa, pesquisadores, desenvolvedores e designers do UX se envolveram para gerar ideias, hipóteses e interpretar o que foi visto e ouvido dos nossos clientes.

Este artigo fala sobre como integrar totalmente os comentários dos clientes no processo de desenvolvimento de produtos. Ele fala sobre adiantar as falhas mais rapidamente. Ele fala sobre como receber comentários sobre suas ideias sem bits de trabalho. Não é apenas sobre uma equipe na divisão de ferramentas de desenvolvedor fazendo isso, mas várias equipes fundamentalmente mudando como as funcionalidades são projetadas em um processo de desenvolvimento lean.

O desafio do design

A tecnologia da Microsoft tem uma rica fonte de dados que pode fornecer aos desenvolvedores uma maneira conveniente de diagnosticar os problemas. Contudo, nos laboratórios de UX, os usuários repetidamente voltavam a percorrer a execução do código manualmente apesar das vantagens que ferramentas como o Criador de Perfil oferecem. Os dados de instrumentação corroboraram o baixo uso do Criador de Perfil do Visual Studio apesar da convicção de que ele poderia tornar a descoberta dos problemas de desempenho muito mais eficiente. Para uma ferramenta como o Visual Studio, em que o usuário gasta oito horas ou mais de trabalho por dia, pode ser complicado pedir ao usuário para mudar seu modo de trabalhar. Por isso, a equipe desejava aproveitar o estilo de trabalho natural do usuário ao depurar os problemas de desempenho para fornecer uma experiência de ambiente.

Se uma abordagem de cascata mais tradicional tivesse sido tomada, teria sido possível conduzir grupos de enfoque para obter comentários já no início, especificações detalhadas teriam sido redigidas e, quando a codificação estivesse quase concluída, os estudos de usabilidade poderiam ter sido agendados. Um usuário poderia ter recebido tarefas que utilizavam as novas funcionalidades e passavam os problemas por uma triagem, como é feito com bugs. Para o Visual Studio 2015, uma abordagem muito diferente foi usada.

O processo de pesquisa

Em vez de agendar os estudos de usabilidade quando os bits de trabalho estavam disponíveis, dois usuários foram pré-agendados toda sexta-feira para a maior parte do ciclo do produto. Esses dias são chamados informalmente de “Sextas Quick Pulse”. Os usuários participam por cerca de duas horas, sendo seu tempo geralmente dividido entre dois a quatro experimentos. Para cada experimento, foi indicada uma estimativa sobre quanto tempo deveria ser dedicado a ele. Todos os experimentos buscavam ajudar a Microsoft a conhecer melhor seus usuário e como eles trabalham, ou a experimentar uma ideia. Projete ideias para sobreviverem pelo menos três semanas recebendo resultados positivos para prosseguir com elas. Um resultado positivo significava que os usuários acreditavam que a ideia agregaria valor para eles, aumentava a taxa de descoberta, facilitava o uso ou poderia trazer melhorias para os principais cenários.

A pesquisa do UX geralmente é categorizada em quantitativa e qualitativa, em que uma combinação de instrumentação/análise e comentários do cliente direciona o negócio e o desenvolvimento do produto. Na pesquisa qualitativa inicial, os comentários significam observar a reação dos usuários às ideias. A equipe considera não apenas o que foi dito, mas também sua reação física, expressões faciais e tom de voz. Os usuários também recebiam uma tarefa real, como corrigir um bug de desempenho em um aplicativo sem qualquer auxílio da equipe de pesquisa enquanto eram observados, como mostrado na foto da Figura 1. Isso significa deixar os usuários terem certa dificuldade. A equipe capturou vídeo deles para futura análise e tomou notas sobre o que foi visto e ouvido. Assistir aos usuários ajudou a equipe a compreender seu estilo de trabalho e identificar as necessidades não articuladas que um usuário poderia não saber como expressar, mas que poderiam representar uma grande melhoria ao produto.

Figura 1: uma sessão de pesquisa com um usuário

O ponto crucial para o sucesso da equipe não foi gastar seu tempo tentando convencer os clientes a gostarem de uma ideia. Ela simplesmente apresentou a ideia aos usuários mostrando sobre como seria usá-la. Em seguida, a equipe se afastava e apenas ouvia, assistia e fazia perguntas que ajudavam a compreender o ponto de vista dos usuários. A chave para o sucesso da equipe foi a capacidade de desligar-se da ideia ou design que eles poderiam ter se apegado.

Toda semana os diferentes participantes eram recrutados para um fluxo constante de novas perspectivas. Uma equipe interna e um fornecedor recrutaram, selecionaram e agendaram os usuários. A equipe não buscou usuários com conhecimentos específicos de diagnósticos; o perfil de recrutamento foi simplesmente usuários ativos do Visual Studio. Isso significou que em cada semana havia usuários com diferentes habilidades, experiências e contextos de trabalho. Isso concedeu à equipe a oportunidade de aprender algo novo toda semana e permitiu identificar as consistências. A equipe também poderia desenvolver suas ideias para funcionarem com um público mais amplo.

Foi igualmente importante equilibrar a maneira como a equipe interagiu com os usuários. A maneira como uma pergunta era feita poderia afetar drasticamente o resultado ou influenciar a conversa. A equipe desenvolveu o hábito de sempre fazer perguntas livres, nas quais as perguntas inquisitivas derivavam daquilo que o usuário disse ou fez. Por exemplo, se um usuário dissesse à equipe que não gostou de algo, eles simplesmente pediriam: “fale mais sobre isso”. A equipe tentou não fazer suposições sobre nada e desafiou suas premissas e hipóteses em cada oportunidade. Essas habilidades são básicas para o campo do UX e foram adotadas por todos os membros da equipe. Se você deseja saber mais sobre essas técnicas de entrevista, recomendamos o livro de Cindy Alvarez de 2014, “Lean Customer Development” (“Desenvolvimento do cliente lean”) (O’Reilly Media).

Sessões Quick-Pulse antecipadas e o estilo de trabalho inabalável

No início do ciclo do produto, a equipe começou com uma ideia para ajudar os usuários a monitorarem o desempenho do seu código. A equipe criou um modelo e o apresentou aos usuários da Sexta Quick Pulse. O que foi constantemente ouvido, mesmo após três semanas de alterações de design, foi que eles não tinham certeza do que isso era e que “provavelmente o teriam desligado”! Isso não era necessariamente o que a equipe queria ouvir, mas foi o que precisava ouvir.

Contudo, enquanto observavam os usuários diagnosticarem os problemas do aplicativo, ficou claro que a equipe precisava de um UX que fizesse parte da experiência de navegação no código de forma mais direta. Embora existissem diversas janelas de depurador que forneciam informações adicionais, era difícil para os usuários prestarem atenção a várias janelas ao mesmo tempo. A equipe observou que muitos usuários mantinham a concentração no código, geralmente “percorrendo o código” mentalmente para a execução. Isso pode parecer óbvio para qualquer desenvolvedor que esteja lendo este artigo, mas o que foi fascinante foi como é inabalável este estilo de trabalho apesar da disponibilidade de ferramentas adicionais destinadas a tornar esta tarefa mais eficiente.

A equipe começou a imaginar ideias usando o Photoshop, em que um designer extremamente experiente seria convocado por um dia para gerar um modelo que poderia ser usado para comentários. O Photoshop tem a flexibilidade para criar uma interface do usuário com alta fidelidade. Em vez disso, a equipe começou a usar o Microsoft PowerPoint e um suplemento de storyboard (aka.ms/jz35cp) que permitiu que todos os membros a equipe criassem rapidamente representações de suas ideias com uma fidelidade média. Esses storyboards proporcionaram aos usuários uma ideia do que poderia ser, mas eles eram básicos o suficiente para os usuários entenderem que se tratava de um design em andamento sobre o qual suas contribuições teriam um impacto direto. O efeito final foi que era muito mais fácil descartar um investimento de 30 minutos quanto o experimento falhava. Além disso, era possível testar ideias que a equipe sabia que não funcionariam na prática, porém os comentários dos clientes sobre ela ajudaria a gerar novas ideias.

Para obter comentários sobre o modelo de interação do usuário, cada slide dos baralhos do PowerPoint representava uma ação do usuário ou uma resposta do sistema a essa ação. Ao esboçar a interação, era incluída uma imagem de ícone de cursor no local em que o usuário clicaria. Isso era útil ao compartilhar ideias e aperfeiçoar os detalhes. Contudo, o ícone do cursor seria removido antes de mostrar o modelo aos usuários. Isso permitia à equipe perguntar aos usuários o que eles fariam em seguida, fornecendo uma maneira fácil de identificar possíveis problemas de descoberta. Para cada slide de resposta do sistema, a equipe também perguntou aos usuário se eles achavam que estavam progredindo, que indicou para a equipe se os comentários fornecidos eram adequados. Essa técnica de comentários é chamada de “processo de passo a passo cognitivo” na pesquisa do UX e pode ajudar a identificar alguns problemas já nos primeiros estágios do design da interação, concedendo uma sensação antecipada das áreas de problema que exigirão iteração e experimentação posterior para corrigi-las.

Para medir o impacto em potencial de uma ideia, a equipe contou com a capacidade do usuário de articular especificamente como ele usaria a ideia em seu ambiente de trabalho cotidiano e quais pontos ele percebia como desvantagens ou benefícios diretos. O usuário precisava fornecer exemplos detalhados e plausíveis para que a equipe pudesse ter confiança de que valia a pena prosseguir com a ideia. A equipe também buscou perceber se o usuário começava a prestar atenção redobrada, ficar mais animado ou expressar empolgação. A equipe procurava ideias que deixariam os usuários empolgados e teriam um impacto positivo em potencial sobre sua experiência de diagnóstico.

“Nossa, isso é incrível!”

A equipe precisava de uma maneira de demonstrar as informações de desempenho no código de maneira a não afetar sua legibilidade e conceder aos usuários uma experiência de depuração no ambiente do código. Code Lens, um recurso do Visual Studio que permite ver informações sobre o histórico de edições, bugs, testes de unidades e referências, proporcionou a inspiração sobre um modelo de interação e um design visual em potencial. A equipe fez experiências com modelos de várias ideias que mostraram aos clientes como, à medida que um desenvolvedor percorre o código, ele mostraria os números de desempenho em milissegundos (veja a Figura 2).

Figura 2: um modelo inicial que mostra os dados de desempenho em uma sessão de depuração

A primeira indicação de que a equipe tinha alcançado algo foi quando um participante, que era um gerente de desenvolvimento, ficou muito empolgado quando mostraram a ele os passos da experiência. Devo enfatizar que a equipe havia acabado de mostrar a ele a experiência proposta sem qualquer informação anterior. À medida que entendeu o que era apresentado, ele começou a fazer perguntas detalhadas e ficou muito empolgado enquanto falava. Ele disse que essa seria a solução para um problema que ele estava enfrentando com seus desenvolvedores novatos que tomavam decisões erradas no código, resultando em baixo desempenho do aplicativo. Em seu processo atual, os problemas de desempenho eram resolvidos por meio de um processo de revisão de código trabalhoso, que representava uma carga pesada sobre ele e sobre sua equipe. Ele achou que a ideia poderia ajudar seus desenvolvedores novatos a aprender como escrever código de bom desempenho da primeira vez que o escreviam. Ele fez comentários como: “isso [o PerfTip] pode ser uma política [no Visual Studio]?” Outro usuário, após reconhecer o valor da ideia, comentou que “o que faz do Visual Studio incrível são suas funcionalidades quando estamos na linha de código!”

Esses comentários iniciais também animaram a equipe sobre este potencial recurso ser um ponto de entrada para as ferramentas de diagnóstico, solucionando alguns problemas de descoberta. A equipe elaborou a hipótese de que o PerfTips poderia ser um gatilho para os usuários se aventurarem pelo nosso rico conjunto de ferramentas.

Projetando os detalhes

Tudo feito até o momento envolveu apenas modelos, sem qualquer investimento em codificação. Se as ideias demonstrassem potencial, um nível maior de detalhes seria criado no “clickthrough” do PowerPoint, bem como diversas alternativas de design para experimentação semanal. Contudo, o limite do que poderia ser feito com modelos foi atingido, restando vários problemas de pesquisa:

• Validação de que o design do PerfTips não era uma distração ao depurar problemas lógicos comuns, permanecendo ainda notável ao lidar com problemas de desempenho.
• A equipe queria que os usuários interpretassem corretamente os números de desempenho, que foi cronometrado desde a última interrupção na execução.
• Os usuários sugeriram mostrar apenas os valores quando o desempenho fosse preocupante, porém ninguém conseguiu sugerir um limite padrão com confiança.
• A preocupação disso foi a possibilidade de sobrecarregar o depurador, o que poderia adicionar vários milissegundos, reduzindo seu valor para os clientes.

A equipe implementou uma versão mínima do recurso que funcionava em condições específicas. Depois, foi criado um aplicativo com problemas de desempenho e de lógica para os usuários diagnosticarem. Foi solicitado aos usuários identificar a causa específica do problema. Se eles não conseguissem fazer isso, a equipe poderia determinar por que os usuários não tiveram êxito pelo que foi visto e ouvido. O design poderia então ser alteado e testado novamente na semana seguinte. Além disso, durante este período, foi entregue uma versão de CTP externa que era instrumentada, na qual o PerfTip estava ligado à janela de propriedades para que os usuários pudessem facilmente alterar o limite se desejado. A equipe concluiu que:

• O PerfTips não causava distração quando os usuários corrigiam problemas de lógica. Na verdade, o PerfTips precisava ser editado com animações sutis para torná-lo mais notável para quando os usuários lidavam com problemas de desempenho.
• Algumas alterações simples de formulação, como adicionar a palavra “decorrido” esclareceu qualquer confusão que os usuários tinham sobre a interpretação dos dados de tempo.
• Os limites apenas confundiam os usuários quando eles não eram mostrados de maneira consistente e não era possível identificar um valor simples que poderia funcionar na maioria das circunstâncias. Alguns usuários disseram que, como eles conheciam melhor seus códigos, julgariam melhor o que seria um tempo razoável de desempenho.
• Os usuários reconheceram que os valores não seriam exatos por causa da sobrecarga do depurador, mas disseram que isso não era um problema, visto que eles estariam se concentrando em grandes diferenças.

Em geral, durante as várias semanas de iterações, a equipe obteve resultados positivos consistentemente ao pedir aos usuários para identificarem a origem dos problemas de desempenho. Sem qualquer prompt, os usuários também emitiram feedback entusiasmado com comentários como “Fantástico” e “Nossa, isso é incrível!”

Tomando notas

Ao tomar nota, a equipe aprendeu a evitar tirar conclusões até a conclusão da sessão, no momento certo de reunir-se e discutir o que havia ocorrido. Ainda mais útil foi fazer anotações muito básicas em tempo real, tentando tomar nota literalmente do que os usuários disseram e do que fizeram. Gramática e ortografia não era uma preocupação. Essas anotações se tornaram a referência da equipe para se atualizar sobre o que acontecia e obter informações dos padrões que eram observados com o passar das semanas.

O Microsoft OneNote demonstrou ser uma ferramenta muito prática para rastrear o que a equipe estava planejando testar, capturar anotações básicas e esboçar resumos rápidos. Sempre havia um escrivão designado que capturava o que era visto e ouvido. Isso proporcionava aos outros membros da equipe oportunidade para concentrar-se totalmente no usuário. Para aqueles que não podiam participar, as sessões ao vivo eram compartilhadas com a equipe usando o Skype; todos da equipe eram convidados para assistir e aprender. Além disso, as sessões eram gravadas para os membros da equipe que enfrentavam conflitos de reuniões e desejavam assistir posteriormente. As gravações de vídeo também permitiam à equipe revisar as áreas que precisavam de atenção extra. A discussão da equipe sobre os resultados de cada semana informava sobre o que seria feito na semana seguinte, enquanto redigir um relatório formal era desnecessário e apenas retardaria o processo.

Conclusão

O design e desenvolvimento do PerfTips foi apenas uma parte do que foi feito nos experimentos semanais. Muitas ideias foram exploradas, com até quatro experimentos por usuário a cada semana. O redesign das Configurações de Ponto de Interrupção é outro exemplo dos experimentos que foram conduzidos semana a semana para iteração rumo ao fornecimento de uma experiência mais útil e utilizável. Aplicando o Lean UX, a equipe foi capaz de reduzir os riscos e inspirar-se com o que era visto e ouvido durante os experimentos. Esses experimentos retiraram as suposições da equação ao reelaborar as funcionalidades. As ideias vieram de muitas fontes e sua inspiração reside na observação de como os desenvolvedores trabalhavam naturalmente.

Se os usuários não achassem uma ideia valiosa, o baixo custo da criação de um modelo tornava muito fácil recomeçar. Além disso, as falhas levavam a novas ideias. Espero que os exemplos e dicas do Lean UX inspirem você a experimentar. A série de livros “Lean” referenciada neste artigo servirá como um guia e estrutura para adotar esta abordagem.

Participe do programa

A equipe de pesquisa do Microsoft UX está buscando comentários diretos de todos os tipos de desenvolvedores, bem como sua participação neste experimento em andamento. Para inscrever-se, informe alguns detalhes sobre seu conhecimento técnico e como você deseja ser contatado em aka.ms/VSUxResearch.

Desejo agradecer especialmente a todos aqueles envolvidos de uma forma ou outra neste projeto. A única maneira de descrever as Sextas Quick Pulse é “lotadas”, com a equipe assistindo, aprendendo e raciocinando muito sobre como fornecer uma adição inteligente útil ao Visual Studio. Agradecemos especialmente Dan Taylor, que liderou a equipe de desenvolvimento e que desbravou os desafios tecnológicos com confiança. Andrew Hall manteve a equipe seguindo a frente com seu profundo conhecimento técnico e abordagem pragmática. Frank Wu manteve um fluxo constante de ideias de design e apresentou uma habilidade incrível de consolidar uma ideia e encontrar uma maneira de mantê-la simples.

Karl Melderé um pesquisador sênior do UX que vem aplicando constantemente seu conhecimento e experiência à pesquisa de UX, ciência da computação e interface do usuário e fatores humanos ao design de UXes. Por mais de 15 anos, ele vem trabalhando para aprimorar a experiência de desenvolvimento no Visual Studio para uma ampla variedade de clientes.

Agradecemos aos seguintes especialistas técnicos da Microsoft pela revisão deste artigo: Andrew Hall, Dan Taylor e Frank Wu
Andrew Hall é um gerente de programa sênior na equipe do Depurador do Visual Studio. Depois de se formar na universidade, ele criou aplicativos de negócios antes de voltar a estudar para conquistar seu mestrado em ciência da computação. Depois de concluir seu mestrado, ele se uniu à equipe de ferramentas de diagnóstico no Visual Studio. Durante seu tempo na Microsoft, ele trabalhou nas ferramentas de depuração, criação de perfil e análise de código no Visual Studio.

Dan Taylor é um gerente de programa da equipe dos Diagnósticos do Visual Studio e tem trabalhado nas ferramentas de criação de perfil e diagnósticos pelos últimos dois anos. Antes de fazer parte da equipe dos Diagnósticos do Visual Studio, Taylor foi um gerente de programa da equipe do .NET Framework e contribuiu para diversas melhorias de desempenho do .NET Framework e do CLR.

Frank Wu é um designer de experiência do usuário sênior que atualmente se concentra no design e fornecimento da melhor experiência de edição e diagnósticos para todos os desenvolvedores. Ele trabalhou em softwares de segurança, produtos do Windows Server e ferramentas de desenvolvedor pelos últimos 10 anos após conquistar seu mestrado em HCI.