Como construir um caso para um redesign de produto

A história de redesenhar o Fabric Crashlytics no Firebase

Maple Blocked Unblock Seguir Seguindo 1º de outubro de 2018 Crashlytics in Fabric (à esquerda), redesenhado Crashlytics no Firebase (à direita)

Recentemente, tive a oportunidade de reprojetar o Crashlytics , uma ferramenta de relatórios de falhas que ajuda os desenvolvedores de aplicativos para dispositivos móveis a entender por que seus aplicativos estão falhando. (Alguma vez você teve uma falha de aplicativo em você? O Crashlytics ajuda os desenvolvedores a consertar isso.)

Minha equipe entrou no Firebase no Google em janeiro de 2017 como parte da aquisição da Fabric . Um dos objetivos da aquisição foi trazer o Crashlytics para o Firebase. Isso significava redesenhar e reconstruir nosso produto no Firebase, que usa Material Design e tem um sistema de design visual muito diferente.

Como precisávamos fazer uma atualização de design visual da Crashlytics, decidi que era uma ótima oportunidade para repensar toda a experiência do usuário, em vez de apenas migrar os recursos como estão. O Crashlytics é um produto muito apreciado, mas acumulou muitas dívidas de design desde a sua criação em 2011. Ouvimos de muitos usuários que eles tinham dificuldade em usar recursos ou não conseguiam encontrar um recurso que já tínhamos. Também estava ficando difícil para nossa equipe saber onde colocar novos recursos porque o produto não tinha uma hierarquia de informações clara – para nós mesmos e nossos usuários. Era hora de um novo design.

Mas primeiro, eu precisava construir meu caso.

Não se trata simplesmente de redesenhar um produto. Leva tempo para entender os usuários, como eles usam seu produto e os problemas que eles têm. É essencial obter todos esses insights antes de embarcar no próprio redesenho para garantir que a equipe esteja resolvendo os problemas certos e alinhados com os objetivos do projeto.

Etapa 1: entenda seus usuários

Comecei coletando informações. Conversei com colegas de equipe da Crashlytics que trabalharam no produto por muitos anos, nossa equipe de relações com desenvolvedores, pesquisadores de usuários e, é claro, nossos usuários. Eu precisava entender por que e como as pessoas usam o Crashlytics antes que eu pudesse descobrir como melhorar sua experiência de usuário.

Felizmente, Jason St. Pierre, meu gerente de produto, trabalhou na Crashlytics por mais de 5 anos e conversou com os usuários com frequência, então ele tinha um profundo entendimento de como uma variedade de pessoas usam o Crashlytics. Ele identificou as 4 jornadas de usuários mais críticas da Crashlytics:

  1. Monitorando a estabilidade de uma versão do aplicativo recém-lançado
  2. Verificar a estabilidade da aplicação
  3. Priorizando quais travamentos para consertar
  4. Depurando um problema do cliente

A jornada mais crítica do usuário no Crashlytics: Monitorando a estabilidade de uma versão recém-lançada do aplicativo

Eu mapeei cada uma dessas jornadas de usuários em fluxos usando personas, o que revelou uma micro jornada consistente entre todas as 4 jornadas: o fluxo “investigar e consertar”. Eu compartilhei essas viagens com a equipe e revisei os fluxos conforme necessário. Esses fluxos alinharam a equipe da Crashlytics em um entendimento básico e compartilhado de como os usuários usam nosso produto.

O fluxo “investigar e corrigir” é um conjunto recorrente de etapas pelas quais um usuário passa em todas as 4 jornadas do usuário

Passo 2: Entenda seus pontos de dor

Uma vez que estávamos alinhados sobre como as pessoas usam nosso produto, precisávamos entender seus pontos problemáticos com o UX existente. A equipe da Crashlytics é extremamente colaborativa e todos nós investimos na criação de uma ótima experiência para nossos usuários. Eu queria uma maneira de envolvê-los no processo de reformulação que fosse mais colaborativo do que eu compartilhando conceitos e obtendo o feedback deles. A equipe também teve muito contexto valioso sobre o produto que seria útil para alavancar o redesenho, já que muitos deles têm trabalhado no produto há anos.

Muitas pessoas da equipe da Crashlytics mencionaram vários aspectos das melhorias necessárias no painel. Para alavancar seus conhecimentos, decidi conduzir uma série de estudos internos de usuários. Meu objetivo era entender quais eram os maiores pontos problemáticos na experiência do usuário – com base no que ouvimos dos clientes ao longo dos anos.

Imprimi e recortei o painel do Crashlytics e configurei sessões individuais com os colegas de equipe, onde pedi que reorganizassem as peças e redesenhassem o painel, falando em voz alta para explicar seu pensamento.

Companheiros de equipe se divertindo redesenhando Crashlytics com recortes de papel Alguns dos painéis redesenhados – algumas pessoas também adicionaram novos recursos com post-its

Isso foi tremendamente útil. Não só foi divertido (com que frequência os designers digitais tocam com papel de verdade hoje em dia?), Eu pude ver o que cada pessoa identificou como pontos de dor sem que fossem influenciados por mais ninguém. Isso facilitou a identificação de temas recorrentes. Por exemplo, todas as pessoas se concentraram em melhorar os filtros e melhorar a hierarquia das informações. Também aprendi com a equipe de relações com desenvolvedores quais recursos eram difíceis de usar e encontrar.

Eu compartilhei esses aprendizados com a equipe em um baralho que catalogou o esforço de redesenho. Também configuro check-ins semanais de design com a equipe para compartilhar atualizações de design e trazê-los ao longo da jornada de reformulação.

Um slide do deck de processos de reformulação descrevendo temas recorrentes na página Visão geral do Crashlytics

Etapa 3: defina os problemas do usuário

Depois de entender os objetivos e pontos problemáticos de nossos usuários, os problemas do usuário tornaram-se muito mais claros. Eu levei todos os meus aprendizados das sessões de recortes de papel e conversas com os usuários e a equipe, depois me concentrei em nossos principais problemas de usuário:

Problema 1: Os usuários acharam difícil obter as informações com as quais realmente se importavam

A primeira coisa que a maioria dos usuários fez em nosso painel foi a rolagem para baixo. As informações procuradas estavam mais abaixo na página ou exigiam vários cliques para chegar. Foi enterrado por trás de características menos importantes.

A página de detalhes do problema em Fabric Crashlytics

Problema 2: os usuários não sabiam que os recursos existiam

Certa vez, um usuário me perguntou sobre adicionar um recurso para registrar o que aconteceu no aplicativo que levava a uma falha. Este recurso já existia em nosso painel de controle – foi apenas enterrado na interface do usuário. Nossa equipe de suporte ouviu muitos casos semelhantes de usuários também. Esse problema também refletia o problema enfrentado por nossa própria equipe: dificuldade em saber onde colocar os recursos.

A página de detalhes das sessões em Fabric Crashlytics

O tema dominante que surgiu foi que a hierarquia de informações do nosso produto não era clara , o que chamei as partes interessadas como o principal problema que devemos resolver. Como eles faziam parte do processo de design o tempo todo, era fácil se alinhar e conseguir o buy-in.

Como tudo funcionou

A equipe comprou oficialmente a necessidade de um novo design. Eles entenderam os problemas que os usuários tinham e concordaram sobre quais partes da experiência do usuário precisavam de melhorias. Sucesso! Os próximos passos foram realmente redesenhar o painel, o que aconteceu nos próximos meses por meio de muitos brainstorming, colaboração, check-ins e testes com usuários.

Construir um caso para um novo design envolve uma tonelada de configuração de contexto. Pode ser claro para você como designer que um produto precisa de um novo design, mas não se pode ir longe sozinho. O redesenho de um produto é um esforço de equipe e é importante que a equipe se alinhe sobre o motivo pelo qual um novo design é necessário. Também é impossível redesenhar algo se você não entender como ele é usado atualmente.

Compreendendo profundamente os usuários do Crashlytics, seus pontos problemáticos e seus problemas, eu estava muito melhor equipado para redesenhar o produto. E ao trazer os outros através desse processo, toda a equipe foi capaz de entender melhor os usuários e atender às suas necessidades. Depois de meses de trabalho duro e conversando com os usuários, lançamos com sucesso uma reformulação do Crashlytics no Firebase no início deste ano, com uma hierarquia de informações aprimorada e uma atualização visual, além de alguns novos recursos !

Para concluir, aqui está minha parte favorita do redesign Crashlytics:

Uma animação comemorativa quando um usuário conserta com sucesso um bug!