ដូច្នេះយើងរចនា និងបញ្ជូនមុខងារថ្មីភ្លឺចាំង។ តើយើងដឹងថាវាដំណើរការដោយរបៀបណា? តើយើងវាស់វែង និងតាមដានផលប៉ះពាល់របស់វាយ៉ាងដូចម្តេច? មិនមានការខ្វះខាតនៅក្នុងរង្វាស់ UX ទេ ប៉ុន្តែចុះយ៉ាងណាបើយើងចង់បង្កើតម៉ែត្រ UX សាមញ្ញ ដែលអាចធ្វើម្តងទៀតបាន និងមានន័យ ជាពិសេសសម្រាប់លក្ខណៈពិសេសរបស់យើង? អញ្ចឹងតោះមើលពីរបៀបធ្វើវា។
ខ្ញុំបានលឺជាលើកដំបូងអំពីក្របខ័ណ្ឌ TARS ពីអត្ថបទដ៏អស្ចារ្យរបស់ Adrian H. Raudschl ស្តីពី "របៀបវាស់វែងផលប៉ះពាល់នៃលក្ខណៈពិសេស"។ នៅទីនេះ Adrian បានរំលេចពីរបៀបដែលក្រុមរបស់គាត់តាមដាន និងសម្រេចថាតើលក្ខណៈពិសេសមួយណាដែលត្រូវផ្តោតទៅលើ — ហើយបន្ទាប់មកគូសវាសគ្នាទៅវិញទៅមកនៅក្នុងម៉ាទ្រីស 2×2 quadrants ។ វាបានប្រែក្លាយទៅជាក្របខ័ណ្ឌដ៏មានសារៈប្រយោជន៍មួយក្នុងការមើលឃើញពីផលប៉ះពាល់នៃការងារ UX តាមរយៈកញ្ចក់នៃរង្វាស់ធុរកិច្ច។ តោះមើលរបៀបដែលវាដំណើរការ។ 1. ទស្សនិកជនគោលដៅ (%) យើងចាប់ផ្តើមដោយកំណត់បរិមាណទស្សនិកជនគោលដៅដោយស្វែងយល់ថាតើភាគរយនៃអ្នកប្រើប្រាស់ផលិតផលមួយណាមានបញ្ហាជាក់លាក់ដែលលក្ខណៈពិសេសមួយចង់ដោះស្រាយ។ យើងអាចសិក្សាមុខងារដែលមានស្រាប់ ឬស្រដៀងគ្នា ដែលព្យាយាមដោះស្រាយបញ្ហាស្រដៀងគ្នា និងថាតើអ្នកប្រើប្រាស់ប៉ុន្មាននាក់ដែលចូលរួមជាមួយពួកគេ។ ទស្សនិកជនគោលដៅមិនដូចគ្នាទៅនឹងការប្រើប្រាស់មុខងារនោះទេ។ ដូចដែល Adrian បានកត់សម្គាល់ ប្រសិនបើយើងដឹងថាមុខងារប៊ូតុងនាំចេញដែលមានស្រាប់ត្រូវបានប្រើប្រាស់ដោយ 5% នៃអ្នកប្រើប្រាស់ទាំងអស់ វាមិនមានន័យថាទស្សនិកជនគោលដៅគឺ 5% នោះទេ។ អ្នកប្រើប្រាស់កាន់តែច្រើនអាចនឹងមានបញ្ហាដែលមុខងារនាំចេញកំពុងព្យាយាមដោះស្រាយ ប៉ុន្តែពួកគេមិនអាចស្វែងរកវាបានទេ។ សំណួរដែលយើងសួរ៖ "តើភាគរយនៃអ្នកប្រើផលិតផលរបស់យើងទាំងអស់មានបញ្ហាជាក់លាក់នោះដែលមុខងារថ្មីមានគោលបំណងដោះស្រាយ?"
2. A = ស្មុំកូន (%) បន្ទាប់ យើងវាស់ថាតើយើង "ទទួលបាន" ទស្សនិកជនគោលដៅរបស់យើងបានល្អប៉ុណ្ណា។ សម្រាប់នោះ យើងតាមដានថាតើអ្នកប្រើប្រាស់ប៉ុន្មាននាក់ពិតជាចូលរួមដោយជោគជ័យជាមួយនឹងមុខងារនោះក្នុងរយៈពេលជាក់លាក់ណាមួយ។ យើងមិនផ្តោតលើ CTRs ឬរយៈពេលនៃវគ្គនៅទីនោះទេ ប៉ុន្តែប្រសិនបើអ្នកប្រើប្រាស់មានអត្ថន័យចូលរួមជាមួយវា។ ជាឧទាហរណ៍ ប្រសិនបើមានអ្វីជាសញ្ញាថាពួកគេបានរកឃើញថាវាមានតម្លៃ ដូចជាការចែករំលែក URL នាំចេញ ចំនួនឯកសារដែលបាននាំចេញ ឬការប្រើប្រាស់តម្រង និងការកំណត់។
ការទទួលយកមុខងារខ្ពស់ (> 60%) បង្ហាញថាបញ្ហាមានផលប៉ះពាល់។ ការស្មុំកូនទាប (<20%) អាចបង្ហាញថាបញ្ហាមានដំណោះស្រាយសាមញ្ញដែលមនុស្សបានពឹងផ្អែកលើ។ ការផ្លាស់ប្តូរទម្លាប់ក៏ត្រូវការពេលវេលាផងដែរ ហើយការស្មុំកូនទាបនៅដើមដំបូងត្រូវបានរំពឹងទុក។ ពេលខ្លះ ការអនុម័តមុខងារទាបមិនមានអ្វីដែលត្រូវធ្វើជាមួយលក្ខណៈពិសេសនេះទេ ប៉ុន្តែជាកន្លែងដែលវាស្ថិតនៅក្នុង UI ។ អ្នកប្រើប្រហែលជាមិនអាចរកឃើញវាទេប្រសិនបើវាត្រូវបានលាក់ ឬបើវាមានស្លាកដែលច្រឡំ។ វាច្បាស់ជាគ្រប់គ្រាន់សម្រាប់មនុស្សជំពប់ដួលលើវា។ ការសុំកូនតូចមិនតែងតែស្មើភាពបរាជ័យនោះទេ។ ប្រសិនបើបញ្ហាប៉ះពាល់ដល់អ្នកប្រើប្រាស់ 10% ប៉ុណ្ណោះ ការចុចយក 50-75% នៅក្នុងទីផ្សារពិសេសនោះមានន័យថាមុខងារនេះជោគជ័យ។ Question we ask: “What percentage of active target users actually use the feature to solve that problem?”
3. ការរក្សាទុក (%) បន្ទាប់មក យើងសិក្សាថាតើមុខងារមួយពិតជាត្រូវបានប្រើប្រាស់ម្តងហើយម្តងទៀតឬអត់។ យើងវាស់ស្ទង់ភាពញឹកញាប់នៃការប្រើប្រាស់ ឬជាពិសេសថាតើអ្នកប្រើប្រាស់ប៉ុន្មាននាក់ដែលបានចូលរួមជាមួយមុខងារនេះពិតជាបន្តប្រើប្រាស់វាយូរៗទៅ។ ជាធម្មតា វាគឺជាសញ្ញាដ៏រឹងមាំសម្រាប់ផលប៉ះពាល់ដ៏មានអត្ថន័យ។ ប្រសិនបើលក្ខណៈពិសេសមួយមានអត្រារក្សាទុក> 50% (ជាមធ្យម) យើងអាចជឿជាក់បានថាវាមានសារៈសំខាន់ជាយុទ្ធសាស្ត្រខ្ពស់។ អត្រារក្សាទុក 25-35% បង្ហាញពីសារៈសំខាន់ជាយុទ្ធសាស្រ្តមធ្យម ហើយការរក្សាទុក 10-20% នោះគឺជាសារៈសំខាន់ជាយុទ្ធសាស្ត្រទាប។ សំណួរដែលយើងសួរថា "ក្នុងចំណោមអ្នកប្រើប្រាស់ទាំងអស់ដែលបានប្រើប្រាស់មុខងារមួយយ៉ាងមានអត្ថន័យ តើមានមនុស្សប៉ុន្មាននាក់ដែលត្រលប់មកប្រើវាម្តងទៀត?"
4. ពិន្ទុពេញចិត្ត (CES) ជាចុងក្រោយ យើងវាស់កម្រិតនៃការពេញចិត្តដែលអ្នកប្រើប្រាស់មានជាមួយនឹងមុខងារនោះដែលយើងបានដឹកជញ្ជូន។ យើងមិនសួរអ្នករាល់គ្នាទេ - យើងសួរតែអ្នកប្រើ "រក្សាទុក" ប៉ុណ្ណោះ។ វាជួយយើងរកឃើញបញ្ហាលាក់កំបាំង ដែលប្រហែលជាមិនត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុងពិន្ទុរក្សា។
នៅពេលដែលអ្នកប្រើប្រាស់ពិតជាបានប្រើមុខងារមួយដងច្រើនដង យើងសួរពួកគេថាតើវាងាយស្រួលយ៉ាងណាក្នុងការដោះស្រាយបញ្ហាបន្ទាប់ពីពួកគេបានប្រើមុខងារនោះ — រវាង “ពិបាកជាង” និង “ងាយស្រួលជាងការរំពឹងទុក”។ យើងដឹងពីរបៀបដែលយើងចង់រកគ្រាប់បាល់។ ការប្រើប្រាស់ TARS សម្រាប់យុទ្ធសាស្ត្រលក្ខណៈពិសេស នៅពេលដែលយើងចាប់ផ្តើមវាស់ជាមួយ TARS យើងអាចគណនាពិន្ទុ S÷T ដែលជាភាគរយនៃអ្នកប្រើប្រាស់ដែលពេញចិត្ត ÷ អ្នកប្រើប្រាស់គោលដៅ។ វាផ្តល់ឱ្យយើងនូវអារម្មណ៍នៃរបៀបដែលលក្ខណៈពិសេសមួយកំពុងដំណើរការសម្រាប់ទស្សនិកជនគោលដៅរបស់យើង។ នៅពេលដែលយើងធ្វើវាសម្រាប់គ្រប់មុខងារ យើងអាចគូសផែនទីលក្ខណៈពិសេសទាំងអស់នៅទូទាំង 4 quadrants ក្នុងម៉ាទ្រីស 2×2។
លក្ខណៈពិសេសដែលដំណើរការលើសគឺមានតម្លៃយកចិត្តទុកដាក់ចំពោះ: ពួកគេមានការរក្សាទុកទាបប៉ុន្តែការពេញចិត្តខ្ពស់។ វាអាចជាលក្ខណៈពិសេសដែលអ្នកប្រើប្រាស់មិនចាំបាច់ប្រើញឹកញាប់ ប៉ុន្តែនៅពេលដែលពួកគេធ្វើ វាពិតជាមានប្រសិទ្ធភាពខ្លាំងណាស់។ លក្ខណៈពិសេសនៃការទទួលខុសត្រូវមានការរក្សាទុកខ្ពស់ ប៉ុន្តែការពេញចិត្តទាប ដូច្នេះប្រហែលជាយើងត្រូវធ្វើការលើពួកវាកែលម្អពួកគេ។ ហើយបន្ទាប់មក យើងក៏អាចកំណត់អត្តសញ្ញាណស្នូល និងលក្ខណៈពិសេសរបស់គម្រោង — និងមានការសន្ទនាជាមួយអ្នករចនា PMs និងវិស្វករអំពីអ្វីដែលយើងគួរធ្វើការបន្ទាប់ទៀត។ អត្រាការបម្លែងមិនមែនជា UX Metric ទេ។ TARS មិនរ៉ាប់រងអត្រាបំប្លែងទេ ហើយសម្រាប់ហេតុផលល្អ។ ដូចដែល Fabian Lenz បានកត់សម្គាល់ ការបំប្លែងជាញឹកញាប់ត្រូវបានចាត់ទុកថាជាសូចនាករចុងក្រោយនៃភាពជោគជ័យ — ប៉ុន្តែនៅក្នុងការអនុវត្តវាតែងតែពិបាកណាស់ក្នុងការបង្ហាញទំនាក់ទំនងច្បាស់លាស់រវាងគំនិតផ្តួចផ្តើមការរចនាតូចជាង និងគោលដៅបំប្លែងធំ។
ការពិតគឺថាស្ទើរតែគ្រប់គ្នានៅក្នុងក្រុមកំពុងធ្វើការឆ្ពោះទៅរកការប្រែចិត្តជឿកាន់តែប្រសើរឡើង។ ការកើនឡើងអាចនឹងត្រូវបានភ្ជាប់ទៅនឹងគំនិតផ្តួចផ្តើមផ្សេងៗគ្នាជាច្រើន — ពីការលក់ និងទីផ្សារ ដល់ការជំរុញការអនុវត្តគេហទំព័រ ដល់ឥទ្ធិពលតាមរដូវកាលដល់គំនិតផ្តួចផ្តើម UX ។ ជាការពិតណាស់ UX អាចធ្វើឱ្យប្រសើរឡើងការបំប្លែង ប៉ុន្តែវាមិនមែនជាម៉ែត្រ UX ទេ។ ជារឿយៗ មនុស្សមិនអាចជ្រើសរើសផលិតផលដែលខ្លួនកំពុងប្រើនោះទេ។ ហើយជារឿយៗ លទ្ធផលអាជីវកម្មដែលចង់បានគឺកើតចេញពីភាពចាំបាច់ និងការតស៊ូ ជាជាងការជឿជាក់ និងការដឹងគុណ។ ការបម្លែងខ្ពស់ទោះបីជា UX មិនល្អក៏ដោយ។ ដូចដែល Fabian សរសេរ អត្រាបំប្លែងខ្ពស់អាចកើតឡើង ទោះបីជា UX ខ្សោយក៏ដោយ ពីព្រោះ៖
អំណាចម៉ាកដ៏រឹងមាំទាញមនុស្សចូល, យុទ្ធសាស្ត្របន្ទាន់ដ៏ខ្លាំងក្លា ប៉ុន្តែមានប្រសិទ្ធភាព តម្លៃគឺទាក់ទាញខ្លាំង, ទីផ្សារដំណើរការយ៉ាងអស្ចារ្យ, ភាពស្មោះត្រង់របស់អតិថិជនជាប្រវត្តិសាស្ត្រ, អ្នកប្រើប្រាស់មិនមានជម្រើសជំនួសទេ។
Low Conversion Despite Great UX ក្នុងពេលជាមួយគ្នានេះ អត្រាបំប្លែងទាបអាចកើតឡើង ទោះបីជា UX ដ៏អស្ចារ្យក៏ដោយ ពីព្រោះ៖
ការផ្តល់ជូនមិនពាក់ព័ន្ធនឹងទស្សនិកជនទេ អ្នកប្រើប្រាស់មិនទុកចិត្តម៉ាក, គំរូអាជីវកម្មមិនល្អ ឬហានិភ័យខ្ពស់នៃការបរាជ័យ ទីផ្សារមិនទទួលបានទស្សនិកជនត្រឹមត្រូវទេ កត្តាខាងក្រៅ (តម្លៃ ពេលវេលា ការប្រកួតប្រជែង)។
ការបំប្លែងដែលប្រសើរឡើងគឺជាលទ្ធផលវិជ្ជមាននៃគំនិតផ្តួចផ្តើម UX ។ ប៉ុន្តែការងារ UX ល្អជាធម្មតាធ្វើអោយប្រសើរឡើងនូវការបញ្ចប់កិច្ចការ កាត់បន្ថយពេលវេលាលើកិច្ចការ កាត់បន្ថយកំហុស និងជៀសវាងការខ្វិននៃការសម្រេចចិត្ត។ ហើយមានរង្វាស់នៃការរចនាដែលអាចអនុវត្តបានជាច្រើនដែលយើងអាចប្រើដើម្បីតាមដាន UX និងជំរុញភាពជោគជ័យប្រកបដោយនិរន្តរភាព។ រុំឡើង ការវាស់វែងផលិតផលតែម្នាក់ឯងមិនតែងតែផ្តល់នូវទិដ្ឋភាពត្រឹមត្រូវនៃរបៀបដែលផលិតផលមួយដំណើរការបានល្អនោះទេ។ ការលក់អាចដំណើរការបានល្អ ប៉ុន្តែអ្នកប្រើប្រាស់អាចនឹងគ្មានប្រសិទ្ធភាព និងមានការខកចិត្តខ្លាំង។ ទោះជាយ៉ាងណាក៏ដោយ ភាពច្របូកច្របល់មានកម្រិតទាប ដោយសារអ្នកប្រើប្រាស់មិនអាចជ្រើសរើសឧបករណ៍ដែលពួកគេកំពុងប្រើ។
យើងត្រូវការរង្វាស់ UX ដើម្បីយល់ និងកែលម្អបទពិសោធន៍អ្នកប្រើប្រាស់។ អ្វីដែលខ្ញុំចូលចិត្តបំផុតអំពី TARS គឺថាវាជាវិធីដ៏ល្អមួយដើម្បីភ្ជាប់ការប្រើប្រាស់របស់អតិថិជន និងបទពិសោធន៍របស់អតិថិជនជាមួយនឹងរង្វាស់ផលិតផលដែលពាក់ព័ន្ធ។ ដោយផ្ទាល់ ខ្ញុំនឹងពង្រីក TARS ជាមួយនឹងរង្វាស់ដែលផ្តោតលើ UX និង KPIs ផងដែរ — អាស្រ័យលើតម្រូវការរបស់គម្រោង។ សូមថ្លែងអំណរគុណយ៉ាងជ្រាលជ្រៅចំពោះ Adrian H. Raudaschl ដែលបានដាក់វាជាមួយគ្នា។ ហើយប្រសិនបើអ្នកចាប់អារម្មណ៍លើម៉ែត្រ ខ្ញុំសូមណែនាំអ្នកឱ្យធ្វើតាមគាត់ ដើម្បីទទួលបានការណែនាំជាក់ស្តែង និងមានប្រយោជន៍ជុំវិញវា! ជួបជាមួយ "របៀបវាស់ UX និងផលប៉ះពាល់ការរចនា" អ្នកអាចស្វែងរកព័ត៌មានលម្អិតបន្ថែមអំពីយុទ្ធសាស្ត្រ UX នៅក្នុង 🪴 Measure UX & Design Impact (8h) ដែលជាការណែនាំជាក់ស្តែងសម្រាប់អ្នករចនា ហើយ UX នាំទៅរកការវាស់វែង និងបង្ហាញពីផលប៉ះពាល់ UX របស់អ្នកលើអាជីវកម្ម។ ប្រើលេខកូដ 🎟 IMPACT ដើម្បីសន្សំ 20% បិទថ្ងៃនេះ។ ចូលទៅកាន់ព័ត៌មានលម្អិត។
វីដេអូ + ការបណ្តុះបណ្តាល UX វីដេអូតែមួយគត់វីដេអូ + ការបណ្តុះបណ្តាល UX $ 495.00 $ 799.00
ទទួលបានវីដេអូ + មេរៀនវីដេអូ UX Training25 (8 ម៉ោង) + វគ្គបណ្តុះបណ្តាល UX ផ្ទាល់។ ធានាសងលុយវិញ 100 ថ្ងៃ។វីដេអូត្រឹមតែ $ 250.00$ 395.00
ទទួលបានមេរៀនវីដេអូ ២៥មេរៀន (៨ម៉ោង)។ បានធ្វើបច្ចុប្បន្នភាពប្រចាំឆ្នាំ។ ក៏មានជាកញ្ចប់ UX ជាមួយនឹងវគ្គសិក្សាវីដេអូចំនួន 3 ។
ធនធានមានប្រយោជន៍
"របៀបវាស់ UX និងផលប៉ះពាល់ការរចនា" ដោយអ្នកពិតប្រាកដ "គំនិតអាជីវកម្មសម្រាប់អ្នករចនា" ដោយ Ryan Rumsey "ROI នៃគម្រោងរចនា "របៀបដែល UX Metrics ត្រឹមត្រូវបង្ហាញតម្លៃនៃការផ្លាស់ប្តូរហ្គេម" ដោយ Jared Spool "ម៉ាស៊ីនគណនាទំហំគំរូស្រាវជ្រាវ"
ការអានបន្ថែម
"ការរចនាសម្រាប់ភាពតានតឹងនិងភាពអាសន្ន", Vitaly Friedman "AI នៅក្នុង UX: សម្រេចបានកាន់តែច្រើនដោយតិចជាង" Paul Boag "បញ្ហាលទ្ធភាពប្រើប្រាស់ជាមួយវិធីសាស្ត្រផ្ទៀងផ្ទាត់ដូច CAPTCHA" Eleanor Hecks Lyndon Cerejo "ពី Prompt ទៅដៃគូ៖ ការរចនាជំនួយការ AI ផ្ទាល់ខ្លួនរបស់អ្នក" Lyndon Cerejo
