Zure talde teknikoak funtzionatzen duela uste du. Erabiltzaileak, agian, ez

Oso ohikoa da talde digitaletan: funtzionalitatea stagingean egiaztatu da, testua onartu da, diseinua egokia da eta denek prest dagoela uste dute. Teknikoki, funtzionatzen du. Marketinaren ikuspegitik, itxura ona du. Baina benetako erabiltzaileak ekoizpenera iristen direnean, istorioa aldatu egiten da: hautsitako esteka bat, irudi astunegia, formulario geldoa, AJAX errore bat edo JavaScript akats batek esperientzia eteten du.

Desoreka hori ia inoiz ez da arduragabekeriaren ondorio. Pentsamendu arriskutsu batetik dator: barne-balidazioa benetako esperientziaren parekoa dela sinestea. Barne-probak ezinbestekoak dira, baina ezin dituzte guztiz erreproduzitu zuzeneko trafikoaren baldintzak; han nabigatzaileak, gailuak, sareak, kanpainak eta erabilera-testuinguruak askoz ere anitzagoak dira.

Kontrol-sentsazio faltsua

Barne-probek zerbait baliotsua ematen dute: konfiantza. Arazoa konfiantza hori estaldura osoarekin nahasten denean hasten da. Ekoizpenean, webgunea ez da ingurune garbi eta aurreikusgarri batean bizi. Nabigatzailearen aldeak, cache-egoerak, konexioaren kalitatea, luzapenak, sistema eragileak eta pantaila-ebazpenak erabiltzaileak ikusten eta sentitzen duena erabat alda dezakete.

Kontrol-sentsazio faltsua normalean hiru arrazoirengatik agertzen da. Lehenik, proba-ingurunea errealitatea baino sinpleagoa delako. Bigarrenik, egiaztatutako eszenatokiak mugatuak direlako. Hirugarrenik, taldeek zerbait kargatzen den ala ez galdetzen dutelako, eta ez zer gertatzen den huts egiten duenean.

Adibide erraza: orri bat bulegoko ordenagailuan primeran ireki daiteke, baina benetako trafikoaren zati bati baliabideak kargatzean erroreak sortu. Edo kanpaina-URL bat zuzen ager daiteke berrikusketan eta, hala ere, ekoizpenean hautsia egon konfigurazio-arazo baten ondorioz. Barrutik dena ondo zirudien. Erabiltzailearentzat, ez.

Barne-probak baliagarriak dira, baina ez nahikoak

Barne-probak lehen babes-lerroa dira. Akats nabariak detektatzen, aldaketak balioztatzen eta regresioak murrizten laguntzen dute. Taldeak ere lerrokatzen dituzte abiaraztearen aurretik: garapena, marketina, produktua eta diseinua oinarri komun berean lan egiten dute.

Baina haien irismena mugatua da. Ez dago gailu, nabigatzaile, konexio-abiadura eta trafiko-iturrien konbinazio guztiak erreproduzitzerik. Bulegoko konexio egonkorrarekin ondo dabilen orri batek oso bestelako portaera izan dezake sare ahulagoan dagoen mugikorretik sartzen den bisitariarentzat. Irudi bat pantaila batean ondo neurtuta egon daiteke eta beste batean handiegia izan. Akats bat baldintza jakin batzuen konbinazio zehatz batean bakarrik ager daiteke.

Horregatik, benetako arriskua ez da barnean probatzea. Arriskua da hori nahikoa dela sinestea.

Zer aldatzen da benetako erabiltzaile-esperientzian

Benetako esperientziak sarri kontuan hartzen ez diren aldagaiak sartzen ditu. Webgune batek laborategian TTFB onargarria izan dezake eta zenbait eskualdetan moteldu. Eduki dinamikoa duten orrietan CLS ezegonkorra erakutsi dezake. Erabilgarria bihurtzeko denbora gehiegi behar izan dezake, nahiz eta karga osoaren denbora arrazoizkoa izan. Eta erabiltzaileak marruskadura gisa sumatzen dituen errore ikusezinak pilatu ditzake.

Gainera, ez dute arazo guztiek pisu bera. Bigarren mailako orri batean dagoen akats txiki batek ez du kanpaina-landing batean dagoen esteka hautsi batek edo bihurketa-urrats batean dagoen JavaScript errore batek bezainbesteko eraginik. Testuinguruak eta maiztasunak zehazten dute eragina.

Horregatik, erakunde askok ulertzen dute “funtzionatzen du” ez dela nahikoa. Benetako galdera hau da: erabiltzaile egokientzat, une egokian eta ahalik eta marruskadura txikienarekin funtzionatzen al du?

Nola pasa intuiziotik ebidentziara

Desberdintasun hori murrizteko modurik praktikoena barne-probak ekoizpen-datuekin osatzea da. Helburua ez da bata bestearekin ordezkatzea, baizik eta aurreko balidazioa eta benetako portaera lotzea. Horrela, benetako trafikoarekin bakarrik agertzen diren arazoak identifikatu daitezke.

Hasi galdera sinpleekin:

• Zein akatsek eragiten diete benetan erabiltzaileei, eta ez soilik proba-inguruneari?
• Non pilatzen dira: nabigatzailea, sistema eragilea, ebazpena edo bisitaren jatorria?
• Zein orri edo kanpainek sortzen dute eragin handiena zerbait huts egiten duenean?
• Zein arazo landu behar da lehenik, esperientziari gehien kalte egiten diolako?

Galdera horiei erantzuteko, webgunea erabiltzailearen ikuspegitik begiratu behar da, ez soilik barne-taldearenetik. Maila horretan, Real User Monitoring-ek eguneroko produktu-errealitatetik hurbilago dauden seinaleak eman ditzake.

Eraginaren arabera lehenetsi, ez intuizioaren arabera

Arazo guztiak berdin tratatzea da akatsik garestienetako bat. Talde batek orduak eman ditzake jende gutxiri eragiten dion xehetasun bisual batean, eta aldi berean trafikoaren zati kritiko bati eragiten dion karga-errorea alde batera utzi. Lehentasunak aldatu egin behar dira eragina aldatzen denean.

Horregatik, erabilgarria da erroreak multzokatzea eta kategorizatzea, haien maiztasuna neurtzea eta bisitaren testuinguruarekin lotzea. Era berean, lagungarria da trafiko-jatorriaren arabera hautsitako estekak detektatzea, handiegiak edo txikiegiak diren irudiak identifikatzea eta TTFB, CLS, erabilgarri dagoen denbora eta karga osoaren denbora bezalako metrikak aztertzea. Ez dashboardak betetzeko, baizik eta hobeto erabakitzeko.

Elkarrizketa “zer dirudi gaizki”tik “zerri eragiten dio gehien erabiltzaileei”ra pasatzen denean, taldeak argitasuna irabazten du. Eta argitasun horrek garapenaren, marketinaren eta produktuaren arteko zarata murrizten du.

Erabakitzeko irizpide fidagarriagoa

Barne-proben eta benetako erabiltzaile-esperientziaren arteko aldea ez da ñabardura tekniko bat. Perspektiba-aldea da. Barne-probek arazoak prebenitzen laguntzen dute. Ekoizpeneko behaketak lehenesten laguntzen du. Elkarrekin, oinarri sendoagoa ematen dute errendimenduari, erroreei eta kalitate digitalari buruz erabakitzeko.

Zure webguneak proba-ingurunean funtzionatzen badu baina errealitateak beste zerbait esaten badu, hurrengo pausoa ez da erabiltzaileak moldatuko direla suposatzea. Baizik eta hobeto neurtzea zer gertatzen den, zein testuingurutan gertatzen den eta zenbat pisatzen duen benetan.