Het verhaal over hoe berichten van de CEO door Slack kwamen en we een AI review-webapp bouwden, maar toen kwam een ander probleem

~ Een designer creëerde een geverifieerde webapplicatie met AI en Cloudflare ~

Hallo. Ik ben Hasshi, UI-designer.

Tegenwoordig is het veel vaker voorgekomen dat we AI gebruiken om mockups van landingspagina's en websites te maken en deze ter controle aan cliënten voorleggen, in plaats van wireframes te tekenen en die ter controle in te dienen.

Tot voor kort stuurden we ontwerpfeedback via Slack:

"Maak hier meer witruimte!" "Vervang deze afbeelding!" "Wijzig de tekst hier!"

Zó kregen we opmerkingen.

Op het eerste gezicht een normale werkwijze.

In feite hadden we er tot nu toe geen grote problemen mee.

Maar sinds we met AI steeds meer prototypes gaan maken, is er een bepaald probleem opvallender geworden.

Opmerkingen stromen voorbij.

Slack is handig.

Het is handig, maar zoals je zou verwachten is het geen tool die speciaal voor design reviews is ontworpen.

Reguliere werkberichten, toevallige gesprekken, vragen over andere projecten – alles stroomt naar dezelfde plek.

Als gevolg daarvan

• correctiecommentaar verdwijnt in ander gesprek
• threads schieten alle kanten op
• je denkt: "waar was die aanpassing ook alweer?"
• het onderwerp verandert ongemerkt van richting

Dit soort dingen gebeurt.

Slack heeft ook een lijstfunctie.

Ik heb eerder ook een artikel geschreven over procesverbetering met behulp van Slack-sjablonen.

Aan de slag met Slack-sjablonen voor eenvoudige DX | Topics | Liberogic

Maar meldingen voor threads zijn onduidelijk, en als je meldingen integreert, wordt het berichtenveld rommelig...

Uiteindelijk

het chatkanaal wordt steeds drukker.

De snelheid waarmee AI landingspagina's maakt is vele malen toegenomen, maar de beoordelingsmethode bleef onveranderd.

Zelfs als het genereren sneller gaat, als de revisie daarna een bottleneck wordt, lijkt het zonde.

Dus dacht ik:

Waarom niet rechtstreeks commentaar in de HTML schrijven?

Terwijl ik aan een landingspagina werkte, dacht ik plotseling.

Zou het niet handig zijn om opmerkingen rechtstreeks in de HTML van een AI-gegenereerd prototype te schrijven? Bovendien, als we opmerkingen en bijgevoegde afbeeldingen in een ZIP-bestand kunnen bundelen en dat rechtstreeks aan AI-tools zoals Claude Code of Codex kunnen doorgeven, zou dat super efficiënt zijn!

Rode opmerkingen op schermafbeeldingen zijn duidelijk, maar het zou veel beter zijn om de HTML zelf te kunnen beoordelen.

• De plaats waar u klikte
• CSS-selector van het doelelement
• Tekst in de buurt
• Paginanaam
• Bijgevoegde referentieafbeelding

en dergelijke kunnen ook tegelijk worden opgeslagen.

Met andere woorden:

In plaats van 'maak dit aan', kunt u zeggen: 'verander dit HTML-element op deze manier'.

Dit lijkt ook goed samen te werken wanneer u AI om correcties vraagt.

"Dit is behoorlijk handig, niet?"

En zo begonnen we met het maken ervan,

Design Marker (LP-redmarkeringschecker)

.

Even snel een eerste versie gemaakt

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

Het gebruik is eenvoudig.

1. Zet alle HTML-bestanden in een ZIP-bestand
2. Sleep het naar Design Marker
3. Bekijk de HTML uit het ZIP-bestand in de browser
4. Klik op de plaats die je wilt aanduiden
5. Een opmerking schrijven
6. Exporteer een review-ZIP met opmerkingsinformatie
7. Verstuur naar AI zoals Claude Code of Codex voor correcties

U kunt rechtstreeks opmerkingen toevoegen aan HTML, net als het trekken van rode lijnen op een schermafbeelding.

Wat zou dit vroeger veel tijd hebben gekost als we dit hadden willen maken.

Terwijl we aan het ontwikkelen waren,

Opmerkingenlijst, namen van verantwoordelijken, springen naar opmerking locaties, afbeeldingen toevoegen, meerdere reviews samenvoegen…….

Gaandeweg dachten we "dit willen we ook" en "dat willen we ook" en groeide de functionaliteit langzaam.

Vanaf dit moment,

Dit… is dit niet gewoon heel handig als intern hulpmiddel?

En zo begint het steeds enthousiaster te worden.

De compatibiliteit met AI was beter dan verwacht

Bij het maken van Design Marker was de integratie met AI het meest indrukwekkend.

Bij een gewoon chatverzoek om aanpassingen,

"Maak de afbeelding linksboven alstublieft iets groter"

zoiets is meestal het geval.

Mensen begrijpen dit intuïtief terwijl ze naar het scherm kijken, maar voor AI is het onduidelijk waar "linksboven" is en welk element de "afbeelding" is.

Met Design Marker kun je van het HTML-element waarop je klikt bijvoorbeeld een CSS-selector als deze ophalen.

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

Dan kun je aan AI communiceren:

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

kunt u op deze manier aangeven.

Als de DOM-structuur niet drastisch is veranderd, kunt u het te corrigeren onderdeel vrij nauwkeurig identificeren.

U kunt ook paginanaam, nabijgelegen tekst, opmerkingen en referentieafbeeldingen tegelijk doorgeven.

Tot nu toe

Nee, nee, dat is het niet!

en tegen AI moest zeggen, worden nu vaak in één keer op de juiste plek aangebracht.

"HTML beoordelen" lijkt behoorlijk goed overeen te komen met het AI-tijdperk, niet waar?

Hier voelde ik echt vooruitgang.

Omdat ik dacht "Dit is handig!", heb ik het met het team gedeeld.

Prima.

Dit is erg handig.

Laten we dit ook met iedereen delen.

Ik deelde dit enthousiast met het team.

Maar toen...

Het werkt niet? Ligt het aan mijn instellingen?

O nee...

Ja, dat klopt.

Op mijn computer werkt het prima.

Maar...

Het werkt niet zomaar op elke computer.

Een klassiek probleem met lokale applicaties, waar we recht op af gaan.

Ik kan het gebruiken. Maar anderen kunnen het niet.

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

Maar voor anderen was het nodig om Node.js te installeren en alle afhankelijke pakketten in te stellen.

Voor wie aan ontwikkeling gewend is, is dit niet echt moeilijk.

Maar voor ontwerpers en projectleiders:

Installeer eerst Node.js

— een review-applicatie waarmee je moet beginnen.

……Dan is het geen eenvoudige review-applicatie meer.

Daarom

"Waarom maken we het niet zo dat het met één klik start!"

dacht ik, en maakte ik ook een startbestand genaamd start-mac.command.

Na dubbelklikken

start de terminal op, voer de nodige voorbereidingen uit, start de app op en opent zelfs de browser.

Prima. Perfect.

...of dat dacht ik tenminste.

Als ik er rationeel over nadenk,

"Dubbelklik alstublieft op dit onbekende .command-bestand"

als instructie is eigenlijk best eng.

Dus ik stuur dit naar de directeur met 'Dubbelklik hier en het werkt!'? Dat voelt raar. En ik heb het zelf gemaakt.

Oké, het werkt technisch, maar het werd niet de echte versie die we intern gebruiken.

Wanneer je een app maakt samen met AI,

'Het werkt op mijn machine, maar niemand anders kan het gebruiken'

Dat is een typische ontwikkelaarshobbel die je gewoon tegenkomt.

Een tip van een ervaren ontwikkelaar

Op dat moment gaf een ervaren ontwikkelaar me een tip.

Maak een README, 'Laad de map in Cloudflare's Cloud Code en volg de instructies in de README' Dat zou veel beter werken, toch?

……

Ik had alles ingewikkelder gemaakt om het handiger te maken, maar voor iemand die AI kan gebruiken was dit veel simpeler.

In plaats van alles aan de app-kant op te lossen,

Denken aan de gemakkelijkste manier voor gebruikers en AI samen.

Dit was ook een leerzame ervaring.

Maar de directeur schrijft geen commentaar.

Ik heb ook een README gemaakt.

Ik heb de opstartmethode ook vereenvoudigd.

Dit zou moeten werken.

...dacht ik.

Maar toen.

Geen reactie.

De directeur is waarschijnlijk druk bezig en let niet op mij...

Hier realiseerde ik me iets veel belangrijkers.

Het is veel moeilijker dan alleen een review-app maken:

mensen erbij betrekken

is vele malen ingewikkelder.

Hoe gebruiksvriendelijk je het ook lokaal maakt,

"de app starten"

is die eerste stap nodig.

Voor drukke mensen wordt zelfs die stap al een drempel.

Dus dan…

laten we het web gebruiken.

Als je alleen op een URL hoeft te klikken, zouden mensen het misschien wel gebruiken?

Met dat in gedachten besloten we een webversie van Design Marker te maken.

Eerst maken we een pagina vóór inloggen om onze motivatie op te bouwen.

Ik wil veel bouwen, maar er zijn veel dingen om over na te denken, dus voorlopig is het een AI-gegenereerde landingspagina.

Ik dacht na over wat ik achter de schermen zou doen. Daarvoor koos ik Cloudflare.

Maar toch ben ik een ontwerper.

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

Hoewel ik de naam ervan had gehoord, was het voor het eerst dat ik zelf de architectuur bedacht en het als webapplicatie bouwde.

Vanaf hier is het moment voor onze AI-leraar.

Ik wil een beheerscherm voor intern gebruik en een reviewscherm om met klanten te delen.

Voor het beheerscherm is er een optie om Cloudflare Access te gebruiken.

Wat met opmerkingen en projectinformatie?

Je kunt het opslaan in D1

Wat met ZIP?

Er is een manier om R2 te gebruiken

Begrijp ik. Ik denk dat ik alles begrijp!

...maar ik denk het maar.

AI is echt uitstekend.

Als je ernaar vraagt, vertelt het je vrij specifieke architectuur.

Wat ik echter sterk heb gevoeld in deze ontwikkeling is dat

AI je een methode kan leren en een veilig systeem bouwen zijn twee verschillende dingen

Dat was het geval.

Van 'Kunt u het me uitleggen?' naar 'Klopt deze inzicht?'

Vooral bij beveiligingskwesties ben ik bang om alleen op AI-antwoorden te vertrouwen.

Daarom heb ik besloten om onduidelijke of belangrijke delen door een senior engineer te laten reviewen.

De oude ik zou

Ik wil dit doen in Cloudflare, hoe moet ik dat aanpakken?

zou ik van daaruit vragen.

Maar dan moet mijn senior collega alles helemaal uitleggen.

Terwijl hij het druk heeft,

zei ik: 'Senior! Leg het me alsjeblieft helemaal uit!'

en tegen aan te gaan.

Dit keer heb ik mijzelf eerst georganiseerd door meerdere keren met AI van gedachten te wisselen.

En,

Het admin-paneel is beperkt tot alleen interne leden via Cloudflare Access. Het delen-scherm logt in per project met URL, ID en wachtwoord. Projectgegevens en opmerkingen worden opgeslagen in D1, de volledige LP ZIP in R2. Klopt deze inzet?

tot die stap gekomen en toen om advies gevraagd.

Met andere woorden:

"Leg het me uit"

maar in plaats daarvan,

"Klopt deze inzet?"

veranderd.

Dit was voor mij een behoorlijk grote verandering.

Minder uitwisseling met collega's nodig, zodat meer tijd kan worden besteed aan wat echt moet worden gecontroleerd.

Ik kopieer het antwoord van de AI niet zomaar en ben klaar,

"waarom doen we dit op deze manier"

en ben geleidelijk aan beter gaan begrijpen terwijl ik voortgang boek.

Toen ik naar web ging, wachtte er een ander probleem

Op deze manier begon de webversie geleidelijk aan te werken.

U kunt het openen door een URL te verzenden.

Veel gebruiksvriendelijker dan de lokale app.

"Is dit geen oplossing?"

...of dat dacht ik tenminste.

Op het moment dat ik naar web ging, kwamen problemen die ik in de lokale versie nauwelijks had opgemerkt, allemaal tegelijk naar voren.

Bijvoorbeeld:

• Mag klantdata van een openbare pre-launch LP naar de cloud worden geupload?
• Wie kan welke projecten bekijken?
• Hoe worden wachtwoorden beveiligd?
• Hoe worden ongeautoriseerde inlogpogingen voorkomen?
• Kunnen geupload HTML-bestanden veilig worden weergegeven?
• Wanneer worden gegevens na projectafronding verwijderd?

enz.

Het toevoegen van één authenticatiescherm betekent niet dat "beveiligingsmaatregelen voltooid" zijn.

Dat mag vanzelfsprekend zijn, maar pas toen ik het zelf bouwde, realiseerde ik me hoe complex het werkelijk is.

Op dit moment hebben we basismaatregelen geïmplementeerd, waaronder Cloudflare Access, projectspecifieke login en opslag in D1 en R2.

Aan de andere kant:

Er zijn nog verbeteringspunten voordat we officieel gaan lanceren, zoals versterkte wachtwoordbeveiliging, limieten voor inlogpogingen, gescheiden HTML-preview, en regels voor gegevensopslag en -verwijdering.

Design Marker heeft ook een modus waarin je ZIP-bestanden alleen in de browser kunt controleren zonder ze in de cloud op te slaan.

We slaan projectinformatie en ZIP-bestanden alleen op in de cloud wanneer projecten worden gedeeld.

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

We bevinden ons in een validatiefase met interne toepassingen.

Met andere woorden, wat we hebben gemaakt is:

"Een volledig veilige service die af is!"

Dat is het niet.

Het is eerder:

Een app waarbij we begrijpen wat we moeten beschermen en stap voor stap de nodige maatregelen implementeren

.

Het web maken is niet alleen maar gemak.

Het brengt ook de verantwoordelijkheid met zich mee om gebruikersgegevens te beheren.

Dit was echt veel leerzaam voor me.

Het beheervenster van de gemaakte designmaker.

Vanuit het dashboard kunnen werknemers alle correctieverificaties bekijken.

Als je de detailpagina opent, kun je de snelkoppelingen van de compositieschets openen en de LP direct bekijken of opmerkingen toevoegen.

Op deze manier kun je de opmerkingen die op de LP zijn geschreven bekijken. Je kunt ook eerder gemaakte opmerkingen raadplegen, dus het herzien van de compositie is veel soepeler geworden.

Zelfs met AI was leren nodig

Door deze ontwikkeling heb ik nog sterker iets gevoeld.

Dankzij AI durven ontwerpers veel gemakkelijker dan ooit eerder aan ontwikkeling.

Ik zelf,

"Ik wil dit maken"

tot iets dat daadwerkelijk werkt, is duidelijk veel breder geworden.

Maar dat betekende niet dat

"je hoeft niet meer te leren"

.

Het was juist het omgekeerde.

Deze configuratie wordt aanbevolen

Begrepen!

alleen is gevaarlijk.

Wat we echt nodig hebben, is

"Waarom?" "Is dit keer ook goed genoeg?" "Missen we niet iets?" "Zou het beter zijn als we deze onderdeel door een expert laten controleren?"

werd geacht.

Je hebt kennis nodig om te bepalen of het AI-voorstel aan de huidige voorwaarden voldoet en wat er ontbreekt.

AI is echt een betrouwbare partner.

Maar uiteindelijk zijn het mensen die de beslissing nemen en verantwoordelijkheid dragen.

De webontwikkeling van Design Marker deze keer was voor ons aanleiding om opnieuw na te denken over hoe we met AI omgaan.

In het AI-tijdperk verandert review misschien het meest

AI maakt in enkele minuten een LP voor je.

Een eerste concept dat vroeger uren kostte, wordt nu ongelooflijk snel afgeleverd.

Maar wat daarna gebeurt,

"Zet dit zo" "Maak deze witruimte iets groter" "Verander alleen deze afbeelding"

die uitwisseling is eigenlijk al heel lang niet veranderd.

alleen de snelheid van maken is toegenomen,

Mensen controleren het, vertellen wat er aangepast moet worden, en het wordt opnieuw gemaakt.

Dit deel is nog steeds behoorlijk menselijk.

Daarom denk ik tegenwoordig,

niet alleen AI zelf, maar ook

hoe AI en mensen met elkaar communiceren

dat wordt ook steeds belangrijker, denk ik.

Design Marker is een van onze experimenten daarvoor.

Nu sla ik

We testen HTML-opmerkingen, afbeeldingsbijlagen, geïntegreerde meerdere beoordelingen en versiebeheer per project.

We hebben nog veel meer dingen die we willen implementeren.

Rode aantekeningen rechtstreeks op de schermafbeelding.

Verzoeken voor AI-gestuurde correcties uit opmerkingen.

Verbeteringen in versievergelingen.

Verbeterde gebruiksvriendelijkheid voor beoordelingen met meerdere reviewers.

En uiteraard verbeterde beveiliging voor authenticatie, HTML-previews en gegevensbeheer.

We gaan het eerst intern gebruiken en geleidelijk verbeteren.

In het begin:

""Slack-berichten verdwijnen uit zicht, dus we moeten er wat aan doen""

Het was een klein hulpmiddel waarmee we aarzelend waren begonnen.

En dan realiseer je het ineens,

Een lokale app maken,

Niet door de directeur gebruikt en,

Webficatie en

Cloudflare bestuderen en

Bezorgd over beveiliging,

Raad een senior engineer in je team

We hebben zelfs moeten nadenken over hoe we met AI omgaan.

……Ik wilde eigenlijk gewoon één beoordelings-app maken. Maar er was veel meer om over na te denken dan verwacht.

Maar het is interessant om te zien hoe ik kleine ongemakken uit mijn dagelijkse werk nu samen met AI kan vormgeven.

Zodra ik het voldoende heb getest en het veilig kan vrijgeven, wil ik Design Marker graag officieel introduceren.

Maar eerst.

Eerst zorg ik dat mijn baas een fatsoenlijke opmerking schrijft (haha). Maar goed, vandaag kan ik vast genieten van een goed glas.