Topp 20 nettdesignkrav Hver RFP-respons må inkludere

Du har nylig sett mange innlegg om kravene, kontraktene og forslagene til et nettsteddesign. Hva er årsaken bak det?

Dette er fordi hvis du ønsker å lansere et vellykket nettsteddesign, trenger du mer enn bilder, tekster og programvarekode. Nedenfor er de øverste nettdesignkravene som hver Request for Proposal (RFP)-svar må inkludere.

Suksessen til et nettsteddesign er et direkte resultat av solid dokumentasjon og strukturert prosess

Gjennomføring av et effektivt webdesignprosjekt starter og slutter med en solid dokumentasjon. Denne solide dokumentasjonen kan være i form av arbeidserklæring, kontrakt eller forslag. Navnet på dette dokumentet er mindre viktig enn informasjonen i dokumentet.

Enten du er en stor bedrift eller en liten bedrift, er solid dokumentasjon nødvendig for å utføre ethvert nettprosjekt som er innenfor budsjett, på oppgave og i tide.

Jo mer du legger merke til dokumentet i salgsprosessen, jo mer smidig og enklere vil hele prosessen gå til alle involverte. Her i denne artikkelen belyser vi evalueringen og gjennomgangen av Request for Proposal (RFP)-svar. Ta en titt!

Evaluering av RFP-svar

Å gjennomgå og evaluere RFP-svar høres enkelt ut? Men faktisk høres det lettere ut enn det faktisk er når du praktiserer det.

Hvis teamet som håndterer prosjektet ber om tilbud fra forskjellige designbyråer, kan oppgaven med å evaluere forslag til webdesign føle dem overveldet. Ok, de føler det ikke bare – men i virkeligheten kan det være overveldende.

Jo større antall RFP-skader, jo større er variasjonene og responspoolen innenfor disse forslagene. Forhåpentligvis ble det til slutt laget en kort liste over nettutviklere før tilbudet ble sendt ut, som vil holde dette nummererte begrenset og gjøre hele gjennomgangsprosessen litt enklere.

Når du har fått et forslag til nettstedet, er det bedre å stille deg noen viktige spørsmål for å komme i gang. Disse spørsmålene inkluderer vanligvis

• Er det mulig å levere forslaget innenfor tidslinjen gitt i prosjektet?
• Er dette forslaget innenfor budsjettrammene til prosjektet?
• Dekker RFP-svaret du får alle kravene til et nettsteddesign?
• Er RFP-svaret velskrevet og lett å forstå?
• Har RFP-svaret du får presentert på en profesjonell måte?
• Ble svaret gitt innen den gitte tidsrammen?

Spørsmålene ovenfor er uten tvil spørsmål på høyt nivå, men det bidrar til å eliminere ethvert webdesignfirma som helt klart er rart. Et ufullstendig, sent eller uprofesjonelt RFP-svar bør gis et rødt flagg om potensiell utvikling av nettstedet. Berør også et RFP-svar som oppgir en pris to ganger eller tre ganger budsjettet ditt.

Nå som du har mottatt alle svarene og du også har gitt et rødt flagg til firmaene som tydeligvis ikke passer, er det nå på tide å gjennomgå hvert RFP-svar grundig slik at det blir enkelt for deg å sammenligne RFP-svar i en mer epler til epler måte.

Webdesignkrav som må ses i hvert RFP-svar

Det er forskjellige lengder på RFP-svar. Så det er bedre å ikke fokusere på antall sider eller tekstvolumet. Det som betyr mest er løsningen og innholdet som presenteres i svaret.

Når du vurderer RFP-svar, må du alltid huske på at hvert svar dekker noen viktige elementer i ethvert nettprosjekt. Sørg for at disse webdesignkravene inkluderer, men ikke er begrenset til, detaljene gitt nedenfor.

Prosjektplan:

Dette må inkludere et høyt nivå og en enorm liste over prosjektoppgaver. Selv om det bare er en innledende plan, vil den ikke være like detaljert som selve den endelige planen, men det bør være nok detaljer slik at du enkelt kan forstå flyten av bygging, utvikling, design og oppdagelse.

Verktøy for prosjektledelse:

Det må være en skikkelig liste over designbyråets prosjektstyringsverktøy. Hvert firma har forskjellige prosjektstyringsverktøy, ettersom det er mange gode alternativer i et selskap. Det mest avgjørende er å sørge for at det er en skikkelig struktur på prosjektledelsesprosessen og de gitte oppgavene, datoene og eierne vil bli dokumentert på en måte som er lett å forstå.

Lag medlemmer:

Ulike designbyråer tilbyr forskjellige strukturer for teamene sine. Jo større webdesignbyrået er, desto større har de prosjektteamet som jobber med det. Som kjøper er det viktig for deg å vite hvem som vil jobbe med deg i teamet ditt og hva arbeidskapasiteten de vil gi er. Det er ikke nødvendig å ha en fullstendig CV for hvert teammedlem, men du har i det minste en liste over personer som jobber med deg i de kommende månedene.

Grunnlinjeteknologi og innholdsstyringssystem:

Hvis RFP-en til nettstedet ditt ikke spesifiserte en ønsket CMS-løsning, da dette vil være et vesentlig element i forslaget. Sørg for at RFP-svarene viser et komplett CMS valgfritt og eventuell tilleggsteknologi som er nødvendig for å distribuere og kode det nye nettstedet. Legg spesielt merke til alt som er proprietært. Gi straks et rødt flagg til en proprietær CMS-pakke, da den låser deg til den nettutvikleren for hele nettstedets levetid.

Leveranser:

Dette er en annen viktig liste fordi den forteller hva som skal leveres til deg når du går live. Dette kan inkludere plug-in som brukes, volum av innholdsmigrering, designmaler og mye mer relatert til prosjektet.

Funksjonalitetsliste:

Dette er en annen viktig liste hvis nettstedet du skal designe er mer enn et enkelt brosjyrenettsted. Jo mer kompleks nettstedet ditt er, desto mer detaljert bør funksjonalitetslisten være.

Innholdsmigrering:

Hvis nettsideprosjektet vil inkludere innholdsmigrering, husk å liste opp hvor mye innhold som skal migreres over til det nye nettstedet ditt. Dette kan inkludere vedlegg, brukere, arrangementer, produkter, innlegg, sider og så videre og så videre. Dersom volumet og innholdet ikke er definert, vil det føre til ekstra kostnader og omfangskryp for deg så vel som for designbyrået.

DETTE:

Glem aldri SEO! Dette kan inkludere 301-omdirigeringer, metadefinisjon, optimalisering på siden, nøkkelord som kreves for sidekartlegging og søkeordundersøkelser. Hvis du stoler på organisk SEO, beskytt denne trafikkkilden under redesignet. Det beste og enkleste å gjøre dette er å sikre at dette emnet er sentrert og først under prosjektforslaget og scoping-prosessen.

Bildebruk:

Det er viktig å nøye forstå oppdraget og eierskapet til bildene designeren brukte i webdesignprosjektet. Spør webdesignbyrået om den som er ansvarlig for plassering, redigering, kjøp og valg av bilder. Dette vil variere prosjekt til prosjekt, så det er bedre å definere dette på et tidlig stadium.

Ekskluderinger:

Selv om det ikke er nødvendig å inkludere ekskluderinger i hvert forslag du kommer med, men ikke glem å liste det når du og klienten diskuterte noe som ikke kommer inn i nettstedets prosjekt. Dette hjelper kjøperen med å beskytte i den senere prosessen, men tydeliggjør også leveransene dine for kunden.

Mobil respons:

I dag er ingen nettside komplett uten mobilrespons. Det bør være hoveddelen av ethvert moderne nettsted. Men det varierer etter størrelsen på nettstedet. Det er mange store selskaper som har en egen mobilapp eller nettsider. Det er greit, hvis du ikke har et eget mobilnettsted, sørg for at forslaget du designer må inneholde språk som enkelt kan administrere visning tilpasset nettbrett og telefoner.

APIer eller/og tredjepartsintegrasjon:

Enterprise- og mellommarkedsbedrifter har vanligvis et stort antall programvare- og systempakker i sin organisasjon. Disse systemene brukes til å enkelt kommunisere med den nye nettsiden ved å synkronisere, pushe og trekke data. Hvis APIer eller integrasjon må brukes noen ganger, sørg for at forslaget definerer tredjepartssystemet, dataoverføringen, datapunktene og den ansvarlige parten.

Rute:

Hvert nettforslagsvar skal inneholde en liste som tilsvarer prosjektets milepæl. Dette vil fortelle kjøperen hvor mye tid det er nødvendig for å fullføre hver milepæl, og om prosjektet vil følge den gitte tidsplanen.

Milepæler:

Hvis det er fastsatte milepæler, vil teamet jobbe mer effektivt for å nå målet på hvert trinn av nettsidedesignprosessen før de går videre på neste trinn. Typiske milepæler inkluderer vanligvis beta-testing eller/og lansering, innholdsmigrering, temakoding, grafisk design, informasjonsarkitektur, oppdagelse og start.

Forsinkelser:

Prosjektforsinkelser skyldes vanligvis både utvikleren og klienten. Det er viktig å forstå hvordan man skal håndtere disse forsinkelsene og hvordan det vil endre den generelle tidslinjen og budsjettet for webdesignprosjektet.

Betalingsbetingelser:

Hvis det er et mindre nettstedsprosjekt, må kjøperen betale en 50% betaling ved oppstart av prosjektet mens 50% etter ferdigstillelse. Mens på den annen side, hvis det er større nettstedsprosjekter, er betalinger basert på fastsatte tidspunkter eller milepæler. Sørg for at betalingsbetingelsene er klart definert i forslaget ditt.

Utgifter:

Utgifter inkluderer vanligvis arkivbilder, plug-in-lisenser, hostingavgifter, domeneavgifter og/eller reiser. Sørg for at det må være riktige detaljer om hver eneste utgift i forslaget, og at kjøperen er ansvarlig for betalingen.

Brukeropplæring:

Hvis brukeren er ny på CMS, kan forslaget inneholde noen retningslinjer for å skrive opplæringsdokumentasjon, interaktive treningsøkter eller/og nettbaserte opplæringsverktøy. Husk at treningsmetodikken må samsvare med brukerbasen din.

Garantiperiode:

Garantiperioden dekker vanligvis korrigering av programvarefeil på nettstedet. Garantiperiode, vanligvis satt for en bestemt periode på dager og må angis i kontrakten eller forslaget. Denne garantien vil dekke koding fra nettstedutvikleren, men ikke tredjeparts utvidelser eller plug-in.

Løpende vedlikehold:

Ikke forveksle vedlikehold med garantiperiode; de er veldig forskjellige fra garantiperioden. En vedlikeholdsavtale må betales for en årlig eller månedlig basis, og den brukes til å gi webutvikleroppdateringer til systemet og programvaren over tid. For WordPress-nettsteder vil løpende vedlikehold omfatte oppdatering av hele WordPress-kjerneprogramvaren og eventuelle plugin-moduler installert på nettstedet. Løpende vedlikehold inkluderer også en-til-en assistanse, rapportering, backup, overvåking og sikkerhet ved behov.

Post-Live-støtte ved behov:

Det er ikke nødvendig at enhver bedrift trenger eller ønsker en vedlikeholdsavtale. I stedet for en vedlikeholdsavtale vil noen selskaper kreve en on-demand post-live-støtte. Dette faktureres vanligvis på timebasis og administreres gjennom et støttesystem eller billett.

Neste trinn involvert i RFP-prosessen for nettstedet:

Etter at du har gått gjennom hele RFP-svarene og begrenset den valgte leverandøren, er det nå på tide å fokusere på neste trinn som er å forhandle endelige detaljer og kontrakter.

Mens Internett er fullt av anbefalinger om kontraktsforhandlinger, ikke bli stoppet i prosessens detaljer. Det er viktig å huske på at dette trinnet er det siste trinnet før man inngår et langt partnerskap med den valgte nettutvikleren.

Denne forhandlingen konsentrerer seg om å løse eventuelle åpne problemer eller spørsmål, som igjen vil gi deg et solid grunnlag for å starte design- og implementeringsprosessen. Gå inn i kontraktsforhandlinger og vær oppmerksom på å løse eventuelle åpne problemer og avklare eventuelle forvirringspunkter.

Hvis det valgte prosjektteamet har gjort en god jobb med prosjektomfang og de valgte riktig utvikler, må forhandlingene ikke være mer enn en signatur. Hvis i tilfelle teamet har valgt feil webdesignbyrå, kan prosjektet vise seg å være nok til å tvinge teamet til å tenke på nummer to-firmaet.