تست الگوهای تاریک؛ از Choice تا Evidence

پاسخ کوتاه: برای تست الگوهای تاریک، دنبال فهرست چند دکمهٔ بد نگردید. Choice واقعی کاربر، اطلاعاتی که پیش از تصمیم می‌بیند، Default، ترتیب و برجستگی گزینه‌ها، هزینهٔ ورود/خروج، State سمت سرور و اثر مشاهده‌شده را نسخه‌دار کنید. سپس Observation را از Pattern candidate، فرضیهٔ Mechanism، Harm، Intent و Legal assessment جدا نگه دارید. خروجی حرفه‌ای یک Deceptive Design Evidence Record است؛ نه حکم «طراح عمداً فریب داده» و نه رأی حقوقی.

این مقاله راهنمای طراحی آزمون و Evidence است. دربارهٔ قصد اشخاص، فریب یا دستکاری در معنای حقوقی، شمول قانون، نقض، جریمه یا انطباق محصول مشخص اظهار نظر نمی‌کند. متن رسمی جاری، واقعیت پرونده، بازار/نقش/زمان و نظر متخصص واجد صلاحیت مقدم‌اند.

مالکیت این مقاله: Deceptive Design Evidence Record

مالکیت محدود این صفحه، تبدیل یک نگرانی دربارهٔ Dark Pattern یا Deceptive Design به رکورد قابل‌بازتولید است: کدام Journey و State، برای کدام Population، چه Choiceهایی را با چه Presentation و Frictionی عرضه کرد؛ چه چیزی مشاهده یا اندازه‌گیری شد؛ چه توضیح‌های جایگزینی باقی ماند؛ چه تصمیمی گرفته شد؛ و اصلاح چگونه Verify شد.

متقاعدسازی اخلاقی در QA مرز Influence و Consent در تصمیم سازمانی را مالک است؛ اخلاق حرفه‌ای تست مسیر Concern/Escalation را؛ تست کاربردپذیری مطالعهٔ Task؛ و معیارهای Usability و SUS طراحی اندازه‌گیری را. این مقاله آن‌ها را تکرار نمی‌کند؛ فقط Evidence مربوط به معماری انتخاب و اثر احتمالی آن را منسجم می‌کند.

چرا «بد UX یا فریب عمدی» دوگانهٔ امنی نیست؟

UI ممکن است به‌دلیل خطای پیاده‌سازی، محدودیت Platform، Debt طراحی، Localisation ناقص، Requirement تجاری، آزمایش رشد، تصمیم آگاهانه یا ترکیبی از آن‌ها نامتقارن باشد. تستر از Screenshot ذهن طراح را نمی‌خواند. Intent نیازمند Artifactهایی مانند Decision log، Experiment goal، Review record و شهادت/تحلیل نقش‌های واجد صلاحیت است؛ حتی آن‌ها نیز باید با Counterevidence و Context خوانده شوند.

پس عبارت دقیق‌تر این است: «در Build و State ثبت‌شده، گزینهٔ رد نسبت به پذیرش سه گام و ۱۸ ثانیه Median بیشتر داشت و Disclosure هزینه بعد از Commitment نمایش داده شد.» این Observation قابل‌بررسی است. عبارت «شرکت عمداً کاربر را دزدید» از Evidence موجود فراتر می‌رود.

نردبان ادعا را از هم جدا کنید

1. OBSERVATION = آنچه در نسخه/State مشخص دیده شد
2. PATTERN_CANDIDATE = شباهت به Taxonomy ثبت‌شده
3. MECHANISM_HYPOTHESIS = چگونه شاید Choice را تغییر دهد
4. MEASURED_EFFECT = اختلاف برآوردشده در Protocol مشخص
5. HARM_ASSESSMENT = نوع/شدت/توزیع زیان احتمالی
6. INTENT_ASSESSMENT = تحلیل جداگانه با Evidence سازمانی
7. APPLICABILITY / LEGAL ASSESSMENT = نظر نقش واجد صلاحیت
8. DECISION / REMEDY = انتخاب Owner با شروط و Review

عبور از هر پله Evidence تازه می‌خواهد. Pattern candidate به‌تنهایی اثر، Harm، قصد یا غیرقانونی‌بودن را ثابت نمی‌کند؛ A/B نیز اگر اثر Choice را نشان دهد، لزوماً Mechanism، رضایت آگاهانه یا Lawfulness را حل نمی‌کند.

رکورد پایه را پیش از برچسب بسازید

RecordID / Version / Status / Owner / AsOf / ReviewAt
Product / Release / Journey / Screen / Route / State
Locale / Channel / Device / Viewport / Configuration
Population / Role / Experience / Language / Ability / Context
ChoiceSet / UserGoal / Options / Default / Exit / Reversal
Disclosure / Presentation / Interaction / PersistedState
Observation / PatternCandidate / MechanismHypothesis
Evidence / Counterevidence / Unknown / AlternativeExplanation
Effect / Harm / IntentStatus / ApplicabilityStatus
Decision / Remedy / Verification / Correction / Supersedes

Record باید بگوید چه چیزی درخواست نشده است: اثبات قصد، تشخیص پزشکی/روانی، رتبه‌بندی اخلاقی فرد، تفسیر قانون یا تضمین Outcome تجاری. این Not-requestedها از Scope creep جلوگیری می‌کنند.

Taxonomy نقشه است، Oracle نیست

منابع مختلف نام‌ها و مرزهای متفاوت دارند. FTC از تاکتیک‌هایی مانند تبلیغ مبدل، دشواری لغو، پنهان‌کردن Term/Fee و فریب برای واگذاری داده صحبت می‌کند؛ OECD تعریف کاری و طبقه‌بندی گسترده‌تری از Steering/Deception/Coercion/Manipulation و Harm ارائه می‌دهد؛ EDPB روی Interfaceهای شبکهٔ اجتماعی و اصول حفاظت داده تمرکز دارد. نام Taxonomy، Version و Mapping خود را ثبت کنید و برچسب را حقیقت ذاتی UI ندانید.

خانوادهٔ Candidate	مشاهدهٔ آزمون‌پذیر	چیزی که خودکار ثابت نمی‌شود
Obstruction	خروج/لغو گام، زمان یا کانال بیشتری دارد	قصد یا نقض قانون
Interface interference	ترتیب، رنگ، اندازه یا Salience نامتقارن است	اثر بر همهٔ کاربران
Sneaking	Fee/Item/Term دیر یا بدون Action روشن ظاهر می‌شود	پنهان‌کاری عمدی
Forced action	داده/Action اضافی شرط ادامه شده است	ضرورت یا عدم ضرورت حقوقی
Nagging	درخواست ردشده با Frequency مشخص برمی‌گردد	Coercion یا Harm قطعی
Social/urgency claim	Countdown، Scarcity یا Social proof نمایش داده می‌شود	دروغ بودن Claim

الگوها اغلب ترکیبی و Stateful هستند

یک صفحه ممکن است به‌تنهایی بی‌خطر به نظر برسد، اما Default عضویت، Disclosure دیرهنگام، CTA برجسته، Back path شکسته و Reminder تکراری در چند Session با هم عمل کنند. CandidateIDها را جدا ثبت کنید و یک CombinationID برای ترتیب، فاصلهٔ زمانی، Dependency و اثر تجمعی بسازید. Screenshot تک‌صفحه‌ای State history را نشان نمی‌دهد.

Choice Set واقعی را استخراج کنید

Choice فقط دکمه‌های دیده‌شده نیست. گزینهٔ No action، Back، Close، Timeout، Browser back، تغییر Channel، تماس با Support، لغو بعدی و Reversal را نیز مدل کنید. مشخص کنید هر گزینه چه Outcome، هزینه، داده، Commitment و State سمت سروری دارد. گزینه‌ای که دیده می‌شود اما Error می‌دهد، Choice عملی نیست.

ChoiceID / Label / Outcome / Commitment / Cost / Data
AvailableWhen / VisibleWhen / EnabledWhen / Default
Steps / Inputs / Wait / Channel / Authentication
ServerMutation / Receipt / Undo / Cancel / Expiry
FailureState / Recovery / SupportAlternative

Disclosure را با لحظهٔ تصمیم بسنجید

وجود Term در Footer یا Tooltip کافی نیست. متن، مبلغ، واحد پول، Fee، Tax، Delivery، Recurrence، Trial conversion، Renewal، Cancellation، Data use و Material restriction را به Decision point وصل کنید. آیا کاربر پیش از Commitment آن را می‌بیند؟ آیا متن در همان Locale، Viewport و Assistive path قابل‌دسترسی است؟ آیا Update بعدی Receipt می‌سازد؟

هزینهٔ پنهان را با Price Timeline پیدا کنید

PriceEventID / JourneyStep / DisplayedAmount / Currency
MandatoryOrOptional / SelectedBy / Removable / Reason
Tax / Shipping / ServiceFee / Recurrence / RenewalDate
BeforeCommitVisible / ConfirmationVisible / ReceiptVisible
CanonicalIRR / DisplayTomanLabel / Rounding / LocaleDigits

در بازار ایران، ریال/تومان و رقم فارسی/لاتین می‌توانند اختلاف واقعی بسازند. «۱۲۰ هزار» بدون Currency/Unit یا جمعی که در Callback با IRR ذخیره و در UI با تومان نمایش می‌شود، باید با Oracle حسابداری و Presentation جدا آزموده شود. Tax یا Shipping واقعی همیشه «پنهان» نیست؛ زمان، وضوح، اجتناب‌پذیری و مبنای نمایش مهم‌اند.

Default و Preselection را End-to-End تست کنید

DOM اولیه، Hydration، API response، Local storage، Account preference، Experiment bucket، Revisit و Cross-device state را بررسی کنید. Checkbox ممکن است بصری خالی اما مقدار Submit آن true باشد؛ Toggle پس از Validation برگردد؛ یا رد کاربر در Device دیگر حفظ نشود. Initial، selected، confirmed، persisted، revoked و expired state را جدا Capture کنید.

برجستگی بصری را به یک Color diff تقلیل ندهید

Order، Position، Size، Contrast، Whitespace، Motion، Sticky behavior، Focus order، Copy length، Icon، Proximity و تکرار همگی Presentation هستند. تفاوت بصری لزوماً فریب نیست و برابری Pixel نیز برابری Choice نمی‌سازد. Measurement را با Task، Population و Neutral comparator تفسیر کنید.

زبان شرمسارکننده را بدون ذهن‌خوانی ثبت کنید

Copy دقیق، Locale، Tone rubric و Alternative neutral را ذخیره کنید. «نه، من پس‌انداز نمی‌خواهم» ممکن است Candidate برای Emotional steering باشد؛ تستر می‌تواند Valence، Presupposition، Loss frame و نسبت متن Accept/Decline را Coding کند، اما احساس واقعی همهٔ کاربران یا قصد نویسنده را از یک جمله نتیجه نگیرد.

Scarcity و Countdown دو Oracle می‌خواهند

Oracle اول صحت Claim است: Inventory/source/timezone/reset/cache/reservation و رابطهٔ Message با داده. Oracle دوم اثر Choice است: آیا Countdown توجه، فهم یا رفتار را تغییر می‌دهد؟ Timer واقعی ممکن است همچنان نیازمند Disclosure باشد؛ Timer دروغین یک Finding صحت مستقل است. تغییر متن یا Reset پس از Refresh را با Clock کنترل‌شده بازتولید کنید.

Social Proof به Source و Population نیاز دارد

«۲۳ نفر اکنون می‌خرند» را به Event source، Window، Unique rule، Bot exclusion، Geography و Refresh semantics متصل کنید. حتی عدد صحیح ممکن است برای Population دیگر گمراه‌کننده برداشت شود؛ این Interpretation باید جدا آزموده شود. Popularity دلیل کیفیت، ضرورت یا Suitability نیست.

لغو را با Symmetry Record بسنجید

EntryChoice / ExitChoice
Channel / Authentication / Steps / Clicks / Inputs / Scroll
MedianTime / Error / Assistance / Wait / OfficeHours
Disclosure / Confirmation / Receipt / EffectiveAt
PartialCancel / Pause / RetentionOffer / Back / Undo
DataAfterCancel / BillingAfterCancel / ReSubscribe

Symmetry به معنای Pixel یا ثانیهٔ کاملاً برابر نیست؛ تفاوت باید با Function، Risk و Constraint تحلیل شود. DSA Article ۲۵ دشوارترکردن Termination نسبت به Subscription را یکی از مواردی می‌داند که Commission می‌تواند درباره‌اش Guidance دهد، اما Scope ماده و پوشش سایر EU regimes را باید نقش حقوقی حل کند.

Nagging را در طول زمان مشاهده کنید

PromptID، Trigger، Frequency cap، Dismissal، Snooze، Session/account persistence، Reset event، Channel و Escalation را ثبت کنید. یک Popup شاید آزاردهنده باشد؛ پنج Popup پس از Decline صریح یک الگوی زمانی متفاوت است. تست سریع در Session تازه معمولاً Memory و Frequency را از دست می‌دهد.

Forced Action را از Dependency لازم جدا کنید

برای هر Field/Permission/Account creation بپرسید: کدام Function به آن وابسته است؟ آیا جایگزین کم‌داده وجود دارد؟ آیا Purpose و Retention روشن است؟ آیا Skip واقعاً مسیر را می‌بندد؟ QA دربارهٔ Legal basis تصمیم نمی‌گیرد. Test evidence را به راهنمای تست حریم خصوصی و رضایت تحویل دهید.

Consent banner فقط مسئلهٔ ظاهر نیست

Accept/Reject/Manage، Purpose granularity، Vendor state، pre-consent traffic، withdrawal، propagation و proof receipt را End-to-End ببینید. CTA parity بدون جلوگیری از Request پیش از Consent کافی نیست؛ و Block شدن Script نیز به‌تنهایی Applicability یا رضایت معتبر را ثابت نمی‌کند. EDPB guidance به‌طور خاص در Context شبکه‌های اجتماعی/حفاظت داده خوانده می‌شود، نه Oracle جهانی هر UI.

Accessibility بخشی از Distribution Effect است

گزینهٔ Decline ممکن است برای Mouse دیده شود اما در Focus order، Screen reader name، Zoom/Reflow یا Voice control گم شود. این هم Barrier فنی و هم تفاوت Exposure به Choice architecture است. آزمون WCAG و ادعای Conformance را به راهنمای انطباق دسترس‌پذیری بسپارید؛ این Record فقط اثر بر گزینه‌ها و Population را لینک می‌کند.

Vulnerability صفت ثابت فرد نیست

زبان ناآشنا، سواد دیجیتال، فشار زمانی، اضطراب، Device کوچک، اینترنت ناپایدار، وضعیت مالی، سن، Ability و Task پرخطر می‌توانند Context آسیب‌پذیری بسازند. گروه‌ها را با برچسب تحقیرآمیز رتبه‌بندی نکنید. Exposure و Effect difference، Safeguard و Unknown را با مشارکت امن و حداقل داده بررسی کنید.

فارسی و RTL می‌توانند Choice را جابه‌جا کنند

ی/ی، ک/ک، ZWNJ، ارقام فارسی/عربی/لاتین، Bidi، LTR token، Line wrap، دکمهٔ برگشت، جای Icon، واحد پول و تاریخ جلالیِ نمایشی را پوشش دهید. ترجمهٔ طولانی ممکن است Decline را زیر Fold ببرد یا Negation را از CTA جدا کند. از نسخهٔ انگلیسی سالم، سلامت فارسی را استنتاج نکنید.

Mobile، Web و App یک Surface نیستند

Viewport، Safe area، Bottom sheet، OS permission، WebView، Keyboard، Deep link، App-store subscription و System back رفتار Choice را عوض می‌کنند. Surface matrix بسازید و Screenshot را با DOM/accessibility tree، network-free fixture و Server state تکمیل کنید.

Baseline خنثی را پیش از مقایسه تعریف کنید

نسخهٔ «خنثی» نباید قیمت، Function، Latency، Content completeness یا Error rate متفاوت داشته باشد. Neutral comparator، Business-rule parity و اختلاف‌های باقی‌مانده را پیش‌ثبت کنید. مقایسهٔ CTA آبی سریع با CTA خاکستری کند اثر رنگ را جدا نمی‌کند.

BaselineID / CandidateID
Same: function, price, content, latency, errors, data, eligibility
Changed: order | salience | copy | default | friction | timing
ExpectedMechanism / PrimaryMetric / Guardrail
KnownDifferences / Contamination / Limits

Oracle را پیش از دیدن نتیجه ثبت کنید

Construct، Metric، Numerator/denominator، Direction، Threshold، Window، Population، Missing/Unknown rule و Not-proven را قبل از Run بنویسید. «اگر Conversion بالا رفت، Dark Pattern است» Oracle نیست؛ Conversion ممکن است با وضوح بهتر، Bug fix یا Traffic mix تغییر کند.

Observation test از User-effect test جداست

• Conformance observation: آیا Fee پیش از Commit دیده می‌شود؟
• State test: آیا Decline پس از Refresh حفظ می‌شود؟
• Parity test: ورود و خروج چه Frictionی دارند؟
• Comprehension study: شرکت‌کننده Term را چگونه فهمید؟
• Behavioral experiment: Variant چه اختلافی در Choice ایجاد کرد؟
• Outcome review: Complaint، Refund یا Cancellation بعدی چه تغییری کرد؟

این روش‌ها جای هم را نمی‌گیرند. DOM assertion اثر انسانی را ثابت نمی‌کند و User study کوچک صحت هر State/Backend را پوشش نمی‌دهد.

Protocol مشاهدهٔ بازتولیدپذیر

ObservationID / Build / Commit / FeatureFlags / ExperimentBucket
Route / AccountState / DataFixture / Locale / Device / Viewport
Clock / NetworkProfile / Cache / ConsentState / SubscriptionState
Steps / Expected / Observed / ServerMutation / Receipt
ScreenshotHash / VideoRef / DOMRef / EventRef / Reproducer
Collector / CollectedAt / Counterevidence / Limit

Evidence باید کمینه و مجاز باشد. Screenshot واقعی ممکن است نام، شماره، موجودی، Cookie یا Token داشته باشد؛ Fixture ساختگی و Redaction در Source ترجیح دارد. Evidence بدون Build/State به‌سرعت کهنه می‌شود.

Instrumentation را خودش تست کنید

Event name کافی نیست. Trigger point، Semantic، Duplicate، retry، bot، session/user identity، consent boundary، clock، loss، late event و validation را ثبت کنید. اگر `cancel_started` هنگام Render و `subscribe_completed` پس از Server commit صادر شود، Funnel نامتقارن و نتیجه جعلی است.

Funnel بدون Denominator خطرناک است

Eligible، Exposed، Visible، Interacted، Submitted، Confirmed، Effective و Reversed جمعیت‌های متفاوت‌اند. نرخ را با Numerator/denominator، Window، Deduplication، Segment، Missing و Freshness گزارش کنید. درصد بالای Accept ممکن است فقط کاربران واجد شرایط Reject را حذف کرده باشد.

تحقیق کیفی را Neutral طراحی کنید

به‌جای «آیا این صفحه فریبنده بود؟» Task طبیعی بدهید و بپرسید کاربر فکر می‌کند بعد از Action چه رخ می‌دهد. Moderator script، Probe rule، Think-aloud boundary، Coding guide، Double coding و Disagreement را ثبت کنید. نقل‌قول را بدون Context یا به‌عنوان رأی اکثریت مصرف نکنید.

شرکت‌کننده ابزار تست رایگان نیست

Notice، مشارکت داوطلبانه، Withdrawal، Compensation، Recording choice، Purpose، Minimum data، Retention، Access و Delete route لازم‌اند. گروه آسیب‌پذیر را برای اثبات Harm در معرض هزینه یا اشتراک واقعی نگذارید. Task محلی، Wallet خیالی و Exit بدون پیامد بسازید.

A/B test مجوز دستکاری نیست

Experiment باید Governance، Risk review، Eligibility، Allocation، Exposure cap، Stop rule، Guardrail و Data minimization داشته باشد. Variant پرریسک را به Production نبرید فقط چون برای اندازه‌گیری «اثر واقعی» داده می‌خواهید. Lab، Prototype یا Study کنترل‌شده می‌تواند سؤال را با ریسک کمتر پاسخ دهد.

اثر را با عدم‌قطعیت گزارش کنید

Estimate، Interval، Sample/Power plan، Attrition، Missingness، Multiple testing، Segment size، Sensitivity و Robustness را بیاورید. `p<۰.۰۵` نه اهمیت عملی را ثابت می‌کند، نه Harm و نه Legality. نتیجهٔ Inconclusive را شکست پروژه ندانید.

Metricها را سبدی ببینید

• Selection/Completion و Reversal؛
• Time، Step، Error و Assistance؛
• Comprehension و Recall؛
• Unexpected charge، Refund و Cancellation؛
• Complaint و Support contact؛
• Privacy withdrawal و Permission revocation؛
• Outcome به تفکیک Locale/Device/Ability/Context؛
• Business metric همراه Guardrail، نه به‌تنهایی.

Conversion کوتاه‌مدت ممکن است بالا و Reversal/Complaint بلندمدت نیز بالا رود. ارتباط اعتماد/شهرت چندعلتی است؛ مرز آن در راهنمای وعده تا شواهد مشتری توضیح داده شده است.

Harm را نوع، زمان و توزیع‌پذیر کنید

HarmID / AffectedParty / Population / Journey / TimeHorizon
Financial / Privacy / Autonomy / Time / Cognitive / Emotional
Accessibility / Opportunity / Cumulative / Reversibility
Exposure / Magnitude / Confidence / Evidence / Counterevidence
Distribution / VulnerabilityContext / Remedy / ResidualUnknown

یک کلیک اضافه Harm قطعی نیست؛ هزینهٔ کوچک تکراری نیز ممکن است تجمعی باشد. Severity را از Pattern label استخراج نکنید. Exposure، Magnitude، Reversibility، Duration، Population و گزینهٔ جبران را جدا تحلیل کنید.

قصد را Status چندحالته نگه دارید

NOT_ASSESSED / UNKNOWN / EVIDENCE_CONFLICT / QUALIFIED_REVIEW / DOCUMENTED از true/false امن‌تر است. Growth goal، Ticket، Copy review، A/B hypothesis، Incentive و Escalation ممکن است Evidence باشند؛ اما باید Scope، نویسنده، زمان، Counterevidence و Authority بررسی شود. QA نباید Motive را از KPI یا ظاهر استنتاج کند.

منابع رسمی چه می‌گویند و چه نمی‌گویند؟

گزارش رسمی FTC در سال ۲۰۲۲ نمونه‌ها و موضوعات اجرایی آمریکا را شرح می‌دهد؛ گزارش OECD دربارهٔ Dark Commercial Patterns یک تعریف کاری، شواهد شیوع/اثر/Harm و پاسخ‌های سیاستی عرضه می‌کند. این دو منبع Taxonomy و Risk question می‌دهند، نه حکم خودکار دربارهٔ محصول ایرانی.

Guidelines ۰۳/۲۰۲۲ نهایی EDPB در Context رابط شبکه‌های اجتماعی و اصول GDPR خوانده می‌شود. مادهٔ ۲۵ DSA برای Providerهای مشمول Online platform، طراحی/سازمان‌دهی/عملیات Interface را با توان تصمیم آزاد و آگاهانه پیوند می‌دهد و در بند ۲، Practiceهای پوشش‌یافته توسط Directive ۲۰۰۵/۲۹/EC یا GDPR را از منع همان ماده جدا می‌کند. Applicability را از یک Screenshot نتیجه نگیرید.

قانون تجارت الکترونیکی ایران را محدود و دقیق بخوانید

متن قانون تجارت الکترونیکی ایران در مواد ۳۳ تا ۳۵ برای Context مصرف‌کننده/معاملهٔ الکترونیکی دربارهٔ اطلاعات مؤثر پیش از عقد، هزینه‌ها، شرایط پرداخت/تحویل/فسخ، تأیید جداگانه و ارائهٔ روشن/صریح/به‌موقع در واسط بادوام متن دارد؛ مادهٔ ۳۷ نیز حق انصراف را با Scope و استثناهای خود بیان می‌کند. این Instrument منبع سؤال‌های Price/Disclosure/Cancel است، نه مجوز QA برای اعلام اینکه هر Candidate «جرم» یا «غیرقانونی» است.

Applicability Record را جدا نگه دارید

Jurisdiction / Instrument / OfficialSource / Version / AsOf
Entity / Role / ProductOrService / Activity / Territory / Market
ConsumerOrBusiness / DataProcessing / PlatformType / Date
ClauseCandidate / Exception / Overlap / EnforcementContext
QualifiedReviewer / Status / Rationale / NotConcluded

FTC، OECD، DSA، GDPR/EDPB و قانون ایران Instrumentهای هم‌ارز یا قابل‌جایگزینی نیستند. OECD قانون نیست؛ Guidance و Staff report نیز همان Statute/Regulation نیستند. برچسب «Dark Pattern» Applicability را ایجاد نمی‌کند.

Finding را بدون Verdict بنویسید

FindingID / RecordVersion / PatternCandidate / Status
Population / Journey / Build / State / Condition
CriteriaSource / Expected / Observed / EvidenceRefs
MechanismHypothesis / AlternativeExplanation / Counterevidence
MeasuredEffect / Interval / HarmCandidate / Confidence
IntentStatus / ApplicabilityStatus / Owner / ResponseDue
NotProven = intent, deception, harm, causality, illegality

Severity فقط از اسم «Roach motel» نمی‌آید. Reach، Decision materiality، پول/داده، Reversibility، Context آسیب‌پذیری، تکرار، Recovery و Evidence quality را لحاظ کنید. Observation/Interpretation/Recommendation را در متن Ticket جدا کنید.

تصمیم فقط Fix یا Ignore نیست

• Remove یا Correct؛
• Replace با Alternative خنثی؛
• Modify Disclosure/Timing/Default/Friction؛
• Pause Experiment یا Journey؛
• Collect Evidence در Lab کم‌خطر؛
• Escalate برای Privacy/Legal/Accessibility/Ethics review؛
• Accept محدود با Authority، شرط، Residual risk و Expiry؛
• Unknown/Hold تا رفع تعارض.

Owner، Authority و Dissent را ثبت کنید. تستر Evidence و Option می‌دهد؛ تصمیم تجاری یا حقوقی را به‌تنهایی امضا نمی‌کند.

Remedy باید Mechanism را هدف بگیرد

اگر مشکل Disclosure دیرهنگام است، فقط رنگ CTA را تغییر ندهید. اگر Friction لغوست، Tooltip اضافه کافی نیست. Mechanism target، Alternative، Accept/Reject و Subscribe/Cancel parity، Cost timing، Copy correction، State migration، Rollback و Side effect را ثبت کنید.

Verification فقط Screenshot سبز نیست

Observation اصلی، Backend state، Telemetry semantics، Population/Locale/Device، Reversal، Receipt و Longitudinal guardrail را Retest کنید. Fix ممکن است CTA را برابر کند اما Focus order را بشکند؛ Cancel را ساده کند اما Billing job را باقی بگذارد؛ یا Fee را زود نشان دهد اما جمع کل فارسی را اشتباه کند.

Correction تاریخ را پاک نمی‌کند

اگر Event semantics، Build، Screenshot، Translation، Sample یا Legal source اشتباه بود، CorrectionID با Old/new claim، Affected findings/decisions/releases، Reason، Issuer، Time و Recipient confirmation بسازید. رکورد قبلی را Silent edit نکنید.

آزمایش قطعی: پنج چراغ سبز ناکافی

یک Validator مستقل و بدون Dependency با Node.js ۲۴.۱۸.۰ روی Fixture کاملاً ساختگی اجرا شد. Checker سطحی فقط دید Cancel قابل‌مشاهده است، Checkbox از پیش انتخاب نشده، همهٔ هزینه‌ها جایی نمایش داده شده‌اند، Copy خنثی است و Usability pass شده؛ سپس به‌اشتباه نتیجه داد:

SUPERFICIAL=FAIR_AND_LEGALLY_COMPLIANT

ممیز ۲۸۸ کنترل یکتا را در ۲۹ گروه Identity، Request، Surface، Population، Choice، Disclosure، Presentation، Interaction، State، Pattern، Observation، Baseline، Oracle، Instrumentation، Experiment، Qualitative، Consent، Metric، Uncertainty، Harm، Vulnerability، Intent، Applicability، Evidence، Finding، Decision، Remediation، Lifecycle و Limits بررسی کرد. هیچ‌کدام در Fixture سطحی نبود:

CONTROL_COUNT=288
AUDIT=HOLD-288
INDEPENDENT_PARTICIPANT=real-user-or-participant:false:PASS

قاعدهٔ مستقل تأیید کرد هیچ کاربر یا Participant واقعی وارد آزمایش نشده است. پس از پرکردن همهٔ فیلدهای ساختاری با مقدارهای ساختگی و فعال‌کردن مرزهای no intent/deception/manipulation/harm/causality/applicability/illegality/compliance/fairness/business-outcome proof، نتیجه شد:

CORRECTED=READY_FOR_DECEPTIVE_DESIGN_REVIEW-0
BOUNDARY=structure-only; no intent, deception, manipulation,
harm, causality, applicability, illegality, compliance,
fairness, or business outcome proven

چرا صفر Finding هنوز Fairness نیست؟

ممکن است Taxonomy ناقص، Comparator غیرخنثی، Instrumentation خراب، Population حذف‌شده، Effect کم‌توان، Harm دیررس، Intent evidence خارج دسترس یا Instrument حقوقی اشتباه باشد. Completeness ساختار مساوی Fair، Ethical، Compliant یا Harmless نیست.

آزمایشگاه فارسی کاملاً آفلاین

یک Checkout خیالی را فقط با HTML/JS محلی و State در حافظه بسازید: Plan انتخابی، Add-on ساختگی، Trial، Fee، Subscription، Cancel و Receipt. Variant A یک Checkbox خالی، Fee پیش از Commit و Cancel دوگامی دارد؛ Variant B Add-on را در State انتخاب می‌کند، Fee را پس از Action اولیه نشان می‌دهد و Cancel چهارگامی است. این تفاوت‌ها عمداً Fixture آزمون‌اند، نه محصول یا شرکت واقعی.

هویت Participant نیز وجود ندارد؛ Script قطعی تمام Choiceها را طی می‌کند و DOM/State/Event را مقایسه می‌کند. مبلغ‌ها IRR خیالی‌اند و تومان فقط Presentation برچسب‌خورده است. ی/ی، ک/ک، ZWNJ، ارقام فارسی/عربی/لاتین، RTL/LTR/Bidi، UTC/Asia/Tehran و تاریخ جلالی صرفاً نمایشی پوشش داده می‌شوند.

LabBoundary = {
  network: false,
  production: false,
  realProductOrCompany: false,
  realUserOrParticipant: false,
  realMoneyOrPersonalData: false,
  intentOrLegalityDetermined: false,
  purpose: "validate evidence-record structure only"
}

تمرین پنج‌مرحله‌ای Lab

1. Choice Set و Price Timeline هر Variant را استخراج کنید.
2. Observationهای DOM/State/Event را با Build و Fixture ثبت کنید.
3. Candidateها را با Taxonomy نسخه‌دار Label و Alternative explanation اضافه کنید.
4. Baseline parity و Oracle را پیش از اجرای Script تعیین کنید.
5. Remedy ساختگی اعمال، Retest و سپس یک Correction نسخه‌دار تزریق کنید.

Anti-patternهایی که خود تیم تست باید رد کند

• «UI بد است، پس طراح قصد فریب داشته»؛
• «دکمهٔ Cancel هست، پس خروج آسان است»؛
• «Checkbox خالی است، پس State رضایت false است»؛
• «همهٔ Feeها جایی نوشته شده، پس شفاف‌اند»؛
• «Copy خنثی است، پس Choice آزاد است»؛
• «Usability pass شد، پس Dark Pattern نداریم»؛
• «Conversion بالا رفت، پس اثر Pattern ثابت شد»؛
• «A/B معنادار است، پس Harm و Causality قطعی‌اند»؛
• «پنج کاربر ناراحت شدند، پس همه آسیب دیده‌اند»؛
• «هیچ‌کس شکایت نکرد، پس Harm نداریم»؛
• «Taxonomy label یعنی نقض قانون»؛
• «FTC/OECD/DSA عیناً در ایران اعمال می‌شود»؛
• «GDPR هر Consent banner را با یک Oracle حل می‌کند»؛
• «تومان/ریال فقط مسئلهٔ ترجمه است»؛
• «Screenshot برای Proof کافی است»؛
• «Telemetry همان معنایی را دارد که اسمش می‌گوید»؛
• «Intent را از KPI رشد می‌توان خواند»؛
• «Fix ظاهری Backend state را هم اصلاح کرده»؛
• «AI می‌تواند Fairness یا Legality نهایی بدهد»؛
• «فرم کامل یعنی محصول اخلاقی و منصفانه است».

چک‌لیست Owner پیش از تصمیم

• RecordID، نسخه، Scope، Owner، AsOf و Supersession روشن است.
• Product/Build/Journey/Screen/State/Locale/Device ثابت‌اند.
• Population و Context بدون برچسب‌زنی آسیب‌زا ثبت شده‌اند.
• Choice، No action، Exit، Reversal و Server outcome کامل‌اند.
• Disclosure و Price/Term timeline به Decision point وصل‌اند.
• Default، persisted، revoked، expired و cross-device state آزموده‌اند.
• Presentation و Interaction جدا اندازه‌گیری شده‌اند.
• Pattern candidate دارای Taxonomy/version و Combination است.
• Observation از Mechanism/Effect/Harm/Intent/Law جداست.
• Comparator از نظر Function/Price/Content/Latency برابر است.
• Oracle، denominator، Unknown و Not-proven پیش‌ثبت شده‌اند.
• Event semantics، duplicate، loss، clock و identity Validate شده‌اند.
• Study/Experiment دارای Governance و Stop rule است.
• Participant notice/withdrawal/data/recording امن است.
• Estimate با Interval/Missing/Attrition/segment limits گزارش شده است.
• Harm بر حسب نوع/توزیع/زمان/برگشت‌پذیری تحلیل شده است.
• Intent چندحالته و بدون ذهن‌خوانی مانده است.
• Applicability با Instrument رسمی و Reviewer واجد صلاحیت جداست.
• Finding دارای Counterevidence و Alternative explanation است.
• Decision authority، Dissent، Condition و Review date ثبت شده‌اند.
• Remedy Mechanism را هدف گرفته و Side effect دارد.
• Verification، Backend/Telemetry/Population/Longitudinal را پوشش می‌دهد.
• Correction به Finding/Decision/Release متاثر رسیده است.
• هیچ Fairness، Compliance، قصد یا Outcome تضمین نشده است.

Pilot سی‌روزهٔ Deceptive Design Testing

هفتهٔ اول: سه Journey تاریخی Sanitized را به Choice/Disclosure/State map تبدیل کنید. هفتهٔ دوم: Taxonomy، Observation protocol و Baseline parity را روی Fixture محلی تمرین کنید. هفتهٔ سوم: Event contract و Metric/uncertainty را با دادهٔ ساختگی Validate کنید. هفتهٔ چهارم: Finding، Decision، Remedy، Retest و Correction را در Tabletop اجرا کنید.

شاخص Pilot تعداد «Dark Pattern پیدا شده» نیست. Observation بی‌نسخه، Choice ناقص، Fee بدون Timeline، Default بدون Server state، Taxonomy بی‌نسخه، Comparator آلوده، Event بی‌معنا، Metric بدون denominator، Effect بدون uncertainty، Intent ذهن‌خوانی‌شده، Law بدون Applicability، Fix بدون Retest و Correction بی‌رسید را بشمارید. این سنجه برای رتبه‌بندی طراح یا تستر نیست.

منابع چگونه استفاده شده‌اند؟

FTC و OECD برای Vocabulary، Candidate mechanism و Harm question؛ EDPB برای Deceptive design در Context رابط شبکهٔ اجتماعی/حفاظت داده؛ DSA Article ۲۵ برای نمونهٔ Instrument با Scope/overlap مشخص؛ و مواد ۳۳ تا ۳۷ قانون تجارت الکترونیکی ایران برای سؤال‌های محدود اطلاعات پیش از عقد، هزینه، وضوح، تأیید و انصراف استفاده شدند. هیچ منبعی Intent، Harm، Applicability یا غیرقانونی‌بودن Case واقعی را برای QA پیشاپیش ثابت نمی‌کند.

جمع‌بندی

تست الگوهای تاریک یعنی معماری انتخاب را قابل‌مشاهده و قابل‌مقایسه کنیم: Choice/Disclosure/Presentation/Friction/State را نسخه‌دار، Baseline و Oracle را پیش‌ثبت، اثر و Harm را با عدم‌قطعیت، Intent و قانون را جدا و Remedy را تا Backend و Population Verify کنیم. حرفه‌ای‌بودن یعنی از یک UI نامطلوب، ذهن یا جرم نسازیم؛ اما ابهام و اثر نامتقارن را نیز پشت «سلیقهٔ طراحی» پنهان نکنیم.

سوالات متداول

تفاوت Dark Pattern با UX ضعیف چیست؟

از روی ظاهر همیشه نمی‌توان تفاوت را تعیین کرد. تستر Observation، Pattern candidate و اثر را ثبت می‌کند؛ Intent به Evidence سازمانی و بررسی جدا نیاز دارد. UX ضعیف، Candidate فریبنده و Practice غیرقانونی سه Verdict هم‌معنا نیستند.

آیا چک‌لیست Dark Pattern برای اعلام Pass کافی است؟

خیر. Taxonomy ممکن است State، ترکیب، Population، Context و الگوی تازه را از دست بدهد. Checklist برای Discovery مناسب است؛ Pass به Scope، Choice model، Evidence، Comparator، Oracle، Backend state و Unknownهای ثبت‌شده وابسته است و Fairness کلی را ثابت نمی‌کند.

آیا اختلاف آماری A/B ثابت می‌کند کاربر دستکاری شده است؟

نه. اختلاف می‌تواند اثر Variant را در Protocol و Population مشخص پشتیبانی کند، به شرط Comparator سالم و Instrumentation معتبر. Mechanism، Harm، Autonomy، Intent، Causality گسترده و Legality به Evidence و Review جدا نیاز دارند.

آیا هر فرایند لغو طولانی یک الگوی تاریک است؟

خودکار نه. Friction، Function، Risk، Authentication، Channel، زمان، Error، Support و تفاوت با ورود را ثبت کنید. پیچیدگی ممکن است توضیح معتبر، جایگزین بهتر یا ناموجه داشته باشد؛ Pattern/Applicability decision باید با Evidence انجام شود.

تستر Dark Pattern را چگونه گزارش کند؟

با Build/Journey/State/Population، Expected/Observed، Evidence، Pattern candidate و Taxonomy version، Mechanism hypothesis، Alternative explanation، Effect/uncertainty، Harm candidate، Intent/Applicability status و Remedy قابل‌Verify. از برچسب «فریب عمدی و غیرقانونی» بدون بررسی واجد صلاحیت پرهیز کند.