Ի՞նչ հաշվի առնել, երբ պլանավորում ենք հեռացնել պրոդուկտի ավելորդ ֆունկցիոնալությունը։
English
Armenian
Russian
Ի՞նչ հաշվի առնել, երբ պլանավորում ենք հեռացնել պրոդուկտի ավելորդ ֆունկցիոնալությունը։
Պատճենել URL-ըՊատճենված է
Կիսվել
Հնարավոր պատասխաններ (12)
Պետք է հասկանալ, թե ինչպես են օգտատերերը վերաբերվում հեռացվող ֆունկցիոնալությանը։ Մեր անձնական կարծիքը կարևոր չէ։ Պետք է թիմի հետ ստուգել մեր բոլոր ենթադրությունները՝ օգտատերերի կողմից փոփոխությունները ընկալելու մասին։ Այս գիտելիքը մեզ պետք կլինի փոփոխությունների մասին պատշաճ հաղորդակցում ապահովելու համար ()։
Պետք է զգույշ լինել, երբ հեռացնում ենք այն տարրերը, որոնք համակարգում գործողությունների շղթայի (workflow) մի մասն են կազմում։
Պետք է ակնկալել օգտատերերի կողմից հեռացված ֆունկցիոնալության օգտագործման մակարդակին անհամաչափ դժգոհություն։ Այս պատճառով նպատակահարմար է հեռացված ֆունկցիոնալության հետ միասին ինչ-որ նոր բան ավելացնել՝ օգտատերերի անհարմարությունը մեղմելու համար։
Նույնիսկ եթե օգտատերը հազվադեպ է օգտագործել պրոդուկտի որոշակի տարրը, նրա համար այդ տարրը համարվում է «իր սեփականությունը»։ Այս տարրը հեռացնելը՝ առանց բացատրության կամ «օգտագործման վիճակագրությանը» հղումով, կարող է ընկալվել կտրուկ բացասական։ Օգտատերերը կարող են մեր գործողությունները անվանել «անարդար» և «անհավատարմություն» ( , )։
Մեր որոշումը բացատրելու համար կարող ենք հղում անել այն ցանկությանը, որ լրիվ վերացնենք որոշակի ռիսկ։
Եթե կանխատեսում ենք կտրուկ բացասական արձագանք ֆունկցիոնալության հեռացման պատճառով, կարող ենք նախապես ձեռնարկել միջոցներ՝ այդ արձագանքը մեղմելու համար։ Օրինակ՝ մի քանի ամիս առաջ կարող ենք հրապարակել նյութեր, որոնք ընդգծում են այն բաղադրիչի թերությունները, որը պատրաստվում ենք հեռացնել։ Սա օգտատերերին կօգնի ավելի հեշտությամբ «ռացիոնալացնել» այդ ֆունկցիոնալության հեռացումը։
Որոշ դեպքերում կարող ենք առաջին հերթին տարրը տեղափոխել պրոդուկտի մեկ այլ մաս, որտեղ այն դուրս կգա համատեքստից։ Ապա միայն օգտատերերի արձագանքը վերլուծելուց հետո հեռացնել այն որպես «ակնհայտ անհարմար» տարր։
Պետք է շատ զգույշ լինել այն ֆունկցիոնալ տարրերի հետ, որոնց մեջ օգտատերերը «տեսնում են իրենց»։ Օրինակ՝ կարող է թվալ, որ «Պրեմիում» նշանը օգտատերերի անվան կողքին ավելորդ է, բայց այն հեռացնելը կարող է հանգեցնել օգտատերերի բաժանորդագրությունների կորստին։ Պրոդուկտի ցանկացած տարր, որը սնուցում է օգտատիրոջ էգոն, կարևոր է։
Եթե օգտատերերը պահպանողական են իրենց գաղափարախոսությամբ, տարիքով կամ մեկ այլ բանով, ապա պետք է փոփոխությունները հասցնենք նվազագույնի։
Օգտատերերը երբեմն դժվարանում են գնահատել փոփոխությունների ազդեցությունը։ Հատկապես երբ փոփոխությունները ազդում են պրոդուկտի մի քանի տարբեր բաղադրիչների վրա: Կարող ենք փոփոխությունները պատկերավոր ներկայացնել «Մինչև» և «Հետո» ձևաչափով։
Եթե հեռացնում ենք ֆունկցիոնալություն, որը ակտիվորեն օգտագործվել է մեր մարքեթինգային նյութերում, օգտատերերի մոտ կարող է առաջանալ այն զգացումը, որ իրենց «խաբել են»։
Որոշ դեպքերում օգտատերերը կարող են դժգոհել փոփոխություններից՝ նույնիսկ չհասկանալով դրանց իմաստը։ Սա հատկապես ճիշտ է B2B-ում, որտեղ օգտատիրոջ համար հաճախ կարող է հարմար լինել իր ղեկավարության առջև թաքցնել իր ոչ կոմպետենտությունը՝ հղվելով պրոդուկտի «ծայրահեղ փոփոխություններին»:
Առնչվող հարցեր
#46.
Ինչպե՞ս պարզեցնել մեր պրոդուկտը։
#55.
Պրոդուկտի ո՞ր բաղադրիչներն են առավել զգայուն փոփոխությունների նկատմամբ։
#8.
Ինչո՞ւ են օգտատերերը շատ զգայուն արձագանքում պրոդուկտի փոփոխություններին։
#17.
Ինչո՞ւ մեր պրոդուկտի ֆունկցիոնալության մեծ մասը չի օգտագործվում։
#32.
Ինչպե՞ս պրոդուկտը դարձնել հնարավորինս հարմարավետ։
#54.
Ի՞նչ պետք է հաշվի առնել պրոդուկտում նոր ֆունկցիոնալություն ավելացնելիս։
Որքա՞ն օգտակար էր այս տեղեկությունը:
Անօգտակար
1
2
3
4
5
6
7
8
9
10
Անօգտակար
Շատ օգտակար
Շնորհակալություն ձեր ներդրման համար
Օգտակար հղումներ
Օգտակար հղումներ
UX CORE GUIDE
(UXCG - Գտնում ենք Ձեր պրոդուկտի խնդիրների լուծումները)
Ինչպես օգտագործելUXCG-ն անվճար գործիք է, որն օգնում է թիմերին հայտնաբերել կոգնիտիվ հակումների հետ կապված UX խնդիրները պրոդուկտի բոլոր փուլերում՝ սկսած պրոտոտիպավորումից և թեստավորումից մինչև գործող պրոդուկտի բարելավում:
Ինչպես օգտագործել UXCG
- Ընտրեք Ձեր պրոդուկտի փուլը ստորև
- Ընտրեք Ձեզ հետաքրքրող հարցը
- Կարդացեք հնարավոր պատասխանները:
Յուրաքանչյուր պատասխան բացատրում է, թե ինչպես են կոգնիտիվ հակումները կապված Ձեր կոնկրետ իրավիճակի հետ։ Քանի որ դուք լավագույնս եք հասկանում Ձեր համատեքստը, կարող եք ուղղակիորեն կիրառել ստացված գիտելիքները։ Թեև գործիքը պատրաստի լուծումներ չի տրամադրում՝ յուրաքանչյուր դեպքի յուրահատկության պատճառով, այն բացահայտում է նոր տեսանկյուններ՝ հիմնված կոգնիտիվ գիտության վրա։
Պիտակի նկարագրությունը
Հարցեր ներքին թիմային համագործակցության մասին (պրոդուկտի թիմի, տեխնիկական թիմի և այլ բաժինների միջև)։
Հարցեր պրոդուկտի մշակման փուլերի մասին (սկսած գաղափարից մինչև առաջին հանրային թողարկում)։
Հարցեր վաճառքների, մարքեթինգի, պոտենցիալ հաճախորդների հետ հաղորդակցության և ընդհանուր առմամբ պրոդուկտի փաթեթավորման մասին։
Հարցեր իրական պրոդուկտի և նրա ֆունկցիոնալության օգտագործման մասին։
Պրոդուկտի վերլուծական տվյալների մշակում:
Ընտրեք ձեր պրոդուկտի փուլը
#10.
Օգտատերերը բողոքում են մեր սպասարկման ծառայության որակից։
#30.
Ի՞նչ սխալներ ենք թույլ տալիս պրոդուկտի վերլուծական տվյալների հետ աշխատելիս։
#41.
Ի՞նչ անել երբ մեր գործընկերների համառությունը վնասում է աշխատանքին։
#43.
Ի՞նչ հաշվի առնել, երբ պլանավորում ենք պրոդուկտի թողարկումներ։
#45.
Ի՞նչ անել, եթե մեր թիմի որոշ անդամներ չեն արտահայտում իրենց կարծիքը։
#50.
Ինչպե՞ս աշխատել ոչ կոմպետենտ գործընկերոջ կամ ղեկավարի հետ:
#59.
Ի՞նչ պետք է հաշվի առնել ընկերության տեքստերում/պրոդուկտում քաղաքական, սոցիալական կամ տնտեսական իրադարձություններ մեկնաբանելիս։
#61.
Ի՞նչ անել երբ մեր թիմը չափազանց շատ ժամանակ է ծախսում անտեղի/աննշան մանրամասներ քննարկելու վրա։
Be Kind. Do Good.