Waar dit artikel over gaat. Een illustratief uitgewerkt voorbeeld, geen klantresultaat. Het fintech-team, zijn product en elk cijfer zijn aannames. Het laat zien wat er nodig is om een ai-prototype dat goed demoot om te zetten in een feature die je voor alle gebruikers kunt zetten.
Neem een productteam van een series b-fintech aan. Een product manager bouwde in een weekend in lovable een prototype van een ai-feature. Het ziet er echt uit en deed het goed in de all-hands. Daarna blijft het liggen, omdat er echt uitzien en betrouwbaar zijn twee verschillende klussen zijn.
over dit voorbeeld: het team is generiek en er zit geen klant achter. Niets hier is een opgeleverd resultaat of een prognose. Het ontwerp is waar het om gaat, niet het logo.
#Waarom loopt een goed prototype vast voor het productie bereikt?
Omdat het prototype een andere vraag beantwoordt dan productie. Het prototype bewijst dat het idee één keer kan werken, op een schone invoer, met de oprichter achter het stuur. Productie moet werken op rommelige invoer, om 2 uur 's nachts, zonder dat iemand meekijkt, en verdedigbaar zijn wanneer een klant betwist wat de functie heeft gezegd. In dat gat sneuvelen de meeste v0- en lovable-bouwsels. Niet omdat het idee fout was. Omdat er geen pad was van demo naar iets waar je je naam onder durft te zetten.
Hoe breng je een ai-prototype naar productie?
Begin bij het echte probleem, niet bij de demo-ui. Bouw de feature opnieuw binnen je eigen product, met streaming-antwoorden, een testsuite die antwoorden toetst aan bekende goede gevallen, audit-logging en menselijke review waar het telt. Meet daarna de supporttickets over de feature voor en na.
#Wat bevat het productieontwerp?
Begin niet bij het chatvak in het prototype. Begin bij de supportwachtrij. Neem aan dat de drie tickets met het grootste volume over deze feature alle naar hetzelfde wijzen: gebruikers krijgen geen duidelijk antwoord zonder de support te mailen. Bouw de feature zo dat hij eerst die drie vragen beantwoordt, binnen het eigen product en designsysteem van het team, niet als een opgeplakte widget.
- streamende antwoorden, zodat de functie direct aanvoelt in plaats van een laadanimatie. Het antwoord verschijnt terwijl het wordt gevormd.
- een testsuite die de functie bij elke wijziging test tegen bekende goede antwoorden, zodat een aanpassing aan één prompt niet stiekem een ander geval kapotmaakt.
- audit logging bij elk antwoord, zodat support de exacte invoer en uitvoer kan opzoeken wanneer een klant betwist wat de functie heeft gezegd.
- in-product UX, gebouwd binnen hun ontwerpsysteem, zodat het aanvoelt als onderdeel van het product, niet als een chatvenster dat er iemand op heeft geplakt.
We are
Wij bouwen een vastgelopen prototype om tot een opgeleverde feature met streaming, een testsuite, audit-logging en native UX in het product.
We aren't
Wij zetten geen generiek chatvak boven op het product en noemen dat een ai-feature.
#Hoe weet je dat de feature supporttickets vermindert?
Bouw de feature achterwaarts vanuit de tickets. De vragen die het meeste supportvolume veroorzaken, beantwoordt de feature in het product, voordat iemand hoeft te mailen. Het auditlog laat zien welke vragen de feature afhandelt en welke nog bij een mens uitkomen. Datzelfde log helpt een team een echte daling van een seizoensdip te onderscheiden: vergelijk het volume van elk tickettype met een referentieperiode van vóór de lancering.
De testsuite zorgt dat elke verbetering standhoudt. Vóór de lancering draait elke wijziging tegen de bekende goede antwoorden. Een promptwijziging die één geval oplost en twee andere breekt, wordt gevangen voordat ze een gebruiker bereikt. Dat is het verschil tussen een demo die één keer werkt en een feature die elke keer werkt. Productteams noemen dit opleveren. Wij ook. Meer over hoe wij productwerk aanpakken, vind je hier.
#In welke volgorde bouw je het?
Eerst auditlog en testsuite, want je kunt niet verbeteren wat je niet kunt meten. Daarna de antwoorden op de belangrijkste tickets opnieuw bouwen in het product. Dan de UX in het designsysteem en de streaming. Tot slot een gefaseerde uitrol naar een groeiend aandeel gebruikers, waarbij je het auditlog in de gaten houdt voor alles wat de tests misten. Geen big-bang-lancering.
De toets: het moet van iets wat je gedemonstreerd hebt naar iets wat je opgeleverd hebt, en de supportwachtrij is hoe je weet dat het werkte.
Dit hebben onze uitgewerkte voorbeelden gemeen. De winst is niet het model. Het zijn de saaie delen eromheen: de testsuite, het auditlog, de reviewpoorten, de uitrol die je kunt volgen. Dat maakt van een prototype iets wat je voor alle gebruikers kunt zetten. Als je een v0- of lovable-build hebt die bij de demo blijft hangen zonder weg vooruit, is dat precies de kloof die wij dichten. vertel ons wat je bouwt.
