مراحل طراحی سایت؛ از Discovery تا Live

در گزارش پروژه نوشته‌اند «طراحی سایت ۹۰٪ تمام شده»؛ اما محتوای واقعی هنوز در Word است، Callback درگاه در خطا دوبار سفارش می‌سازد، Redirectهای سایت قدیمی آماده نیستند و هیچ‌کس نمی‌داند چه کسی اجازه انتشار می‌دهد. این پروژه ۹۰٪ تمام نشده؛ فقط بخشی که آسان‌تر دیده می‌شود جلو رفته است.

مراحل طراحی سایت حرفه‌ای صف ثابتی از «تحقیق، وایرفریم، UI، برنامه‌نویسی و تحویل» نیست. فرایند قابل‌کنترل سه حلقه دارد: کشف مسئله و ریسک، ساخت و راستی‌آزمایی در برش‌های کوچک، و عملیات و یادگیری پس از انتشار. هر مرحله باید سؤال تصمیم، خروجی قابل‌بررسی، Evidence، Owner و شرط ورود/خروج داشته باشد؛ درصد پیشرفتِ ذهنی جای آن‌ها را نمی‌گیرد.

پاسخ کوتاه: نقشه ۱۴ مرحله‌ای طراحی سایت

1. آمادگی و Project intake؛
2. Discovery مسئله، کاربر، وضعیت موجود و Constraint؛
3. Alpha/Pilot برای پرریسک‌ترین فرض‌ها؛
4. تعریف Operating model، Backlog و Quality gates؛
5. Content model و معماری اطلاعات؛
6. Journey، Flow، Wireframe و Prototype؛
7. UI system، Component و State؛
8. Architecture، Platform و Integration contract؛
9. Build در Vertical sliceهای قابل‌استفاده؛
10. Verification پیوسته و UAT؛
11. Migration rehearsal و Launch readiness؛
12. Cutover و Go-live؛
13. Hypercare و تثبیت؛
14. Live operations، Measurement، Improvement و Retirement.

برای معنای جامع طراحی و مرز Strategy/Content/UX/UI/Development/Quality، راهنمای طراحی سایت چیست را بخوانید. این مقاله مالک جریان کار و Evidence بین مراحل است، نه تعریف هر تخصص.

قبل از مراحل: پروژه را با Trackها ببینید، نه صف واحد

Content، Design، Engineering، Data/Integration، Quality و Operations منتظر پایان یکدیگر نمی‌مانند. آن‌ها با عمق متفاوت و در Cadence مشترک جلو می‌روند:

یک Timeline می‌تواند Milestone داشته باشد، اما یادگیری و تست باید Trackها را به عقب و جلو متصل کند.

مرحله ۱: آمادگی و Project intake

پیش از Kickoff بررسی کنید آیا ورودی حداقلی وجود دارد: Problem/Outcome، Decision owner، Budget range، Journey اولویت‌دار، دارایی موجود، Constraint، حساب‌ها و ریسک‌های شناخته‌شده. اگر پاسخ‌ها نامعلوم‌اند، Discovery را برای یافتن آن‌ها Scope کنید؛ آن‌ها را با فرض پنهان وارد Build نکنید.

راهنمای شروع پروژه طراحی سایت Website brief، Readiness pack، RFP و Pilot پیش از سفارش را پوشش می‌دهد. خروجی Intake یک قرارداد کامل نیست؛ یک Project charter نسخه‌دار و Backlog سؤال‌هاست.

context/problem | desired outcome/guardrail | owner/team
priority journey | known assets/systems | constraints
budget/time range | risks/assumptions | first decision date

مرحله ۲: Discovery؛ مسئله را پیش از راه‌حل بشناسید

GOV.UK Service Manual Discovery را فهم مسئله پیش از تعهد به ساخت می‌داند: User و Context، Journey وسیع‌تر، Constraintهای قانون/قرارداد/Legacy و فرصت‌های بهبود. در Discovery نباید Solution ازپیش‌تعیین‌شده را فقط توجیه کرد.

• مرور Analytics/Search/Support/Sales و مشاهده Task؛
• ممیزی URL، Content، Accessibility، Performance و Operations؛
• نقشه Actor/Journey/Channel و Backstage؛
• Inventory داده، Integration، Policy و Account؛
• گزینه‌های No-build/Repair/Content/UX/Replatform/Build؛
• Baseline هزینه، Outcome و Guardrail؛
• Risk/assumption/dependency register.

خروج Discovery یک «سایت دلخواه مدیر» نیست؛ Evidence کافی برای Stop، Repeat، Alpha/Pilot یا Delivery است.

Gate خروج Discovery

• Problem و Scope مسئله روشن و صاحب دارد؛
• کاربر، Journey و نیاز با شواهد اولیه توصیف شده‌اند؛
• وضع موجود و Baseline قابل‌بازیابی است؛
• Constraint سخت از ترجیح نرم جداست؛
• گزینه‌ها و Counterfactual «نسازیم» بررسی شده‌اند؛
• پرریسک‌ترین فرض‌ها و روش آزمون آن‌ها معلوم‌اند؛
• Outcome، Guardrail و معیار تصمیم اولیه دارند؛
• بودجه/تیم برای مرحله بعد واقع‌بینانه است.

اگر Gate رد شد، ادامه‌ندادن هم یک تصمیم حرفه‌ای است.

مرحله ۳: Alpha یا Pilot؛ پرریسک‌ترین فرض را ارزان بیازمایید

راهنمای Alpha از GOV.UK بر آزمون پرریسک‌ترین فرض‌ها با Prototypeهایی تأکید می‌کند که فقط به‌اندازه تصمیم پیچیده‌اند؛ Alpha جای Production code کامل نیست و خروجی آن ممکن است دورریختنی باشد.

Alpha باید با Decision record تمام شود: فرض چه بود، چه دیدیم، محدودیت چیست و Stop/Pivot/Proceed با چه شرطی.

مرحله ۴: Operating model و قواعد جریان کار

• Product/Service owner، تصمیم‌گیر Content/Design/Technical و Risk owner؛
• Repository، Design file، CMS، Ticket و سند مرجع؛
• Cadence برنامه‌ریزی، Show-and-tell، Research playback و Retro؛
• Definition of Ready و Definition of Done؛
• محیط Local/Development/Preview/Staging/Production؛
• نحوه Review، Approval، Change و Emergency fix؛
• Severity، SLA و Waiver با تاریخ انقضا؛
• مالکیت دسترسی، MFA، Secret و Offboarding.

ابزار مهم نیست؛ Traceability از مسئله تا تصمیم و Evidence مهم است.

Backlog را با Vertical slice بسازید

Backlog صفحه‌محور یا لایه‌محور، «همه UI سپس همه Backend» می‌سازد و Failure دیر آشکار می‌شود. Slice کوچک باید یک Outcome را از Content/UI تا Rule/Data/Integration/Telemetry لمس کند.

actor + job + scenario
content/data/rules/states
happy + edge + failure + recovery
acceptance + quality budgets
instrumentation + owner + evidence

مثلاً Slice «درخواست ارزیابی B2B» فقط Form نیست: Message و Proof، Validation، Consent، Spam، CRM idempotency، Notification، SLA، Error recovery و Qualified-outcome reconciliation را در بر می‌گیرد.

Definition of Ready و Done را قاطی نکنید

Done مطلق نیست؛ برای Prototype، Beta و Production تعریف متفاوت و صریح داشته باشید.

مرحله ۵: Content model و معماری اطلاعات

پیش از رنگ و Layout، Entity، Field، Relation، Source، Owner و Lifecycle محتوا را مدل کنید. سپس Candidate page و URL را بر اساس Audience/Intent/Answer/Evidence/Action بسازید.

• Inventory و Keep/Improve/Merge/Remove/Create؛
• Content type، Field، Validation و Reuse؛
• Claim/source/scope/date/review؛
• Taxonomy، Navigation، Search و Related content؛
• URL، Canonical، indexability و Redirect destination؛
• Owner، approval، freshness و archive/retire.

برای Card sorting، Tree testing و قرارداد URL/Taxonomy از راهنمای معماری اطلاعات سایت استفاده کنید. محتوای واقعی باید زود وارد Prototype شود؛ Lorem ipsum طول فارسی، Claim و Workflow را پنهان می‌کند.

مرحله ۶: Journey، Flow، Wireframe و Prototype

Prototype برای تأیید سلیقه مدیر ساخته نمی‌شود. با Task و Participant مرتبط مشاهده شود. راهنمای تست کاربردپذیری طراحی مطالعه، نمونه، سناریو و تبدیل یافته به تصمیم را پوشش می‌دهد.

مرحله ۷: UI system، Component و State

خروج UI مجموعه تصویر صفحه نیست؛ قواعد قابل‌اجرا برای Typography، Color، Spacing، Component، Content و State است. برای هر Component این حالت‌ها را در Context واقعی ببینید:

default | hover | focus | active | selected | disabled
loading | skeleton | empty | validation | error | success
permission | expired | offline | pending | partial | long-content

فارسی/RTL را با متن واقعی، نیم‌فاصله، ی/ک، عدد، ریال/تومان، تاریخ شمسی/میلادی، URL/ایمیل LTR، نام طولانی و Zoom کنترل کنید. Mobile یک قاب کوچک‌شده Desktop نیست؛ Priority، Input، Keyboard، Network و Thumb reach فرق دارد.

دسترس‌پذیری یک مرحله پایانی نیست

W3C Planning and Managing Accessibility فعالیت‌ها را در Initiate، Plan، Implement و Sustain قرار می‌دهد و بر مسئولیت، بودجه، Baseline، ارزیابی زودهنگام و Monitoring تأکید دارد. بنابراین Accessibility در Brief، Research، Content، Design، Component، Code، QA، Procurement و Operations سهم دارد.

Automated scan فقط بخشی از Evidence است. Keyboard، Focus، Heading/Landmark، Label/Error، Contrast، Zoom/Reflow، Screen reader و Task با افراد دارای نیاز مرتبط را بر اساس ریسک ترکیب کنید. راهنمای ممیزی WCAG Baseline، تست و Remediation را عمیق‌تر می‌کند.

مرحله ۸: Architecture، Platform و Integration contract

معماری از Brand یا Framework شروع نمی‌شود؛ از Actor/Job، Content/Data، Rule، Volume، Quality، Team و Exit شروع می‌شود.

• CMS/Builder/Headless/Custom و مرز مسئولیت؛
• Domain/Content/Data model و Source of truth؛
• Server/client rendering و Cache/invalidation؛
• API/Webhook/File و Auth/Secret؛
• Timeout/retry/idempotency/order/reconciliation؛
• Role/permission/audit/retention؛
• Deploy/rollback/backup/restore/observability؛
• Export، Portability و Decommission.

Architecture decision record باید Context، Options، Consequence، Owner و Review trigger داشته باشد؛ «بهترین تکنولوژی» بدون Context وجود ندارد.

مرحله ۹: Build در برش‌های قابل‌نمایش و قابل‌آزمون

هر Iteration یک Running increment بدهد، نه درصد لایه‌های نیمه‌تمام. شاخه کوتاه، Review کوچک، CI، Migration نسخه‌دار، Test data کنترل‌شده و Preview environment زمان Feedback را کم می‌کند.

Feature flag وقتی مفید است که Owner، Audience، default، exposure، expiry و cleanup دارد. Flag رهاشده بدهی عملیاتی است. Production data را بی‌دلیل به محیط تست کپی نکنید؛ Mask/synthetic fixture و دسترسی حداقلی لازم است.

مرحله ۱۰: Verification پیوسته، نه «هفته تست»

راهنمای Test portfolio وب نسبت Unit/Integration/E2E، Release gate و Production feedback را توضیح می‌دهد.

UAT با QA یکی نیست

QA می‌پرسد سیستم مطابق Contract و Quality target کار می‌کند؛ UAT می‌پرسد آیا Role کسب‌وکار می‌تواند سناریوی واقعی را با Rule/Content/Data درست انجام دهد. «یک دور سایت را نگاه کردیم» UAT نیست.

scenario | role | precondition/test data | steps
expected business result | downstream/reconciliation
actual/evidence | severity | owner | decision

محیط، Build، داده و Scope UAT را Freeze و نتیجه را ثبت کنید. Defect بحرانی را با «بعداً» نبندید؛ Waiver باید Risk owner، Mitigation و Expiry داشته باشد.

مرحله ۱۱: مهاجرت را چندبار تمرین کنید

Migration فقط Copy محتوا نیست؛ Content، Media، User/Role، Data، URL، Metadata، Redirect، Integration و عملیات را شامل می‌شود. Repeatable dry run با Count/Hash/Sample/Reconciliation بسازید.

Google Search Central برای تغییر URL بر آماده‌سازی و تست سایت جدید، URL mapping، Redirect و پایش هر دو URL قدیم/جدید تأکید می‌کند. اگر Domain، CMS و Layout همگی تغییر می‌کنند، دامنه ریسک را با ترتیب یا Pilot کوچک‌تر کنید.

برای Inventory، Export، Dry run، Delta، Cutover و Decommission عمیق‌تر، راهنمای مهاجرت پلتفرم سایت را ببینید.

Launch readiness؛ انتشار یک Event مهندسی‌شده است

• Scope/Build/Content/Config و Decision owner نهایی؛
• Critical defect و Waiverهای معتبر؛
• Backup و Restore evidence؛
• DNS/CDN/Certificate/Cache و TTL plan؛
• URL/Redirect/Canonical/Robots/Sitemap/Search Console؛
• Payment/Form/Email/SMS/CRM و Reconciliation؛
• Analytics/Consent/PII و Baseline؛
• Dashboard/Alert/On-call/Status/Support script؛
• Cutover sequence، command owner و communication؛
• Rollback trigger، point of no return و recovery path؛
• Vendor/contact/escalation و Change freeze؛
• Go/No-go record و Hypercare plan.

Checklist بدون تمرین Restore یا Rollback اطمینان کاذب می‌دهد.

مرحله ۱۲: Cutover، Go-live و کنترل ساعت اول

در War room نقش‌ها را از قبل جدا کنید: فرمان Cutover، اجرا، مشاهده، کسب‌وکار، پشتیبانی و ارتباطات. هر تغییر Timestamp و Owner داشته باشد. مسیرهای حیاتی را با Synthetic و Transaction واقعیِ کنترل‌شده بسنجید.

T-? freeze/backup/delta → deploy/migrate/configure
→ smoke/critical journey/reconcile → expose traffic
→ monitor user/system/search/support → go/rollback decision
→ stakeholder update → handoff to hypercare

موفقیت «صفحه اصلی باز شد» نیست؛ Order/Lead/Content/Role/Integration/Telemetry و Recovery باید کار کنند.

مرحله ۱۳: Hypercare و تثبیت

• Availability/latency/error و resource saturation؛
• Journey completion/drop/error/retry؛
• Order/Payment/CRM/Finance reconciliation؛
• ۴۰۴/redirect/crawl/index و landing traffic؛
• Support/contact/refund/complaint؛
• A11y/content/visual regression؛
• Security event، Spam و abuse؛
• Business outcome و Guardrail.

Exit از Hypercare باید شرط داشته باشد: Incidentهای بحرانی بسته، SLO پایدار، Reconciliation سالم، Runbook آزموده و تیم عملیات آماده.

مرحله ۱۴: Live یعنی عملیات و یادگیری مداوم

راهنمای Live از GOV.UK بر پشتیبانی پایدار، تحقیق و بهبود مستمر، Accessibility/Performance/Security/QA و اثر تغییر بر کانال‌های دیگر تأکید می‌کند. Launch پایان Design نیست؛ آغاز مشاهده رفتار واقعی و هزینه نگهداری است.

برای Journeyهای مهم SLI/SLO، Alert، Runbook و Error budget تعریف کنید. راهنمای Observability و مانیتورینگ سایت Telemetry، SLO و Incident learning را پوشش می‌دهد.

Measurement plan از Discovery تا Live ادامه دارد

Event باید Trigger، Property، Consent، Dedup، Source و Reconciliation داشته باشد. Traffic یا Click به‌تنهایی موفقیت پروژه نیست.

تغییر Scope را از اصلاح خطا جدا کنید

هر Feedback یکی از این‌هاست: Defect نسبت به Acceptance، فهم تازه از نیاز، تغییر کسب‌وکار/قانون، یا Preference. Impact را بر Outcome، Risk، Content/Data، Design، Architecture، Test، Time و TCO بسنجید.

change_id | reason/evidence | requested_by | affected scope
options | time/cost/risk/quality impact | decision owner
accepted/rejected/deferred | target release | acceptance update

تأیید Wireframe به معنای ممنوعیت یادگیری بعدی نیست؛ به معنای آن است که تغییر جدید باید آگاهانه و قابل‌ردیابی مدیریت شود.

نقش‌ها و تحویل مسئولیت

RACI را برای تصمیم‌های مهم بسازید، نه برای هر Task. Handover یک جلسه آخر نیست؛ تیم داخلی باید در طول پروژه در Review، Release و Incident drill مشارکت کند.

نمونه اجرای پروژه سایت B2B ایرانی

1. Discovery نشان می‌دهد مشکل کمبود Lead نیست؛ ۵۸٪ تماس‌ها خارج Scope و اطلاعات Fit مبهم است.
2. Alpha دو مدل Content/Qualification را با کاربران و فروش می‌آزماید؛ اتصال CRM با Sandbox Spike می‌شود.
3. Slice اول Service→Evidence→Form→CRM→SLA است؛ Spam، Duplicate و Failure نیز در Scope هستند.
4. Content owner Claimها و نمونه‌کارها را با Source/Consent/Review date آماده می‌کند.
5. Prototype با مدیر فنی و خرید آزموده و سؤال امنیت/پشتیبانی زود آشکار می‌شود.
6. Build با Content فارسی واقعی، Mobile/RTL، A11y و Telemetry پیش می‌رود.
7. سایت قدیمی Crawl و URLها Keep/Merge/Redirect می‌شوند؛ Dry run انجام می‌شود.
8. UAT یک Lead واجدشرایط را تا CRM و پاسخ فروش دنبال می‌کند.
9. Go-live با Dashboard فرم/CRM/۴۰۴ و Hypercare انجام می‌شود.
10. پس از چهار هفته، Qualified rate و time-to-response با Baseline و Guardrail Spam مقایسه می‌شوند.

عدد نمونه صرفاً Illustration است؛ هدف پروژه و Baseline باید از داده واقعی همان سازمان بیاید.

ریتم هفتگی پیشنهادی

روزانه: Sync کوتاه بر Blocker و Evidence

نه گزارش درصد؛ چه چیزی یاد گرفتیم، چه چیزی Block است و کدام تصمیم Owner می‌خواهد.

هفتگی: Show-and-tell با Running slice

Content واقعی، Prototype یا Build قابل‌استفاده را در Scenario نشان دهید؛ Slide جای تجربه را نگیرد.

منظم: Research و Quality playback

Observation، defect، metric و counter-evidence به Backlog و Acceptance برگردند.

هر Iteration: Planning، Review و Retro

Risk و Outcome را اولویت دهید؛ Actionهای Retro Owner و Due date بگیرند.

در Gateها: Decision review

Proceed/Stop/Pivot/Release با Evidence و Assumptionهای باقی‌مانده ثبت شود.

پانزده خطای رایج در مراحل طراحی سایت

• نمایش فرایند به‌صورت صف خشک و بدون Feedback loop؛
• شروع Build در Discovery؛
• Alpha زیبا اما بی‌ارتباط با پرریسک‌ترین فرض؛
• Backlog صفحه/لایه به‌جای Vertical slice؛
• درصد پیشرفت بدون خروجی و Evidence؛
• ورود دیر محتوای فارسی واقعی؛
• UI page set بدون Component state و Error؛
• انتخاب Technology پیش از Constraint و Operating model؛
• «API موجود» بدون Contract/Failure/Reconciliation؛
• Accessibility/Security/SEO/Performance در هفته آخر؛
• QA و UAT به‌عنوان یک نگاه کلی؛
• یک Migration بدون Dry run و Count/Hash؛
• Go-live بدون Owner/Monitor/Rollback؛
• Handover آخر پروژه بدون تمرین تیم داخلی؛
• Launch به‌عنوان پایان و نبود Live improvement/retirement.

منابع و وضعیت زمانی

این راهنما در ۱۲ اوت ۲۰۲۶ بازبینی شده است. فرایند را بر اساس اندازه، ریسک، قانون، تیم و نوع سرویس Tailor کنید؛ مدت‌های عمومی یا نام فازها قانون جهانی نیستند.

• GOV.UK: How the discovery phase works
• GOV.UK: How the alpha phase works
• GOV.UK: How the live phase works
• W3C WAI: Planning and Managing Web Accessibility
• Google Search Central: Site moves with URL changes

سؤالات متداول مراحل طراحی سایت

مراحل طراحی سایت به‌ترتیب چیست؟

آمادگی، Discovery، Alpha/Pilot، Operating model، Content/IA، UX/Prototype، UI system، Architecture، Build، Verification/UAT، Migration/Launch readiness، Go-live/Hypercare و Live operations. Trackها هم‌پوشان‌اند و با Evidence به عقب برمی‌گردند؛ این فهرست صف واترفال نیست.

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

Spike یا Prototype فنی می‌تواند در Alpha برای آزمون ریسک شروع شود؛ Build محصولی وقتی آغاز شود که Slice، Content/Data/Rule، Dependency، Acceptance و محیط به‌اندازه کافی Ready باشند. لازم نیست همه صفحه‌ها از پیش نهایی شوند.

محتوا در کدام مرحله طراحی سایت آماده می‌شود؟

Inventory و Content model از Discovery/IA شروع می‌شوند، متن واقعی پیش از UI نهایی وارد می‌شود و Migration/Review تا Launch ادامه دارد. پس از Live نیز Freshness، Claim و Retirement محتوا عملیاتی‌اند.

تست سایت فقط بعد از برنامه‌نویسی انجام می‌شود؟

خیر. مسئله و فرض در Discovery/Alpha، IA و Prototype با کاربر، Component/Contract هنگام Build و Journey/Quality/Operations پیوسته آزموده می‌شوند. پیش از Release نیز UAT، Migration rehearsal، Restore و Rollback evidence لازم است.

بعد از انتشار سایت چه مراحلی داریم؟

Hypercare، پایش SLO/Journey/Business، Incident و Reconciliation، رفع Regression، تحقیق و بهبود، نگهداری Content/Security/Accessibility/Performance و در نهایت تصمیم Replatform یا Retirement. Launch پایان پروژه محصولی نیست.

جمع‌بندی: هر مرحله باید یک تصمیم را ممکن کند

فرایند خوب با تعداد جلسه یا فایل سنجیده نمی‌شود. Discovery باید تصمیم ارزش ادامه را روشن کند؛ Alpha ریسک را کم کند؛ Sliceها Outcome قابل‌استفاده بسازند؛ Verification آسیب را پیش از کاربر بگیرد؛ Launch قابل‌بازگشت باشد و Live یادگیری را به تغییر امن تبدیل کند.

برای پروژه خود یک جدول پنج‌ستونه بسازید: «سؤال تصمیم، خروجی، Evidence، Owner، شرط خروج». اگر برای مرحله‌ای فقط نام فایل یا درصد دارید، هنوز تعریف فرایند کامل نیست.