وقتی تستر روی Wireframe مینویسد «کاربر این دکمه را پیدا نمیکند»، هنوز یک یافته درباره کاربر نداریم؛ یک فرضیه از نگاه یک عضو تیم داریم. همین فرضیه میتواند بسیار ارزشمند باشد—اگر به سؤال، روش بررسی، شواهد و تصمیم تبدیل شود. مشکل از جایی شروع میشود که نظر QA با صدای کاربر، تست پروتوتایپ با اثبات محصول و حضور زودهنگام با تضمین موفقیت یکی گرفته شود.
این راهنما مشارکت تستر در طراحی محصول را به یک Product Design Contribution Record تبدیل میکند: زمینه و تصمیم را پین میکنیم، فرض و ریسک را از نیاز اثباتشده جدا میکنیم، توان و محدودیت Prototype را ثبت میکنیم، سؤال کیفیت و روش شواهد را انتخاب میکنیم، مشاهده را بدون تعمیم گزارش میدهیم، گزینه و trade-off میسازیم و تصمیم را تا Build و Outcome بازبینی میکنیم.
پاسخ کوتاه: تستر چگونه به طراحی محصول کمک میکند؟
- فرضهای مبهم درباره کاربر، جریان، داده، حالت، خطا و بازیابی را به سؤال قابل بررسی تبدیل میکند.
- حالت عادی، مرزی، شکست، وقفه، retry، برگشت و دسترسپذیری را پیش از Build مدل میکند.
- برای هر ادعا مشخص میکند Expert Review، User Research، Conformance Check، Technical Spike یا داده Production لازم است.
- محدودیت Wireframe، Prototype و داده ساختگی را به Claim Limit وصل میکند.
- Observation، Interpretation، Assumption، Finding، Unknown و Recommendation را از هم جدا نگه میدارد.
- به جای گفتن «این طراحی بد است»، گزینهها و trade-offهای قابل تصمیم ارائه میدهد.
- تصمیم، مالک، شرط، شواهد لازم، نسخه طرح و اثر بر Acceptance/Build/Test را ردیابی میکند.
- پس از پیادهسازی و عرضه، بررسی میکند فرض اولیه تأیید، رد یا همچنان نامعلوم مانده است.
تستر کاربر واقعی یا وکیل همه کاربران نیست
تستر یک منبع تخصصی درباره failure، state، evidence و testability است؛ ممکن است خودش نیز عضوی از یک گروه کاربری باشد، اما عضویت یا همدلی جای نمایندگی را نمیگیرد. راهنمای GOV.UK درباره نیاز کاربر توصیه میکند نظرهایی را که از کاربران نیامدهاند فرضهایی بدانیم که باید با پژوهش بررسی شوند. پس عبارت «کاربر گیج میشود» را به «فرض میکنیم برچسب مقصد برای گروه X قابل تشخیص نیست؛ باید بررسی شود» بازنویسی کنید.
| عبارت اولیه | نوع واقعی | بازنویسی حرفهای |
|---|---|---|
| کاربر این را نمیفهمد | فرضیه | آیا شرکتکننده هدف میتواند بدون راهنمایی مقصد را توضیح دهد؟ |
| این جریان Accessible است | ادعای اثباتنشده | کدام معیار WCAG، فناوری کمکی، کاربر و دامنه بررسی شده است؟ |
| این دکمه خطرناک است | Risk claim | در چه حالت/اثر/برگشتپذیری، چه خطای محتملی و با چه شواهدی؟ |
| تستر نماینده کاربر است | Role overreach | تستر فرض و ریسک را آشکار میکند؛ پژوهشگر/شرکتکننده شواهد کاربر میآورند. |
| پروتوتایپ موفق بود | نتیجه مبهم | کدام سؤال، task، participant، نسخه و criterion چه نتیجهای داشت؟ |
مالکیت محتوایی این راهنما
این مقاله مالک چرخه Design Context → Assumption/Risk → Artifact/Fidelity → Quality Question → Evidence Method → Observation/Finding → Options/Decision → Build Trace → Outcome Review است. راهنمای Shift-left تستر رابط کلی زودهنگام کیفیت را پوشش میدهد؛ راهنمای تست تجربه کاربری مالک مطالعه UX و تبدیل Observation به تصمیم است؛ و رابط تستر و مالک محصول Product Bet و تصمیم محصول را عمیق میکند. اینجا تمرکز فقط Contribution تستر به Design Artifact و تصمیم طراحی است.
Product Design Contribution Record چیست؟
این Record یک یادداشت کامنتی روی Figma نیست؛ قرارداد نسخهدار یک Contribution است. میگوید درباره کدام Product/Outcome/Flow/Artifact و برای کدام Decision صحبت میکنیم، ادعا از کجا آمده، چه چیز معلوم یا نامعلوم است، چه Evidence لازم است و چه کسی اختیار تصمیم دارد.
ContributionID: PDC-SYN-001 Version / Status: v1 / OPEN Product / Outcome: Fake Checkout / بازیابی نتیجه پرداخت DesignArtifact: PROTO-R7 / frame=payment-result / digest=FAKE-77 Fidelity / Missing: clickable / no backend, latency, screen-reader tree DecisionNeed / Due: انتخاب recovery flow / 2026-08-16T09:00:00Z Assumption: کاربر وضعیت Pending را از Failed جدا میکند RiskClaim: retry فوری ممکن است عملیات تکراری بسازد QualityQuestion: پس از timeout چه state/action/evidence لازم است؟ EvidenceMethod: expert state review + technical spike + user study Observation / Unknown: دو مقصد همنام / رفتار واقعی callback نامعلوم Options: A=Retry، B=Status check، C=Reconciliation-first Recommendation / Dissent: C / Product-B prefers B DecisionOwner / Authority: Product-C / DESIGN_DECISION Decision / Conditions / Expiry: C / Spike passes / 2026-09-01 BuildTrace / Review: BUILD-SYN-19 / NOT_YET_REVIEWED ClaimLimit: نه صدای کاربر، نه اثبات UX، امنیت، کیفیت یا موفقیت
مرحله صفر: زمینه و تصمیم را پین کنید
پیش از Review، Product، Product Goal یا Outcome موردنظر، beneficiary فرضی، Flow، Scenario، Platform، Locale، Risk class، Design Artifact/version/digest، وضعیت تصمیم و موعد را ثبت کنید. «صفحه پرداخت» subject کافی نیست؛ نسخه موبایل فارسی یک Prototype بدون backend با صفحه نتیجه پرداخت، subject قابل بازبینیتری است.
- Decision need: بعد از جلسه دقیقاً چه انتخابی باید ممکن شود؟
- Decision owner: چه کسی اختیار این نوع انتخاب را دارد و چه کسی فقط input میدهد؟
- Deadline source: چرا اکنون تصمیم لازم است و اگر عقب بیفتد چه میشود؟
- Evidence minimum: پیش از تصمیم چه سطحی از Evidence لازم است؟
- Harm floor: چه اثر یا ریسکی با trade-off عادی پذیرفتنی نیست؟
- Out of scope: این Review درباره چه چیزی هیچ ادعایی نمیکند؟
مرحله یک: Need، Assumption، Requirement و Design Choice را جدا کنید
| نوع | سؤال | نمونه |
|---|---|---|
| User need | فرد برای رسیدن به چه Outcome نیاز دارد؟ منبع چیست؟ | بر اساس مطالعه UR-۴، نتیجه عملیات نامطمئن را پیگیری کند |
| Assumption | چه چیزی را فعلاً باور کردهایم؟ | واژه «در انتظار» برای گروه هدف قابل فهم است |
| Requirement | چه الزام معتبر و قابل ردیابی وجود دارد؟ | REQ-۱۷ با Source/Version/Applicability |
| Constraint | کدام محدودیت فنی/حقوقی/زمانی معتبر است؟ | Callback ممکن است دیر و تکراری برسد |
| Design choice | کدام راهحل انتخاب شده اما قابل تغییر است؟ | نمایش Status Check به جای Retry |
| Preference | چه کسی چه چیزی را ترجیح میدهد؟ | Designer-A گزینه C را ترجیح میدهد |
برای تحلیل کامل Requirement و منبع/ابهام/آزمونپذیری از چکلیست تحلیل نیازمندی تستر استفاده کنید. در Design Review، هدف تبدیل همه چیز به Test Case نیست؛ هدف جلوگیری از این است که فرض یا preference با برچسب «نیاز کاربر» قطعی شود.
مرحله دو: Fidelity پروتوتایپ را ثبت کنید
راهنمای رسمی GOV.UK درباره Prototype از Sketch تا Prototype کدنویسیشده را متمایز میکند و هشدار میدهد کد Prototype لزوماً استانداردهای امنیت یا Performance محصول واقعی را ندارد. اصل قابل انتقال این است: Artifact را متناسب با سؤال بسازید و نتیجه را فراتر از توان آن تعمیم ندهید.
| Artifact | برای چه سؤالهایی مفید است؟ | چه چیزی را معمولاً ثابت نمیکند؟ |
|---|---|---|
| Sketch/Flow | ترتیب مفهومی، گزینه، حالت جاافتاده | خوانایی واقعی، تعامل، timing، accessibility tree |
| Wireframe | ساختار اطلاعات، مسیر و hierarchy اولیه | کنتراست نهایی، copy واقعی، رفتار component |
| Clickable mock | مسیرهای محدود، label، navigation، task study | backend، race، persistence، network، security |
| Code prototype | تعامل واقعگراتر، responsive/keyboard experiment | Production quality، scale، data integrity، compliance |
| Integrated beta | رفتار end-to-end در محیط/Build مشخص | همه device/user/risk/outcomeهای آینده |
ArtifactRecord: ArtifactID / Version / Digest / Tool / Owner Product / Flow / Frames / CopyVersion / Locale Fidelity: SKETCH|WIREFRAME|CLICKABLE|CODE|INTEGRATED WorkingInteractions / StubbedInteractions / DeadEnds DataSource: FICTIONAL|MASKED_AUTHORIZED|OTHER_REVIEWED DeviceViewport / Input / AssistiveTechSupport Backend / Network / Persistence / ErrorBehavior Security / Performance / Analytics / AccessibilityTree KnownMissing / KnownDivergence / ClaimLimits AccessControl / Expiry / Supersedes
مرحله سه: پنج Contribution متمایز تستر
عدد پنج در این مقاله دستهبندی عملی است، نه قانون جهانشمول. بسته به ریسک، بلوغ تیم و مهارتها ممکن است بعضی Contributionها را QA، Designer، Researcher، Developer، Accessibility specialist، Security یا Domain expert انجام دهد. نام نقش دلیل اعتبار نیست؛ Method، Evidence و Claim Limit اعتبار میسازد.
۱) تبدیل ادعا و فرض به Quality Question
تستر میتواند واژههای مبهمی مانند ساده، سریع، امن، شهودی، قابل اعتماد و همهکاره را به سؤال محدود تبدیل کند. سؤال خوب Subject، Population/Context، Scenario، Attribute، Evidence و Decision را روشن میکند. «آیا UX خوب است؟» سؤال تصمیمپذیر نیست؛ «آیا کاربران کمتجربه هدف میتوانند پس از timeout نتیجه عملیات را بدون retry ناخواسته پیدا کنند؟» قابل طراحیتر است.
QualityQuestionID / Version ClaimOrAssumption / Source / Confidence PopulationOrRole / Context / Scenario / Trigger ArtifactOrBuild / Locale / Platform QualityAttribute / HarmOrDecisionImpact Question / CompetingExplanations EvidenceMinimum / MethodCandidate / Owner / Due AnswerState: OPEN|PARTIAL|ANSWERED|INVALIDATED ClaimLimit / FollowUp
۲) مدلکردن State، Edge، Error و Recovery
ارزش فنی QA در طراحی اغلب از پرسیدن «قبل، هنگام و بعد از شکست چه میشود؟» میآید. Happy path را به state model تبدیل کنید: Initial، Editing، Submitted، Pending، Confirmed، Failed، Cancelled، Expired، Reconciled و Unknown. سپس قطع شبکه، back/refresh، duplicate tap، retry، session expiry، permission change، late event و concurrent device را بررسی کنید.
StateTransition: StateModelID / Version From / Event / Guard / To UserVisibleStatus / SystemState / SourceOfTruth AllowedAction / ProhibitedAction IdempotencyOrDuplicateRule / TimeoutRule ErrorMessage / Recovery / SupportRoute Persistence / Resume / Back / Refresh EvidenceNeeded / Unknown / Owner
این کار تصمیم Design را غنی میکند، اما QA بهتنهایی feasibility یا معماری را تعیین نمیکند. ادعای فنی را به Developer/Architect/Platform owner و در صورت نیاز Technical Spike ارجاع دهید. یک تصویر شبیه بانک نیز مجوز ادعای بانکی یا استفاده از داده واقعی نیست.
۳) ساخت Quality Attribute و Evidence Map
Design فقط ظاهر نیست، اما هر Attribute با دیدن Frame سنجیده نمیشود. برای Usability، Accessibility، Reliability، Security، Privacy، Performance، Compatibility، Localization، Observability و Supportability، سؤال و روش جدا بسازید. «پیام خطا وجود دارد» ممکن است Observation طراحی باشد؛ قابل فهمبودن آن برای کاربران، announce شدن توسط Screen Reader، ثبت امن error و رفتار تحت latency به شواهد متفاوت نیاز دارند.
| Attribute | Contribution طراحی QA | Evidence بعدی محتمل |
|---|---|---|
| Usability | Task/state/error hypothesis و rescue risk | مطالعه با کاربران هدف + تحلیل |
| Accessibility | Design check اولیه، focus/order/name/contrast question | WCAG evaluation + AT + کاربران دارای معلولیت |
| Reliability | failure/retry/recovery/idempotency state | contract/integration/fault test |
| Security/Privacy | misuse/data exposure/auth boundary question | threat/privacy review و تست مجاز |
| Performance | latency budget و loading/timeout UX | Build مشخص، workload و distribution |
| Localization | expansion/RTL/digit/money/time cases | منبع ترجمه، rendering و locale test |
۴) بازبینی Artifact و کمک به آزمایش طراحی
Expert Review میتواند mismatch، dead end، state مفقود، copy متناقض، affordance مبهم یا dependency پنهان را سریع آشکار کند. خروجی باید Observation و Hypothesis باشد، نه «کاربران واقعی این را دوست ندارند». برای مطالعه moderated، شرکتکننده، task و روش، از راهنمای تست کاربردپذیری استفاده کنید؛ اندازهگیری SUS و Task Success نیز به پروتکل و دامنه جدا نیاز دارد.
راهنمای GOV.UK برای یک دور پژوهش بر هدف روشن، فرض مورد بررسی، شرکتکننده مناسب، نیاز دسترسی، رضایت آگاهانه، Prototype آماده و Pilot تأکید دارد. این منبع برای خدمات دولتی بریتانیا نوشته شده؛ اصول برنامهریزی را اقتباس میکنیم، نه اینکه آن را استاندارد اجباری همه محصولات یا قانون ایران معرفی کنیم.
۵) ردیابی تصمیم تا Build و Outcome
Contribution وقتی با Merge یا کامنت resolved بسته شود، ممکن است تصمیم تحریف یا منقضی شود. Design decision را به Artifact version، Requirement/Acceptance example، Build/flag/config، Test Evidence و Outcome review وصل کنید. اگر Copy یا State model عوض شد، اثر بر Scenario، instrumentation، support content و پژوهش قبلی را بررسی و artifactهای متاثر را reissue کنید.
DecisionTrace: DecisionID / Version / Status / Supersedes ContributionIDs / EvidenceIDs / Dissent Options / TradeOffs / Chosen / Rationale Owner / Authority / DecidedAt / EffectiveFrom Conditions / Expiry / ReopenTrigger DesignArtifact / Requirement / AcceptanceExample Build / FeatureFlag / Config / TestEvidence Rollout / Guardrail / Stop / Rollback OutcomeMeasure / Countermeasure / Window ReviewResult / Correction / AffectedArtifacts
Observation را از Finding و Decision جدا کنید
| لایه | مثال | محدودیت |
|---|---|---|
| Observation | Frame ۱۷ دو control با label «ادامه» دارد | فقط Artifact و نسخه مشخص |
| Participant observation | P03 پیش از انتخاب ۱۲ ثانیه مکث کرد | نه نیت یا تعمیم به همه |
| Telemetry | event retry در ۸٪ exposureهای معتبر | وابسته به schema/کیفیت/جمعیت |
| Interpretation | labelها ممکن است مقصد را مبهم کنند | توضیح محتمل، نه واقعیت قطعی |
| Finding | الگوی چندمنبعی برای گروه/دامنه مطالعه | با support و counterexample |
| Recommendation | نام actionها outcome-specific شود | یک گزینه با trade-off |
| Decision | گزینه B در Prototype-R8 آزمایش شود | صاحب اختیار، شرط و بازبینی |
رنگ، hierarchy، consistency و copy را میتوان با expertise نقد کرد؛ اما «احساس کندی»، «اعتماد»، «رضایت» یا «خواستنیبودن» را از ترجیح یک تستر استخراج نکنید. یادداشت باید Fact، interpretation، alternative، Unknown و سطح اطمینان را نگه دارد. اسکرینشات نیز context، interaction و علت را بهتنهایی ثابت نمیکند.
Accessibility: شبیهسازی معلولیت شواهد کاربر نیست
تستر میتواند keyboard path، focus indication، name/role/value، contrast candidate، reflow و error association را در Design بررسی کند؛ اما بستن چشم، خاموشکردن ماوس یا استفاده کوتاه از Screen Reader نمایندگی تجربه زیسته نیست. راهنمای W3C WAI درباره مشارکت کاربران دارای معلولیت میگوید ارزیابی با کاربران مسائل مهمی مییابد، اما بهتنهایی انطباق دسترسپذیری را تعیین نمیکند و باید با ارزیابی استاندارد ترکیب شود.
- Design check، Expert accessibility review، Conformance evaluation و User evaluation را نامگذاری جدا کنید.
- شرکتکنندگان را متناسب با audience، فناوری کمکی و سطح تجربه جذب کنید؛ یک فرد نماینده همه نیست.
- نیاز دسترسی، همراه، مترجم، استراحت، کانال، زمان و جبران را در برنامه بگنجانید.
- مشکل ممکن است از content، code، browser، AT، آموزش یا ترکیب آنها باشد؛ علت را زود قطعی نکنید.
- برای دامنه فنی کامل از راهنمای تست دسترسپذیری WCAG ۲.۲ استفاده کنید.
پروتوتایپ فارسی و بازار ایران
یک Frame فارسی زیبا اثبات L10n نیست. Copy واقعی، فونت و fallback، طول رشته، RTL/LTR، ترتیب focus، Bidi در شناسه، ی/ی، ک/ک، نیمفاصله، رقم فارسی/عربی/لاتین، جداکننده، IRR/تومان، تقویم، UTC/Asia-Tehran، شماره تلفن، آدرس و ورودی فیزیکی/کیبورد را به قرارداد تبدیل کنید. قانون یا رفتار مالی جاری را از حافظه طراح یا تستر قطعی نکنید؛ Source و نقش واجد صلاحیت لازم است.
برای جزئیات فنی از چکلیست تست i18n و L10n فارسی/RTL استفاده کنید. در Prototype، مشخص کنید قیمت نمایشدادهشده IRR است یا تومانِ برچسبخورده؛ تبدیل پنهان، digit normalization پنهان و تاریخ جلالی بدون instant/zone میتواند طراحی را از ابتدا مبهم کند.
سناریوی ایرانی: نتیجه نامطمئن پرداخت
Prototype یک Checkout ساختگی پس از timeout دکمه «تلاش مجدد» نشان میدهد. تستر نباید بگوید «کاربر حتماً دوباره پرداخت میکند» یا «بانک این کار را میکند». Contribution معتبر میگوید Artifact وضعیت PaymentAttempt و Source of Truth را نمایش نمیدهد؛ callback ممکن است دیر یا تکراری برسد؛ retry میتواند Risk عملیات تکراری بسازد؛ و سه گزینه باید با Technical Spike و مطالعه task بررسی شوند.
- Option A: Retry فوری؛ سادهتر اما با Risk تکرار و ابهام.
- Option B: Status check؛ وابسته به endpoint و freshness.
- Option C: Pending + reconciliation + notification؛ ممکن است انتظار را طولانی کند.
- Harm floor: CTA نباید وضعیت قطعیِ تاییدنشده یا برداشت تکراری را القا کند.
- Evidence: state/contract spike، failure-injection روی Build، task study و telemetry معتبر پس از rollout.
- Decision: توسط Product/Risk/Engineering authority، نه رأی سلیقهای QA.
از User Story تا Example و Oracle
User Story فشرده، جای User Research یا specification کامل نیست. تستر میتواند Rule، Example، Question و edge را در Discovery آشکار کند، اما Acceptance Criteria را به فهرست همه Test Caseها تبدیل نکند. Example باید outcome observable و Source/Oracle داشته باشد؛ implementation detail مانند نام button یا table فقط وقتی وارد شود که واقعاً constraint است.
Rule: وضعیت عملیات نامطمئن نباید «ناموفق قطعی» نمایش داده شود Example: Given PaymentAttempt=ATT-SYN-7 و پاسخ client timeout شده And PSP Stub بعداً callback موفقِ تکراری میفرستد When کاربر صفحه نتیجه را باز یا refresh میکند Then UI حالت Pending را با Status source/freshness نشان میدهد And action تکراری تا Decision Rule مجاز نیست Questions: زمان انقضا؟ Source of Truth؟ حالت offline؟ wording پژوهششده؟ Oracle: versioned domain rule + contract response + ledger/reconciliation evidence
برای Formulation دقیق Rule/Example/Question و مرز Gherkin از راهنمای سناریونویسی Gherkin در BDD استفاده کنید. سناریوی خوانا هنوز صحت نیاز، کفایت نمونه یا رفتار واقعی کاربر را اثبات نمیکند.
جلسه Design Review را به Comment Storm تبدیل نکنید
Review پیش از جلسه به Purpose، Artifact version، scope، تصمیم لازم، نقشها، pre-read، زمان و شیوه ثبت نیاز دارد. در جلسه، اول طراح Context و سؤال را میگوید؛ سپس Contributionها بر اساس Risk/Question گروهبندی میشوند. دهها کامنت typo و سلیقه نباید یک state-loss یا harm جدی را دفن کند.
- کامنت را با نوع Question، Observation، Risk، Requirement trace، Suggestion یا Decision needed برچسب بزنید.
- یک issue را در یک thread نگه دارید و duplicateها را لینک کنید.
- Severity طراحی را با Priority تصمیم یکی نگیرید؛ روش/authority را ثبت کنید.
- نویسنده Design موظف به پذیرش همه suggestionها نیست؛ disposition و دلیل کافی است.
- Resolved یعنی پاسخ/تصمیم به Source of Record منتقل شده، نه صرفاً thread بسته است.
- افراد async، کمحرف، چندزبانه و دارای نیاز دسترسی باید مسیر برابر برای input داشته باشند.
DesignReviewSession: SessionID / Purpose / ArtifactVersion / DecisionNeed Roles: designer, QA, research, engineering, domain, authority PreRead / QuestionsDue / Channel / Accessibility Facilitation / Timebox / ConflictRoute ContributionIDs / DuplicateLinks / ParkingLot Dispositions: ACCEPT|TEST|SPIKE|DEFER|REJECT|UNKNOWN DecisionIDs / Actions / Owners / Due Dissent / Minutes / SourceOfRecord / FollowUp
Method را بر اساس Claim انتخاب کنید
| Claim/Question | روش نامزد | خطای رایج |
|---|---|---|
| state گمشده یا تناقض Rule | model review، example mapping، domain review | ارسال مستقیم به User Study |
| کاربر label را میفهمد | content test/usability task با گروه هدف | رأیگیری تیم |
| راهحل فنی شدنی است | technical spike/architecture review | نتیجه از clickable Prototype |
| Criterion دسترسپذیری برقرار است | conformance method روی artifact مناسب | یک participant یا scanner تنها |
| جریان در latency امن میماند | Build+network/fault test و UX state review | انیمیشن Prototype |
| تغییر Outcome را بهتر کرد | rollout/experiment/telemetry+qualitative evidence | تعداد comment یا bug |
Evidence Request را محدود و قابل تحویل کنید
EvidenceRequestID / QuestionID / DecisionID Claim / EvidenceMinimum / Method / Rationale PopulationOrSystem / SampleOrCases / InclusionExclusion ArtifactOrBuild / Environment / Data / Locale / Device TaskOrWorkload / StartEnd / Oracle / Instrumentation Owner / Capability / Due / Freshness / Budget PrivacyConsentSafety / Accessibility ResultVocabulary / AnalysisRule / ClaimLimit Delivery / Missing / Invalid / Rework / Expiry
«لطفاً تست کنید» درخواست Evidence نیست. Minimum باید پیش از دیدن نتیجه تعریف شود تا cherry-picking کمتر شود. برای Prototype ممکن است Evidence فقط مسیر و observation محدود باشد؛ برای تصمیم پرریسک ممکن است چند روش مستقل لازم باشد. همه سؤالها ارزش مطالعه بزرگ ندارند؛ Cost، harm، reversibility، uncertainty و deadline را در انتخاب روش بسنجید.
Privacy، Consent و Safety در پژوهش طراحی
QA ممکن است Observer یا Note-taker باشد، اما این نقش مجوز جمعآوری نامحدود نیست. Purpose، participant criteria، دعوت، رضایت ضبط/مشاهده، داده مورد استفاده، دسترسی، withdrawal، compensation، نگهداشت و incident route را پیش از session مشخص کنید. Prototype عمومینشده را نیز طوری محافظت کنید که با سرویس واقعی اشتباه نشود یا داده واقعی بیاجازه نگیرد.
- از حساب، پرداخت، شماره، پیام یا مدرک واقعی فقط با ضرورت و بررسی واجد صلاحیت استفاده کنید؛ داده ساختگی امنترِ پیشفرض است.
- Observerها معرفی شوند و شرکتکننده بداند چه کسانی میبینند یا میشنوند.
- Consent به حضور، Consent جداگانه به ضبط، نقلقول یا استفاده ثانویه نیست.
- Task نباید شرکتکننده را مجبور به افشای اطلاعات حساس یا انجام عملیات واقعی کند.
- یادداشتها Observation را از inference جدا و شناسه مستعار را از کلید هویت جدا نگه دارند.
- NDA یا هدیه نباید حق توقف، استراحت یا withdrawal را بیاثر کند.
Option و Trade-off بسازید، نه حکم طراحی
Contribution خوب فقط ایراد پیدا نمیکند. دستکم گزینه حفظ وضع، تغییر محدود، تغییر بنیادی، کسب Evidence بیشتر و no-action/rollback را در صورت معنیداربودن مقایسه کنید. هر گزینه اثر محتمل بر Outcome، Risk/Harm، accessibility، complexity، delivery، support، observability، reversibility و Unknown دارد.
OptionRecord: OptionID / Description / Assumptions UserOutcomeHypothesis / QualityEffects Risks / HarmFloor / Accessibility / Privacy TechnicalDependency / DeliveryCostRange / SupportCost EvidenceFor / EvidenceAgainst / Unknowns Reversibility / Rollback / LearningValue RecommendationBy / Rationale / ConflictOfInterest DecisionOwner / Disposition / Conditions
Decision authority را از تخصص جدا کنید
QA میتواند سؤال و Evidence مهمی عرضه کند، اما عنوان «شریک استراتژیک» حق وتوی همه Designها نمیدهد. Designer مالک لزوماً Risk نیست؛ Product Owner در Scrum نیز خودکار مالک امنیت، حقوق، Accessibility conformance، عملیات یا پذیرش همه کاربران نیست. Authority را بر اساس نوع تصمیم و ساختار واقعی تعیین کنید و Dissent را نگه دارید.
| Capability | Input نمونه | Authority احتمالی، وابسته به سازمان |
|---|---|---|
| Product | Outcome، priority، bet، scope | Product decision owner |
| Design/Content | interaction، information، copy، prototype | Design system/feature owner |
| User Research | method، recruitment، session، analysis | Research owner/ethics route |
| QA/Test | risk، state، oracle، evidence design | Test capability owner؛ نه universal gate |
| Engineering/Architecture | feasibility، contract، failure، cost | Technical authority |
| Specialist/Qualified | accessibility/security/privacy/legal/domain | تعریفشده در governance جاری |
از Shift-left افسانه نسازید
یادگیری زودتر میتواند گزینههای بیشتری باز نگه دارد، اما «هرچه زودتر همیشه ارزانتر و بهتر» قانون نیست. فرض هنوز ناپایدار، Prototype کموفاداری، هزینه Opportunity، تغییر بازار، نیاز به داده واقعی یا معماری ناشناخته ممکن است Evidence را منقضی کند. هدف انتقال همه تستها به چپ نیست؛ انتخاب زمان و روش مناسب برای سؤال و Risk است.
- Shift-left مناسب: Rule ambiguity، state omission، accessibility-by-design، observability need، testability.
- نیازمند Build: performance distribution، integration behavior، browser/AT tree، failure injection.
- نیازمند کاربر: comprehension، task behavior، lived accessibility، trust perception.
- نیازمند Production/rollout: Outcome، adoption، support load، long-term behavior—با guardrail و privacy.
- نیازمند نقش واجد صلاحیت: legal/regulatory/clinical/security acceptance.
Metric مشارکت طراحی را ضدبازی طراحی کنید
تعداد کامنت، باگ پیش از کدنویسی، جلسه، rejected design یا «هزینه ذخیرهشده» معیار ارزش فرد نیست. معیار فرایندی محدود میتواند زمان پاسخ به Question، درصد Contribution دارای Source/Claim limit، پوشش stateهای پرریسک، Evidence request تحویلشده، Decision trace کامل، stale decision، reopen و correction باشد؛ همه با تعریف، پنجره، مخرج و countermeasure.
| Measure | تعریف | Guardrail |
|---|---|---|
| Question-to-decision latency | از OPEN تا تصمیم معتبر در window | سرعت نباید Evidence minimum را حذف کند |
| Trace completeness | رکوردهای دارای Artifact/Evidence/Decision/Build ÷ واجد بررسی | presence صحت را ثابت نمیکند |
| Stale contribution rate | Contributionهای منقضی/نسخهناهمسان ÷ بازشده | تغییر زیاد الزاماً بد نیست |
| Reopen reason | گروه علت بازشدن با denominator | برای رتبهبندی فرد استفاده نشود |
| Outcome review coverage | تصمیمهای واجد rollout با review ÷ واجد rollout | Outcome علیت را به Contribution اثبات نمیکند |
آزمایشگاه آفلاین فارسی: پنج کامنت برابر Design Success نیست
این آزمایشگاه کاملاً ساختگی، بدون شبکه و بدون Product، سازمان، کاربر، Participant، پژوهش، پرداخت یا پول واقعی است. Checkout/PSP Stub/Ledger فقط نام مدل محلیاند. IRR خیالی و تومان صرفاً نمایشی است؛ ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، نیمفاصله، RTL/LTR/Bidi، UTC، Asia/Tehran و جلالی نمایشی برای fixture حضور دارند.
// Node.js 24+ — no network, package, real product/user/research/payment
const fixture = {
id: "SYN-PRODUCT-DESIGN-CONTRIBUTION-01",
artifact: "FAKE-CHECKOUT-PROTO-R7",
system: "Order/PaymentAttempt/PSP Stub/Callback/Ledger/Reconciliation",
events: ["timeout-before-fake-commit", "timeout-after-fake-commit",
"retry", "duplicate", "late", "reordered"],
superficial: ["UX feedback", "edge cases", "accessibility comment",
"acceptance criteria", "exploratory prototype"],
money: {canonical: "IRR-FAKE", view: "تومانِ صرفاً نمایشی"},
glyphs: ["۱۲۳", "١٢٣", "123", "کیفیت", "كيفيت", "نیمفاصله"],
time: {instant: "2026-08-13T09:00:00Z", zone: "Asia/Tehran",
jalali: "نمایشی/غیرمحاسباتی"},
realProductOrgUserParticipantResearchPaymentOutcome: false
};
const groups = {
identity: ["contributionId","version","status","createdAt","zone","asOf","owner","reviewAt","expiry","supersedes","sourceOfRecord","correctionRoute"],
context: ["product","productGoal","desiredOutcome","beneficiary","flow","scenario","platform","locale","riskClass","phase","inScope","outOfScope","unknowns"],
decision: ["decisionId","decisionNeed","decisionType","deadline","deadlineSource","decisionOwner","authority","evidenceMinimum","harmFloor","optionsNeeded","dissentRoute","conflictOfInterest"],
artifact: ["artifactId","artifactVersion","digest","tool","artifactOwner","frames","copyVersion","fidelity","workingInteractions","stubbedInteractions","deadEnds","dataSource","deviceViewport","input","backend","network","persistence","errorBehavior","securityLimit","performanceLimit","accessibilityTreeLimit","knownMissing","knownDivergence","accessControl","artifactExpiry"],
claim: ["claimId","claimText","claimType","source","sourceVersion","assumption","requirement","constraint","designChoice","preference","confidence","applicability","competingExplanation","claimLimit"],
question: ["questionId","claimRef","populationOrRole","context","trigger","qualityAttribute","harm","question","answerNeededFor","methodCandidate","questionOwner","due","answerState","followUp"],
state: ["stateModelId","from","event","guard","to","userVisibleStatus","systemState","sourceOfTruth","allowedAction","prohibitedAction","duplicateRule","timeoutRule","errorMessage","recovery","supportRoute","persistence","resume","back","refresh","stateEvidence","stateUnknown","stateOwner"],
attribute: ["usability","accessibility","reliability","security","privacy","performance","compatibility","localization","observability","supportability","safety","attributePriority","attributeEvidence","attributeOwner"],
method: ["methodId","methodType","claimFit","rationale","expertReview","userResearch","conformanceCheck","technicalSpike","buildTest","telemetry","mixedMethod","methodOwner","capability","methodLimit"],
research: ["researchQuestion","participantCriteria","inclusion","exclusion","sampleRationale","recruitment","accessNeeds","consent","recordingConsent","observerNotice","withdrawal","compensation","task","taskStart","taskEnd","moderator","rescueRule","pilot","sessionSafety","dataMinimization","retention"],
observation: ["observationId","observer","timestamp","subject","fact","participantObservation","telemetryObservation","internalState","interpretation","alternative","unknown","support","counterexample","uncertainty","noIntentInference","noUserVoiceClaim"],
finding: ["findingId","observationRefs","pattern","scope","populationLimit","artifactLimit","severityMethod","impact","confidence","recommendation","recommendationLimit","openQuestion","needsMoreEvidence","findingOwner"],
accessibility: ["designCheck","expertReviewA11y","wcagEvaluation","assistiveTechnology","disabledUserInvolvement","notSimulation","userRange","oneUserNotAll","conformanceNotUserOnly","contentCodeBrowserAtContext","accommodation","accessibleVenue","a11yClaimLimit"],
locale: ["utf8","rtl","ltr","bidi","zwnj","persianYeh","arabicYeh","persianKaf","arabicKaf","persianDigits","arabicDigits","latinDigits","irrCanonical","tomanLabel","instant","ianaZone","jalaliPresentationOnly","fontFallback","stringExpansion","focusOrder"],
review: ["sessionId","purpose","artifactPinned","roles","preRead","questionsDue","channel","asyncPath","accessibility","facilitator","timebox","conflictRoute","commentType","duplicateLink","parkingLot","disposition","actionOwner","actionDue","minutes","followUp"],
evidence: ["evidenceRequestId","decisionRef","evidenceMinimumDefinedBefore","populationOrSystem","sampleOrCases","artifactOrBuild","environment","data","device","locale","workloadOrTask","startEnd","oracle","instrumentation","evidenceOwner","due","freshness","budget","privacy","safety","resultVocabulary","analysisRule","delivery","missing","invalid","rework","evidenceExpiry"],
option: ["optionId","description","optionAssumptions","outcomeHypothesis","qualityEffects","risks","optionHarmFloor","optionAccessibility","optionPrivacy","technicalDependency","deliveryCostRange","supportCost","evidenceFor","evidenceAgainst","optionUnknown","reversibility","rollback","learningValue","recommendedBy","recommendationRationale","optionConflict","optionDisposition"],
trace: ["traceDecisionId","traceVersion","traceStatus","contributionRefs","evidenceRefs","traceDissent","chosenOption","decisionRationale","decidedAt","effectiveFrom","conditions","traceExpiry","reopenTrigger","requirementRef","acceptanceExample","build","featureFlag","config","testEvidence","rollout","guardrail","stop","traceRollback","outcomeMeasure","countermeasure","outcomeWindow","reviewResult"],
lifecycle: ["deliveryConfirmed","artifactChanged","impactAnalysis","staleDetected","revalidate","reopen","correction","reissue","affectedArtifacts","closureReason","archive","delete","auditTrail","nextReview"],
metrics: ["measureId","definition","window","denominator","source","owner","limitation","countermeasureMetric","questionLatency","traceCompleteness","staleRate","reopenReason","outcomeReviewCoverage","noCommentCountScore","noBugCountScore","noIndividualRanking","noSavingsFabrication"],
governance: ["productCapability","designCapability","researchCapability","testCapability","engineeringCapability","domainCapability","securityCapability","privacyCapability","accessibilityCapability","legalCapability","authoritySeparateFromExpertise","noUniversalQaGate","noUniversalPoAuthority"],
limits: ["testerNotUserProxy","notUserVoice","notResearchProof","notUsabilityProof","notAccessibilityConformance","notTechnicalFeasibilityProof","notSecurityProof","notPerformanceProof","notProductQualityProof","notSuccessProof","notCostSavingProof","notCausalityProof","notLegalAdvice","notIranCompliance","notUniversalProcess","noRealTarget"]
};
const required = Object.entries(groups).flatMap(([g, xs]) => xs.map(x => `${g}.${x}`));
const supplied = new Set(fixture.controls || []);
const missing = required.filter(x => !supplied.has(x));
const superficial = fixture.superficial.length === 5
? "TESTER_DESIGN_PARTNER_PRODUCT_SUCCESS_READY" : "INCOMPLETE";
console.log(superficial); // ادعای غلط checker سطحی
console.log(`HOLD-${missing.length}`); // ممیزی ساختاری باید HOLD دهد
console.log(new Set(required).size === required.length ? "UNIQUE" : "DUPLICATE");
console.log(fixture.realProductOrgUserParticipantResearchPaymentOutcome === false
? "NO_REAL_TARGET_PASS" : "STOP_REAL_TARGET");
fixture.controls = [...required];
const remaining = required.filter(x => !new Set(fixture.controls).has(x));
console.log(remaining.length === 0
? "READY_FOR_PRODUCT_DESIGN_CONTRIBUTION_REVIEW-0"
: `HOLD-${remaining.length}`);
Checker سطحی پنج فعالیت رایج را میبیند و بهاشتباه TESTER_DESIGN_PARTNER_PRODUCT_SUCCESS_READY میسازد. ممیزی مستقل باید کنترلهای گروهبندیشده غایب را بشمارد و HOLD بدهد؛ قانون جداگانه نیز نبود Product، سازمان، کاربر، Participant، پژوهش، پرداخت یا Outcome واقعی را تأیید میکند. حتی خروجی READY_FOR_PRODUCT_DESIGN_CONTRIBUTION_REVIEW-0 فقط آمادگی fixture برای Review است.
ضدالگوهای مشارکت تستر در طراحی
- تستر به عنوان اولین/واقعیترین کاربر یا وکیل همه کاربران؛
- همدلی، intuition یا ذهنیت نقادانه به عنوان Evidence کاربر؛
- Role-play معلولیت، مبتدی، سالمند یا فرهنگ دیگر به جای مشارکت واقعی؛
- نظر QA مساوی Usability Finding یا Product Insight؛
- Wireframe مساوی behavior و code Prototype مساوی Production؛
- زیبایی Prototype مساوی feasibility، performance یا security؛
- هرچه زودتر همیشه ارزانتر/بهتر؛
- هزاران برابر صرفهجویی بدون baseline و counterfactual؛
- Design Review بدون Artifact version یا Decision need؛
- کامنت «این بد است» بدون Observation/Question/Impact؛
- رأیگیری تیم به جای User Research؛
- یک Participant مساوی همه کاربران؛
- Scanner یا User Study تنها مساوی Accessibility conformance؛
- تستر دارای معلولیت مساوی نماینده تمام تجربهها؛
- User Story مساوی User Need اثباتشده؛
- Acceptance Criteria مساوی همه Testها/DoD/Outcome؛
- Mock بانکی با داده یا رفتار واقعی و ادعای مالی؛
- اسکرینشات مساوی علت، نیت یا تجربه؛
- Severity طراحی مساوی Priority تصمیم؛
- Resolved comment مساوی تصمیم اجراشده؛
- Product Owner یا QA به عنوان authority جهانی؛
- تعداد comment/bug/meeting به عنوان ارزش فرد؛
- Instrumentation بدون schema/privacy/quality؛
- AI persona، sentiment یا synthetic user به جای انسان هدف؛
- Outcome بهتر مساوی اثبات اثر QA؛
- ادعای تضمین کیفیت، کاربرپسندی، ROI یا موفقیت محصول.
چکلیست مالک Design Contribution
- ContributionID، نسخه، وضعیت، Source of Record و Correction route ثبت شده است.
- Product/Outcome/Flow/Scenario/Platform/Locale و Risk class روشناند.
- Artifact/version/digest و Fidelity/Missing/Claim limit پین شدهاند.
- Decision need، owner، authority، deadline source و Evidence minimum مشخصاند.
- Need، Assumption، Requirement، Constraint، Choice و Preference جدا هستند.
- QA خود را user proxy یا universal advocate معرفی نکرده است.
- Quality Question محدود، تصمیمپذیر و دارای Population/Context است.
- State، error، interruption، duplicate، timeout و recovery مدل شدهاند.
- Attributeها روش Evidence متناسب دارند.
- Expert opinion با User research و Conformance claim یکی نشده است.
- Accessibility lived experience شبیهسازی نشده و یک نفر به همه تعمیم نیافته است.
- Prototype داده ساختگی/مجاز، access control و expiry دارد.
- Research هدف، شرکتکننده، access need، consent، task، pilot و safety دارد.
- Observation، Interpretation، Finding، Recommendation و Decision جدا هستند.
- Alternative، Counterexample، Unknown و uncertainty محفوظاند.
- Design Review purpose/role/async/accessibility/disposition دارد.
- کامنتها type، duplicate link، owner و due دارند.
- Evidence Request پیش از نتیجه، method/subject/oracle/freshness/limit دارد.
- حداقل دو Option یا دلیل معتبر برای نبود گزینه ثبت شده است.
- هر Option اثر، Risk، cost range، Unknown و reversibility دارد.
- Authority از expertise و title جدا شده و Dissent حفظ شده است.
- Decision شرط، expiry، reopen، rollout، guardrail، stop و rollback دارد.
- Design به Requirement/Example/Build/Flag/Config/Test Evidence ردیابی شده است.
- Persian/RTL/digit/money/time assumptions صریحاند.
- Metricها تعریف/پنجره/مخرج/guardrail دارند و افراد را رتبهبندی نمیکنند.
- Outcome review علیت، کیفیت یا موفقیت را بیشادعا نمیکند.
- تغییر Artifact باعث impact analysis، stale detection و reissue میشود.
- Closure دلیل، correction، affected artifacts، archive/delete و next review دارد.
Pilot سیروزه بدون Product یا کاربر واقعی
هفته اول با Flow و Prototype کاملاً ساختگی، vocabulary و Recordها را تمرین کنید. هفته دوم State/Quality Question/Evidence Map را بسازید. هفته سوم Design Review، Technical Spike خیالی و User Study tabletop بدون Participant را اجرا کنید. هفته چهارم Decision Trace، تغییر نسخه، stale finding، rollout/guardrail و Correction را ممیزی کنید.
- روز ۱–۵: role/authority، claim taxonomy، fidelity و not-proof را توافق کنید.
- روز ۶–۱۰: timeout/duplicate/late/reordered و Persian/RTL را در State model وارد کنید.
- روز ۱۱–۱۵: هر comment را به Question/Observation/Risk/Decision-needed تبدیل کنید.
- روز ۱۶–۲۰: Evidence Method و Request را بدون داده یا انسان واقعی طراحی کنید.
- روز ۲۱–۲۵: سه Option، trade-off، Dissent و Decision مشروط بسازید.
- روز ۲۶–۳۰: Artifact را تغییر دهید و impact/reopen/correction/validator را اجرا کنید.
جمعبندی
تحول نقش تستر در طراحی محصول با تغییر لقب از «دروازهبان» به «شریک استراتژیک» کامل نمیشود. ارزش واقعی در ساخت یک رابط شفاف میان Assumption، Risk، Design Artifact، Quality Question، Evidence و Decision است. تستر نه جای کاربر مینشیند، نه جای طراح یا پژوهشگر؛ توان خود در state، failure، oracle و evidence را به تصمیم تیم اضافه میکند.
نتیجه حرفهای یک Design Review تعداد بیشتر کامنت نیست. تصمیمی است که Subject و نسخهاش معلوم، Evidence و Unknown آن قابل دیدن، Option و authority آن روشن، و اثرش در Build و Outcome قابل بازبینی باشد. این چرخه میتواند ریسک تصمیم را کاهش دهد؛ موفقیت، کیفیت یا رضایت را تضمین نمیکند.
سؤالات متداول درباره نقش تستر در طراحی محصول
آیا تستر باید در همه جلسههای طراحی حضور داشته باشد؟
خیر. حضور باید به Decision need، Risk، capability و هزینه هماهنگی وابسته باشد. بسیاری از inputها با pre-read و async review بهتر ارائه میشوند. برای state، error، evidence یا testability پرریسک حضور QA ارزشمند است؛ جلسه بدون موضوع و اختیار روشن فقط بار ارتباطی میسازد.
آیا نظر تستر میتواند جای تست با کاربران را بگیرد؟
نه. Expert Review میتواند مسئله و فرضیه مهمی را سریع پیدا کند، اما رفتار، درک یا نیاز گروه هدف را نمایندگی نمیکند. سؤال کاربرمحور را با روش پژوهش مناسب و شرکتکنندگان مرتبط بررسی کنید و دامنه/نمونه/محدودیت را در گزارش نگه دارید.
روی Wireframe دقیقاً چه چیزی را میتوان تست کرد؟
ساختار اطلاعات، ترتیب مفهومی، stateهای جاافتاده، label candidate، navigation و سؤالهای Rule را میتوان بررسی کرد. رفتار backend، race، persistence، performance، security، accessibility tree و تجربه واقعی تعامل معمولاً خارج از توان Wireframe است و به Artifact/Method دیگری نیاز دارد.
تستر چگونه بدون دخالت در کار طراح بازخورد بدهد؟
Artifact و نسخه را نام ببرد، Observation را از interpretation جدا کند، Impact/Risk و Unknown را توضیح دهد، سؤال یا Evidence موردنیاز را پیشنهاد کند و در صورت امکان Option بسازد. صاحب Design مجبور به پذیرش پیشنهاد نیست؛ disposition و تصمیم باید توسط authority مناسب ثبت شود.
آیا مشارکت زودهنگام QA هزینه بازکاری را حتماً کاهش میدهد؟
خیر، تضمین یا ضریب جهانی وجود ندارد. کشف بعضی ابهامها پیش از Build میتواند تغییر را آسانتر کند، اما Review اضافی نیز هزینه دارد و Evidence زودهنگام ممکن است با تغییر فرض یا Artifact منقضی شود. baseline، نوع مسئله، هزینه کشف/اصلاح، زمان و counterfactual لازم است؛ نتیجه را به فرد نسبت ندهید.
