På ett tidigare företag satt jag på ett möte där vi debatterade om vi skulle omforma en funktion som hade varit i produkten i tre år. PM trodde att vi borde lämna den ensam. Sedan drog någon upp den ursprungliga designspecifikationen från 2021. Det visar sig att funktionen byggdes för att lösa ett problem som inte längre existerade. den leverantörsAPI som den arbetade kring? Fixad för 18 månader sedan. Den tekniska begränsningen som formade hela interaktionen var också borta. De hade bara lärt sig hur man använder vad vi gav dem, och ingen någonsin gick tillbaka för att fråga om vi borde bygga om det ordentligt nu som vi kunde. Det mötet fastnade med mig. min man Det är en fras som jag har tänkt mycket på senaste tiden – hur användbarhet fortsätter att omvandla produkter länge efter att det ursprungliga behovet är löst, ibland länge efter att det behovet har förändrats helt. skrev något Products keep changing even when they look the same Tänk på cyklar. De vi rider idag ser inte ut som de första versionerna. De tidiga mönstren var besvärliga, obekväma och lite farliga, faktiskt. Vad som utvecklades var vår förståelse för användbarhet. Bättre material, ja, men också raffinerad ergonomi och förbättrad balans. Varje generation lärde sig från att se människor faktiskt rida dessa saker. Jag fortsätter att se detta mönster. Den första versionen löser behovet. Allt efter det? Det handlar om att göra lösningen livskraftig. Why "it works" is a trap Teams behandlar "det fungerar" som en finishlinje. funktion levererad, problem löst, nästa sak vänligen. Men "det fungerar" betyder vanligtvis bara att användarna har räknat ut hur de ska uppnå sitt mål trots friktionen. Det betyder inte att friktionen inte är där. Det betyder inte att de inte skulle hoppa på något bättre. Jag granskade ett flöde en tid tillbaka där användare var tvungna att klicka genom tre bekräftelseskärmar för att slutföra en enda åtgärd. Varför tre bekräftelser? Ingen på det nuvarande teamet kunde berätta för mig. Vi grävde igenom gamla biljetter och fann att för två år sedan fanns det en dataförlust bugg. Den tredubbla bekräftelsen var en tillfällig patch medan tekniken fixade roten orsaken. De fixade buggen sex månader senare. De tre bekräftelseskärmarna stannade. Eftersom det "fungerade." Användare gick igenom det, var drop-off inte hemskt, och andra prioriteringar kom upp. Det är inte användbarhet som utvecklas. Det är användbarhet som fastnar. What actual evolution looks like Verklig användbarhetsutveckling handlar inte om att lägga till funktioner. Det är förfining baserat på hur människor faktiskt använder vad du har byggt. Bankomater är förmodligen det tydligaste exemplet jag kan tänka mig. första generationens bankomater gav dig kontanter först, sedan returnerade ditt kort. Enkel, funktionell, löste behovet. Senare mönster vände ordningen: kort först, sedan pengar. inte en ny uppfinning. inte lösa ett annat problem. bara anpassa sig till hur människor faktiskt beter sig i stället för hur maskinlogiken föreslog att de borde bete sig. Samma kärnfunktion, formad kring verklighet istället för teori. Why do products stop evolving? Från vad jag har sett, produkter sluta förbättra sin användbarhet av några förutsägbara skäl. Den ursprungliga formgivaren lämnade, och ingen vet varför saker och ting fungerar som de gör. Metrik ser bra ut, så det finns inget affärsfall.Även om användarna bara har lärt sig att arbeta kring problem. Systemet blev så sammankopplat att förändring av en sak bryter tre andra. Att förbättra vad som finns känns mindre spännande än att bygga vad som är nästa. All rimlig. Allare långsamt erodera din produkts användbarhet. What I've noticed about features that improve vs features that stagnate Funktionerna som fortsätter att bli bättre har vanligtvis någon som fortfarande bryr sig om dem.En ägare tittar på hur människor använder det, märker små frustrationer, trycker på förfiningar. Funktioner som stagnerar är föräldralösa barn. Ingen äger dem längre. De fungerar "tillräckligt bra". Varje kvartal tittade de på funktioner som lanserades för mer än sex månader sedan och frågade: hur använder folk det här nu? Inte bara "använder de det" utan hur. Då skulle de prioritera förbättringar baserade på faktiska användningsmönster, inte bara nya funktionsförfrågningar. Men det är skillnaden mellan produkter som åldras väl och produkter som bara blir gamla. When evolution goes wrong De ser användare kämpa och omedelbart omforma utan att förstå varför det fungerar som det gör. Jag såg ett team förenkla det som verkade som ett onödigt komplext flöde. Tre steg blev ett. mycket renare. Drop-offs har tredubblats De tre stegen var inte slumpmässig komplexitet. De var staket som hjälpte användarna att fatta bättre beslut. Kollapsa allt i en skärm tog bort strukturen människor behövde tänka igenom sina val. Bra utveckling kräver förståelse inte bara vad människor gör, men varför den nuvarande designen fungerar, även när det verkar som om det inte borde. The products that never stop improving De produkter jag verkligen älskar att använda har inte nödvändigtvis de bästa funktionerna. Google Search har inte ändrat sitt grundläggande syfte på 20 år. men användbarheten fortsätter att utvecklas. Autocomplete, omedelbara resultat, kunskapspaneler och utvalda utdrag. Var och en är baserad på att lära sig hur människor faktiskt söker, inte hur Google trodde att de skulle söka. Slack uppfann inte teamchatt. De fortsatte bara att förfina hur det fungerar. Threading, reaktioner, bättre meddelanden, smartare sökning. De är noggranna, kontinuerlig utveckling baserad på att titta på riktiga människor använder produkten. What this means for how I think about design now Behovet kan skapa den första versionen av din produkt, men användbarhetsutvecklingen avgör om det finns en tionde version. Vad håller vi bara för att det finns, inte för att det fortfarande är rätt? Vilka begränsningar formade vår design som inte längre gäller? vad har användarna lärt sig att arbeta kring som vi faktiskt kunde fixa? Och kanske den viktigaste frågan: vem i teamet är ansvarig för att göra befintliga funktioner bättre, inte bara bygga nya? Something worth trying Varje månad väljer du en etablerad funktion och låtsas att du designar den ny idag med aktuell teknik, nuvarande förståelse för användare och nuvarande affärssammanhang. Skulle du designa det på samma sätt? Vanligtvis är svaret nej. Och när det är, är nästa fråga: vad hindrar dig från att göra det bättre? Ibland är det verkliga begränsningar. men många gånger är det bara tröghet. Och tröghet är dyrt när du konkurrerar med team som faktiskt utvecklar sina produkter. Where I've landed on this Behovet uppfinner produkter. Användbarhet avgör om dessa produkter förblir relevanta. Uppfinningen får dig till marknaden.Evolution håller dig där. Teams som får detta inte bara skepp och flytta vidare. de skepp, titta på vad som faktiskt händer, lära av det, och förfina. Särskilt när saker och ting faktiskt fungerar. Because "working" is just the starting point for what a product can become. Eftersom "arbete" bara är utgångspunkten för vad en produkt kan bli.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Read My Stories

Det här ljudet är producerat på berättelsens originalspråk!

Varför "det fungerar" är ofta den farligaste frasen i produktdesign

About Author

KOMMENTARER

HÄNG TAGGAR

DENNA ARTIKEL PRESENTERAS I

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps