Nova experiência de edição de fotos

Mais de 16% dos usuários relataram dificuldade para editar imagens na plataforma do Casar.com. Essa era a maior dor que eles tinham ao editar o site.

No Casar.com, os casais criam seus sites para anunciar o casamento e receber presentes dos convidados. Por isso, sempre foi muito claro para nós que os casais querem sites bonitos para os convidados verem.

O site é como a marca do casal!

Muitos até pagam fotógrafos profissionais para fazer um pré-wedding e tirar várias fotos lindas, para colocá-las no site e mostrar a todo mundo o quanto estão apaixonados.

Até aí, tudo bem! Mas imagine só:

Depois de tirar várias fotos incríveis e colocá-las no site, você encontra várias delas distorcidas e até cortadas, dependendo do dispositivo que está usando.

Você não tem controle real sobre como a foto aparece no site! Depois de tentar bastante, talvez você até consiga deixá-la bonita no computador… mas talvez uma das suas convidadas não tenha a mesma sorte no celular.

Mas essa percepção não veio só do nosso "feeling". Como você viu acima:

Mais de 16% dos usuários relataram dificuldade para editar imagens! Essa era a maior dor que eles tinham ao editar o site.

Tiramos esse dado da nossa "pesquisa de edição do site", que pergunta, de 1 a 5, qual foi o nível de dificuldade na edição, os principais pontos de dificuldade, e traz um espaço aberto para a pessoa contar um pouco mais sobre a experiência.

Essa pesquisa é um método de interceptação e foi integrada à plataforma pelo Typeform. Ela aparece quando a pessoa faz a segunda edição e clica no botão de salvar. A pesquisa de edição, junto com outras pesquisas, ajuda a alimentar o Problem Space do Casar de forma contínua, o que foi e continua sendo muito importante para entender o usuário e priorizar as dores que vamos resolver.

💡 Se você não conhece o termo "Problem Space", dê uma olhada no artigo abaixo, do Renato Caliari, sobre o Triple Track Agile. Garanto que você não vai se arrepender ;)

Triple Track Agile: a combinação do Problem Space com o Solution Space

Além da pesquisa, o time de CX recebia reclamações diárias sobre a edição de imagens. Muitas vezes, o time chegava a editar as imagens dos usuários à mão para que as fotos ficassem do jeito que eles queriam, o que tomava muito tempo.

Analisando a pesquisa e reunindo a experiência do CX, confirmamos a prioridade de resolver esse problema e conseguimos entendê-lo melhor. Com isso, usei o framework How Might We (HMW), ou "Como poderíamos", para ajudar a direcionar a construção da solução:

A maior parte dessa construção foi feita e documentada no Miro.

Com a direção definida, analisei a solução atual para encontrar pontos de melhoria. Descobri que a plataforma tinha experiências diferentes de edição de fotos em partes diferentes. Cada uma tinha problemas diferentes e precisava ser analisada separadamente. Para você ter uma ideia, uma delas não tinha edição nenhuma: a imagem era simplesmente inserida.

Foto de capa do site

Extremamente relevante

Problemas identificados:

• Não há corte nem pré-visualização específicos para celular
• Não dá para cancelar a ação de trocar a imagem de capa
• O corte não segue a proporção do tema, ou seja, mesmo que o tema tenha uma imagem de capa quadrada, o corte continua nesse formato retangular e a imagem fica superampliada no tema (obs.: cada usuário pode escolher um tema diferente para o site, mudando layout, cores, tipografia etc.)
• Não dá para trabalhar a imagem: ela fica do jeito que foi enviada
• Os usuários dizem que é difícil escolher a imagem no computador
• Os usuários reclamam que a foto fica com baixa qualidade

Imagens no corpo do site

Relevante

Problemas identificados:

• Não tem nem corte nem edição

Avatar dos noivos

Não tão relevante

Problemas identificados:

• Muito pequeno: é difícil selecionar um rosto numa foto grande
• Botões invertidos, o que causa estranhamento

Criação de um novo presente personalizado com foto

Não tão relevante, já que temos vários presentes pré-selecionados para o usuário escolher

Problemas identificados:

• Dá para arrastar uma foto do computador e soltar ali, diferente das outras, mas não há nenhum feedback, enquanto ela é arrastada, de que isso vai funcionar
• Depois de colocar a foto uma vez, nada indica como substituí-la
• Não dá para aplicar nenhum corte nem edição

Também era importante buscar referências de experiências de edição bem-feitas para ampliar meu repertório no assunto. Fui analisando concorrentes e outras referências e documentando com prints e post-its no Miro.

Daqui saíram insights importantes para a ideação, que ajudaram muito a resolver os problemas encontrados na análise da solução atual.

Usando os 3 HMWs definidos e as análises feitas, fiz uma ideação para definir os caminhos possíveis para a nossa solução. Nessa etapa, qualquer ideia vale: mesmo que pareça impossível no começo, ela ainda pode ser adaptada e se mostrar uma inovação de alto valor mais adiante.

Depois da ideação, priorizei cada uma das ideias numa matriz de impacto x esforço e agrupei as ideias para que fizessem sentido juntas. Assim, tínhamos várias propostas para a solução final, desde uma mais essencial e simples até uma com incrementos mais complicados, mas ainda relevantes.

Para viabilizar algumas das minhas propostas de solução, decidi pesquisar e analisar diferentes APIs de edição de imagem. Mas logo percebi que a API que usávamos na época, o Cropper.js, já tinha vários dos recursos mais importantes de que precisávamos. Assim surgiu outra proposta de solução, mais enxuta, mas com o essencial e com muito menos esforço do que as outras.

Propostas de solução com sketches

Apresentando as diferentes propostas de solução para o resto do time de produto, conseguimos discutir nossas prioridades e o esforço de cada uma das soluções, considerando a alocação do time de desenvolvimento.

Depois da discussão, o time concordou que, naquele momento, seguiríamos com a versão mais enxuta, mas essencial, da solução, já que ela resolveria grande parte da dor dos casais e usaria só os recursos da API atual.

Para criar os sketches, também pesquisei e documentei várias interfaces diferentes de upload e edição de imagens, o que também ajudou na construção do protótipo no Figma.

Vale lembrar que os novos usuários vão usar a ferramenta ao criar um site novo.

Mas e quem já editou todas as fotos? Vai ficar com as fotos antigas e distorcidas?

Pensando nisso, desenhei um modal com ícones personalizados para divulgar a novidade aos usuários atuais quando eles entrassem no site.

Decidimos fazer um lançamento em fases, ou seja, liberar para os usuários aos poucos, em etapas diferentes. Assim, conseguiríamos encontrar eventuais bugs na solução e corrigi-los enquanto ainda afetavam só uma parte dos usuários, sem deixar o problema ganhar escala.

Além disso, a solução inteira e suas particularidades, como o lançamento e os detalhes de interação com o usuário, foram detalhados num documento de requisitos para o time de desenvolvimento, com critérios de aceite, para que a solução fosse aprovada antes do deploy. Mas vale esclarecer que isso não substitui o handoff ao time de desenvolvimento, com conversas para tirar dúvidas sobre a solução, nem o acompanhamento enquanto ela é desenvolvida.

O primeiro próximo passo deste projeto seria fazer testes de usabilidade e corrigir os principais problemas encontrados. Só então a solução iria para o time de desenvolvimento, comigo acompanhando todo o processo e testando a solução final antes do lançamento para os usuários.

Depois do lançamento, precisaríamos analisar os resultados, mas é importante dizer que saí do Casar antes de a solução ser lançada, então não pude fazer essa análise. Ainda assim, as métricas que eu usaria são:

• Redução de tickets sobre o tema no CX
• Redução de exclusões de sites (agora automatizada e com uma pesquisa que desenhei para ajudar a alimentar o Problem Space)
• Customer Satisfaction Score (CSAT), analisando essa etapa da jornada com a pesquisa de edição