Ontwikkelaarsgerichte Productsprints voor inhoud en portals

Bij het creëren van ontwikkelaarsportals en inhoud is de snelheid van besluitvorming vaak belangrijker dan perfectionisme. Je kunt maanden besteden aan het ontwikkelen van een functie, iteraties doorlopen, middelen investeren, en toch, na de release, zien dat je doelgroep niet genoeg geïnteresseerd is of er simpelweg niet genoeg gebruik van maakt.

Vertrekken vanuit een concrete hypothese, niet vanuit een verlangen

Het moeilijkste deel van een productsprint is het identificeren van het juiste probleem en een hypothese die je daadwerkelijk kunt testen.

“We willen de UX-documentatie verbeteren” is niet echt een probleem. Het moet concreter en meetbaarder zijn, bijvoorbeeld:

• De helft van de gebruikers haakt af na de stap ‘Eerste API-oproep’ in de conversietrechter: Documentbezoek -> OpenAPI downloaden/kopiëren -> Eerste API-oproep -> Aanhoudende API-aanroepen.
• De doorlooptijd wordt met 20 minuten verlengd tijdens een specifiek leerlab of tutorialsessie.
• De gemiddelde sessieduur in de Cloud IDE bedraagt ​​minder dan 10 seconden.

Elk van deze kan na de release worden gemeten, verbeterd en opnieuw gecontroleerd.

Meet wat belangrijk is: indicatoren voor de aansluiting van producten op de markt voor ontwikkelaarsportals

Na elke release is het belangrijk om het succes te meten en relevante bedrijfs- en productgegevens te consolideren in één dashboard voor de belangrijkste belanghebbenden en de volgende sprint. Dit is waar product-market-fit (PMF)-indicatoren belangrijk worden.

Mogelijke sleutelindicatoren voor de geschiktheid van de productmarkt voor ontwikkelaarsportals:

• Groei in gebruik en inschrijving onder individuele en zakelijke klanten, met focus Activeringspercentage EN Gebruik van de retour.
• Voor educatieve inhoud of handleidingen, Voltooiingstijd moet overeenkomen met de geschatte tijd. Als een lab ontworpen is voor 30 minuten maar gemiddeld een uur duurt, is er te veel wrijving.
• Unieke bezoeken aan documentatiepagina’s en downloads of kopieën van OpenAPI-, SDK- en MCP-documentatie correleren met een toename van het aantal API-verzoeken.
• Bas supportticket voor 100 actieve ontwikkelaars (of op basis van het aantal API-verzoeken).
• Een laag 4xx-foutenpercentage na een update of documentrelease, samen met een hoog succespercentage bij het gebruik van de API.
• Tijd voor de eerste Hello World (TTFHW) – eerste app, integratie of API-call – minder dan 10 minuten.

Productanalysegebeurtenissen die we volgen of aanbevelen

Productanalyse- en gebruikerservaringsessies kunnen u voorzien van de informatie die u nodig heeft om productbeslissingen te nemen. Analytics kan ook gebruikersverhalen en functieverzoeken verrijken met echte gegevens.

Hier volgen enkele voorbeelden van Google Analytics-gebeurtenissen die helpen verklaren hoe gebruikers omgaan met op ontwikkelaars gerichte inhoud. Sommige ervan gebruiken we al in de praktijk, terwijl andere suggesties zijn die nuttig kunnen zijn voor teams die ontwikkelaarsportals en inhoud maken.

• sign_up, login – voor portals waarvoor inloggen vereist is.
• tutorial_begin – er is een tutorial geopend en de gebruiker heeft meer dan 10 seconden op de pagina doorgebracht.
• tutorial_complete – geactiveerd door meerdere signalen, zoals de tijd die op de pagina wordt doorgebracht, de scrolldiepte of het uitvoeren of kopiëren van gerelateerde opdrachten.
• search, view_search_results – om zoekpatronen te begrijpen en hoe gebruikers omgaan met resultaten.

Er is ook een specifieke reeks gebeurtenissen die ons helpt begrijpen hoe inhoud wordt geconsumeerd door gebruikers en AI-codeeragenten of -assistenten:

• copy_for_ai – hoe vaak en op welke pagina gebruikers Markdown kopiëren om in AI-agents te kunnen blijven werken.
• text_select / text_copy – geactiveerd wanneer de gebruiker interactie heeft met meer dan 500 tekens; nuttig als “Copy for AI”-proxy, zelfs op pagina’s zonder een expliciete knop.
• download_openapi_doc, download_mcp_doc, download_sdk_doc – hoe vaak elk compleet document wordt gedownload voor lokaal gebruik of AI-agentworkflows.

Validatie van beslissingen: analyses + gebruikersfeedback + zakelijke impact

Een kenmerk of verandering is een effectieve oplossing als je de hypothese vanuit drie invalshoeken kunt bevestigen:

• Productanalyse
• Feedback van gebruikers
• Zakelijke impact

Als ze alle drie dezelfde beslissing steunen, is het veel gemakkelijker om verder te komen. Als dit niet het geval is, betekent dit meestal dat de hypothese niet specifiek genoeg was.

Hoe we het toepassen in DevNet

Hier ziet u hoe deze cyclus werkt – hypothese, analyse, feedback, beslissing – in echte voorbeelden.

Voorbeeld 1: README – eerste Cloud IDE

Tijdens regelmatige UX- en feedbacksessies vertelden gebruikers ons dat ze de README van een repository wilden zien met gerelateerde instructies en inhoud, en duidelijkere richtlijnen voor het gebruik van de IDE zelf, terwijl ze werkten met codevoorbeelden in de Code Exchange Cloud IDE. Sommige van deze omgevingen zijn uniek, zoals Cisco NSO-containers die gebruikers rechtstreeks in de Cloud IDE kunnen starten.

Analytics liet hetzelfde probleem zien: het standaardvenster ‘Aan de slag met VS Code’ leidde gebruikers af in plaats van hen te helpen.

We hebben een vergelijkende analyse uitgevoerd over twee periodes, waarbij we het totale aantal geanalyseerde pagina’s hebben onderzocht, pagina’s met sessies van minder dan 2 minuten, het percentage pagina’s met een lage duur, het totale aantal weergaven, de duur van de kortste sessie en het aantal kritische pagina’s met een gemiddelde duur van minder dan 15 seconden. De gegevens bevestigden het patroon en de oplossing was om standaard de README-instructies van de repository te openen.

Voorbeeld 2: Beëindig verouderde repository’s met een gerelateerde repositorywidget

Het tweede probleem was een grote hoeveelheid verouderde inhoud van codevoorbeelden. Toen we naar de gegevens keken, zagen we dat deze repository’s nog steeds veel verkeer trokken, dus er zat zakelijke waarde in het zorgvuldig beheren ervan. Er waren twee opties:

1. Verwijder pagina’s volledig en zorg ervoor dat gebruikers een 404 kunnen krijgen.
2. Beëindig ze, toon een duidelijk beëindigingsbericht en geef een widget weer met andere gerelateerde repository’s.

We hebben voor optie 2 gekozen omdat dit gebruikers een consistentere ervaring biedt en hen naar inhoud leidt die nog steeds werkt.

Voorbeeld 3: “Ontwikkeld door”-filters in de MCP-catalogus

Een paar maanden geleden hebben we de AI-repositorycatalogus op Code Exchange uitgebracht, waar we MCP-servers en AI-agents verzamelen die verband houden met Cisco-technologieën. In UX-sessies vertelden gebruikers ons dat ze onderscheid wilden maken tussen MCP-servers die zijn uitgebracht door productteams en die zijn uitgebracht door de community:

• Productteam MCP-server ze zijn meestal een stabielere keuze en de meeste zijn afgelegen.
• Community MCP-server Ze zijn open source, zodat gebruikers de code kunnen lezen en de MCP-tools, prompts of bronnen zelf kunnen configureren.

Beide typen zijn waardevol, maar gebruikers wilden ze snel van elkaar onderscheiden. Om dit aan te pakken hebben we filteropties toegevoegd en een speciale badge geïntroduceerd die door Cisco ontwikkelde servers benadrukt.

Neem deel aan DevNet-feedbacksessies

Veel van deze veranderingen zijn begonnen tijdens gebruikerservaringsessies. Analytics kan ons laten zien waar gebruikers afhaken of problemen ondervinden, maar door met gebruikers te praten, kunnen we begrijpen waarom en wat we vervolgens kunnen verbeteren.

Wilt u uw feedback delen over inhoud voor ontwikkelaars en het Cisco DevNet-platform? Schrijf ons op devnet_feedback@cisco.com.