Coordenação

Na Loog, como o Designer de Produto Sênior mais experiente da equipe, naturalmente assumi um papel de coordenação ao longo do tempo, desempenhando um papel na orientação do backlog e na definição dos rumos estratégicos da startup. Contribuí orientando e conduzindo diversas validações e descobertas, ofereci direcionamento aos designers, liderei diversas dinâmicas e participei ativamente de discussões técnicas, táticas e estratégicas na startup. Desempenhei diversas funções na Loog, e certamente a coordenação foi uma delas. Exercendo e praticando a coordenação eu enfrentei desafios diários de planejamento, objetivos de negócio desalinhados com os objetivos do usuário, mas creio que o meu maior desafio foi catalisar uma mudança na mentalidade da equipe. Desde o início, identifiquei um problema crucial: a construção de fluxos sem a validação do real desejo do usuário ou cliente. Ao longo de discussões aprofundadas, consegui introduzir e promover a mentalidade de abordagem fundamental versus incremental. Basicamente a mentalidade MVP. Considero essa transformação na mentalidade da equipe como uma das minhas maiores conquistas na Loog. Foi uma mudança significativa que permeou toda a equipe e tenho certeza que muitos levaram essa mentalidade para outros lugares. Certamente, há outros desafios que, como coordenador, poderia destacar, mas não quero prolongar mais este tópico. No entanto, se houver interesse ou curiosidade, fico à disposição para um bate-papo. :)

Validação Produto Proprietário

Quando comecei na Loog, um dos primeiros desafios foi validar o produto destinado aos donos de imóveis para aluguel. Lembrando que nosso modelo consistia em algo ousado: a Loog pagava o aluguel, gerenciava o imóvel por completo e garantia o pagamento do aluguel mesmo se estivesse desocupado. Claro, a Loog propunha e pagava um aluguel com um deságio. A estratégia que usei para validar foi lançar uma LP e abordar donos de imóveis para verificar se eles aceitariam o modelo de negócio proposto. Assim que os leads apareciam, eu entrava em contato com um roteiro de perguntas para entender se:

1. Eles compreendiam o modelo de negócio da Loog.
2. Estavam cientes de que a Loog seria responsável pelo pagamento do aluguel do imóvel.
3. Sabiam que a Loog faria uma "sublocação".
4. Aceitavam o modelo de negócio proposto.
5. E, mesmo com o deságio, viam vantagens no modelo da Loog. E por quê.

Alguns números:

1. Contatei 50 proprietários.
2. 23 eram leads não qualificados, podendo ter casas à venda ou imóveis fora da região de atuação. Não segui adiante com eles.
3. Dos 27 restantes, consegui conversar com 17.
4. Basicamente todos os 17 validaram o modelo proposto.

Decidi fazer uma breve análise do perfil desses 17 proprietários e proprietárias. Através dessa análise, identifiquei três proto-personas:

1. Livre de Despesas: Proprietários com imóveis com despesas muito altas.
2. Não Tenho Tempo para Administrar Meu Imóvel: Proprietários com rotinas profissionais que não dispõem de tempo para administrar seus imóveis.
3. Rendimento Certo Todos os Meses: Proprietários com vários imóveis que dependem do aluguel como fonte de renda, priorizando a segurança de receber um valor fixo todo mês, mesmo com o desconto.

No final, junto com a equipe, concluímos que o produto para o proprietário foi validado e tinha valor para algumas personas, mas reconhecemos que precisávamos acertar nas personas "Não Tenho Tempo para Administrar" e "Rendimento Certo Todos os Meses" e nos distanciar do ”Livre de Despesas”, proprietários com imóveis com despesas altas.

Planilha com o controle do recrutamento e da validação dos questionamentos

Utilizei uma planilha feita no sheets para reunir e compilar os dados.

Board final com a compilação dos proprietários

Com a ajuda do questionário acima fui capaz de encontrar semelhanças e diferenças nos leads interessados no modelo Loog.

Identificando as Personas Moradores

Eu dediquei um espaço separado apenas para falar sobre o processo de identificação das personas. Para dar uma olhada é só clicar abaixo.

Interfaces Loog

As interfaces que desenhei para a Loog tinham que ser simples e de fácil implementação. Por quê? Pois precisávamos ser ágeis o suficiente para validar o quanto antes o produto. Mas como colocado no tópico que falo sobre Coordenação, no início a equipe não estava preparada e não estava com a mentalidade MVP, e neste início fui cobrado muito para desenhar os fluxos "completos". Um exemplo prático foi o fluxo Minhas Visitas. Compare a complexidade das telas desenhadas por um outro designer e posteriormente as telas desenhadas por mim após os meus questionamentos em relação ao que é fundamental e o que é incremental.

Fluxo Minhas Visitas "Completo"

Difícil implementação, onerando Desenvolvimento, atrasando a entrega do fluxo em produção

Fluxo Minhas Visitas MVP

Simples implementação, o básico, o fundamental e com o tempo o cliente me diz qual caminho devo pavimentar

Com a adoção da mentalidade MVP, a Loog conseguiu aprimorar significativamente sua agilidade e eficiência nas entregas, especialmente em relação às variadas Landing Pages projetadas para testes de conversão e captação. Reduzimos o ciclo de criação, desenvolvimento e implementação de uma Landing Page de 5 a 7 dias para aproximadamente 2 a 3 dias. Isso contribuiu significativamente para a construção dessas páginas, tornando-nos mais eficientes na obtenção de dados para propor melhorias.

Diversas LP's

Apenas algumas das muitas desenhadas

Uma das várias análises das métricas das landing pages

Por meio do Hotjar e do Google Analytics, foi possível analisar, compilar e sugerir melhorias tanto na taxa de conversão quanto na usabilidade.

Exemplo de landing page testada

Uma das LP's testadas para o produto proprietário

Na concepção das interfaces, adotamos a estratégia de benchmarking, observando os fluxos propostos pelo mercado imobiliário e adaptando-os conforme nossos objetivos. Quando nos deparávamos com fluxos excessivamente complexos, empregávamos a técnica do MVP Concierge. Veja o exemplo do Fluxo Morador "Tenho Interesse" no imóvel. Durante sua construção percebemos que o fluxo era um tanto quanto complexo. Neste caso, a solução adotada foi direcionar o botão "Tenho Interesse" na página do imóvel diretamente para o Whatsapp Business da Loog. Neste canal, o potencial morador teria a oportunidade de interagir com um atendente humano, permitindo-nos compreender suas dificuldades e pontos de atrito. Isso possibilitou a proposição de fluxos mais adequados às necessidades do usuário.

Fluxo Morador Tenho Interesse "Completo"

Consideravelmente mais complexo do que o fluxo Minhas Visitas apresentado alguns pixels acima.

Fluxo Morador Tenho Interesse MVP Concierge

Optamos por direcionar o usuário diretamente para um atendente, facilitando a análise, compilação das dores e pontos de atrito, permitindo-nos propor fluxos mais adequados.

No final tivemos muitas telas desenhadas, várias landing pages analisadas e diversos userflows criados para realizar refinamentos junto aos desenvolvedores. Todo esse trabalho foi respaldado pelo Design System que desenvolvemos e pelos testes de usabilidade realizados que menciono nos tópicos logo abaixo.

Design System

Um dos problemas enfrentados pela equipe foi o desafio de manter a equidade visual entre elementos e componentes das interfaces, mas inicialmente, devido à natureza acelerada das demandas, análises e iterações, optei por não investir uma sprint na estruturação do nosso Design System. Para mitigar as divergências visuais e aprimorar a qualidade das entregas aos desenvolvedores, incorporamos no Definition of Done (D.o.D.) da equipe de designers a prática de revisar a padronização sempre que um fluxo ou interface fosse concluído. Era uma dinâmica semelhante ao Design Critique. Inicialmente, essa abordagem teve o efeito desejado, mas percebemos que algumas entregas estavam atrasando devido à necessidade de validação de toda a equipe, tornando-se um gargalo. Começamos então, a abrir exceções no cumprimento do D.o.D., e os problemas de equidade visual e padronização de componentes ressurgiram. Diante desse cenário, decidi dedicar uma sprint inteira para estruturar o Design System da Loog. Obviamente essa decisão revelou-se extremamente benéfica, pois, como sou obcecado pela padronização visual, observei que, logo após a implementação da estrutura básica do Design System, as entregas de interfaces e fluxos passaram a apresentar uma qualidade significativamente melhor. A lição aprendida foi que, em futuros projetos, deverei priorizar a construção do Design System desde o início e ir aperfeiçoando com o tempo. Embora, inicialmente, tenha deixado essa parte de lado na Loog, pois tudo era para ser entregue o quanto antes, percebi que esse descuido impactou negativamente na qualidade das entregas e no tempo perdido pela equipe.

Algumas telas do Design System estruturado

Fomos dos elementos mais simples para componentes mais

Testes de Usabilidade e Réguas de Relacionamento

Estou em processo de atualização do meu portfolio e ainda não subi o conteúdo sobre testes de usabilidade e réguas de relacionamento.