نمونه‌سازی سریع وب با سایت‌ساز؛ راهنمای تست

یک تیم در دو روز Landing page زیبایی می‌سازد، ۵۰۰ نفر وارد آن می‌شوند و ۴۰ نفر فرم «علاقه‌مندم» را پر می‌کنند. تیم نتیجه می‌گیرد بازار تأیید شده است؛ سه ماه بعد می‌فهمد هیچ‌کس حاضر نیست قیمت واقعی را بپردازد و خدمتی که وعده داده شده از نظر عملیاتی هم شدنی نیست. سرعت ساخت بالا بوده، اما فرضیه اشتباه با شاهد ضعیف سنجیده شده است.

سایت‌ساز می‌تواند فاصله ایده تا یک URL قابل‌تست را کوتاه کند، اما Prototype خوب را ابزار تعیین نمی‌کند. سؤال پژوهش، فرضیه پرریسک، Fidelity، شرکت‌کننده مناسب، Task غیرهدایت‌گر، Event قابل‌اعتماد و قانون تصمیم تعیین می‌کنند آیا چیزی یاد گرفته‌اید یا فقط صفحه‌ای ساخته‌اید.

نمونه‌سازی سریع وب چیست؟

نمونه‌سازی سریع فرایند ساخت نمایش موقت و هدفمند از یک ایده، آزمودن آن با افراد یا شرایط مناسب و تغییر/حذف آن براساس یادگیری است. Prototype می‌تواند طرح کاغذی، Wireframe، کلیک‌پذیر، سایت‌ساز تعاملی، Wizard of Oz یا Thin slice کدنویسی‌شده باشد. «سریع» یعنی زمان رسیدن به یادگیری معتبر کوتاه شود، نه اینکه مرحله فهم مسئله حذف شود.

چارچوب Double Diamond شورای طراحی بریتانیا مسیر را به Discover، Define، Develop و Deliver تقسیم می‌کند. Diverge/Converge یادآوری می‌کند قبل از دل‌بستن به یک راه‌حل، مسئله را کشف و تعریف کنید و سپس چند پاسخ را بسازید و بیازمایید.

Prototype، PoC، Landing test، Pilot و MVP یکی نیستند

خروجی	پرسش اصلی	کاربر/داده واقعی	قابل فروش/اتکا؟
Sketch/Wireframe	ساختار و مسیر قابل فهم است؟	ممکن است در تست	خیر
Prototype	راه‌حل فرضی فهمیدنی/کاربردپذیر است؟	معمولاً شبیه‌سازی‌شده	نه لزوماً
Proof of Concept	ریسک فنی خاص شدنی است؟	اغلب داده آزمایشی	خیر
Landing/Smoke test	پیام/پیشنهاد رفتار اولیه می‌سازد؟	Traffic واقعی، خدمت ممکن است آماده نباشد	فقط با شفافیت؛ شاهد خرید نیست
Concierge/Wizard of Oz	ارزش End-to-end با عملیات دستی هست؟	کاربر واقعی، Backend دستی/شبیه‌سازی	محدود و شفاف
Pilot	سرویس واقعی در Scope کنترل‌شده کار می‌کند؟	بله	برای گروه محدود
MVP	کمینه محصول واقعی، مسئله را پایدار حل می‌کند؟	بله	بله؛ نیازمند کیفیت Production متناسب

Prototype کد دورریختنی می‌تواند موفق باشد اگر یادگیری بسازد. MVP «Prototype کمی تمیزتر» نیست؛ محصول واقعی با امنیت، دسترس‌پذیری، داده، پشتیبانی، پرداخت، عملیات و مسئولیت است.

نقش واقعی سایت‌ساز در نمونه‌سازی

سایت‌ساز برای انتشار سریع صفحه، جریان چندمرحله‌ای، فرم، Content، Catalog یا Integration آماده مفید است. مزیتش کاهش Lead time ساخت و امکان اصلاح مستقیم توسط تیم محصول/محتواست. اما این محدودیت‌ها را هم دارد:

Template ممکن است پاسخ طراحی را پیشاپیش تحمیل کند.
تعامل، State، API یا Data model پیچیده شاید به Hack بدل شود.
Analytics، Export، SEO، Accessibility یا Performance ممکن است محدود باشد.
ظاهر Production می‌تواند شرکت‌کننده را درباره واقعی‌بودن خدمت گمراه کند.
ساخت آسان، سؤال پژوهش یا Recruitment درست تولید نمی‌کند.

بنابراین سایت‌ساز یک Prototype medium است. برای کشف مسئله شاید مصاحبه/مشاهده بهتر باشد؛ برای تست معماری، Technical spike؛ و برای سنجش قیمت، رفتار پرهزینه‌تری از کلیک «علاقه‌مندم» لازم است.

از راه‌حل شروع نکنید؛ ریسک را پیدا کنید

نوع ریسک	پرسش	روش مناسب‌تر	شاهد ضعیف
Desirability	این مسئله مهم و فوری است؟	Contextual interview، diary، demand test	«ایده جالبی است»
Usability	کاربر می‌تواند Task را کامل کند؟	Prototype + usability test	نظر درباره زیبایی
Feasibility	فناوری/عملیات با Constraint واقعی شدنی است؟	PoC، data/API/ops spike	Demo با داده Hard-coded
Viability	اقتصاد، قیمت و کانال پایدارند؟	Pricing test، concierge، unit model	Lead بدون قیمت
Integrity	امنیت، اخلاق، قانون و دسترس‌پذیری پذیرفتنی است؟	Threat/ethics/accessibility review	«فعلاً فقط تست است»

Assumption mapping را با «اهمیت × عدم‌اطمینان» انجام دهید. پرریسک‌ترین فرض باید اول آزموده شود، حتی اگر ساختن Hero section جذاب‌تر باشد.

قرارداد فرضیه قبل از Build

فیلد	نمونه برای رزرو آنلاین خدمات
Segment/Context	صاحب کسب‌وکار خدماتی تهران که وقت‌ها را تلفنی هماهنگ می‌کند
Problem/Job	کاهش رفت‌وبرگشت تماس و نوبت ازدست‌رفته
Riskiest assumption	مشتری حاضر است بدون تماس، بازه آزاد را انتخاب و بیعانه بدهد
Prototype	Landing + سه گام رزرو + Sandbox پرداخت؛ Backend دستی
Primary evidence	تکمیل رزرو واجد شرایط از افراد Segment
Guardrail	خطای زمان، انصراف، شکایت، حریم خصوصی و هزینه عملیات
Threshold/period	آستانه از اقتصاد/تصمیم تیم، با دوره و Denominator از پیش ثبت‌شده
Decision	Persevere، Pivot، تحقیق بیشتر یا Stop

آستانه را از ارزش و هزینه خطا بگیرید، نه عدد مشهور اینترنتی. «ده نفر دیدند و خوششان آمد» برای تصمیم سرمایه‌گذاری تعریف کافی نیست.

قدرت شاهد را با ادعا متناسب کنید

شاهد	چه چیزی می‌گوید؟	چه چیزی نمی‌گوید؟
نظر مثبت	برداشت/ادب/کنجکاوی	رفتار آینده
کلیک CTA	پیام یا کنجکاوی اولیه	خرید و Retention
فرم Lead	تحمل اصطکاک و علاقه بیشتر	کیفیت/پرداخت
رزرو/Deposit شفاف	تعهد رفتاری قوی‌تر	استفاده مکرر
استفاده Concierge	ارزش واقعی برای Scope کوچک	مقیاس و Automation
تکرار/پرداخت/Retention	ارزش پایدارتر در Cohort	اقتصاد در Scale دیگر

شاهد را بیش از ظرفیتش تفسیر نکنید. Page view اندازه بازار نیست، Hotjar علت قطعی رفتار نیست و ثبت ایمیل تضمین willingness to pay نیست.

Fidelity را براساس سؤال انتخاب کنید

Fidelity	زمان تقریبی نسبی	مناسب برای	خطر
Paper/Sketch	دقیقه تا ساعت	ایده، IA و مسیر	تعامل واقعی کم
Low-fi click	ساعت	Flow و Label	Content/State کم‌واقعی
Mid-fi	ساعت تا روز	Task usability و alternative	ظاهر می‌تواند نظر را منحرف کند
High-fi visual	روز	اعتماد، Content و تعامل دقیق	Sunk cost و اشتباه با محصول
Website builder	روز	URL، فرم، Content، Instrumentation و Traffic	Constraint/Lock-in و داده واقعی
Code spike	روز تا هفته	Performance/API/feasibility	ساخت قبل از desirability

راهنمای رسمی GOV.UK برای ساخت Prototype از Sketch تا Prototype کدنویسی‌شده را تفکیک می‌کند و هشدار می‌دهد کد Prototype لزوماً استاندارد امنیت/کارایی Production را ندارد و نباید مستقیم به سرویس زنده کپی شود.

چه زمانی سایت‌ساز بهترین Medium است؟

سؤال به پیام، Information architecture، Landing، Content یا فرم مربوط است.
URL واقعی، Mobile browser، Share و Traffic source بخشی از تست‌اند.
منطق را با فرم، Automation یا عملیات دستی محدود می‌توان شبیه‌سازی کرد.
تیم می‌تواند Analytics و Consent را درست Instrument کند.
Prototype قرار نیست حساسیت/مقیاس Production را وانمود کند.

برای Gesture پیچیده، Collaboration لحظه‌ای، الگوریتم، Offline، Hardware، Data-heavy state یا Integration بحرانی، Figma-like prototype، Code spike یا Sandbox تخصصی ممکن است معتبرتر باشد.

نوع Prototype را به سؤال وصل کنید

سؤال	Prototype پیشنهادی	Primary signal	Guardrail
آیا مسئله واقعی است؟	مصاحبه/مشاهده + Artifact کم	رفتار/راه‌حل فعلی و شدت درد	Bias پرسش
آیا پیام فهمیده می‌شود؟	Landing variants	Comprehension + qualified action	Misleading claim
آیا Flow قابل استفاده است؟	Clickable یا builder flow	Task completion/error	Moderator help
آیا قیمت پذیرفتنی است؟	شفاف‌سازی قیمت + اقدام پرهزینه	Qualified commitment	Refund/trust
آیا عملیات شدنی است؟	Concierge/Wizard of Oz	Cycle time/quality/cost	Manual scalability
آیا فناوری شدنی است؟	Thin technical spike	Latency/accuracy/integration	Demo data bias

تست کاربر را Taskمحور طراحی کنید

راهنمای تست کاربردپذیری مدیریت‌شده GOV.UK توصیه می‌کند Research question، نوع کاربر و بخش مورد تمرکز پیش از Session مشخص شوند. Task خوب هدفی باورپذیر دارد، پاسخ را لو نمی‌دهد و به شرکت‌کننده نمی‌گوید کدام دکمه را بزند.

نمونه Task بد و بهتر

بد	بهتر	دلیل
روی «رزرو سریع» بزنید و نوبت بگیرید	فرض کنید برای سه‌شنبه عصر نوبت می‌خواهید؛ نشان دهید چه می‌کنید	Label و مسیر را لو نمی‌دهد
آیا این صفحه را دوست دارید؟	این خدمت چه کاری برای شما انجام می‌دهد؟	فهم را به‌جای سلیقه می‌سنجد
این فرایند آسان بود؟	کجا انتظار دیگری داشتید؟	پرسش هدایت‌گر نیست
آیا حاضر بودید بخرید؟	آخرین بار چگونه حل کردید و چه هزینه‌ای دادید؟	رفتار گذشته از نیت فرضی قوی‌تر است

در Session فکرکردن با صدای بلند، مشاهده، زمان/خطا و پرسش پس از Task را ترکیب کنید. Moderator نباید UI را آموزش دهد. برنامه کامل Recruitment، Script، Severity و Synthesis در راهنمای تست کاربردپذیری آمده است.

شرکت‌کننده واقعی مهم‌تر از تعداد مشهور است

همکار تیم یا دوستی که Context مسئله را ندارد، جای Target user را نمی‌گیرد. معیار Recruitment باید تجربه، رفتار، محدودیت، دستگاه، دسترس‌پذیری و زمینه تصمیم را پوشش دهد. راهنمای GOV.UK برای یافتن شرکت‌کننده عدد معمول ۴ تا ۸ نفر را برای یک دور Interview/Usability ذکر می‌کند، اما خود Method سؤال و تعداد را تعیین می‌کند؛ Survey، A/B و برآورد نرخ به نمونه بسیار بزرگ‌تر نیاز دارند.

به‌جای یک Round بزرگ، Round کوچک و متنوع اجرا کنید، مسئله‌ها را اصلاح و دوباره آزمایش کنید. افراد دارای معلولیت، سواد دیجیتال پایین، شبکه ضعیف یا دستگاه قدیمی را وقتی در Population هستند عمداً Recruit کنید.

Event contract قبل از اتصال Analytics

فیلد	نمونه
Event	`booking_completed`
Trigger	ثبت موفق رزرو در Truth source، نه کلیک دکمه
Eligible denominator	کاربران Segment که صفحه زمان را دیدند و slot موجود بود
Properties	prototype_version، source، device، city_group؛ بدون داده حساس غیرضروری
Deduplication	booking_id هش/غیرقابل‌شناسایی مستقیم
QA	Happy/error/back/reload/adblock و Reconciliation
Owner/retention	مالک داده، هدف و زمان حذف

Analytics می‌گوید کجا افت رخ داد؛ مشاهده و گفت‌وگو کمک می‌کند چرا را بفهمید. چارچوب اتصال Signal کمی/کیفی به تصمیم در راهنمای UX داده‌آگاه تشریح شده است.

Landing page آزمون بازار است، نه خود بازار

Landing می‌تواند Message، Channel و اقدام اولیه را بسنجد. Source→Promise→Evidence→Action باید هم‌خوان باشد. Traffic بی‌ربط Conversion را مخدوش می‌کند و CTA مبهم شاهد ضعیف می‌سازد. Landing خوب، Problem/Outcome/Constraint/Price یا بازه آن، شاهد و اقدام روشن دارد.

برای طراحی فرم، Qualified conversion، A/B و Profit به راهنمای Landing page رجوع کنید. کلیک روی «خرید» بدون امکان/قصد ارائه، باید از ابتدا به‌شکل آزمون شفاف طراحی شود، نه تله.

Fake door، پیش‌فروش و Deposit را اخلاقی اجرا کنید

Fake door می‌تواند علاقه به Feature را بسنجد، اما نباید کاربر را تا ورود داده حساس یا پرداختی ببرد که انتظار خدمت واقعی دارد و تازه بعداً اعتراف کند. متن آزمایش، وضعیت موجودبودن، زمان، قیمت، Refund/Cancel و استفاده از داده باید در نقطه تصمیم روشن باشد. Dark pattern اعتماد و کیفیت داده را هم‌زمان خراب می‌کند.

مرز رضایت، Scarcity، Countdown، Preselection و Cancel را با راهنمای طراحی اخلاقی کنترل کنید. درباره پیش‌فروش، پرداخت و داده شخصی در حوزه قضایی خود مشورت حقوقی بگیرید؛ Prototype مجوز دورزدن تعهدات نیست.

تست تبدیل با تست کاربردپذیری فرق دارد

روش	سؤال	واحد	خروجی
Usability test	کجا و چرا Task شکست می‌خورد؟	Session/Task/Participant	Issue، علت محتمل و Design change
A/B experiment	Variant در Population چه اثر علّی دارد؟	User/session طبق قرارداد	Effect + uncertainty + guardrail
Smoke test	Source/Promise اقدام اولیه می‌سازد؟	Eligible visitor	Demand signal محدود
Interview	Context، نیاز و رفتار قبلی چیست؟	Participant	Pattern و hypothesis

برای A/B واقعی به Assignment، Exposure، MDE، Power، SRM و بازه اعتماد نیاز دارید؛ «نسخه B بیشتر شد» کافی نیست. طراحی کامل Experiment در راهنمای CRO و آزمایش آمده است.

سایت‌ساز را با Capability انتخاب کنید، نه فهرست برندها

Capability	سؤال Pilot	شاهد
Interaction/Data	State، Form، Auth و workflow لازم را می‌سازد؟	Task end-to-end
Instrumentation	Event/Consent/Export و Truth reconciliation دارید؟	Raw test و QA
RTL/Persian	Typography، BiDi، عدد/تاریخ/آدرس درست است؟	Device matrix فارسی
Accessibility	Keyboard، label، focus، error و semantic قابل‌کنترل‌اند؟	Manual + automated audit
Performance	روی موبایل/شبکه هدف قابل‌استفاده است؟	Field/lab test
Security/Privacy	Access، retention، export/delete و incident چیست؟	Contract/config test
SEO/Domain	Status، title، canonical، noindex و redirect کنترل می‌شوند؟	Rendered HTML/crawl
Exit/TCO	Content/data/asset/domain/event IDs قابل خروج‌اند؟	Export/rebuild drill و cost model

برند «بهترین» عمومی وجود ندارد. ابزار مناسب برای Landing ممکن است برای SaaS stateful نامناسب باشد. محدودیت Workload، Quota، Integration و Exit را با راهنمای مقیاس‌پذیری سایت‌ساز بررسی کنید.

پلن رایگان همیشه ارزان‌ترین Prototype نیست

Subdomain، Branding اجباری، no-export، محدودیت Form، Analytics، Custom code، SEO، Storage، Collaborator یا پرداخت می‌تواند تست را منحرف کند. هزینه واقعی شامل زمان ساخت workaround، داده ازدست‌رفته، Upgrade، FX، Payment، Domain و Migration است. برای مقایسه پلن رایگان از راهنمای محدودیت و TCO سایت‌ساز رایگان استفاده کنید.

Prototype را از Production جدا نگه دارید

بعد	Prototype	MVP/Production
داده	Dummy/minimal، حذف سریع	Data contract، backup، rights و retention
امنیت	Access محدود و بدون Secret واقعی	Threat model، authz، patch و incident
Reliability	برای Session پژوهش کافی	SLO، monitoring، support و recovery
Performance	به‌اندازه سؤال تست	Load/field budget و capacity
Accessibility	از ابتدا برای تعامل موردتست	WCAG/AT coverage و maintenance
Operations	دستی و موقت می‌تواند باشد	Owner، runbook، reconciliation و audit

ظاهر حرفه‌ای نباید تیم را وادار کند Prototype را بی‌ممیزی Live کند. Technical debt آگاهانه، Expiry date و Owner برای خاموشی Prototype ثبت کنید.

حریم خصوصی و امنیت در Prototype تعطیل نمی‌شوند

تا حد ممکن Dummy data؛ داده شخصی فقط وقتی لازم، با هدف/رضایت/حفاظت/حذف روشن.
Prototype پژوهشی را با Password/Access control و noindex از عموم جدا کنید.
Secret تولید، کلید درگاه و Customer database را وارد Workspace آزمایشی نکنید.
ضبط Session، صدا/تصویر، Screen و Note را با رضایت و Retention محدود مدیریت کنید.
Form spam، file upload، webhook و Automation بیرونی را تهدیدمدل کنید.
اگر عملیات دستی پشت صحنه است، دسترسی اپراتور و خطای انسانی را ثبت کنید.

راهنمای GOV.UK نیز در تست با داده شخصی، استفاده از Dummy data را وقتی حفاظت کافی فراهم نیست توصیه می‌کند. مرز دقیق قانونی را برای بازار هدف با متخصص بررسی کنید.

Accessibility را به انتهای MVP موکول نکنید

اگر Prototype فقط با Mouse، دید کامل یا سرعت خواندن بالا کار کند، راه‌حل ناقص را معتبر جلوه می‌دهد. Semantic heading، Label، Keyboard، Focus، Error message، Contrast، Target size، Zoom و Screen reader را متناسب با Fidelity تست کنید. WCAG ۲.۲ از W3C معیارهایی مانند Focus not obscured، Target size، Redundant entry و Accessible authentication را افزوده است.

شرکت‌کننده دارای معلولیت را فقط در مرحله Audit دعوت نکنید؛ اگر بخشی از Population است در Discovery و Roundهای Prototype نیز حضور داشته باشد.

Prototype فارسی و ایران چه چیزهایی را باید واقعاً تست کند؟

ریسک	Test case	Failure رایج
RTL/BiDi	فارسی + Email/URL/کد/شماره	ترتیب و Cursor نادرست
حروف	ی/ک فارسی و عربی، نیم‌فاصله، Search	Duplicate/عدم تطبیق
عدد/پول	ریال/تومان، جداکننده و تبدیل	ده‌برابرشدن ادراک قیمت
تاریخ/زمان	شمسی/میلادی، منطقه زمانی و تعطیلی	نوبت جابه‌جا
موبایل/شبکه	Android رایج، شبکه کند/قطع، Back	Form/OTP از دست‌رفته
آدرس/تلفن	استان/شهر، پلاک، کدپستی، ۰۹/+۹۸	Validation خارجی نامتناسب
OTP/درگاه	Timeout، resend، duplicate و برگشت	سفارش/رزرو مبهم
دسترسی ابزار	Eligibility، پرداخت ارزی، Export و Support	Prototype غیرقابل‌تداوم

فقط از Wi‑Fi دفتر و لپ‌تاپ تیم تست نکنید. Device/Browser/ISP و شرایط زمینه‌ای Population را در Recruitment و Matrix بیاورید.

SEO و انتشار Prototype

Prototype پژوهشی را Auth کنید و noindex بگذارید تا کاربر عمومی و موتور جست‌وجو آن را سرویس واقعی ندانند. اگر Landing عمومی برای Demand test است، Title/Description/Status/Canonical، Claim و عملکرد Mobile واقعی باشند. بعد از تغییر URL یا Platform، Redirect و Event continuity را حفظ کنید. صفحات آزمایشی رهاشده می‌توانند Cannibalization و داده آلوده بسازند.

از یافته تا تصمیم: Observation با Insight فرق دارد

سطح	نمونه	خطا
Observation	۳ شرکت‌کننده «بیعانه» را ندیدند	تفسیر نیت
Pattern	در دو Segment، قیمت فقط در گام آخر دیده شد	تعمیم بیش از Sample
Insight	قیمت دیرهنگام مانع مقایسه و اعتماد است	علت بدون شاهد زمینه‌ای
Opportunity	قیمت/شرط را پیش از انتخاب زمان نشان دهیم	یکی‌دانستن Opportunity و Solution
Decision	Variant تازه با Task/Metric ثابت آزمایش شود	رفع فوری بدون retest

Quote، Clip، Screenshot و Event را به نسخه Prototype و Task وصل کنید. Severity را از Impact، Frequency و Persistence بسازید. یافته مخالف نظر بنیان‌گذار را حذف نکنید و تناقض‌ها را ثبت کنید.

چرخه Iteration سریع اما کنترل‌شده

یک سؤال پرریسک، نه ده سؤال.
یک Baseline/نسخه و تغییر قابل‌ردیابی.
Session یا Exposure با Population تعریف‌شده.
Synthesis همان روز با شواهد و Confidence.
Decision log: Keep/Change/Stop و دلیل.
Round بعدی برای مسئله‌های مهم، نه Cosmetic backlog.

Fast iteration به معنی تغییر وسط Session برای هر شرکت‌کننده نیست؛ مگر مطالعه تطبیقی را عمداً طراحی کرده باشید. در غیر این صورت نمی‌دانید چه نسخه‌ای چه نتیجه‌ای ساخته است.

چه زمانی Prototype را به MVP تبدیل کنیم؟

وقتی شاهد کافی برای مسئله/ارزش، Flow اصلی و امکان ارائه دارید، هنوز باید Production gap را ببندید:

Domain/Data model/API و Ownership
Authentication/Authorization/Secret/Privacy
Payment/order/idempotency/reconciliation
Performance/Capacity/SLO/Monitoring/Backup
Accessibility/Localization/Content/Support
SEO/Analytics/Consent/Attribution
TCO، Vendor contract، Export و Exit

ممکن است همان سایت‌ساز MVP را میزبانی کند؛ ممکن است Migration لازم باشد. معیار، Capability gap و TCO است، نه شرم از No-code یا شیفتگی به Custom.

Migration را پیش از انتخاب ابزار تصور کنید

از ابتدا مشخص کنید Domain، URL، Content، Submission، Customer data، Asset، Automation، Schema، Event ID و Consent record چگونه Export می‌شوند. یک Export نمونه بگیرید و Import/Checksum را آزمایش کنید. راهنمای تصمیم و Cutover در مهاجرت از سایت‌ساز آمده است.

مثال: Prototype رزرو برای یک کسب‌وکار ایرانی

مرحله	تصمیم	شاهد
Discover	مشاهده تماس/پیام و مصاحبه مشتری/اپراتور	علت No-show و کار فعلی
Define	فرض پرریسک: انتخاب خودکار + بیعانه پذیرفتنی است	Assumption map
Low-fi	دو Flow زمان‌محور/خدمت‌محور	Task completion و comprehension
Builder	Landing، Form سه‌گام، قیمت شفاف، Sandbox	Qualified booking، خطا، abandonment
Concierge	تطبیق دستی با تقویم واقعی و پیام تأیید	Cycle time، collision و هزینه اپراتور
Decision	Pilot محدود یا Stop/Pivot	Primary + guardrail + unit economics

اگر کاربران Flow را کامل کنند ولی Slot collision زیاد باشد، Desirability شاید تأیید و Feasibility رد شده است. پاسخ درست می‌تواند Integration تقویم یا Scope محدود باشد، نه صرفاً بزرگ‌ترکردن دکمه.

برنامه ۳۰روزه نمونه‌سازی سریع

روز ۱ تا ۵: Discover و Define

Segment، Job و رفتار فعلی را با تحقیق کوتاه بررسی کنید.
Assumptionها را در Desirability/Usability/Feasibility/Viability/Integrity بنویسید.
یک فرض پرریسک، سؤال، شاهد، Guardrail و قانون تصمیم انتخاب کنید.

روز ۶ تا ۱۲: Fidelity و Build

دو راه‌حل کم‌هزینه Sketch و Critique کنید.
Medium و سایت‌ساز را با Capability/Exit انتخاب کنید.
Prototype version، Access/noindex، Dummy data و Event contract را بسازید.
Taskها را Pilot داخلی کنید؛ همکار جای شرکت‌کننده اصلی نیست.

روز ۱۳ تا ۲۰: Test

شرکت‌کننده واقعی و متنوع Recruit و رضایت/ضبط را مدیریت کنید.
Task غیرهدایت‌گر اجرا و Observation/Time/Error/Quote ثبت کنید.
اگر Demand test است، Traffic source و Eligibility را ثابت نگه دارید.
Data quality و Reconciliation را پیش از تحلیل کنترل کنید.

روز ۲۱ تا ۳۰: Synthesis و Decision

Observation→Pattern→Insight→Opportunity را با Confidence تفکیک کنید.
Primary، Guardrail، Bias و محدودیت را کنار هم گزارش کنید.
Persevere/Pivot/Research/Stop را با دلیل ثبت کنید.
برای MVP، Production gap/TCO/Exit؛ یا برای Round بعد، سؤال جدید تعریف کنید.

اشتباه‌های پرتکرار

بازکردن Template پیش از تعریف مسئله و فرضیه.
اشتباه‌گرفتن Prototype زیبا با Product مفید.
پرسیدن «دوست دارید؟» به‌جای مشاهده Task/تعهد واقعی.
تست با همکار، خانواده یا Traffic نامرتبط و تعمیم به بازار.
تعبیر کلیک/Lead به‌عنوان پرداخت و Retention.
تغییر چند متغیر و نداشتن Version/Exposure.
جمع‌آوری داده واقعی/حساس در Prototype ناامن.
Fake door، Scarcity یا پرداخت گمراه‌کننده.
موکول‌کردن RTL، Accessibility و شبکه موبایل به Production.
کپی مستقیم Prototype code/config به سرویس زنده.
انتخاب پلن رایگان بدون Export/TCO و سپس Lock-in.
ادامه ساخت به‌خاطر Sunk cost با وجود شاهد رد.

چک‌لیست قبل از هر Round

Segment، Context، Problem و رفتار فعلی مستندند.
فقط یک سؤال/فرض پرریسک اصلی برای Round تعریف شده است.
Prototype کم‌هزینه‌ترین Fidelity معتبر برای همان سؤال است.
Primary، Denominator، Guardrail، Threshold، Period و Decision rule از پیش نوشته شده‌اند.
شرکت‌کنندگان واقعی، متنوع و متناسب با سؤال Recruit شده‌اند.
Taskها هدف دارند و پاسخ/Label را لو نمی‌دهند.
Prototype version، Access، noindex، Dummy data و Expiry مشخص‌اند.
Consent، Recording، Retention و حذف داده تعریف شده‌اند.
Keyboard/Screen reader/RTL/BiDi/Mobile/Network متناسب تست می‌شوند.
Eventها با Truth source QA و Reconcile شده‌اند.
Observation از Interpretation و تصمیم جدا ثبت می‌شود.
Production gap، TCO، Export و Exit پیش از تبدیل به MVP روشن‌اند.

پرسش‌های متداول

تفاوت Prototype و MVP چیست؟

Prototype ابزار موقت یادگیری است و ممکن است تعامل یا Backend شبیه‌سازی‌شده داشته باشد. MVP کمینه محصول واقعی است که مسئله‌ای را برای کاربر حل می‌کند و متناسب با ریسک به امنیت، داده، دسترس‌پذیری، پشتیبانی و عملیات نیاز دارد.

آیا سایت‌ساز برای ساخت MVP کافی است؟

اگر Capabilityهای لازم—Flow، Data، Payment، Security، Accessibility، Performance، Monitoring، Export و TCO—را با کیفیت لازم فراهم کند، بله. اگر Gap حیاتی دارید، Integration، Hybrid یا Migration لازم است. نام No-code یا Custom معیار کافی نیست.

بهترین سایت‌ساز برای نمونه‌سازی کدام است؟

بهترین عمومی وجود ندارد. برای Landing به انتشار/فرم/Analytics، برای فروشگاه به Catalog/Payment/order، و برای SaaS به State/Auth/API نیاز دارید. ابزار را با Prototype واقعی، RTL، Accessibility، Data export، هزینه و Exit بسنجید.

برای تست Prototype چند کاربر لازم است؟

به سؤال و روش بستگی دارد. برای یک Round کیفی Usability معمولاً گروه کوچک هدفمند و چند Round تکراری مفید است؛ GOV.UK بازه معمول ۴ تا ۸ نفر را ذکر می‌کند. برای A/B، Survey یا برآورد نرخ به Sample و Power بسیار بزرگ‌تر نیاز است؛ عدد ثابت را به همه روش‌ها تعمیم ندهید.

آیا می‌توان با Landing page خرید یا تقاضا را تست کرد؟

Landing پیام و اقدام اولیه را می‌سنجد، نه الزاماً خرید/Retention. برای شاهد قوی‌تر، قیمت و Constraint را شفاف کنید و تعهد واجد شرایط بسازید. اگر خدمت آماده نیست، وضعیت، زمان، داده و Refund را صادقانه اعلام کنید و از Fake door گمراه‌کننده دوری کنید.

جمع‌بندی: هدف Prototype ساختن نیست؛ کم‌کردن عدم‌قطعیت است

سایت‌ساز می‌تواند در یک روز چیزی قابل لمس بسازد، اما ارزش آن در تعداد صفحه یا سرعت Drag-and-drop نیست. ارزش در این است که سؤال پرریسک را با Fidelity درست، کاربر درست، رفتار قابل‌مشاهده و تصمیم ازپیش‌تعریف‌شده جواب دهد.

اگر امروز ایده‌ای دارید، هنوز Template انتخاب نکنید. Segment، مسئله، پرریسک‌ترین فرض و شاهدی که نظرتان را واقعاً عوض می‌کند بنویسید. بعد کوچک‌ترین Prototype صادقانه را بسازید. گاهی نتیجه «ادامه بده» است؛ گاهی «مسئله را عوض کن» و گاهی ارزشمندترین خروجی توقف پیش از سه ماه ساخت بی‌فایده است.