Två bokningssidor ser prydliga ut. Båda har ett datumfält och en Spara-knapp. På den första ändrar en dialogruta bokningen; på den andra öppnas en separat sida. Vilken version är bättre? En skärmdump hjälper med färger och avstånd. Den visar bara i begränsad utsträckning om människor förstår flödet.
Den 15 oktober 2026 öppnade Figma upp Code Layers som beta. Prototyper som stöds kan vidareutvecklas med kod och jämföras på den gemensamma designytan; befintlig kod kan tas in under de dokumenterade villkoren. Ur redaktionell synvinkel är det intressanta att man arbetar tillsammans med beteende. En prototyp blir därmed föremål för ett beslut i stället för att bara visa sitt snygga resultat.
Först samma uppgift, sedan olika gränssnitt
Vårt eget exempel är ett föreningsevenemang. Personen ska ändra datumet, läsa deltagarvillkoret och sedan antingen spara eller avbryta. Båda versionerna får samma titel, samma datum och samma längre anteckning. Om en version bara visade en kort platshållartitel vore jämförelsen redan snedvriden.
Dialogrutan behåller bokningsöversikten i bakgrunden. En separat redigeringssida ger mer utrymme. Det är olika designbeslut, inte kvalitetsomdömen. Det blir intressant vid övergångarna: var befinner sig personen efter att ha sparat? Vad händer med påbörjad inmatning när personen avbryter? Vilken information förblir synlig under ändringen?
En tillståndsmodell gör beteende till något man kan diskutera
Beskriv först flödet utan programmeringssyntax. Bokningen är synlig. Redigera öppnar en inmatning. Ogiltig inmatning leder till en förklaring, och de giltiga uppgifterna behålls. Spara visar det bekräftade tillståndet. Avbryt återgår till det oförändrade tillståndet. Detta är krav för vårt exempel, inte ett löfte om inbyggda funktioner i Figma.
View → Edit → Input
Input → valid → Save → Confirmation
Input → invalid → Hint + input kept
Input → Cancel → original viewMed den här lilla modellen kan varje version granskas målinriktat. Kanske ser dialogrutan utmärkt ut men tappar hjälptexten när ett fel uppstår. Kanske är den separata sidan mindre elegant men gör vägen tillbaka lättare att förstå. Bedömningen handlar då om observerbart beteende, inte om en allmän förkärlek för dialogrutor.
Återkoppling behöver en gemensam referenspunkt
En användbar kommentar lyder: ”Efter att jag avbröt kunde jag inte avgöra om mitt nya datum hade sparats.” Den anger platsen, handlingen och osäkerheten. ”Känns inte tillräckligt modernt” ger däremot ännu ingen fråga som någon kan arbeta med. När utkast och kommentarer finns på samma yta kan kopplingen till den version som granskas bevaras.
Anteckna för varje ändring vilken osäkerhet den är tänkt att undanröja. Ändra till exempel bekräftelsen först, i stället för att ändra typsnitt, färger och navigering samtidigt. Det gör det lättare att förstå varför en andra version uppfattas annorlunda. Detta är ingen kontrollerad användbarhetsstudie, men det är en vettig arbetsdisciplin för designfasen.
Beslutet går att överföra; koden gör det inte automatiskt
I slutet bör det finnas en kort överlämningsanteckning: den föredragna versionen, uppgiften den stöder, de relevanta tillstånden och de återstående frågorna. Ett interaktivt utkast med exempeldata är ännu inte en riktig bokningsplattform. Inloggning, lagrade data och faktiska behörigheter måste fungera separat i en applikation.
För ett litet tillägg på klientsidan till en KENJTEC-sida kan beslutet sedan implementeras som din egen HTML, CSS och JavaScript. I KENJTEC WebSiteBuilder ai finns ett utvecklarläge för detta, med en isolerad förhandsvisning och ett eget steg för kodpublicering. Du överför själv den relevanta komponenten; detta innebär varken en Figma-import eller hosting för valfri applikation.
Enligt den dokumenterade statusen är Code Layers fortfarande en beta. Tillgänglighet, startprojekt som stöds och villkor bör kontrolleras igen före varje konkret instruktion. Metoden håller dock oavsett verktyg: jämför inte bara två snygga skärmbilder. Jämför två spårbara svar på samma fråga om hur något används.
Källor och status
Research och dokumentation per den 25 oktober 2026. Designa tillsammans med kodlager på designytan.
