الهام در طراحی سایت؛ از Reference تا Prototype و تست

وقتی می‌گوییم «برای طراحی سایت الهام می‌خواهم»، معمولاً یکی از سه مسئله پنهان است: هنوز مسئله و محتوای صفحه روشن نیست، زبان بصری مشترکی با تیم نداریم، یا میان چند راه‌حل گیر کرده‌ایم. دیدن صدها Screenshot ممکن است حال‌وهوای تازه بدهد، اما به‌تنهایی نمی‌گوید کدام الگو برای کاربر فارسی، داده واقعی، حالت خطا و محدودیت فنی پروژه شما کار می‌کند.

الهام حرفه‌ای یک Pipeline است: Reference را با Context جمع می‌کنید، الگو را Teardown می‌کنید، اصل قابل انتقال را از ظاهر جدا می‌سازید، چند Concept متفاوت می‌سازید و با Prototype و کاربر می‌آزمایید. این راهنما همین مسیر را همراه حقوق اثر، Accessibility، RTL، Performance و Decision log توضیح می‌دهد.

الهام، تقلید و شواهد را از هم جدا کنید

ایده کلی «فرم چندمرحله‌ای» با اجرای خاص متن، Illustration، Layout، Motion و Code یکسان نیست. U.S. Copyright Office توضیح می‌دهد Copyright از Expression حمایت می‌کند، نه ایده، روش یا سیستم؛ اما قانون و قرارداد به حوزه قضایی و Asset وابسته است. این توضیح مشاوره حقوقی نیست: License تصویر/فونت/Code و Trademark را ثبت و در مورد استفاده حساس بررسی تخصصی کنید.

پیش از Gallery، Design brief یک‌صفحه‌ای بسازید

بدون معیار، هر نمونه هم جذاب و هم نامربوط است. Brief باید تصمیم را محدود کند، نه اینکه راه‌حل را از ابتدا دیکته کند.

هفت سؤال پایه

1. کاربر: چه کسی در چه Contextی و با چه توانایی/محدودیتی وارد می‌شود؟
2. Job: می‌خواهد چه کاری را با چه نشانه‌ای تمام کند؟
3. Outcome: موفقیت کاربر و کسب‌وکار چگونه سنجیده می‌شود؟
4. Content/Data: چه متن، تصویر، قیمت، موجودی یا داده واقعی داریم؟
5. Constraint: RTL، موبایل، شبکه، قانون، Brand، CMS، زمان و تیم چیست؟
6. Risk: شکست این Journey چه آسیبی می‌زند؟
7. Decision: در پایان این مرحله دقیقاً چه چیزی باید انتخاب شود؟

پرسونا را با سن، جنسیت و سلیقه فرضی جای Research نگذارید. Support ticket، Search داخلی، Analytics، Interview، مشاهده Task و داده فرم شکست‌خورده ورودی‌های بهتری برای سؤال طراحی‌اند. فرایند کامل را در راهنمای طراحی تجربه کاربری دنبال کنید.

از سؤال طراحی، Search brief بسازید

جست‌وجوی «best website design» بیشترین زیبایی و کمترین تناسب را می‌دهد. Query را از نوع صفحه، Task، State، مخاطب و Constraint بسازید:

• [task] + [page/pattern] + [state]: بازیابی پرداخت + checkout + payment pending؛
• [domain] + [constraint]: داشبورد مالی + mobile RTL؛
• [component] + accessibility: date picker + keyboard؛
• [journey] + error/empty/loading: onboarding + verification failed؛
• [content type] + comparison: pricing plan + compare features؛
• [adjacent industry]: صف نوبت درمان برای الهام از Status در ارسال سفارش.

برای هر دور جست‌وجو Timebox و خروجی تعیین کنید: مثلاً «۴۵ دقیقه، حداکثر ۱۲ Reference، حداقل سه الگوی متفاوت و دو Anti-pattern». این کار گردآوری بی‌پایان را به تحقیق هدفمند تبدیل می‌کند.

منابع الهام را بر اساس نوع Evidence انتخاب کنید

پلتفرم‌هایی مثل Awwwards، Behance، Dribbble یا Pinterest می‌توانند Direction بصری نشان دهند، اما Award، Like و Screenshot اثبات Usability نیست. در مقابل، GOV.UK Design System Patternها را حول Task مشخص، Guidance و نمونه کد ارائه می‌کند؛ U.S. Web Design System نیز Component، Pattern، Token و راهنمای Accessibility دارد. حتی این منابع معتبر باید برای Context شما آزمایش شوند.

Reference inventory؛ لینک بدون یادداشت دانش نیست

Screenshot و URL را در Board رها نکنید. صفحه تغییر می‌کند، Context فراموش می‌شود و تیم بعداً فقط رنگ یا Shape را می‌بیند. برای هر Reference یک کارت بسازید:

Statusهایی مثل raw / reviewed / shortlisted / tested / rejected / adopted و Owner/Expiry اضافه کنید. دلیل رد نیز دانش است؛ Reference حذف‌شده بدون Decision note دوباره به بحث بعدی برمی‌گردد.

Teardown هشت‌لایه؛ ظاهر فقط لایه آخر نیست

۱. Context و Promise

کاربر از کجا آمده، چه می‌داند، چه وعده‌ای دیده و چه چیزی در خطر است؟ Hero یک سایت Portfolio را نمی‌توان بدون Context به صفحه پرداخت منتقل کرد.

۲. Information architecture و Content

چه اطلاعاتی پیش از تصمیم آمده، چه چیزی Group شده، Labelها از زبان کاربرند یا سازمان، و Content واقعی چقدر طول دارد؟ Screenshot انگلیسی با دو کلمه، رفتار عنوان فارسی یا قیمت چندسطری را نشان نمی‌دهد.

۳. Task flow و Decision

Entry، قدم‌ها، Primary action، Back، Cancel، Review و Confirmation را رسم کنید. آیا Flow خروج امن دارد؟ آیا کاربر می‌فهمد چه داده‌ای می‌دهد و چه تعهدی می‌سازد؟

۴. State و Recovery

Loading، Empty، Partial، Error، Permission denied، Offline، Timeout و Success را ببینید. Galleryها معمولاً Happy path را نشان می‌دهند؛ کیفیت محصول در Recovery آشکار می‌شود.

۵. Accessibility

Heading، Label، Contrast، Focus، Keyboard، Touch target، Zoom، Screen reader، Motion و Error را بررسی کنید. W3C WCAG 2.2 معیارهای قابل آزمون را زیر چهار اصل Perceivable، Operable، Understandable و Robust سازمان می‌دهد؛ Conformance را از روی Screenshot نمی‌توان اعلام کرد. فرایند مشارکت افراد دارای معلولیت و QA را با راهنمای طراحی فراگیر و WCAG کامل کنید.

۶. Responsive و RTL

نه فقط شکستن Grid، بلکه اولویت Content، ترتیب Focus، جدول، نمودار، Sticky action، Keyboard موبایل و متن Bidirectional را تست کنید. راهنمای W3C برای متن راست‌به‌چپ در صفحه فارسی استفاده از dir="rtl" روی عنصر html را توضیح می‌دهد؛ آینه‌کردن CSS به‌تنهایی کافی نیست.

۷. Performance و Feasibility

Video hero، WebGL، Blur، Font و Motion چه Byte/CPU و پیاده‌سازی‌ای می‌خواهند؟ Core Web Vitals جاری LCP، INP و CLS را برای Loading، Interaction و Visual stability در داده Field تعریف می‌کند. Screenshot از هزینه Runtime خبر نمی‌دهد.

۸. Trust، Ethics و Measurement

قیمت، حریم خصوصی، Consent، Review و Urgency چگونه ارائه شده‌اند؟ آیا Pattern کاربر را هل می‌دهد یا کمک می‌کند؟ Outcome و Guardrail چیست؟ Dark pattern جذاب را با راهنمای طراحی اخلاقی حذف کنید.

از Teardown، Pattern hypothesis استخراج کنید

جمله «این Card را دوست دارم» قابل آزمایش نیست. آن را به فرضیه تبدیل کنید:

برای کاربری که سه پلن نزدیک را روی موبایل مقایسه می‌کند، نمایش تفاوت‌های تصمیم‌ساز در Summary و جزئیات Progressive، زمان انتخاب و خطای Plan را کم می‌کند؛ به شرط اینکه Feature کلیدی پنهان نشود و Comparison با Keyboard قابل استفاده باشد.

هر فرضیه باید For whom + Context + Change + Expected outcome + Guardrail داشته باشد. سپس Prototype و Metric از آن ساخته می‌شوند. اگر فقط صفت «مدرن، تمیز، خلاق» دارید، هنوز Pattern تعریف نکرده‌اید.

چهار Board متفاوت بسازید

Moodboard باید کلمات جهت‌دار داشته باشد: «آرام، دقیق، بدون تزئین لوکس» بهتر از «زیبا» است. برای هر صفت، نشانه و Anti-example مشخص کنید. یک Board فارسی با Content واقعی بسازید؛ نمونه انگلیسی کوتاه Density و Rhythm متن شما را تحریف می‌کند.

Diverge؛ سه Concept واقعاً متفاوت بسازید

سه نسخه‌ای که فقط رنگ دکمه فرق دارد، واگرایی نیست. Conceptها باید فرض متفاوتی درباره IA، Sequence یا Interaction داشته باشند. برای مثال صفحه انتخاب دوره:

• Concept A — Goal-first: ابتدا هدف، سپس فیلتر و پیشنهاد چند دوره؛
• Concept B — Compare-first: جدول شفاف سطح/زمان/پیش‌نیاز؛
• Concept C — Evidence-first: نمونه درس و خروجی واقعی پیش از فهرست؛

در Timebox کوتاه، Sketch فردی قبل از بحث گروهی، تعداد و تنوع ایده را بالا می‌برد. سپس هر Concept با همان معیار Brief نقد شود؛ رأی سلیقه‌ای مدیر یا تعداد Like جای معیار نیست.

Converge؛ Scorecard پیش از Hi‑fi

وزن‌ها را قبل از امتیاز تعیین کنید و Gateهای Pass/Fail مثل حق استفاده، Security یا WCAG بحرانی را با میانگین جبران نکنید. نتیجه Scorecard تصمیم خودکار نیست؛ اختلاف نظر و Evidence ناقص را آشکار می‌کند.

از Mood به زبان بصری و Token برسید

برای جلوگیری از «Frankenstein UI»، عناصر چند Reference را مستقیم مونتاژ نکنید. Design principles کوتاه بسازید و انتخاب‌ها را به Token/Rule تبدیل کنید:

• Type scale برای فارسی و لاتین با وزن‌های واقعی Font؛
• Spacing scale و Density بر اساس Task؛
• Semantic color برای text/surface/action/status، نه نام رنگ خام؛
• Radius/Border/Shadow بر نقش و Elevation؛
• Motion برای Feedback و continuity با Reduced motion؛
• Image direction با Source، License، Crop و Alt؛
• Component anatomy، State و Content rule.

اگر جهت «مینیمال» است، حذف را با Minimum effective complexity بسنجید؛ Label، Help، Error و Evidence را قربانی ظاهر خالی نکنید. راهنمای طراحی سایت مینیمال این مرز را شرح می‌دهد.

محتوا را پیش از Hi‑fi وارد کنید

Lorem ipsum و عکس Placeholder باعث می‌شوند Layout خیالی بی‌نقص به نظر برسد. عنوان کوتاه/بلند، نام فارسی/لاتین، قیمت تومان/ریال، موجودی، خطا، Legal copy، جدول، Badge، کد پیگیری و User-generated content واقعی را زود وارد کنید.

Content stress test

• عنوان یک‌خطی و چهارخطی؛
• عدد فارسی/لاتین، اعشار، درصد، تلفن و کد؛
• نام کالا با برند لاتین داخل جمله RTL؛
• قیمت قبل/بعد تخفیف و مرز تومان/ریال؛
• بدون تصویر، تصویر عمودی/افقی و Alt طولانی؛
• Empty، Loading، Error، Partial و Permission state؛
• ترجمه یا Locale دوم با طول متفاوت.

جهت تصویر/ویدئو، Rights و Performance را با راهنمای رسانه در سایت هماهنگ کنید.

RTL فارسی؛ Mirror کردن پایان کار نیست

الهام از سایت LTR را با Flip افقی تمام نکنید. ترتیب منطقی DOM، خواندن متن دوزبانه، Back/Forward، Timeline، نمودار، Stepper، Icon جهت‌دار، جای Currency و ورود عدد را جدا طراحی کنید. Iconهای فیزیکی مثل Play الزاماً Mirror نمی‌شوند؛ Iconهای جهت مسیر ممکن است شوند. تصمیم را با معنی و Test بگیرید.

ترند را با هفت سؤال Gate کنید

1. چه Jobی را بهتر می‌کند؟
2. Affordance و Feedback را روشن‌تر یا مبهم‌تر می‌کند؟
3. با Keyboard، Screen reader، Zoom، Contrast و Reduced motion کار می‌کند؟
4. در موبایل و شبکه/Device ضعیف چه هزینه‌ای دارد؟
5. با Content و Brand واقعی سازگار است؟
6. ساخت، QA، نگهداری و Deprecation آن چقدر است؟
7. با چه Metric و چه Stop condition آن را می‌سنجیم؟

Glassmorphism، Bento، Brutalism، 3D یا AI image نه خوب‌اند نه بد؛ بدون Job فقط Decoration هستند. Trend register با تاریخ، Browser/support، Risk و Owner بسازید. اگر Trend حذف شد، Task باید همچنان قابل انجام باشد.

AI برای واگرایی، نه جعل Evidence

مدل مولد می‌تواند Directionهای بصری، نام‌گذاری Board، Edge case و Variant پیشنهاد دهد؛ اما خروجی آن User research، Pattern تأییدشده یا Asset دارای حق روشن نیست. UI تولیدشده ممکن است متن جعلی، کنترل ناممکن، Hierarchy متناقض یا Dark pattern داشته باشد.

• Prompt را با Brief/Constraint بدهید و داده شخصی یا محرمانه وارد نکنید؛
• هر خروجی را Reference خام با Provenance ثبت کنید؛
• Asset، Font، Logo و شباهت برند را از نظر حق و Trademark بررسی کنید؛
• Code تولیدشده را از Accessibility، Security، Performance و License عبور دهید؛
• خروجی را با کاربر و Content واقعی تست کنید؛
• AI را به‌عنوان منشأ «تحقیق کاربران نشان داد» ذکر نکنید.

Prototype متناسب با سؤال بسازید

Figma prototype برای Latency، Native form، Screen reader و Network حقیقت کامل نیست. Fidelity را آن‌قدر بالا ببرید که سؤال پاسخ بگیرد، نه بیشتر. برای Study plan، Recruitment، Task و تحلیل شواهد به راهنمای تست کاربردپذیری رجوع کنید.

Critique را از سلیقه به معیار تبدیل کنید

به‌جای «دوست دارم/مدرن نیست»، قالب نقد استفاده کنید:

در Context [X]، این تصمیم [مشاهده] احتمالاً روی [Task/Metric] اثر [Y] دارد، چون [اصل/شاهد]. برای بررسی، [Test] را انجام دهیم.

مثال: «در Checkout موبایل، Summary بسته باعث می‌شود هزینه ارسال تا آخر پنهان بماند؛ ممکن است Surprise و Back را بالا ببرد. یک نسخه با Total اولیه و Disclosure جزئیات را با Task و Error سنجش کنیم.» Critique باید علیه Artifact باشد، نه هویت طراح.

نمونه عملی: صفحه دوره آنلاین برای بازار ایران

فرض کنید Brief می‌گوید کاربر می‌خواهد قبل از پرداخت بفهمد دوره برای سطح او مناسب است، چه خروجی می‌گیرد و زمان تعهد چقدر است. تیم سه Reference پیدا می‌کند: Marketplace با Filter قوی، دانشگاه با پیش‌نیاز روشن و سرویس ویدئو با Preview سریع.

1. از Marketplace اصل مقایسه و فیلتر، نه Card visual، استخراج می‌شود؛
2. از دانشگاه ساختار پیش‌نیاز/سرفصل/ارزیابی گرفته می‌شود؛
3. از سرویس ویدئو Preview، Duration و Resume pattern بررسی می‌شود؛
4. Risk board شامل حجم ویدئو، Caption، سطح مبهم، قیمت تومان و ادعای شغلی است؛
5. سه Concept Goal-first/Compare-first/Evidence-first ساخته می‌شود؛
6. با کاربران مبتدی/حرفه‌ای، فهم Fit، انتخاب دوره و اعتماد به خروجی تست می‌شود؛
7. Concept منتخب با Video facade، متن فارسی واقعی و Error پرداخت Vertical slice می‌شود.

اگر محصول فروشگاهی است، Patternهای Catalogue/Product/Checkout و Stateهای موجودی/ارسال را با راهنمای UX فروشگاه اینترنتی تطبیق دهید.

اندازه‌گیری؛ الهام باید به تصمیم ختم شود

تعداد Reference، ساعت در Figma یا پسند Stakeholder Outcome نیست. Funnel طراحی را بسنجید:

Analytics می‌گوید کجا مشکل هست؛ Research و Test برای «چرا» کمک می‌کنند. آن‌ها را در فرایند UX داده‌آگاه ترکیب کنید و نسبت به Attribution تغییر Design محتاط باشید.

Governance؛ Reference و Pattern عمر دارند

یک Reference archive بدون Owner به موزه Screenshot تبدیل می‌شود. Quarterly review بگذارید: Link شکسته، Pattern منسوخ، تغییر WCAG/Browser، License منقضی، Result آزمایش و Component جایگزین را ثبت کنید. Pattern پذیرفته‌شده باید Anatomy، Content rule، State، Accessibility، Token، Code، Test و Changelog داشته باشد.

• Reference registry: Source/Date/Context/Rights/Status؛
• Decision log: انتخاب، گزینه‌ها، Evidence، Owner و Review date؛
• Pattern library: When/When not، State و Implementation؛
• Research repository: Finding با Participant/Method محدودشده و Privacy؛
• Design debt: شکاف Artifact با Pattern و Risk/Deadline.

برنامه ده‌روزه از ابهام تا Test

روز ۱ و ۲: Brief و Evidence

Job، Outcome، Content، Constraint و Risk را بنویسید. Support/Analytics/Research موجود را مرور و Evidence gap را جدا کنید. Search brief و Timebox بسازید.

روز ۳ و ۴: Reference و Teardown

۱۲ Reference از محصول خود، رقیب، صنعت مجاور، Design system و جهان غیر وب جمع کنید. هرکدام را با کارت Source/Task/State/Why/Risk/Rights ثبت و هشت‌لایه Teardown کنید.

روز ۵ و ۶: Pattern و Concept

فرضیه‌های قابل تست استخراج، Evidence/Mood/Pattern/Risk board را جدا و حداقل سه Concept ساختاری متفاوت Sketch کنید. با Gate حقوق/Accessibility/Feasibility گزینه‌های نامعتبر را کنار بگذارید.

روز ۷ و ۸: Content و Prototype

Content فارسی واقعی، RTL، Stateهای Failure و Deviceهای هدف را وارد کنید. Fidelity متناسب با سؤال بسازید و Test script بدون سؤال هدایت‌کننده آماده کنید.

روز ۹ و ۱۰: Test و Decision

Task، Comprehension، Keyboard/Screen reader و Performance slice لازم را آزمایش کنید. Finding را از Preference جدا، Decision log و Next experiment را ثبت کنید؛ Hi-fi فقط پس از پاسخ سؤال اصلی.

چک‌لیست الهام و ایده‌پردازی طراحی سایت

• Design brief کاربر، Job، Outcome، Content، Constraint و Risk دارد.
• Search brief و Timebox از جست‌وجوی بی‌پایان جلوگیری می‌کنند.
• منابع از چند صنعت/نوع‌اند و فقط Gallery نیستند.
• هر Reference URL، تاریخ، Task، State، Viewport، Why، Risk و Rights دارد.
• Happy path همراه Error/Empty/Loading/Offline بررسی شده است.
• اصل قابل انتقال از Style و Asset جدا شده است.
• Copyright/License/Trademark/Font/Code ثبت و بازبینی شده‌اند.
• Evidence، Pattern، Mood و Risk board با هم قاطی نشده‌اند.
• حداقل سه Concept واقعاً متفاوت ساخته شده‌اند.
• Gateهای Accessibility، Ethics، Rights و Feasibility Pass شده‌اند.
• Content فارسی واقعی، RTL/Bidi، تومان/ریال و عنوان بلند Test شده‌اند.
• Keyboard، Screen reader، Zoom، Touch و Reduced motion دیده شده‌اند.
• Performance budget و LCP/INP/CLS در Vertical slice سنجیده می‌شوند.
• Prototype Fidelity به سؤال تحقیق می‌خورد.
• Critique بر مشاهده، اثر، شاهد و Test نوشته می‌شود.
• Decision log دلیل انتخاب/رد و Review date دارد.
• Pattern پذیرفته‌شده Owner، State، Code، Test و Changelog دارد.

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

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

یک سایت بهترین نیست. Showcase برای Direction بصری، Design system برای Guidance/State/Code، محصول واقعی برای Flow و محصول خودتان برای Constraint مفید است. نوع منبع را به سؤال وصل کنید و Screenshot را Evidence موفقیت ندانید.

چگونه الهام بگیریم اما کپی نکنیم؟

منبع و تاریخ را ثبت، «چرا» را Teardown و اصل را به فرضیه تبدیل کنید؛ سپس چند Concept مستقل با Content/Brand خود بسازید. Asset، Code، Font و Expression را فقط با License مناسب استفاده کنید و برای ریسک حقوقی مشخص مشاور بگیرید.

Moodboard چه تفاوتی با Wireframe دارد؟

Moodboard جهت حسی و بصری—رنگ، Type، تصویر و Motion—را هم‌تراز می‌کند؛ Wireframe ساختار، Content و Flow را نشان می‌دهد. Moodboard صفحه نهایی و شاهد Usability نیست. Evidence board و Pattern board را نیز جدا نگه دارید.

از چند Reference استفاده کنیم؟

عدد جادویی وجود ندارد. برای یک دور کوتاه، سقفی مانند ۱۲ Reference با حداقل چند منبع متفاوت می‌تواند جلوی انباشت را بگیرد. وقتی Patternهای تازه کم و سؤال‌های Test روشن شدند، از جمع‌آوری به Concept بروید.

آیا می‌توان از AI برای ایده طراحی سایت استفاده کرد؟

بله، برای Divergence، Edge case و Mood direction؛ اما خروجی AI تحقیق کاربر یا Pattern تأییدشده نیست. داده محرمانه وارد نکنید، منشأ و Rights را بررسی و UI/Code را با Content واقعی از Accessibility، Security، Performance و Test عبور دهید.