Որո՞նք են պրոդուկտում մեծ փոփոխությունների գլխավոր ռիսկերը:

Որո՞նք են պրոդուկտում մեծ փոփոխությունների գլխավոր ռիսկերը:

Հնարավոր պատասխաններ (10)

Ամենաօգտագործվող ֆունկցիաներում ցանկացած փոփոխություն կպատճառի սուր արձագանք։ Այս խնդիրը կանխելու համար պետք է օգտատերերին աստիճանաբար պատրաստել փոփոխություններին, որպեսզի դրանք չլինեն անակնկալ (
Եթե մրցակիցները մեր լայնածավալ փոփոխությունների ընթացքում գործարկեն արշավներ «ակնթարթային բոնուսներով», մենք ռիսկի կենթարկենք օգտատերերի մի մասին կորցնելու։ Սա նաև պատճառներից մեկն է, թե ինչու չարժե ժամանակից շուտ հայտարարել կարևոր թողարկումների մասին։
Եթե փոփոխությունների անհրաժեշտությունը բացատրում ենք միայն «նորության» գործոնով, շատերը դա չեն ընդունի։ Նույնիսկ եթե փոփոխությունների պահանջը եկել է հենց օգտատերերից, նրանք կարող են դժգոհ մնալ։
Եթե փոփոխությունները լիովին համահունչ են պրոդուկտի համատեքստին, կարելի է դրանք բաժանել փոքր մասերի և ներկայացնել փուլերով՝ օգտատերերի անհարմարությունը նվազագույնի հասցնելու համար։
Եթե պրոդուկտի փոփոխությունները վերաբերվում են դրա գաղափարախոսական կամ տերմինաբանական մասերին, պետք է համոզվել, որ դրանք համահունչ են օգտատերերի համոզմունքներին։ Ամենապարզ օրինակը՝ եթե բաց կոդով (open-source) ծրագրավորողների խումբը սկսի վաճառել իրենց լուծումը, դա կհակասի իրենց լսարանի արժեքներին:
Օգտատերերը կարող են ցանկանալ տեսնել փոփոխությունների «մինչև» և «հետո» տարբերակները։ Եթե դա տեղին է, կարող ենք ներկայացնել փոփոխությունները այդ տեսքով։ Եթե ոչ, կարելի է փոփոխությունները ներկայացնել մաս-մաս՝ համեմատությունը դժվարացնելու համար։
Կարելի է հրապարակել մի քանի հոդված՝ կապված սպասվող փոփոխությունների հետ՝ լսարանի արձագանքը վերլուծելու համար։ Սա կօգնի հասկանալ, թե ինչն է առավել անհանգստացնում օգտատերերին։ Մենք կարող ենք օգտագործել այս տեղեկատվությունը ապագա փոփոխությունների նկատմամբ բացասական արձագանքները մեղմելու մեխանիզմներ ստեղծելու համար:
Անհրաժեշտ է ստեղծել նոր ֆունկցիոնալությունը օգտագործելու չափազանց պարզ հրահանգներ։ Այն ամենը, ինչ հնարավոր է պարզեցնել ինտերֆեյսում, պետք է պարզեցվի։ Եթե ​​պրոդուկտի առանձնահատկությունը թույլ է տալիս, մենք կարող ենք ստեղծել ֆունկցիոնալության երկու տեսողական ներկայացում (Ստանդարտ և Ընդլայնված տեսք): Սա կարող է լինել ժամանակավոր լուծում, քանի դեռ օգտատերերը ծանոթ չեն հիմնականին։
Նույնիսկ այն ֆունկցիաները, որոնք պրոդուկտի օգտատերերը հազվադեպ են օգտագործում, նրանք ընկալում են որպես «իրենց սեփականություն»։ Նման ֆունկցիաների չհիմնավորված փոփոխությունները կարող են սուր արձագանք առաջացնել, որը կարող է թվալ ոչ համաչափ ֆունկցիայի օգտագործման քանակին ():
Մենք բոլորս ինտուիտիվ կերպով հասկանում ենք էական փոփոխությունների ռիսկերը: Սովորաբար, եթե մենք որոշում ենք դրանք, ապա պրոդուկտի ապագան վերածվում է զրոյական գումարի խաղի, որտեղ մենք կամ ստանում ենք ամեն ինչ, կամ ոչինչ: Սովորաբար, նման որոշումների դեպքում կարևոր է ստուգել մեր ենթադրությունները թիմի մյուս անդամների հետ՝ սխալներից խուսափելու համար։ Այսպիսով, մենք կարող ենք սխալվել ենթադրությունները մեր լսարանի «աշխարհի» սխալ ընկալման պատճառով ( , ), մեր գոռոզության ( , ) կամ մեր կույր հավատքի պատճառով՝ ինչպես «Մենք այնքան ջանք ենք թափել, որ արժանի ենք հաջողության» ( ):

Առնչվող հարցեր

Որքա՞ն օգտակար էր այս տեղեկությունը:
Անօգտակար
1
2
3
4
5
6
7
8
9
10
Անօգտակար
Շատ օգտակար
Շնորհակալություն ձեր ներդրման համար
previous bias
next bias
keepsimple logo
picՄուտք
Իմ պրոֆիլըԿարգավորումներԵլք
Օգտակար հղումներ

UX CORE GUIDE

arrow downԻնչպես օգտագործել

UXCG-ն անվճար գործիք է, որն օգնում է թիմերին հայտնաբերել կոգնիտիվ հակումների հետ կապված UX խնդիրները պրոդուկտի բոլոր փուլերում՝ սկսած պրոտոտիպավորումից և թեստավորումից մինչև գործող պրոդուկտի բարելավում:

Ինչպես օգտագործել UXCG

  1. Ընտրեք Ձեր պրոդուկտի փուլը ստորև
  2. Ընտրեք Ձեզ հետաքրքրող հարցը
  3. Կարդացեք հնարավոր պատասխանները:

Յուրաքանչյուր պատասխան բացատրում է, թե ինչպես են կոգնիտիվ հակումները կապված Ձեր կոնկրետ իրավիճակի հետ։ Քանի որ դուք լավագույնս եք հասկանում Ձեր համատեքստը, կարող եք ուղղակիորեն կիրառել ստացված գիտելիքները։ Թեև գործիքը պատրաստի լուծումներ չի տրամադրում՝ յուրաքանչյուր դեպքի յուրահատկության պատճառով, այն բացահայտում է նոր տեսանկյուններ՝ հիմնված կոգնիտիվ գիտության վրա։

Պիտակի նկարագրությունը
Հարցեր ներքին թիմային համագործակցության մասին (պրոդուկտի թիմի, տեխնիկական թիմի և այլ բաժինների միջև)։
Հարցեր պրոդուկտի մշակման փուլերի մասին (սկսած գաղափարից մինչև առաջին հանրային թողարկում)։
Հարցեր վաճառքների, մարքեթինգի, պոտենցիալ հաճախորդների հետ հաղորդակցության և ընդհանուր առմամբ պրոդուկտի փաթեթավորման մասին։
Հարցեր իրական պրոդուկտի և նրա ֆունկցիոնալության օգտագործման մասին։
Պրոդուկտի վերլուծական տվյալների մշակում:
search icon
Ընտրեք ձեր պրոդուկտի փուլը
#10.

Օգտատերերը բողոքում են մեր սպասարկման ծառայության որակից։

#30.

Ի՞նչ սխալներ ենք թույլ տալիս պրոդուկտի վերլուծական տվյալների հետ աշխատելիս։

#41.

Ի՞նչ անել երբ մեր գործընկերների համառությունը վնասում է աշխատանքին։

#43.

Ի՞նչ հաշվի առնել, երբ պլանավորում ենք պրոդուկտի թողարկումներ։

#45.

Ի՞նչ անել, եթե մեր թիմի որոշ անդամներ չեն արտահայտում իրենց կարծիքը։

#50.

Ինչպե՞ս աշխատել ոչ կոմպետենտ գործընկերոջ կամ ղեկավարի հետ:

#59.

Ի՞նչ պետք է հաշվի առնել ընկերության տեքստերում/պրոդուկտում քաղաքական, սոցիալական կամ տնտեսական իրադարձություններ մեկնաբանելիս։

#61.

Ի՞նչ անել երբ մեր թիմը չափազանց շատ ժամանակ է ծախսում անտեղի/աննշան մանրամասներ քննարկելու վրա։

Be Kind. Do Good.