Design the decision before the component

Every page has a decision to support

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.

یک landing page شاید به مخاطب کمک کند بفهمد سرویس مناسب او هست یا نه. یک dashboard به اپراتور نشان می‌دهد چه چیزی نیاز به توجه دارد. یک case study به خریدار کمک می‌کند توان تحویل تیم را بسنجد. وقتی تصمیم اصلی صریح باشد، محتوا برای وزن بصری برابر با هم رقابت نمی‌کند.

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.

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

Build an evidence ladder

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.

این رویکرد کمبود محتوا را زود آشکار می‌کند. اگر طراحی برای معتبرشدن به سه testimonial نیاز دارد اما هیچ‌کدام وجود ندارد، مشکل از محصول و محتواست، نه دلیلی برای ساختن filler بصری. empty state صادقانه و نمونه‌ی دارای برچسب از قطعیت بی‌پشتوانه قوی‌تر است.

Components should encode meaning

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.

کامپوننت قابل‌استفاده مجدد زمانی ارزشمند است که قواعد معنایی و رفتاری را حفظ کند. کارت پروژه فقط تصویر کنار عنوان نیست؛ می‌تواند heading واقعی، مقصد واحد، زبان وضعیت، ابعاد تصویر، رفتار focus و metadata منسجم را تضمین کند. این قرارداد، reuse را از کپی‌کردن 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.

داده محتوا را فقط جایی از presentation جدا کنید که تکرار را کاهش می‌دهد. از سیستم‌های انتزاعی که همه صفحات را به یک ریتم مجبور می‌کنند دوری کنید. مجموعه‌ای کوچک از primitiveهای قوی—section، stack، cluster، grid، media، heading و action—معمولاً از ده‌ها کامپوننت محدود، دامنه طراحی بیشتری می‌سازد.

Responsive design is editorial prioritization

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.

موبایل نسخه فشرده‌ی دسکتاپ در یک ستون نیست. در هر breakpoint تصمیم بگیرید چه چیزهایی باید کنار هم بمانند، چه چیزهایی stack شوند، چه چیزهایی به disclosure تبدیل شوند و چه چیزی در فضای محدود ارزش کمتری دارد. عنوان بلند فارسی، label کوتاه انگلیسی، اعداد واقعی، داده خالی و پیام خطا را تست کنید؛ نه فقط placeholder ایده‌آل.

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.

تایپوگرافی، عرض container و فاصله‌ها بهتر است تا جای ممکن پیوسته واکنش نشان دهند. breakpoint برای تغییر ساختاری است، نه ترمیم هر خط نامناسب. container query، logical property، intrinsic sizing و fluid type تعداد استثناهای شکننده را کم می‌کنند و رفتار RTL و LTR را هم‌راستا نگه می‌دارند.

Ship the page as a hypothesis

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.

رابط حرفه‌ای همچنان به نتیجه‌ای قابل‌مشاهده نیاز دارد. پیش از انتشار مشخص کنید موفقیت یعنی چه: درک بهتر، تکمیل فرایند، درخواست واجدشرایط، زمان انجام کار، خطای کمتر یا کاهش فشار پشتیبانی. معیار اصلی را با guardrailهایی مثل دسترس‌پذیری، performance، نرخ خطا و اعتماد کاربر همراه کنید.

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.

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

• One explicit user decision per page
• Evidence ordered by the questions users ask
• Components preserve semantics and interaction
• Success and guardrail metrics are defined