https://virgool.io/feed/@baran.masoumian طراح رابط و تجربه کاربری. عاشق پادکست، سینما و انیمه‌های کلاسیک. علاقه‌مند به یاد گرفتن و یاد دادن. fa 2026-06-18 13:51:29 https://files.virgool.io/upload/users/153731/avatar/L2rdOR.png?height=120&width=120 https://virgool.io/@baran.masoumian https://virgool.io/@baran.masoumian/%DA%86%D8%B1%D8%A7-%D9%86%D8%A8%D8%A7%DB%8C%D8%AF-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%B1%D8%A7-%D8%A8%D8%AF%D9%88%D9%86-%D8%A8%D8%B1%DB%8C%D9%81-brief-%D8%B4%D8%B1%D9%88%D8%B9-%DA%A9%D9%86%DB%8C%D9%85-b2k9gbji2jxa UX UI Design Project Briefدر انتهای پست نمونه یک بریف برای دانلود قرار گرفته.خیلی از پروژه‌های طراحی بدون اینکه به اندازه کافی شفاف باشن و ابهامات رو برطرف کنن شروع میشن.برای مثال کارفرما میگه "میخوام این وبسایت/اپلیکیشن بازطراحی بشه" یا مثلا " یه اپلیکیشن فروشگاهی می‌خوام".موارد خیلی بیشتری هستن که قبل از شروع پروژه باید درموردشون صحبت بشه تا مطمئن بشیم که قراره توی مسیر درستی حرکت می‌کنیم و دیزاینر، ذی‌نفع‌ها، برنامه‌نویس‌ها و همه‌ی افراد مرتبط با محصول دید یکسانی به پروسه‌ای که قراره انجام بشه و اتفاقاتی که قراره بیفته داشته باشن.تهیه بریف (حس می‌کنم ترجمه‌ی خلاصه به طور دقیق منظور رو نمی‌رسونه و از اونجایی که کلمه‌ی بریف بین طراح‌ها رایجه از خود کلمه استفاده می‌کنم) در اینجا به شفاف شدن ابهامات کمک می‌کنه و باعث میشه همه‌ی این افراد بدونن محصول قراره چه روندی رو طی کنه.مزایای داشتن بریفکاهش ابهامدرک عمیق‌تر تیم از ساختار پروژهکمک به کشف شکاف و تفاوت میان نظرات اعضاواضح کردن هرچه‌ بیشتر نقش‌های افرادافزایش سرعت انجام پروژهتسهیل بحث‌ گروهی با شفاف کردن درک اعضا از پروژهساختار یک بریفنام پروژهتاریخ شروع:آخرین به‌روزرسانی:موضوع و پیشینهموضوع پروژه چیست و چه پیشینه‌ای دارد.در صورتی که بخشی از یک پروژه‌ی بزرگتر است در مورد پروژه بزرگتر توضیح دهید.هدفپروژه به دنبال رسیدن به چه هدفی است؟ این هدف چگونه با اهداف شرکت یا تیم مطابقت دارد؟مزایای آن برای کاربران چیست؟مزایای آن برای ذی‌نفعان چیست؟نتایج کلیدی و معیارهای موفقیتپس از اتمام پروژه چگونه میزاین موفقیت آن را اندازه می‌گیرید؟ ( KPI ها ، OKR ها ، معیارهای UX، اهداف شرکت و ...)مخاطب هدف تشریح کنید مخاطب هدف این پروژه چه کسانی هستند؟ (پیوست پرسونا در صورت وجود)سطح دانش عمومی، سن، منطقه جغرافیایی، جنسیت، علایق و...(مشخصا بسته به موضوع پروژه، تنها برخی از موارد بالا درخواست می‌شوند)وظایف اعضای تیم و ذینفعانافراد مرتبط با پروژه چه کسانی هستند؟ چه وظایفی دارند؟ و میزان مشارکت آنها در پروژه چه مقدار است؟تصمیم‌گیرندگان اصلی چه کسانی هستند؟محدوده وظایف طراحمحدوده وظایف شما (طراح) دقیقا چیست و بر روی چه مواردی باید کار کنید؟چه مواردی ممکن است در محدوده وظایف شما قرار بگیرند؟(به عنوان مثال اگر وقت به اندازه کافی وجود داشته باشد، اگر تحقیقات به نتیجه برسند و ...)چه مواردی در محدوده وظایف شما نیست؟(به عنوان مثال محدودیت‌های بخش فنی، CMS و ...)وابستگی‌ها آیا تیم، افراد، فناوری‌های دیگری هم هستند که موفقیت این پروژه به آنها نیز وابسته باشد؟ شرح دهید.ریسک‌هادر حین انجام پروژه چه ریسک‌هایی باید در نظر گرفته شوند؟به عنوان مثال: در صورت عبور از ددلاین چه اتفاقی می‌افتد؟مواردی که باید تحویل داده شونددر پایان انجام کار کارفرما تقاضای تحویل چه مواردی را دارد؟زمانبندیددلاین‌ها، زمان شروع پروژه و زمان‌های تحویل (در صورت تحویل چند مرحله‌ای) را مشخص کنید.نحوه‌ی انجام کارروتین همکاری بین تیم به چه صورت است؟(بازه Sprintها چه مدت است؟ چه کسانی در آن شرکت می‌کنند؟ چه کسی مسئول رسیدگی به جلسات است؟)اعضا از چه ابزاری برای ارتباط با یکدیگر استفاده می‌کنند؟(اسلک؟ اسکایپ؟ ...)روش و ابزار مستندسازی پروژه چیست؟فضای ذخیره‌سازی پروژه کجاست؟ آیا همه به آن دسترسی دارند؟در نهایت در این مطلب لیست جامعی از آیتم‌های یک بریف گفته شد.این وظیفه طراح هست که با شناختی که از کارفرما داره، بریف رو قبل از ارسال شخصی‌سازی کنه تا بهترین نتیجه رو بگیره. برای مثال اگر کارفرمای شما فردی باشه که با اصطلاحات گفته شده آشنایی نداره و زمینه‌ کاریش خیلی متفاوته، با به کار بردن افعال ساده‌تر و حذف اصطلاحات بار شناختی رو براش کمتر کنید.یا اگر بعضی از موارد بالا مشخص هستند، از قرار دادنشون داخل بریف خودداری کنید.ممنون که همراه من بودین!با استفاده از این لینک می‌تونید فایل ورد نمونه بریف رو دانلود کنید:نمونه بریف طراحی رابط و تجربه کاربریمنبع: https://uxdesign.cc/ Baran Masoumian Baran Masoumian Tue, 05 Oct 2021 21:38:47 +0330 https://virgool.io/@baran.masoumian/%D8%AA%D8%B1%D9%81%D9%86%D8%AF%D9%87%D8%A7%DB%8C-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%B1%D8%A7%D8%A8%D8%B7-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%DB%8C-%DB%8C%DA%A9-aff86aqyibi8 نکات ریز طراحی رابط کاربریتوی این مطلب قصد دارم چندتا از تجربه‌‌های عملی خودم در طراحی UI رو با شما به اشتراک بگذارم.این‌ها تجربه‌های کوچیک و نکات ریزی هستن که صرفا فقط موقع کار کردن و تجربه‌ی عملی به دست میان و انقدر جزئی هستن که معمولا در دوره‌ها و مقاله‌های آموزشی بهشون اشاره‌ای نمیشه.اما همین نکات جزئی و کوچیک در کنار هم که جمع میشن، باعث بهتر و منظم‌تر شدن کار میشن.مطمئنا افراد حرفه‌ای و مجرب روش‌ها و سبک کاری خودشون رو دارن. اما تازه‌کارها می‌تونن از این مطلب استفاده کنن و نظم بیشتری به کارشون بدن.پوشه‌بندی یک پروژه UIوقتی که یه پروژه جدید رو شروع میکنم، داخل پوشه‌ای که به اسم اون پروژه میسازم، همون ابتدای کار ۳ تا پوشه میسازم. یکی برای آیکن‌ها، یکی برای تصاویری که داخل اون پروژه استفاده میکنم و یکی هم برای خروجی‌هام (png، jpg، svg و pdf) از اون پروژه.با یه مثال پیش میرم. فرضا پروژه‌ی ما، طراحی رابط کاربری یه سایت، برای یه برند لباس، به اسم Zuha (ژوها) هست.پوشه‌ای اصلی: Zuhaپوشه‌های داخلی: Zuha-Icons، Zuha-Exports و Zuha-Picsبعد از شروع و پیش‌بردن پروژه ممکنه به پوشه‌های داخلی، پوشه‌های Zuha-Graphics برای وقتی که از ایلاستریشن‌ها و المان‌های گرافیکی استفاده میکنم و پوشه‌ی Zuha-Documents در صورتی که داکیومنت‌های مربوط به پروژه روی پلتفرم‌های آنلاین نباشن، نیاز بشه.در نهایت هم بعد از لانچ شدن پروژه، پوشه‌ی Zuha-Test به جمع پوشه‌ها اضافه میشه تا نتایج و عکس‌های تست پروژه رو در اون ذخیره کنم.نحوه پوشه‌بندی یک پروژه یوآینام‌گذاری آرتبردهابرای نام گذاری آرتبردها بهتره که یه فرمت یکسان برای خودتون داشته باشید، تا داخل همه‌ی پروژه‌هاتون یه روش یکسان و هماهنگ برای نام‌گذاری داشته باشید.فرمتی که من برای خودم ساختم به این شکل هست که اول حالت مخفف اسم پروژه رو در حد دو الی سه حرف می‌نویسم. برای مثال ما، میشه مثلا Zu. بعد از اون، بخش کلی‌ای که صفحه بهش مربوط میشه رو مینویسم.برای مثال وقتی دارم صفحات مختلف مربوط به سبد خرید رو دیزاین می‌کنم، کلمه‌ی Basket رو بعد از Zu اضافه می‌کنم. پس تا اینجای کار چی داریم؟ Zu-Basketو این کار رو برای بخش‌های مختلف، که هر کدوم شامل صفحات خودشون هستند انجام میدم.بنابراین در انتهای پروژه ردیف‌هایی از آرتبردها دارم که هر ردیف پیشوند جداگونه داره.Zu-Register، Zu-SearchResult، Zu-Product و ...در آخر هم نوبت میرسه به اسم منحصر به فرد اون صفحه که در این مورد نمیترسم اگر اسمش طولانی بشه.ملاکم اینه که به هدف اصلی اون صفحه اشاره کنم. و نگران نباشید؛ هیچوقت اونقدری که فکرش رو می‌کنید طولانی نمیشن.فرضا اگر دارم داخل یک صفحه، حالت تایپ اینپوت‌ها و حالت هاور و سلکت دکمه‌ها رو نمایش میدم، اسم صفحه میشه این:Zu-Register-InputType/btnHover&Selectنام‌گذاری فایل‌های پروژهمعمولا کم و بیش بین طراح‌ها این عادت هست که ویرایش‌های مختلف از یک فایل رو با پسوند‌هایی مثل final edit final، final edit، final final و از این دست موارد ذخیره کنن :)روشی که من ویرایش‌های مختلف رو ذخیره میکنم به این شکله که بعد از اسم پروژه، تاریخ اون روز رو به شکل عددی مینویسم. برای مثال 991013 که یعنی 13 دی 99. و برای اینکه بدونم فرق این نسخه با نسخه‌های بعدی چیه یه اشاره کوچیک هم به تغییراتی که ایجاد کردم میکنم.که در نهایت مثلا میشه: Zuha-BasketEdit-991013اشتراک گذاری فایل بین هم‌تیمی‌هاوقتی که دارید به صورت تیمی دیزاین انجام می‌دید، بدون شک فایل‌ها مدام بین شما و هم‌تیمی‌هاتون رد و بدل میشن.توی این فایل‌ها بعضی صفحات جدیدا اضافه شدن، بعضی‌ها صفحات قبلی هستن که ویرایش شدن و بعضی‌ها هم دیزاین‌هایی هستن که هنوز به صورت قطعی تایید نشدن و در حال بررسی‌ان و داریم چیزهای مختلف رو امتحان میکنیم.برای اینکه این صفحات به طور واضحی از همدیگه تفکیک بشن و مرتب باشن، کاری که من انجام میدم اینه که هر دسته از دیزاین‌هایی که اشاره شد، یعنی جدید، ویرایش شده و در حال بررسی رو، توی یه ردیف قرار میدم و بعد یه نوار رنگی بالای اون ردیف میذارم؛ که رنگ متفاوتی داره. و چون از قبل بین هم‌تیمی‌ها توافق کردیم که هر رنگی به چه معناست همه میدونیم که کجا باید دنبال چه چیزی باشیم و این کار رو خیلی راحت میکنه.رنگ‌هایی که من استفاده میکنم: سبز برای دیزاین جدید، آبی برای دیزاین ویرایش شده، نارنجی برای دیزاین در حال بررسی.اشتراک فایل UI Design بین هم‌تیمی‌هاانجام دادن مواردی که داخل این مطلب گفته شد زمان خیلی کمی از شما می‌گیره اما نتیجه‌ی بزرگی داره و علاوه بر منظم کردن فایل‌ها و کارتون، کمک میکنه تا ذهنتون هم مرتب بشه. Baran Masoumian Baran Masoumian Mon, 14 Dec 2020 17:00:34 +0330 https://virgool.io/@baran.masoumian/%DA%A9%D8%AF%D8%A7%D9%85-%D9%85%D8%AF%D9%84-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA-%D9%85%D9%86%D8%A7%D8%B3%D8%A8-%D8%B3%D8%A7%DB%8C%D8%AA%D8%A7%D9%BE%D9%84%DB%8C%DA%A9%DB%8C%D8%B4%D9%86-%D9%85%D9%86-%D8%A7%D8%B3%D8%AA-p3dgorezhbwi یکی از سوالای مهمی که در طراحی اپلیکیشن یا سایت پرسیده میشه و یا به عبارت دیگه باید پرسیده بشه، اینه که کدوم یک از مدل‌های معماری اطلاعات برای اپلیکیشن یا سایت ما مناسبه؟درست مثل وقتی که توی یه مقصد جدید از هواپیما پیاده می‌شید و فورا این سوال‌ها توی ذهنتون شکل می‌گیره که الان توی کدوم قسمت هستید، کجا باید برید و چطور باید به جایی که مد نظرتونه برسید؛ وقتی هم که توی سایت یا اپلیکیشن جدید قرار می‌گیرید این سوال که "چطور به صفحه‌ یا امکانی که مد نظرمه برسم" توی ذهن شما شکل می‌گیره.انتخاب یه معماری اطلاعات مناسب تعیین می‌کنه که انتظاری که کاربر از سایت یا برنامه داره به خوبی جواب داده می‌شود یا نه. یه معماری اطلاعات نادرست می‌تونه هزینه زیادی، هم برای کاربر و هم صاحب اپلیکیشن/سایت به وجود بیاره.متاسفانه توی خیلی از ترند‌های دیزاین امروزی به این موضوع برمی‌خوریم که راهبری و پیمایش (Navigation) در بخش‌های مختلف سایت یا اپ، فدای محتوا شده.موبایل محور شدن سایت‌ها که به معنی کوچیک شدن صفحه‌ نمایش هم هست، باعث شده تا مجبور بشیم بعضی از گزینه‌هایی که قبلا می‌تونسیتم برای هدایت و راهبری کاربر استفاده کنیم رو حذف کنیم. به همین دلیل اهمیت انتخاب یه معماری اطلاعات مناسب خیلی بیشتر از قبل شده.توی این مطلب بعضی از مدل‌های معماری اطلاعات و کاربردشون رو با هم بررسی می‌کنیم.سلسله‌ مراتب درختی (Hierarchical Tree)سلسله مراتب درختی مدلیه که بیشتر ما با اون آشنایی داریم و شناخته شده‌ترین مدل معماری اطلاعاته.وقتی که سایت ما قراره محتوای زیادی داشته باشه و به اصطلاح content-heavy هست، این مدل، یه مدل استاندارد برای معماری اطلاعات این نوع سایت محسوب میشه.توی این معماری کاربر می‌تونه به دسته‌بندی‌ها (Category)ی سطح بالا یا اصطلاحا Parent دسترسی پیدا کنه و بعد با پایین اومدن و باز کردن دسته‌ها، محتوا‌ داخل اون دسته‌بندی‌ها رو مشاهده کنه.مدل معماری اطلاعات سلسله مراتب درختی - hierarchical tree بنابراین وقتی سایتی داریم که محتوا در اون در دسته‌‌ها و زیردسته‌‌های متعددی قرار می‌گیره و حجم زیادی لینک برای نمایش داریم، از این معماری اطلاعات استفاده می‌کنیم، تا محتوا رو تدریجا به کاربر نمایش بدیم و مسیرهای دسترسی رو برای کاربر مشخص کنیم.از اونجایی که این مدل می‌تونه به لحاظ حجم لینک خیلی سنگین (link-heavy) بشه، برای صفحه‌نمایش‌های کوچیک مناسب نیست، چون مدیریت حجم زیاد لینک‌ها قطعا توی اسکرین‌های کوچیک سخت میشه.لیست تو در تو (Nested List)مدل معماری لیست تودرتو یکی از متداول‌ترین انواع پیمایش موبایلیه و اغلب برای مدیریت کردن منوهایی که چندسطحی هستن و آیتم‌های زیادی هم دارن استفاده میشه.اگر به تصویر این مدل نگاه کنید متوجه می‌شید که بهترین جایگزین برای پیاده‌سازی مدل معماری سلسله مراتب درختی توی موبایله و کاربر به راحتی با ضربه زدن (tap) یا کشیدن (swipe) می‌تونه بین منوها پیمایش کنه.مدل معماری اطلاعات لیست تو در تو - nested list‌ مزیت این مدل معماری اطلاعات اینه که به کاربر کمک می‌کنه تا بتونه بهتر روی محتوای هر بخش تمرکز کنه. اما هرچقدر که این مدل توی پیمایش عمقی خوب عمل می‌کنه و به بهترین نحو کاربر رو بین منوها جابه‌جا میکنه توی پیمایش جانبی ضعیفه و کاربر برای اینکه سکشن رو تغییر بده باید مسیر رفته رو برگرده و بعد بخش دیگه‌ای رو باز کنه.مرکز و پره (Hub and Spoke)این مدل رو به نام‌های دیگه‌ای مثل قطب و اقمار و یا به صورت مخفف H&S هم میشناسن.توی این مدل معماری اطلاعات، ما یه صفحه به عنوان صفحه‌ی مرکزی (hub) داریم و به واسطه‌ی پیوندهای موجود توی این صفحه، به بخش‌هایی که کاملا از هم مستقل هستن دسترسی داریم. وقتی داخل یک بخش هستیم امکان دسترسی به بخش دیگه‌ای رو نداریم و برای این کار اول باید به صفحه مرکزی برگردیم و بعد بخش دیگه‌ای که موردنظرمون هست رو انتخاب کنیم.این مدل هم مثل مدل Nested List توی افزایش تمرکز کاربر روی محتوا خیلی خوب عمل می‌کنه. چون بعد از وارد شدن به هر بخش مستقل، از ناوبری کلی برنامه خبری نیست و در عوض دکمه‌ی بازگشت رو می‌بینیم که به نحوی برجسته شده تا بتونیم مسیر برگشت رو به راحتی پیدا کنیم. این مدل برای سایت یا برنامه‌های تسک محور خیلی مناسبه.مدل معماری اطلاعات مرکز و پره - hub and spoke‌برای مثال Google Play از این معماری اطلاعات داخل دسته‌های اصلیش استفاده می‌کنه. بنابراین وقتی که وارد صفحه‌ یه محصول می‌شیم اولین چیزی که توجه ما رو جلب می‌کنه دکمه دانلود یا آپدیت برنامه‌ست.یه مثال دیگه میتونه بخش تنظیمات موبایلتون باشه.که هر کدوم از تنظیمات یه سکشن جدا هستند و تنظیمات مخصوصی رو انجام میدن و برای تغییر تنظیمات قسمت دیگه‌ای از موبایل، باید به صفحه اصلی تنظیمات برگردید و بخش مورد نظرتون رو انتخاب کنید.اگر به برنامه‌هایی که ازشون استفاده می‌کنید دقت کنید این معماری اطلاعات رو می‌تونید توی تعداد زیادیشون پیدا کنید.بنتو باکس (bento box‌)اسم این مدل معماری اطلاعات از روی یه جعبه غذای جمع و جور ژاپنی که مخصوص بیرون بردن غذاست گرفته شده. جعبه غذای بنتو (از ظروف سنتی ژاپن)هدف از دیزاین این مدل معماری، افزایش بهره‌وری و استفاده بهینه از فضا بوده.همه‌ی آیتم‌ها با اینکه در یک صفحه و یکجا نمایش داده میشن در عین حال از هم جدا هستند و به طور واضح کارایی خودشون رو نمایش میدن.این مدل شبیه به این هست که از مدل Hub & Spoke استفاده کنیم ولی برای برنامه یا سایتی که استایل یک داشبورد رو داره؛ که محتوا رو به صورت پویا از منابعی که براش تعریف شده میخونه و نمایش میده.بنابراین بنتو باکس یه دیزاین تک صفحه‌ای چند منظوره‌ست که با باز کردن هر بخش لایه‌های جدیدی از محتوا رو به کاربر نشون میده.این مدل برای سایت‌هایی که کاربر در اونها با داده سروکار داره انتخاب خیلی مناسبیه.توی اکثر موارد این داده‌ها از منابع مختلفی تامین میشن. مثلا داده‌های آماری از یه منبع، داده‌های ویدئویی از یه منبع دیگه و...برای مثال توی عکس پایین، اگر منو رو انتخاب کنیم به بخش منو هدایت میشیم، اگر قسمت نموداری رو انتخاب کنیم وارد بخش نمایش داده‌های مربوط به اون میشیم، انتخاب ویدئوها ما رو به سکشن پیش‌نمایش وید‌ئوها می‌بره و با انتخاب گزینه تنظیمات، آپشن‌هایی که میتونیم تغییر بدیم به ما نمایش داده میشه.مدل معماری اطلاعات بنتو باکس - bento box‌ نمای فیلتر شده (Filtered View)برخلاف داشبورد که مثل یه مرکز کنترل برای تعامل با داده‌های مختلف عمل میکنه. این سیستم یه مجموعه داده‌ی واحد و از یک جنس رو نمایش میده، و اطلاعات می‌تونن در اون به روش‌های متفاوتی جستجو و مرتب سازی بشن.کاربر در این سیستم‌ها گزینه‌های زیادی برای مرتب‌سازی و شیوه‌ی نمایش اطلاعات داره.اگر موزیک پلیر تلفن همراهتون رو باز کنید این مدل معماری اطلاعات رو میتونید ببینید.شما توی موزیک پلیرتون می‌تونید موزیک‌ها رو بر اساس آرتیستشون، آلبوم‌هاشون، سبکشون و... ببینید. یا بر اساس محبوب‌ترین، جدیدترین، اخیرا پخش شده و... مرتب کنید.مشابه چیزی که توی تصویر زیر اتفاق میفته. مدل معماری اطلاعات نمای فیلتر شده - filtered view مدل‌های ترکیبی (Combined IA Models)در نهایت مدل‌های مختلف معماری اطلاعات برای اهداف مختلف و بر اساس نیاز ما میتونن با همدیگه ترکیب بشن و معماری اطلاعاتی که مناسب سایت یا برنامه ما هست رو بسازن.برای مثال کاربر می‌تونه وارد یه سایت بشه که از مدل درختی استفاده می‌کنه و بعد از لاگین کردن به یک سیستم کاملا جداگانه و صفحه‌ای هدایت بشه که به عنوان صفحه‌ی مرکزی مدل Hub & Spoke هست و با این مدل تعامل کنه.همینطور حالت‌های خیلی زیادی که انواع مدل‌ها میتونن با ترکیب شدنشون به وجود بیارن. برای مثال ما سیستم فیلترینگ رو به اشکال مختلف در خیلی از سایت‌ها داریم.نکته‌ای که باید بهش دقت بشه اینه که ترکیب چند مدل داخل یک سایت میتونه گیج‌کننده باشه و استفاده از مدل‌های ترکیبی باید بر اساس انتظارات کاربر و نوع محتوا باشه.مدل معماری اطلاعات ترکیبی - combined IA modelsممنونم که همراه من شدید و خوشحال میشم نظرتون رو با من به اشتراک بگذارید.در پست‌های آتی بیشتر و بیشتر درمورد انواع مدل‌ها و جزئیاتشون میگم و با هم مدل‌ها رو عمیق‌تر و جزئی‌تر بررسی می‌کنیم. Baran Masoumian Baran Masoumian Fri, 04 Dec 2020 14:17:10 +0330