Ao criar portais e conteúdo para desenvolvedores, a velocidade na tomada de decisões geralmente é mais importante do que o perfeccionismo. Você pode passar meses desenvolvendo um recurso, passar por iterações, investir recursos e ainda assim, após o lançamento, ver que seu público-alvo não está interessado o suficiente ou simplesmente não está utilizando o suficiente.
Comece com uma hipótese concreta, não um desejo
A parte mais difícil de um dash de produto é identificar o problema certo e uma hipótese que você possa realmente testar.
“Queremos melhorar a documentação UX” não é um problema actual. Deveria ser mais concreto e mensurável, por exemplo:
- Metade dos usuários desiste após a etapa “Primeira chamada de API” no funil de conversão: Visita ao documento -> Obtain/cópia de OpenAPI -> Primeira chamada de API -> Chamadas de API sustentadas.
- O tempo de conclusão aumenta em 20 minutos durante um laboratório de aprendizagem específico ou sessão de tutorial.
- A duração média da sessão no Cloud IDE é inferior a ten segundos.
Cada um deles pode ser medido, melhorado e verificado novamente após o lançamento.
Avalie o que importa: indicadores de adequação do produto ao mercado para portais de desenvolvedores
Após cada lançamento, é importante medir o sucesso e consolidar dados relevantes de negócios e produtos em um único painel para os principais interessados e para o próximo dash. É aí que os indicadores de adequação do produto ao mercado (PMF) se tornam importantes.
Possíveis indicadores-chave de adequação do produto ao mercado para portais de desenvolvedores:
- Crescimento da utilização e cadastro entre clientes pessoas físicas e jurídicas, com destaque para Taxa de ativação e Retorno de uso.
- Para conteúdo ou guias educacionais, Tempo para conclusão deve corresponder ao tempo estimado. Se um laboratório é projetado para durar 30 minutos, mas dura em média uma hora, há muito atrito.
- Visitas únicas a páginas de documentação e downloads ou cópias de documentação OpenAPI, SDK e MCP correlacionadas com um aumento nas solicitações de API.
- Baixo tickets de suporte por 100 desenvolvedores ativos (ou por quantity de solicitação de API).
- Uma baixa taxa de erro 4xx após uma atualização ou lançamento de documentos, juntamente com uma forte taxa de sucesso no uso da API.
- Hora do primeiro Hey World (TTFHW) – primeira chamada de aplicativo, integração ou API – menos de 10 minutos.
Eventos de análise de produtos que rastreamos ou recomendamos
A análise do produto e as sessões de experiência do usuário podem fornecer as informações necessárias para tomar decisões sobre o produto. O Analytics também pode enriquecer suas histórias de usuários e solicitações de recursos com dados reais.
Aqui estão exemplos de eventos do Google Analytics que ajudam a explicar como os usuários interagem com o conteúdo voltado para desenvolvedores. Já utilizamos alguns deles na prática, enquanto outros são sugestões que podem ser úteis para equipes que constroem portais e conteúdos para desenvolvedores.
sign_up,login– para portais que exigem login.tutorial_begin– um tutorial foi aberto e o usuário passou mais de 10 segundos na página.tutorial_complete– acionado por vários sinais, como tempo na página, profundidade de rolagem ou execução ou cópia de comandos relacionados.search,view_search_results– para compreender os padrões de pesquisa e como os usuários interagem com os resultados.
Há também um conjunto específico de eventos que nos ajuda a entender como o conteúdo é consumido pelos usuários e agentes ou assistentes de codificação de IA:
copy_for_ai– quantas vezes e em qual página os usuários copiam Markdown para continuar trabalhando em agentes de IA.text_select/text_copy– acionado quando o usuário interage com mais de 500 caracteres; útil como proxy “Cópia para IA”, mesmo em páginas sem um botão explícito.download_openapi_doc,download_mcp_doc,download_sdk_doc– quantas vezes cada documento completo é baixado para uso native ou fluxos de trabalho do agente de IA.
Validando decisões: análises + suggestions do usuário + impacto nos negócios
Um recurso ou mudança é uma boa opção quando você pode confirmar a hipótese de três ângulos:
- Análise de produto
- Suggestions do usuário
- Impacto nos negócios
Suggestions do usuário e análises que alimentam as decisões do produto
Se todos os três apoiarem a mesma decisão, será muito mais fácil avançar. Caso contrário, geralmente significa que a hipótese não period suficientemente específica.
Como aplicamos isso no DevNet
Veja como esse ciclo – hipótese, análise, suggestions, decisão – funciona em exemplos reais.
Exemplo 1: README-first Cloud IDE
Durante sessões regulares de experiência do usuário e suggestions, os usuários nos disseram que queriam ver um README do repositório com instruções e conteúdo relacionado, e um guia mais claro sobre como usar o próprio IDE, enquanto trabalhavam com exemplos de código no IDE de nuvem de troca de código. Alguns desses ambientes são únicos, como Contêineres Cisco NSO que os usuários podem ativar diretamente no Cloud IDE.
O Analytics mostrou o mesmo problema: a janela padrão “Introdução ao VS Code” distraia os usuários em vez de ajudá-los.
Realizamos uma análise comparativa em dois períodos, observando o whole de páginas analisadas, páginas com sessões inferiores a 2 minutos, a porcentagem de páginas de baixa duração, whole de visualizações, a menor duração da sessão e o número de páginas críticas com duração média inferior a 15 segundos. Os dados confirmaram o padrão, e a solução foi abrir as instruções README do repositório por padrão.
Interface Cloud IDE atualizada com o repositório README aberto por padrão
Exemplo 2: descontinuação de repositórios desatualizados com um widget de repositórios relacionados
O segundo problema period uma grande quantidade de conteúdo de amostra de código desatualizado. Analisando os dados, vimos que esses repositórios ainda atraem tráfego significativo, portanto, havia valor comercial em manipulá-los com cuidado. Havia duas opções:
- Remova totalmente as páginas e deixe os usuários atingirem um erro 404.
- Suspenda-os, mostre uma mensagem clara de descontinuação e exiba um widget com outros repositórios relacionados.
Escolhemos a opção 2 porque ela oferece aos usuários uma experiência mais consistente e direciona-os para conteúdo que ainda funciona.
Widget com repositórios relacionados no Code Change
Exemplo 3: Filtros “Desenvolvido por” no catálogo MCP
Há alguns meses, lançamos o Catálogo de repositório de IA no Code Change, onde reunimos servidores MCP e agentes de IA relacionados às tecnologias Cisco. Nas sessões de UX, os usuários nos disseram que queriam distinguir entre servidores MCP lançados pelas equipes de produto e aqueles lançados pela comunidade:
- Servidores MCP da equipe de produto tendem a ser uma escolha mais estável e a maioria deles é remota.
- Servidores MCP da comunidade são de código aberto, para que os próprios usuários possam ler o código e configurar ferramentas, prompts ou recursos do MCP.
Ambos os tipos são valiosos, mas os usuários queriam distingui-los rapidamente. Para resolver isso, adicionamos opções de filtragem e introduzimos um emblema dedicado destacando os servidores desenvolvidos pela Cisco.
Filtros “Desenvolvido por” no catálogo MCP
Participe de sessões de suggestions do DevNet
Muitas dessas mudanças começaram nas sessões de experiência do usuário. A análise pode nos mostrar onde os usuários desistem ou têm dificuldades, mas conversar com eles nos ajuda a entender por que e o que melhorar em seguida.
Quer compartilhar seus comentários sobre o conteúdo do desenvolvedor e a plataforma Cisco DevNet? Escreva para nós em devnet_feedback@cisco.com.