Hvordan håndtere Feature Creep
Hvis noen antagelser er trygge, er det at seks måneder etter at du har startet et nettsted (eller tidligere?), Vil eierne få en liste over ting de vil bytte , fra mindre typoer til helt ny funksjonalitet.
Er det mulig å godta funksjonskryp som en naturlig (eller i det minste uunngåelig) prosess?
Mange nettsteder begynner å mislykkes når deres mål endres eller deres omfang utvides.
Funksjonskryp setter inn når en klient ber om en liten justering som tar bare et minutt ... og slutter aldri å stille forespørsler.
Å godta funksjonskryp som en naturlig prosess krever en evne til å skille mellom et ekte behov og en bortvunnet fantasi eller "Ville det ikke vært bra hvis ..."
Klienter vil naturligvis klemme så mye arbeid fra et budsjett som de kan. Noen ganger må designere og utviklere si: "Nei, det er utenfor det vi enighet om."
Men ikke alle forespørsler om endring er penny-pinching; og som på nettet, endres prosjekter og bedrifter over tid: butikkene har sesongbasert salg; bedrifter utvikler nye produkter; Internett-tjenester forbereder sine prosesser; Publikasjoner slipper ut nytt innhold. Endring skjer.
Unngå Solution-Creep
Klienter kan kjenne sin virksomhet, men de ansetter webeksperter for sin webkompetanse. Feature kryp setter inn når klienter glemmer det og behandler designere som verktøy i stedet for problemløsere.
Å være i stand til å forklare for altfor entusiastiske, ikke-web-folk, hvilke teknikker og teknologier som ikke er hensiktsmessige for et gitt nettsted, er en kjedelig forsømmelseskrig.
Men designere som presenterer seg som problemløsere , og ikke bare kodende aper, er avgjørende for deres forhold til klienter.
Nøkkelen er å få klienten til å bringe problemer, ikke løsninger. Si at klienten lærer om Twitter. Det er alt raseri, de blir fortalt. Så de vil ha det. Nå.
I det lange løp vil innsatsen for å skrive tweets bli frustrerende med mindre tweets skaper målbare fordeler. I stedet spør kunden om de trenger en Twitter-konto som legger inn i bedriftens blogg eller bare trenger blogger av høy kvalitet?
Her er noen eksempler:
"Jeg vil ha en levende design" er en løsning, ikke et problem.
"Hva ville gjøre nettstedet ser levende ut?" Er et designproblem.
"Jeg vil ha et søkeverktøy" er en løsning, ikke et problem.
"Kunder finner ikke våre produkter" er et designproblem.
"Jeg vil ha en RSS-feed" er en løsning, ikke et problem.
"Hva betyr kommunikasjon er besøkende på nettstedet vårt mest sannsynlig å forvente og bruke?" Er et designproblem.
"Jeg liker dette andre nettstedets design" er konkurranse-avund, ikke en løsning.
"Du er ikke dem", er heller ikke et tilstrekkelig svar.
Snarere, "Hvordan vil du at kundene skal oppfatte din bedrift eller organisasjon?" Ville få samtalen tilbake på sporet.
Hvis spørsmålet ditt, "Hva synes du om denne logoen?" Etterfølges av ubehagelig stillhet, så snu den med en en-to slag: "Hvordan vil du at kundene skal se merkevaren din? Hvilke visuelle bilder vil kundene dine knytte til disse egenskapene? "
I hvert tilfelle kan funksjonskrysset håndteres ved å snu "Jeg vil" til et spørsmål for designeren , ikke klienten, for å løse .
Spørsmål Alt opp foran
Å lære å spørre tilsynelatende urealistiske spørsmål er viktig og, med litt praksis, overraskende morsomt.
For eksempel, når ville et nettsted ha behov for mer enn en hjemmeside? Eller hva om en kaffebar begynte å selge videoer?
Slike spørsmål synes bare latterlig hvis du tenker på umiddelbare problemer.
Vurder flere hjemmesider. Tilbakevendende besøkende trenger kanskje ikke den fulle introduksjonen som nybegynnere ville. I så fall vil en hjemmeside som viser nyere høydepunkter fungere sammen med en hjemmeside som har en generell oversikt.
Googles Nettstedoptimereren hjelper med å spore hvilke av hjemmesidene dine som genererer mer meningsfull trafikk.
En strategi er å tredoble dine høyeste forventninger . Tenk på tre "Kontakt oss" -sider, tretti kategorier i stedet for ti, og tre nivåer av navigering i stedet for en. Eller hvordan ville du håndtere en innholdsside hvis den ble tre ganger så lang?
En annen strategi er å kutte alt med en tredjedel. Hva om du ønsket å designe nettsider for mobile enheter? Hvordan kunne et 960-pixel bredt design passe inn i en 320 pixel bred skjerm? Hva om nettstedet kun genererte ti salg per måned i stedet for en per dag? Hvordan endret "Om vårt lag" side hvis personalet på 15 ble kuttet til 10?
Før du signerer noen kontrakt, skann etter disse avgjørende ordene: "a," "an", "den" og "en".
Før: "Nettstedet vil få en liste over tjenester."
Etter: "Nettstedet vil ha flere lister over tjenester organisert etter emne."
Før: "Kontaktskjemaet vil sende en e-post til eieren."
Etter: "Hovedkontaktskjemaet vil sende e-post til eieren og, avhengig av emnet, anleggskoordinator, teknisk support eller ledende selger."
Før: "Overskriften blir oransje."
Etter: "Hjemmesiden header vil være oransje. Innsideoverskriftene vil være halvt så høye for å understreke innholdet. "
Før: "Medlemskapsprofiler vil inneholde et telefonnummer og en e-postadresse."
Etter: "Medlemskapsprofiler inneholder kontaktinformasjon, inkludert telefonnumre (kontor, hjemme, andre), faksnumre, e-postadresser og tre åpne felt for postadresse, Twitter og Facebook-kontoer og lignende."
Før: "Bloggen vil bli organisert etter dato."
Etter: "Bloggets standardskjerm vil vise innlegg etter dato. Innlegg vil bli organisert med tags; Siden blir utformet slik at den ikke ser tom ut når den bare har fem innlegg; og besøkende vil kunne bla gjennom minst 500 innlegg. "
De beste planene er ikke begrenset til en bestemt design, men står for en rekke parametere. Problemer er bare latterlige når du blir levert en i fristen.
Ekte behov
Ingen system kan tegne seg for hvert scenario.
De fleste kan tilpasse seg små, gradvise endringer over nettstedets levetid, men når båndhjelpsløsninger overgår de opprinnelige problemene, er det på tide å hente ordet som ingen klient noensinne vil høre: "omtanke."
Når du starter fra bunnen av, er det mer effektiv enn å fikse endringene som løste tidligere problemer (men ødela andre ting), den største hindringen overbeviser alle involverte at drastisk endring nå er bedre i det lange løp.
Deretter trenger du et annet ord: "kostnadseffektiv."
Patching kode eller tweaking layouter appellerer til designere, utviklere og kunder fordi det er raskt. De klør en kløe med minimal innsats. Og jo flere mennesker cringe på å fikse et nettsted som bryter med den minste berøring, jo mindre sannsynlig vil noen foreslå en større hodepine.
Men det er et sikkert tegn på at endring er nødvendig. Drakonisk funksjonskryp skjer når tekniske folk og designere virkelig frykter å gjøre endringer. Du kjenner prosjektet: den med saghistorikken med sitt eget arkivskap, med eieren som har stemmen til å rope, og de vandrende prosessene som krever brukerhåndbøker som ingen har tid til å skrive.
Slike prosjekter koster mer enn penger. De er moralsk drenering av ressursgriser som sap oppmerksomhet fra nyere, nimblerprosjekter og forårsaker nok tennkorn til å bære tannleger gjennom lavkonjunkturen.
Krig mot denne typen funksjonskryp begynner med å definere problemer , inkludert problemene som oppstod fra symptomløsende løsninger.
Tilnærming komplette retanker ved å se på langsiktige, både i fortiden og i fremtiden. Nettstedet var flott da, men ting har endret seg. Teknologien har forbedret seg. Klientens produkter eller tjenester har utviklet seg. Kunder er mer (eller kanskje mindre) sofistikerte eller har forskjellige behov.
Utarbeide en plan for å gjøre denne overgangen praktisk . Detaljene avhenger av innholdet på nettsiden, men tilsvarer det samme: overbevise klienten om at den drastiske herdingen ikke er verre enn dagens tyggegummi-og-bailing-wire kurs. Dette er en psykologisk krig så mye som det er teknisk problemløsing.
Det vil skje
De fleste funksjonskrypene tar to former: en kløe som en klient vil klø på og et ekte behov for endring.
Hvis du kan uttrykke etterspørselen som et spørsmål , plasserer du deg selv som en beslutningstaker, i stedet for noen som følger kundens eventuelle dårlig informerte innfall.
Innse at forandringen vil skje. Et nettsted som aldri endres, er en svart pit.
Ben Gremillion er freelance webdesigner som har lært at klienter reagerer bra hvis du kan holde temperament når de mister deres.
Hvordan håndterer du funksjonskryp? Vennligst del noen av dine erfaringer med oss ...