Atuação
PM · UX Designer
Período
2025–2026
Plataforma
iOS & Android
Time
2 devs · 2 ilustradores · 1 PM/designer

Minha Atuação

Atuei inicialmente como Product Designer, participando das etapas de discovery, definição de fluxos e prototipagem das telas da primeira versão do jogo. Ao longo do desenvolvimento, passei a atuar como Product Manager e UX Designer, focando mais na camada estratégica do produto e passando a gerenciar o time, acompanhar prazos e definir escopo.

Colaborei com definição de fluxos, condução de testes, análise de feedbacks e tomada de decisões de produto orientadas por dados e usabilidade, além da definição de visão e modelo de negócio — o que explica o menor aprofundamento em decisões de interface neste case.

01

Contexto

O The King's Jest é um jogo mobile multiplayer no formato party game, em que jogadores competem em partidas rápidas usando os sensores do celular para se movimentar e desviar de obstáculos.

O projeto foi desenvolvido durante um ciclo do Apple Developer Academy, no qual o time tinha apenas três meses para conceituar, desenvolver e lançar um jogo na App Store com uma mecânica ou dinâmica diferente do mercado.

Trade-offs

  1. Necessidade de narrativa

    Além de ser divertido, o jogo seria apresentado em pitch para possíveis investidores, o que exigiu a construção de uma narrativa forte e clara para sustentar a experiência de entretenimento.

  2. Foco na mecânica central

    Priorizamos a entrega de uma fase completa e funcional em três meses, suficiente para validar a mecânica central, mesmo sem contemplar toda a experiência de um party game.

  3. Domínio desconhecido

    Optamos por desenvolver um jogo mesmo sem experiência prévia do time com game design, assumindo o risco de explorar um território novo como parte do processo.

02

Discovery e Direcionamento

Premissas Iniciais

Desde a primeira reunião, o time decidiu usar o Core Motion, kit nativo do Swift que captura os movimentos do celular, como base da mecânica do jogo, por seu potencial de diferenciação. Para reforçar essa proposta e sustentar uma narrativa forte para o pitch, optamos pelo multiplayer local, partindo da premissa de que a presença física dos jogadores potencializaria a experiência.

  • •

    O movimento físico seria a mecânica central do jogo

  • •

    O multiplayer local reforçaria a narrativa e a experiência social

  • •

    Partidas rápidas e informais seriam ideais para momentos de descontração

  • •

    A presença física dos jogadores estimularia reações espontâneas e interação social

Benchmark

A análise de similares teve como foco dois eixos principais: mecânica baseada em sensores e formato de party game. Para mecânica, usamos como referência WarioWare e 1-2-Switch, jogos que exploram sensores para criar desafios rápidos e acessíveis. Já para o formato, analisamos party games conhecidos como Pico Park, Fall Guys e Mario Party, que se destacam por partidas curtas, dinâmicas variadas e forte interação social presencial.

Tabela de benchmark comparando The King's Jest com WarioWare Move It!, 1-2-Switch, Mario Party, Pico Park e Fall Guys em seis características, entre elas sensores como mecânica central e multiplayer local em vários dispositivos

Among Us foi analisado como referência de sucesso em party games mobile, mas não entrou no benchmarking por não atender aos critérios centrais definidos para o projeto.

Hipóteses de Público e Comportamento

Neste momento do projeto, as decisões partiam majoritariamente de suposições, e o público-alvo foi definido com base no contexto de uso imaginado: jovens e adultos (14–30 anos) → que gostam de estar presencialmente com amigos → e buscam experiências competitivas leves.

Como se tratava de um produto de entretenimento, a aceitação da mecânica, do formato e do público era incerta e só poderia ser avaliada após o desenvolvimento do MVP. Por isso, durante o Discovery, essas incertezas foram organizadas na forma de hipóteses a serem validadas com o jogo em uso real:

  • 01

    O jogo teria apelo para um público amplo e diverso

  • 02

    A mecânica baseada em movimento causaria surpresa positiva

  • 03

    O multiplayer local funcionaria como diferencial e narrativa do produto

  • 04

    O jogo teria potencial de estimular interação e engajamento social entre amigos

03

MVP

Storytelling

Definimos um contexto narrativo simples para dar identidade ao jogo sem interferir na gameplay, usando o storytelling apenas como apoio para criar conexão e contextualizar os desafios.

Ambientado em um universo medieval fictício, o jogo traz humor ácido e dificuldade moderada, onde bobos da corte competem pela aprovação de um rei cruel. No MVP de fase única, a experiência se resume a uma corrida de plataformas em uma masmorra, na qual os jogadores precisam escapar sem cair na lava.

MoSCoW

Com apenas dois meses até o lançamento, usamos o MoSCoW para priorizar requisitos técnicos e de viabilidade, focando na validação das tecnologias centrais do jogo.

Quadro de priorização MoSCoW com quatro colunas — Must, Should, Could e Won't — listando requisitos como arquitetura modular, mecânica central e multiplayer local em Must, e ajustes de sensibilidade em Won't

Arquitetura do Fluxo

Abaixo estão as opções e estados principais do fluxo da primeira versão.

Diagrama do fluxo de usuário do MVP na versão 1.0, indo de abrir o jogo a inserir o apelido, o menu principal, criar ou entrar em uma sala, a sala de espera, jogar a fase 1 e a tela de fim de jogo, em que o tempo é a pontuação
04

Validação do MVP

Testes em Ambiente Controlado

Após o lançamento do jogo, realizamos testes controlados com dois grupos de 4 a 8 jogadores, focados em validar o multiplayer local e a mecânica central. Os participantes seguiam o público-alvo inicialmente definido: jovens de 14 a 30 anos, com diferentes níveis de familiaridade com jogos.

6 em cada 10 relataram dificuldade para se adaptar à mecânica.

Todos esses participantes não tinham familiaridade prévia com jogos.

Todos os participantes que se consideravam gamers avaliaram a experiência como satisfatória.

Tanto a dificuldade da fase quanto a experiência geral foram bem avaliadas por esse grupo.

Esses resultados indicaram que o jogo gerava mais engajamento no público com hábito de jogar, que demonstrou maior interesse em repetir as partidas. A partir disso, decidimos levar o jogo para um evento de games, com o objetivo de testar essa hipótese em alta escala, em um contexto mais próximo do público gamer.

Testes em Contexto Real

Os testes em alta escala foram realizados durante um evento de jogos, ao longo de três dias. Nesse período, mais de 600 partidas foram jogadas. Para estimular o engajamento e observar comportamento competitivo, organizamos uma competição com premiações, que teve alta adesão do público e repetição espontânea de partidas.

  • •

    O jogo estimula não apenas competição, mas também auto-superação, com jogadores buscando melhorar seus próprios tempos

  • •

    A maioria do público joga com amigos remotamente, mas relatou pouco hábito de encontros presenciais para jogar

  • •

    Mesmo não sendo jogadores mobile frequentes, grande parte do público avaliou a mecânica como divertida e afirmou que jogaria novamente

  • •

    Mais da metade dos interessados utilizava Android, evidenciando um ponto crítico de plataforma para o produto, que ainda era disponível somente para iOS

Conclusões e Quebra de Hipóteses

Os testes mostraram que algumas hipóteses se confirmaram, enquanto outras precisaram ser reformuladas a partir do uso real do produto.

❌ O jogo teria apelo para um público amplo e diverso

O engajamento foi significativamente maior entre pessoas com familiaridade prévia com jogos.

✅ A mecânica baseada em movimento causaria surpresa positiva

A proposta foi percebida como divertida e diferente, inclusive por quem não costuma jogar no celular.

❌ O multiplayer local funcionaria como diferencial e narrativa do produto

Na prática, a exigência de presença física limitou o uso e reduziu oportunidades de jogo.

✅ O jogo teria potencial de estimular interação e engajamento social entre amigos

A interação social se mostrou relevante, mas os jogadores relataram preferência por jogar com amigos à distância.

05

Redirecionamento de Produto

Os dados de validação indicaram limitações no público-alvo inicial, no modelo de multiplayer e na escalabilidade técnica do jogo. A partir disso, liderei um redirecionamento estratégico do produto, com foco em ampliar alcance, aumentar oportunidades de uso e potencializar crescimento.

Decisões Estratégicas

Os aprendizados dos testes levaram a mudanças estruturais no direcionamento do produto.

Maior engajamento entre jogadores experientes → Refinamento de público-alvo

O público deixou de ser generalista e passou a ser mais específico.

Novo público-alvo: jovens e adultos (14–30 anos) com familiaridade prévia com jogos digitais, que valorizam experiências competitivas.

Auto-superação como motivador → Inclusão de modo single-player

Muitos jogadores criavam salas para jogar sozinhos, tentando melhorar seus próprios tempos.

Isso levou à inclusão de um modo treino, focado em prática individual e repetição rápida de partidas.

Presença física como barreira de uso → Mudança de modelo de multiplayer

O multiplayer local restringia oportunidades de jogo e não refletia o comportamento do público, que relatou preferência por jogar à distância.

A decisão foi migrar de multiplayer local para multiplayer online, ampliando a frequência de uso.

Predominância de usuários Android → Reconstrução técnica do produto

A concentração de usuários Android evidenciou um gargalo de alcance da versão iOS-only.

Optamos por reconstruir o jogo do zero em Unity, viabilizando suporte multiplataforma e uma base técnica mais flexível para evolução contínua.

Reestruturação da Experiência

A reconstrução técnica abriu espaço para redesenhar a experiência de ponta a ponta. O fluxo do jogo foi reestruturado considerando:

  • •

    A nova plataforma (Unity) e suas possibilidades técnicas

  • •

    O novo modelo de multiplayer online, com foco em estabilidade e escalabilidade

  • •

    A inclusão do modo treino (single-player), atendendo comportamentos já observados

  • •

    Uma arquitetura de experiência preparada para múltiplas fases, progressão e expansão futura

Resultados Finais

Aproveitando a reconstrução do jogo, amadurecemos a identidade visual e revisamos todas as telas para refletir o novo fluxo, considerando a migração para Unity, o multiplayer online e a inclusão do modo single-player.

Telas da versão 1.0 ao lado da versão 2.0, mostrando a identidade visual amadurecida — a tela inicial, as telas de sala e de partida, a tela de inserir código e o cronômetro em jogo, redesenhados no novo estilo medieval

O comportamento de auto-superação observado foi transformado em uma opção de uso.

Modo single-player, antes e depois. Antes, jogar sozinho exigia criar uma sala vazia e iniciar a partida sem ninguém; depois, a opção oficial Praticar Sozinho aparece na tela de jogar, ao lado de Criar Partida e Entrar em Partida
Fluxo do anfitrião da partida, antes e depois. Antes, o anfitrião aprovava cada jogador manualmente na visão geral da sala; depois, ele gera e compartilha um código de partida de seis caracteres e os jogadores preenchem a grade sozinhos
Fluxo do convidado da partida, antes e depois. Antes, os jogadores procuravam uma sala em uma lista e esperavam a aprovação do anfitrião; depois, inserem o código da partida para acesso imediato e só esperam o anfitrião começar

Definição de Métricas e Telemetria

Estruturamos a base analítica do produto (NSM, OMTM e eventos), viabilizando testes quantitativos e iterações futuras orientadas por métricas.

  • •

    North Star Metric (NSM): tempo de jogo diário por usuário ativo

    Reflete o quanto o jogo entrega valor contínuo aos jogadores.

  • •

    One Metric That Matters (OMTM): taxa de partidas finalizadas

    Jogadores que concluem partidas passam mais tempo jogando e tendem a voltar.

Por não termos um modelo de monetização, o foco é entender quanto tempo os jogadores passam dentro de partidas, pois é um indicativo direto de engajamento.

Plano de eventos de telemetria em três etapas. Criação e entrada de partidas acompanha os fluxos do host, do convidado e solo para medir o funil de início de partida, revelando erros de distribuição de hosts e convidados, tempo de espera para iniciar a partida e desistência. Gameplay da fase 1 registra a saída da sala para medir engajamento e desistência, avaliando dificuldade e tempo de jogo até a frustração, para ajustar o balanceamento. Encerramento e Retenção registra fechar o jogo, voltar ao menu e jogar de novo para medir a OMTM, validando a hipótese de que quem conclui a fase tem mais chances de jogar novamente
06

Reflexões Finais

Desenvolver um produto de entretenimento colocou todo o time em um território novo. O foco não era resolver uma dor direta, mas criar uma experiência diferente, divertida e memorável.

Ficou claro que pensar em um jogo exige uma lógica diferente de produtos utilitários. As decisões vão além de eficiência e usabilidade, e passam por engajamento, surpresa e vontade de jogar de novo. Apesar da complexidade, esse desafio tornou o projeto especialmente divertido de construir.

Atuei principalmente na camada estratégica do produto, transitando entre os papéis de designer e product manager. Ao longo do projeto, consolidei meu interesse e facilidade em funções que exigem visão de produto, organização e comunicação constante.

“O The King's Jest está disponível, com as evoluções descritas neste case, para iOS e Android.”