En besökare tillbringar nittio sekunder på din publika webbplats. En receptionist tillbringar åtta timmar om dagen i din backoffice, fem dagar i veckan, i åratal.
Jämför nu hur budgeten fördelades.
Nästan varje projekt jag tar över har fördelat den precis tvärtom: månader på marknadsföringssajten, och ett administrationsgränssnitt som är vad ramverket råkade generera, aldrig öppnat av den som beställde det. Personalen jobbar runt det. De för ett parallellt kalkylark, för kalkylarket är snabbare. Och då är systemets data fel, och alla skyller på systemet.
Vad ”adminen är produkten” betyder konkret
Skärmen matchar beslutet, inte tabellen
En standardadmin ger dig ett formulär per databastabell, alltså en bild av ditt schema och inte av någons arbete. Receptionisten redigerar inte en Appointment-rad - hon försöker klämma in en patient på torsdagen medan hon tittar på vem mer som är inne den dagen. De två behöver olika skärmar, även om de rör samma tabell.
Allt ägaren kan tänkas ändra är en rad, inte en deploy
Priser, öppettider, texten i e-postmeddelanden, samtyckestexten, den juridiska sidfoten, vilka fält som är obligatoriska. Om det krävs en utvecklare för att ändra något av det har du inte levererat ett system, du har levererat ett beroende av dig själv. Jag använder frågan ”skulle någon rimligen vilja ändra det här utan mig?” som test, och svaret är ja långt oftare än man tror.
De farliga åtgärderna ser farliga ut
Radera, återbetala, skicka till alla kunder, köra över en spärr. De här behöver friktion i proportion till sin konsekvens och - viktigare - en notering om vem som gjorde dem. Inte för att sätta dit någon, utan för att ”vad hände här?” ska vara en fråga med ett svar.
Det fungerar på maskinen det kommer att användas på
Ofta en gammal laptop på en dålig uppkoppling i en reception, eller en telefon i ett lager. En admin som är behaglig på en utvecklares skärm och oanvändbar på den hårdvara den är avsedd för är inte färdig.
Testet jag använder
Före överlämningen sätter jag mig bredvid den som kommer att använda det mest och ser på medan personen gör en vanlig dags arbete. Inte en demo - det riktiga arbetet, utan att jag säger något.
Varje gång de tvekar är det ett designfel. Varje gång de öppnar ett kalkylark i stället är det en funktion som saknas. Varje gång de frågar ”kan jag ångra det där?” behöver något en bekräftelse eller en historik.
Det tar en timme och det är den enskilt mest värdefulla timmen i något projekt jag har gjort. Det har aldrig en enda gång slutat utan ändringar.
Varför det här är ett kommersiellt argument, inte ett estetiskt
Den publika webbplatsens jobb är att få in en förfrågan. Backofficens jobb är att få verksamheten att fungera. Dålig marknadsföring kostar dig leads du aldrig fick veta om; en dålig backoffice kostar dig en timme om dagen, varje dag, per anställd, plus datakvaliteten som varje rapport och varje beslut längre fram är beroende av.
Fördela utgifterna därefter.
Även om den billigaste versionen av det här är att inte bygga backofficen alls, om någon redan säljer en som passar. Det är vad anteckningen om när man inte ska bygga handlar om.