MMarketingWiki
fogalom vázlat

Emberi hiba vagy rossz tervezés? (slip vs. mistake)

Más névenhuman error, emberi hiba, slip, mistake, csúszás, tévedés, action slip, memory lapse, capture slip, description-similarity slip, mode error, módhiba, rule-based mistake, knowledge-based mistake, root cause analysis, gyökérok-elemzés, five whys, öt miért, Swiss cheese model, svájci sajt modell, James Reason, learned helplessness, tanult tehetetlenség, taught helplessness, blame the user, resilience engineering, jidoka, poka-yoke, sensibility check, undo, checklist, paradox of automation, hindsight bias

A nyitó számadat. Az ipari balesetek 75–95%-át emberi hibának tulajdonítják. Norman érve egyszerű és megsemmisítő:

"How is it that so many people are so incompetent? Answer: They aren't. It's a design problem. If the number of accidents blamed upon human error were 1 to 5 percent, I might believe that people were at fault. But when the percentage is so high, then clearly other factors must be involved."

És az aszimmetria, ami a wiki mérés-oldalaira üt: "When a bridge collapses, we analyze the incident… and reformulate the design rules… But when an accident is thought to be caused by people, we blame them and then continue to do things just as we have always done."

A taxonómia (Norman és James Reason)

HIBA (error)
├── SLIP — a cél jó, a végrehajtás rossz (az alsó négy szakasz)
│   ├── action-based: rossz cselekvés jó tárgyon vagy jó cselekvés rossz tárgyon
│   │   ├── capture slip
│   │   ├── description-similarity slip
│   │   └── mode error
│   └── memory lapse: a szándékolt lépés kimarad
└── MISTAKE — a cél vagy a terv rossz (a felső három szakasz)
    ├── rule-based: jó a diagnózis, rossz a választott szabály
    ├── knowledge-based: rossz a diagnózis (hiányos vagy hibás tudás)
    └── memory-lapse: a cél vagy a terv felejtődik el

A hét szakaszra vetítve (→ seven-stages-of-action): a mistake a célképzésnél, a tervezésnél és a végső összehasonlításnál keletkezik, a slip a specifikálásnál, a végrehajtásnál, az észlelésnél és az értelmezésnél.

Paradox, és fontos: "slips… tend to occur more frequently to skilled people than to novices." Mert a szakértő automatikusan, tudatalatt csinálja; a kezdő odafigyel. A kezdő viszont több mistake-et vét, mert nincs modellje.

A három slip-típus, amit a tervezés okoz

Típus Példa Tervezési következmény
Capture Norman kollégája visszafordult a táskájáért, leállította a motort, és a karóráját csatolta ki a biztonsági öv helyett. Vagy: "1, 2, 3… 9, 10, Jack, Queen, King" fénymásolás közben (kártyázott előtte). A gyakoribb sorozat "elkapja" a ritkábbat, ha az elején azonosak. "Sequences should be designed to differ from the very start." Ne legyen két folyamatod azonos első lépésekkel.
Description-similarity A diák a kosárba szánta az izzadt pólót, és a WC-be dobta (más szobában volt, tehát nem célzási hiba): mindkettő "elég nagy tartály". A kezelőszervek és kijelzők különbözzenek egymástól. A pilótafülkében a gázkar, a fékszárnykar és a futóműkar formában is más (a futóműkaron kerék van).
Mode error Az Airbus-baleset: a rendszernek két üzemmódja volt — függőleges sebesség és süllyedési szög. A pilóták –3,3-at ütöttek be, szögnek szánva (−3,3° ≈ −800 láb/perc). A rendszer sebességmódban volt: –3300 láb/perc. Halálos baleset. Az Airbus utólag úgy módosított, hogy a függőleges sebesség mindig négy számjegy, a szög kettő. "Mode error is really design error." Kerüld a módokat; ha muszáj, tedd feltűnően láthatóvá, melyikben vagy.

Memory lapse — az ATM-példa tanulságos: a kártya bennfelejtése olyan gyakori volt, hogy a gépek kényszerítő funkciót kaptak: előbb a kártyát adják vissza, aztán a pénzt. Mert a célt (a pénzt) az ember nem felejti el, a mellékes lépést igen. → design-constraints

A gyökérok-elemzés és az "öt miért" kritikája

Ez a fejezet üt a legkeményebben a metrika- és menedzsmentoldali wiki-oldalakra.

A root cause analysis elve helyes, a gyakorlata elrontott: megáll, amint emberi hibát talál. "If a machine stops working, we don't stop the analysis when we discover a broken part. Instead, we ask: 'Why did the part break?'… We should do the same thing when we find human error."

Az F-22-eset. 2010-ben lezuhant egy F-22, a pilóta meghalt. A légierő vizsgálóbizottsága két évvel később pilótahibának minősítette: "failure to recognize and initiate a timely dive recovery due to channelized attention…". 2013-ban a védelmi minisztérium főfelügyelője megkérdezte, miért nem vették figyelembe a hirtelen eszméletvesztést (a típusnál pilóták sorozatban panaszkodtak oxigénhiányra). Norman paródiája:

Légierő: Pilótahiba volt — a pilóta nem tett korrekciós lépést. Főfelügyelő: Azért, mert valószínűleg eszméletlen volt. Légierő: Akkor egyetért: a pilóta nem korrigált.

Az öt miért (Toyoda Szakicsi, Toyota Production System). Norman használja, de három korlátot ír ki rá:

  1. A "miért?" kétértelmű — más vizsgáló más válaszhoz jut.
  2. Túl korán megáll — jellemzően ott, ahol a vizsgáló megértése véget ér.
  3. Egyetlen okot sugall, holott a komplex eseményeknek több, egymásra ható okuk van.

A svájci sajt modell (James Reason). A baleset akkor következik be, ha minden szeleten egy vonalba kerülnek a lyukak. Ebből két tanulság: (a) ne keresd "az" okot; (b) a rendszer ellenállóbbá tehető több szelettel, kevesebb és kisebb lyukkal, és azzal, hogy a különböző alrendszerek eltérő mechanizmusúak legyenek (hogy a lyukak ne tudjanak egy vonalba kerülni).

"It is relatively easy to find some action or decision that, had it been different, would have prevented the accident. But that does not mean that this was the cause."

Az elektromos művek esete — ez a bekezdés a szervezeti diagnózis: Norman átnézett több halálos áramütést. Minden vizsgálóbizottság a munkást találta hibásnak, és maguk a (túlélő) munkások sem vitatták. A javaslatai egyszerűek lettek volna, de a kultúrát kellett volna megváltoztatni: "We are supermen: we can solve any problem… We do not make errors." A jelentést udvariasan megköszönték. Évekkel később: "No changes. And we are still injuring people."

Miért hibáztatja magát a felhasználó (és miért ez a legdrágább)

  • A hallgatás összeesküvése. "Because everyone perceives the fault to be his or her own, nobody wants to admit to having trouble. This creates a conspiracy of silence." Norman egy nagy számítógépcégnél kimutatta, hogy a Return és az Enter összekeverése percek munkáját törli. A tervező: "Miért csinálta? Nem olvasta a kézikönyvet?" — és állította, hogy soha senki nem panaszkodott. Elmentek megkérdezni az alkalmazottakat: "Oh, yes, we do that a lot." Miért nem jelentették? Mert amikor a gép elromlott, jelentették; amikor ők tévesztettek, magukat hibáztatták.
  • Az attribúció megfordul. Normál esetben a saját hibánkat a környezetnek, a másokét a személyiségüknek tulajdonítjuk (fundamental-attribution-error). Technológiánál fordítva: a saját hibánkat magunknak. "This false blame is especially ironic because the culprit here is usually the poor design of the technology."
  • Tanult (és tanított) tehetetlenség. Ismételt kudarc után az ember feladja, és általánosít: "nem értek a technikához", "nem vagyok matekos". Norman szerint a matematikaoktatás és a rossz termékek szinte gyártják ezt: "We could call this phenomenon taught helplessness."

A marketinges fordítás. A vevő, aki magát hibáztatja, nem panaszkodik — tehát a hiba nem jelenik meg a támogatási statisztikában, a NPS-magyarázatokban vagy a churn-okokban. Csendben elmegy, vagy csendben nem használja a funkciót, amiért fizetett. A „nálunk kevés a panasz" ezért nem jó hír.punitive-vs-protective-brands, goodharts-law

Norman hitvallása a hibáról (a tervezőnek szóló lista)

  • Töröld az "emberi hiba" kifejezést. Beszélj kommunikációról és interakcióról: "what we call an error is usually bad communication or interaction". Két ember beszélgetésében nem "hibázik" a másik — visszakérdezünk, tisztázunk, folytatjuk.
  • Ne hibáztasd az embert, ha nem tudja jól használni a terméket.
  • A nehézségeket vedd jelölőnek arról, hol javítható a termék.
  • Töröld az összes hibaüzenetet — adj helyettük segítséget és útmutatást.
  • A segítő üzenetből lehessen azonnal javítani, és a munkát lehessen folytatni. Soha ne kelljen elölről kezdeni.
  • Tételezd fel, hogy amit az ember csinált, részben helyes, és adj útmutatást a javításához.

Tervezési válaszok

Eszköz Mit old meg Megjegyzés
Undo (többszintű) mindent, ami visszafordítható "Perhaps the most powerful tool to minimize the impact of errors."
Sensibility check mistake-ek nagyságrendi hibái Ha ezerszeres sugárdózist vagy egymillió dolláros utalást kérnek, a rendszer kérdezzen vissza — a bank ismeri a szokásos tranzakcióméretedet. Ma is halnak meg emberek amiatt, hogy az infúziós pumpa "engedelmesen" beadja a beütött értéket.
Confirmation slipet igen, mistake-et alig A megerősítő ablak akkor működik, ha a cselekvés meglepetés volt (Shift+W helyett Cmd+W). Ha viszont szándékos volt, csak a tárgy rossz, a felhasználó el sem olvassa. Megoldás: a tárgyat tedd kiemeltté (nagyítás, szín), ne a cselekvést — és tedd visszafordíthatóvá.
Checklist, kettesével slip és memory lapse Az egyedül végzett, majd utólag ellenőrzött lista gyengébb: mindkét fél lazít. Együtt kell csinálni (egy olvas, egy végez, az első ellenőriz). Repülésben kötelező; az orvoslás hevesen ellenállt ("sértés a szakmai kompetenciára"). A nyomtatott lista hibája, hogy sorrendet kényszerít — az elektronikus jelölni tudja a kihagyott tételt.
Jidoka (Toyota) a hiba jelentése Bárki megállíthatja a sort; a szakértők odamennek és megkeresik a valódi okot. Aki nem jelent hibát, azt megbüntetik.
NASA ASRS a jelentés társas költsége A pilóta félanonim jelentést küld a NASA-nak (nem a munkáltatónak, nem az FAA-nak); a NASA a kapcsolati adatokat visszaküldi, így már nem tudja, ki írta — és a beküldés automatikus mentességet ad kisebb szabálysértés esetén. Az orvoslásban nincs ilyen semleges szerv.
Resilience engineering a nem várt Nagy szolgáltatók szándékosan kapcsolnak le éles rendszereket, hogy leteszteljék a tartalékot. "Safety shows itself only by the events that do not happen!" (Hollnagel–Woods–Leveson) → robustness-and-redundancy

A megszakítás, a multitasking és a társas nyomás

  • A megszakítás a memóriahibák fő oka, és a költsége nem a megszakítás ideje, hanem a visszatérés: mi volt a cél, hol tartottam, milyen állapotban van a rendszer. A legtöbb szoftver eldobja pont azt az információt, ami ehhez kellene.
  • A multitasking mérhetően ront. Hyman és mtsai (2010): mobilozás séta közben — a mobilozók lassabban mentek, többször irányt váltottak, kevésbé vették észre a többi embert, és kevésbé vették észre az egykerekűn tekerő bohócot az útvonalon.
  • "Sterile Cockpit" — az FAA a felszállás és a leszállás alatt tiltja a repüléshez nem kapcsolódó beszélgetést a pilótafülkében. Norman ugyanezt javasolja az orvoslásba (és a saját autójában is alkalmazza az autópálya fel- és lehajtóknál). → switch-cost-and-multitasking, flow-and-deep-attention
  • Tenerife, 1977 (583 halott) és Air Florida, 1982 (78 halott): mindkettőben idő- és gazdasági nyomás + a hierarchia. Az Air Florida esetében az elsőtiszt négyszer jelezte a kapitánynak felszállás közben, hogy "valami nem stimmel" — a kapitány nem szakította meg. A KLM kapitánya a cég legtekintélyesebb pilótája volt; az elsőtiszt halkan tiltakozott.
  • A búvároktató megoldása a társas nyomásra: nyilvánosan megdicsérte és ingyen pótolta azt, aki biztonsági okból eldobta a drága ólomsúlyát — mert a búvárok szégyellték volna, ha utólag kiderül, hogy nem volt rá szükség, és inkább megfulladtak.

Az automatizálás paradoxona

"Automation can take over the dull, dreary tasks, but fail with the complex ones" — vagyis épp akkor mond fel, amikor a legnagyobb szükség lenne rá, és rendszerint figyelmeztetés nélkül. Ilyenkor az ember "out of the loop": időbe telik észrevenni, felmérni és dönteni. Repülőn 10 km magasan van rá néhány perc; autóban töredékmásodperc, és a sofőr nincs kiképezve.

A Royal Majesty (1997) esete: a GPS-antenna kábele lecsúszott (soha nem derült ki, hogyan), a navigációs rendszer halkan átváltott becsült helymeghatározásra ("dr" két apró betűvel a kijelzőn), és a hajó Bermudától Bostonig napokig rossz pozíción haladt, míg zátonyra futott a Cape Codnál, több millió dolláros kárral. Mode error, észrevehető visszajelzés nélkül, évekig hibátlan automatika után felépült bizalommal.

Norman jóslata: az önvezető autó csökkenteni fogja a balesetek számát — "but that when there is an accident, it will be huge".

És mikor tényleg az ember hibázik?

Norman nem naiv: "Sometimes, people really are at fault." Alvásmegvonás, alkohol, kábítószer, hiányzó képesítés, valamint a szándékos szabályszegés (deliberate violations), ami "a hibairodalomban jellemzően kimarad, a balesetirodalomban viszont központi". A szabályszegés rutinná válik, ha a szabály betartásával a munka nem végezhető el — és a sikeres szabályszegőt megjutalmazzák. "Cultures that encourage and commend violations set poor role models."

Az arányokról viszont egyértelmű: "because people occasionally are at fault does not justify the attitude that assumes they are always at fault."

Hogyan alkalmazd (marketing- és termékkontextus)

  1. Minden churn-, panasz- és support-adatot olvass át ezzel a szűrővel: amit "felhasználói hibaként" zártak le, ott a vizsgálat a felénél állt meg.
  2. Kérdezd meg, hogy slip vagy mistake. Slipnél a felület a hibás (hasonló gombok, közös első lépések, rejtett mód); mistake-nél a modell hiányzik vagy hamis (conceptual-model).
  3. Ne "képezd" a vevőt. A tanítás a mistake ellen néha segít, a slip ellen soha. "Teaching me the relationship will not stop the error from recurring: redesigning the stove will."
  4. A megerősítő ablakot a tárgyra tedd, ne a cselekvésre, és mindenhol ahol lehet, adj Undót.
  5. Vezesd be a saját "jidokádat": legyen olcsó és jutalmazott jelenteni, hogy valami nem működik — belül is, kívül is. A hiba, amit nem jelentenek, megmarad.
  6. Nézd meg a nagy számot. Ha a "felhasználói hiba" a te rendszeredben is 75% fölött van, az a rendszerről szól.

Feszültségek

  • Goodhart törvénye (goodharts-law) — ez a legfontosabb kapcsolódás. Ha a mutató "az emberi hibák száma", és a válasz "hibáztatás és képzés", a szervezet a jelentések számát fogja optimalizálni, nem a hibákét: a csendes hibaelhallgatás pontosan olyan patkányfarok, mint Hanoiban. Hollnagelék ugyanezt mondják: "a paradigm of tabulating error as if it were a thing, followed by interventions to reduce this count" — a rezilienciamérnökség kifejezetten ez ellen van. A wiki állása: a hibaszám mint cél Goodhart-áldozat; a mérendő a rendszer helyreállási képessége, nem az incidensszám.
  • Taleb (silent-evidence, narrative-fallacy, black-swan-events). A hindsight bias (Fischhoff: az utólag ismert kimenetel valószínűnek tűnik, előre senki nem találja el) Norman változatában pontosan Taleb narratív tévedése, baleseti kontextusban: "During an incident, there are never clear clues… Things that appear irrelevant will turn out to be critical." A svájci sajt = a többokú rendszer, amiben nincs "az" ok. Erős egyezés két teljesen különböző szerző közt.
  • Cialdini és a tekintély (authority, influence). A Tenerife- és Air Florida-eset a hierarchia halálos oldala; Cialdini a tekintélyt meggyőzési elvként írja le, Norman rendszerkockázatként. A repülés válasza (CRM, checklist, kötelező kifogásolás) a wiki egyetlen dokumentált ellenszere a tekintély-heurisztikára.
  • Eyal és a "friction" (friction-and-least-effort, hook-model). A súrlódás eltávolítása és a kényszerítő funkció beépítése ellentétes irányba mutat. A feloldás Normané: a súrlódás a gyakori, visszafordítható cselekvésnél ellenség, a ritka, visszafordíthatatlan cselekvésnél barát.
  • Módszertani fenntartás. A "75–95%" idézett becslés, forrásmegjelölés nélkül a fejezetben. Az F-22, a Royal Majesty, Tenerife és az Air Florida hivatalos vizsgálati jelentésekre épül (NTSB, DoD IG); a slip-tipológia mögött lektorált szakirodalom áll (Reason: Human Error, 1990). Az elektromos művek esete és a Return/Enter-történet a szerző anekdotája, névtelen céggel. A könyv érvelő mű, nem kontrollcsoportos kutatás — az "emberi hiba = rossz tervezés" tétel logikai és etikai állítás, nem mért eredmény.

Kapcsolódó

the-design-of-everyday-things · don-norman · seven-stages-of-action · conceptual-model · design-constraints · natural-mapping · feedback-and-feedforward · norman-design-principles · human-centered-design · goodharts-law · fundamental-attribution-error · silent-evidence · narrative-fallacy · robustness-and-redundancy · punitive-vs-protective-brands · switch-cost-and-multitasking · authority