Como lançar novos recursos sem prejudicar os usuários fiéis

“Seja ágil; liberar cedo; solte com frequência.” Conhecemos o exercício. Mas é estrategicamente sábio continuar lançando recursos com frequência? Especialmente quando um produto que você está construindo atinge um determinado tamanho, você provavelmente não quer arriscar a integridade de seu aplicativo a cada nova versão secundária.

A pior coisa que pode acontecer com seu produto é que usuários fiéis, clientes que têm usado esse pequeno recurso de forma consistente ao longo dos anos, de repente não consigam usá-lo da mesma maneira conveniente. A mudança pode capacitar mais os usuários, mas a experiência se torna menos direta. Frustração e ansiedade entram nas mídias sociais de forma rápida e repentina, e a pressão sobre o suporte ao cliente para responder de forma significativa e a tempo aumenta a cada minuto. Claro, não queremos lançar novos recursos apenas para perceber que eles realmente prejudicam os usuários fiéis.

Leitura adicional no SmashingMag: Link

• Como começamos a lançar recursos duas vezes mais rápido
• A lista de verificação de lançamento do site - 15 verificações essenciais antes de entrar no ar
• Uma abordagem centrada no usuário para web design para dispositivos móveis
• Como lançar qualquer coisa

Podemos evitar isso sendo mais estratégicos ao lançar novas versões de nossos produtos. Neste artigo, analisaremos uma estratégia para designers de produto e engenheiros de front-end testarem e implantarem completamente um recurso antes de lançá-lo para toda a base de usuários e como evitar que problemas de UX surjam no caminho.

Antes de mergulhar em uma estratégia de teste real, vamos voltar atrás e examinar os equívocos comuns de como um novo recurso é projetado, construído e eventualmente implantado.

Equívocos sobre novos recursos

Sempre que um novo recurso para um produto existente é projetado, o foco principal geralmente é como exatamente ele deve ser integrado à interface existente. Para obter consistência, nós, designers, geralmente examinamos os padrões existentes e aplicamos a linguagem de design estabelecida para fazer com que o novo recurso se encaixe bem na interface do usuário. No entanto, os problemas geralmente ocorrem não porque os componentes não funcionam juntos visualmente, mas porque se tornam confusos ou ambíguos quando combinados de maneiras inesperadas .

Talvez a cópia da interface seja ambígua em áreas relacionadas, mas distantes do site, ou o resultado de dois recursos sendo usados ​​ativamente ao mesmo tempo faça sentido do ponto de vista técnico, mas não corresponda às expectativas do usuário ou tenha grandes implicações de desempenho e prejudique o UX .

De fato, no design, são essas inúmeras combinações que são tão difíceis de prever e revisar completamente. Uma maneira de abordar o problema já no processo de design é considerar os outliers – casos de uso em que as coisas têm mais probabilidade de dar errado. Como seria um perfil de usuário se o nome do usuário fosse muito longo? Uma visão geral de e-mails não respondidos ainda é óbvia quando uma dúzia de marcadores de caixa de entrada estão sendo usados? Um novo filtro faria sentido para usuários que acabaram de se inscrever e têm apenas alguns e-mails na caixa de entrada?

Projetando valores atípicos: a pilha da interface do usuário

Como exatamente podemos projetar os outliers depois de identificá-los? Uma boa estratégia é estudar os diferentes estados da interface do usuário. A “pilha de interface do usuário”, uma ideia introduzida por Scott Hurff, é versátil e complicada, e quando projetamos nossas interfaces, geralmente não é suficiente criar uma maquete perfeita em pixels no Photoshop, Sketch ou HTML e CSS – temos que considerar vários casos de borda e estados: o estado em branco, o estado de carregamento, o estado parcial, o estado de erro e o estado ideal. Estes não são tão simples como poderíamos pensar.

O estado em branco não precisa estar vazio — poderíamos estar usando service workers para fornecer uma melhor experiência offline aos visitantes regulares. O estado parcial não precisa ser quebrado — podemos melhorar a experiência com imagens quebradas e JavaScript quebrado por meio de aprimoramento progressivo.

O estado ideal pode diferir significativamente de nossos modelos de “resultado perfeito” – devido às preferências personalizadas do usuário e à escolha do navegador do usuário; alguns conteúdos e fontes da web podem não ser exibidos devido à configuração de um navegador, por exemplo.

Assim, a paisagem é, como sempre, complexa, complicada e imprevisível, e não podemos tornar insignificante o risco de as coisas correrem mal, mas isso não significa que não possamos minimizar o risco de forma eficaz. Ao explorar outliers e toda a pilha de interface do usuário desde o início, podemos evitar problemas comuns de UX no estágio inicial de design. Não fica mais fácil no lado técnico, no entanto.

O efeito borboleta na implantação

Mesmo pequenas mudanças tendem a levar a reações em cadeia, introduzindo bugs em áreas e situações que parecem não estar absolutamente relacionadas. A principal razão para isso é a grande quantidade de variáveis ​​que influenciam a experiência do usuário, mas que estão fora do nosso controle. Conhecemos nossos caminhos com os navegadores, mas isso não significa que sabemos mais sobre o contexto em que um usuário escolhe ver o site que criamos tão incansavelmente e completamente.

Agora, embora pequenas alterações, como o preenchimento de um botão ou uma área de texto progressivamente aprimorada, possam não parecer grande coisa, tendemos a subestimar o impacto dessas pequenas alterações ou recursos brilhantes em grande escala. Toda vez que tomamos uma decisão de projeto ou desenvolvimento, essa mudança tem algum efeito no sistema complexo que estamos construindo, principalmente porque os componentes que estamos construindo nunca existem isoladamente.

A realidade é que nós nunca apenas construímos um botão, nem simplesmente escrevemos uma nova função JavaScript – botões e funções pertencem a uma família de componentes ou bibliotecas, e todos eles operam dentro de uma certa configuração, e estão inevitavelmente conectados a outros partes do sistema por suas propriedades ou por seu escopo ou por seu nome ou por convenções não escritas da equipe.

Essas conexões “silenciosas”, quase imperceptíveis, são a razão pela qual a implementação de recursos é difícil e por que prever as consequências de longo alcance de uma mudança geralmente se mostra um exercício de visão aguçada. É por isso que é uma boa ideia evitar dependências desnecessárias na medida do possível, seja em CSS ou JavaScript - elas não ajudarão você com manutenção ou depuração, especialmente se você estiver confiando em uma biblioteca que você não entende completamente .

Felizmente, para entender melhor o impacto de uma mudança, podemos usar recursos como as ferramentas de desenvolvedor de um navegador. Podemos medir o alcance de um seletor ou o alcance de uma função JavaScript e, às vezes, pode ser uma boa ideia voltar a ele durante o desenvolvimento para manter o escopo da mudança o mais local e mínimo possível.

Isso é útil, mas também é apenas uma parte da história. Fazemos suposições, consciente e inconscientemente, com base em nossa própria experiência com a interface e nossos próprios hábitos - muitas vezes esquecendo que suposições podem (e, portanto, irão ) variar significativamente de usuário para usuário. A maioria dos aplicativos tem apenas uma interface, mas essa interface ou suas configurações podem ter dezenas de estados — com as visualizações mudando dependendo das configurações e preferências do usuário.

Pense em painéis com cartões que podem ser personalizados (software de análise), clientes de e-mail com visualizações “compactas”, “confortáveis” e “detalhadas” (Gmail), uma interface de reservas que muda para clientes logados e para hóspedes, uma experiência de leitura para pessoas que usam um bloqueador de anúncios ou um filtro antivírus agressivo. O efeito borboleta tem impacto em mais do que apenas a base de código; todos esses fatores externos também pesam, e testar contra eles – diferentemente dos testes unitários ou do controle de qualidade em geral – é muito difícil porque muitas vezes nem sabemos com o que testar.

Validação de recurso e máximo local

Podemos usar diagnósticos e métricas para determinar quais mudanças precisam ser feitas, mas seguindo apenas os dados, você pode acabar estagnando no que costumamos chamar de “máximo local”, um estado da interface com um design bom o suficiente, mas que totalmente carece de inovação porque sempre segue iterações lógicas e previsíveis. Ao trabalhar em um projeto e explorar os dados, tendemos a agrupar recursos nos quatro grupos a seguir:

• Características quebradas. . Recursos que parecem estar quebrados ou ineficientes — obviamente, precisamos corrigi-los;
• Funcionalidades não utilizadas. . Recursos que funcionam como pretendido, mas raramente são usados ​​- geralmente um sinal de que eles devem ser removidos ou precisam desesperadamente de inovação;
• Recursos de uso inesperado. . Recursos que são usados ​​de uma maneira extremamente diferente do que seus criadores imaginaram originalmente – um bom candidato para refinamento lento e contínuo;
• Funcionalidades de trabalho. . Recursos que são muito usados ​​e parecem estar funcionando conforme o planejado – nesse caso, nos perguntamos se há alguma maneira de melhorar ainda mais sua UX explorando o processo iterativo lento e conceitos inovadores totalmente diferentes em paralelo.

Os dois primeiros buckets são essenciais para manter uma interface funcional e utilizável, enquanto os dois últimos são essenciais para manter os usuários envolvidos e satisfeitos. Idealmente, queremos atingir os dois objetivos ao mesmo tempo, mas as restrições de tempo, orçamento e equipe têm a vantagem.

Ainda assim, uma vez que uma nova iteração ou uma nova ideia é escolhida, pode ser tentador começar a projetar ou construir o novo recurso imediatamente. Mas antes mesmo de pensar em como um recurso se encaixaria em uma interface existente, é uma boa estratégia validar a ideia primeiro – com um protótipo rápido e pesquisa do usuário. Uma maneira comum de conseguir isso é usando um processo iterativo rápido, como o sprint de design do Google Ventures. Ao iterar em alguns dias, você pode identificar como o novo recurso deve ser implementado e/ou se é útil da maneira que você imaginou inicialmente.

Com sprints de design, expomos a ideia à pesquisa de usabilidade desde o início. Na metodologia do Google Ventures, você testaria um design com cinco usuários por dia; então, você iteraria e passaria por outra rodada de testes do novo design. A razão pela qual todos os mesmos usuários estão envolvidos é porque se você testar um design diferente com cada usuário naquele dia, você não terá dados válidos para saber quais elementos devem ser alterados. Você precisa de alguns usuários para validar uma iteração de design.

Aplicamos um modelo ligeiramente diferente em nossos sprints. Quando começamos a trabalhar em um novo recurso, uma vez que um primeiro protótipo é construído, reunimos designers, desenvolvedores e a equipe de UX na mesma sala, convidamos usuários reais para testar e depois iteramos em um cronograma apertado. No primeiro dia, os primeiros testadores (duas a três pessoas) podem ser agendados para uma entrevista de 30 minutos às 9h, o segundo grupo às 11h, o próximo às 14h e o último uma por volta das 16h. Entre as entrevistas com os usuários, temos “janelas de tempo abertas”, quando realmente iteramos o design e o protótipo até que, em algum momento, tenhamos algo viável.

A razão para isso é que, desde o início, queremos explorar direções totalmente diferentes, às vezes até opostas, rapidamente; uma vez que coletamos feedback sobre diferentes interfaces, podemos convergir para o que parece ser a interface do “máximo absoluto” . Podemos obter feedback muito diversificado em iterações de design muito diversas mais rapidamente dessa maneira. O feedback é baseado principalmente em três fatores: mapas de calor que registram os cliques dos usuários, o tempo que os usuários precisam para concluir uma tarefa e quão agradável é a experiência para eles. No final da semana, continuamos trabalhando consistentemente com um número maior de usuários, assim como o Google faz, validando permanentemente o novo design à medida que avançamos.

Até agora tudo bem, mas às vezes um novo recurso aparentemente inovador colide com um recurso existente, e tê-los na mesma interface atrapalharia o design. Nesse caso, exploramos se uma das opções pode ser considerada uma extensão da outra. Se puder ser, começamos reiterando sua funcionalidade e o design. É quando temos que escolher um redesenho radical ou uma mudança incremental. O último é menos arriscado e manterá um padrão de interação familiar para os usuários, enquanto o primeiro é necessário se mudanças críticas forem impossíveis de serem alcançadas de outra forma ou se os ganhos de mudanças incrementais forem muito superficiais.

Em ambos os casos, é fundamental manter o foco em toda a experiência do usuário do produto, e não no valor de um único recurso desse produto. E uma vez que você escolheu o recurso e projetou e construiu o primeiro protótipo, é hora de testar.

Os oito níveis de teste

Bem, então, como podemos efetivamente impedir que erros e falhas se infiltrem em um ambiente real? Quantas verificações, revisões e testes executamos antes que um recurso seja implantado? E em que sequência executamos esses testes? Em outras palavras, como seria a estratégia final para lançar recursos?

Uma das melhores estratégias para lançar recursos foi proposta por Andrew Sumin, chefe de desenvolvimento do Mail.ru, um importante provedor de e-mail na Rússia. A estratégia não seria aplicável a todos os projetos, mas é uma abordagem razoável e abrangente para empresas que atendem produtos de médio e grande porte a milhares de clientes.

Vamos analisar a estratégia em detalhes e cobrir as oito etapas de um lançamento de recursos, abrangendo o processo de desenvolvimento de produtos do Mail.ru:

1. teste com desenvolvedores,
2. teste com usuários reais em um ambiente controlado,
3. teste com usuários de toda a empresa,
4. teste com testadores beta,
5. teste com usuários que optam manualmente,
6. teste de divisão e retenção de cheques,
7. solte lenta e gradualmente,
8. medir as consequências.

No caso do Mail.ru, o recurso mais importante para manter intacto, não importa o que está compondo uma mensagem (obviamente). Essa é a parte mais usada da interface, e permitir que ela fique indisponível ou funcione incorretamente mesmo por segundos estaria absolutamente fora de questão. Então, e se quiséssemos estender a funcionalidade de uma área de texto, talvez adicionando algumas funções inteligentes de preenchimento automático, um contador ou uma visualização lateral?

1. Teste com desenvolvedores

Quanto mais o tempo passa no desenvolvimento, mais caro fica para corrigir um problema. Novamente, pense em como todas as decisões estão conectadas no desenvolvimento de produtos; quanto mais refinado o produto, mais decisões precisam ser revertidas, custando tempo e recursos. Portanto, identificar e resolver problemas desde o início, tanto de uma perspectiva de negócios quanto de uma perspectiva de design e desenvolvimento.

Você não pode depurar uma ideia, portanto, o teste inicial deve ocorrer durante a produção, nos primeiros protótipos. Os primeiros testadores no Mail.ru, então, são os desenvolvedores que realmente escrevem o código. A empresa incentiva seus funcionários a usar o produto para comunicação interna (e até comunicação privada); assim, os desenvolvedores podem ser considerados usuários hardcore do produto.

A primeira etapa é bastante óbvia: projetar e construir o recurso e, em seguida, testá-lo localmente, revisá-lo e implementá-lo no servidor de teste. É aí que entra o teste de controle de qualidade, com ferramentas abrangentes e executores de tarefas que tentam travar o recurso e a interface, potencialmente automatizados com ferramentas de teste de macaco, como Gremlins.js.

Os resultados são monitorados e, em seguida, enviados de volta ao loop de feedback para a próxima iteração do recurso. Em algum momento, os desenvolvedores se sentirão bastante confiantes com a compilação: a mudança parece estar funcionando conforme o esperado e os requisitos foram atendidos. É quando o teste real do usuário entra em ação.

2. Teste com usuários reais em um ambiente controlado

Quando o primeiro protótipo funcional é concluído, o recurso é testado com usuários reais em entrevistas. Os clientes são convidados a concluir tarefas e, ao fazê-lo, a equipe de UX monitora becos sem saída e problemas que surgem e os aborda no local.

No entanto, não apenas o novo recurso está sendo testado; o objetivo do teste de usabilidade é garantir que o novo recurso não afete componentes críticos da interface, razão pela qual os usuários realizam tarefas rotineiras, como redigir uma mensagem e abrir, responder e navegar por e-mails em sua caixa de entrada. Se o novo recurso e os recursos antigos forem bem compreendidos, o processo pode seguir em frente.

3. Teste com usuários de toda a empresa

Obviamente, o feedback do teste de usabilidade leva os desenvolvedores a introduzirem mudanças, que então retroalimentam os testadores de usabilidade, indo e voltando até que o resultado pareça ter valor para um público maior. O próximo passo, então, é que o recurso seja destacado dentro da empresa: um e-mail para toda a empresa é enviado incentivando todos os colegas a verificar o recurso e enviar relatórios, bugs e sugestões em um rastreador.

Com os testes, não há uma diferença particularmente grande entre usuários em departamentos “remotos” dentro da empresa e usuários em geral. Mesmo os usuários internos não sabem quais mudanças esperar ou sabem exatamente o que um recurso faz ou como ele deve funcionar ou ser. A única diferença principal é que os colegas podem ser solicitados a enviar feedback rapidamente ou deixar um comentário. É quando os formulários de votação são introduzidos. Os testadores podem não apenas brincar com o recurso, mas também adicionar um comentário e votar a favor ou contra. A votação deve ser ponderada em relação à estratégia do produto e aos requisitos de negócios, mas se os usuários acharem claramente um recurso inútil ou útil, essa é uma maneira simples e eficaz de coletar feedback e testar se o produto funciona conforme o esperado.

4. Teste com testadores beta

Se um recurso passou por uma verificação técnica, uma verificação de usabilidade e uma revisão dentro da empresa, o próximo passo lógico é apresentá-lo a alguns segmentos do público. No entanto, em vez de lançá-lo para um segmento aleatório de usuários, a equipe envia um recurso para revisão entre os testadores beta - usuários que optaram por participar de testes e enviar feedback para recursos experimentais. Eles podem fazer downvote ou upvote em um recurso, bem como relatar bugs e confirmar partes de código.

Mas como você escolhe beta-testers apropriados? Bem, se você quiser incentivar os testadores a quebrar a interface, você pode se concentrar em usuários leais avançados com habilidades técnicas - usuários que poderiam fornecer detalhes técnicos sobre um bug, se necessário, e usuários que conhecem a interface existente o suficiente para serem capaz de antecipar problemas que outros usuários possam ter.

No entanto, você precisa de critérios para determinar se um usuário é avançado o suficiente para ser um testador beta. No caso de um cliente de e-mail, pode ser alguém que usa Chrome ou Firefox (ou seja, sabe como alterar seu navegador padrão), que criou mais de três pastas em sua caixa de entrada e que também instalou o aplicativo móvel.

5. Teste com usuários que optam manualmente

Até este ponto, os testes envolveram um número gerenciável de usuários, configurações e relatórios de teste. No entanto, a diversidade de usuários, sistemas e configurações existentes, incluindo sistema operacional, navegador, plug-ins, configurações de rede, software antivírus e outros aplicativos instalados localmente, pode ser um pouco mais assustadora em escala.

No caso do Mail.ru, o próximo passo é lançar o recurso em uma interface ao vivo, por trás de uma bandeira, e enviar um e-mail para esse segmento maior de usuários ativos, apresentando o novo recurso e convidando-os a ativá-lo em seus possui na interface, geralmente com um botão brilhante “Atualizar”. Para medir o valor do recurso para os usuários reais, a equipe novamente usa um sistema de votação, com alguns prompts aqui e ali, basicamente perguntando aos usuários se eles acham o recurso útil ou útil. Observe que a diferença entre este nível e o nível anterior é que o opt-in manual envolve um público muito maior - muitos dos quais não são técnicos, ao contrário dos testadores beta.

Assim, o tempo e a coordenação são importantes . Você provavelmente não escolheria um dia aleatório para enviar o e-mail para usuários ativos, porque deseja que a equipe de suporte ao cliente e os desenvolvedores estejam disponíveis quando o fluxo de relatórios de bugs começar a chegar. É por isso que o e-mail é enviado em no início da semana, quando todos (ou a maioria) dos desenvolvedores estiverem disponíveis e a equipe de suporte estiver pronta para entrar em ação, tendo sido informada e conectada ativamente com os desenvolvedores via Skype ou Slack. Em uma empresa menor, você pode até ter desenvolvedores sentados por algumas horas nas mesas de suporte para chegar ao cerne de um problema mais rapidamente, falando diretamente com os clientes.

6. Teste de divisão e retenção de cheques

Nas etapas até agora, exceto para testes de usabilidade, todos os testadores usaram o novo recurso voluntariamente. No entanto, se você habilitar o recurso por padrão, de repente os usuários terão que usá-lo, e este é um tipo muito diferente de grupo, um que não testamos.

Para garantir que você não quebre os hábitos dos usuários passivos, você pode fazer um teste de divisão com três pequenos segmentos de usuários e medir a retenção . Afinal, você quer ter certeza de que uma nova versão funcione pelo menos tão bem quanto a anterior. Identifique a atividade mais importante na interface e meça não apenas quanto tempo os usuários gastam nela antes e depois do lançamento, mas também quanto tempo passa até eles retornarem. No caso do Mail.ru, a retenção implica que os usuários verifiquem seus e-mails e componham uma mensagem. Quanto mais vezes um usuário voltar, maior será a retenção, o que é um indicador de um melhor UX.

Cada segmento recebe uma visualização ligeiramente diferente , o que nos permite testar como exibir o novo recurso para todos os usuários posteriormente. Para o primeiro segmento, adicionamos o novo recurso e fornecemos um tutorial sobre como usá-lo. Para o segundo segmento, apenas adicionamos o novo recurso. Para o terceiro segmento, poderíamos deixar o recurso como está. Para todos esses segmentos, poderíamos implementar a mudança ao mesmo tempo, selecionar um prazo razoável para executar o teste, medir a retenção e comparar os resultados. Quanto maior a retenção de um segmento, maior a probabilidade de que o design seja promovido a todos os usuários posteriormente.

7. Solte Lenta e Gradualmente

Se um recurso chegou até este ponto, provavelmente já funciona bem para um grande segmento do público. É quando você pode distribuir gradualmente para todos os usuários - com um prompt de votação para coletar feedback. Se o feedback for principalmente positivo, você pode continuar lançando o recurso e ele acabará se tornando parte integrante da interface. Caso contrário, você avaliaria o feedback e retornaria ao laboratório para a próxima iteração.

No entanto, o lançamento do recurso não é suficiente: ele precisa ser comunicado aos usuários. Uma maneira comum de fazer isso é através de e-mail e mídias sociais. Ainda assim, um rápido tutorial passo a passo explicando o valor do recurso em cenários da vida real também pode ser útil. Além disso, não se esqueça de integrar uma caixa de sugestões para obter feedback imediatamente.

8. Meça as consequências

Uma vez que o recurso tenha sido implementado, podemos monitorar seu desempenho e tentar diferentes métodos para chamar a atenção para ele, para que os usuários possam realizar suas tarefas com mais eficiência. Você pode rastrear as tarefas mais comuns ou as páginas mais visitadas e, em seguida, exibir uma pequena nota em linha recomendando uma maneira um pouco mais inteligente e rápida para o usuário atingir seu objetivo e, em seguida, avaliar se o usuário prefere esse novo recurso ou o método usual.

Não se esqueça de trazer o feedback de volta para toda a equipe, não apenas para os desenvolvedores ou designers, para que eles fiquem motivados e engajados e vejam como as pessoas usam um recurso que inicialmente não passava de uma ideia aproximada. Nada é mais motivador do que ver pessoas felizes e encantadas usando um aplicativo exatamente do jeito que você imaginou ou de maneiras totalmente diferentes. Também irá nutrir o crescimento dos recursos subsequentes da equipe.

O processo de revisão parece complexo e completo, mas às vezes apenas o tempo e uma ampla rede para testes com usuários descobrirão um problema. Por exemplo, se uma alteração afetar a aparência da visão geral das mensagens recebidas, nenhum teste de unidade poderá descobrir as dificuldades que os usuários de software assistivo possam encontrar. Em uma interface de e-mail, o que você deseja que o dispositivo de acessibilidade leia primeiro: a data, o remetente, a linha de assunto ou a própria mensagem? A maneira como você reorganiza as colunas na visão geral pode alterar a maneira como os usuários escolhem acessar as informações; portanto, permitir que eles desativem o novo recurso também seria crítico.

Conclusão

Então, como é uma estratégia de lançamento? Você pode começar explorando o gráfico de dependências para entender o alcance de sua mudança. Então, você pode testar o recurso com desenvolvedores e com usuários reais em um ambiente controlado. Em seguida, você pode pedir aos colegas que revisem o recurso antes de enviá-lo para um grupo seleto de testadores beta. Por fim, você pode disponibilizar o recurso como uma opção para os usuários. E, antes de habilitar o recurso para todos, você pode executar um teste de divisão para descobrir a melhor maneira de introduzir o recurso e, em seguida, medir as taxas de retenção para tarefas críticas.

Obviamente, a implantação não é um processo linear . Ao longo do processo, você pode precisar dar dois passos para trás para dar um passo à frente – até que finalmente tenha um candidato a lançamento. O fluxo de trabalho abordado acima pode parecer bastante lento e não particularmente ágil, mas você minimiza drasticamente o risco de os usuários serem repentinamente confrontados com um problema inesperado e terem uma experiência inferior como resultado. Em algumas situações, pode valer muito a pena.