https://virgool.io/feed/@shayan دایرکتور سابق تجربهٔ کاربر در دیوار fa 2026-06-07 15:01:42 https://files.virgool.io/upload/users/141/avatar/VsoTyO.png?height=120&width=120 https://virgool.io/@shayan https://virgool.io/DivarDesign/%DA%86%D8%B1%D8%A7-%D8%A7%D8%B3%D8%AA%D8%AE%D8%AF%D8%A7%D9%85-%D9%86%D8%B4%D8%AF%D9%85-k0lkm9cmmck0 در شرایطی هستیم که کمبود متخصص در کشور واضحه و سرمایه‌گذاری روی آموزش و رشدِ آدم‌های مستعد اجتناب‌ناپذیره.ما در دیوار تجربه‌ی استخدام و منتورینگِ کارآموز داشتیم اما می‌خواستیم به طراحانِ کم‌تجربه‌تر فرصتِ بیش‌تری بدیم، فرایند استخدامِ کارآموز رو بازنگری و بهینه کنیم و از فرصتِ دورکاری استفاده کنیم. این شد که امسال تصمیم گرفتیم موقعیت شغلی «کارآموزیِ طراحی تجربه» رو تعریف و منتشر کنیم.پس از اتمام ارزیابی متقاضیانِ کارآموزی، عده‌ی زیادی پرسیدن که چرا پذیرفته نشدن؟ در این یادداشت سعی کردم با آمار جواب بدم. در انتها هم به بعضی از سؤال‌هایی که در تلگرام و توییتر پرسیده شده بود پاسخ دادم.موقعیت کارآموزی دیزاین از ۱۰ خرداد تا ۱۱ تیر ۱۴۰۰ برای دریافت رزومه باز بود.در ۴۸ ساعتِ اول حدود ۱۱۰ رزومه گرفتیم. در بازه‌ی یک ماه حدود ۶۰۰ رزومه به دستمون رسید. به‌جز ایران، از ایرانی‌های مقیم اسپانیا، ایتالیا و پرتغال هم متقاضی داشتیم.هر نقطه، نماینده‌ی یک رزومه‌ست.تصمیم‌گیری و انتخاب بخشِ اجتناب‌ناپذیرِ فرایندهاست. استخدام هم مستثنا نیست. ما قصد داشتیم از بین چندصد نفر، ۲ نفر انتخاب کنیم.استخدام کارآموزِ طراحی هم مشابه فرایند استخدام طراح تجربه بود اما سطح انتظاراتمون فرق داشت. برای افزایش آگاهیِ مخاطب از این انتظارات، معیارهای اساسیِ بررسی رزومه رو در شرح شغل نوشته بودیم:تجربه‌ی کشف و حل مسئله‌ی آدم‌ها در چارچوب محدودیت‌هاارتباط و همکاری مؤثر کلامی و نوشتاریآشنایی با اساس دیزاین، مانند طراحی layoutتجربه‌ی طراحی رابط کاربر با ابزارهایی مثل اسکچ یا فیگما، با پیروی از راهنماهای طراحیعلاقه‌ی بلندمدت به دیزاین و UX به‌عنوان یک مسیر شغلی و تمایل به یادگیری و پیش‌رفتبرای عادلانه بودنِ گزینش، حتا کسانی رو که همکاران بهمون معرفی می‌کردن، سمتِ صفحه‌ی فرصت‌های شغلی می‌فرستادیم تا اطمینانِ بیش‌تری داشته باشیم که پیش از ثبت‌نام همه انتظاراتِ ما رو خوندن.تعریف و حدود انتظاراتی که نوشتیم شفاف نیست، اما مصداق‌هایی که مواردِ بالا رو نقض می‌کنه تا حدی مشخصه؛ مثلن نداشتنِ تجربه‌ی کاری مرتبط؛ رزومه‌ای پر از اشکالات املایی و انشایی؛ ساختار و اولویت‌بندی نامناسب در نمایش اطلاعاتِ مهم؛ انتخاب شیوه‌ی نامناسب برای به‌تصویر کشیدنِ اطلاعات؛ نبودِ نشونه‌ای از علاقه و انگیزه به یادگیری — که برای کارآموزی شرط لازمه.در بررسی رزومه‌ها بیشینه‌ی تجربه‌ی کاریِ مرتبط رو ۳ سال در نظر گرفتیم. این مقدار فراتر از حدی بود که ابتدا مد نظر داشتیم اما به‌تجربه می‌دونستیم میزانِ تجربه‌‌ی کاری شاخص مناسبی برای تخمین دانش و مهارت نیست. حواسمون بود که به میزان تجربه امتیاز مثبت ندیم، بلکه تجربه‌ی کار رو فرصتی بدونیم که فرد برای رشد در اختیار داشته. خلاصه، افرادی با تجربه‌های متفاوت رو با میزانِ انتظارِ یکسان ارزیابی نکردیم و انتظار بالاتری از افراد باتجربه داشتیم.تأکید کردیم در همه‌ی مراحل به‌دنبال نشونه‌هایی برای ارزیابیِ مواردِ بالا می‌گردیم، و گشتیم. از میان این ۶۰۰ رزومه تنها ۶۷ رزومه ویژگی‌های مورد انتظار ما رو به‌خوبی نشون دادن.تنها ۱۱ درصد از رزومه‌ها از مرحله‌ی بررسی گذشتن.یک‌سوم از این ۶۷ رزومه مربوط به خانم‌ها بود. ۸۰ درصدِ متقاضیان ساکن تهران بودند.در بین این رزومه‌ها تنوعی از رشته‌های تحصیلی، حوزه‌ی کار، میزانِ تجربه‌ی کار و انگیزه‌ی ورود به دیزاین دیدیم.پس از بحث و اولویت‌بندی، با تعدادی از متقاضیان تماس گرفتیم. براساس شرایطی مثل امکانِ همکاریِ تمام‌وقت تا سال آینده، از ۱۶ نفر برای مصاحبه دعوت کردیم.بعد از ۱۶ مصاحبه‌ی یک‌ساعته به‌شکل بررسیِ نمونه‌کار، برای ۹ نفر تسک فرستادیم. تسکی که فرستادیم یک مسئله‌ی محصولیِ باز و نامرتبط با دیوار بود و یک هفته فرصت انجام داشت.کمتر از ۳ درصد به مصاحبه‌ی مرحله‌ی یک دعوت شدن و ۱.۵ درصد از متقاضیان تسک دریافت کردن.نتیجه‌ی تسک‌ها رو بررسی و ۵ نفر رو به جلسه‌ی دفاع از تسک دعوت کردیم. در نهایت به ۲ نفر پیشنهاد همکاری دادیم.پاسخ پرسش‌های متداولپرسش ۱: چرا به‌نظر میاد کسی قبول نشده؟!دو نفر پذیرفته و استخدام شدن. این عدد در مقابلِ تعدادِ متقاضیان عدد کوچکیه. با فرض یکسان بودنِ شرایط متقاضیان، هر کسی که ثبت‌نام کرد تنها ۰.۳ درصد شانس استخدام داشت. این موضوع نشون می‌ده که چرا احتمال مشاهده‌ی افرادی که پذیرفته نشدن بسیار بیش‌تره.احتمال پذیرش ۲ از ۶۰۰ بود.پرسش ۲: چرا نتیجه رو بهم اطلاع ندادین؟ما به همه‌ی متقاضیان نتیجه رو ایمیل کردیم اما وقوعِ چند مشکلِ نادر ممکنه باعث شده باشه ایمیل نگرفته باشید:رزومه‌ی بعضی‌ها به‌دست ما نرسیده، احتمالن چون موقع ثبتِ رزومه به خطا برخوردن.بعضی‌ها ایمیل نامتعبری وارد کرده بودن. ما این موضوع رو از خطای سیستمِ تحویلِ ایمیل می‌فهمیدیم. حدس می‌زنیم مواردی هم بوده که ایمیل معتبر ولی اشتباهی رو موقع پُر کردنِ فُرم وارد کردن و ایمیل اعلامِ نتیجه رو دریافت نکردن.ایمیل ما به دست متقاضیان نرسیده. احتمال اندکی هست که سیستمِ تحویلِ ایمیل در ارسال ایمیلِ انبوه دچار مشکل شده باشه. ما به یک مورد برخوردیم و ایمیل رو دستی فرستادیم.پرسش ۳: چرا بازخوردی ندادین؟ما یک ایمیل عمومی حاوی منابعی برای مطالعه و یادگیری فرستادیم چون امکان‌پذیر نبود برای همه بازخوردی با جزئیات بنویسیم. درک می‌کنیم بازخوردِ عمومی و شخصی‌نشده پاسخگوی نیاز افرادی نباشه که قصد کشف مشکلات پورتفولیو یا رزومه‌شون رو دارن. اما حتا اگه می‌نوشتیم، این بازخوردها متناسب با انتظاراتِ ما داده می‌شد و قابل‌تعمیم به انتظاراتِ شرکت‌های دیگه نبود. یعنی احتمالن کمکی به استخدامِ شما در شرکت‌های دیگه نمی‌کرد.به‌طور خلاصه، اگر در مرحله‌ی بررسی رزومه رد شُدید، مواردی رو که انتظار داشتیم در رزومه‌ی شما ببینیم ندیدیم، یا رزومه‌ی شما طوری طراحی نشده بود که پیامی رو که می‌خواستیم دریافت کنیم به‌خوبی بهمون برسونه.رزومه هم یه محصوله. متقاضیِ استخدام طراحِ این محصوله و ارزیاب‌ها کاربرانِ این محصول. اصول طراحی تعامل و کاربردپذیری، از جمله مؤثر بودن در ارائه‌ی اطلاعاتِ مورد نیاز به کاربر در کمترین زمانِ ممکن، در مورد رزومه هم صادقه.پرسش ۴: چرا ایمیل‌ها رو انگلیسی می‌فرستید؟تا چند روز پیش از ATS انگلیسی‌زبانی استفاده می‌کردیم که به‌خوبی از فارسی پشتیبانی نمی‌کرد. در نتیجه، ایمیل‌ها رو انگلیسی می‌فرستادیم تا از خوانده‌شدنِ درستِ متنِ ایمیل — که حاویِ کلمات انگلیسی و فارسیه — مطمئن باشیم.در ادامه‌ی تابستون تغییراتی در این روند می‌‌دیم، اما همچنان در مواردی از جمله نوشتنِ شرح شغل، انگلیسی‌نویسی رو ترجیح می‌دیم. هر چند ما برای پاسداری از زبان فارسی تلاش می‌کنیم، بسیاری از کلمات تخصصی معادلِ فارسیِ مناسب یا آشنایی ندارن که متقاضیان رو از انتظاراتِ ما مطلع کنن. گاهی بین نگارش متنی که ۸۰٪ فارسی و ۲۰٪ انگلیسیه، متنی که ۱۰۰٪ انگلیسی نوشته‌شده رو انتخاب می‌کنیم.پرسش ۵: اصلن چرا از کارآموز انتظار رزومه دارید؟!فرض این پرسش اینه که «کسی که کارِ قابل ارائه‌ای داشته باشه دیگه کارآموز نیست.» اما فرض درستی نیست. تعریف «کار» و «کارآموز» تابع نیاز و شرایط شرکت‌هاست. همونطور که برای فرصت‌های شغلیِ غیر از کارآموزی، انتظارات متفاوتی از متقاضیان نسبت به سایر شرکت‌ها داریم، در مورد کارآموزی هم سطح انتظاراتمون فرق می‌کنه. در مقابل، همه‌ی کارجوها هم انتظار یکسانی از شرکت‌ها ندارن.کارآموزی فرصت خوبیه تا دانشجویانی که به‌تازگی فارغ‌التحصیل شدن تجربه کسب کنن و استخدام بشن. شرکت‌های خارجی برای انتخاب از میانِ جمعِ علاقه‌مندان به شرکت در دوره‌های کارآموزی، ممکنه به افرادی که در رشته‌های تحصیلیِ مرتبط تحصیل کردن اولویت بدن، چون رشته‌ی تحصیلی نشونه‌ای از دانشِ اولیه، علاقه‌مندی و تمرکزه.در ایران چون رشته‌ی نزدیکی به طراحی محصول دیجیتال نداریم — طراحی صنعتی رو رشته‌ی نزدیکی نمی‌دونیم — از معیارهای دیگه‌ای برای انتخاب از بین متقاضیان استفاده می‌کنیم. تجربه‌ی کاریِ مرتبط با طراحی محصول برای ما یک نشونه‌ست.بعلاوه، با ایجاد یک سازوکار غربال کردن، فرایند استخدام رو سریع‌تر می‌کنیم. تصور کنید ما برای شناخت همه‌ی این ۶۰۰ نفر تصمیم به مصاحبه می‌گرفتیم. اگر هر روز دو مصاحبه‌ی دو نفره‌ی یک‌ساعته برگزار می‌کردیم، فقط مرحله‌ی اولِ مصاحبه‌ها ۶ ماه وقت می‌گرفت. اما با دریافت و بررسی رزومه این فرایند کمتر از یک ماه زمان برد.همچنین،‌ با غربال کردن استخدام رو به‌شکلی بهینه می‌کنیم که مثبتِ کاذب نداشته باشیم، چون هزینه‌ی استخدام کردنِ اشتباه، حداقل در مقطع فعلی و برای کارآموزی، بسیار بیش‌تر از استخدام نکردنِ اشتباهه.پرسش ۶: چرا از کارآموز انتظاری برابر با سینیور دارید؟چنین انتظاری نداریم و احتمال می‌دیم تعریف پرسش‌گر از «سنیور» متفاوت از تعریف ما باشه. به‌هر رو، تعداد افرادی که فراتر از انتظار (overqualified) تشخیص دادیم و به مصاحبه دعوت نکردیم، به‌نسبت کم بود.از دو نفری که پذیرفته شدن یک نفر تنها تجربه‌ی محدود طراحی UI و دیگری فقط یک سال تجربه‌ی طراحی UX داره. بنابراین طبق تعریفِ ما، نه تنها انتظار سنیور بودن نداشتیم، بلکه سنیور هم استخدام نکردیم.کلام آخربه‌واسطه‌ی این یادداشت سعی کردم منطق تصمیم‌گیری و انتخاب‌مون رو توضیح بدم. می‌دونیم چنین فرایندی هیچ‌وقت بی‌نقص نخواهد بود و مثبت یا منفیِ کاذب خواهد داشت. گاهی هزینه‌ی بهینه‌سازی به حدِ کمال توجیه‌پذیر نیست. اما آگاهیم که بهتر شدنِ این فرایند به‌نفع هر دو طرفه. بنابراین از نتیجه‌ی تصمیم‌هایی که گرفتیم و بازخوردهای شما برای بهبودش استفاده می‌کنیم.مرسی که همراه‌مون بودید. اگر سؤال دارید، در نظرات یا در کانال تلگرام دیزاین در دیوار بپرسید. در این کانال دوره‌های کارآموزی بعد رو هم به اطلاع‌تون خواهیم رسوند. شایان مهردوست شایان مهردوست Mon, 26 Jul 2021 11:12:07 +0430 https://virgool.io/@shayan/%D8%AA%D8%B9%DB%8C%DB%8C%D9%86-%D8%AC%D9%87%D8%AA-%D8%AF%D8%B1-%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-saxs2zyhvi08 در این یادداشت ایمان نتیجه گرفته نوشتار و اجزای رابط کاربر باید هم‌جهت باشن. یعنی چون فارسی رو از راست به چپ می‌نویسیم، باید راست‌به‌چپ هم اسکرول کنیم. گرچه این نتیجه‌گیری درسته، اما محصولِ مفهومِ جامع‌ترِ ارتباط (communication) در طراحیه.رسالتِ دیزاین ارتباط درسته. ارتباط یعنی «رسوندنِ مقصودِ یک‌طرف به طرفِ دیگه به‌واسطه‌ی نشانه‌ها و قوانینی که هر دو طرف درک مشترکی از اون‌ها دارن.» طراح این مقصود رو به‌واسطه‌ی رابط کاربر (UI) به کاربر منتقل می‌کنه.مقصود یا پیام رو می‌تونیم صریح (explicit) یا ضمنی (implicit) منتقل کنیم. این‌که کدوم رویکرد رو انتخاب کنیم، به میزانِ اعتماد ما به گیرنده‌ی پیام (کاربر) بستگی داره. این اعتماد جنبه‌های متفاوتی داره. یکی از این جنبه‌ها درکِ مشترکِ طرفین از مفهومه.برای مثال، در ابتدای هر سطری که می‌خونید ننوشتم «از راست به چپ بخوانید.» چون قانونِ زبانِ فارسی به‌صورت ضمنی این اطلاعات رو به شما می‌ده. به‌عبارت دیگه، هر کسی که به زبانِ فارسی می‌خونه و می‌نویسه، آگاهه که جهتِ زبانِ فارسی از راست به چپه. پس نیازی ندارم در رابط کاربر به‌صراحت به این موضوع اشاره کنم.این اصل در دیزاینِ اجزا و اینترکشن‌ها هم صادقه: یا جهتِ Scroll و Swipe رو به کاربر می‌گیم، یا به‌صورت ضمنی بهش اشاره می‌کنیم. راه‌های اشاره‌ی ضمنی متعدده و signifierها یکی اون‌هاست. برای مثال، کامپوننت ImageCarousel دیوار رو در حالتی که viewport مانعِ نمایش کاملِ عکسِ سوم شده ببینید.بدونِ این‌که بگیم جهتِ اسکرول به سمتِ چپه، می‌تونیم انتظار داشته باشیم کاربر به سمتِ چپ اسکرول کنه تا عکسِ کامل رو ببینه، چون طبقِ اصلِ تداوم (continuity) بقیه‌ی عکس‌ها در سمت چپِ تصویره. [۱]اما اگه اندازه‌ی عکس‌ها ثابت و عرض صفحه طوری بود که عکس سوم کامل دیده می‌شد، کاربر چطور اسکرول می‌کرد؟ به بیانِ دیگه، اگه به‌صورت صریح یا ضمنی به جهتِ اسکرول اشاره نمی‌کردیم، کاربر چطور می‌فهمید در چه جهتی اسکرول کنه؟تصویری که کاربر از سیستم دریافت می‌کنه (system image) موقع حدس‌زدن بهش کمک می‌کنه. پس ما باید تصویری ازین‌که سیستم چطوری کار می‌کنه بسازیم. اصلِ یکپارچی (consistency) در دیزاین، در ساختِ این تصویر بهمون کمک می‌کنه. ما با تکرارِ یک رفتارِ مشخص در شرایط متفاوت در رابط کاربر، به انتظارِ کاربر شکل می‌دیم: «تا حالا جهت اسکرول و سوایپ در همه‌جا از راست به چپ بوده. پس این‌‌جا هم باید به سمتِ چپ اسکرول بشه.» واضحه که هر کاربر پیش از هر اینترکشن این جمله رو توی ذهنش مرور نمی‌کنه و این اتفاق در کسری از ثانیه رخ می‌ده. بعلاوه، سیستم فقط محدود به یک ابزار و محصول نیست؛ کاربران پیش از یاد گرفتنِ کار با محصولِ ما، یاد گرفتن چطوری با سیستم‌عامل و شاید محصولاتِ دیگه‌ کار کنن. آموخته‌های اون‌ها از چگونگیِ کارکردِ سیستم، روی انتظاری که از دیزاینِ ما دارن اثر می‌ذاره.خلاصه، بهترین راه برای طراحی با هدفِ کاهشِ سوءِبرداشت، اشاره‌ی صریحه. ایمان مثالی آورده که چطور با تغییر دیزاینِ «از» و «تا» در دیزاینِ کامپوننت Slider این انتقالِ پیام رو می‌شه از حالتِ ضمنی به حالت صریح تغییر داد. اما صراحت معمولن راه بهینه‌ای برای طراحیِ همه‌چیز نیست. تصور کنید پیش از استفاده از هر دستگاهی مجبور بودید راهنمای استفاده از اون دستگاه رو مطالعه کنید. راه دیگه، اشاره‌ی ضمنی با کمکِ نشانه‌هاست تا کاربر بتونه متوجهِ کارکردِ سیستم بشه.همزمان، لازمه اصل یکپارچگی رو رعایت کنیم تا کاربر بدونِ نشانه‌ها هم بتونه حدس بزنه هر چیز چطور کار می‌کنه؟ با توجه به توصیه‌ی راهنمای دیزاین سیستم‌عامل به آینه‌کردنِ رابط کاربر در حالتِ نوشتارِ راست‌به‌چپ و تبعیت اپ‌های روی سیستم‌عامل ازین راهنما، ریسکِ کم‌تری داره که اجزای رابط کاربر رو هم‌جهت با جهتِ نوشتار طراحی کنیم.اتکا به اصل یکپارچگی، فهمِ اینترکشن‌ها رو راحت‌تر و ریسکِ سوءبرداشت رو کم‌تر می‌کنه، اما ریسک رو به صفر نمی‌رسونه. بعلاوه، وقتی راجع‌به اجزای بصری صحبت می‌کنیم، ترجیح کاربران با هم متفاوته. این مقاله نشون داده که کاربران عبری‌زبان آینه‌شدنِ نیمی از اجزای رابط کاربر رو ترجیح نمی‌دن. باید توجه کنیم که راهنمای دیزاین، به‌قصد یک راهنمای عمومی و بیش‌ازحد ساده‌شده‌ست و پاسخگوی ترجیح همه‌ی کاربران نیست. برآوردنِ ترجیح همه‌ی کاربران هم رویکردِ بهینه‌ای در دیزاین نیست. در نتیجه، اگه بخوایم در مورد آینه‌کردنِ همه‌‌ی آیکون‌ها تصمیم بگیریم، برخلافِ توصیه‌ی راهنمای Material ممکنه به کاهش هزینه‌ی توسعه اولویت بدیم و این کار رو نکنیم.[۱] حتا اگه بالای عکس متنی چپ‌به‌راست نوشته بودیم، فرض منطقی اینه که کاربر عکس‌ها رو به‌سمتِ چپ — خلاف جهت نوشته — اسکرول کنه؛ احتمالن چون پیامی که به‌شکل بصری و مستقیم، به‌واسطه‌ی نشانه‌ها در ImageCarousel منتقل می‌شه، مفهوم رو ساده‌تر منتقل می‌کنه نسبت به این‌که کاربر از روی جهتِ متنِ بالای عکس، جهتِ اسکرول عکس‌ها رو حدس بزنه. شایان مهردوست شایان مهردوست Fri, 14 May 2021 14:54:49 +0430 https://virgool.io/DivarDesign/%D9%84%DB%8C%D8%AF%D8%B1%D8%B4%DB%8C%D9%BE-%D8%AF%D8%B1-%D8%B5%D9%86%D9%81-%D8%AA%D8%AC%D8%B1%D8%A8%D9%87%D9%94-%D8%AF%DB%8C%D9%88%D8%A7%D8%B1-bttolf1byb0s سه سال از اولین روزِ حضورم در دیوار گذشت. بخش اصلی آموخته‌های زندگی و کارم رو مدیون فرصتی‌ام که در این سال‌ها واسم فراهم شد. این‌جا یاد گرفتم که آدم‌ها، تعامل، تیم، لیدرشیپ و فرهنگ سازمانی نه تنها مهمه، بلکه اولویته.در دیوار جمعی ۲۰ نفره از بهترین‌ها در زمینه‌ی پژوهش، دیزاین، مهندسی و نگارش تجربه‌ی کاربر (UX) حضور دارن. هر کدوم از این زمینه‌ها رو یک چپتر می‌نامیم و هر چپتر یک لیدر داره. به مجموعه‌ی این افراد که مسئولیت‌شون کشف نیازهای کاربر و بهبود تجربه‌ست، صنف تجربه یا UX Guild می‌گیم. من این شانس رو داشتم که لیدرشیپ این صنف رو به‌عهده داشته باشم. در این یادداشت مسئولیت‌های اصلی چپترلیدرها رو در صنف تجربه‌ی دیوار نوشتم.مثل هر مسئله‌ی دیزاین، این مسئولیت‌ها در پاسخگویی به نیاز، و متناسب با ساختار و شرایط دیوار تعریف شده. در گذر زمان هم متناسب با شرایط تغییر خواهد کرد. باهار در این یادداشت ساختار رو بیش‌تر توضیح داده تا تصویر واضح‌تری از این سیستم ارائه کنیم.هدفم از نوشتنِ این متن، علاوه بر تعیین چارچوبِ فکری و انتقال تجربه، گرفتنِ بازخورده. بنابراین سعی کردم کلمات و عبارات رو با دقت انتخاب کنم تا متن کوتاه‌تری بخونید. حذف جزئیات و نبودِ مصداق ممکنه منجر به طرح پرسش‌های بیش‌تری بشه. برای من همین پرسش‌ها مهمه.مسئولیت‌های لیدرشیپ صنف تجربه دیوار این‌هاست:توظیف (staffing)هم‌سویی (alignment)رشد (growth)توظیفلیدرشیپ مسئوله آدم‌هایی رو با مهارت مطلوب و در زمان درست برای دیوار استخدام کنه، آن‌ها رو در جای مناسبی قرار بده و حفظ کنه.انتظار از لیدرشیپ:سرعت استخدام رو متناسب با نیاز فعلی و رشد دیوار تنظیم کنه.مهارت‌های مورد نیاز رو در کوتاه‌مدت تعیین و بر همین اساس متقاضیان استخدام رو ارزیابی کنه.اعضا رو متناسب با نیاز دیوار و برنامه‌ی رشد افراد جانمایی کنه.بالاترین دستمزد بازار رو متناسب با مهارت‌های هر سطح مشخص کنه.هم‌سوییلیدرشیپ باید مسئولیت‌ها و انتظارها رو مشخص و منتقل کنه؛ براین اساس بازخورد بده و ارزیابی کنه. تجربه‌های موفق رو به فرایند و چارچوب تبدیل کنه تا بهره‌وری بیش‌تری در تولید داشته باشیم.انتظار از لیدرشیپ:مسئولیت اعضا و انتظاری رو که از تعامل آن‌ها با سایر نقش‌های دیوار داریم، متناسب با مهارت‌های فرد و شرایط تیم تعیین و به دو طرف منتقل کنه.ناظر بر تعهد و برآورده شدن انتظار از سوی دو طرفِ تعامل باشه و برای بهبود آن بازخورد بده.اصول و فرایندهای صنف رو بهینه و به استاندارد تبدیل کنه و ناظر بر اجرای استانداردها باشه.عملکرد اعضا رو طبق انتظار ارزیابی و رتبه‌بندی کنه.رشدرشد افراد رو در راستای نفع بلندمدت دیوار می‌دونیم و معتقدیم هر کسی مسئول رشد خودشه. لیدرشیپ سعی می‌کنه با رفع موانع و در اختیار گذاشتنِ فرصت، رشد افراد رو تسهیل کنه.انتظار از لیدرشیپ:با آموزش، راهنمایی و ارائه‌ی بازخورد پیوسته، سرعت و کیفیت دلیوری رو متناسب با سرعت توسعه‌ی محصول تنظیم کنه.اطلاعات، ابزار و شرایط لازم رو برای تصمیم‌گیری و اثرگذاری در اختیار اعضا قرار بده.فرصت به‌اشتراک‌گذاری دانش و تجربه رو میان اعضا فراهم کنه.فرصت توسعه‌ی مهارت‌های فردی رو متناسب با شرایط دیوار برای اعضا فراهم کنه.این مطلب رو که در ابتدای متن بهش ارجاع دادم برای معرفی صنف تجربه نوشتیم. بخونید و سؤالی هم داشتید بپرسید. شایان مهردوست شایان مهردوست Tue, 29 Dec 2020 17:23:23 +0330 https://virgool.io/@shayan/%D9%82%D8%A7%D9%86%D9%88%D9%86%D9%90-%D8%A8%DB%8C%D9%82%D8%A7%D9%86%D9%88%D9%86%DB%8C%D9%90-%D9%81%D8%B1%D9%87%D9%86%DA%AF%D9%90-%D9%86%D8%AA%D9%81%D9%84%DB%8C%DA%A9%D8%B3-vslxpivwizau نتفلیکس از جهات زیادی بین شرکت‌های آی‌تی معروفه؛ دفعاتی که چرخش‌های بیزینسی جدی رو تجربه کرده، فرهنگِ سازمانیِ منتشر‌شده برای عموم و دستمزدهای بالا.برای من فرهنگ سازمانی‌ش جالبه چون اثر مهم و بلندمدتی روی تصمیم‌گیری و اجرا می‌ذاره. در گذشته بخشی از این فرهنگ رو توی کتاب Powerful — که مدیر منابع انسانیِ سابق نوشته — خونده بودم ولی کتابی که به‌تازگی منتشر شده به موضوعات جدیدی اشاره کرده.متنی که می‌خونید قسمتی از یادداشت‌های منه از دو فصل از چهار فصلِ کتابِ No Rules Rules، به قلم Reed Hastings مدیرعامل نتفلیکس و Erin Meyer شخصیتی آکادمیک و بی‌طرف که پژوهش‌های مربوط یا نقل‌قولِ کارمندانِ شرکت رو به نوشته‌های رید اضافه کرده.این کتاب چهار بخش داره:۱) اولین قدم‌ها در راستای فرهنگ آزادی و مسئولیت۲) قدم‌های بعدی در همین راستا۳) فنونی برای تحکیمش۴) جهانی‌شدن!فصل سوم بدونِ جزئیاتش به‌نظرم کافی نیست. بنابراین خلاصه‌ش رو ننوشتم. فصل چهارم رو هم درلحظه نیاز نداشتم و نخوندم. باقی متن تلفیقی از بخش اول و دومه.ناگفته پیداست که این متن خلاصه‌ست و ناقص. هر فصلش برای من ده‌ها سؤال بی‌جواب داشت، برای شما هم خواهد داشت. این متن رو نوشتم که شاید عده‌ای رو به خوندنِ این کتابِ خوب ترغیب کنم.استخدام بهترین‌هاسه سال بعد از تأسیس نتفلیکس، مدیران این شرکت در سال ۲۰۰۱ مجبور به اخراج یک‌سوم از نیروهاشون شدن. رید (Reed) انتظار داشت که شرکت از لحاظ روحی و عملکردی بِهم بریزه... که نریخت! بلکه کارمندان بهتر از گذشته هم کار می‌کردن. این موضوع نگاهش رو به انگیزه‌ی کارمند و مسئولیت لیدر به‌کل تغییر داد.رید این بحث رو مطرح می‌کنه که وقتی آدم‌های باهوش رو کنارِ هم قرار می‌دیم، اثرگذاری‌شون هم‌افزایی پیدا می‌کنه. ۵ تا دلیل هم میاره که کارمندان «مناسب» به‌اندازه‌ی کافی خوب نیستن:انرژی مدیر رو می‌گیرن که منجر می‌شه مدیران وقت کمتری برای آدم‌های قوی داشته باشن.کیفیتِ بحثِ گروهی و ضریبِ هوشیِ همه‌ی تیم رو پایین میارن.بقیه رو وادار می‌کنن راهی واسه دورزدن اون‌ها پیدا کنن؛ در نتیجه بهره‌وری رو کاهش می‌دن.کارمندانی که پیِ تعالی می‌گردن رو مجبور به ترک سازمان می‌کنن. به تیم نشون می‌دن که شُمای مدیر، معمولی‌بودن رو می‌پذیری که مشکلات رو تشدید می‌کنه.در ادامه پیشنهاد کرده مدیران باید آموزش ببینن تا شهامت و قدرت لازم رو داشته باشن که کارمندانی رو که رفتارِ نامناسب و عملکردِ معمولی دارن اخراج کنن.بیان آزاد اندیشه‌هادر این بخش که به فرهنگ بازخورد دادن و گرفتن مربوطه، صحبت شده که چه دلایلی منجر می‌شه من نظر واقعی‌م رو نخوام بگم:فکر می‌کنم که از نظرم حمایت نخواهد شد.نمی‌خوام آدمی به‌نظر برسم که کار باهاش سخته.دوست ندارم وارد بحث ناخوشایند بشم.نمی‌خوام خطر ناراحت یا عصبانی کردنِ همکارانم رو بپذیرم.نگرانم که «بازیکن تیم» به‌شمار نیام.پیشنهاد کرده به همه این شهامت رو بدیم تا چیزی رو که می‌اندیشند به‌زبان بیارن اما با نیّت مثبت؛ نه با هدفِ حمله‌کردن یا آسیب‌رسوندن به دیگری. هدفْ اینه که احساسات، نظرات و بازخوردها رو مطرح کنیم و باهاشون مواجه بشیم.حلقه‌ی بازخورد (feedback loop) رو به‌عنوان مؤثرترین ابزارِ بهبودِ عملکرد معرفی می‌کنه. بازخورد کمک می‌کنه سوءتفاهم‌ها رفع بشه، جوِ مسئولیت‌پذیریِ اشتراکی به‌وجود بیاد و نیاز کمتری به سلسله‌مراتب قدرت و قانون باشه.در مورد اصطلاحِ رایجِ «فقط چیزی رو در مورد کسی بگو که جلوی روی خودش هم می‌گی.» صحبت می‌کنه که چطور به فرهنگ زیرآب‌زنی و سیاست‌بازی خاتمه می‌ده.برای جاانداختنِ این فرهنگ پیشنهاد می‌کنه که راهِ ساده — یعنی بازخورد رئیس به کارمند — رو نریم؛ بلکه روی راه سخت‌تر که بازخوردِ صادقانه دادن به رئیسه تمرکز کنیم.نتفلیکس یک راهنمای 4A داره که شرایط بازخورد دادن و گرفتن رو توضیح داده:برای بازخورد دادن، راهنمایی‌اش اینه که می‌کنه هدف باید کمک‌کردن باشه (Aim to Assist) و اجراشدنی باشه (Actionable)؛ یعنی بازخورد باید روی این تمرکز کنه که طرفِ مقابل چه کاری رو لازمه متفاوت انجام بده.به بازخوردگیرنده هم توصیه می‌کنه که قدردان باشه (Appreciate) و بازخورد رو بپذیره یا رد کنه (Accept or Discard)؛ به این معنی که حق پذیرش یا ردِ بازخورد با بازخوردگیرنده‌ست و لزومن نباید تغییری توی رفتارش بده.تأکید می‌کنه فرهنگ «صداقت» منجر نمی‌شه که هر کی هر چی دلش خواست بگه، بلکه فضایی رو فراهم می‌کنه که آدم‌ها به‌دقت به راهنمای 4A فکر کنن و در زمان و مکان درست بازخورد بدن و بگیرن.حذف کنترلوقتی بهترین‌ها رو استخدام کردیم و فرهنگ بازخورد دادن و گرفتن رو جا انداختیم، می‌تونیم سازوکارهای کنترل رو حذف کنیم. مثال‌هایی از حذف قوانینِ مرخصی‌‌گرفتن و خرج‌کردن به حسابِ شرکت زده.این‌جا نکته‌های زیادی هست؛ از جمله این‌که لیدر خودش باید از این قوانین تبعیت کنه. این‌طوری نباشه که لیدر بگه «همه هر چقدر دلشون می‌خواد می‌تونن مرخصی بگیرن.» و خودش ۲۴/۷ سرِ کار باشه. اِرین (Erin) نوشته خودِ رید حداقل ۶ هفته از سال رو به تعطیلات می‌ره.در نبودِ قانونْ شرایطی که به تصمیم‌گیری افراد کمک می‌کنه باید فراهم باشه. از خرج‌کردن در سفر به حسابِ شرکت مثال می‌زنه: مدتی راهنمای پیشنهادشده در نتفلیکس این بود که «هر جوری توی سفرهای شخصی خرج می‌کنی، توی سفرهای کاری هم خرج کن.» که دیدن جواب نمی‌ده؛ بعضی‌ها توی سفر شخصی جوری خرج می‌کردن که توی سفر کاری نباید اون‌جوری می‌بودن. مثلن اگه کارمندی در سفر شخصی، از منوی رستوران همبرگر برای خودش سفارش می‌ده، در ضیافتِ شام با مدیرِ یک شرکتِ چند بیلیون‌دلاری شاید نباید همبرگر سفارش بده!این شد که اون اصل رو به «کاری رو بکن که به نفع نتفلیکس باشه.» تغییر دادن و قضاوت رو هم به خودِ افراد سپردن.این‌جا بحث می‌شه که «اگه آدم‌ها سوءاستفاده کنن چی؟» و جواب کوتاهش اینه که: عده‌ای سوءاستفاده خواهند کرد. اخراج هم می‌شن و اعلام هم می‌شه که اخراج شدن، چون ازین آزادیِ عمل با بی‌مسئولیتی استفاده کردن؛ ولی ریسک سوءاستفاده‌ی اقلیت، نباید منجر به اذیت‌شدنِ اکثریت بشه. یادمون نره که بهترین‌ها رو استخدام کردیم و فرهنگ بازخورد هم داریم.پرداخت بالاترین دستمزددر ابتدا طبقه‌بندیِ ساده‌شده‌ای از مشاغل ارائه می‌ده و اون‌ها رو به دسته‌های عملیاتی و خلاقانه تقسیم می‌کنه. بحث اینه که در کارهای عملیاتی مثل رانندگی یا بستنی‌فروشی، کارمندِ عالی نمی‌تون خیلی بهتر از کارمندِ معمولی باشه. اما در مشاغل خلاقانه مثل مهندسی نرم‌افزار، کارمند عالی می‌تونه صد برابر بهتر از کارمند معمولی باشه.نتیجه می‌گیره که منطقیه دستمزد به‌نسبت بالایی به این گروه از مشاغل بدیم. این دستمزد در نتفلیکس باید بالاترین دستمزد در بازار باشه که برای هر فرد هم متفاوته.پاداش‌های مشروط به عملکرد در نتفلیکس وجود نداره؛ چون آینده رو نمی‌شه پیش‌بینی کرد و خودِ کارمند هم شاید نقش پررنگی در تعیین «عملکردِ خوب» نداشته باشه که به‌خاطرش پاداش بگیره. بعلاوه، انعطاف سازمان هم کم می‌شه چون کارمند برای رسیدن به اون پاداش ممکنه نفع شخصی‌ش رو بهینه کنه ولی ممکنه شرکت به‌یکباره بخواد تغییرِ جهت بده و تعریف «عملکردِ خوب» رو عوض کنه. این‌جا تضادِ منافع بین شخص و سازمان پیش میاد و منجر به نارضایتی می‌شه.علاوه بر این، اعتقاد دارن که برای کارمندانی با عملکرد استثنایی پاداش منجر به تلاش بیش‌تر نمی‌شه، چون پاداش نیست که به این افراد انگیزه می‌ده.به‌طور کلی، هزینه‌ی از دستن دادنِ آدم‌ها برای نتفلیکس بسیار بیش‌تر از اینه که دستمزد بیش‌تری به کارمندان‌شون بدن.آزادیِ دسترسی به اطلاعاتدر بخش open the books، از محرمانگی و شفافیت می‌گه. بحث می‌کنه که اگر می‌خوایم فرهنگِ شفافیت رو جا بندازیم، نمی‌تونیم به چیزها قفل بزنیم؛ این «چیز» می‌تونه درِ یک اتاق یا کمد باشه یا استراتژی محصول. این محدودسازی‌ها باعث می‌شه کارمندان خودشون رو «خودی» ندونن و حس تعلق نسبت به سازمان نداشته باشن.مثال‌هایی می‌زنه از چیزهای مرموز!:به تغییرِ ساختار فکر می‌کنی و عده‌ای ممکنه کارشون رو از دست بدن.کارمندی رو اخراج کردی ولی توضیحِ دلیلش منجر به خدشه‌دار شدنِ اعتبارِ طرف می‌شه.دستورالعمل محرمانه‌ای داری که نمی‌خوای به‌دستِ رقیب بیافته.اشتباهی کردی که ممکنه منجر به لطمه‌‌دیدنِ اعتبار یا نابودشدنِ کارِت بشه.دو لیدر با نظراتِ مخالف داری که اگه اعضای تیم‌شون بفهمن، وضع بِهم می‌ریزه.کارمندان ممکنه به‌دلیلِ انتشار اطلاعات مالیِ خاص با دوستانشون، به زندان بی‌افتن.مسئولیت اشتراک هر نوع اطلاعاتی رو به لیدرها سپردن که تا حد امکان با همه به‌اشتراک بذارن. فعالانه سعی می‌کنن که این اطلاعات در اختیار همه قرار بگیره.در این‌جا مثال‌هایی از تصمیم برای اخراج و چگونگیِ اطلاع‌رسانیِ این تصمیم به افراد می‌زنه. خلاصه‌ی بحث اینه که ضمن مد نظر قرار دادنِ حریم شخصیِ افراد وقتی موضوعِ شرکت مطرحه، همه‌ی حقیقت رو به کارمندان بگیم و مثل آدم‌های بالغ باهاشون رفتار کنیم.برای کارمندان نتفلیکس شفافیت بزرگ‌ترین نمادِ اعتمادِ به افراد برای عملِ مسئولانه‌ست. این اعتماد منجر به ایجادِ حس مالکیت، تعهد و مسئولیت در اشخاص می‌شه.آزادیِ تصمیم‌گیریوقتی همه‌ی تصمیم‌ها بخواد از مدیران رد بشه سرعت کارها و خلاقیت کم می‌شه. بنابراین هر کسی مسئوله توی جایگاهی که هست خودش تصمیم بگیره. اِرین این موضوع رو در مورد خودِ رید وقتی حس کرد که ازش پرسید چقدر برای نوشتنِ همین کتاب می‌تونه وقت بذاره؟ جواب رید این بود: «هر قدری که فکر می‌کنی نیازه.» چرا؟ چون همه‌ی تصمیم‌های نتفلیکس رو مدیرعامل نمی‌گیره. آدم‌های زیادی هستن که این تصمیم‌ها رو بگیرن.به تصمیم‌ها به‌چشم «شرط» در شرط‌بندی نگاه می‌شه. با توجه به این‌که می‌دونیم شانس درست‌بودنِ شرط‌ها زیاد نیست، به‌جای اینکه رئیس کیفیت تصمیم‌ها رو تأیید کنه، ایده رو در حلقه‌ی نوآورانه و به این ترتیب مطرح کنیم:ایده‌ت رو به جمع بگو و مخالفت با ایده رو ترویج کن.اگه ایده‌ی بزرگیه آزمایشش کن.به‌عنوان یک ناخدای مطلع شرط ببند.اگه موفق شد جشن بگیر. اگه شکست خورد عیانش کن! (حاجت به بیان است!)از یکی از مدیران نقل‌قول می‌کنه: «ما از کارمندان انتظار نداریم که پیش از تصمیم‌گیری تأییدِ رئیس‌شون رو بگیرن. ولی می‌دونیم که تصمیم‌های خوب به درکِ درستِ شرایط، گرفتنِ بازخورد از افرادی با نظرات مختلف و آگاهی از همه‌ی گزینه‌ها نیاز دارن.» بنابراین اگر کسی از این آزادیِ فراهم‌شده برای گرفتنِ تصمیم‌های مهم استفاده کرد بدونِ این‌که نظر بقیه رو بدونه، نتفلیکس این رفتار رو ناشی از قضاوت ضعیف فرد می‌دونه.سؤال پیش میاد که «چقدر حاضریم هزینه‌ی شکست‌خوردن‌ها رو بدیم؟» یا «چطور عملکرد آدم‌ها رو ارزیابی می‌کنیم؟» که جواب بسیار ساده‌شده‌ش اینه: دستاورد نهاییِ مجموعه‌ی تصمیم‌هاست که اثرگذاری رو نشون می‌ده، نه فقط یک تصمیم.فصل ۳ از شرایطی گفته که به این فرهنگ کمک می‌کنه، از جمله شیوه‌های سازمانی ارائه‌ی بازخورد و هم‌جهت نگه‌داشتنِ تصمیم‌گیرنده‌ها. خوندنش کمک می‌کنه تصویر واضح‌تری از شرایطِ فراهم‌شده برای کارکردِ این فرهنگ داشته باشید.علاوه بر کتاب، پیشنهاد می‌کنم این مصاحبه رو در مورد کتاب ببینید.ممنونم از باهار ابراهیمی برای خوندن و گرفتنِ اشکالاتِ متن. شایان مهردوست شایان مهردوست Wed, 07 Oct 2020 22:31:42 +0330 https://virgool.io/DivarDesign/%D8%A7%D8%AE%D9%84%D8%A7%D9%82%D9%86%D8%A7%D9%85%D9%87%DB%8C-%D8%B7%D8%B1%D8%A7%D8%AD%D8%A7%D9%86-m4wa3kmkkm3v مایک مانتِیرو طراح باسابقه‌ی آمریکایی و هم‌بنیان‌گذار Mule Design، از پرسروصداترین طراحان این روزهاست. او تصمیمات غیراخلاقی شرکت‌های بزرگ را به چالش می‌کشد و از نقش پررنگ طراحان در شکل دادن به جامعه می‌نویسد. در نگاه مایک، طراحان وظیفه‌ی کم‌اهمیت‌تری نسبت به پزشکان ندارند؛ اگر پزشکان متعهد به رفتار در چارچوب سوگندنامه‌ای اخلاقی می‌شوند، طراحان نیز باید به اخلاق پایبند باشند. با این هدف، او اخلاق‌نامه‌ای نوشته که تا کنون به چندین زبان ترجمه شده است. متنی را که می‌خوانید من از نوشته‌ی اصلی بازگردان کردم.طراح قبل از هر چیز، یک انسان است.‬‫قبل از آن‌که طراح باشید، انسان هستید و مانند همه‌ی انسان‌های روی کره‌ی زمین، بخشی از یک قرارداد اجتماعی هستید. کره‌ی زمین بین ما مشترک است. وقتی انتخاب می‌کنید طراح باشید، انتخاب کرده‌اید که بر انسان‌هایی که با کارِ شما در تعامل هستند اثرگذار باشید؛ با کارتان، یا به آن‌ها کمک می‌کنید یا آسیب می‌رسانید. در کار خود، همیشه اثر آن‌چه را که به جامعه وارد می‌کنید مد نظر قرار دهید.‬‫همه‌ی انسان‌هایی که روی کره‌ی زمین زندگی می‌کنند، باید تلاش کنند زمین را بهتر از آن‌جور که بوده ترک کنند. طراحان از این قاعده مستثنی نیستند.‬‫اگر کاری می‌کنید که موفقیتِ آن در گروِ اختلافِ درآمد یا تفاوتِ طبقاتی است، در انجام کارِ خود به‌عنوانِ یک شهروند و نیز طراح شکست خورده‌اید.‬طراح مسئولِ کاری‌ست که به جهان ارائه می‌کند.‬‫طراحی حوزه‌ای عملی است. شما مسئول چیزی هستید که به جهان ارائه می‌کنید. نام شما بر آن حک شده است. اگرچه نمی‌توان پیشبینی کرد کارهای شما چطور مورد استفاده قرار خواهند گرفت، اما وقتی کاری که در جهت آسیب‌رساندن به دیگری انجام شده به موفقیت می‌انجامد، نباید عجیب باشد. اگر سلاحی که طراحی کردیم انسانی را بکُشد، نباید تعجب کنیم. اگر پایگاه‌داده‌ای که برای فهرست‌کردنِ مهاجران طراحی کردیم، منجر به اخراج آن مهاجران از کشور بشود، نباید شگفت‌زده شویم. وقتی آگاهانه کاری می‌کنیم که هدفِ آن آسیب‌رساندن است، از مسئولیت خود سر باز زده‌ایم. وقتی با بی‌توجهی نسبت به عواقب کار، چیزی تولید می‌کنیم که به دیگران آسیب می‌رساند، چندباره مقصریم.‬‫کاری که به جهان ارائه می‌کنید، میراث شماست؛ پس از شما باقی می‌ماند و از جانب شما سخن می‌گوید.‬طراح به اثرگذاری بیش از شکل اهمیت می‌دهد.‬‫بیش از آن‌که عاشق هوشمندی ایده‌هایمان باشیم، باید از پیامدهای کارمان بترسیم.‬‫طراحی مستقل از اطرافش نیست. جامعه بزرگترین سیستمی‌ست که می‌توانیم بر آن اثر بگذاریم و هر کاری که می‌کنید – خوب یا بد — بخشی از اسلوب آن است. در نهایت، ما باید ارزش کارمان را براساس همان اثرگذاری قضاوت کنیم، نه ملاحظات زیبایی‌شناسانه. نمی‌توان گفت چیزی که برای آسیب‌رساندن به انسان‌ها ساخته شده، خوب طراحی شده، چون صَرفِ نظر از زیباییِ لذت‌بخشی که می‌تواند داشته باشد، طراحیِ خوبِ آن مساوی‌ست با آسیب‌رساندن به دیگران. چیزی که رژیم تمامیت‌خواه طراحی کرده، خوب طراحی نشده چون اساسن رژیمی تمامیت‌خواه آن را طراحی کرده است.‬طراح به کسی که او را استخدام کرده است، نه فقط کار، بلکه مشاوره بدهکار است.‬‫وقتی برای طراحیِ چیزی استخدام شدید، برای تخصصتان استخدام شده‌اید. شغل شما فقط ارائه‌ی کار نیست بلکه ارزیابی اثرِ آن کار نیز هست. شغل شما آگاهی‌بخشیدن به کارفرما یا مشتری از اثرگذاری آن کار است. اگر این اثر منفی‌ست، وظیفه‌ی شماست که به مشتری اطلاع دهید، و در صورت امکان، اثر منفی آن کار را از بین ببرید. اگر از بین بردن اثر منفی کار ممکن نیست، وظیفه‌ی شماست که جلوی آن را بگیرید. به بیان دیگر، شما فقط برای حفر یک چاله استخدام نشدید، بلکه ارزیابی اقتصادی، جامعه‌شناختی و زیست‌محیطی اثر آن چاله نیز به‌عهده‌ی شماست. اگر این چاله نتوانست امتحانش را پس دهد، وظیفه‌ی شماست که بیل را از بین ببرید.‬‫طراح بی‌آنکه خدمتگزار باشد، از تخصصش برای خدمت به دیگران استفاده می‌کند. «نه» گفتن یک مهارت طراحی‌ست؛ پرسیدنِ «چرا» یک مهارت طراحی‌ست؛ اما «پشت چشم تنگ کردن» نه. به‌مراتب بهتر است از خودمان بپرسیم که چرا چیزی را می‌سازیم به‌جای آن‌که بپرسیم آیا می‌توانیم آن را بسازیم یا نه.‬طراح از نقد استقبال می‌کند.‬‫هیچ دستوری اخلاقی نباید از کار شما در برابر نقد مشتری، عموم یا سایر طراحان محافظت کند. برعکس؛ شما باید تشویق به نقد کنید تا در آینده کار بهتری بسازید. اگر کارِ شما به‌حدی آسیب‌پذیر است که توانایی مقابله با نقد را ندارد، اساسن نباید وجود داشته باشد. زمانِ آزمودنِ چرخ‌ها پیش از وقتی‌ست که به جاده برخورد می‌کنند. پذیرای نقد از هر سویی باشید.‬‫نقش نقد، اگر درست طرح شود، ارزیابی و بهبود کار است. نقد یک هدیه‌ست. کار خوب را بهتر می‌کند و جلوی کار بد را می‌گیرد.‬‫در هر مرحله از فرایند طراحی باید درخواست نقد کرد و آن را پذیرفت. نمی‌توانید کیک را پس از پخته شدن اصلاح کنید. اما با دریافت بازخوردِ زودهنگام و پیوسته، می‌توانید شانس موفقیت پروژه‌تان را بیشتر کنید. شما مسئول درخواست نقد هستید.‬طراح می‌کوشد مخاطبش را بشناسد.‬‫طراحی راه‌حلی حساب‌شده برای حل یک مسئله در چارچوب محدودیت‌هاست. برای آن‌که بدانید مسئله‌ای را به‌درستی حل می‌کنید، لازم است کسانی را که آن مسئله را دارند ملاقات کنید، و اگر عضوی از تیم هستید، تیم شما باید بکوشد مسئله‌ی این افراد را منعکس کند. هر چه یک تیم بتواند مخاطبی را که مسئله‌اش را حل می‌کند بهتر نمایندگی کند، دقیق‌تر می‌تواند آن مسئله را حل کند. آن تیم می‌تواند از زوایا، زمینه‌ها، نیازها یا تجربه‌های مختلفی سراغ مسئله بیاید. تیمی که تنها یک نقطه‌نظر دارد، به‌خوبیِ تیمی با چند نقطه‌ی دید، محدودیت‌هایی را که برای آن‌ها طراحی می‌کند درک نخواهد کرد.‬‫پس همدلی چه؟ همدلی لغت زیبایی برای چشم‌پوشی است. اگر می‌خواهید بدانید که زن‌ها چطور چیزی که طراحی کرده‌اید را استفاده خواهند کرد، یک زن را وارد تیم طراحی کنید.‬طراح به موارد حاشیه‌ای اعتقادی ندارد.‬‫وقتی انتخاب می‌کنید برای چه‌کسی طراحی می‌کنید، به‌طور ضمنی می‌گویید برای چه کسی طراحی نمی‌کنید. ما سال‌ها افرادی را که برای موفقیت محصولمان حیاتی نبودند «موارد حاشیه‌ای» نامیدیم. مردم را به حاشیه راندیم و تصمیم می‌گرفتیم که در جهان، مردمانی زندگی می‌کنند که حل مسائلشان اهمیت ندارد.‬‫فیسبوک مدعی‌ست دو میلیارد کاربر دارد. یک درصدِ دو میلیارد نفر، که بسیاری از محصولات آن را موردی حاشیه‌ای می‌دانند، بیست میلیون نفر می‌شود. آن‌ها انسان‌هایی در حاشیه‌اند.‬‫«وقتی چیزی را مورد حاشیه‌ای می‌نامید، تنها حدود اهمیت‌دادنِ خود را مشخص کرده‌اید.» — اریک میِر‬‫آن‌ها مردمِ تِرَنسی هستند که در حاشیه‌ی پروژه‌ای با «اسم واقعی» گیر می‌افتند. آن‌ها مادرانِ مجردی هستند که در حاشیه‌ی برگه‌ی مجوز «هر دو والد باید امضا کنند» گیر می‌افتند. آن‌ها مهاجران مسنّی هستند که پای صندوق‌های رأی حاضر می‌شوند اما نمی‌توانند برگه‌ی رأی را به زبانِ مادری خود تحویل بگیرند.‬‫آن‌ها موارد حاشیه‌ای نیستند. آن‌ها انسانند و ما بهترین کارمان را به آن‌ها بدهکاریم.‬طراح عضوی از یک اجتماع حرفه‌ای‌ست.‬‫شما عضوی از یک جامعه‌ی حرفه‌ای هستید و رَوش کاری و رفتارِ حرفه‌ای شما بر همه‌ی افرادِ آن جامعه اثرگذار است؛ همان‌طور که موجِ خیزان بر همه‌ی قایق‌ها، و مدفوع کردن در استخر بر همه‌ی شناگران اثرگذار است. اگر با مشتری یا کارفرما صادق نباشید، طراحِ بعد از شما بهای آن را خواهد پرداخت. اگر رایگان کار کنید، از طراح پس از شما هم چنین انتظاری خواهد رفت. اگر در برابر کارِ بد ایستادگی نکنید، طراح بعدی برای جبران باید دو برابر سخت‌تر کار کند.‬‫به‌لحاظ اخلاقی طراحان باید تا آن‌جا که توانایی و فرصت‌ها اجازه می‌دهد درآمد کسب کنند، اما فدا کردنِ کسانی که پیشه‌ی مشترکی دارند، ظلم در حق همه است. هیچ‌گاه برای رسیدن به اهدافتان، طراح دیگری را قربانی نکنید. این موضوع شامل بازطراحی عمومیِ کارِ شخصی دیگر، فراخوان طراحی، کار داوطلبانه و سرقت هنری است.‬‫طراح باید به‌دنبال ساخت اجتماع باشد، نه ازهم‌گسستن آن.‬طراح از گوناگونی و رقابت استقبال می‌کند.‬‫طی تمام دوره‌ی کاری، طراح سعی می‌کند بیاموزد؛ به‌این معنا که با آن‌چه نمی‌داند روبرو می‌شود، به تجربه‌های سایرین گوش می‌دهد، از افرادی که پیش‌زمینه و فرهنگ گوناگونی دارند استقبال و آن‌ها را تشویق می‌کند و برای افراد جداافتاده از اجتماع، جا باز می‌کند. ما طراحان باید برای شنیده‌شدنِ صداهایی که ‌کم‌تر شنیده شده‌اند، در این پیشه فضایی ایجاد کنیم. گوناگونی منجر به نتایج و راه‌حل‌های بهتری می‌شود. گوناگونی به طراحی بهتری می‌انجامد.‬‫یک طراح همیشه خوددار است، می‌داند که چه‌وقت باید خفه شود و گوش کند، به سوگیری‌های خود آگاه است و از بازرسیِ آن استقبال می‌کند، و می‌جنگد تا برای کسانی که ساکت شده‌اند فضایی بسازد.‬طراح برای ارزیابی خود وقت اختصاص می‌دهد.‬‫هیچ‌کس پس از برخاستن از خواب، به‌ناگاه در طراحی اخلاق را کنار نمی‌گذارد. این اتفاق به‌آهستگی می‌افتد، لغزشی از پسِ لغزش دیگر. مجموعه‌ای از تصمیمات کوچک است که در ابتدا حتا خوب به‌نظر می‌رسند، و ناگهان به خود می‌آیید و متوجه می‌شوید که در حال طراحی واسط کاربرِ فیلتری برای فروشگاه آنلاین اسلحه‌ی والمارت هستید.‬‫هر چند ماه، وقتی را برای خودارزیابی اختصاص دهید. تصمیم‌هایی که به‌تازگی گرفته‌اید را ارزیابی کنید. آیا به باورهایتان وفادار مانده‌اید؟ یا آهسته آهسته دروازه‌های اهداف اخلاقی خود را با هر ارتقا یا پاداشِ سهام چند متر جابه‌جا می‌کنید؟‬‫از راه منحرف شدید؟ درستش کنید. محل کارتان جهنمی غیراخلاقی‌ست؟ جای دیگری را انتخاب کنید.‬‫شغل شما یک انتخاب است. لطفن درست انتخاب کنید.‬ممنونم از علی رستگار، مهدی رحمن و جمال احمدی برای خواندن متن و کمک به ترجمه‌ی بهتر. شایان مهردوست شایان مهردوست Tue, 25 Feb 2020 12:53:11 +0330 https://virgool.io/DivarDesign/%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%AF%DB%8C%D9%88%D8%A7%D8%B1-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%87%D9%85%D9%87-axerqsexucom در سال گذشته، ما در تیم طراحی و توسعه‌ی دیوار اصولِ طراحیِ مقیاس‌پذیر (scalable) و دسترس‌پذیر (accessible) را به‌کار گرفتیم. در این یادداشت، از روندی نوشتم که برای بهبود طراحی و دسترس‌پذیری برنامه‌ی اندرویدِ دیوار (نسخه‌ی ۱۱) طی کرده‌ایم.طراحی و دسترس‌پذیریطراحان همیشه سعی می‌کنند هزینه و فایده‌ی فرصت‌های مختلف را بسنجند و تصمیمی آگاهانه بگیرند. اما گاهی سوگیری‌ها جلوی تشخیص مسئله و تصمیمِ درست را می‌گیرد؛ ممکن است دانشِ آدم‌ها را اشتباه تخمین بزنند یا برای توانایی دیگران، حد نُرمال یا متوسطی فرض کرده و شروع به حل مسئله با پیش‌فرض‌های نادرستی کنند. اما در دنیای واقعی «توانایی متوسط» وجود ندارد. در اینتراکشن انسان–کامپیوتر (HCI)، کم‌توانی فقط محصولِ محدودیت‌های فردی نیست، بلکه ناشی از محدودیت‌هایی است که کامپیوتر به انسان تحمیل می‌کند.کم‌توانی انواع و گستره‌ی متفاوتی دارد. بیش از یک میلیارد نفر گونه‌ای از کم‌توانی دارند. ۹ درصد از جامعه، به اختلالات بینایی (رنگ‌بینی، کم‌بینی و نابینایی) مبتلا هستند. در ایران دست‌کم ۶۰۰ هزار کم‌بینا و ۱۵۰ هزار نابینا زندگی می‌کنند.هدف از دسترس‌پذیر کردنِ یک محصول یا سرویس این است که استفاده از آن برای افراد کم‌توان امکان‌پذیر باشد. در دنیای فناوری، اَپل دسترس‌پذیری را حقی انسانی می‌داند، مایکروسافت جعبه‌ابزاری برای کمک به طراحی فراگیر (inclusive) دارد و گوگل در راهنمای طراحیِ متریال بر آن تأکید می‌کند.طراحی مقیاس‌پذیربیش از ۱۹ میلیون نفر از دیوار استفاده می‌کنند که نیازها و توانایی‌های متنوعی دارند. برای آن‌که گوناگونی‌ها را بهتر بشناسیم و دید بهتری نسبت به محدودیت‌های فردی داشته باشیم، ابتدا به پژوهش و مصاحبه پرداختیم؛ اما پیش از شروع طراحی و برای ایجاد تغییرات گسترده ولی کم‌هزینه در محصولی همچون دیوار، به زیرساختی مقیاس‌پذیر و زبانی مشترک میانِ تیم طراحی و مهندسی نیاز داشتیم. به‌این ترتیب می‌توانستیم به‌جای تغییرات مقطعی و کوتاه‌مدت، از دسترس‌پذیری تمامِ اجزای سیستم مطمئن باشیم.بنابراین، سال گذشته شروع به ساختِ سیستمِ مقیاس‌پذیری برای طراحی و توسعه‌ی دیوار کردیم. نام دیزاین‌سیستمِ دیوار را «سنّت» گذاشتیم. سنّت، مجموعه‌ای از اصول طراحی و پیاده‌سازی، و زبانِ مشترکِ اعضای تیم است. ما برنامه‌ی اندروید دیوار را به اجزای سازنده‌اش – مشخصه‌ها، عناصر و کامپوننت‌ها – تجزیه کردیم و هر جزء را طبق اصول و راهنمای طراحی اینتراکشن (مانند Material و HIG) و با رویکردی شبیه به طراحی اتمی، بازبینی و بازطراحی کردیم. سپس اجزای طراحی‌شده را در کتابخانه‌ای توسعه دادیم.پیاده‌سازی سنّت، زمینه‌ای را فراهم کرد تا بتوانیم اجزای دیوار را یک به یک وارسی کنیم و دسترس‌پذیریِ آن‌ها را با استانداردها مقایسه کنیم. در یادداشت دیگری از روندی که برای طراحی آن طی کردیم خواهم نوشت.بهبودِ دسترس‌پذیریبا مطالعه و رعایتِ اصولِ دسترس‌پذیری در طراحی و توسعه‌ی دیزاین‌سیستمِ دیوار، سعی کردیم قدم کوچکی برداریم و استفاده از برنامه‌ی دیوار را برای جامعه‌ی بزرگتری – فارغ از حدودِ توانایی‌هایشان – فراهم کنیم. مهم‌ترین کارهایی که انجام دادیم:با هدف افزایش قابلیت دستیابی (reachability)، اجزای اینتراکتیو (interactive) اصلی مانند دکمه‌ها را طوری جایگذاری کردیم که استفاده از گوشی با یک دست راحت‌تر باشد.اندازه‌ی اجزای اینتراکتیو را به‌حدی تعیین کردیم که لمس و انتخابِ آن‌ها برای افرادی که لرزشِ دست دارند، آسان‌تر باشد.با رعایت اصول نویسه‌نگاری و صفحه‌آرایی، از فونتِ مقیاس‌پذیر استفاده کردیم تا افراد بتوانند متن را در ابعادی متناسب با اندازه‌ی فونتِ گوشی‌شان بخوانند.با بازبینی همه‌ی نماهای دیوار، مطمئن شدیم طیف گسترده‌ای از افراد مبتلا به رنگ‌بینی در استفاده از برنامه مشکلی نداشته باشند. از Stark برای این کار کمک گرفتیم.تباین (contrast) رنگِ نوشته‌های دیوار را مطابق با استاندارد سطح AA تغییر دادیم. چون ابزارهای موجود امکان مقایسه‌ی همزمان چند رنگ یا امکانِ تعریف رنگ با شفافیت را نداشتند، خودمان ابزاری را توسعه دادیم.اجزای اینتراکتیو و اطلاعاتی (informational) دیوار برچسب‌گذاری و با ابزارهای تبدیل متن به گفتار (Talkback + eSpeak) هماهنگ کردیم تا نابینایان بتوانند از دیوار استفاده کنند.برای کاربران حساس به نور، پروژه‌ی «شامگاه» را طراحی و پیاده‌سازی کردیم که در ادامه توضیح خواهم داد.از این منابع کمک زیادی گرفتیم:Mismatch: How Inclusion Shapes Design, Kate Holmes (لینک)Inclusive Design Toolkit, Microsoft (لینک)Accessibility - Material Design, Google (لینک)Web Content Accessibility Guidelines (لینک)مقاله‌ها: اثر سن بر طراحی راه‌بری، اندازه‌ی قلم، اجزای اینتراکتیو و آیکونمعتقدیم هنوز راه زیادی در پیش است تا استفاده از دیوار در پلتفرم‌های مختلف، برای طیف وسیع‌تری از کاربران امکان‌پذیر و لذت‌بخش باشد.شامگاهحساسیت به نور یکی از انواع کم‌بینی است. روشناییِ بیش از حد، دیدن را برای افراد مبتلا به این خللِ بینایی، دشوار یا غیرممکن می‌کند و سبب احساسِ درد در سر و چشم می‌شود. کاهش روشنایی صفحه‌ی نمایش گوشی راه‌حلی موقتی است ولی دیدنِ متن و عکس را سخت‌تر می‌کند.برای کاهش این اثرات، در هکاتونِ اسفندماه ۹۷ کافه‌بازار تصمیم گرفتیم حالت شب (night mode) – با نام پروژه‌ی شامگاه – را به دیوار اضافه کنیم. همزمان با استاندارد کردنِ تباین رنگ‌ها در اجزای دیزاین‌سیستم، باید رنگ، شکل و جلوه‌ها را برای هر دو حالتِ تیره و روشن توسعه می‌دادیم. همچنین سیستمی برای نگاشت (mapping) رنگ‌ها نیاز داشتیم تا امکان تغییر کُدِ هر رنگ بسته به کاربرد یا محیط آن وجود داشته باشد.علاوه بر مشکلات بینایی، مصرف بهینه‌ی باتری، کاهش عوارض نور آبیِ صفحه‌ی نمایش و ترجیح جمعی از مردم، حالت شب را به‌راحتی توجیه می‌کند. حدس می‌زنیم برای کاربران دیوار که در ساعاتِ شب بهره‌ی بیشتری از آن می‌برند، این ویژگی حتا مهم‌تر باشد.اگر این‌جور مسائل برای شما هم جذاب است و می‌تونید به تیم ما کمک کنید، سری به این‌جا بزنید. اگر هم پیشنهادی برای بهبودِ دیزاینِ دیوار دارید به ux@divar.ir ایمیل بفرستید. شایان مهردوست شایان مهردوست Wed, 29 May 2019 11:18:33 +0430 https://virgool.io/@shayan/%D8%B5%D8%AD%D8%A8%D8%AA%DB%8C-%D8%A8%D8%A7-%D8%B7%D8%B1%D8%A7%D8%AD%D8%A7%D9%86-shhozlvaiekt تا چند سال پیش وقتی کسی یک وبسایت می‌خواست، یا خودش دست به کار می‌شد یا به‌دنبال طراحِ سایت می‌گشت. طراحِ سایت در ساده‌ترین حالت، کسی بود که دانش کدنویسی وب و سلیقه‌ی قابل قبولی داشت. کمی بعد، کارفرمایانی که سایت‌های خارجی و داخلی را می‌دیدند، سایت قشنگ‌تر و پیچیده‌تری می‌خواستند. دیگر فقط یک نفر جوابگوی نیاز آن‌ها نبود، بنابراین مجموعه‌ای از برنامه‌نویسان و طراحان دور هم جمع می‌شدند و تیم طراحیِ سایت تشکیل می‌دادند. حالا هم که چند سالی‌ست موبایل فراگیر شده و کارفرما به‌دنبال تیم طراحی اپ می‌گردد…به‌طور خلاصه، رشد تکنولوژی نیازهای کار و کسب آنلاین را تغییر می‌دهد، اما طراحی همواره تخصصی مطلوب بوده است. با وجود این، وقتی دو نفر از طراحی حرف می‌زنند، احتمالن درک مشترکی از مفهوم و اهمیت آن ندارند و نقش متفاوتی را برای طراح متصورند؛ به‌طوری که کم‌تر می‌توانیم دو آگهی استخدامِ طراح پیدا کنیم که دانش و توانایی مشابهی را انتظار داشته باشند. متأسفانه طراحان هم تلاش چندانی برای بهبود این وضع نکرده‌اند. تمسخر کارفرما به‌دلیل ناآگاهی یا انتشار ویدئوی طنزی که فقط «دخالت کارفرما در کار طراح» را هدف می‌گیرد کمک چندانی به حل این مسئله نکرده و نمی‌کند.به‌نظرم چند عامل در واضح نبودنِ معنا و مفهوم طراحی و مشخص نبودنِ جایگاه طراحان مؤثر بوده:در زبان انگلیسی، میان کشیدنِ نقش یا نقاشی (drawing) با طرح زدن یا طراحی (design) تفاوت مشخصی وجود دارد. در زبان فارسی، این تفاوت کم‌رنگ است. برای مثال، کسی را که صورت آدم نقاشی می‌کند، طراح چهره می‌نامیم. همین نبودنِ تفکیکِ لغوی بین نقاشی و طراحی، باعث شده عده‌ی زیادی تفاوت نقاشی بروی کاغذ را با طراحی واسط کاربر صرفن در ابزارِ کار بدانند. در نظر اکثر مردم، طراحی معادل «چیزی است که دیده می‌شود و می‌تواند خوشگل باشد». البته طی دهه‌ی گذشته، تعداد زیادی از طراحان گرافیک به طراحی UI تغییر شغل داده‌اند، آن هم بدونِ مطالعه و در نظر گرفتنِ تفاوت کاغذ با صفحه‌ی دیجیتال. این موضوع باعث شده فرق چندانی در خروجیِ کار آن‌ها دیده نشود. پس کارفرما هم تا حدی حق دارد که تفاوتی نبیند!از سویی، مفهوم طراحی یا دیزاین در زبانِ انگلیسی تغییر جالب و هوشمندانه‌ای داشته: می‌دانیم که طراحی در بهترین حالت، «حل مسئله‌ی انسان‌ها» است. برای آن‌که گرافیک و طراحی بصری با معنای بنیادینِ طراحی (حل مسئله) اشتباه گرفته نشود، دیوید کِلی و تیم براون —بنیان‌گذاران IDEO— مفهوم تفکر طراحی (design thinking) را گسترش دادند و سعی کردند روح تازه‌ای به طراحی ببخشند تا اهمیت آن روشن‌تر شود. ما فارسی‌زبانان که در انتقال مفهومِ اولیه‌ی دیزاین یا طراحی مشکل داشتیم، حالا با مشکل انتقال مفهومِ جدیدِ آن روبرو هستیم!در این بین، عده‌ای از طراحانِ ایرانی برای حل مشکل نارساییِ کلمات، تصمیم گرفتند دیزاین را به‌جای طراحی به‌کار ببرند و خود را دیزاینر معرفی می‌کنند. به‌نظرم این موضوع، مشکل گنگ بودنِ طراحی را برای عموم مردم حل نمی‌کند چون کلمه‌ی نامفهوم دیگری به‌جای آن به‌کار رفته است. در این رابطه، صحبت‌های تورج صابری‌وند را که سعی در جا انداختن مفهوم «تفکر طراحی» داشته، بشنوید.این را هم در نظر بگیریم که طراحی مانند علوم مهندسی، گسترده است و حوزه‌های مختلفی دارد. همان‌طور که از مهندس عمران و مهندس کامپیوتر، صرفن به‌دلیل مهندس بودنِ هر دوی آن‌ها، انتظار دانش و تجربه‌ی مشابهی نداریم، از طراح اینتراکشن و طراح خدمات نیز نباید انتظار یکسانی داشته باشیم. همانند علوم مهندسی، علوم طراحی نیز تفاوت و اشتراک زیادی دارند؛ برای مثال، به‌رغم تفاوت‌های طراحی واسط کاربر (UI) و طراحی اینتراکشن (IX)، طراحان UI و IX نباید از اصول کارِ همدیگر بی‌اطلاع باشند.علوم طراحی علاوه بر گستردگی، همواره حوزه‌های جدیدی به طراحی اضافه می‌شود که تا چند دهه‌ی قبل وجود نداشتند. برای مثال، در گذشته که کامپیوتر را مهندسین برای مهندسین می‌ساختند، فقط عملکردِ درستِ آن در حل مسائل پیچیده اهمیت داشت. کامپیوتر به‌معنای واقعی برای افراد غیرمتخصص قابل استفاده نبود. برای آن‌که کامپیوتر بتواند در سازمان‌ها و شرکت‌ها به‌کار بیاید، باید فکری به حال کاربران عادی و کاربردپذیری می‌کردند. چند دهه بعد، احساس در مباحث HCI جایگاه ویژه‌ای پیدا کرد و موجب پدید آمدن مفهوم تجربه‌ی کاربر شد. به‌تبع هر آن‌چه بر کاربردپذیری و تجربه‌ی کاربر اثر می‌گذارد باید طراحی شود.نامفهوم بودن طراحی و مشخص نبودنِ نقش طراح در تیم‌ها یک چالش بزرگ است و حل کردنِ آن به شناختِ بهتر مسئله و همدلی نیاز دارد. گنگ بودن طراحی در لغت، تغییر معنای آن در گذر زمان، گستردگی علوم طراحی، اضافه شدن حوزه‌های جدید به آن و ضعف دانشگاه‌های کشور در معرفی و آموزش این حوزه‌ها را که در نظر بگیریم، همدلی بیشتری میان ما و مردم عادی و کارآفرینانی ایجاد خواهد شد که شناخت درستی از طراحی ندارند. وظیفه‌ی ما طراحان است که نیازها و محدودیت‌های مخاطبین خود را بشناسیم تا بتوانیم در حل مسائل پیچیده‌ی امروزی نقش جدی‌تری ایفا کنیم. شایان مهردوست شایان مهردوست Thu, 05 Apr 2018 20:09:15 +0430