Hoe om te gaan met Feature Creep
Als een veronderstelling veilig is, is het dat zes maanden na het lanceren van een website (of eerder?), De eigenaren een lijst hebben met dingen die ze willen veranderen , van kleine typfouten tot geheel nieuwe functionaliteit.
Is het mogelijk om feature creep als een natuurlijk (of op zijn minst onvermijdelijk) proces te accepteren?
Veel websites beginnen te falen wanneer hun doelen veranderen of hun bereik wordt uitgebreid.
Feature creep wordt ingeschakeld wanneer een client vraagt om een kleine aanpassing die slechts een minuut duurt ... en daarna nooit stopt met het maken van verzoeken.
Het accepteren van feature-creep als een natuurlijk proces vereist het vermogen om een onderscheid te maken tussen een echte behoefte en een verbeelding van de fantasie of "Zou het niet geweldig zijn als ..."
Klanten willen natuurlijk zoveel mogelijk werk uit een budget persen. Soms moeten ontwerpers en ontwikkelaars zeggen: "Nee, dat is meer dan waar we het over eens waren."
Maar niet alle verzoeken om verandering zijn centenknijpen; en net als het web veranderen projecten en bedrijven in de loop van de tijd: winkels hebben seizoensgebonden verkoop; bedrijven ontwikkelen nieuwe producten; online diensten verfijnen hun processen; publicaties brengen nieuwe content uit. Verandering gebeurt.
Vermijd Oplossing-Creep
Klanten kunnen hun bedrijf kennen, maar huren webexperts in voor hun webexpertise. Feature creep komt opzetten wanneer klanten dat vergeten en ontwerpers als tools behandelen in plaats van probleemoplossers.
In staat zijn om overdreven enthousiaste niet-webmensen uit te leggen welke technieken en technologieën niet geschikt zijn voor een bepaalde website, is een moeizame uitputtingsslag.
Maar ontwerpers die zichzelf presenteren als probleemoplossers , en niet louter coderende apen, zijn essentieel voor hun relaties met klanten.
De sleutel is om de cliënt problemen te laten brengen, geen oplossingen. Stel dat de klant leert over Twitter. Het is allemaal woede, wordt hen verteld. Dus ze willen het. Nu.
Op de lange termijn zal de moeite om tweets te schrijven frustrerend zijn, tenzij de tweets meetbare voordelen opleveren. Vraag de klant in plaats daarvan of hij een Twitter-account nodig heeft dat berichten plaatst op het bedrijfsblog of gewoon blogberichten van hogere kwaliteit nodig heeft?
Hier zijn enkele voorbeelden:
"Ik wil een levendig ontwerp" is een oplossing, geen probleem.
"Wat zou de website er leuk uit laten zien?" Is een ontwerpprobleem.
"Ik wil een zoekfunctie" is een oplossing, geen probleem.
"Klanten vinden onze producten niet" is een ontwerpprobleem.
"Ik wil een RSS-feed" is een oplossing, geen probleem.
"Welke communicatiemiddelen zijn bezoekers van onze website die het meest waarschijnlijk verwachten en gebruiken?" Is een ontwerpprobleem.
"Ik hou van het ontwerp van deze andere website" is concurrentie-afgunst, geen oplossing.
"U bent niet hen", is ook geen adequate reactie.
Integendeel, "Hoe wilt u dat klanten uw bedrijf of organisatie waarnemen?" Zou het gesprek weer op het goede spoor krijgen.
Als uw vraag, "Wat vindt u van dit logo?" Wordt gevolgd door een ongemakkelijke stilte, draai het dan om met een een-tweetje: "Hoe wilt u dat klanten uw merk bekijken? Welke visuals zouden uw klanten met deze kwaliteiten associëren? "
In beide gevallen kan de feature creep worden afgehandeld door "I want" in een vraag te veranderen die de ontwerper , niet de klant, moet oplossen .
Vraag alles van voren
Leren om schijnbaar onrealistische vragen te stellen is belangrijk en, met wat oefening, verrassend leuk.
Wanneer zou een website bijvoorbeeld meer dan één homepage moeten hebben? Of wat als een coffeeshop video's gaat verkopen?
Zulke vragen lijken alleen maar belachelijk als je denkt aan onmiddellijke problemen.
Overweeg meerdere startpagina's. Terugkomende bezoekers hebben misschien niet de volledige introductie nodig die nieuwkomers zouden hebben. In dat geval zou een startpagina met recente hoogtepunten naast een startpagina met een algemeen overzicht werken.
Google's Website Optimizer helpt bijhouden welk van uw startpagina's betekenisvoller verkeer genereert.
Eén strategie is om uw hoogste verwachtingen te verdrievoudigen . Stelt u zich eens drie 'Contact'-pagina's voor, dertig categorieën in plaats van tien en drie navigatieniveaus in plaats van één. Of hoe zou u een pagina met inhoud behandelen als deze drie keer zo lang zou worden?
Een andere strategie is om alles met een derde te verminderen. Wat als u webpagina's voor mobiele apparaten wilde ontwerpen? Hoe kan een 960-pixel breed ontwerp passen in een 320-pixel breed scherm? Wat als de website slechts tien verkopen per maand genereert in plaats van één per dag? Hoe zou de pagina 'Over ons team' veranderen als het personeelsbestand van 15 werd teruggebracht tot 10?
Voordat u een contract tekent, scant u op deze cruciale woorden: "a", "een", "de" en "één".
Vóór: "De website bevat een lijst met services."
After: "De website zal verschillende lijsten met services bevatten, gerangschikt op onderwerp."
Vóór: "Het contactformulier stuurt een e-mail naar de eigenaar."
Na: "Het hoofdcontactformulier stuurt e-mails naar de eigenaar en, afhankelijk van het onderwerp, de faciliteitscoördinator, technische ondersteuning of hoofdverkoper."
Vóór: "De koptekst is oranje."
After: "De koptekst van de startpagina is oranje. Binnenste paginakopteksten zullen half zo lang zijn om de inhoud te benadrukken. "
Vóór: "Lidmaatschapsprofielen bevatten een telefoonnummer en e-mailadres."
Na: "Lidmaatschapsprofielen bevatten contactgegevens, waaronder telefoonnummers (kantoor, thuis, overig), faxnummers, e-mailadressen en drie open velden voor postadres, Twitter- en Facebook-accounts en dergelijke."
Voordien: "De blog zal worden georganiseerd op datum."
After: "Het standaardscherm van de blog toont berichten op datum. Posts zullen worden georganiseerd met tags; de pagina zal worden ontworpen om er niet leeg uit te zien als deze slechts vijf berichten heeft; en bezoekers kunnen minstens 500 berichten bekijken. "
De beste plannen zijn niet beperkt tot een specifiek ontwerp, maar houden rekening met een reeks parameters. Problemen zijn alleen maar belachelijk als je er een op de deadline wordt overhandigd.
Echte behoeften
Geen enkel systeem kan voor elk scenario rekenschap geven.
De meeste kunnen zich aanpassen aan kleine, incrementele veranderingen in de levensduur van de website, maar als oplossingen voor pleisters groter zijn dan de initiële problemen, is het tijd om het woord naar voren te brengen dat geen enkele klant ooit wil horen: "heroverwegen".
Wanneer van nul af aan beginnen efficiënter is dan het oplossen van de veranderingen die eerdere problemen hebben opgelost (maar andere dingen hebben gebroken), overtuigt de grootste hindernis iedereen die ingrijpende verandering nu beter is op de lange termijn.
Dan heb je nog een ander woord nodig: "kosteneffectief."
Patching-code of het aanpassen van lay-outs spreekt ontwerpers, ontwikkelaars en klanten aan omdat het snel is. Ze krassen een jeuk met minimale inspanning. En hoe meer mensen ineenkrimpen bij het repareren van een website die breekt met de minste aanraking, des te minder waarschijnlijk zal iemand een grotere hoofdpijn suggereren.
Maar dat is een zeker teken dat verandering noodzakelijk is. Draconische feature creep gebeurt wanneer technische mensen en ontwerpers oprecht vrezen voor het aanbrengen van wijzigingen. U kent het project: degene met de casusgeschiedenis met een eigen archiefkast, met de eigenaar wiens stem mensen doet huiveren, en de wandelprocessen waarvoor gebruikershandleidingen nodig zijn die niemand de tijd heeft om te schrijven.
Dergelijke projecten kosten meer dan geld. Het zijn moreel slopende bronnenzwijnen die de aandacht trekken van nieuwere, nimbler-projecten en genoeg tandenknarsen veroorzaken om tandartsen door de recessie te vervoeren.
Oorlog tegen dit type feature-creep begint met het definiëren van problemen , inclusief de problemen die zijn voortgekomen uit oplossingen voor het oplossen van symptomen.
Benader volledige heroverwegingen door er langdurig naar te kijken, zowel naar het verleden als de toekomst. De website was toen geweldig, maar de dingen zijn veranderd. De technologie is verbeterd. De producten of diensten van de klant zijn geëvolueerd. Klanten zijn meer (of misschien minder verfijnd) of hebben verschillende behoeften.
Bedenk een plan om deze overgang praktisch te maken . De details zijn afhankelijk van de aard van de website, maar komen op hetzelfde neer: de klant ervan overtuigen dat de drastische genezing niet slechter is dan de huidige kauw-kauwgom-draad-draadtraining. Dit is net zo goed psychologische oorlog als technische probleemoplossing.
Het zal gebeuren
De meeste functies creep neemt twee vormen aan: een jeuk dat een klant wil krabben en een echte behoefte aan verandering.
Als je de vraag als een vraag kunt formuleren , dan positioneer je jezelf als een beslisser in plaats van iemand die elke slecht geïnformeerde bevlieging van de cliënt volgt.
Realiseer je dat verandering zal plaatsvinden. Een website die nooit verandert, is een zwarte put.
Ben Gremillion is een freelance webdesigner die heeft geleerd dat klanten goed reageren als je je humeur kunt bewaren wanneer ze de hunne verliezen.
Hoe ga je om met feature creep? Deel alstublieft enkele van uw ervaringen met ons ...