Zes dingen die een site voor developers laten mislukken

Technische producten hebben vaak de lastigst te repareren sites. Het team kent het product tot in de diepte, dus wordt de site geschreven voor wie hem al begrijpt.

Dit zijn zes problemen die steeds terugkeren op sites voor developers, en wat je eraan doet.

1. De kop beschrijft de categorie, niet het resultaat

Een kop als "Bouw en integreer communicatie-apps. Sneller." klinkt specifiek en zegt bijna niets. Sneller dan wat? Voor wie?

Noem het resultaat. Laat je product een team een werkende koppeling opleveren in een dag in plaats van een maand, schrijf dat dan op.

2. De afkortingen voeren het woord

Vakjargon voelt precies voor wie erin werkt en leeg voor alle anderen. Termen als CPaaS, CCaaS en UCaaS verliezen de niet-technische koper, en bij de meeste deals tekent juist die persoon.

Schrijf eerst de gewone versie. Zet de afkorting erachter tussen haakjes als je het zoekverkeer nodig hebt.

3. Twee knoppen concurreren

"Gratis beginnen" naast "Praat met een expert" splijt de lezer in tweeën. Geen van beide is duidelijk de volgende stap, dus zetten veel mensen geen enkele.

Kies één hoofdactie en maak die overal visueel luider. De tweede mag bestaan, maar moet er tweederangs uitzien.

4. De bovenkant is overladen

Een generieke illustratie en een muur van tekst bovenaan is een veelvoorkomende combinatie. Geen van beide helpt. De tekening legt het product niet uit en de tekst is te lang om staand te lezen.

Breng de bovenkant terug tot één belofte, één ondersteunende regel, één knop, en één ding dat de belofte staaft.

5. Het ontwerp heeft geen hiërarchie

Felle kleuren even sterk ingezet, dichte tekstblokken, en geen duidelijke leesvolgorde. Als alles nadruk krijgt, krijgt niets nadruk.

Kies één accentkleur en gebruik die alleen voor de actie die je wilt. Breek de tekst zodat hij te scannen is. Leest iemand alleen de koppen, dan moet het aanbod nog steeds duidelijk zijn.

6. Het bewijs is er, maar werkt niet

Een rij bekende logo's zonder meer doet heel weinig. Een sectie met ervaringen zonder namen, functies of cijfers ook niet.

Maak het bewijs concreet. Eén persoon met naam, functie en een meetbaar resultaat doet meer dan tien logo's.

Wat het zwaarst weegt bij technische producten

Developers beoordelen door te proberen, niet door te lezen. Heeft je product een API, zet dan een echt stukje code op de pagina en laat zien wat het teruggeeft.

Een kort voorbeeld dat werkt wekt meer vertrouwen dan welke alinea over betrouwbaarheid ook.