https://virgool.ir/feed/@mohammadalamnejadطراح UI/UX و توسعه‌دهنده، بنیان‌گذار آرکا استودیو. سازندهٔ نبضا (پلتفرم عملیات کافه و رستوران)، آونیا و ردپا. دربارهٔ طراحی محصول فارسی، نرم‌افزار و امنیت می‌نویسم.fa2026-11-10 19:40:37https://files.virgool.ir/upload/users/4956584/avatar/OgSBXT.jpghttps://virgool.ir/@mohammadalamnejadhttps://virgool.ir/@mohammadalamnejad/درس-هایی-از-کار-روی-محصولات-بزرگ-ایرانی-برای-طراحی-و-فرانت-اند-سیستم-طراحی-سرعت-تایپوگرافی-فارسی-و-دسترس-پذیری-jipeurigimk9خلاصه در چند خط (نکته‌های کلیدی)در مقیاس بزرگ، ثبات از خلاقیت مهم‌تر است. سیستم طراحی یعنی یک تصمیم یک‌بار گرفته شود و صدها بار درست تکرار شود.توکن‌ها زبان مشترک طراح و برنامه‌نویس‌اند. رنگ، فاصله و اندازهٔ متن باید نام معنایی داشته باشند، نه کد هگز و عدد پیکسل.سرعت را روی گوشی متوسط و اینترنت ناپایدار بسنجید، نه روی لپ‌تاپ تیم. فونت فارسی و تصویر معمولاً بزرگ‌ترین بار صفحه‌اند.تایپوگرافی فارسی قواعد خودش را دارد: فاصلهٔ خطوط بیشتر، بدون فاصله‌گذاری حروف، نیم‌فاصلهٔ درست، و فونتی که اعداد و حروف لاتین را هم خوب نشان دهد.دسترس‌پذیری لوکس نیست؛ کنتراست کافی، فوکوس دیدنی، برچسب فارسی برای صفحه‌خوان و هدف لمسی بزرگ، برای همه کاربردی است.بیشتر مشکلات محصول بزرگ، مشکل ارتباط است نه کد. نام‌گذاری مشترک، تحویل دقیق طراحی و بازبینی دوطرفه از دوباره‌کاری جلوگیری می‌کند.من محمدرضا علم‌نژاد هستم؛ طراح و توسعه‌دهندهٔ UI/UX، برنامه‌نویس و بنیان‌گذار آرکا استودیو. پیش از راه‌اندازی استودیو، روی چند محصول بزرگ ایرانی مثل آچاره، فیلیمو، بله و دیجی‌کالا در نقش‌های توسعه‌دهنده، طراح UI/UX، فرانت‌اند و امنیت کار کرده‌ام.می‌خواهم از همین ابتدا یک مرز را روشن کنم: در این نوشته دربارهٔ جزئیات داخلی، کد یا تصمیم‌های هیچ‌کدام از این شرکت‌ها حرف نمی‌زنم و ادعا نمی‌کنم فلان بخش را من ساخته‌ام. آنچه می‌خوانید درس‌های کلی است؛ چیزهایی که کار در محصولاتی با کاربران زیاد، تیم‌های بزرگ و انتظارات بالا به من یاد داد و حالا در محصولات خودمان در آرکا استودیو به کار می‌برم. اگر طراح یا برنامه‌نویس فرانت‌اند هستید و اولین تجربه‌تان در یک محصول بزرگ را شروع کرده‌اید، یا تیم کوچکی دارید که می‌خواهد مثل تیم بزرگ منظم کار کند، این فهرست برای شماست.۱. در مقیاس بزرگ، هیچ تصمیمی «کوچک» نیستدر یک پروژهٔ کوچک، اگر رنگ دکمه در دو صفحه کمی متفاوت باشد، کسی متوجه نمی‌شود. در محصولی با صدها صفحه و ده‌ها نفر که هم‌زمان رویش کار می‌کنند، همین تفاوت کوچک صد بار تکرار می‌شود و نتیجه، محصولی است که «یک‌دست» به نظر نمی‌رسد و کاربر نمی‌داند کدام دکمه مهم‌تر است.اولین درسی که گرفتم این بود که در مقیاس بزرگ، ثبات از خلاقیت تک‌صفحه‌ای مهم‌تر است. صفحه‌ای که «خلاقانه» از الگوی بقیهٔ محصول بیرون می‌زند، معمولاً هزینهٔ یادگیری اضافه برای کاربر و هزینهٔ نگهداری اضافه برای تیم دارد. خلاقیت جایش در طراحی خود الگوهاست، نه در شکستن آن‌ها برای هر صفحه.نتیجهٔ عملی: قبل از طراحی یک صفحهٔ جدید، اول بپرسید «آیا الگوی موجودی برای این کار داریم؟» اگر دارید، از همان استفاده کنید. اگر ندارید، الگوی جدید را طوری طراحی کنید که بقیهٔ تیم هم بتوانند از آن استفاده کنند.۲. سیستم طراحی: از کتابخانهٔ کامپوننت فراترخیلی‌ها سیستم طراحی را با یک فایل فیگما پر از دکمه یکی می‌دانند. در عمل، سیستم طراحی سه لایه دارد و هر سه لازم‌اند:توکن‌ها (Design Tokens): کوچک‌ترین تصمیم‌ها؛ رنگ، فاصله، اندازه و وزن متن، گردی گوشه‌ها، سایه، مدت انیمیشن.کامپوننت‌ها: دکمه، فیلد ورودی، کارت، پنجرهٔ گفت‌وگو، جدول، که از توکن‌ها ساخته می‌شوند.الگوها و قواعد: اینکه کی از پنجرهٔ گفت‌وگو استفاده کنیم و کی از صفحهٔ جدا، پیام خطا چطور نوشته شود، حالت خالی صفحه چه شکلی باشد.توکن‌ها با نام معناییبزرگ‌ترین تغییر ذهنی برای من این بود که رنگ را با نقشش نام‌گذاری کنم، نه با ظاهرش. «آبی ۵۰۰» به برنامه‌نویس نمی‌گوید کجا استفاده‌اش کند؛ «رنگ اقدام اصلی» یا «رنگ متن ثانویه» می‌گوید. وقتی تصمیم بگیرید حالت تاریک اضافه کنید یا رنگ برند عوض شود، توکن معنایی یک‌جا عوض می‌شود و کل محصول دنبالش می‌آید.یک ساختار ساده که در پروژه‌های خودمان هم استفاده می‌کنم:لایهٔ پایه: پالت خام رنگ‌ها و مقیاس فاصله‌ها (مثلاً ۴، ۸، ۱۲، ۱۶، ۲۴، ۳۲).لایهٔ معنایی: «پس‌زمینهٔ سطح»، «متن اصلی»، «مرز»، «خطر»، «موفقیت»، که به لایهٔ پایه اشاره می‌کنند.لایهٔ کامپوننت (در صورت نیاز): «پس‌زمینهٔ دکمهٔ اصلی در حالت فشرده».حالت‌ها را فراموش نکنیدکامپوننتی که فقط حالت عادی‌اش طراحی شده، نیمه‌کاره است. برای هر کامپوننت تعاملی این حالت‌ها را طراحی و پیاده کنید: عادی، رفتن نشانگر روی آن، فوکوس با صفحه‌کلید، فشرده، غیرفعال، در حال بارگذاری و خطا. در محصول بزرگ، حالت‌های فراموش‌شده همان جاهایی‌اند که هر تیم به روش خودش پر می‌کند و ناهماهنگی از آنجا شروع می‌شود.۳. سرعت: محصول را روی گوشی کاربر بسنجید، نه گوشی تیمتیم‌های فنی معمولاً لپ‌تاپ قوی و اینترنت خوب دارند. بخش بزرگی از کاربران ایرانی با گوشی‌های میان‌رده و اینترنت همراهی که کیفیتش در طول روز و از شهری به شهر دیگر فرق می‌کند، از محصول استفاده می‌کنند. صفحه‌ای که در دفتر کار در یک ثانیه باز می‌شود، ممکن است برای کاربر چند برابر طول بکشد.درس‌های عملی:فونت فارسی را سبک کنید. فونت‌های فارسی، به‌خصوص وقتی چند وزن دارند، می‌توانند سنگین باشند. فقط وزن‌هایی را بارگذاری کنید که واقعاً استفاده می‌کنید (معمولاً دو یا سه وزن)، از قالب WOFF2 استفاده کنید و اگر فونت اجازه می‌دهد، فقط نویسه‌های لازم را نگه دارید. با font-display: swap هم متن قبل از رسیدن فونت دیده می‌شود.تصویر بزرگ‌ترین بار صفحه است. تصویر را در اندازهٔ نمایش واقعی و قالب‌های امروزی مثل WebP یا AVIF بفرستید، برای اندازه‌های مختلف صفحه نسخهٔ جدا داشته باشید و تصویرهای پایین صفحه را با تأخیر بارگذاری کنید.اسکلت بارگذاری بهتر از چرخندهٔ بی‌پایان است. نشان‌دادن شکل کلی محتوا قبل از رسیدن داده، حس سرعت را بهتر می‌کند و صفحه هم موقع رسیدن داده بالا و پایین نمی‌پرد.جابه‌جایی صفحه را صفر کنید. وقتی تصویر یا تبلیغی دیر می‌رسد و متن را پایین می‌برد، کاربر روی چیز اشتباه لمس می‌کند. برای هر عنصری که دیر بارگذاری می‌شود، از قبل جا نگه دارید.بودجهٔ سرعت تعیین کنید. یک حد مشخص برای حجم صفحه و زمان نمایش محتوای اصلی بگذارید و در فرایند انتشار بررسی‌اش کنید. بدون عدد مشخص، سرعت هر ماه کمی بدتر می‌شود و هیچ‌کس مسئولش نیست.اینترنت ناپایدار را طراحی کنید. درخواستی که شکست می‌خورد باید پیام روشن و دکمهٔ «تلاش دوباره» داشته باشد، و فرمی که کاربر پر کرده نباید با قطع اتصال پاک شود.۴. تایپوگرافی فارسی: جایی که بیشتر محصولات کم می‌گذارندخط فارسی ساختار متفاوتی از خط لاتین دارد: حروف به هم می‌چسبند، بالا و پایین حروف ارتفاع زیادی دارند و نقطه‌ها بخش مهمی از خوانایی‌اند. قواعدی که از طراحی برای لاتین آمده، همیشه برای فارسی جواب نمی‌دهد.قواعدی که همیشه رعایت می‌کنم:فاصلهٔ خطوط بیشتر. متن فارسی با فاصلهٔ خطوط تنگ، شلوغ و خسته‌کننده می‌شود. برای متن بدنه، فاصلهٔ خطوطی بیشتر از آنچه برای لاتین معمول است در نظر بگیرید و برای عنوان‌ها کمی کمتر.اندازهٔ متن را کوچک نگیرید. بسیاری از فونت‌های فارسی در یک اندازهٔ اسمی، کوچک‌تر از فونت لاتین به چشم می‌آیند. اندازهٔ پایهٔ متن را روی گوشی واقعی امتحان کنید، نه فقط در فایل طراحی.فاصله‌گذاری بین حروف (letter-spacing) ممنوع. در خط پیوسته، فاصلهٔ اضافه بین حروف اتصال‌ها را می‌شکند. برای تأکید از وزن یا اندازه استفاده کنید.کشیدهٔ تزئینی (ـــ) را برای تراز کردن متن استفاده نکنید. هم جست‌وجو را خراب می‌کند و هم در اندازه‌های مختلف صفحه زشت می‌شود.نیم‌فاصله را جدی بگیرید. «می‌شود»، «کتاب‌ها» و «طراحی‌شده» با نیم‌فاصله درست خوانده می‌شوند. هم در متن رابط و هم در ورودی کاربر، نیم‌فاصله را حذف نکنید و مطمئن شوید فونت آن را درست نمایش می‌دهد.فونتی انتخاب کنید که با لاتین و اعداد هم خوب کنار بیاید. رابط فارسی پر از نام‌های لاتین، کدها و اعداد است. فونتی که لاتینش ناهماهنگ است، هر صفحه را شلخته نشان می‌دهد. مجوز استفادهٔ فونت را هم پیش از انتخاب بررسی کنید؛ همهٔ فونت‌های فارسی برای استفادهٔ تجاری رایگان نیستند.چینش متن راست‌چین باشد، نه تمام‌چین. تمام‌چین (justify) در ستون‌های باریک گوشی، فاصله‌های بزرگ و نامنظم بین کلمات می‌سازد.اعداددربارهٔ اعداد یک تصمیم روشن بگیرید و در کل محصول رعایتش کنید: در متن فارسی اعداد فارسی نشان داده شوند، اما در ورودی‌ها هر سه نوع رقم (فارسی، عربی و لاتین) پذیرفته و پیش از ذخیره یکسان شوند. در جدول‌ها و مبالغ، رقم‌هایی با عرض یکسان کمک می‌کند ستون‌ها مرتب بمانند و مقایسه راحت‌تر شود.۵. راست‌به‌چپ: از اول، نه در پایانمحصولی که اول چپ‌به‌راست طراحی شده و بعد «برعکس» شده، همیشه جاهایی را جا می‌اندازد. جهت راست‌به‌چپ باید از اولین فایل طراحی و اولین خط کد پیش‌فرض باشد. چند نکتهٔ کوتاه:آیکون‌های جهت‌دار (بازگشت، بعدی، فلش‌ها) باید برعکس شوند؛ لوگو، عکس، نقشه و آیکون‌هایی مثل پخش ویدیو نه.متن‌های لاتین داخل جملهٔ فارسی (شمارهٔ سفارش، ایمیل، نام برند) باید جدا (ایزوله) شوند تا علامت‌ها جابه‌جا نشوند.فیلدهای شماره تلفن، ایمیل و کد، چپ‌به‌راست باشند ولی برچسبشان راست‌به‌چپ.در CSS به‌جای «چپ» و «راست»، از ویژگی‌های منطقی مثل «شروع» و «پایان» استفاده کنید تا جهت خودکار درست شود.۶. دسترس‌پذیری: برای همه، نه فقط برای عده‌ای خاصدسترس‌پذیری در بسیاری از تیم‌های ایرانی هنوز اولویت پایینی دارد. اما وقتی کاربران محصول از میلیون‌ها نفر با سنین، توانایی‌ها و دستگاه‌های مختلف تشکیل شده‌اند، هر مانع کوچک برای تعداد بسیار زیادی آدم مشکل می‌سازد. و بیشتر اصلاحات دسترس‌پذیری، برای همهٔ کاربران تجربه را بهتر می‌کند.حداقل‌هایی که در هر پروژه بررسی می‌کنم:[ ] کنتراست کافی بین متن و پس‌زمینه، به‌خصوص برای متن خاکستری روی سفید که در طراحی‌های «مینیمال» زیاد دیده می‌شود.[ ] رنگ تنها راه انتقال معنا نیست. خطا فقط با قرمز شدن فیلد نشان داده نشود؛ پیام متنی و آیکون هم داشته باشد.[ ] فوکوس صفحه‌کلید دیده می‌شود. حذف حلقهٔ فوکوس به خاطر زیبایی، کار را برای کاربر صفحه‌کلید غیرممکن می‌کند.[ ] هدف لمسی بزرگ است. دکمه‌ها و پیوندهای روی گوشی باید آن‌قدر بزرگ باشند که با انگشت راحت زده شوند و با فاصلهٔ کافی از هم.[ ] برچسب فارسی برای صفحه‌خوان. دکمه‌ای که فقط آیکون دارد، باید برچسب متنی فارسی داشته باشد؛ و صفحه باید lang="fa" داشته باشد تا صفحه‌خوان زبان را درست تشخیص دهد.[ ] ساختار عنوان‌ها منطقی است. عنوان‌ها برای ساختار صفحه استفاده شوند، نه برای بزرگ‌کردن متن.[ ] انیمیشن قابل کاهش است. برای کاربرانی که تنظیم «کاهش حرکت» را فعال کرده‌اند، انیمیشن‌های بزرگ حذف یا کم شوند.[ ] فرم‌ها برچسب واقعی دارند. متن راهنمای داخل فیلد (placeholder) با شروع تایپ ناپدید می‌شود و جایگزین برچسب نیست.۷. همکاری: بیشتر مشکلات، مشکل ارتباط استدر تیم‌های بزرگ دیدم که بسیاری از اشکالات و دوباره‌کاری‌ها از کد بد نمی‌آیند؛ از اینکه طراح و برنامه‌نویس و مدیر محصول یک چیز را با سه اسم صدا می‌زنند، یا طراحی بدون حالت‌های خطا و خالی تحویل داده می‌شود و برنامه‌نویس مجبور است حدس بزند.عادت‌هایی که کار را ساده‌تر می‌کند:واژه‌نامهٔ مشترک. نام کامپوننت‌ها، توکن‌ها و مفاهیم محصول در فایل طراحی و کد یکی باشد. اگر در فیگما «کارت محصول» است، در کد هم همان باشد.تحویل کامل طراحی. هر صفحه با همهٔ حالت‌ها تحویل داده شود: بارگذاری، خالی، خطا، دادهٔ خیلی طولانی، و نسخه‌های اندازه‌های مختلف صفحه.متن واقعی، نه متن نمونه. طراحی با متن نمونهٔ کوتاه زیباست؛ با نام واقعی محصولی که سه خط است می‌شکند. در طراحی از متن و دادهٔ واقعی فارسی استفاده کنید.بازبینی دوطرفه. برنامه‌نویس طراحی را پیش از شروع بازبینی کند و طراح پیاده‌سازی را پیش از انتشار. این دو بازبینی کوتاه، از هفته‌ها اصلاح بعدی جلوگیری می‌کند.انتشار تدریجی. تغییرات بزرگ رابط را با امکان روشن و خاموش‌کردن منتشر کنید تا اگر مشکلی پیش آمد، بدون انتشار دوباره بشود برگشت.تصمیم‌ها را بنویسید. چرا این الگو انتخاب شد و آن یکی نه؟ چند ماه بعد که کسی می‌خواهد تغییرش دهد، این توضیح کوتاه بحث تکراری را حذف می‌کند.۸. نگاه امنیتی در فرانت‌اندتجربهٔ کار امنیتی کنار کار طراحی و فرانت‌اند، یک عادت مهم به من داد: فرانت‌اند را هیچ‌وقت مرز امنیت ندانم. هر چیزی که در مرورگر است، در دسترس کاربر است.مخفی‌کردن دکمه یا ستون برای نقشی که نباید ببیند، کافی نیست؛ داده نباید اصلاً در پاسخ سرور باشد.کلیدها و رمزهای سرویس‌های بیرونی هرگز در کد سمت مرورگر قرار نگیرند.اعتبارسنجی فرم در مرورگر برای تجربهٔ کاربری است؛ اعتبارسنجی واقعی در سرور تکرار شود.محتوایی که از کاربر می‌آید، پیش از نمایش امن شود تا کد مخرب اجرا نشود.پیام‌های خطا اطلاعات فنی داخلی را به کاربر نشان ندهند.۹. چک‌لیست کوتاه برای تیم‌های کوچک که می‌خواهند مثل تیم بزرگ کار کنندآیا توکن‌های رنگ، فاصله و متن با نام معنایی تعریف شده‌اند؟آیا هر کامپوننت همهٔ حالت‌هایش را دارد؟آیا سرعت روی یک گوشی میان‌رده و اینترنت همراه سنجیده شده است؟آیا فونت فارسی فقط با وزن‌های لازم و قالب سبک بارگذاری می‌شود؟آیا فاصلهٔ خطوط، نیم‌فاصله و اعداد فارسی درست رعایت شده‌اند؟آیا راست‌به‌چپ از ابتدا پیش‌فرض بوده و آیکون‌های جهت‌دار بررسی شده‌اند؟آیا کنتراست، فوکوس، اندازهٔ هدف لمسی و برچسب صفحه‌خوان بررسی شده‌اند؟آیا طراحی با متن واقعی و همهٔ حالت‌ها تحویل داده می‌شود؟آیا داده‌های حساس در سرور محدود می‌شوند، نه در ظاهر صفحه؟سخن پایانیبزرگ‌ترین چیزی که کار در محصولات بزرگ به من یاد داد این بود که کیفیت در مقیاس، نتیجهٔ سیستم است نه قهرمان‌بازی. یک طراح یا برنامه‌نویس فوق‌العاده می‌تواند یک صفحهٔ عالی بسازد؛ اما فقط یک سیستم خوب، یعنی توکن‌های روشن، کامپوننت‌های کامل، بودجهٔ سرعت، قواعد تایپوگرافی و ارتباط شفاف، می‌تواند صدها صفحه را عالی نگه دارد. خبر خوب این است که تیم کوچک هم می‌تواند از روز اول همین سیستم را بسازد؛ ساختنش در ابتدا ارزان‌تر از هر زمان دیگری است.دربارهٔ نویسندهمحمدرضا علم‌نژاد (با املای «محمدرضا علم نژاد» هم شناخته می‌شود) برنامه‌نویس و فعال حوزهٔ امنیت شبکه، طراح و توسعه‌دهندهٔ UI/UX و بنیان‌گذار آرکا استودیو، استودیوی طراحی و توسعه در تهران، است. او پیش از این روی محصولات بزرگ ایرانی مانند آچاره، فیلیمو، بله و دیجی‌کالا در نقش‌های توسعه‌دهنده، طراح UI/UX، فرانت‌اند و امنیت کار کرده و امروز سازندهٔ محصولاتی مانند نبضا، آونیا، نچریو و ردپا است. او در دانشگاه صنعتی شریف و دانشگاه علم و صنعت ایران در رشتهٔ کامپیوتر و فناوری اطلاعات تحصیل کرده است.محمدرضا علم نژادمحمدرضا علم نژادWed, 14 Oct 2026 06:48:58 +0330https://virgool.ir/@mohammadalamnejad/امنیت-وب-برای-کسب-وکارهای-کوچک-ایرانی-چک-لیستی-عملی-برای-ورود-کد-پیامکی-پشتیبان-و-پنل-مدیریت-plfag6un8dqbخلاصه در چند خط (نکته‌های کلیدی)بیشتر حمله‌ها به کسب‌وکارهای کوچک هدفمند نیستند؛ خودکارند. ربات‌ها دنبال رمز ضعیف، افزونهٔ قدیمی و پنل مدیریت بی‌محافظ می‌گردند، نه دنبال اسم شما.کد پیامکی (OTP) باید کوتاه‌عمر، یک‌بارمصرف و محدود به تعداد تلاش باشد. صفحهٔ ارسال کد بدون محدودیت، هم حساب‌ها را در خطر می‌گذارد و هم شارژ پنل پیامکی را می‌سوزاند.پنل مدیریت را از اینترنت عمومی پنهان کنید یا حداقل دو مرحله‌ای‌اش کنید. هر کارمند حساب خودش را داشته باشد و حساب مشترک ممنوع.پشتیبانی که بازیابی‌اش را امتحان نکرده‌اید، پشتیبان نیست. حداقل یک نسخه باید بیرون از همان سرور و همان حساب هاست باشد.مبلغ و نتیجهٔ پرداخت را همیشه سمت سرور با درگاه بررسی کنید، نه از روی آدرس بازگشت یا چیزی که مرورگر می‌فرستد.امنیت یک‌بار انجام نمی‌شود؛ یک عادت ماهانه است. یک ساعت در ماه برای به‌روزرسانی، بررسی دسترسی‌ها و تست بازیابی، از بیشتر حادثه‌ها جلوگیری می‌کند.من محمدرضا علم‌نژاد هستم؛ برنامه‌نویس و فعال حوزهٔ امنیت شبکه، طراح و توسعه‌دهندهٔ UI/UX و بنیان‌گذار آرکا استودیو. در کار طراحی و توسعه، مدام با کسب‌وکارهای کوچکی روبه‌رو می‌شوم که وب‌سایت یا فروشگاه اینترنتی دارند ولی تیم فنی ندارند: یک کافه با منوی آنلاین، یک فروشگاه پوشاک با چند صد محصول، یک آموزشگاه با فرم ثبت‌نام. برای این کسب‌وکارها «امنیت» معمولاً یا کلمه‌ای ترسناک و گران است یا چیزی که «بعداً» به آن رسیدگی می‌شود.این نوشته تلاشی است برای اینکه امنیت را از حالت مبهم بیرون بیاورم و به چند تصمیم مشخص تبدیل کنم. هدفم این نیست که شما متخصص امنیت شوید؛ هدف این است که بدانید کدام سؤال‌ها را از خودتان، از برنامه‌نویستان و از شرکت هاستینگ بپرسید. این متن گزارش یک حادثهٔ خاص یا ممیزی یک سایت مشخص نیست؛ جمع‌بندی اصولی است که در هر پروژه‌ای اول بررسی می‌کنم.۱. اول بدانید از چه چیزی محافظت می‌کنیدقبل از هر ابزاری، پنج دقیقه وقت بگذارید و فهرست کنید چه چیزی اگر از دست برود، کسب‌وکارتان آسیب می‌بیند. برای بیشتر کسب‌وکارهای کوچک این فهرست تقریباً یکی است:اطلاعات مشتری: شمارهٔ موبایل، نشانی، سابقهٔ خرید. نشت این‌ها هم اعتماد مشتری را از بین می‌برد و هم می‌تواند به کلاهبرداری از همان مشتری‌ها با نام شما منجر شود.پول: درگاه پرداخت، کیف پول مشتری، کد تخفیف، و هر جایی که مبلغ تعیین می‌شود.دسترسی به پنل مدیریت: کسی که وارد پنل شود، می‌تواند قیمت عوض کند، سفارش جعلی بسازد یا کل سایت را پاک کند.دامنه و حساب‌های زیرساختی: حساب ثبت دامنه، پنل هاست، پنل پیامکی، ایمیل سازمانی. این‌ها کلید همهٔ قفل‌های دیگرند.خود داده‌ها و فایل‌ها: محصولات، عکس‌ها، محتوایی که سال‌ها برایش وقت گذاشته‌اید.نکتهٔ مهم این است که بیشتر حمله‌ها به کسب‌وکارهای کوچک شخصی نیستند. ربات‌ها هر روز هزاران سایت را برای رمزهای رایج، نسخه‌های قدیمی افزونه‌ها و مسیرهای شناخته‌شدهٔ پنل مدیریت اسکن می‌کنند. یعنی «سایت من کوچک است، کسی کاری با آن ندارد» استدلال درستی نیست. کوچک‌بودن فقط یعنی کسی متوجه نفوذ نمی‌شود.۲. ورود و رمز عبور: ساده‌ترین جای شکسترایج‌ترین مشکلی که می‌بینم فنی نیست، عادتی است: رمز مشترک بین چند نفر، رمزی که در گروه پیام‌رسان فرستاده شده، یا رمزی که برای پنل هاست و ایمیل و پنل سایت یکی است.چک‌لیست ورود:☐ هر نفر حساب خودش را دارد. حساب مشترک «admin» که سه نفر رمزش را می‌دانند، یعنی هیچ‌وقت نمی‌فهمید چه کسی چه کاری کرده است.☐ رمزها طولانی و یکتا هستند و در یک مدیر رمز عبور نگهداری می‌شوند، نه در یادداشت گوشی یا پیام ذخیره‌شده.☐ برای حساب‌های حیاتی (دامنه، هاست، ایمیل، پنل مدیریت سایت، پنل پیامکی) ورود دومرحله‌ای فعال است.☐ تعداد تلاش ناموفق ورود محدود است و بعد از چند تلاش، تأخیر یا قفل موقت اعمال می‌شود.☐ پیام خطای ورود نمی‌گوید «این کاربر وجود ندارد» یا «رمز اشتباه است»؛ فقط می‌گوید «اطلاعات ورود درست نیست». پیام دقیق به مهاجم می‌گوید کدام نام کاربری واقعی است.☐ وقتی کسی از تیم جدا می‌شود، همان روز حسابش غیرفعال و رمزهای مشترک (اگر هنوز هست) عوض می‌شوند.☐ نشست‌ها (session) بعد از مدتی بی‌فعالیتی منقضی می‌شوند و با تغییر رمز، همهٔ نشست‌های قبلی باطل می‌شوند.یک آزمون ساده: اگر امروز یکی از کارمندانتان با گوشی‌اش گم شود، آیا می‌توانید در ده دقیقه همهٔ دسترسی‌هایش را قطع کنید؟ اگر جواب «نمی‌دانم» است، از همین بخش شروع کنید.۳. کد پیامکی (OTP): راحت برای کاربر، خطرناک اگر بی‌قاعده باشددر ایران ورود با شمارهٔ موبایل و کد پیامکی تقریباً استاندارد شده و از نظر تجربهٔ کاربری انتخاب خوبی است. اما صفحهٔ «ارسال کد» یکی از پرخطرترین بخش‌های هر سایت است، چون هم به حساب کاربر راه دارد و هم مستقیماً از جیب شما پول خرج می‌کند.خطرهای رایج:حدس‌زدن کد. کد چهار یا پنج رقمی اگر بی‌نهایت بار قابل امتحان باشد، با یک اسکریپت ساده در زمان کوتاهی پیدا می‌شود.سوزاندن شارژ پنل پیامکی. رباتی که هزار بار دکمهٔ «ارسال دوبارهٔ کد» را برای شماره‌های مختلف بزند، هم شارژ را تمام می‌کند و هم ممکن است خط ارسال شما به خاطر پیام انبوه مسدود شود.کلید پنل پیامکی در کد سمت مرورگر. اگر سایت پیامک را مستقیم از مرورگر کاربر به سرویس پیامکی می‌فرستد، کلید API در دسترس همه است.کدی که بعد از استفاده هم معتبر می‌ماند یا ساعت‌ها عمر دارد.چک‌لیست OTP:☐ کد فقط در سرور ساخته و بررسی می‌شود و کلید پنل پیامکی هرگز به مرورگر نمی‌رسد.☐ عمر کد کوتاه است (چند دقیقه) و بعد از یک‌بار استفادهٔ موفق باطل می‌شود.☐ برای هر کد تعداد تلاش محدود است؛ بعد از چند بار اشتباه، کد باطل می‌شود و باید کد جدید گرفت.☐ ارسال کد هم برای هر شماره و هم برای هر آی‌پی محدودیت دارد (مثلاً یک کد در هر دقیقه و چند کد در هر ساعت).☐ کد به‌صورت خام در پایگاه داده ذخیره نمی‌شود؛ مثل رمز عبور، نسخهٔ درهم‌شده (hash) نگهداری می‌شود.☐ متن پیامک فقط کد و نام کسب‌وکار را دارد و صریحاً می‌گوید «این کد را به هیچ‌کس ندهید». کلاهبرداری‌های تلفنی معمولاً با گرفتن همین کد کار می‌کنند.☐ پاسخ صفحهٔ ارسال کد برای شمارهٔ ثبت‌شده و ثبت‌نشده یکسان است تا نشود فهمید چه کسی مشتری شماست.☐ برای عملیات حساس (تغییر شمارهٔ موبایل، برداشت از کیف پول، تغییر نشانی تحویل) کد جداگانه خواسته می‌شود، نه همان نشست ورود.اگر سایتتان را با یک افزونهٔ آماده ساخته‌اید، این موارد را از برنامه‌نویس یا پشتیبان افزونه بپرسید. افزونه‌ای که «محدودیت ارسال» و «انقضای کد» را قابل تنظیم نکرده، انتخاب خوبی نیست.۴. پنل مدیریت: دری که نباید رو به خیابان باز باشدپنل مدیریت قدرتمندترین بخش سایت است و معمولاً در آدرسی قرار دارد که همه می‌دانند. ربات‌ها اول سراغ همین مسیرهای شناخته‌شده می‌روند.چک‌لیست پنل مدیریت:☐ ورود دومرحله‌ای برای همهٔ حساب‌های مدیر فعال است، بدون استثنا.☐ اگر ممکن است، دسترسی به پنل محدود به آی‌پی ثابت دفتر یا یک VPN سازمانی است. حتی محدودیت ساده در سطح وب‌سرور، بخش بزرگی از اسکن‌های خودکار را بی‌اثر می‌کند.☐ هر کس فقط دسترسی لازم برای کار خودش را دارد. کسی که فقط سفارش‌ها را پیگیری می‌کند، نباید بتواند افزونه نصب کند یا کاربر جدید بسازد.☐ تعداد مدیران کامل (کسانی که همه‌کار می‌توانند بکنند) به حداقل رسیده است؛ معمولاً یک یا دو نفر کافی است.☐ فهرست کاربران مدیر هر ماه بازبینی می‌شود. حساب‌های فراموش‌شدهٔ برنامه‌نویس قبلی یا کارمند سابق، رایج‌ترین درِ باز هستند.☐ تغییرات مهم (قیمت، موجودی، کاربران، تنظیمات پرداخت) در سابقه ثبت می‌شوند: چه کسی، چه زمانی، چه چیزی را از چه به چه تغییر داد.☐ آپلود فایل در پنل محدود به نوع‌های لازم است و فایل از روی محتوا بررسی می‌شود، نه فقط از روی پسوند.دربارهٔ «پنهان‌کردن» هم یک نکته: اگر به کارمندی نباید عدد سود یا اطلاعات مالی را نشان دهید، پنهان‌کردن آن در ظاهر صفحه کافی نیست. اگر عدد در پاسخ سرور باشد، با باز کردن ابزار توسعه‌دهندهٔ مرورگر دیده می‌شود. محدودیت دسترسی باید در سرور اعمال شود.۵. وردپرس، افزونه‌ها و قالب‌های «رایگان‌شده»بخش بزرگی از سایت‌های کسب‌وکارهای کوچک ایرانی روی وردپرس و ووکامرس ساخته شده‌اند. وردپرس به‌خودی‌خود ناامن نیست؛ مشکل معمولاً در افزونه‌ها و قالب‌هاست.نسخهٔ نال‌شده (کرک‌شده) استفاده نکنید. قالب یا افزونهٔ پولی که از منبع غیررسمی و رایگان دانلود شده، ممکن است کد مخفی داشته باشد که بعدها برای تزریق لینک، سرقت اطلاعات یا ساخت حساب مدیر استفاده شود. صرفه‌جویی در خرید یک افزونه ارزش این ریسک را ندارد.افزونه‌های بلااستفاده را حذف کنید، نه فقط غیرفعال. کد غیرفعال هم روی سرور است و گاهی قابل سوءاستفاده.به‌روزرسانی را برنامه‌ریزی کنید. هستهٔ وردپرس، افزونه‌ها و قالب را مرتب به‌روز کنید، ولی قبلش پشتیبان بگیرید و اگر می‌توانید اول روی نسخهٔ آزمایشی امتحان کنید.افزونه‌ای را انتخاب کنید که زنده است. افزونه‌ای که مدت‌هاست به‌روزرسانی نشده، احتمالاً مشکلات امنیتی‌اش هم رفع نمی‌شود.افزونهٔ امنیتی جایگزین عادت خوب نیست. دیوارهٔ آتش و اسکنر مفیدند، ولی اگر رمز مدیر ضعیف باشد یا پشتیبان نداشته باشید، کمک زیادی نمی‌کنند.۶. پرداخت: هرگز به مرورگر اعتماد نکنیددر فروشگاه اینترنتی، مسیر پرداخت معمولاً این است: کاربر به درگاه بانکی منتقل می‌شود، پرداخت می‌کند و به سایت برمی‌گردد. خطای خطرناک وقتی رخ می‌دهد که سایت فقط از روی بازگشت کاربر یا پارامترهای آدرس نتیجه بگیرد پرداخت موفق بوده است.چک‌لیست پرداخت:☐ بعد از بازگشت از درگاه، سرور سایت با سرویس تأیید درگاه (verify) نتیجهٔ تراکنش را مستقیماً استعلام می‌کند.☐ مبلغ تأییدشده با مبلغ سفارش در پایگاه داده مقایسه می‌شود، نه با مبلغی که در فرم یا آدرس آمده است.☐ هر تراکنش فقط یک‌بار به سفارش موفق تبدیل می‌شود. اگر کاربر صفحهٔ بازگشت را رفرش کند، نباید دو سفارش یا دو شارژ کیف پول ثبت شود.☐ قیمت، تخفیف و هزینهٔ ارسال در سرور محاسبه می‌شوند. هر عددی که از مرورگر می‌آید قابل دستکاری است.☐ کد تخفیف محدودیت استفاده و تاریخ انقضا دارد و استفادهٔ هم‌زمان چندباره از آن جلوگیری می‌شود.☐ اطلاعات کارت بانکی هیچ‌وقت در سایت شما وارد یا ذخیره نمی‌شود؛ این کار درگاه است.۷. پشتیبان‌گیری: بیمه‌ای که فقط با تست بازیابی کار می‌کندبدترین روز هر کسب‌وکار اینترنتی روزی است که سایت از دست برود و معلوم شود پشتیبان یا وجود ندارد یا خراب است یا روی همان سروری بوده که از دست رفته.چک‌لیست پشتیبان:☐ هم پایگاه داده و هم فایل‌ها (عکس محصولات، آپلودها) پشتیبان دارند. پشتیبان فقط از پایگاه داده، سایت را برنمی‌گرداند.☐ پشتیبان خودکار و منظم است (روزانه برای فروشگاه‌های فعال) و قبل از هر به‌روزرسانی بزرگ هم یک نسخهٔ دستی گرفته می‌شود.☐ حداقل یک نسخه بیرون از همان سرور و ترجیحاً بیرون از همان حساب هاستینگ نگهداری می‌شود. اگر حساب هاست از دست برود، پشتیبان داخلش هم از دست رفته است.☐ پشتیبان‌ها رمزگذاری شده‌اند، چون شامل اطلاعات مشتری هستند.☐ چند نسخهٔ قدیمی‌تر هم نگه داشته می‌شود. اگر نفوذ چند روز بعد کشف شود، پشتیبان دیروز هم آلوده است.☐ حداقل هر چند ماه یک‌بار، بازیابی واقعی امتحان می‌شود: پشتیبان را روی یک محیط جدا بالا بیاورید و ببینید سایت کامل کار می‌کند.جملهٔ کلیدی این بخش همان است که در خلاصه گفتم: پشتیبانی که بازیابی‌اش را امتحان نکرده‌اید، فقط یک فایل امیدوارکننده است.۸. دامنه، هاست و ایمیل: کلیدهای اصلیکسی که حساب ثبت دامنهٔ شما را در اختیار بگیرد، می‌تواند کل سایت و ایمیلتان را به جای دیگری هدایت کند. با این حال این حساب‌ها معمولاً کمترین توجه را می‌گیرند.☐ دامنه به نام خود کسب‌وکار یا صاحب آن ثبت شده است، نه به نام برنامه‌نویس یا شرکت طراحی سایت.☐ ایمیل بازیابی حساب دامنه و هاست، ایمیلی است که در اختیار خود شماست و فعال است.☐ تاریخ تمدید دامنه یادآوری دارد. دامنه‌ای که منقضی شود ممکن است دست دیگری بیفتد.☐ برای ایمیل سازمانی رکوردهای SPF، DKIM و DMARC تنظیم شده‌اند تا جعل ایمیل به نام شما سخت‌تر شود.☐ گواهی HTTPS فعال است و به‌صورت خودکار تمدید می‌شود و همهٔ صفحه‌ها، به‌خصوص ورود و پرداخت، فقط روی HTTPS باز می‌شوند.۹. اشتباه‌های رایجی که بارها تکرار می‌شونداین فهرست از الگوهای کلی آمده، نه از یک پروژهٔ خاص. اگر حتی یکی از این‌ها را در کسب‌وکارتان می‌بینید، اولویت را به همان بدهید:فرستادن رمز در پیام‌رسان. پیام‌ها روی چند دستگاه همگام می‌شوند و سال‌ها می‌مانند.برنامه‌نویسی که پروژه را تحویل داده ولی هنوز دسترسی کامل دارد. بعد از تحویل، دسترسی‌ها را به حداقل برسانید یا عوض کنید.فایل پشتیبان قابل دانلود در پوشهٔ عمومی سایت. فایل‌هایی با نام‌های قابل حدس مثل backup یا نسخهٔ zip سایت، اغلب توسط ربات‌ها پیدا می‌شوند.صفحه‌های خطایی که جزئیات فنی نشان می‌دهند. پیام خطای پایگاه داده یا مسیر فایل‌ها روی صفحه، نقشهٔ راه مهاجم است.فرم تماس یا ثبت‌نام بدون محدودیت. هم اسپم می‌آورد و هم می‌تواند برای حمله به سرویس‌های دیگر (مثلاً ارسال پیامک) استفاده شود.اعتماد به قیمت و مبلغی که از مرورگر می‌آید.نبود هیچ سابقه‌ای از تغییرات. وقتی عددی اشتباه است، کسی نمی‌داند از کجا آمده و همه به هم شک می‌کنند.۱۰. برنامهٔ یک‌ساعتهٔ ماهانهامنیت برای کسب‌وکار کوچک باید آن‌قدر ساده باشد که واقعاً انجام شود. پیشنهاد من یک جلسهٔ یک‌ساعته در ماه است، با همین ترتیب:ده دقیقه: به‌روزرسانی هسته، افزونه‌ها و قالب (بعد از گرفتن پشتیبان).ده دقیقه: بازبینی فهرست کاربران پنل مدیریت، هاست و پنل پیامکی؛ حذف حساب‌های اضافه.ده دقیقه: بررسی اینکه پشتیبان دیروز وجود دارد، کامل است و یک نسخه بیرون از سرور هست.ده دقیقه: نگاه به سابقهٔ ورودهای ناموفق، مصرف غیرعادی پیامک و سفارش‌های عجیب.ده دقیقه: امتحان یک سناریوی ساده؛ مثلاً با حساب کارمند عادی وارد شوید و ببینید به چیزی که نباید، دسترسی دارید یا نه.ده دقیقه: هر چند ماه یک‌بار، به‌جای این مورد، بازیابی کامل پشتیبان را روی محیط جدا امتحان کنید.این برنامه شما را در برابر هر حمله‌ای مصون نمی‌کند، اما بیشتر چیزهایی را که ربات‌ها و حمله‌های خودکار دنبالش هستند از دسترس خارج می‌کند. و از آن مهم‌تر، اگر روزی اتفاقی بیفتد، می‌دانید از کجا شروع کنید.سخن پایانیکسب‌وکار کوچک نیاز به تیم امنیت ندارد؛ نیاز به چند عادت درست دارد. هر حساب برای یک نفر، کد پیامکی کوتاه‌عمر و محدود، پنل مدیریت دومرحله‌ای، پرداختی که در سرور تأیید می‌شود و پشتیبانی که بازیابی‌اش را دیده‌اید. اگر فقط همین پنج کار را انجام دهید، از بخش بزرگی از کسب‌وکارهای هم‌اندازه‌تان امن‌تر هستید.دربارهٔ نویسندهمحمدرضا علم‌نژاد (که گاهی «محمدرضا علم نژاد» هم نوشته می‌شود) برنامه‌نویس و فعال حوزهٔ امنیت شبکه، طراح و توسعه‌دهندهٔ UI/UX و بنیان‌گذار آرکا استودیو، استودیوی طراحی و توسعه در تهران، است. او سازندهٔ نبضا، پلتفرم عملیات کافه و رستوران، و محصولاتی مانند آونیا، نچریو و ردپا است. در دانشگاه صنعتی شریف و دانشگاه علم و صنعت ایران در رشتهٔ کامپیوتر و فناوری اطلاعات تحصیل کرده و پیش از این روی محصولات بزرگ ایرانی مانند آچاره، فیلیمو، بله و دیجی‌کالا در نقش‌های توسعه‌دهنده، طراح UI/UX، فرانت‌اند و امنیت کار کرده است.محمدرضا علم نژادمحمدرضا علم نژادWed, 14 Oct 2026 03:54:12 +0330https://virgool.ir/@mohammadalamnejad/چطور-برای-یک-پلتفرم-عملیات-کافه-و-رستوران-ux-طراحی-کنیم-که-در-شلوغی-صندوق-و-آشپزخانه-کار-کند-rnrwcrbgmphzخلاصه در چند خط (نکته‌های کلیدی)مسئلهٔ اصلی UX در کافه و رستوران «شلوغی» است، نه زیبایی. هر صفحه باید وقتی صف جلوی صندوق است، با یک دست و بدون فکرکردن کار کند.هر نقش باید صفحهٔ خودش را داشته باشد: باریستا صندوق را می‌بیند، سرآشپز رسپی را، مالک سود را؛ و پنهان‌کردن داده باید در سرور انجام شود، نه فقط در ظاهر صفحه.زمان و پول باید محلی باشند: تاریخ شمسی، ساعت تهران، مبلغ به ریال دقیق، و «روز کاری» از ساعت شروع همان شعبه حساب شود نه از نیمه‌شب.فیش باید با واقعیت چاپگر جور باشد: رول حرارتی ۸۰ و ۵۸ میلی‌متری، به اندازهٔ محتوا، و فیش آشپزخانه فقط یک‌بار چاپ شود.دوبار کلیک‌کردن نباید دو فروش بسازد. در محیط شلوغ، مقاومت در برابر ثبت تکراری بخشی از UX است، نه فقط مسئلهٔ فنی.رابط باید صادق باشد: جایی که داده نیست، «نامعلوم» نشان بدهد نه صفر؛ و آنچه هنوز ساخته نشده را صریح بگوید.من محمدرضا علم‌نژاد هستم، طراح UI/UX و توسعه‌دهنده. در چند وقت اخیر در آرکا استودیو روی نبضا کار کرده‌ام؛ پلتفرمی برای عملیات کافه و رستوران که صندوق و فروش، منوی QR و سفارش، آشپزخانه، انبار، رسپی و بهای تمام‌شده و کار تیم را یک‌جا جمع می‌کند. نبضا هنوز در مرحلهٔ پایلوت است، پس این نوشته گزارش موفقیت یا آمار نیست. این‌ها تصمیم‌های طراحی‌ای است که در مسیر ساختنش گرفتم و فکر می‌کنم برای هر کسی که نرم‌افزار «محیط شلوغ» طراحی می‌کند به درد می‌خورد: صندوق فروشگاه، داروخانه، کارگاه، یا هر جایی که کاربر وقت خواندن ندارد.۱. اول شلوغی را طراحی کنید، بعد صفحه رابیشتر نرم‌افزارهای مدیریتی در شرایط آرام طراحی می‌شوند: پشت میز، با موس، با یک فنجان چای. ولی صندوق کافه ساعت یک ظهر جای دیگری است. صندوق‌دار هم‌زمان با مشتری حرف می‌زند، به باریستا سفارش را یادآوری می‌کند و پول می‌گیرد. در این شرایط سه چیز برای من معیار شد:کمترین تصمیم در هر قدم. صندوق لمسی نبضا روی تبلت طراحی شده تا فروش با محصولات و گزینه‌ها سریع ثبت شود. هر سؤالی که می‌شود از صفحهٔ صندوق حذف کرد و به تنظیمات مدیر برد، باید برود.عدد نهایی همیشه جلوی چشم. تخفیف درصدی و مالیات پیش از ثبت جلوی چشم صندوق‌دار جمع زده می‌شود. اگر صندوق‌دار مجبور باشد بعد از ثبت بفهمد مبلغ چقدر شد، یعنی رابط شکست خورده است.خطا را سخت کنید، نه کار را. تخفیف در نبضا مجوز، سقف و دلیل دارد و در سابقه می‌ماند. این‌طوری صندوق‌دار برای کار عادی معطل نمی‌شود، اما برای کار غیرعادی یک قدم آگاهانه لازم است.یک قاعدهٔ ساده که به آن رسیدم: اگر کاری روزی صدبار انجام می‌شود، باید با کمترین لمس انجام شود؛ اگر روزی یک‌بار انجام می‌شود و پول جابه‌جا می‌کند، اشکالی ندارد یک قدم تأیید داشته باشد.۲. هر نقش، صفحهٔ خودشدر یک کافهٔ کوچک ممکن است یک نفر هم صندوق‌دار باشد هم باریستا. در یک مجموعهٔ چندشعبه، مالک، مدیر شعبه، سرپرست شیفت، انباردار، سرآشپز و حسابدار هرکدام دنیای متفاوتی دارند. اشتباه رایج این است که همه یک داشبورد بزرگ ببینند و هر کس دنبال تکهٔ خودش بگردد.در نبضا جمله‌ای که راهنمای ما بود این بود: «باریستا صندوق می‌بیند، سرآشپز رسپی، شما سود.» هر نقش فقط همان چیزی را می‌بیند که برای کارش لازم دارد؛ نه کمتر که کارش بماند، نه بیشتر که اطلاعات مجموعه بیرون برود.دو نکتهٔ مهم که از سابقهٔ کار امنیتی‌ام با خودم آوردم:پنهان‌کردن داده باید در پاسخ سرور باشد. در مرکز کنترل مالک، دادهٔ مالی برای کسی که مجوز مالی ندارد در خود پاسخ سرور حذف می‌شود، نه اینکه فقط در ظاهر صفحه مخفی شود. اگر فقط دکمه را پنهان کنید، هر کسی که ابزار توسعه‌دهندهٔ مرورگر را باز کند عدد را می‌بیند.نقش فقط یک اسم نیست. در عملیات حساس مثل انتقال بین انبارها، علاوه بر نقش، شعبه و انبار مقصد هم بررسی می‌شود. کسی نمی‌تواند به خودش مجوز بیشتر بدهد و آخرین مالک مجموعه قابل حذف نیست.از نظر UX، این یعنی منو و صفحهٔ شروع هر کاربر بر اساس نقشش ساخته می‌شود. صفحهٔ اول مالک «اتاق فرمان» است: فروش خالص روز، سفارش‌های باز و هشدارهایی که اقدام می‌خواهند؛ نه صدها عدد بی‌معنی.۳. زبان: فارسی، ساده، و هم‌زبان با خود کافهکاربران نرم‌افزار کافه معمولاً حسابدار یا برنامه‌نویس نیستند. واژه‌هایی مثل «Inventory adjustment» یا حتی ترجمهٔ خشک آن‌ها، برای باریستا معنایی ندارد. در نبضا تلاش کردیم برچسب‌ها فارسی و هم‌زبان با خود کافه باشند: «صندوق»، «فیش»، «رسپی»، «پرس»، «ضایعات»، «شمارش».یک جای کمتر دیده‌شده هم ورود داده است. وقتی کافه‌دار می‌خواهد فهرست مواد اولیه یا تأمین‌کننده‌هایش را از اکسل بیاورد، نبضا نگاشت ستون‌ها را با سرفصل فارسی، پیش‌نمایش و گزارش همهٔ خطاها انجام می‌دهد. اگر کاربر مجبور شود فایلش را به قالب انگلیسی تبدیل کند، همان‌جا از محصول ناامید می‌شود.نکتهٔ عملی برای طراح‌ها: فهرست واژه‌های رابط را با خود کاربران بنویسید، نه با مستندات نرم‌افزارهای خارجی. واژه‌ای که سرپرست شیفت هر روز بلند می‌گوید، بهترین برچسب است.۴. زمان: شمسی، ساعت تهران، و روز کاری واقعینبضا خودش را این‌طور معرفی می‌کند: «فارسی، شمسی، ابری». تاریخ شمسی برای کاربر ایرانی یک قابلیت لوکس نیست، پیش‌فرض است. ولی جزئیات مهم‌تر از خود تقویم است:ساعت تهران، نه ساعت سرور. سرور ممکن است هر جای دنیا باشد. رزرو میز در نبضا با ساعت تهران ثبت می‌شود. هر زمانی که کاربر می‌بیند باید زمانی باشد که روی ساعت دیوار کافه است.روز کاری از نیمه‌شب شروع نمی‌شود. کافه‌ای که تا یک بامداد باز است، فروش ساعت دوازده و نیم شب را جزو «فردا» نمی‌داند. در اتاق فرمان نبضا، روز کاری از ساعت شروع همان شعبه حساب می‌شود. این یک جزئیات فنی کوچک است که اگر رعایت نشود، گزارش پایان روز هر شب غلط است و مدیر به کل گزارش‌ها بی‌اعتماد می‌شود.سررسیدها با تقویم شعبه. مثلاً سررسید سرویس دوره‌ای تجهیزات با تقویم شعبه حساب می‌شود.۵. پول: ریال دقیق و محاسبه‌ای که قابل بازبینی استدر نبضا قیمت‌ها به ریال دقیق ثبت می‌شوند. وقتی پای تخفیف درصدی و مالیات وسط است، گردکردن بی‌دقت در طول یک ماه به اختلافی می‌رسد که کسی نمی‌تواند توضیحش بدهد. دو تصمیم UX که از این مسئله آمد:مالیات روی قیمت منو محاسبه و در گزارش جدا نشان داده می‌شود؛ تخفیف و مالیات روی فیش هم با درصد آمده‌اند تا مشتری و صندوق‌دار بفهمند عدد از کجا آمده.استرداد تأیید و سقف مبلغ پرداختی دارد. صفحهٔ استرداد نباید سریع‌ترین صفحهٔ نرم‌افزار باشد.۶. فیش: با چاپگر واقعی کافه طراحی کنیدبخش بزرگی از تجربهٔ مشتری کافه روی یک تکه کاغذ حرارتی است. رایج‌ترین عرض رول حرارتی در صندوق‌ها ۸۰ و ۵۸ میلی‌متر است و طراحی یک فیش برای هر دو عرض، کار ساده‌ای نیست؛ در ۵۸ میلی‌متر، نام‌های بلند فارسی و ستون مبلغ به‌سرعت با هم تداخل پیدا می‌کنند.اصولی که برای فیش نبضا دنبال کردیم:فیش دقیقاً به اندازهٔ محتوا. بدون کاغذ سفید اضافه در انتها، چون کاغذ هزینه دارد و فیش بلند بی‌دلیل حرفه‌ای به نظر نمی‌رسد.چاپ از مرورگر روی هر چاپگر حرارتی. فیش مشتری و فیش آشپزخانه از طریق مرورگر چاپ می‌شوند. صادقانه بگویم: اتصال مستقیم به چاپگر شبکه بدون مرورگر هنوز ساخته نشده است و این را در پرسش‌های سایت هم نوشته‌ایم.فیش آشپزخانه فقط یک‌بار. چاپ خودکار فیش آشپزخانه طوری طراحی شده که حتی وقتی دو دستگاه باز است، هر فیش یک‌بار چاپ شود. دو فیش برای یک سفارش یعنی دو بشقاب غذا و یک مشتری.۷. دوبار کلیک = یک فروشدر محیط شلوغ، کاربر دکمه را دوبار می‌زند؛ اینترنت لحظه‌ای قطع می‌شود؛ صفحه دیر جواب می‌دهد و صندوق‌دار دوباره امتحان می‌کند. اگر نرم‌افزار در این لحظه دو فروش یا دو پرداخت ثبت کند، کاربر دیگر به هیچ عددی اعتماد نمی‌کند.در نبضا تکمیل‌شدن سفارش «یک‌بار و فقط یک‌بار» به فروش تبدیل می‌شود، حتی با کلیک دوباره. پرداخت تکراری یا بیش از مانده رد می‌شود و درخواست تکراری در شمارش انبار، اصلاحیهٔ دوم نمی‌سازد.حالت آفلاین هم از همین منطق پیروی می‌کند: اگر اینترنت قطع شود، سفارش ساده در دستگاه ذخیره و پس از اتصال دقیقاً یک‌بار ثبت می‌شود. اگر قیمت در این فاصله تغییر کرده باشد، سفارش برای بررسی نگه داشته می‌شود و هرگز بی‌صدا قیمت عوض نمی‌شود. مرزش را هم صریح نوشته‌ایم: حالت آفلاین فقط ثبت سفارش ساده را پوشش می‌دهد؛ فروش نهایی، انبار و پرداخت به اتصال نیاز دارند.از دید طراح، این یعنی وضعیت «در حال ارسال»، «ذخیره در دستگاه» و «ثبت‌شده» باید سه حالت دیداری متفاوت و واضح باشند.۸. آشپزخانه: هر قلم به ایستگاه خودشسفارشی که از صندوق یا منوی QR سر میز می‌آید، معمولاً هم نوشیدنی دارد هم غذا. در نبضا هر کالا به ایستگاهی می‌رود که برایش تعیین شده؛ بار یا آشپزخانه. صفحهٔ ایستگاه (KDS) تمام‌صفحه است، سفارش‌ها را به تفکیک ایستگاه نشان می‌دهد و هشدار تأخیر دارد.برای منوی QR هم یک اصل امنیتی-تجربه‌ای داشتیم: هیچ عددی از گوشی مهمان پذیرفته نمی‌شود. قیمت و تخفیف را سرور حساب می‌کند و QR هر میز قابل ابطال است.۹. «نامعلوم» بهتر از صفر استیکی از مهم‌ترین تصمیم‌های طراحی، صداقت رابط در برابر دادهٔ ناقص است. اگر بهای یک ماده ثبت نشده باشد، بهای تمام‌شده «نامعلوم» نشان داده می‌شود، نه صفر. تا نرخ دستمزد ثبت نشده، هزینهٔ نیروی کار «دادهٔ لازم» است نه صفر. مغایرت انبار بدون دو شمارش معتبر قابل اندازه‌گیری نیست و همین‌طور هم نمایش داده می‌شود.صفر دروغ قشنگی است: گزارش را تمیز نشان می‌دهد و سود را بیشتر از واقعیت. رابطی که «نمی‌دانم» می‌گوید، در بلندمدت اعتماد بیشتری می‌سازد.۱۰. چک‌لیست کوتاه برای طراحی نرم‌افزار محیط شلوغآیا کار پرتکرار با کمترین لمس انجام می‌شود؟آیا عدد نهایی قبل از ثبت جلوی چشم کاربر است؟آیا هر نقش صفحهٔ شروع خودش را دارد و پنهان‌کردن داده در سرور انجام می‌شود؟آیا زمان‌ها به ساعت محلی کاربر و روز کاری واقعی کسب‌وکار است؟آیا فیش روی هر دو عرض رایج کاغذ حرارتی تست شده است؟آیا دوبار کلیک یا قطع اینترنت، رکورد تکراری نمی‌سازد؟آیا رابط جایی که داده ندارد، صادقانه «نامعلوم» می‌گوید؟آیا محدودیت‌های فعلی محصول جایی نوشته شده که کاربر قبل از تصمیم ببیند؟اگر روی محصولی برای کسب‌وکارهای حضوری کار می‌کنید، پیشنهاد می‌کنم یک ساعت شلوغ کنار صندوق بایستید و فقط تماشا کنید. بیشتر تصمیم‌های بالا از همین نگاه ساده به کاربر بیرون می‌آیند.دربارهٔ نویسندهمحمدرضا علم‌نژاد، طراح UI/UX و توسعه‌دهنده، بنیان‌گذار آرکا استودیو است؛ استودیویی برای طراحی و توسعهٔ UI/UX، وب‌اپ و اپلیکیشن. پیش از این، در محصولات بزرگ ایرانی مانند آچاره، فیلیمو، بله و دیجی‌کالا تجربهٔ کار به‌عنوان توسعه‌دهنده، طراح UI/UX، توسعه‌دهندهٔ فرانت‌اند و امنیت داشته است. معرفی کامل او در صفحهٔ بنیان‌گذار آرکا استودیو و نبضا در nabzaapp.ir در دسترس است.محمدرضا علم نژادمحمدرضا علم نژادTue, 13 Oct 2026 05:16:53 +0330