Steve Jobs Haatte Gebruikersonderzoek

Steve Jobs haatte gebruikersonderzoek. Dit is waarom ik het met hem eens ben. Mensen hebben geen idee wat ze willen en productmanagers zouden beter af zijn met het schrijven van tickets voor hun engineers. Dit is waarom de overmoedige voorspellingen van uw gebruikers onzin zijn.

Het is logisch dat Steve Jobs gebruikersonderzoek haatte, omdat hij van "first-run experience" hield. Foto: AB Unsplash

Ik heb van andere professionele software-engineers gehoord over een trend in de industrie waar ik het in dit artikel over wil hebben. Soms geven productmanagers (PM's) er de voorkeur aan om "met gebruikers te praten" (gebruikersonderzoek) boven het werk van het identificeren en documenteren van functies en bugfixes voor het product.

Ik denk dat dat komt omdat, zoals u waarschijnlijk weet, het opschrijven van werkitems ("tickets") in feite werk is. Het is saai en het is waardeloos, maar het helpt het engineeringteam om succesvol te zijn. Maar "rondhangen" met je gebruikers tijdens lange videogesprekken voelt niet echt als werk, want dat is het ook niet.

(Om eerlijk te zijn tegenover fulltime gebruikersonderzoekers, die doorgaans bijhouden hoe lang het duurt voordat gebruikers bepaalde taken voltooien en heatmaps gebruiken om de cursorpositie te kwantificeren, lijkt het meeste "gebruikersonderzoek" door PM's slechts een licht gestructureerd gesprek, van wat ik heb gehoord in de geruchtenmolen.)

Meestal, wanneer het team geen fulltime, gekwalificeerde gebruikersonderzoekers heeft, nemen de PM's en/of productontwerpers die rol over. Dat lijkt logisch, totdat de engineers wachten op tickets en het werk van die PM's en ontwerpers moeten doen door de tickets op te schrijven.

"Gebruikersonderzoek" klinkt zeker als een belangrijke, werkgerelateerde activiteit, toch?

Maar gebruikersonderzoek kost niet alleen tijd van het ondersteunen van engineeringteams die bijna universeel niet genoeg programmeurs hebben; het is in de eerste plaats niet echt nuttig. Dit was een sentiment waar Steve Jobs het mee eens was:

"Mensen weten niet wat ze willen totdat je het ze laat zien. Daarom vertrouw ik nooit op marktonderzoek. Onze taak is om dingen te lezen die nog niet op de pagina staan." — Steve Jobs

Hier is waarom ik wou dat PM's hun "gebruikersonderzoek"-tijd zouden besteden aan het schrijven van tickets voor het engineeringteam.

Waar worden productmanagers voor betaald?

In een team met beperkte middelen, vooral een team dat niet genoeg software-engineers heeft om de productroadmap volgens plan te laten verlopen, moet iemand de slappe klappen opvangen en de ******* tickets schrijven.

Wiens taak is het in ons team om de tickets te schrijven? In de meeste teams die het geluk hebben een productmanager te hebben, is dat de belangrijkste rol van de PM.

Maar veel PM's nemen blijkbaar de tegenovergestelde filosofie ter harte, het sentiment dat "engineers de tickets moeten schrijven." Wacht, wat?

Volgens mensen met ervaring in teams die op deze manier werken, is de "verantwoordelijkheid van de PM's om het probleem of de kans te kaderen" — en niet om het als ticket op te schrijven. Blijkbaar zijn de PM's te druk met praten met gebruikers en vergaderingen met belanghebbenden om de tickets op te schrijven, afgaande op wat ik over dit onderwerp heb gelezen.

Zeker, als je genoeg software-engineers hebt — met name overtollige engineers vergeleken met de productroadmap, die ik nog nooit heb gezien maar blijkbaar bij sommige bedrijven gebeurt, met name maar niet uitsluitend in de EU — dan schrijven de engineers vaak betere tickets dan de PM's.

In dat geval, ontsla de PM(s) dan en laat de engineers de tickets schrijven. Engineers haten het misschien om tickets te schrijven, maar het is een efficiënter gebruik van het budget om meer programmeurs en minder middle managers te betalen.

Als dat het geval is, waarom zou je de PM(s) dan houden, ook al schrijven de engineers de tickets? Wat de **** gaan ze de hele dag doen?

Gebruikersonderzoek! (Duh!)

Eh, oké, dus hoe gaat dat meestal? Nou, "gebruikersonderzoek" lijkt te betekenen een informeel gesprek van 30-60 minuten dat deze onderwerpen behandelt, die ik heb geselecteerd uit een Hotjar-artikel over kwalitatieve gebruikersinterviews:

1. Wat is je eerste reactie op dit prototype?
2. Wat vind je leuk en niet leuk aan dit prototype?
3. Hoe zou je dit ontwerp verbeteren?
4. Welke functies zijn het belangrijkst voor je in een product als dit? Wat vind je leuk en niet leuk aan dit product?
5. Heeft dit product de functies die je nodig hebt? Heb je nog extra functionaliteit nodig?
6. Hoe vind je dat dit product zich verhoudt tot vergelijkbare producten op de markt?
7. Op een schaal van 1-10, hoe waarschijnlijk is het dat je dit product koopt?
8. Op een schaal van 1-10, hoe gemakkelijk was het voor je om deze specifieke taak te voltooien?
9. Op een schaal van 1-10, hoe waarschijnlijk is het dat je ons aanbeveelt bij een vriend of collega? Waarom heb je die beoordeling gegeven?
10. Wat zou uw ervaring beter maken?

Ziet u hoe gebruikers (zowel potentiële als huidige) gaan liegen — zonder het te bedoelen — door deze vragen vol vertrouwen te beantwoorden?

Nou, als u het nog niet ziet, laat me u dan door het onderzoek naar overmoed leiden om te illustreren waarom deze kwalitatieve gebruikersinterviews meestal tijdverspilling zijn, vooral vergeleken met PM's die tickets schrijven. Overmoed is de reden waarom gebruikersinterviews nutteloos zijn

Begrijp me niet verkeerd, ik ben de grootste fan van klantervaring die je ooit zult tegenkomen bij een software-engineer, en daarom heb ik mijn hele carrière gericht op UI / UX (user interface / user experience) product engineering.

Maar er zijn gewoon te veel universele waarheden over softwareontwikkeling en consumentenvoorkeuren die uw gebruikers nooit zullen noemen tijdens informele gebruikersonderzoeksgesprekken, ook al zijn dit de belangrijkste:

Websites en apps moeten snel en performant zijn.
Websites en apps moeten reageren op gebruikersinvoer.
Websites en apps moeten duidelijk en gebruiksvriendelijk zijn.
Websites en apps mogen geen bugs hebben.
Websites en apps moeten op alle schermformaten werken.

Ik garandeer dat gebruikers meer om deze 5 items geven dan om de vorige lijst met 10 vragen, maar deze items staan niet in de vorige bron over kwalitatieve gebruikersinterviews. Zou het oplossen van bugs niet altijd #1 moeten zijn?

Kwalitatief gebruikersonderzoek in de trant van de vragen die ik in de vorige sectie noemde, is niet echt nuttig, omdat mensen standaard overmoedig zijn over hun voorspellingen in het leven.

"Praten met gebruikers" zet gebruikers aan om zelfverzekerde — maar verkeerde — antwoorden te geven over een voorgesteld ontwerp van de gebruikersinterface (UI) en de gebruikerservaring (UX).

Dat is geen goed idee.

Gebruikers zijn immers doorgaans geen software-engineers, productmanagers of productontwerpers, dus waarom zouden ze **** weten over UI/UX?

Denk je dat gebruikers, die "wowed" zijn alleen al om de kans te krijgen om deel te nemen aan 1-op-1 gebruikersonderzoek, een nauwkeurige lijst gaan rapporteren van alle bugs die ze in je softwareproduct hebben gevonden? Denk je dat de suggesties van gebruikers, die vaak niet in de komende 12+ maanden van een productroadmap passen, eigenlijk "goede ideeën" zijn? Denkt u dat gebruikers hun toekomstige gedrag nauwkeurig kunnen voorspellen als het gaat om het "geweldige nieuwe ontwerp" van een softwareproduct?

Het is gewoon overweldigend duidelijk uit zowel onderzoek als persoonlijke ervaring dat "traditioneel gebruikersonderzoek" gebrekkig is — gebruikers zijn geen technologen.

Laten we kijken naar het bewijs op basis van mislukte bedrijfsexperimenten (New Coke) en wetenschappelijk onderzoek naar waarom mensen vol vertrouwen voorspellingen doen, ook al blijken die voorspellingen meestal onjuist te zijn.

"Traditioneel consumentenonderzoek zal net zo goed onwaarheden als waarheden aan het licht brengen. Gedragswetenschap heeft zelfs bewezen hoe slecht mensen zijn in het begrijpen waarom we doen wat we doen, en heeft aangetoond dat consumenten meestal niet weten wat ze willen." — Adam Cleaver over WRAC

Dit is geen nieuwe informatie, aangezien Wikipedia onderzoekspapers uit 2002 en 2008 aanhaalt als de belangrijkste bronnen voor het "overmoedseffect":

"Het overmoedseffect is een goed gevestigde bias waarbij het subjectieve vertrouwen van een persoon in zijn of haar oordelen betrouwbaar groter is dan de objectieve nauwkeurigheid van die oordelen, vooral wanneer het vertrouwen relatief hoog is.[1][2]" — Wikipedia

Het feit dat gebruikers vol vertrouwen tegen je liegen over wat ze willen, maar zich daar niet van bewust zijn, is gerelateerd aan het Dunning-Krugereffect, of het idee dat elke bestuurder zichzelf beoordeelt als "beter dan gemiddeld".

Je gebruikers zullen zichzelf gewoon niet voor gek zetten — of "je tijd verspillen" — door te zeggen dat ze het niet weten. Dus ze zullen een zelfverzekerde verklaring afleggen, maar het is meestal gewoon een ongeïnformeerde gok zonder echte waarde.

Dat maakt het concept ongeldig om mensen te vragen wat ze willen zien in je software, wat kan verklaren waarom de iPhone 1,46 miljard actieve gebruikers heeft.

“Mythe #21: Mensen kunnen je vertellen wat ze willen

Veel organisaties vertrouwen er nog steeds op om mensen te vragen welke veranderingen ze graag zouden zien in hun website of service, waarbij ze historische onderzoeksmislukkingen zoals de New Coke of de Aeron-stoel negeren.

Wanneer je mensen vraagt, moet je je ervan bewust zijn dat mensen zelfverzekerde maar valse voorspellingen doen over hun toekomstige gedrag, vooral wanneer ze worden geconfronteerd met een nieuw en onbekend ontwerp.” — UXMyths.com

Wanneer een bedrijf je een privé-uitnodiging geeft om je hun “opwindende, nieuwe ontwerp” voor hun softwareproduct te laten zien, denk je dat de meeste mensen zullen zeggen: “Ja, dit is waardeloos. Stop met het veranderen van dingen zonder reden!” Geen kans!

Maar wanneer je een dagelijkse gebruiker bent van een softwareproduct en ze veranderen de hele gebruikerservaring zonder reden, zullen de meeste mensen precies dat zeggen!

"Het volstaat om te zeggen tegen NI (en iedereen anders in de computerindustrie) — STOP ALSJEBLIEFT MET HET VERANDEREN VAN DINGEN ZONDER ENIGE REDEN. STOP MET HET GEBRUIKEN VAN OPEN SOURCE BIBLIOTHEKEN DIE NIET WERKEN. STOP MET HET TOEVOEGEN VAN DIEFSTALBEVEILIGING DIE EEN NEGATIEVE IMPACT HEEFT OP UW EERLIJKE GEBRUIKERS." — Bergsten, schrijvend op de Native Instruments (NI) forums

En dat brengt ons terug bij het (beruchte?) citaat van Steve Jobs waarmee ik dit artikel begon en dat ik hier zal herhalen ter referentie. Hier is het volledige citaat:

"Sommige mensen zeggen: "Geef de klanten wat ze willen.” Maar dat is niet mijn aanpak. Onze taak is om erachter te komen wat ze willen voordat ze het zelf weten. Ik denk dat Henry Ford ooit zei: “Als ik klanten had gevraagd wat ze wilden, hadden ze gezegd: ‘Een sneller paard!’” Mensen weten pas wat ze willen als je het ze laat zien. Daarom vertrouw ik nooit op marktonderzoek. Onze taak is om dingen te lezen die nog niet op de pagina staan.” — Steve Jobs

Steve Jobs en Henry Ford hadden het allebei helemaal bij het rechte eind: consumenten hebben vaak geen idee wat ze willen, tenminste totdat je nieuwe product populair wordt op sociale media vanwege de uitstekende gebruikerservaring.

Daarom moeten PM's weer tickets gaan schrijven! Het doel van softwareontwikkeling zou een performante, bugvrije ervaring moeten zijn, niet elke 6-12 maanden een nieuwe richting inslaan vanwege “snelle chats met gebruikers.”

Laat het gebruikersonderzoek over aan professionele gebruikersonderzoekers die uw team helpen uw app te optimaliseren, zodat uw gebruikers een nog betere gebruikerservaring hebben, door de tijd te verkorten die gebruikers nodig hebben om taken uit te voeren.

Oh, en geef prioriteit aan het oplossen van bugs. Er is niets ergers dat u voor uw merk kunt doen dan buggy software uitbrengen en die bugs vervolgens maanden of jaren niet oplossen. Het oplossen van bugs is duidelijk altijd prioriteit #1. Afronding: Steve Jobs en Henry Ford hadden gelijk

Om af te ronden, nemen we het hypothetische voorbeeld van een onderbezet, ondergekapitaliseerd software-engineeringteam bij een videogamebedrijf dat alleen een pc-app heeft, maar deze wil uitbrengen op Xbox, Playstation en Switch.

In dit geval zijn gebruikers gamers, dus we kunnen aannemen dat ze waarschijnlijk minstens één console ergens in huis hebben liggen, om nog maar te zwijgen van het feit dat ze mobiele telefoons hebben en een telefoonversie van de game niet erg zouden vinden.

Als je met ze praat, zullen je gebruikers waarschijnlijk zeggen dat ze consolepoorten willen en ze zouden kunnen zeggen dat ze zich kunnen voorstellen dat ze het meer zouden gebruiken dan ze momenteel de pc-app gebruiken, vooral als je ze sturende vragen stelt: "Zou je een consolepoort meer gebruiken dan onze huidige pc-game?"

Maar als je ze precies dat levert in dit hypothetische voorbeeld, is het heel goed mogelijk dat je slechts een marginale migratie van je pc-game naar je consoles ziet.

Waarom?

Je gebruikers gebruiken de pc-game al! Ze weten het, ze vertrouwen het en ze zouden liever hebben dat de bugs daar worden opgelost dan dat ze overstappen op consoles. Dat is een reële mogelijkheid voor het werkelijke gebruikersgedrag en het is precies het tegenovergestelde van wat de meeste mensen zullen zeggen tijdens freeform user research "quick chats". Je consolepoorten kosten immers geld om te kopen, toch?

Dus ja, poorten klinken als een geweldig idee, maar je gebruikers zullen er net als iedereen slecht in zijn om hun eigen toekomstige gedrag nauwkeurig te voorspellen!

Zoals Nate Silver uitlegt in de samenvatting van zijn boek The Signal and the Noise: "Zowel experts als leken verwarren zelfverzekerdere voorspellingen met nauwkeurigere. Maar overmoed is vaak de reden voor mislukking."

Omdat uw PM's, productontwerpers en directieteam net als ieder ander zijn, gaan ze ervan uit dat die "zelfverzekerde uitspraken" uit uw gebruikersonderzoek ook "nauwkeurige uitspraken" zijn over het toekomstige gedrag van gebruikers.

Ze gaan ook ten onder aan hun eigen Dunning-Kruger-effect, in die zin dat ze ervan uitgaan dat ze "beter dan gemiddeld" zijn in hun eigen werk, ondanks elk bewijs dat die conclusie noodzakelijkerwijs ondersteunt.

Vanwege hun eigen overmoed in hun vaardigheden, gaan uw niet-professionele gebruikersonderzoekers (PM's, productontwerpers, leidinggevenden, enz.) — bijna altijd — de uitspraken van de gebruikers voor waar aannemen, zonder te begrijpen dat wat mensen zeggen en wat mensen doen, verschillend zijn.

Iedereen heeft overdreven veel vertrouwen in zijn eigen kunnen, of het nu gaat om het evalueren van gebruikersonderzoek als stakeholders of om het voorspellen van zijn eigen toekomstige gedrag als gebruikers die deelnemen aan gebruikersonderzoek.

Kwalitatieve gebruikersinterviews uitvoeren als enige methode van gebruikersonderzoek, zonder kwantitatieve bruikbaarheidstesten (het observeren en timen van uw gebruikers terwijl ze taken in uw product voltooien) is garbage in, garbage out.

Maar gebruikersinterviews "zien eruit als werk" en zijn veel leuker dan wat PM's eigenlijk zouden moeten doen, namelijk het identificeren van vereisten voor het product in samenwerking met stakeholders en ontwerpers, en vervolgens tickets schrijven.

PM's: Laat de **** weer aan het werk gaan en laat uw gebruikers met rust. (Ze hebben geen idee dat ze vol **** zitten en ze zullen het niet waarderen om het te horen!) Leidinggevenden: Huur afzonderlijke, professionele gebruikersonderzoekers in met als enige missie het verkorten van de tijd die gebruikers nodig hebben om taken te voltooien. Software-engineers: Sla het luisteren naar gebruikersinterviews over, aangezien de inhoud van die interviews eigenlijk helemaal niet nuttig zal zijn.

Engineers willen geen tijd verspillen aan activiteiten die geen waarde toevoegen; ze willen geen eindeloze, last-minute (“agile”?) wijzigingen in de product roadmap van gebruikersonderzoek; en ze willen niet de meeste tickets schrijven.

Daarom ben ik het eens met Steve Jobs en Henry Ford!

Je kunt kwalitatief consumentenonderzoek niet vertrouwen ("Wat wil je?"), alleen verkoop (omzet) en kwantitatieve timing van echte gebruikers die echte taken voltooien.

Veel plezier met coderen!

P.S. Laat me in de reacties weten of Steve Jobs iOS 18 zou hebben gehaat, zoals Macworld's hoofdredacteur Michael Simon suggereerde in een recent artikel: Waarom Steve Jobs De Grootste Functie Van Ios 18 Zou Hebben Gehaat - Startscherm en Control Center-aanpassing? Niet zozeer.

Vrij naar Dr. Derek Austin
www.macworld.com
Productiviteit || Technologie || Programmeren