Omdat de opmerkingen van de CEO via Slack binnenkomen, bouwde ik een AI-reviewwebapp, maar toen kwam er een nieuwe hindernis | Topics

~Een ontwerper bouwt samen met AI een webapp met authenticatie op Cloudflare~

Hallo. Ik ben Hassie, UI-ontwerper.

Tegenwoordig tekenen we niet meer eerst wireframes en laten we die door klanten goedkeuren. In plaats daarvan gebruiken we steeds vaker AI om mockups van landingspagina's en websites te maken, die we dan ter goedkeuring voorleggen.

Vroeger, wanneer we een ontwerp lieten goedkeuren, gebeurde dat via Slack,

"Kun je hier meer witruimte toevoegen!" "Vervang deze afbeelding!" "Hier moet de tekst worden gewijzigd!"

en zo kregen we feedback in de vorm van opmerkingen.

Op het eerste gezicht is dit een gebruikelijke aanpak.

En eerlijk gezegd leverde dit tot nu toe geen grote problemen op.

Sinds we met AI steeds sneller prototypes maken, is echter een bepaald probleem steeds duidelijker naar voren gekomen.

Opmerkingen komen binnen.

Slack is handig.

Het is handig, maar uiteraard is het geen tool die uitsluitend bedoeld is voor design reviews.

Dagelijkse werkberichten, praatjes en overleg over andere projecten komen allemaal op dezelfde plek binnen.

Het gevolg:

Correctieopmerkingen belanden in een ander gesprek
Er ontstaan steeds meer threads
"Welke correctie was dat ook alweer?"
Voor je het weet is het onderwerp alweer veranderd

en dat gebeurt vaak.

Slack heeft ook een lijstfunctie.

We hebben eerder ook een artikel geschreven over het verbeteren van werkprocessen met Slack-sjablonen.

Eenvoudig beginnen met digitale transformatie via Slack-sjablonen | Topics | Liberogic Inc.

Maar meldingen van threads zijn lastig te volgen, en als je meldingen koppelt, raakt het berichtenvenster al snel overvol.

Uiteindelijk

wordt alleen het chatvenster steeds drukker.

Met AI maken we landingspagina's vele malen sneller, maar de manier waarop we ze beoordelen is nog hetzelfde gebleven.

Het is zonde als het genereren sneller gaat, maar de review daarna alsnog vastloopt.

Daarom bedachten we het volgende.

Waarom schrijven we dan niet gewoon commentaar direct in de HTML?

Terwijl ik aan een landingspagina werkte, kwam ik ineens op een idee.

Zou het niet handig zijn als je direct commentaar kunt plaatsen op de HTML van een prototype dat met AI is gemaakt? En als je opmerkingen en bijgevoegde afbeeldingen samen in een ZIP-bestand kunt zetten en die ongewijzigd kunt doorgeven aan AI-tools zoals Claude Code of Codex, zou dat toch ook prettig zijn?

Schermafbeeldingen voorzien van rode aantekeningen is ook duidelijk, maar als je de HTML zelf kunt beoordelen,

de geklikte plek
het CSS-selector van het doelelement
de tekst in de buurt
paginanaam
de bijgevoegde referentieafbeelding

kun je ook samen met de feedback opslaan.

Met andere woorden:

In plaats van "Fix dit" kun je zeggen: "Pas dit HTML-element zo aan."

Dit lijkt ook goed te werken wanneer je AI vraagt om wijzigingen door te voeren.

"Dit is best handig, toch?"

Zo begon het maken van

Design Marker (LP-feedbackchecker)

Gewoon even geprobeerd

De eerste versie was een lokale app die op mijn eigen computer draaide.

Het gebruik is eenvoudig.

Zet de volledige HTML-set in een ZIP
Sleep naar Design Marker
Bekijk de HTML in de ZIP direct in de browser
Klik op een plek die je wilt beoordelen
Schrijf een opmerking
Exporteer een beoordelings-ZIP met de opmerkingsinformatie erin
Geef het door aan AI-tools zoals Claude Code of Codex om het te laten corrigeren

Net alsof je met een rode pen op een screenshot tekent, kun je direct in de HTML commentaar geven.

Als we dit vroeger zouden moeten bouwen, hadden we er misschien wel dagen mee bezig geweest.

Terwijl we aan het bouwen waren,

een overzicht van opmerkingen, namen van verantwoordelijken, springen naar de opmerkingspositie, afbeeldingen toevoegen, het samenvoegen van meerdere beoordelingen...

"Dit wil ik ook" en "dat wil ik ook", zo kwamen er steeds meer functies bij.

Vanaf dat moment,

Dit is eigenlijk gewoon handig als interne tool, toch?

En zo gaat het stilaan steeds verder.

De samenwerking met AI werkte beter dan verwacht

Bij het bouwen van Design Marker voelde de samenwerking met AI als het sterkste resultaat.

Wanneer je in een gewone chat om aanpassingen vraagt,

"Maak de afbeelding linksboven een beetje groter"

is zo'n instructie vaak wat je krijgt.

Mensen die samen naar een scherm kijken, begrijpen dat meestal wel, maar voor een AI is het onduidelijk waar "linksboven" precies ligt en welk element met "afbeelding" wordt bedoeld.

Met Design Marker kun je vanuit het HTML-element dat je aanklikt, bijvoorbeeld een CSS-selector ophalen zoals deze.

article.strength-item:nth-of-type(1)
 > div.strength-visual-wrap
 > div.illustration-slot

Die wordt dan aan de AI doorgegeven:

Vergroot de illustratie in article.strength-item:nth-of-type(1) tot ongeveer 115% van de huidige grootte.

U kunt dit als volgt aangeven.

Zolang de DOM-structuur niet sterk is veranderd, kan het te wijzigen element vrij precies worden bepaald.

Daarnaast kunt u ook de paginanaam, nabijgelegen tekst, opmerkingen en referentieafbeeldingen meegeven.

Tot nu toe,

Nee, nee, niet daar!

Wijzigingen waarvoor ik de AI meerdere keren moest corrigeren, komen nu steeds vaker in één keer precies op de juiste plek terecht.

"Reviewen in HTML" lijkt heel goed te passen bij het AI-tijdperk, toch?

Hier merkte ik dat dit echt werkt.

Na het intern delen met de gedachte "Dit is handig!" was het resultaat

Oké.

Dit is handig.

Laten we het ook de anderen laten gebruiken.

Vol enthousiasme deelde ik het binnen het bedrijf.

Toen...

Werkt het niet? Wat nu, is het mijn instelling?

Oh...

Ja, dat klopt.

Op mijn computer werkt het.

Maar,

Het werkt niet zomaar op andermans computer.

Netjes ingepakt in de typische valkuilen van lokale apps.

Ik kan het gebruiken. Maar anderen kunnen het niet gebruiken.

Ik ben degene die het ontwikkelt, dus natuurlijk werkt het bij mij.

Maar voor anderen was het nodig om Node.js te installeren en afhankelijke pakketten voor te bereiden.

Voor wie gewend is aan ontwikkelen, is dat niet zo moeilijk.

Maar voor ontwerpers en projectleiders,

installeer eerst Node.js

een reviewapp die begint met uitleggen.

...Dit is dan niet langer een eenvoudige reviewapp.

Dus,

"Dan kan het toch gewoon met één klik starten!"

Dat dacht ik, en ik heb ook een opstartbestand gemaakt: start-mac.command.

Wanneer je erop dubbelklikt,

start het Terminal, voert het de nodige voorbereidingen uit, start de app en opent zelfs de browser.

Prima. Perfect.

...dacht ik.

Als ik er rustig over nadenk,

"Dubbelklik op dit onbekende .command-bestand"

is zo'n instructie ook best wel griezelig.

Je stuurt je baas een bericht van 'Dubbelklik hier maar even op!' en dan denk je... Dit ziet er verdacht uit. Terwijl ik het zelf heb gemaakt, en het toch verdacht lijkt.

Het werkte wel, maar het werd niet de definitieve versie die we intern wilden delen.

Terwijl je samen met AI een app bouwt,

"Het werkt op mijn eigen computer, maar andere mensen kunnen het niet gebruiken"

Een muur die ontwikkelaars blijkbaar goed kennen, en waar je gewoon gewoon tegenaan loopt.

Het advies van een senior engineer

Toen gaf een senior engineer me een tip.

Schrijf een README en zeg dan gewoon: "Laad de map in Claude Code en stel alles in volgens de README".

……

Ik probeerde het handiger te maken door van alles in de app zelf op te lossen, maar voor mensen die AI kunnen gebruiken was dat veel eenvoudiger.

In plaats van alles in de app zelf op te lossen,

Ik denk na over de makkelijkste manier, ook voor de gebruikers en de AI.

Ook dit was weer een leerzame ervaring.

Maar de baas schrijft geen reactie...

Ik heb ook een README gemaakt.

Ik heb de manier om het op te starten ook eenvoudiger gemaakt.

Dit moet lukken.

...dacht ik.

Maar toen.

Geen enkele reactie.

Baas, je bent vast druk, dus ik hoop dat je even tijd voor me hebt...

Hier merkte ik nog iets belangrijkers op.

Het is veel moeilijker om ervoor te zorgen dat mensen het gebruiken dan om een reviewapp te bouwen.

Ervoor zorgen dat mensen het gebruiken

is vele malen moeilijker.

Hoe handig je het ook lokaal maakt,

"de app starten"

is de eerste stap die nodig is.

Voor drukke mensen is zelfs die ene stap al een drempel.

Dan dan...

Dan maar via het web

Zou het niet al bruikbaar zijn als je gewoon een URL kunt openen en het gebruiken?

Met die gedachte heb ik besloten een webversie van Design Marker te maken.

Voorlopig bouw ik eerst de pagina vóór de inlog om mezelf te motiveren.

Ik wil nog veel uitwerken, maar er is nog veel om over na te denken, dus voor nu is het een landingspagina gemaakt met AI.

Ik heb nagedacht over de backend. Daarvoor heb ik gekozen voor Cloudflare.

Toch ben ik ontwerper.

Cloudflare Pages、Pages Functions、Cloudflare Access、D1、R2……。

Ik had wel van deze namen gehoord, maar het was de eerste keer dat ik zelf de architectuur bedacht en een webapplicatie ermee bouwde.

Vanaf hier is het tijd voor de AI-leraar.

Ik wil een beheerpaneel voor intern gebruik en een beoordelingspagina die ik met klanten kan delen.

Voor het beheerpaneel is er de mogelijkheid om Cloudflare Access te gebruiken.

Wat met opmerkingen en projectinformatie?

Je kunt het opslaan in D1

En ZIP?

Er is een manier om R2 te gebruiken

Aha. Ik denk dat ik alles begrijp!

...Dat denk ik maar.

AI is echt briljant.

Als je het vraagt, geeft het zelfs een vrij concrete opzet.

Tijdens deze ontwikkeling viel me echter vooral op dat

AI kan je vertellen hoe iets werkt, maar dat betekent niet dat je er een veilig systeem mee bouwt

Zo was het, kort gezegd.

Van "Leg het me alstublieft uit" naar "Klopt dit begrip zo?"

Vooral bij onderdelen die met beveiliging te maken hebben, is het eng om alleen op het antwoord van de AI te vertrouwen.

Daarom heb ik besloten de delen die ik niet begrijp of die belangrijk zijn, te laten nakijken door een senior engineer.

Vroeger zou ik

Ik wil dit soort dingen doen met Cloudflare. Hoe pak ik dat aan?

vanaf daar gevraagd hebben, denk ik.

Maar dan moet mijn senior alles weer helemaal van nul uitleggen.

Terwijl die het al druk heeft,

"Senior! Leg het me alstublieft helemaal vanaf het begin uit!"

is het alsof je met de kop door de muur gaat.

Deze keer heb ik eerst door meerdere rondes met de AI heen en weer gepraat om het voor mezelf op een rijtje te zetten.

En daarna

Het beheerscherm is beperkt tot interne teamleden via Cloudflare Access. Het gedeelde scherm is toegankelijk via een URL per project, met ID en wachtwoord. Projectinformatie en opmerkingen worden opgeslagen in D1, en het volledige ZIP-bestand van de landingspagina in R2. Klopt deze opvatting?

En pas toen ik het zo ver had uitgewerkt, heb ik om advies gevraagd.

Met andere woorden:

"Kunt u mij alstublieft vertellen"

in plaats van

"Klopt deze opvatting?"

geworden.

Voor mezelf was dit een heel grote verandering.

Er was minder heen-en-weer met senioren, zodat je tijd kon besteden aan de punten die echt controle nodig hadden.

Ook ik kopieerde het AI-antwoord niet zomaar en was ermee klaar, maar ik

"waarom doen we het zo?"

begon stap voor stap te begrijpen en zo verder te komen.

Toen ik het naar het web bracht, wachtte er een nieuwe muur

Zo werkte de webversie stukje bij beetje steeds beter.

Je kunt het openen met een URL.

Het is veel gebruiksvriendelijker dan een lokale app.

"Is dit dan niet gewoon opgelost?"

...dacht ik.

Zodra ik het naar het web bracht, kwamen er in één keer problemen naar boven waar ik bij de lokale versie nauwelijks bij stilstond.

Neem bijvoorbeeld

Mogen we de niet-gepubliceerde landingspagina's van klanten in de cloud opslaan?
Wie kan welk project bekijken?
Hoe worden wachtwoorden beschermd?
Hoe voorkomen we ongeautoriseerde inlogpogingen?
Kunnen geüploade HTML-bestanden veilig worden weergegeven?
Wanneer verwijderen we de gegevens na afloop van een project?

enzovoort.

Een inlogscherm toevoegen betekent niet dat de beveiliging daarmee compleet is.

Dat klinkt vanzelfsprekend, maar pas toen ik het zelf bouwde, besefte ik hoeveel werk erin zit.

Momenteel heb ik de basisfunctionaliteit geïmplementeerd, waaronder Cloudflare Access, inloggen per project en opslag in D1 en R2.

Aan de andere kant,

Er zijn nog onderdelen die we willen verbeteren voordat we het officieel openbaar lanceren, zoals een sterkere wachtwoordbeveiliging, een limiet op het aantal inlogpogingen, een gescheiden HTML-preview en regels voor het opslaan en verwijderen van gegevens.

Design Marker heeft ook een modus waarin ZIP-bestanden niet naar de cloud worden opgeslagen, maar uitsluitend in de browser worden beoordeeld.

Alleen wanneer een project in de cloud wordt gedeeld, worden de benodigde projectgegevens en ZIP-bestanden opgeslagen.

Design Marker is op dit moment nog geen officiële dienst.

We testen het momenteel vooral voor intern gebruik.

Wat we met dit project hebben gemaakt, is dus

"een volledig veilige dienst is af!"

niet. Dat is het niet.

Integendeel,

een app waarin we leren welke zaken beschermd moeten worden en de nodige maatregelen stap voor stap implementeren

Een website bouwen betekent niet alleen dat het handiger wordt.

Er komt ook de verantwoordelijkheid bij om de gegevens van gebruikers te beheren.

Dit heeft me tijdens dit project veel geleerd.

Dit is het voltooide beheerscherm van de designmaker.

Via het dashboard kunnen medewerkers alle feedbackcontroles bekijken.

Op de detailpagina kun je via snelkoppelingen naar de structuurvoorstellen gaan, waarna je de landingspagina direct kunt bekijken en er opmerkingen bij kunt plaatsen.

Vervolgens kun je de opmerkingen bij de landingspagina bekijken. Je kunt ook eerdere opmerkingen raadplegen, waardoor het aanpassen van de structuur soepeler verloopt.

Ook met AI bleef leren noodzakelijk

Tijdens deze ontwikkeling merkte ik nog iets anders op.

Dankzij AI is het voor ontwerpers veel makkelijker geworden om zich aan ontwikkeling te wagen dan voorheen.

Ik persoonlijk,

"Ik wil dit bouwen"

is het bereik van wat je kunt maken, van idee tot een werkend product, duidelijk groter geworden.

Maar dat,

"Je hoeft niet meer te studeren"

betekende niet wat ik dacht.

Het was juist het omgekeerde.

Deze opzet raden we aan

Begrepen!

is niet genoeg. Dat is riskant.

Wat echt nodig is,

"Waarom?" "Is dat dit keer ook weer goed?" "Mist er niets?" "Zullen we dit deel toch even laten controleren door een expert?"

bleek het belangrijkste inzicht te zijn.

Je hebt kennis nodig om te kunnen beoordelen of het voorstel van de AI past bij de voorwaarden van deze opdracht en wat er ontbreekt.

AI is een echt betrouwbare partner.

Maar uiteindelijk moet een mens beslissen en verantwoordelijkheid nemen.

De webversie van Design Marker bracht ons ook opnieuw aan het nadenken over hoe we met zulke AI samenwerken.

In het AI-tijdperk verandert misschien het meest het reviewen

AI maakt in enkele minuten een landingspagina.

Een eerste concept dat vroeger uren kostte, verschijnt nu verrassend snel.

Maar daarna, bij wat er daarna gebeurt,

"Doe dit zo" "Maak die witruimte wat ruimer" "Verander alleen deze afbeelding"

Dit soort heen-en-weer is verrassend genoeg al lange tijd hetzelfde.

Alleen de snelheid van het maken is omhooggegaan,

Een mens controleert het, geeft aan wat er moet worden aangepast, en laat het daarna opnieuw maken.

Dit deel is nog steeds erg menselijk.

Daarom denk ik dat het de laatste tijd

niet alleen om de AI zelf gaat,

maar ook om hoe AI en mensen met elkaar communiceren

een systeem dat steeds belangrijker wordt.

Design Marker is een van die experimenten.

Momenteel worden de gegevens opgeslagen in

We testen onder andere opmerkingen in HTML, het toevoegen van afbeeldingen, het samenvoegen van meerdere reviews en versiebeheer per project.

Er staan nog heel veel dingen op ons lijstje om te doen.

Rechtstreeks markeren op screenshots zelf.

Wijzigingsverzoeken aan AI doen op basis van opmerkingen.

Betere vergelijking tussen versies.

Een prettigere werkervaring voor reviews door meerdere personen.

En natuurlijk meer veiligheid, zoals verbeterde authenticatie, HTML-previews en gegevensbeheer.

We gebruiken het eerst intern en verbeteren het stap voor stap.

Om te beginnen,

"Ik wilde iets doen aan de Slack-berichten die voortdurend voorbijflitsen"

was het begin van een klein hulpmiddel dat we ooit even snel wilden bouwen.

Maar voordat we het wisten,

bouwden we een lokale app,

maar de directeur wilde er niet mee werken,

dus zetten we het om naar een webapp,

doken we in Cloudflare,

worstelden we met beveiliging,

raadpleegden we een senior engineer,

en uiteindelijk moesten we ook nadenken over hoe we met AI omgaan.

...Ik wilde eigenlijk gewoon een reviewapp maken, maar er kwam best veel bij kijken.

Maar het is toch een interessante verandering dat je met AI kleine ergernissen in je eigen werk nu zelf kunt omzetten in iets concreets.

Zodra ik de app zo ver heb ontwikkeld dat ik er met een gerust hart iedereen toegang toe kan geven, wil ik Design Marker graag officieel aan jullie voorstellen.

Maar eerst.

Eerst ga ik ervoor zorgen dat de directeur er een echte reactie op schrijft (haha). Maar vandaag lijkt het in elk geval een goede dag om lekker iets te drinken.