پنج کاربر یک Prototype را دیدهاند، تیم میگوید «۸۵٪ مشکلات کاربردپذیری» کشف شده، سه تغییر طراحی اعمال شده و Dashboard بعدی افزایش ۴۵٪ تکمیل و کاهش ۷۰٪ رهاشدن را نشان میدهد. آیا تست تجربه کاربری محصول را متحول کرده است؟ نه لزوماً. معلوم نیست ۸۵٪ مخرجش چیست، پنج نفر نماینده چه Segmentیاند، Observation چگونه به Insight رسیده، کدام تغییر چه Mechanismی داشته و چه عوامل دیگری میان Before و After عوض شدهاند.
این راهنما یک UX Evidence-to-Decision Loop میسازد: Decision need → Research question → Study/Sample → Session → Observation → Analysis → Insight + Limitation → Options/Decision → Change hypothesis → Validation/Production evidence → Follow-up/Correction. هدف تولید Quote جذاب یا اثبات «صدای کاربر» نیست؛ هدف تبدیل شواهد محدود به تصمیمی محدود، قابل آزمون و قابل اصلاح است.
پاسخ کوتاه: تست تجربه کاربری چگونه به تصمیم محصول وصل میشود؟
پیش از مطالعه مشخص کنید کدام تصمیم و فرض را با چه گروه/سفر/بافت بررسی میکنید. در Session، رفتار و گفته را از تفسیر جدا ثبت کنید. در Analysis، Pattern، negative case، تناقض، Missing data و Bias را نگه دارید. Insight را فقط در همان Scope بیان کنید؛ چند Option و do-nothing بسازید؛ Authority تصمیم بگیرد؛ سپس Change را با Hypothesis، Measure، Guardrail و Attribution limit اعتبارسنجی کنید.
| Artifact | نمونه | ادعای مجاز |
|---|---|---|
| Observation | Participant پیش از دکمه مکث کرد | چه دیده/شنیده شد |
| Interpretation | ممکن است پیامد روشن نباشد | فرض توضیحی |
| Insight | معنا در Scope ناسازگار است | جمعبندی Evidence+Limit |
| Option | Copy یا Confirmation تغییر کند | راهحل نامطمئن |
| Decision | Option ترکیبی Prototype شود | تعهد محدود |
| Validation | تفسیر Task در V5 بهتر شد | Hypothesis در Scope |
هدف جستوجو و مرز این راهنما
اگر تعریف، انواع، جذب Participant، نوشتن Task و اجرای عمومی Usability Study را میخواهید، راهنمای تست کاربردپذیری مالک آن است. برای Task Success، Time on Task، Error، SEQ، SUS و Measurement plan به معیارهای تست کاربردپذیری بروید. این مقاله روی حلقهی پس از/پیش از Session متمرکز است: Evidence چگونه بدون جهش منطقی وارد تصمیم Product و Validation تغییر شود.
| پرسش | مالک محتوا | خروجی |
|---|---|---|
| Usability Test چگونه اجرا شود؟ | 640 | Plan/Task/Session/Finding |
| Usability چگونه اندازهگیری شود؟ | 774 | Measure/Analysis/Report |
| Workflow سازمانی چگونه سنجیده شود؟ | 1820 | Workflow evidence/gate |
| کاربر کسبوکار چه چیزی را میپذیرد؟ | 1893 | UAT acceptance decision |
| Research evidence چگونه Product را تغییر دهد؟ | همین مقاله | Insight→Option→Validation |
UX، Usability، UI و User Research را یکی نکنید
| مفهوم | سؤال نمونه | محدوده |
|---|---|---|
| User Experience | تجربهی فرد در کل رابطه/سفر چگونه است؟ | ادراک، رفتار، Context و زمان |
| Usability | کاربر در Context معین مؤثر/کارا/راضی است؟ | کیفیت استفاده از محصول |
| User Interface | رابط چگونه ارائه و تعامل را ممکن میکند؟ | یک جزء تجربه |
| User Research | درباره User/Need/Behavior/Context چه میآموزیم؟ | خانواده روشهای پژوهش |
| UX Testing | کدام فرض تجربه با کدام روش آزموده میشود؟ | اصطلاح عملی، نه یک Method واحد |
تست رنگ، Functional UI check، Interview، Analytics، A/B، Diary study و Moderated usability یک چیز نیستند. واژهی «UX Testing» را به Research question، Method و Claim تبدیل کنید تا خروجی قابل داوری شود.
منبع رسمی: از سؤال به Observation، Finding و Action
راهنمای رسمی GOV.UK میگوید Opinion/Assumption بیپایه را به Research question تبدیل کنید و روش را بر اساس پاسخ قابل اعتماد به آن انتخاب کنید؛ مرجع: Plan user research. در تحلیل Session نیز توصیه میکند هر Observation ابتدا دقیقاً آنچه دیده یا شنیده شده باشد، نه معنای فرضی آن؛ سپس Observationها گروهبندی، به Finding/Insight تبدیل و برای Design/Research/Backlog action استفاده شوند؛ مرجع: Analyse a research session.
قراردادهای جزئی این مقاله الگوی عملیاتی خود راهنما هستند، نه استاندارد یا فیلد اجباری GOV.UK. از منبع رسمی، اصل جداسازی Data/Observation، Interpretation/Insight و Action را میگیریم و Traceability/Decision/Validation را برای مسئلهی این مقاله اضافه میکنیم.
مدل مرکزی: UX Evidence-to-Decision Loop
UXEvidenceDecisionLoop {
studyId, studyVersion, roundId,
researchQuestionId, samplePlanId,
sessionIds[], observationIds[], analysisId,
insightIds[], decisionPacketId,
optionIds[], decisionId, changeId,
validationId, productionEvidenceIds[],
followupDecision, expiry,
reopenTriggers[], correctionId
}
حلقه بسته است چون Research report پایان کار نیست. Decision باید به Change و Validation برسد؛ و Evidence تازه بتواند Insight و Decision قدیمی را Reopen یا Supersede کند.
هویت مطالعه و نسخهها را قفل کنید
Program/Product/Study/Version/Round/Research Plan/Decision Policy/Segment/Journey/Prototype-or-Build/Environment/Data/Instrument/Coding scheme/Analysis/Evidence Manifest/Change/Validation Plan را شناسهدار کنید. «تحقیق هفته قبل» یا «نسخه جدید» برای بازبینی کافی نیست؛ تغییر Prompt، Task، Prototype یا Coding میتواند نتیجه را عوض کند.
Decision Need را قبل از Research Question بنویسید
UXResearchQuestion {
decisionNeed, researchObjective, researchQuestion,
assumptionOrBelief, claimBoundary,
targetPopulation, segmentIds[], journeyIds[],
contextOfUse, methodRationale, alternativeMethods[],
expectedEvidence[], notClaimed[],
decisionAuthority, researchOwner, riskOwner,
validityWindow, digest
}
«کاربران چه میخواهند؟» پهن و هدایتکننده است. سؤال بهتر: «کاربران احتمالی Segment عملیات، در Task اصلاح تراکنش خیالی، قبل از Action برگشتناپذیر پیامد را چگونه تفسیر میکنند؟» notClaimed بنویسید: این Round شیوع جمعیتی، Conversion، Revenue، وفاداری یا موفقیت بازار را ثابت نمیکند.
Research Question با سؤال Interview یکی نیست
Research question مسئلهی دانشی تیم است؛ Interview/Task prompt چیزی است که Participant میشنود. پرسیدن «آیا این دکمه گیجکننده نبود؟» Hypothesis را لو میدهد. Prompt باید Context/Goal بدهد و مسیر یا قضاوت را تحمیل نکند. نسخه و ترتیب سؤالها را ثبت کنید.
روش را از سؤال انتخاب کنید، نه از محبوبیت
| سؤال | روش Candidate | ادعای غیرمجاز |
|---|---|---|
| کجا Task میشکند؟ | Moderated/Unmoderated task study | شیوع در Population |
| چرا Context مهم است؟ | Contextual interview/field study | رفتار قطعی آینده |
| ساختار اطلاعات چگونه فهمیده میشود؟ | Card sort/tree test | کل UX بهتر است |
| کدام Variant Outcome بیشتری دارد؟ | Experiment/A-B با طراحی مناسب | چرا رخ داده |
| در Production چه رخ میدهد؟ | Telemetry/RUM/support data | انگیزه و Need |
| اثر تغییر در زمان چیست؟ | Longitudinal/diary/cohort | علت بدون کنترل Confounder |
Sampling؛ پنج کاربر قانون جهانی نیست
تعداد Participant به Decision، Method، Segment diversity، Problem discoverability، Risk، مقایسه/Benchmark، desired uncertainty و Iteration وابسته است. یک Round کوچک Formative میتواند Pattern مهمی آشکار کند، اما درصد Population یا Coverage کلی نمیدهد. عدد «پنج نفر ۸۵٪ مشکلات را پیدا میکنند» را بدون فرض نرخ کشف مستقل/یکسان، تعریف Problem universe و Scope تکرار نکنید.
UXSamplePlan {
samplePlanId, populationBasis,
segmentQuotaRationale,
eligibilityCriteria[], exclusionCriteria[],
recruitmentChannels[], screeningVersion,
sampleSizeRationale, stoppingRule, replacementRule,
recruitmentBiases[], nonresponseRisk,
accessNeedsPlan, languageLocalePlan, incentivePlan,
consentPlan, privacyPlan,
participantIds[], sampleLimitations[], coverageStatus,
digest
}
Participant واقعی هم Bias را حذف نمیکند
Actual یا likely user بودن ضروریِ بسیاری از سؤالهاست، اما Volunteer bias، familiarity، recruitment channel، incentive، nonresponse و observer effect باقی میماند. Friend یا همکار ممکن است فقط برای Pilot ابزار مناسب باشد و باید Limit آن روشن شود؛ در سیستم داخلی، همکار میتواند خودِ user واقعی باشد. Eligibility را به Role/Context/Task ببندید.
Segment، Persona و Demographic را جایگزین هم نکنید
Segment میتواند بر Job-to-be-done، Role/Permission، تجربه، Frequency، Context، Access need، Device/Connectivity، زبان و Risk بنا شود. Persona روایی بهتنهایی Sampling frame نیست؛ Demographic نیز بدون ارتباط با سؤال نباید جمع شود. تنوع را با Hypothesis و harm توضیح دهید، نه با یک فهرست تزئینی.
Consent، Withdrawal و Privacy بخشی از صحت Evidence هستند
راهنمای رسمی GOV.UK درباره داده و حریم خصوصی پژوهش بر رضایت آگاهانه، کمینهسازی، دسترسی محدود، حذف بهموقع و ناشناسسازی خروجیها تاکید دارد. Policy و مشاور حقوقی/حریم خصوصی سازمان حاکم است؛ این مقاله توصیه حقوقی ایران یا کشور دیگری نیست.
Purpose، داده، Recording، Observer، استفاده، Sharing، Retention و Withdrawal را پیش از Session با زبان/فرمت قابل فهم بگویید. اگر Participant Withdraw کرد، داده باید طبق Policy قابل یافتن و رسیدگی باشد؛ انباشتن Clipهای جذاب در Slide یا ابزار AI بدون مجوز، Evidence practice سالم نیست.
Accessibility را به یک Round جدا تبعید نکنید
Recruitment، Consent، Session، Prototype و Reporting باید برای Keyboard، Screen reader، Zoom، Caption، مترجم، استراحت، مکان و اتصال قابل استفاده باشند. نبود Participant دارای Access need اثبات نبود Barrier نیست؛ آن را Coverage gap ثبت و Round مناسب طراحی کنید.
Session Contract؛ Artifact و Prompt باید قابل بازبینی باشند
UXResearchSession {
sessionId, participantId, segmentId, journeyId,
taskVersion, artifactVersion, environmentId,
startedAt, endedAt, moderatorId, observerIds[],
promptVersion, assistanceEvents[], deviations[],
recordingConsent, sessionStatus,
evidenceRefs[], limitations[], digest
}
Session status میتواند VALID، VALID_WITH_LIMITATION، INVALID، WITHDRAWN یا INCOMPLETE باشد. Prototype outage، تغییر Task، Coaching، حضور مدیر Participant یا قطع اتصال را پنهان نکنید. Evidence جلسهی Invalid ممکن است برای Tool diagnosis مفید باشد، اما وارد Finding کاربر نشود.
Moderation؛ بیطرفی کامل افسانه است، کنترل ممکن است
Tone، ترتیب سؤال، سکوت، اشاره، تعریف اصطلاح و کمک میتوانند رفتار را تغییر دهند. Script/Pilot، آموزش Moderator، Assistance vocabulary، observer briefing و reflexive note کمک میکند. Moderator neutrality را Zero-bias ننامید؛ Bias candidate و اثر احتمالی را ثبت کنید.
| مداخله | ثبت | اثر بر Evidence |
|---|---|---|
| تکرار خنثی Task | REPEAT | معمولاً Limit کم |
| توضیح واژه | CLARIFY | Comprehension متاثر |
| اشاره به مسیر | NAVIGATION_HINT | Task success متاثر |
| انجام مرحله | DIRECT_HELP | Attempt برای استقلال Invalid/Fail |
| رفع Prototype | TECH_INTERVENTION | Restart/Separate attempt |
Think-aloud پنجره کامل ذهن نیست
گفتار میتواند رفتار را کند، ترتیب فکر را تغییر یا فقط بخش قابل بیان تجربه را نشان دهد. Silence به معنی نبود مشکل و عبارت Participant به معنی Cause قطعی نیست. Behavior، Statement، State، Outcome و Context را جدا ثبت کنید و Limit روش را حمل کنید.
Observation را از Interpretation پاک نگه دارید
UXObservation {
observationId, sessionId, timestamp,
observedBehavior, verbatimStatement,
artifactState, taskStep, context,
assistanceLevel, evidenceRefs[], observerId,
observationConfidence, interpretationExcluded,
privacyClass, affectedJourney, affectedSegment,
unknowns[], digest
}
«کاربر گیج شد چون رنگ CTA بد بود» Observation نیست. سالمتر: «Participant ۱۸ ثانیه صفحه را پیمایش کرد، دو بار به Summary برگشت و گفت “نمیدانم با این دکمه اجرا میشود یا بررسی”». Cause candidate بعداً میتواند Label، consequence visibility، Layout، prior expectation یا Task wording باشد.
Quote، نیاز کاربر یا Insight نیست
Quote یک Data point در Context است. «یک دکمه قرمز میخواهم» راهحل پیشنهادی Participant است، نه لزوماً Need. Need candidate میتواند تشخیص پیامد و کنترل پیش از اقدام برگشتناپذیر باشد. Quote cherry-picking و کلیپ احساسی نباید negative case یا رفتار مخالف را حذف کند.
Analysis Contract؛ Theme بدون Trail کافی نیست
UXAnalysis {
analysisId, analysisVersion,
includedSessionIds[], excludedSessionIds[], exclusionReasons[],
codingSchemeVersion, coderIds[], codingUnit,
themeIds[], negativeCases[], contradictoryEvidence[],
triangulationSources[], quantitativeDefinitions[],
denominators, missingDataRule, uncertainty,
biasReview[], sensitivityChecks[],
analysisLimitations[], analysisLog, digest
}
Affinity mapping ابزار سازماندهی است، نه ماشین حقیقت. چه کسی Note را نوشته، چه چیزی Merge/Move/Discard شده و اختلاف چگونه حل شده را نگه دارید. Researcher consensus میتواند مشترکاً Bias داشته باشد؛ negative case، coder اختلافی، Source دیگر و sensitivity check مهماند.
Pattern، Exception، Frequency و Prevalence را جدا کنید
| عبارت | معنا | نیاز |
|---|---|---|
| ۳ از ۵ Session | فراوانی در Sample معتبر | مخرج/Validity |
| Pattern کیفی | Behavior/Meaning تکرارشده | Evidence/Context |
| Negative case | مورد مخالف Pattern | حفظ/تفسیر |
| Population prevalence | نرخ در جمعیت هدف | Sampling/inference مناسب |
| High-severity exception | مورد کمتکرار با Harm زیاد | Risk-based action |
سه نفر از پنج نفر برابر ۶۰٪ Population نیست. همچنین یک Barrier دسترسپذیری یا اقدام برگشتناپذیر را فقط بهخاطر فراوانی کم کنار نگذارید. Frequency و Impact دو ورودی متفاوتاند.
Insight Contract؛ Evidence، Scope و Alternative explanation
UXInsight {
insightId, insightStatement,
observationRefs[], segmentScope, journeyScope, contextScope,
patternOrException, frequencyClaim, confidence,
alternativeExplanations[], harmOrNeed, affectedOutcome,
limitations[], openQuestions[], status,
supersedes, ownerCapability, digest
}
Insight خوب میتواند بگوید «Label فعلی ممکن است پیامد Action را برای Segment/Task تعریفشده ناسازگار منتقل کند». نمیگوید «کاربران Label را نمیفهمند» یا «این رنگ باعث ۶۰٪ رهاشدن شد». Confidence، alternative و open question، ضعف نیستند؛ مرز تصمیماند.
Finding، Insight، Opportunity و Recommendation یک چیز نیستند
| نوع | پرسش | خروجی |
|---|---|---|
| Finding | Evidence چه مسئلهای نشان داد؟ | مشکل/Pattern محدود |
| Insight | این Evidence درباره Context چه میآموزد؟ | Meaning+Limit |
| Opportunity | کدام Outcome ارزش بررسی دارد؟ | Problem space |
| Option | چه Mechanismهایی ممکن است کمک کنند؟ | راهحلهای Candidate |
| Recommendation | با Evidence فعلی قدم بعد چیست؟ | پیشنهاد |
| Decision | Authority چه تعهدی میدهد؟ | Record/Owner/Condition |
Severity را با تعداد Participant تعیین نکنید
Impact، frequency basis، critical journey، reversibility، recovery، affected Segment، access barrier و workaround را جدا کنید. یک Participant میتواند Hazard جدی را آشکار کند؛ پنج نفر مشابه نیز ممکن است یک اصطکاک کماثر را تکرار کنند. Severity proposal و Product priority را با Authority و Evidence جدا نگه دارید.
از Insight مستقیم به Fix نپرید
اگر CTA پیدا نمیشود، Contrast فقط یک Hypothesis است؛ Hierarchy، Scroll, wording، state، device یا task expectation نیز ممکن است نقش داشته باشند. حداقل دو Option و do-nothing بسازید؛ Mechanism، Benefit، Harm، Dependency، Cost range، Risk و Evidence needed را مقایسه کنید.
UXDecisionPacket {
decisionPacketId, insightIds[], problemStatement,
optionIds[], doNothingOption,
optionMechanisms[], expectedBenefits[], expectedHarms[],
tradeoffs[], dependencies[], costRanges[], riskAssessment,
evidenceStrength, unknowns[], recommendation,
decisionAuthority, decision, conditions[],
decisionRationale, decisionAt, digest
}
Vocabulary نمونه: EXPLORE، PROTOTYPE، TEST_OPTION، IMPLEMENT_BOUNDED، DEFER و DO_NOT_PROCEED. Researcher میتواند Evidence و Recommendation بدهد؛ Product/Design/Risk/Release authority طبق Governance تصمیم میگیرد. «Research sign-off» مجوز انتشار نیست.
Research Repository را انبار PDF نکنید
Question، Segment، Journey، Observation، Insight، Decision، Change، Validation، expiry و supersession باید قابل جستوجو و لینک باشند. Access و Retention را بر Privacy تنظیم کنید. Insight قدیمی را بدون Context reuse نکنید؛ Segment/Product/Policy ممکن است عوض شده باشد.
Share یافته، Evidence را به داستان پیروزی تبدیل نکند
برای Audienceهای مختلف View بسازید، اما Packet واحد بماند. Quote، Clip و Journey map باید anonymized/authorized، Contextدار و کنار negative case/Limit باشند. برای ارائهی Claim، denominator، uncertainty و Decision record، ارائه نتایج تست از Evidence تا تصمیم را ببینید.
تغییر طراحی یک Hypothesis تازه است
Finding درباره نسخه A، نسخه B را تایید نمیکند. Copy سادهتر ممکن است Precision را کم کند؛ Just-in-time permission ممکن است Task دیگری را مختل کند؛ CTA پررنگتر ممکن است Accidental action بسازد. هر Option باید Change hypothesis و Guardrail داشته باشد و با Prototype/Build نسخهدار Retest شود.
Validation Plan؛ از Change تا Outcome
UXChangeValidation {
validationId, changeId, changeHypothesis,
targetOutcome, comparisonBasis,
baselineWindow, validationWindow,
exposure, population, primaryMeasure,
guardrailMeasures[], countermetrics[],
instrumentationChecks[], confounders[],
stopRule, rollbackPlan, result,
attributionLimit, followupDecision, expiry,
digest
}
Result میتواند SUPPORTED_WITHIN_SCOPE، NOT_SUPPORTED، INCONCLUSIVE، INVALID یا STOPPED باشد. Supported یعنی Hypothesis محدود در Population/Artifact/Window/Measure تعریفشده پشتیبانی شد؛ نه اینکه UX، Revenue یا وفاداری کل بهتر شده است.
Before/After بهتنهایی علیت را ثابت نمیکند
Marketing mix، Season، traffic quality، Performance، Bug fix، Pricing، Policy، onboarding، channel و instrumentation ممکن است همزمان تغییر کنند. Baseline/Window/Population/Exposure و Confounder را ثبت کنید. اگر Experiment مناسب و اخلاقی نیست، Attribution را محدود و Evidenceهای مکمل را Triangulate کنید.
A/B Testing چه میگوید و چه نمیگوید؟
A/B میتواند تفاوت Measure تعریفشده را در Exposure/Population و طراحی مشخص برآورد کند؛ بهتنهایی «چرا» یا کیفیت تجربه را توضیح نمیدهد. Assignment، sample-size/power plan، exposure، contamination، novelty، multiple comparisons، stopping، missing data و Guardrail لازماند. A/B را برای Correctness یا تغییر پرخطرِ بدون Safety control استفاده نکنید.
Analytics، Funnel و NPS صدای کامل کاربر نیستند
Analytics میگوید چه Eventی ثبت شده، نه لزوماً Intent/Need/Cause. Funnel به Instrumentation و Population حساس است. NPS یک پاسخ به سؤال و Scale مشخص است؛ وفاداری، Revenue یا Cause را ثابت نمیکند. Behavior telemetry، qualitative evidence، support signals و domain outcome را با تعاریف مستقل کنار هم بگذارید.
Production Evidence؛ مشاهده بدون جاسوسی
Event minimization، purpose limitation، access، aggregation، consent/legal basis، retention و deletion را با تیم Privacy/Legal تعیین کنید. Session replay، free text و support record میتواند داده حساس داشته باشد. برای Canary/A-B/RUM/Telemetry/Guardrail/Rollback، راهنمای Shift-right امن را جدا بخوانید.
Sprint Review، UAT و UX Research را ادغام اسمی نکنید
Sprint Review برای Inspect کردن Outcome/Environment و Adapt Product Backlog است؛ Feedback آن Sampling/Protocol پژوهش نیست. راهنمای Sprint Review شواهدمحور را ببینید. UAT نیز Acceptance Claim و Authority دارد؛ راهنمای UAT Decision مالک آن است. یک جلسه میتواند ورودیهای مختلف بدهد، اما Claimها را مخلوط نکنید.
تست UX سازمانی؛ Screen آخر Journey نیست
در ERP/CRM/Backoffice، Role/Permission، Data grid، Bulk action، Handoff، Timeout/Resume، Notification، Export، Expertise و Training بخشی از Context هستند. برای طراحی مطالعهی این حوزه، تست کاربردپذیری نرمافزار سازمانی را استفاده کنید. Insight صفحهای را به Outcome کل Workflow تعمیم ندهید.
Opportunity و نوآوری؛ Research حق تقدم خودکار نمیدهد
Insight میتواند Opportunity بسازد، اما Roadmap به Goal، Risk، Cost، Dependency، Strategy و Evidenceهای دیگر هم نیاز دارد. برای Problem portfolio، Option و Experiment gate به نوآوری در QA مراجعه کنید. «User asked» به معنی «باید بسازیم» نیست.
Research debt و Evidence freshness
پرسشهای بیپاسخ، Segmentهای غایب، Instrumentation ناقص، Insightهای بیValidation، تصمیمهای بدون rationale و Repositoryهای بدون expiry بدهیاند. Age بهتنهایی Stale نیست؛ Change trigger مهم است: Policy، Journey، Artifact، Population، Market context یا Technology تغییر کرده؟
Correction؛ Insight و Decision هم ممکن است غلط باشند
اگر Session اشتباه Exclude شده، Quote غلط Transcribe شده، Coding تغییر کرده، Sample eligibility نادرست بوده یا Instrumentation شکسته، گزارش قدیمی را پاک نکنید. Correction با prior/new digest، دلیل، Evidence، affected Insights/Decisions/Changes، notification و access بسازید.
آزمایشگاه فارسی و آفلاین Reconciliation خیالی
Lab کاملاً ساختگی و بدون شبکه است. یک Participant شبهنامدار در Prototype فارسی باید وضعیت Order خیالی را پس از Timeout بررسی و Action برگشتناپذیر Reconciliation را بفهمد. سؤال: آیا Label فعلی «بررسی/اجرا» را برای Segment عملیات در همین Journey روشن میکند؟ هیچ شرکت، کاربر، بانک، PSP یا پرداخت واقعی وجود ندارد.
| Evidence | رکورد سالم | جهش ممنوع |
|---|---|---|
| Behavior | مکث و بازگشت به Summary | کاربر گیج است |
| Statement | «بررسی یا اجرا؟» | همه کاربران همین Need را دارند |
| Negative case | یک نفر درست تفسیر کرد | حذف چون با Story نمیخواند |
| Insight | معنا در Scope ناسازگار است | Label علت رهاشدن است |
| Decision | Option ترکیبی Prototype شود | Fix قطعی |
| Validation | Hypothesis در V5 پشتیبانی شد | Conversion/Revenue بهتر شد |
شناسههای Tenant/Order/Attempt/Event/Ledger/Run/Build/Evidence جدا هستند؛ IRR کاملاً خیالی Canonical و تومان فقط نمایش برچسبخورده است؛ ارقام فارسی/عربی/لاتین، ی/ی و ک/ک، Unicode NFC، RTL/LTR، UTC/Asia-Tehran و جلالی فقط نمایشی آزموده میشوند. هیچ نام، موبایل، ایمیل، IP، Account، PAN، CVV2، OTP، Cookie، Token، Credential، Log، Recording یا Screenshot واقعی وجود ندارد.
Fixture: پنج کاربر و «۸۵٪ مشکل» در برابر ۲۲۴ Finding
Fixture مستقل `SYN-UX-EVIDENCE-PRODUCT-DECISION-۰۱` با Node.js و بدون Dependency بیرونی اجرا شد. Dashboard پنج Participant، «۸۵٪ مشکلات»، سه Design fix، افزایش ۴۵٪ تکمیل ثبتنام و کاهش ۷۰٪ رهاشدن انتقال را نشان داد و `UX_TRANSFORMATION_SUCCESS` صادر کرد. ممیزی ۲۳۴قاعدهای همان ورودی را با دقیقاً ۲۲۴ Finding به HOLD برد.
| گروه | قاعده | نمونه |
|---|---|---|
| Identity | 18 | Study/Round/Artifact/Instrument/Analysis |
| Question | 18 | Decision/Population/Method/Boundary |
| Sampling | 20 | Eligibility/Bias/Size/Stop/Consent |
| Session | 18 | Participant/Task/Prompt/Assistance/Status |
| Observation | 18 | Behavior/Quote/State/Context/Unknown |
| Analysis | 20 | Coding/Negative/Contradiction/Denominator |
| Insight | 18 | Refs/Scope/Frequency/Alternative/Limit |
| Decision | 20 | Options/Mechanism/Harm/Authority |
| Validation | 20 | Hypothesis/Measure/Guardrail/Attribution |
| Governance | 20 | Consent/Privacy/Review/Correction |
| Forbidden + Relations | 44 | تضمینها و اتصال قراردادها |
۲۲۴ Finding برابر تمام ۱۹۰ فیلد غایب و ۳۴ ادعای ممنوع بود؛ ده Relation چون رکورد پیوندپذیر وجود نداشت، صادقانه فعال نشدند. نسخه اصلاحشده Study/Question/Sample/Session را برای `SEG-OPS-SYN-۳۵` و `JOURNEY-RECONCILE-SYN-۳۵` قفل کرد؛ Behavior و Quote را از Cause جدا نگه داشت؛ سه Session معتبر، یک Session Invalid و یک negative case را تحلیل کرد؛ Insight با Confidence متوسط و alternative explanations ساخت؛ سه Option و do-nothing را مقایسه و فقط TEST_OPTION تصمیم گرفت؛ V5 را با Guardrail و Attribution limit سنجید و `READY_FOR_UX_EVIDENCE_DECISION_REVIEW` با صفر Finding ساخت—نه اثبات حقیقت Evidence، نمایندگی Population، شیوع، علیت، Conversion، Revenue یا موفقیت محصول.
Automation و AI در UX Research
Automation میتواند Artifact/version، Consent state، timestamp، Evidence digest، coding lineage و affected-decision query را نگه دارد. AI میتواند Transcript draft، Code candidate یا Theme proposal تولید کند؛ نباید Missing statement بسازد، Tone/Emotion/Need را قطعی استنباط کند، Participant را Profile، negative case را حذف، Insight/Severity/Decision یا Consent صادر کند. داده حساس را فقط طبق Policy/Permission بدهید و Model/Prompt/Input/Output/Human review را ثبت کنید.
معیارهای سالم و Countermetricها
| Metric | کاربرد | Countermetric/Limit |
|---|---|---|
| Question-to-decision trace | کاربردپذیری Research | Decision quality/unknown |
| Observation evidence completeness | قابلیت بازبینی | Participant burden/privacy |
| Negative-case retention | Bias guardrail | Token counts without meaning |
| Insight freshness | اعتبار Context | False expiry |
| Insight-to-option diversity | پرهیز از Fix jump | Decision delay |
| Change validation closure | حلقه بسته | Weak attribution |
| Correction reach | تصمیمهای اصلاحشده | Privacy/access incident |
| Research harm | اخلاق/Guardrail | Under-reporting |
۳۴ Anti-pattern در UX Evidence و تصمیم محصول
- پنج کاربر همیشه کافیاند.
- پنج کاربر ۸۵٪ مشکلات را پیدا میکنند.
- Participant بیشتر حقیقت را تضمین میکند.
- یک Round نماینده همه کاربران است.
- User واقعی Bias را حذف میکند.
- Friend هرگز معتبر نیست.
- Participant گفت پس User need است.
- Quote همان Insight است.
- Observation همان Cause است.
- Theme همان Prevalence است.
- درصد Sample همان نرخ Population است.
- سکوت یعنی Problem نیست.
- Observation نشد یعنی Barrier نیست.
- Moderator کاملاً خنثی است.
- Think-aloud حقیقت کامل ذهن است.
- Affinity map عینی است.
- اجماع Researcher اثبات است.
- Satisfaction یعنی Usability.
- Usability همان UX است.
- UX Testing همان UI Testing است.
- UX Testing همان A/B است.
- A/B علت را توضیح میدهد.
- Analytics انگیزه را توضیح میدهد.
- NPS وفاداری را ثابت میکند.
- Fix زودهنگام همیشه صد برابر ارزانتر است.
- UX Testing Conversion را زیاد میکند.
- UX Testing Revenue را زیاد میکند.
- UX Testing وفاداری را تضمین میکند.
- UX Testing موفقیت محصول را تضمین میکند.
- سه Fix Outcome را ایجاد کردهاند.
- Before/After علیت را ثابت میکند.
- Metric مثبت یعنی Experience بهتر است.
- AI میتواند User need را استنباط کند.
- Research Sign-off همان Release decision است.
چکلیست ۳۲نقطهای UX Evidence Owner
| حوزه | کنترل |
|---|---|
| Identity | Study/Round/Plan/Artifact/Env/Instrument/Coding/Analysis نسخه دارد؟ |
| Question | Decision/Objective/Assumption/Population/Context/not-claimed روشن است؟ |
| Method | Rationale/Alternative/Expected evidence و Claim limit دارد؟ |
| Sample | Basis/Segment/Eligibility/Channel/Size/Stop/Bias/Limit ثبت است؟ |
| Ethics | Consent/Withdrawal/Privacy/Minimization/Access/Retention برقرار است؟ |
| Access | Language/Locale/Disability/Device/Connection پوشش دارد؟ |
| Session | Participant/Task/Artifact/Prompt/Moderator/Assistance/Deviation پیوند دارد؟ |
| Observation | Behavior/Quote/State/Context/Unknown از تفسیر جداست؟ |
| Analysis | Include/Exclude/Coding/Negative/Contradiction/Missing/Bias روشن است؟ |
| Insight | Refs/Scope/Frequency/Confidence/Alternative/Limit/Open question دارد؟ |
| Decision | Problem/Options/Do-nothing/Mechanism/Harm/Trade-off/Authority دارد؟ |
| Validation | Hypothesis/Population/Measure/Guardrail/Confounder/Stop/Rollback دارد؟ |
| Attribution | Qualitative/Experiment/Telemetry claims از هم جدا هستند؟ |
| Freshness | Expiry/Reopen/Supersession/Correction و affected decisions تعریف است؟ |
Pilot سیروزه برای بستن حلقه UX Research
| بازه | کار | خروجی/Guardrail |
|---|---|---|
| روز ۱–۵ | Decision/Question/Scope/not-claimed | یک Journey/Segment |
| روز ۶–۱۰ | Method/Sample/Consent/Artifact Pilot | Privacy/accessibility |
| روز ۱۱–۱۵ | Session/Observation | Assistance/deviation trail |
| روز ۱۶–۲۰ | Analysis/negative/Insight | Bias/uncertainty |
| روز ۲۱–۲۵ | Options/Decision/Prototype | No fix jump |
| روز ۲۶–۳۰ | Validation/Follow-up/Correction rehearsal | Guardrail/attribution limit |
جمعبندی
تست تجربه کاربری را از یک Session نمایشی یا Case study پیروزی به سیستم Evidence تبدیل کنید. Question را به Decision ببندید؛ Sample و Context را محدود کنید؛ Consent و دسترسی را در کیفیت مطالعه حساب کنید؛ Observation را از تفسیر، Insight را از Solution و Recommendation را از Decision جدا کنید؛ negative case و Unknown را نگه دارید؛ Change را Hypothesis بدانید؛ و نتیجه را با Validation و Attribution limit ببندید. شنیدن کاربر ضروری است، اما «صدای کاربر» بدون روش، Scope و اختیار تصمیم، حقیقت واحد محصول نیست.
سؤالات متداول
آیا پنج کاربر برای تست تجربه کاربری کافیاند؟
گاهی برای یک Round کوچک Formative و یک Segment/Task محدود مفیدند، اما قانون عمومی نیست. Method، تنوع Segment، Risk، نرخ کشف، هدف مقایسه/برآورد و Iteration تعیینکنندهاند. Sample rationale، stopping rule و محدودیت تعمیم را بنویسید.
تفاوت Observation و Insight در UX Research چیست؟
Observation آنچه در Session دیده یا شنیده شد با Context و Evidence است. Insight حاصل Analysis چند Observation و موارد مخالف است و Scope، Confidence، alternative explanation و Limit دارد. «مکث کرد» Observation است؛ «پیامد Action ممکن است در این Journey روشن نباشد» Insight محدود است.
آیا گفته کاربر باید مستقیم وارد Roadmap شود؟
خیر. گفته یک Data point است. آن را با Behavior، Context و Evidenceهای دیگر تحلیل کنید؛ Need/Harm و alternative را بسازید؛ چند Option و do-nothing را با Strategy/Risk/Cost بسنجید. Authority محصول درباره قدم بعد تصمیم میگیرد.
چگونه ثابت کنیم تغییر UX باعث افزایش Conversion شده است؟
«اثبات» معمولاً بیش از Before/After میخواهد. Assignment یا comparison مناسب، Population/Exposure، Measurement/instrumentation، Sample plan، Guardrail، Confounder، stopping و uncertainty را طراحی کنید. حتی Experiment خوب، اثر را برای همان طرح برآورد میکند و لزوماً چرایی را توضیح نمیدهد.
AI در تحلیل پژوهش کاربر چه نقشی دارد؟
میتواند Transcript، Code یا Theme candidate بسازد و جستوجو را سریع کند؛ Human باید Context، negative case، Bias و Privacy را بازبینی کند. AI نباید Need/Emotion/Cause را قطعی، داده گمشده را تولید، Participant را Profile یا Product/Release decision صادر کند.
