قبل از کامپوننت، تصمیم کاربر را طراحی کنید

هر صفحه باید کار مشخصی انجام دهد

A landing page may help someone decide whether a service fits. A dashboard may help an operator decide what needs attention. A case study may help a buyer decide whether the team can deliver. When the primary decision is explicit, content stops competing for equal visual weight.

صفحه معرفی خدمات به مخاطب کمک می‌کند تشخیص دهد آن خدمت مناسب او هست یا نه. داشبورد نشان می‌دهد کدام کار نیاز به رسیدگی دارد. صفحه نمونه‌کار هم به مشتری اجازه می‌دهد توانایی طراح یا تیم را بسنجد. وقتی این هدف روشن باشد، لازم نیست همه بخش‌ها با اندازه و تأکید یکسان نمایش داده شوند.

Write the decision as a sentence, then list the questions a careful user will ask before committing. Those questions become the page’s information architecture. Decoration can improve recognition and emotion, but it should not reorder the evidence users need.

هدف صفحه را در یک جمله بنویسید. بعد سؤال‌هایی را فهرست کنید که مخاطب پیش از تصمیم گرفتن می‌پرسد. ترتیب همین سؤال‌ها، ساختار محتوا را مشخص می‌کند. رنگ، تصویر و حرکت باید به فهم آن کمک کنند؛ ترتیب اطلاعات مهم را صرفاً برای زیباتر شدن صفحه به هم نزنید.

اطلاعات را به ترتیب نیاز مخاطب بچینید

A dependable sequence often moves from promise to proof: state the outcome, explain who it is for, show the mechanism, present constraints, provide evidence, and offer the next action. Not every page needs this exact order, but every section should answer a question introduced by the one before it.

یک مسیر رایج این است: ابتدا بگویید نتیجه چیست و برای چه کسی مناسب است؛ بعد روش کار، محدودیت‌ها و نمونه واقعی را نشان دهید و در پایان راه ادامه را مشخص کنید. این ترتیب برای همه صفحات یکسان نیست. معیار این است که هر بخش، سؤال طبیعی بخش قبل را پاسخ دهد.

This approach also exposes missing content early. If a design needs three testimonials to feel credible but none exist, the gap is a product and content problem—not a reason to invent visual filler. Honest empty states and clearly labelled examples are stronger than unsupported certainty.

این نگاه کمبود محتوا را زود مشخص می‌کند. اگر طرح به سه نظر مشتری نیاز دارد ولی چنین نظرهایی ندارید، باید ساختار صفحه را اصلاح کنید. اضافه کردن متن ساختگی یا بخش‌های بی‌کاربرد، اعتماد ایجاد نمی‌کند. یک نمونه واقعی با توضیح دقیق، از چند ادعای بدون پشتوانه مفیدتر است.

کامپوننت فقط ظاهر تکراری نیست

Reusable components are most valuable when they preserve semantic and behavioral rules. A project card is not merely an image beside a title; it can guarantee a real heading, a single destination, status language, image dimensions, focus behavior, and consistent metadata. That contract makes reuse safer than copying markup.

یک کارت پروژه می‌تواند علاوه بر تصویر و عنوان، مقصد روشن، وضعیت پروژه، ابعاد ثابت تصویر و رفتار درست با کیبورد داشته باشد. وقتی این قواعد داخل کامپوننت قرار می‌گیرند، استفاده دوباره از آن هم ظاهر را یکدست می‌کند و هم احتمال فراموش شدن جزئیات مهم را کم می‌کند.

Keep content data separate from presentation only where separation reduces duplication. Avoid abstract systems that force every page into the same rhythm. A small set of strong primitives—section, stack, cluster, grid, media, heading, action—usually creates more range than dozens of narrowly named components.

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

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

Mobile is not the desktop page squeezed into one column. At each breakpoint, decide what must stay adjacent, what can stack, what can become a disclosure, and what loses value when space is scarce. Test long Persian titles, short English labels, real numbers, empty data, and error messages—not only ideal placeholder text.

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

Typography, container width, and spacing should respond continuously where possible. Breakpoints are for structural change, not for repairing every awkward line. Container queries, logical properties, intrinsic sizing, and fluid type reduce the number of brittle exceptions while keeping RTL and LTR behavior aligned.

اندازه نوشته و فاصله‌ها می‌توانند همراه عرض صفحه به‌تدریج تغییر کنند. نقطه شکست را برای تغییر ساختار انتخاب کنید، نه برای اصلاح تک‌تک خط‌ها. ویژگی‌های منطقی CSS مثل margin-inline نیز کمک می‌کنند فاصله‌ها در فارسی و انگلیسی درست عمل کنند.

بعد از انتشار، نتیجه را ببینید

A polished interface still needs an observable outcome. Define what success means before release: comprehension, completion, qualified enquiry, task time, reduced error, or support deflection. Pair the primary metric with guardrails such as accessibility, performance, error rate, and user trust.

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

The goal is not to turn every creative decision into a dashboard. It is to keep the team honest about which part of the page is doing which job. When the result is weak, revise the promise, evidence, sequence, or interaction before adding more visual effects.

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

• هدف اصلی صفحه در یک جمله روشن است.
• ترتیب محتوا به سؤال‌های واقعی مخاطب پاسخ می‌دهد.
• کامپوننت‌ها با کیبورد و محتوای واقعی قابل استفاده‌اند.
• معیار نتیجه، سرعت و دسترس‌پذیری مشخص شده است.