Projektet är redo att lanseras. Designers är redo att designa, utvecklare redo att utveckla och...Vem ska skriva kopian? Projektägare tror bestämt att det är upp till projektteamet, mjukvaruutvecklare undrar varför de ens övervägs göra det, och UI/UX-designers rycker på axlarna. Det fanns inget om något sådant i projektplanen.
När du startar ett projekt som en ny webbplats från grunden är chansen stor att kopian ännu inte är lagd ut för teamet. Projektägaren har vanligtvis några nyckelord i åtanke, till exempel innovativ, banbrytande eller toppmodern, men inte strukturerat innehåll. Den genomgång som teamet får är till exempel att bygga en störande blockchain fintech-affärswebbplats, och de borde arbeta med allt annat därifrån.
För att förstå vem som ska skriva kopian, och med tanke på den nuvarande populariteten för upplevelser med flera slut, låt oss arbeta med några möjliga scenarier med olika slut.
För detta hypotetiska scenario antar vi att det inte är möjligt att anställa en professionell copywriter, till exempel på grund av vanliga begränsningar när det gäller budget eller projektstorlek. Det skulle i alla andra fall vara det bästa alternativet överlägset, eftersom värdet som en copywriter kan ta med till bordet i stor utsträckning överstiger alla resultat av följande möjligheter.
Med allt detta i åtanke, vem ska göra det?
Det finns alltid ett självklart val som, med tanke på dess natur, människor bara inte känner sig bekväma med att välja. Och det finns en bra anledning till det. Men eftersom projektägare kommer med idéerna skulle det vara vettigt att de borde vara ansvariga för all kopia, eller hur? Fel, åtminstone i de flesta fall.
Det betyder inte att projektägare inte kan skriva bra exemplar, men vanligtvis är de inte det bästa valet. Det sätt på vilket en projektägare ser produkten skiljer sig från synen hos en potentiell användare, och det tankesättet är ibland svårt att ändra. Uppgifter som att definiera om kopian ska vara kortare eller längre och välja ton och stil kommer att vara mycket mer fokuserade på produkten och inte på användaren.
Detta scenario leder till en produkt som kommer att gilla sig själv alldeles för mycket. Längre ner på vägen, när vikten av att engagera sig med användare och ge en fantastisk upplevelse sjunker in, måste någon annan förbättra kopian genom att skriva om den helt. Det som var tänkt att vara en tidsbesparande åtgärd kommer i slutändan att kosta mycket mer än tid.
Designers är de första som får händerna smutsiga, och när de hanterar produktens bilder kan de också frestas att hantera kopian. Den främsta anledningen är att det blir lättare att skapa ett gränssnitt om du vet att du fritt kan justera kopian till designen.
Detta är det bästa sättet att säkerställa att produkten ser bra ut, eftersom designers har total frihet över den kreativa processen i detta skede. Kopiering kommer dock att ses som ett tillbehör i den större bilden, och tiden som spenderas i den kommer att vara minimal. Följaktligen får användarna en underbar upplevelse genom abstrakta skärmar som visar poetiska och/eller vaga fraser, vilket innebär att ändra hur alla uppfattar den specifika produkten eller branschen.
Designercommunityn kanske älskar det, men användare kommer inte ens att sluta tänka på vad allt det handlar om. Webbplatsen kommer att vara som en vacker målad duk som alla berömmer utan att någonsin tänka på vad den representerar. Det kan till och med få en plats i bästa av 20XX mönster artiklar i slutet av året, men kommer inte att uppfylla något av produktägarens mål. Så småningom, någon kommer att behöva ändra sitt tillvägagångssätt eftersom wow-faktor bleknar ut.
Om det fortfarande inte finns någon kopia när designen är klar har du redan ett problem. Det är ett problem som måste hanteras ändå. Utvecklare är nästa i raden, och förmodligen de som minst vill skriva något förutom kod, men finns det något alternativ nu?
Det är irrelevant om utvecklare är redo att skriva kopian själva eller inte, eftersom det alltid kommer att vara problematiskt att försena problemet till detta stadium. Tiden att skriva kommer att vara mycket begränsad och eftersom designen redan är klar måste den anpassa sig till de befintliga gränssnitten. Variabler blir oundvikliga omständigheter och besluten kommer att vara mycket begränsade.
Allt kommer att bli snabbt gjort på ett pragmatiskt sätt, och slutresultatet kommer att vara nära vad man kan förvänta sig att uppnå genom AI. Det är inget fel med objektivitet, men produkten kan ses som trubbig och ointressant genom användarnas ögon. Det kommer att levereras med några brister som redan ska påpekas, och en andra version kommer snart att följa.
Samla alla runt bordet och börja diskutera idéer. Du kommer snart att se att det som börjar som en rolig upplevelse kommer att förvandlas till frustration, eftersom om sidan Det diskuteras fortfarande veckor djupt in i projektet. Senare bestämmer laget att det är bättre att var och en skriver lite och i slutändan kommer allt ihop. För det fungerar alltid, eller hur?
I det här fallet kopian blir en inkonsekvent massa av ilska och tvivel. Produkten kan fortfarande skickas, men utan något tydligt meddelande att prata med någon. Användare kan lära känna det, och med lite tur till och med räkna ut vad produkten handlar om och njuta av den. Det är upp till slumpen, eftersom kopian inte riktigt driver i någon riktning.
Inget bra kommer från att lämna något åt slumpen, och det kommer att vara mycket svårt att sticka ut från tävlingen. Längre ner på vägen måste produktägaren fixa röran som skapades. Det som skiljer detta alternativ från de andra är att produkten kanske inte kan överleva tillräckligt länge för att göra de nödvändiga ändringarna.
Vi är vana vid att skapa en kausalitetseffekt mellan framgång och djärva drag, men det beror på att vi bara lär oss om de djärva drag som lyckas.
I det här scenariot är det mer troligt att produkten blir designad, utvecklad och levererad. Den uppenbarligen inspirerande trenden att skicka en produkt utan förklaring av vad det är förvirrar användarna och den delas över sociala medier. Efter surret kommer det att försvinna, eftersom ingen verkligen använde det.
Företaget stänger dörrar och skulden ska delas mellan alla inblandade i projektet. Ingen är nöjd med det.
I detta hypotetiska scenario där det ideala alternativet att anställa en professionell författare inte är en möjlighet, är svaret, så osannolikt som det kan verka,: något av de tre första alternativen. Det som gör skillnaden i copywriting är tillvägagångssättet, och inte personen som slutar göra det. Även om det vanligtvis inte ses lika viktigt som design eller utveckling, är kopian viktig. Det som händer för det mesta är dock att det bara staplas ovanpå de andra uppgifterna och rusas ut i slutändan.
Det vanliga misstaget som markerades i alternativen ovan är att kopia ses som en börda och en tillbehörsuppgift som så småningom kommer att bli klar. Kopiering är dock en avgörande punkt som måste övervägas i projektplanen redan från början. Vem som helst kan göra det, men det är ingen lätt uppgift.
Affärskunskap och en god förståelse för användarupplevelse är båda viktiga, men för att skriva övertygande kopia måste man göra en mycket mer grundlig forskning. En process som Persona-metoden är idealisk för att förstå vem projektet riktar sig till, och för att skapa den perfekta dialogen med användarna. Det tar tid och resurser, men det finns inget sätt att kringgå det.
Konsekvenserna av dålig kopia kanske inte alltid är lika tragiska som de som nämns här, men det är ett misstag att tro att det inte finns några konsekvenser alls. Kopiera representerar historien som du vill berätta, och det är det som stannar kvar i användarnas sinne efter att de använder en produkt för första gången. Oavsett hur bra det kan vara.
Tyckte den här artikeln intressant? Du kanske gillar dessa också!
Innehållshanterare, textredigerare, och presentatör av strategiska idéer, tillsammans med att vara en ivrig beundrare av filmkonst och visuellt berättande.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
%20(1).webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
