برای طراحی سایت از کجا شروع کنیم؟ نقشه آمادگی

سه شرکت برای «طراحی سایت فروشگاهی» سه قیمت کاملاً متفاوت می‌دهند. یکی فقط قالب و درگاه دیده، دیگری مهاجرت ۱۲هزار محصول و URL را حساب کرده و سومی تصور کرده انبار و قیمت از فایل Excel می‌آیند؛ در حالی که سیستم حسابداری باید منبع حقیقت باشد. اختلاف فقط قیمت نیست؛ هرکدام پروژه متفاوتی را برآورد کرده‌اند، چون خریدار هنوز مسئله، داده، جریان و معیار پذیرش را روشن نکرده است.

برای طراحی سایت از کجا شروع کنیم؟ از خرید قالب، انتخاب WordPress یا درخواست قیمت شروع نکنید. ابتدا تصمیم بگیرید آیا واقعاً سایت جدید لازم است، چه Outcomeی برای چه مخاطبی می‌خواهید، چه دارایی و محدودیتی دارید و نسخه نخست با چه شاهدی پذیرفته می‌شود. خروجی این مرحله یک سند صدصفحه‌ای نیست؛ یک Website brief + Readiness pack کوچک، مستند و قابل‌مقایسه است.

پاسخ کوتاه: ده خروجی پیش از سفارش

1. Problem/Outcome و گزینه «نسازیم/اصلاح کنیم»؛
2. Decision owner و Stakeholder map؛
3. Audience، Journey و سناریوی اصلی؛
4. Inventory سایت، محتوا، URL، داده و حساب‌ها؛
5. Capabilityهای Must/Should/Could/No-go؛
6. Content/Data/Integration readiness؛
7. Quality و Acceptance قابل‌آزمون؛
8. Budget/TCO range و محدودیت زمان؛
9. Risk/assumption/dependency register؛
10. RFP/Pilot pack برای مقایسه تیم‌های اجرا.

برای تعریف جامع اینکه طراحی سایت چه اجزایی دارد، ابتدا Pillar طراحی سایت چیست را ببینید؛ این صفحه فقط آمادگی پیش از شروع را مالک است.

گام صفر: آیا سایت جدید راه‌حل مسئله است؟

«رقبا سایت جدید دارند» یا «ظاهر قدیمی شده» Problem statement نیست. گزینه‌ها را پیش از Rebuild مقایسه کنید:

راهنمای تصمیم بازطراحی سایت Root cause و Option gate را عمیق‌تر بررسی می‌کند.

Problem statement یک‌صفحه‌ای بنویسید

امروز: چه کسی در چه Journey با چه مانعی روبه‌رو است؟
اثر: این مانع چه هزینه/ریسک/فرصتی دارد و شاهد چیست؟
تغییر مطلوب: کدام رفتار یا Outcome باید بهتر شود؟
مرز: چه چیزی در این پروژه نیست؟
Guardrail: چه چیزی نباید بدتر شود؟
مالک: چه کسی تصمیم و Outcome را می‌پذیرد؟

نمونه: «شرکت‌های متقاضی پس از دیدن خدمت نمی‌دانند آیا برای پروژه‌شان Fit هستیم؛ ۶۰٪ تماس‌های فروش خارج Scope است. باید قبل از تماس، Scope/Proof/Constraint روشن و Lead واجدشرایط به CRM برسد؛ حجم Lead خام نباید هدف شود و زمان پاسخ فروش نباید افزایش یابد.»

Outcome را از Output جدا کنید

Page count، Feature count و Launch date Outcome نیستند. اندازه‌گیری Outcome باید پیش از Build ممکن شود.

Decision owner و RACI را زود تعیین کنید

وقتی همه نظر می‌دهند و هیچ‌کس تصمیم نمی‌گیرد، Review طولانی و Scope متناقض می‌شود. یک Product/Project owner داخلی باید Priority، Conflict و Acceptance را جمع‌بندی کند.

بازخورد ذی‌نفعان را در یک کانال و با Deadline جمع کنید. «نظر شخصی مدیر» و «یافته تست کاربر» را با برچسب متفاوت ثبت کنید.

مخاطب را با نقش و Job توصیف کنید

«همه مردم» مخاطب نیست. برای هر Role بنویسید:

role + context + job + question + evidence needed + action + obstacle + risk + channel/device

در خرید B2B، User، مدیر، Procurement، Security و Finance ممکن است سؤال‌های متفاوت داشته باشند. در فروشگاه، خریدار، گیرنده، پشتیبانی و اپراتور سفارش Roleهای جدا هستند. ابتدا Journey پرارزش را انتخاب کنید؛ همه Personaها نباید در نسخه نخست مسیر کامل بگیرند.

برای Evidence، Journey map و Service blueprint از راهنمای پرسونا و سفر مشتری استفاده کنید.

پنج مصاحبه داخلی کوتاه اما ساختاریافته

با فروش، پشتیبانی، عملیات، محتوا و فناوری صحبت کنید. سؤال‌های نمونه:

• کدام درخواست بیشترین ارزش یا بیشترین اتلاف را دارد؟
• مشتری پیش از اقدام چه چیزی را اشتباه می‌فهمد؟
• کدام وعده را واقعاً نمی‌توانیم اجرا کنیم؟
• داده از کجا می‌آید و چه کسی آن را اصلاح می‌کند؟
• کدام Failure امروز با کار دستی جبران می‌شود؟
• اگر حجم دو برابر شود، کجا می‌شکنیم؟
• کدام قانون/دسترسی/پلتفرم تغییرناپذیر است؟

پاسخ داخلی Hypothesis است؛ با تماس، Ticket، Search query، Analytics یا کاربر واقعی اعتبارسنجی شود.

Baseline سایت موجود را قبل از دست‌زدن ذخیره کنید

اگر سایت فعلی دارید، Screenshot کافی نیست. Snapshot تاریخ‌دار بسازید:

• URLهای CMS، Sitemap، Crawl، Search Console و Analytics؛
• Title/Meta/H1/Canonical/Robots/Status/Schema؛
• Query، landing، conversion، backlink و referralهای مهم؛
• Content owner، updated date و decision: keep/update/merge/remove؛
• Field performance و error در Template/Journey؛
• Form/CRM/order/payment/email/SMS integration؛
• Accessibility/Security/Privacy defects و incidentها؛
• Hosting/DNS/CDN/cache/backup/monitoring configuration.

Google در راهنمای رسمی Site move با تغییر URL بر آماده‌سازی سایت جدید، URL mapping، Redirect، Search Console و پایش تأکید می‌کند. حتی اگر هنوز مهاجرت قطعی نیست، Inventory جلوی حذف کور دارایی را می‌گیرد.

ممیزی محتوا: Keep، Improve، Merge، Remove یا Create

برای هر Content item، Audience/Job، Evidence، Quality، Freshness، Traffic/Outcome، Link و Owner را ثبت کنید. صفحه پربازدید لزوماً مفید نیست و صفحه کم‌ترافیک ممکن است Policy حیاتی باشد.

content_id, url, type, audience_job, owner, source, last_review, risk, outcome, decision, destination

عکس، ویدئو، PDF، فونت، Logo، Icon و مجوز استفاده نیز بخشی از Inventory هستند. «بعداً محتوا می‌نویسیم» برآورد Design و Timeline را غیرواقعی می‌کند.

معماری اطلاعات اولیه، بدون طراحی منو

ابتدا Content type و رابطه را مدل کنید؛ سپس Navigation. Site map اولیه باید از Job کاربر، Lifecycle و Content operations بیاید، نه چارت واحدهای شرکت. برای هر Candidate page مشخص کنید:

• Audience/Intent و Promise؛
• Evidence/CTA؛
• Parent/related links؛
• Template/Content type؛
• Owner/Freshness؛
• Indexability و URL؛
• Stateهای Empty/Error/Unavailable.

راهنمای معماری اطلاعات، Taxonomy و Navigation برای مرحله بعدی مفید است.

Capability inventory بسازید، نه Wish list

هر قابلیت باید به Actor/Job/Rule/Data/State/Volume/Acceptance متصل باشد:

MVP یعنی جریان کامل کوچک، نه نسخه ناقص

نسخه نخست باید یک Outcome را End-to-end کامل کند. فروشگاهی که Product page دارد اما مرجوعی/پرداخت/پشتیبانی نامشخص است، MVP نیست. قابلیت‌ها را دسته‌بندی کنید:

• Must: نبود آن Journey یا Compliance را می‌شکند؛
• Should: ارزش بالا اما Workaround موقت دارد؛
• Could: پس از Evidence؛
• Won’t now: آگاهانه خارج نسخه؛
• No-go: ریسک/هزینه/شرط غیرقابل‌قبول.

برای Mustها Scenario پذیرش و Owner تعیین کنید. «Chatbot AI» بدون Job و Baseline در Backlog آینده بماند.

Content readiness را امتیاز دهید

اگر Content آماده نیست، زمان/هزینه Content design و review را داخل Scope بیاورید؛ جای خالی را با Lorem ipsum پنهان نکنید.

Data map اولیه بسازید

برای هر داده بنویسید چرا، از کجا، توسط چه کسی، به کجا، با چه دسترسی و تا چه زمان:

data/entity → purpose → source → fields → owner → recipients/vendors → access → retention → deletion/export → incident

نام/موبایل/ایمیل Form فقط شروع است؛ Order، Payment، Analytics ID، Chat، Session replay، Cookie، Applicant CV و Support attachment نیز داده‌اند. داده حساس را پیش از انتخاب Tool به Vendor ناشناس ندهید.

Integration inventory و Source of truth

لیست «اتصال به CRM، درگاه و پیامک» برای برآورد کافی نیست. برای هر Integration:

• System/owner/environment؛
• Entity و Source of truth؛
• API/Webhook/File/Manual؛
• Auth/secret/allowlist؛
• Rate/volume/latency؛
• Retry/idempotency/order/replay؛
• Error/DLQ/reconciliation؛
• Sandbox/test data/support؛
• Version/change/exit.

یک نامه «API داریم» Evidence Fit نیست؛ Vertical slice کوچک با Failure واقعی لازم است.

نیازهای غیرعملکردی را قابل‌آزمون کنید

دسترس‌پذیری را در Scope، بودجه و مسئولیت بگذارید

راهنمای Planning and Managing Accessibility از W3C دسترس‌پذیری را در Initiate/Plan/Implement/Sustain و با Policy، مسئولیت، بودجه، Baseline، ارزیابی زودهنگام و Monitoring قرار می‌دهد. عبارت «رعایت استانداردها» در پیشنهاد کافی نیست.

Target، بخش‌های شامل، نقش Content/Design/Development/QA، روش تست و Remediation SLA را روشن کنید. برای Baseline سایت موجود از راهنمای ممیزی WCAG استفاده کنید.

Security را با Requirement بنویسید

OWASP ASVS 5.0.0 برای تعریف و Verification کنترل‌های Web application و استفاده در Procurement طراحی شده است. همه Requirementها برای سایت معرفی کوچک لازم نیستند؛ سطح و موارد مرتبط را بر اساس Threat/Data/Function انتخاب و نسخه را ثبت کنید.

Account admin، MFA، Role، Backup، Update، Secret، Log، Incident، Vulnerability remediation و Offboarding حداقل پرسش‌های شروع‌اند.

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

Domain، DNS، Hosting/Cloud، Email، CMS، Repository، Analytics، Search Console، Ads، CDN و Vendor portal باید در Account register باشند. برای هرکدام Legal/Business owner، Admin، MFA، Recovery، Billing، expiry و emergency access مشخص شود.

ICANN Registrant را فرد/نهاد ثبت‌کننده می‌داند که با Registrar قرارداد دارد و مدیریت/انتقال/تمدید تابع همان قرارداد است. این راهنما برای دامنه‌های مشمول ICANN است؛ برای .ir شناسه، صاحب امتیاز، رابط‌ها و مقررات جاری IRNIC را در سامانه رسمی همان زمان بررسی کنید. دامنه را در حساب شخصی طراح یا آژانس رها نکنید.

بودجه را به Range و سبد هزینه تبدیل کنید

بودجه فقط مبلغ Build نیست:

Low/Likely/High range، فرض حجم و ارز، اقلام شامل/خارج و Contingency مرتبط با Risk را ثبت کنید. راهنمای هزینه‌های پنهان سایت و TCO مدل کامل‌تر می‌دهد.

Deadline را به Constraint و Trade-off تبدیل کنید

اگر تاریخ نمایشگاه، کمپین یا الزام قانونی ثابت است، علت و Consequence تاخیر را بنویسید. سپس Scope را با Vertical slice/Phased release تنظیم کنید؛ Quality gate بحرانی را حذف نکنید. تفاوت این سه تاریخ را ثبت کنید:

• Prototype/Decision date؛
• Content freeze/Go-no-go؛
• Launch/Hypercare/Outcome review.

مدت دقیق پروژه مالک مقاله زمان‌بندی ۱۷۷۸ است؛ در اینجا فقط ورودی‌های لازم برای برآورد آماده می‌شوند.

ریسک‌ها، فرض‌ها و وابستگی‌ها را ثبت کنید

id | type(risk/assumption/dependency) | statement | evidence | likelihood/impact | owner | due | mitigation | trigger

نمونه ایران: دسترسی/تمدید SaaS خارجی، نرخ ارز، PSP/SMS sandbox، اختلال شبکه، تعطیلات، فونت/مجوز، تفاوت ریال/تومان، زمان Asia/Tehran و دسترسی متخصص. «بعداً حل می‌شود» برنامه نیست.

نمونه RFP کوچک اما قابل‌مقایسه

1. Context و Problem/Outcome؛
2. Audience/Journeyهای اولویت‌دار؛
3. Current state و Inventory summary؛
4. Must/Should/Won’t/No-go؛
5. Content/Data/Integration readiness؛
6. Quality/Acceptance و Test evidence؛
7. Timeline constraints و staged option؛
8. Budget range/TCO assumptions؛
9. Ownership/handover/support/exit expectations؛
10. درخواست Approach، team، risks، exclusions و comparable breakdown.

همان Pack را به همه ارائه‌دهندگان بدهید تا Quoteها یک مسئله را قیمت‌گذاری کنند. انتخاب شرکت و Due diligence مالک مقاله ۱۷۷۹ و بندهای حقوقی/تجاری مالک ۱۷۸۰ است.

Pilot را پیش از تعهد بزرگ تعریف کنید

Vertical slice نماینده انتخاب کنید: مثلاً Product→Cart→Payment sandbox یا Service→Form→CRM. Pilot باید Content فارسی واقعی، Role، Integration، Error، Mobile، A11y، Performance، SEO و Export را به‌اندازه ریسک لمس کند.

Readiness score؛ ابزار تصمیم داخلی، نه امتیاز جهانی

هر حوزه را ۰ تا ۲ امتیاز دهید: ۰ نامعلوم، ۱ Hypothesis/ناقص، ۲ Evidence/Owner/Decision. حوزه‌ها: Outcome، Audience، Content، Data، Integration، Scope، Quality، Budget، Ownership، Operations. Score پایین به معنای توقف همیشگی نیست؛ نشان می‌دهد Discovery یا Pilot باید کجا سرمایه‌گذاری شود.

وزن‌ها را بر اساس ریسک تنظیم و Version کنید. این Score استاندارد Google یا تضمین موفقیت نیست.

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

• همه متن‌ها؛ اما Content model و Owner باید روشن باشد.
• همه Featureهای آینده؛ اما Must و architecture-changing assumption لازم است.
• Logo/Visual نهایی؛ مگر Rebrand Scope و dependency باشد.
• Technology قطعی؛ مگر Constraint واقعی و موجه باشد.
• برآورد روزبه‌روز؛ پیش از Discovery فقط Range/assumption.

اصل این است: تصمیم پرهزینه و برگشت‌سخت را زود Evidence دهید؛ جزئیات برگشت‌پذیر را به زمان مناسب موکول کنید.

Gate آمادگی برای Kickoff

• Problem/Outcome/Guardrail تصویب شده؛
• Decision owner و زمان Review مشخص؛
• یک Journey و Vertical slice اولویت دارد؛
• Inventory و Baseline سایت فعلی قابل‌دسترسی است؛
• Must/Should/Won’t/No-go ثبت شده؛
• Content/Data/Integration owner و Gap معلوم است؛
• Acceptance و Quality target نسخه‌دار است؛
• Budget range و Timeline constraint شفاف است؛
• Domain/accounts روی کنترل سازمان‌اند؛
• Risk/assumption/dependency و مالک دارند؛
• Pilot و Go/No-go evidence تعریف شده؛
• پیشنهادها روی Scope مشترک قابل‌مقایسه‌اند.

برنامه هفت‌روزه آماده‌سازی

روز ۱: Problem و Owner

مسئله، شاهد، Outcome، Guardrail، No-build option و صاحب تصمیم را ثبت کنید.

روز ۲: Audience و Journey

Roleها، سؤال‌ها، موانع و یک Journey نماینده را با Sales/Support و داده موجود مرور کنید.

روز ۳: Inventory و Baseline

URL/Content/Media/Data/Integration/Account و Performance/Search/Analytics/issue baseline را جمع کنید.

روز ۴: Scope و Content/Data

Must/Should/Won’t/No-go، Content readiness، Data map و Source of truthها را تعیین کنید.

روز ۵: Quality و Risk

Acceptance برای A11y/Security/Privacy/SEO/Performance/Ops و Risk/assumption/dependency را بنویسید.

روز ۶: Budget و Pilot

TCO range، Timeline constraint، Vertical slice و Evidence تصمیم را مشخص کنید.

روز ۷: RFP و Review

Pack را با ذی‌نفعان تصویب و نسخه یکسان را برای مقایسه ارائه‌دهندگان منتشر کنید.

خطاهای رایج شروع پروژه سایت

• شروع از رنگ، قالب، CMS یا Framework؛
• فرض Rebuild بدون Root cause/No-build option؛
• هدف «حضور حرفه‌ای» بدون Outcome/Guardrail؛
• پرسونا از حدس بدون Evidence؛
• نادیده‌گرفتن URL/Content/Data سایت فعلی؛
• Wish list بدون Actor/Job/Acceptance؛
• MVP ناقص به‌جای Journey کامل کوچک؛
• ورود Content واقعی پس از Design؛
• «API داریم» بدون Sandbox/Failure/Reconciliation؛
• Fast/Secure/SEO-friendly/Accessible بدون معیار؛
• دامنه و حساب‌ها روی ایمیل شخصی مجری؛
• بودجه فقط Build و نادیده‌گرفتن Run/Change/Exit؛
• Deadline قطعی بدون Scope trade-off؛
• Quote گرفتن با Briefهای متفاوت؛
• تعهد کامل بدون Pilot نماینده.

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

این راهنما در ۱۲ اوت ۲۰۲۶ بازبینی شده است. مقررات دامنه، پلتفرم، دسترس‌پذیری و Security تغییر می‌کنند؛ نسخه و حوزه را در زمان خرید بررسی کنید.

• W3C WAI: Planning and Managing Web Accessibility
• Google Search Central: Site moves with URL changes
• OWASP ASVS 5.0.0
• ICANN: Information for Domain Name Registrants

سوالات متداول شروع طراحی سایت

اولین قدم برای طراحی سایت چیست؟

نوشتن Problem/Outcome یک‌صفحه‌ای و بررسی گزینه نسازیم/اصلاح کنیم/بازطراحی کنیم. سپس Audience/Journey، دارایی موجود و معیار پذیرش را مشخص کنید؛ Technology و ظاهر بعدتر می‌آیند.

اول دامنه بخریم یا شرکت طراحی سایت انتخاب کنیم؟

نام و ریسک برند را زود بررسی کنید و دامنه لازم را از مسیر رسمی ثبت کنید، اما Registrant/صاحب امتیاز، ایمیل، MFA، Recovery و Billing باید تحت کنترل سازمان باشد. قواعد دامنه .ir را در IRNIC جاری و gTLD را نزد Registrar مربوط بررسی کنید.

آیا باید همه محتوا قبل از شروع آماده باشد؟

نه، اما Inventory، Content model، پیام اصلی، Owner، Source و برنامه تولید/بازبینی باید آماده باشد. محتوای واقعی پیش از UI نهایی وارد شود تا طول، Proof، RTL، State و Workflow آزموده شوند.

نسخه اول سایت چه امکاناتی داشته باشد؟

کمترین مجموعه‌ای که یک Journey پرارزش را End-to-end و با Recovery/Operations کامل می‌کند. هر Must باید Actor، Job، Rule/Data، Failure و Acceptance داشته باشد؛ Feature جذاب بدون Evidence به بعد موکول شود.

برای گرفتن قیمت طراحی سایت چه اطلاعاتی بدهیم؟

Problem/Outcome، Audience/Journey، Inventory فعلی، Scope اولویت‌دار، Content/Data/Integration، Quality/Acceptance، Budget/زمان، مالکیت/پشتیبانی/Exit و Riskها را در RFP یکسان بدهید تا پیشنهادها واقعاً قابل‌مقایسه باشند.

جمع‌بندی: پیش از سفارش، مسئله را قابل‌خرید کنید

شروع حرفه‌ای یعنی ابهام‌های پرهزینه را به تصمیم، مالک و شاهد تبدیل کنید. Brief خوب تیم اجرا را محدود به راه‌حل دلخواه شما نمی‌کند؛ مسئله، Outcome، Guardrail و قیود را روشن می‌کند تا راه‌حل‌های متفاوت قابل‌ارزیابی باشند.

امروز فقط سه سطر بنویسید: «چه کسی کجا گیر می‌کند؟ چه تغییری می‌خواهیم؟ با چه شاهدی می‌فهمیم بهتر شده؟» سپس یک Journey، Inventory فعلی و Owner را اضافه کنید. این Pack کوچک، کیفیت برآورد و انتخاب بعدی را بیش از فهرست صد Feature بالا می‌برد.