Webbutveckling
Webbutveckling för företag: från behov till en webbplats som fungerar
Ska företaget ha en ny webbplats, nätbutik eller webbapp? Använd en konkret kravspecifikation för att välja lösning och kontrollera leveransen vid lansering.
En ny webbplats för företaget bör göra ett konkret jobb: förklara erbjudandet, skaffa relevanta förfrågningar, sälja produkter eller låta kunden lösa en uppgift själv. När uppgiften är tydlig blir det enklare att bedöma både teknik, omfattning och pris.
Den här guiden handlar om köp av webbutveckling. Den hjälper dig att skriva ett bra underlag för offert och kontrollera att leveransen fungerar i praktiken, oavsett om du behöver en företagswebbplats, en nätbutik eller en webbapplikation.
Webbplats, nätbutik eller webbapp?
Börja med det viktigaste användaren ska göra. En webbplats kan vara rätt när kunden behöver information och sedan tar kontakt. En nätbutik måste också hantera köpet och uppföljningen kring ordern. En webbapp blir aktuell när användaren ska arbeta med data, processer eller personuppgifter över tid.
Gränserna kan överlappa. En företagswebbplats kan ha bokning, och en nätbutik kan ha en kundportal. Fråga därför vad som måste fungera vid första lanseringen. Extra funktioner bör motiveras av ett konkret behov och en person som ska använda dem.
| Lösning | Typisk huvuduppgift | Klargör tidigt |
|---|---|---|
| Företagswebbplats | Förklara erbjudandet och skapa kontakt. | Innehåll, redigering, kontaktflöde och synlighet. |
| Nätbutik | Låta kunden välja, beställa och betala. | Produktdata, frakt, betalning, order och kundservice. |
| Webbapp eller portal | Låta kunden utföra en uppgift över tid. | Inloggning, roller, datakällor, historik och integrationer. |
Beskriv tre uppgifter som sidan måste lösa
Välj tre viktiga uppgifter och skriv dem som korta situationer. För ett tjänsteföretag kan de vara: En ny kund ska ta reda på om ni täcker området, en inköpare ska förstå vad ett serviceavtal innehåller, och en befintlig kund ska be om hjälp.
Gå igenom dagens lösning med dessa uppgifter. Notera var information saknas, var kunden måste leta och var medarbetare måste göra dubbelarbete. Det här blir ett bättre underlag för webbdesign och utveckling än en lista över webbplatser ni tycker ser fina ut.
Beskriv också ett lyckat slutläge. ”Formuläret fungerar” är otydligt. ”En kund kan skicka en förfrågan på mobil, får bekräftelse, och förfrågan visas hos rätt ansvarig” kan demonstreras. På så sätt knyter ni det visuella arbetet till en faktisk leverans.
Skriv en kravspecifikation som går att använda
Dela upp kraven i måste finnas vid lansering, bör finnas och kan vänta. Varje krav bör ha en ansvarig och ett enkelt sätt att godkänna det. Be leverantören förklara förutsättningar, beroenden och vad som faller utanför offerten.
Tabellen visar förslag på krav. Anpassa detaljerna till verksamheten, särskilt roller, integrationer och vad ni behöver kunna ändra själva.
| Område | Krav | Så kan det godkännas |
|---|---|---|
| Innehåll | Redaktör kan uppdatera tjänstetext och kontaktinformation. | En medarbetare gör ändringen efter utbildning. |
| Kontakt | Inskickade förfrågningar kommer till rätt team. | Ett märkt test spåras från formulär till mottagare. |
| Mobil | Viktiga uppgifter fungerar på små skärmar. | Uppgifterna genomförs på avtalade telefoner och webbläsare. |
| Integration | Avtalade fält överförs till rätt system. | Testa med både komplett och bristfällig inskickning. |
| Överlämning | Åtkomster, dokumentation och driftsansvar är klargjorda. | Företaget tar emot och kontrollerar en överlämningslista. |
Ge innehållet en ägare innan designen är klar
En ny lösning behöver text, bilder och klargjorda uppgifter om tjänsterna. Fördela ansvar för varje sida. Bestäm vem som kan bekräfta priser, leveransområden, produktbeskrivningar och eventuella kundreferenser. Innehåll som är ”på väg” bör ha ett avtalat leveransdatum.
Använd en faktisk tjänstesida i designarbetet. Den visar om rubriker, förklaringar, bilder och handlingsknappar fungerar tillsammans. Ett snyggt utkast med korta exempeltexter kan dölja problem som först dyker upp när den verkliga beskrivningen ska in.
För nätbutik måste produktdata få samma uppmärksamhet. Bestäm var namn, varianter, lagerstatus och bilder kommer från, och vem som rättar fel. En ny design löser inte otydliga produktdata eller oklara ansvarsförhållanden.
Kom överens om kvalitet i användning, inte bara en poängsumma
Be om testning av de viktigaste användaruppgifterna på mobil och med tangentbord. Ta med tydliga fältetiketter, läsbar text och begripliga felmeddelanden. W3C rekommenderar att tillgänglighet ingår genom hela produktionsprocessen och bedöms tidigt och regelbundet. Gör därför detta till en del av arbetet från start.
Prestanda bör också bedömas med verkligt innehåll. Googles Core Web Vitals beskriver inläsning av huvudinnehåll, respons på handlingar och visuell stabilitet. Använd mätningar för att hitta problem, och kombinera dem med praktiska uppgiftstester. En snabb startsida hjälper föga om kontaktformuläret är svårt att använda.
Be om att testunderlaget beskrivs: vilka sidor, enheter och situationer som har kontrollerats, vilka fel som har rättats och vad som eventuellt återstår.
Planera lansering och ägarskap före sista veckan
Vid ersättning av en befintlig webbplats måste viktiga webbadresser kartläggas. Om adresserna ändras rekommenderar Google en plan som kopplar gamla sidor till relevanta nya sidor och vidarebefordrar trafiken. Inkludera detta i omfattningen, tillsammans med kontroll av interna länkar och viktiga formulär.
Kom överens om vem som äger domänen, publiceringslösningen och nödvändiga konton. Företaget bör veta vem som följer driften, tar säkerhetskopior där det är relevant, hanterar fel och genomför uppdateringar. Beskriv också hur ni beställer mindre ändringar efter lansering.
Sätt en separat tidpunkt för överlämning. Den som ska redigera sidan bör prova uppgifterna själv. Först när innehåll, kontaktflöde, mätning och ansvar fungerar tillsammans har ni en bra grund för att använda webbplatsen i marknadsföringen.
Frågor och svar
Måste vi välja teknik innan vi kontaktar en utvecklingsbyrå?
Vanligtvis är det bättre att först beskriva användaruppgifter, redigeringsbehov och integrationer. Har ni interna systemkrav eller kompetens som ska användas vidare bör detta självklart stå i behovsbeskrivningen.
Behöver ett litet företag en skräddarsydd webbplats?
Inte nödvändigtvis. Klargör vilka krav en standardlösning täcker och vilka behov som faktiskt kräver anpassning. Jämför också redigering, drift, vidareutveckling och möjligheten att flytta senare.
Vad bör vi ha klart innan vi ber om offert på webbutveckling?
Beskriv huvudmålet, de viktigaste användaruppgifterna, ungefärliga sidtyper, innehållsansvar, integrationer och önskad lansering. Bifoga länken till dagens webbplats och vad ni vill förbättra.
Källor och vidare läsning
Från insikt till något som fungerar.
Prata med oss om vad ditt företag behöver och var det är klokt att börja.
Diskutera företagets nya webbplats