Kā atpazīt un pārvaldīt UX parādu

Lietotāju pieredzes parāds neizbēgami notiek laika gaitā. Tā ir summa novēloti dizaina un izmantojamības uzdevumi izriet no tādām lietām kā ātrs biznesa lēmums, dizaina īsceļi, neizmantotās iespējas, laika ierobežojumi un citi faktori.

Lietotāju pieredzes parādu sauc par parādu, jo tas ir līdzīgs reālajam parādam; mēs saņemam kaut ko tagadnē, bet tikai maksā par to nākotnē. Kamēr parāds netiek atmaksāts, procentu likmes rodas kā pastāvīgas izmaksas.

Lietotāju pieredzes parāds - kopā ar tuvu brālēnu, tehnisko parādu - ir a dizains antipattern, kas samazina projekta kvalitāti. Tā kā lietotāju pieredzes parāds ir mazāk plaši apspriests temats, turklāt ne vienmēr ir viegli to atpazīt, šajā rakstā mēs to aplūkojam tuvāk.

Tehniskais parāds pret UX parādu

Tīmekļa izstrādē ir dažādi parādu veidi. Vispazīstamākais ir tehnisko parādu tas ir definēts CSS triki kā "summa kompromisus mēs izstrādājam, ierakstot kodu izstrādes procesa laikā..

Vēlāk mūsu darbplūsmā mums būs jārisina šo kompromisu sekām, kas nozīmē papildu darbu nākotnē.

Tehniskais parāds nav saistīts ar tiešām kļūdām, bet gan par to, ka pat ar labākajiem kodēšanas paņēmieniem nav iespējams pilnībā nodrošināt nākotnes kodu, tomēr efektīva kodu optimizācija noteikti var palīdzēt.

Izmantojot antipatternus, kodēšanas īsceļus, neefektīvu arhitektūru vai grūti pārvaldāmās atkarības, visi var veicināt tehnisko parādu, bet ir svarīgi, ka pat optimālā, hipotētiskā ideālā scenārijā to nav iespējams izvairīties - kā turpmākās nesaderības, vajadzības un problēmas ir neprognozējamas. Tāpēc pēc kāda laika ieteicams veikt refaktoru.

Lietotāja pieredzes parāds ir līdzīgs tehniskajam parādam tādā nozīmē, ka:

• nevar izvairīties (kaut arī to var samazināt)
• ir grūti atpazīt
• var apdraudēt projekta panākumus.

Lietotāja pieredzes parāds ir plašāka kategorija nekā izmantojamības parāds, tā nav tikai par to, kā tīmekļa vietne vai lietojumprogramma ir izmantojama, bet arī par to veids, kā lietotāji izjūt jūsu produktu - vai viņi uzskata, ka tas ir izklaidējošs, noderīgs atalgojums vai kāda sajūta, ko vēlaties izmantot jūsu mērķauditorijā.

Lietotāju pieredze ietver lietojamību, jo grūti lietojama vietne nepadara lietotājus justies ērti un tādā pašā veidā, arī UX parāds ietver arī lietojamības parādu.

Diemžēl nav daudz tiešsaistes resursu par lietojamības parādu un lietotāju pieredzes parādu, bet šeit ir daži, kas ir noderīgi, un palīdzēja man veidot savu viedokli par šo tēmu:

• Catriona Cornett, SalesforceIQ produktu dizaina direktors kā efektīvi risināt lietojamības parādu (lasiet šeit)
• TryMyUI ir emuārs par kā izvairīties no UX parādu krīzes (lasiet šeit)
• Lietotāju pieredzes profesionāļu asociācija par viņu pieeju UX parādam ar ieteikumu kā aprēķināt tā apjomu (lasiet šeit)
• Andrew Wright ir UX parāda skaidrojums un klasifikācija vietnē nForm (lasiet šeit)

Starp visām iespējamām ilustrācijām, kuras es varētu atrast par UX parādu, šī ir diezgan labākā izvēle, jo es domāju, ka tas īsi parāda tās būtību.

Lietotāja pieredzes parādu var definēt kā atšķirība starp jūsu pašreizējā un optimālā produkta kvalitāti.

UX parāds ir subjektīvāka nekā tehniskais parāds, tā kā jūs (vai jūsu klients) esat nolēmis, kādu kvalitāti vēlaties sasniegt. Piemēram, varat atlasīt "funkcionāls" minimālais dzīvotspējīgs produkts, bet jūs varat arī noteikt augstus (bet parasti dārgus) standartus mērķauditorijas atlase "patīkams" līmenis augstākās kvalitātes produktam - tas viss ir atkarīgs no jūsu mērķiem.

Tehniskais parāds ir atšķirīgs tādā nozīmē, ka daudzos gadījumos vāji pārvaldītais kods vienkārši pārtrauc darbu. Ar UX parādu ir šādas krasas izmaiņas nav, tomēr tas nav tikai nopelns, bet arī drauds šāda veida parāds ir vieglāk nolaidīgs.

Kā atpazīt UX parādu

Lai pārvaldītu UX parādu, vispirms mums tas ir jāatzīst. Ir divu veidu UX parāds - tīši un netīši.

1. Nodomu UX parāds ir mūsu apzināto lēmumu rezultāts kad mēs trūkst naudas, laika, apmācības, vai citiem resursiem vai kad mēs esam spiesti ievērot ārējos noteikumus. Labas idejas, ko mēs zaudējam straujā darba vidū, arī veicina tīšu UX parādu.
2. Tas ir viegli redzēt, ka tīrais UX parāds var notikt jebkurā laikā produkta dzīves cikla laikā.
3. Neparedzēts UX parāds rodas no kļūdainiem pieņēmumiem, ko mēs darām par mūsu lietotājiem. Biežāk nekā parasti mēs domājam, ka mēs zinām, ko mūsu lietotāji vēlas, piemēram, vai var izmantot, un mēs izveidojam visu mūsu vietni (lietotni, produktu utt.) paredzamās zināšanas.
4. Labā netīša UX parāda summa rodas produkta dzīves cikla sākums, un tā dabiski pieaug laika gaitā. Neparedzētais UX parāds ir daudz grūtāk noķert, kā tas ir nepieciešams atbrīvoties no mūsu nepieciešamības pamatot savus pieņēmumus.

Tātad, kā UX parāds izskatās reālajā dzīvē? Ja lietotāji nevar vai nevēlas izmantot mūsu vietni sliktas lietotāju pieredzes dēļ. Viņi vienkārši neiesaistieties; mēs nevar nozvejot savu uzmanību un interesi.

UX parādu izpausme dažādās vietnēs atšķiras, bet, ja mums ir a samazinot konversijas likmi vai pieaugošais lielums vairumā gadījumu mums ir aizdomas, ka esam uzkrājuši jauku summu UX parādam.

Kā pārvaldīt UX parādu

Tur ir nav universālas receptes efektīvi pārvaldīt UX parādus, jo daudzas lietas ir atkarīgas no subjektīvajām iezīmēm, tomēr ir vērts aplūkot, kā citi šo problēmu risina, lai atrastu savu ceļu.

Piemēram, Catriona Cornett, SalesforceIQ produktu dizaina direktors parāda piecpakāpju procesu, ko viņi izmanto, lai pārvaldītu lietojamības parādu SalesforceIQ.

Redzēsim to īsi, lai mēs varētu novērtēt, cik labi mēs varam to piemērot mūsu pašu darbplūsmai.

1. Definējiet a kopīga valoda par lietojamības jautājumiem.
2. Atrast un savākt lietojamības problēmas.
3. Organizēt un klasificēt lietojamības problēmas.
4. Prioritātes lietojamības uzlabojumi.
5. Pasākums uzlabojumu ietekmi.

Lietotāju pieredze ir plašāka teritorija nekā lietojamība, bet es domāju, ka iepriekšminētā darbplūsma var to efektīvi piemērot.

Andrew Wright nāk ar nedaudz atšķirīgu vadības darba plūsmu viņa UX parādu prezentācijā, un viņš iesaka 4 pakāpju procesu, lai risinātu UX parādu.

1. Noteikt ja un kur UX parāds pastāv.
2. Salīdzināt svarīgumu.
3. Padariet laiku to salabot.
4. Socialize koncepts.

Nepieciešams arī rīkoties ar tīšu un netīšu UX parādu dažādas metodes. Īsceļus, ko mēs apzināti izgatavojam, un labas idejas, kas pazūd procesa laikā, var pārvaldīt piezimju nemsana, uzdevumu pārvaldība, vai problēmu izsekošana lietotnes.

Nejaušu UX parādu var vairāk vai mazāk pārvarēt, regulāri darbojoties lietotāju pārbaudes, lūdzot klientu atsauksmes, vai izmantojot uzlabotas metodes, piemēram, A / B testēšanu, lai redzētu dažādu dizainu ietekmi.

Pieteikšanās principiem iteratīvs dizains var būt arī noderīga; mēs varam veidot mūsu UX parādu pārvaldības pasākumus katrā iterācijā, lai novērstu tā uzkrāšanos.

UX parādu pārvaldībai ir nepieciešams iekļaujas mūsu plašākā darbplūsmā, ar mūsu komandas īpašībām, mūsu mērķiem un mūsu produkta raksturu, bet ir daži universālas lietas tas ir ieteicams ievērot visos gadījumos.

1. Mums vajag sazināties visā mūsu komandā kāpēc mums ir jārisina UX parāds, kādi ir mūsu mērķi, un kā mēs vēlamies paveikt tiem.
2. Mums ir jāatrod rīki izsekot apzinātu UX parādu.
3. Mums ir jāatrod veidi, kā pārbaudīt mūsu produktu un saņemt atsauksmes no mūsu lietotājiem nozvejot netīšu UX parādu.
4. Mums vajag organizēt un prioritāti mūsu jautājumiem.
5. Mums vajag pasākums mūsu darba rezultāti, kā mums vienmēr ir nepieciešams pielāgot UX parādu pārvaldība atbilstoši mūsu mainīgajām vajadzībām.

Galīgie vārdi

Lai radītu kvalitatīvus produktus, mums ir ne tikai jābūt inovatīviem, bet arī jāpievērš uzmanība lietām, kas nav tik acīmredzamas no pirmā acu uzmetiena, viens no tiem ir UX parāda atzīšana un efektīva pārvaldība. Iespējams, tas nav visinteresantākais uzdevums, bet tas ir ļoti svarīgi, jo laika gaitā UX parāds var būt nopietns drauds mūsu darba panākumiem.

Ja mēs sagriežam UX parādu pārvaldāmus gabalus, un integrēt saistītos uzdevumus mūsu darbplūsmā, mums vienlaicīgi nav jādara pārāk daudz, mēs varam izvairīties no nepatīkamiem pārsteigumiem un ērti uzturēt vai uzlabot produkta kvalitāti..