طراحی سایت چیست؟ اجزا، خروجی‌ها و معیار کیفیت

دو سایت می‌توانند ظاهر تقریباً یکسانی داشته باشند؛ یکی Lead واجدشرایط را با رضایت کاربر به CRM می‌رساند، روی موبایل و Keyboard کار می‌کند، خطای پرداخت را بازیابی و با تغییر محتوا خراب نمی‌شود. دیگری فقط Screenshot زیبایی برای روز تحویل است. هر دو «طراحی شده‌اند»، اما فقط اولی یک سیستم قابل‌استفاده و قابل‌عملیات است.

طراحی سایت فرایند تبدیل هدف سازمان و نیاز انسان به مجموعه‌ای از صفحه‌ها، تعامل‌ها، محتوا، داده و عملیات است که در وب قابل‌دسترسی، قابل‌فهم، امن، سریع، قابل‌پایش و قابل‌تغییر باشند. طراحی بصری بخشی از آن است؛ Strategy، Research، معماری اطلاعات، Content، UX/UI، Accessibility، توسعه، SEO، Security، Measurement و نگهداری نیز در همان تصمیم شریک‌اند.

پاسخ کوتاه: طراحی سایت شامل چه چیزهایی است؟

1. تعریف Outcome، مخاطب، مسئله و محدودیت؛
2. مدل‌کردن Journey، محتوا، صفحه، State و نقش‌ها؛
3. طراحی معماری اطلاعات، تعامل، رابط و زبان؛
4. انتخاب پلتفرم و معماری فنی متناسب؛
5. توسعه با کیفیت‌های عملکرد، امنیت، دسترس‌پذیری و SEO؛
6. تست سناریوهای واقعی و Failure؛
7. انتشار، مشاهده‌پذیری، اندازه‌گیری و بهبود چرخه‌ای.

اگر Scope فقط «یک سایت شیک با پنج صفحه» باشد، تصمیم‌های اصلی درباره کاربر، محتوا، داده، پذیرش، مالکیت و عملیات به بعد موکول می‌شوند؛ همان‌جایی که تغییر گران‌تر است.

طراحی وب، توسعه وب و محصول دیجیتال چه تفاوتی دارند؟

در پروژه کوچک یک نفر ممکن است چند نقش داشته باشد؛ حذف نقش فکری با کوچک‌شدن تیم توجیه نمی‌شود.

وب‌سایت صفحه نیست؛ سیستم تجربه، محتوا و عملیات است

هر صفحه چند State دارد: Loading، Empty، Success، Error، Permission، Out-of-stock، Payment pending و Offline. هر محتوا نیز Owner، Source، تاریخ، وضعیت و چرخه اصلاح دارد. پشت فرم، فرایند پاسخ، SLA، CRM و حریم خصوصی وجود دارد. بنابراین Deliverable طراحی فقط فایل Figma یا HTML نیست.

User need → interface state → domain action → data/integration → operational owner → measurable outcome → recovery

هدف کسب‌وکار را به Outcome کاربر وصل کنید

«افزایش فروش» برای طراحی کافی نیست. مشخص کنید کدام Audience در چه Situation چه Jobی دارد، چه مانعی را باید رفع کند و موفقیت چگونه تأیید می‌شود.

برای تبدیل مشاهده‌ها به Persona/Journey/Blueprint و Backlog، از راهنمای پرسونا و نقشه سفر مشتری مبتنی بر شواهد استفاده کنید.

انواع رایج سایت، برچسب پروژه نیستند

• شرکتی/خدماتی: معرفی، اعتماد، Case، Qualification و Lead؛
• فروشگاهی: Catalog، Search، Variant، Inventory، Price، Cart، Payment و Order operations؛
• رسانه/محتوا: Taxonomy، Editorial workflow، Search، Subscription و Archive؛
• Landing/Microsite: Source→Promise→Evidence→Action برای یک Campaign؛
• Marketplace: چند نقش، عرضه/تقاضا، Trust، Payment و Dispute؛
• وب‌اپ/Portal: Auth، Role، Workflow، Data، State و Integration؛
• Documentation/Help: Findability، Version، Feedback و Deflection؛
• Hybrid: Marketing/content عمومی در کنار Product app خصوصی.

یک «سایت شرکتی» با رزرو، قیمت‌گذاری پویا و پنل نماینده ممکن است از Landing ساده پیچیده‌تر باشد. نوع را از Actor/Job/Rule/Data/State/Volume/SLO استخراج کنید.

چرخه عمر طراحی سایت

Discover → Define → Model → Prototype → Design → Build → Verify → Launch → Operate → Learn

این مراحل Waterfall اجباری نیستند؛ چرخه‌های کوچک و بازخوردی بهترند. اما حذف Discovery یا Verify معمولاً عدم‌قطعیت را به Production منتقل می‌کند. Launch پایان ساخت نیست؛ آغاز مشاهده رفتار واقعی است.

Discovery چه چیزی را روشن می‌کند؟

Discovery باید ابهام را کاهش دهد، نه فقط جلسه معارفه برگزار کند:

• اهداف و Counterfactual: اگر سایت نسازیم چه می‌شود؟
• Audience/role و Journeyهای پرارزش؛
• Evidence از Analytics، Search، Support، Sales و پژوهش؛
• Content/Data/Integration موجود؛
• محدودیت حقوقی، امنیتی، فنی، زمانی و ایران؛
• Capabilityهای Must/Should/Could و No-go؛
• Acceptance، Owner، Budget range و مسیر Exit.

در این مرحله Solution از پیش‌تعیین‌شده را نفروشید. شاید مشکل با اصلاح Content/IA/Form حل شود و Rebuild لازم نباشد.

Requirement را به سناریوی قابل‌آزمون تبدیل کنید

«سایت سریع، امن و کاربرپسند باشد» الزام نیست. نمونه سناریو:

Given: کاربر مهمان با Android اقتصادی و شبکه همراه
When: محصول موجود را به سبد اضافه و درگاه را باز می‌کند
Then: قیمت/ارز صحیح، رویداد یکتا، وضعیت سفارش قابل بازیابی و خطای شبکه دارای Retry امن است
Evidence: synthetic test + RUM + order/payment reconciliation
Owner: commerce lead

Quality attribute را با Context/Stimulus/Response/Measure بنویسید؛ در غیر این صورت Vendor و کارفرما تعریف متفاوتی از «حرفه‌ای» خواهند داشت.

محتوا پیش از قاب نهایی وارد طراحی شود

Lorem ipsum طول، لحن، Proof، جدول، خطا، RTL و تصویر واقعی را نمایندگی نمی‌کند. Content inventory و مدل محتوا باید مشخص کنند هر Entity چه Field، رابطه، Owner، Source و Lifecycle دارد.

معماری اطلاعات: ساختار بر اساس مدل ذهنی، نه چارت سازمان

IA صفحه، Navigation، Taxonomy، Label، Search و رابطه محتوا را طراحی می‌کند. کاربر لازم نیست بداند خدمت زیرمجموعه کدام معاونت است. Card sorting، Tree testing، Search log و Support query برای Label/Grouping Evidence می‌دهند.

برای Inventory، Sitemap، Taxonomy، Facet، Navigation و Governance به راهنمای معماری اطلاعات سایت مراجعه کنید.

UX research و طراحی تعامل

UX با Persona تزئینی یا «خودمان کاربر را می‌شناسیم» کامل نمی‌شود. Risk تعیین می‌کند چه Research لازم است:

• مصاحبه برای Context/Language/Constraint؛
• مشاهده/Support review برای رفتار و failure؛
• Usability test برای Task، Error و Recovery؛
• Prototype برای ارزان‌کردن یادگیری؛
• Analytics/RUM برای توزیع رفتار واقعی؛
• Accessibility research با کاربران دارای معلولیت.

تست پنج نفر قانون کافی برای همه پروژه‌ها نیست؛ Sample، Task و دورها بر اساس ریسک/تنوع انتخاب می‌شوند. راهنمای تست کاربردپذیری Study plan و تبدیل Evidence به تصمیم را پوشش می‌دهد.

UI و Visual design چه خروجی‌ای می‌سازند؟

UI باید سلسله‌مراتب، Affordance، Feedback، State، خوانایی و هویت را به Component قابل‌ساخت تبدیل کند. فقط Desktop happy path کافی نیست. برای هر Component دست‌کم Default/Hover/Focus/Active/Disabled/Loading/Empty/Error/Success و Responsive/RTL تعریف شود.

Design token برای رنگ، Type، Space، Radius و Motion، Pattern برای Form/Navigation/Table و Content rule برای Label/Error/Hints ساخته می‌شود. Design system محصول جانبی گران برای هر سایت کوچک نیست؛ حداقل سیستم لازم را متناسب با تغییرپذیری بسازید.

Responsive design یعنی سازگاری با Context

Responsive فقط سه Breakpoint نیست. عرض، ارتفاع، Zoom، Orientation، Input، Keyboard، Motion preference، Contrast mode، Font load و محتوای بلند فارسی باید تحمل شوند. Container و Component behavior را با محتوای واقعی بسنجید.

روی دستگاه‌های اقتصادی، مرورگرهای در دسترس، WebView، اینترنت همراه/ثابت و قطع اتصال آزمایش کنید؛ «در موبایل خوب به نظر می‌رسد» معادل Task success نیست.

دسترس‌پذیری از ابتدا، نه افزونه آخر کار

W3C WAI دسترس‌پذیری را توان ادراک، فهم، Navigation، Interaction و مشارکت افراد دارای معلولیت می‌داند. Semantic HTML، Keyboard، Focus، Contrast، Text alternative، Label/Error، Caption و Motion preference باید در Content/Design/Code/Test حضور داشته باشند.

هم CMS/editor باید برای Author قابل‌استفاده باشد و هم او را در تولید محتوای دسترس‌پذیر یاری کند. ATAG این دو بخش را از هم تفکیک می‌کند. برای ممیزی کامل، راهنمای تست دسترس‌پذیری WCAG را ببینید.

فارسی و RTL یک تست انتهایی نیست

• ی/ک و نیم‌فاصله در Search، Sort و URL slug؛
• BiDi برای ایمیل، Domain، کد، شماره سفارش و IBAN؛
• ریال/تومان با واحد صریح و عدم ضرب اشتباه؛
• تاریخ شمسی/میلادی و Timezone Asia/Tehran؛
• شماره موبایل و تلفن با Normalization؛
• Font فارسی، وزن، Fallback و CLS؛
• آیکن جهت‌دار، Progress، Carousel و Focus order؛
• متن بلند ترجمه، Error و Empty state.

انتخاب پلتفرم پس از Capability و Operating model

گزینه‌ها طیف‌اند: Hosted builder، CMS مدیریت‌شده، WordPress self-hosted، Headless/Hybrid و Custom. تصمیم را بر اساس Capability، فرکانس تغییر، Workflow، Integration، Non-functional requirement، TCO، مهارت تیم، مالکیت و Exit بگیرید.

راهنمای سایت‌ساز یا کدنویسی اختصاصی Scorecard و Vertical-slice Pilot ارائه می‌کند. هیچ گزینه‌ای ذاتاً سریع‌تر، امن‌تر یا SEO-friendly نیست.

معماری فنی را به‌اندازه نیاز پیچیده کنید

برای سایت محتوایی، Rendering ساده و CMS مناسب ممکن است بهترین باشد. برای Product app چندنقشی، Domain/API/State/Authorization/Observability مهم می‌شود. Microservice، Kubernetes یا Headless نباید نشانه حرفه‌ای‌بودن تلقی شوند.

Actor/Job → capability → source of truth → state/rules → integration → SLO/failure → security/privacy → operations/exit

Front-end و Backend در طراحی چه نقشی دارند؟

Front-end Semantic HTML، CSS، Interaction و ارتباط با API را در Browser پیاده می‌کند. Backend منطق Domain، Data، Authorization، Integration و Taskهای async را مدیریت می‌کند. مرز دقیق به معماری بستگی دارد؛ Validation فقط Client-side یا Policy فقط در مدل UI قابل‌اعتماد نیست.

API contract باید Request/Response/Error/Version/Idempotency/Timeout و Owner داشته باشد. فرم «تماس» نیز Failure state، Spam control، notification، retention و SLA پاسخ لازم دارد.

SEO بخشی از معماری و محتواست، نه افزونه رتبه

راهنمای شروع SEO گوگل SEO را کمک به فهم محتوا توسط موتور و کمک به کاربر برای یافتن و تصمیم‌گیری می‌داند و تضمین Index/رتبه اول ارائه نمی‌کند. در طراحی سایت این موارد از ابتدا لازم‌اند:

• URL و Intent ownership؛
• Navigation و لینک a href؛
• Title/Meta/H1/Body منحصربه‌کاربر؛
• HTTP status، Redirect، Canonical، Robots و Sitemap؛
• Structured data مطابق محتوای مرئی؛
• Rendering محتوای اصلی و Failure fallback؛
• Content workflow، Author/Source/Freshness/Correction؛
• Search Console و Release annotation.

Performance را با Journey و Field data بسنجید

PageSpeed score هدف تجاری نیست. LCP/INP/CLS Field در صدک مناسب، Task latency، Error و دستگاه/شبکه واقعی را بسنجید. Budget برای Image/Font/CSS/JS/Third-party/Main thread در سطح Template تعریف کنید.

تصویر زیبا، Analytics، Chat، Map و Animation هر کدام هزینه دارند؛ ارزش و هزینه را با هم بسنجید. Performance را به Conversion نسبت ندهید مگر با طراحی اندازه‌گیری و کنترل Confounder.

امنیت و حریم خصوصی Requirement هستند

HTTPS تنها بخشی از امنیت است. Asset/Data/Actor/Threat/Trust boundary را مشخص و Least privilege، Authentication، Authorization، Validation/Encoding، Secret management، Logging، Backup و Incident را طراحی کنید. OWASP ASVS 5.0.0 می‌تواند Requirementهای قابل‌آزمون Security و زبان Procurement بدهد؛ «امنیت کامل» یا Badge مبهم Acceptance نیست.

برای داده نیز Purpose، Basis/Consent در صورت نیاز، Minimization، Access، Retention، Vendor/Subprocessor، Export/Delete و Incident تعریف شود. فرم نباید اطلاعاتی را بگیرد که Process بعدی نیاز ندارد.

اعتماد از شواهد و Recovery ساخته می‌شود

Logo، Testimonial و Badge به‌تنهایی اعتماد نیستند. هویت، قیمت و شرایط شفاف، Claim با Source، Review واقعی، مسیر تماس، وضعیت پرداخت، جبران خطا و Correction مهم‌اند. برای معماری کامل از راهنمای اعتمادسازی در سایت استفاده کنید.

Measurement plan پیش از Launch

PII را در URL/Event نریزید و Event dictionary، Owner، Version و QA داشته باشید.

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

• Content/claim/link/metadata review؛
• Visual/responsive/RTL regression؛
• Keyboard/Screen reader/Zoom/contrast؛
• Unit/Component/Integration/E2E متناسب با ریسک؛
• Form/Payment/Webhook/Email/SMS و failure injection؛
• Security verification و dependency/configuration؛
• Performance lab/field و load/capacity در صورت نیاز؛
• SEO HTTP/source/render/index contract؛
• Backup/restore، deploy/rollback و monitoring.

راهنمای مهندسی Test portfolio وب انتخاب لایه بر اساس Risk و Feedback speed را پوشش می‌دهد.

Acceptance Criteria پیش از قرارداد

جزئیات حقوقی را در مقاله قرارداد جدا نگه می‌داریم، اما تعریف طراحی بدون پذیرش ناقص است. برای هر Deliverable بنویسید:

scope + scenario + environment + expected result + evidence + owner + severity + due + waiver/expiry

• URL/Page/Stateهای تحویلی؛
• Browser/device/language/accessibility target؛
• Performance/Security/SEO/Data criteria؛
• Content/Media ownership و license؛
• Domain/DNS/Hosting/Repo/CMS/Analytics account control؛
• Source/design/export/backup/documentation؛
• Training، warranty، support، SLA و Exit.

هزینه طراحی سایت از چه چیزی ساخته می‌شود؟

رقم ثابت بدون Scope بی‌معناست. TCO را تفکیک کنید:

برای ایران، ریال/تومان، تورم/ارز، دسترسی Vendor، تمدید، محدودیت پرداخت، شبکه، PSP/SMS و Support را به فرض‌های تاریخ‌دار تبدیل کنید. قیمت کمتر ممکن است با Change/Incident/Exit گران‌تر شود.

زمان طراحی سایت چگونه برآورد می‌شود؟

برآورد از تعداد Template/State، Content readiness، Integration، Migration، Review latency، Test depth و Availability تیم می‌آید؛ نه فقط Page count. سه زمان را جدا کنید:

• Time to learning: نخستین Prototype/Pilot؛
• Time to launch: Release قابل‌استفاده با Acceptance؛
• Time to outcome: داده کافی برای ارزیابی اثر.

تقویم قطعی پیش از Discovery، Precision کاذب است. جزئیات زمان‌بندی مالک Intent مقاله تخصصی جدا خواهد بود.

مالکیت در طراحی سایت دقیقاً چیست؟

«مالکیت کامل سایت» را به Assetهای جدا بشکنید:

Launch چه چیزهایی نیاز دارد؟

Launch یک DNS change ساده نیست. Go/No-go، Backup، Migration/reconciliation، Redirect/canonical/sitemap، Cache warm، Monitoring، Support readiness، Communication، Rollback و Hypercare لازم‌اند. اگر Order/Data در حال تغییر است، Cutover و Delta/write control طراحی شود.

پس از انتشار: Operate و Learn

سایت باید Owner و SLO داشته باشد. Uptime به‌تنهایی کافی نیست؛ مسیرهای حیاتی، Error، latency، queue/webhook، form delivery، payment reconciliation، Search health و content freshness پایش شوند. راهنمای Observability و Monitoring سایت Signal→Alert→Owner→Runbook→Learning را عملی می‌کند.

چه زمانی سایت موجود را اصلاح کنیم و چه زمانی بازطراحی؟

ظاهر قدیمی دلیل کافی برای Rebuild نیست. Root cause ممکن است Content، IA، Form، Integration، Performance یا Operations باشد. گزینه‌ها از Repair/Content refresh/Visual refresh/UX-IA redesign تا Replatform/Rebuild طیف دارند. تصمیم را با Evidence، TCO، Risk و Reversibility بگیرید.

چک‌لیست Brief اولیه

• مسئله و Outcome، نه فقط «نیاز به سایت»؛
• Audience/Role/Journeyهای اصلی؛
• Content/Data/URL/System موجود؛
• Capabilityهای Must/Should و No-go؛
• Language/RTL/Accessibility/Jurisdiction؛
• Integration و Source of truth؛
• Security/Privacy/Performance/SEO/Availability target؛
• Budget range و هزینه Run/Change/Exit؛
• زمان‌های ثابت و علت آن‌ها؛
• مالک Content/Decision/Approval/Operations؛
• Acceptance/Evidence و Definition of Done؛
• مالکیت، تحویل، پشتیبانی و Exit.

خطاهای رایج در طراحی سایت

• شروع از Theme/Framework پیش از مسئله؛
• برابرگرفتن سایت حرفه‌ای با Animation/Technology؛
• ورود Content واقعی بعد از UI نهایی؛
• ساخت Sitemap از چارت سازمان؛
• Design فقط برای Desktop/happy path؛
• Accessibility و RTL در انتهای پروژه؛
• گفتن «Responsive/fast/secure/SEO-friendly» بدون Acceptance؛
• Collect داده بدون Purpose/Retention؛
• Tracking پس از Launch و بدون QA؛
• تست فقط روی لپ‌تاپ تیم؛
• تحویل Figma/ZIP بدون Account/Repo/Backup/Runbook؛
• پایان پروژه در Launch؛
• قیمت/زمان ثابت پیش از Scope؛
• Rebuild برای هر افت یا مشکل ظاهری؛
• وابستگی به یک نفر یا Vendor بدون Exit.

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

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

• W3C WAI: Introduction to Web Accessibility
• W3C WAI: ATAG Overview
• OWASP ASVS 5.0.0
• Google Search Central: SEO Starter Guide

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

طراحی سایت چیست؟

فرایند تبدیل هدف، نیاز کاربر و قواعد کسب‌وکار به صفحه، تعامل، محتوا، داده و عملیات وبِ قابل‌استفاده، دسترس‌پذیر، امن، سریع، قابل‌پایش و قابل‌تغییر است. ظاهر یکی از خروجی‌هاست.

آیا طراحی سایت فقط UI و ظاهر است؟

خیر. Strategy، Research، IA، Content، UX، Accessibility، Development، SEO، Security، Measurement، QA و Operations در کیفیت نهایی اثر دارند. UI بدون State/Content/Acceptance فقط بخشی از کار است.

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

کارفرما لازم نیست Developer باشد، اما باید هدف، محتوا، قواعد و پذیرش را با تیم روشن کند. تیم اجرا نیز باید Trade-off فنی، مالکیت، عملیات و ریسک را به زبان قابل‌فهم توضیح دهد.

وردپرس، سایت‌ساز یا کدنویسی اختصاصی کدام بهتر است؟

به Capability، فرکانس تغییر، Integration، کیفیت‌های غیرعملکردی، تیم، TCO، مالکیت و Exit بستگی دارد. گزینه را با Vertical-slice Pilot و Evidence خروجی انتخاب کنید، نه نام فناوری.

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

زیرساخت URL/Render/Metadata/Link/Performance و Content workflow باید در طراحی باشد؛ رشد ارگانیک تضمین نمی‌شود. نگهداری، Monitoring و بهبود نیز باید Scope/Owner/SLA روشن داشته باشند و ممکن است قرارداد جدا داشته باشند.

جمع‌بندی: طراحی سایت یعنی طراحی یک قابلیت پایدار

سایت موفق یک خروجی تصویری نیست؛ قابلیت سازمان برای خدمت‌رسانی، ارتباط، فروش یا انجام کار در وب است. کیفیت آن از اتصال تصمیم کسب‌وکار به نیاز انسان، Content/Data/Technology و عملیات سنجیده می‌شود.

برای شروع، یک Brief یک‌صفحه‌ای بنویسید: Audience، Job، Outcome، سه Journey، Content/Data موجود، محدودیت، Acceptance، Owner و Exit. سپس کوچک‌ترین Vertical slice واقعی را Prototype و Test کنید. این کار پیش از انتخاب قالب یا Framework، پرهزینه‌ترین ابهام‌ها را آشکار می‌کند.