Ett releasemejl konkurrerar med allt annat i en inkorg. En banner i produkten konkurrerar med nästan ingenting: den dyker upp medan någon redan använder det ni ändrat, i det ögonblick ändringen är relevant för dem. Den fördelen är lätt att slösa bort. En banner som är permanent, generell, eller visas för människor som inte kan agera på den lär alla att titta förbi sidans överkant — även den dag ni har något viktigt att säga.
Varför en ändring i produkten hör hemma inne i produkten
Releasemejl har ett strukturellt problem: det kommer när ni skickar det, inte när läsaren kan använda det. Öppningsfrekvens mäter leverans till en inkorg, inte ögonblicket då mottagaren står framför funktionen. Någon som läser om ett nytt exportalternativ på en telefon under helgen har inget sätt att prova det, och på måndag morgon ligger meddelandet flera skärmar ner.
En banner vänder på det. Den dyker upp på den sida där ändringen bor, för människor som redan arbetar, och den kan vänta på rätt sida i stället för på rätt dag. Driftvarningar, påminnelser om provperioder, prisändringar och nya funktioner delar alla den egenskapen: de går bara att agera på i sitt sammanhang, och utanför det är de bara information att arkivera.
Avvägningen är uppmärksamhet. Varje banner spenderar en liten del av kundernas förtroende för att skärmens överkant är värd att läsa. Spendera det på saker med ett beslut kopplat till sig — något att prova, något att förnya, något att känna till innan det stör dem — och låt ändringsloggen bära resten.
Skriv för beslutet, inte för releasenoteringarna
En banner har plats för en rubrik, ett par rader och en knapp, vilket räcker för precis en idé. Namnge ändringen i rubriken med kundens ord, använd brödtexten för att säga vad den betyder för dem, och lägg detaljerna bakom knappen: en post i ändringsloggen, ett dokument, en inställningssida. Att försöka pressa in en hel release i bannern är det säkraste sättet att få den avfärdad oläst.
Knappen är där ett meddelande blir användbart, så dess destination ska vara konkret: en post i ändringsloggen för en funktion, faktureringssidan för en planpåminnelse, en statussida under en incident. Länkar stannar inom er egen sajt eller pekar på en https-adress, och en knapp utan länk — eller en länk utan etikett — fångas innan meddelandet kan gå live, eftersom en halv uppmaning är sämre än ingen.
Välj vem som ser den, och var
De flesta meddelanden är inte för alla. En påminnelse om provperioden är för befintliga användare snarare än anonyma besökare, och en ändring i kassaflödet betyder något på kassasidorna. Målgrupp och sidsökväg smalnar räckvidden, medan en kort fördröjning hindrar bannern från att komma innan sidan satt sig. Planerat underhåll är det ärliga undantaget: det går oftast till alla, på varje sida, omedelbart.
Schemaläggning täcker de meddelanden ni planerar snarare än reagerar på. Ett meddelande satt till ett datum och klockslag börjar levereras när det ögonblicket kommer, så en driftnotis kan skrivas på tisdagen och visas på fredagsmorgonen, och en lanseringsbanner kan förberedas tillsammans med releasen i stället för att kommas ihåg en timme efter den.
Publicera, pausa och pensionera
En banner är ett utkast medan ni skriver den och live när ni publicerar den. Varje person ser den en gång, vilket är vad som hindrar ett meddelande från att bli en permanent inventarie: dess räckvidd är antalet skilda personer som sett den, inte en räkning av visningar. När nyheten slutar vara nyhet, pausa den — texten, målgruppen och schemat ligger kvar, så samma meddelande kan återanvändas till nästa release eller raderas när ni är säkra.
Att pensionera meddelanden i tid är en vana värd att upprätthålla. En banner som överlever sin nyhet är huvudskälet till att folk slutar läsa banners alls. Ge varje meddelande ett slutvillkor när ni publicerar det — ett datum, en release, en avslutad migrering — och pausa det då, även om det fortfarande samlar klick.
En kort checklista innan du publicerar ett meddelande
Besvara tre frågor innan ni skriver ett ord. Vem kan agera på den här ändringen, på vilken sida är de när de kan agera, och vad ska de göra härnäst? Svaren blir målgruppen, sidregeln och knappen. Saknar den tredje frågan svar hör meddelandet troligen hemma i ändringsloggen snarare än överst på allas skärm.
Skriv texten mot det utrymme ni faktiskt har. En rubrik som namnger ändringen, en eller två rader om vad den betyder, en knapp med en konkret destination. Läs tillbaka det som någon som aldrig sett er färdplan: interna namn, versionsnummer och projektkodord är det snabbaste sättet att tappa en läsare som annars hade brytt sig.
Bestäm slutet före början. Skriv in slutvillkoret i meddelandets namn — ”till 15 augusti”, ”tills migreringen är klar” — så att den som går igenom listan nästa månad vet om det fortfarande bör vara live. Att pausa bevarar allt för återanvändning, vilket gör ett återkommande meddelande som planerat underhåll till en fråga om att redigera datum snarare än att skriva om text.
Vanlig fråga
Ska jag skicka ett releasemejl eller visa en banner i produkten?
De besvarar olika frågor. E-post når människor som inte använder produkten just nu och passar sammanfattningar, färdplaner och nyheter kunder kan läsa i sin egen takt. En banner når människor som redan är i produkten och passar ändringar som går att agera på direkt, som en ny funktion på den sida där den bor, en provperiod som tar slut, eller planerat underhåll. Större lanseringar förtjänar oftast båda, där bannern pekar på detaljerna snarare än upprepar dem.