Hur man hanterar funktionskryp
Om något antagande är säkert är det att sex månader efter att ha startat en webbplats (eller tidigare), kommer ägarna att få en lista över saker som de vill byta från mindre typsnitt till helt ny funktionalitet.
Är det möjligt att acceptera funktionskryp som en naturlig (eller åtminstone oundviklig) process?
Många webbplatser börjar misslyckas när deras mål ändras eller deras omfattning expanderar.
Funktionskryp sätter in när en kund frågar efter en liten justering som bara tar en minut ... och slutar aldrig att göra förfrågningar.
Att acceptera funktionskryp som en naturlig process kräver en förmåga att särskilja mellan ett genuint behov och en bortvunnen fantasi eller "skulle det inte vara bra om ..."
Klienter vill naturligtvis pressa så mycket arbete från en budget som de kan. Ibland måste designers och utvecklare säga "Nej, det är bortom det vi enades om."
Men inte alla förfrågningar om förändring är penny-pinching; och som på nätet förändras projekt och företag över tiden: butikerna har säsongsförsäljning; Företag utvecklar nya produkter; Online-tjänster förfina sina processer; publikationer släpper ut nytt innehåll. Ändring sker.
Undvik lösning-krypa
Kunderna kanske känner till sin verksamhet, men de anställer webbexperter för sin webbkompetens. Feature creep sätter in när kunder glömmer det och behandlar designers som verktyg istället för problemlösare.
Att kunna förklara för alltför entusiastiska, icke-webmänniskor vilka tekniker och tekniker som inte är lämpliga för en viss webbplats är ett tråkigt krig mot slöseri.
Men designers som presenterar sig som problemlösare , och inte bara kodande apor, är avgörande för deras relationer med kunderna.
Nyckeln är att få kunden att få problem, inte lösningar. Säg att kunden lär sig om Twitter. Det är allt raseri, de berättas. Så de vill ha det. Nu.
På lång sikt kommer insatsen att skriva tweets bli frustrerande om inte tweetsna skapar mätbara fördelar. I stället fråga kunden om de behöver ett Twitter-konto som skickar in till företagsbloggen eller helt enkelt behöver bloggar av högre kvalitet?
Här är några exempel:
"Jag vill ha en livlig design" är en lösning, inte ett problem.
"Vad skulle få webbplatsen att se vibrerande?" Är ett designproblem.
"Jag vill ha ett sökverktyg" är en lösning, inte ett problem.
"Kunderna hittar inte våra produkter" är ett designproblem.
"Jag vill ha ett RSS-flöde" är en lösning, inte ett problem.
"Vilka kommunikationsmedel är besökare på vår webbplats som troligen kan förvänta och använda?" Är ett designproblem.
"Jag gillar den här andra webbplatsens design" är konkurrens-avund, inte en lösning.
"Du är inte dem", är inte heller ett tillräckligt svar.
Snarare, "Hur vill du att kunder ska uppfatta din verksamhet eller organisation?" Skulle få konversationen tillbaka på rätt spår.
Om din fråga, "Vad tycker du om den här logotypen?", Följs av obekväm tystnad, vänd sedan om med en enstaka stans: "Hur vill du att kunder ska se ditt varumärke? Vilka visuella bilder skulle dina kunder associera med dessa egenskaper? "
I varje fall kan funktionskryp hanteras genom att vrida "Jag vill" till en fråga för konstruktören , inte kunden, att lösa .
Fråga allt upp framför
Att lära sig att vara orealistiska frågor är viktigt och, med viss övning, överraskande kul.
Till exempel, när skulle en webbplats behöva mer än en hemsida? Eller vad händer om en kafé började sälja videor?
Sådana frågor verkar bara löjligt om du tänker på omedelbara problem.
Tänk på flera hemsidor. Återkommande besökare kanske inte behöver den fullständiga introduktionen som nykomlingar skulle göra. I så fall skulle en hemsida som visar senaste höjdpunkter fungera tillsammans med en hemsida som har en allmän översikt.
Googles Website Optimizer hjälper dig att spåra vilka av dina hemsidor som genererar mer meningsfull trafik.
En strategi är att tredubbla dina högsta förväntningar . Föreställ dig tre "Kontakta oss" -sidor, trettio kategorier i stället för tio, och tre nivåer av navigering istället för en. Eller hur skulle du hantera en innehållssida om den blev tre gånger så lång?
En annan strategi är att skära allt med en tredjedel. Vad händer om du vill designa webbsidor för mobila enheter? Hur kan en 960-pixel-bred design passa in i en 320 pixel bred skärm? Vad händer om webbplatsen bara genererade tio försäljningar per månad istället för en per dag? Hur förändras "Om vårt lag" -sida om personalen på 15 var skuren till 10?
Innan du signerar något kontrakt, skanna efter dessa avgörande ord: "a," "an", "den" och "en".
Innan: "Webbplatsen kommer att ha en lista över tjänster."
Efter: "Webbplatsen kommer att ha flera listor av tjänster organiserade efter ämne."
Innan: "Kontaktformuläret skickar ett mail till ägaren."
Efter: "Huvudkontaktformuläret skickar e-post till ägaren och, beroende på ämnet, anläggningskoordinator, teknisk support eller ledande säljare."
Innan: "Rubriken kommer att vara orange."
Efter: "Hemsidahuvudet kommer att vara orange. Innehåll på sidhuvudet kommer att vara halva så långa att betona innehållet. "
Innan: "Medlemskapsprofiler kommer att innehålla ett telefonnummer och en e-postadress."
Efter: "Medlemskapsprofiler innehåller kontaktuppgifter, inklusive telefonnummer (kontor, hem, annat), faxnummer, e-postadresser och tre öppna fält för adress, Twitter och Facebook-konton och liknande."
Innan: "Bloggen kommer att organiseras efter datum."
Efter: "I bloggens standardskärm visas inlägg efter datum. Inlägg kommer att organiseras med taggar; Sidan kommer att utformas så att den inte ser tom ut när den bara har fem inlägg. och besökare kommer att kunna bläddra i minst 500 inlägg. "
De bästa planerna är inte begränsade till en specifik konstruktion utan står för en rad parametrar. Problem är bara löjliga när du lämnas en vid deadline.
Äkta behov
Inget system kan ta hänsyn till varje scenario.
De flesta kan anpassa sig till små, stegvisa förändringar över webbplatsens livslängd, men när bandhjälplösningar överstiger de ursprungliga problemen är det dags att ta upp ordet som ingen klient någonsin vill höra: "ompröva".
När du börjar från början är effektivare än att fixa de förändringar som löste tidigare problem (men bröt andra saker), är det största överhoppet att övertyga alla inblandade att den drastiska förändringen nu är bättre på lång sikt.
Då behöver du ett annat ord: "kostnadseffektivt".
Patching-kod eller tweaking-layouter vädjar till designers, utvecklare och kunder eftersom det är snabbt. De kliar en klåda med minimal ansträngning. Och ju fler människor cringe på att fixa en webbplats som bryter med den minsta beröringen, desto mindre trolig kommer någon att föreslå större huvudvärk.
Men det är ett säkert tecken på att förändring är nödvändig. Drakonisk funktion kryp händer när tekniska människor och designers verkligen fruktar att göra ändringar. Du känner till projektet: den med sagans historia med sitt eget arkivskåp, med ägaren vars röst gör att människor rycker, och de ramblingprocesser som kräver användarhandböcker som ingen har tid att skriva.
Sådana projekt kostar mer än pengar. De är moraliskt tömande resurshöns som uppmärksammar uppmärksamhet från nyare, nimblerprojekt och orsakar tillräckligt med tandkörning för att bära tandläkare genom lågkonjunkturen.
Krig mot denna typ av funktionskryp börjar med att definiera problem , inklusive problemen som uppstod från de lösningar som gav upphov till symptomlösning.
Tillvägagångssätt fullständiga omprövningar genom att se långsiktigt, både i det förflutna och i framtiden. Webbplatsen var stor då, men sakerna har förändrats. Tekniken har förbättrats. Klientens produkter eller tjänster har utvecklats. Kunderna är mer (eller kanske mindre) sofistikerade eller har olika behov.
Utarbeta en plan för att göra denna övergång praktisk . Detaljerna beror på webbplatsens art, men motsvarar samma sak: övertygande klienten att den drastiska botningen inte är värre än den nuvarande tuggummi-och-bailing-wire kursen. Detta är psykologiskt krig lika mycket som det är tekniskt problemlösande.
Det kommer att hända
De flesta funktioner kryp tar två former: en kliar som en klient vill klia och ett genuint behov av förändring.
Om du kan formulera efterfrågan som en fråga placerar du dig själv som en beslutsfattare snarare än någon som följer kundens alla dåligt informerade infall.
Inse att förändringen kommer att hända. En webbplats som aldrig ändras är en svart grop.
Ben Gremillion är en frilans webbdesigner som har lärt sig att kunderna reagerar bra om du kan hålla ditt humör när de förlorar deras.
Hur hanterar du funktionskryp? Vänligen dela med dig av dina erfarenheter med oss ...