طراح تجربهٔ کاربر در دیوار
پرسش و پاسخ‌های اولین جلسهٔ دیوارِ تجربه
ما در صنف تجربهٔ کاربر دیوار همیشه دوست داریم که با هم‌حرفه‌ای‌هامون صحبت کنیم و از همدیگه یاد بگیریم. یکی از کارهایی که به ذهنمون رسید در این راستا انجام بدیم شروع یک سری رویداد به اسم «دیوار تجربه» است که در اون با افراد مختلف و دربارهٔ موضوعات مختلف صحبت کنیم. طبیعتن خیلی دوست داریم که شما هم با ما همراه باشید و هرجا نکته‌ای برای گفتن یا پرسیدن داشتید دریغ نکنید.
برای رویداد اولمون که در ۷ دی‌ماه ۱۴۰۰ برگزار شد به نظرمون اومد که اول باید خودمون رو به شما مفصل‌تر معرفی کنیم. توی یکی از بلاگ‌های قبلی‌مون باهار معرفی کوتاهی از صنف کرده بود که می‌تونید این‌جا بخونیدش. برای این معرفی مفصل‌تر ازتون خواستیم که سؤالاتتون رو از ما برامون بفرستید تا در این رویداد به اون‌هایی که بیشتر پرسیده شده‌اند جواب بدیم.
پس بریم و قسمت پرسش و پاسخ این جلسهٔ آشنایی رو باهم بخونیم که در اون راجع به ساختار کلی دیوار و صنف تجربهٔ کاربر، طراحی، کاربرپژوهی، تجربه‌نویسی، مهندسی تجربهٔ کاربر و همکاری با صنف تجربهٔ کاربر دیوار صحبت می‌کنیم.
ساختار کلی دیوار و صنف تجربهٔ کاربر
ارزش اصلی دیوار چیه و درآمدش از کجاست؟
- شایان مهردوست (کارگردان صنف تجربهٔ کاربر): دیوار یک بازارگاه (marketplace) و هم‌زمان یک شرکت تِکه (tech). روی این نکته تأکید می‌کنم چون جایگاه تِک خیلی برامون مهمه و ما کمپانی عملیات‌محوری (operational) نیستیم. دیوار یک محصول نیازمندیه (classified) و شبکه‌ای از عرضه‌کنندگان و متقاضیان داره که مثلن در دستهٔ کالا می‌شه فروشنده و خریدار و در دستهٔ خدمات هم می‌شه خدمت‌دهنده و خدمت‌گیرنده. ارزش اصلی‌ای هم که ایجاد می‌کنه به اصطلاح تولید لیده که یعنی دو سر عرضه و تقاضا رو در بازار به هم وصل می‌کنه. درآمدش هم به‌واسطهٔ همین تولید لید از راه در اختیار قرار دادن بسته‌های آگهی و نردبان و پنل‌هایی به سمت عرضه است.
چرا در دیوار به تجربهٔ کاربر اهمیت می‌دید؟
- شایان: از دو جنبه می‌تونم به این سؤال جواب بدم:
اول این که کلن چرا کاربر برای محصول مهمه؟ جوابش اینه که محصول نتیجه‌ی واکنش به نیاز مصرف‌کنندگان اون محصوله. پس مهمه کاربر و نیازهاش رو بشناسیم تا بتونیم راه حل مناسب پیشنهاد بدیم.
دوم این که چرا برای پلتفرم‌هایی مثل دیوار که بازارگاه هستند مهمه؟ چون خودشون عرضه‌کننده هستند و ارزشی که خلق می‌کنند همین دادن لید و در واقع ایجاد شبکه‌ی متصل خریدار و فروشنده و ایجاد امکان تعامل بینشونه. کلن به همین خاطره که تجربهٔ کاربر یا همون UX توی تمام پلتفرم‌ها چه airbnb و چه amazon و چه دیجی‌کالا اهمیت ویژه داره.
چطور توی دیوار برنامه‌ریزی‌ها و اولویت‌بندی‌ها رو انجام می‌دید؟
- شایان: برای جواب به این سؤال اول یک مقدار ساختار محصولی دیوار رو توضیح می‌دم. ما چندتا قبیله (vertical) داریم که تمرکز‌های بیزینسی دیوار رو مشخص می‌کنند و از بیرون دیوار به شکل دسته‌بندی‌های دیوار قابل تشخیص هستند؛ مثل قبیلهٔ املاک یا قبیلهٔ خودرو. تا سال ۹۷ دیوار قبیله نداشت و مشغول فراهم‌کردن ابزارهای تبادل و معامله بود و در واقع به صورت افقی (horizontal) پیش می‌رفت. از سال ۹۷ با تشکیل قبیلهٔ خودرو به سمت تمرکزگرایی حرکت کرد.
در راستای برنامه‌ریزی و اولویت‌بندی در آخر هر سال، در هیئت مدیره و با حضور نمایندهٔ هر قبیله استراتژی سال بعد کل دیوار رو به عنوان یک پلتفرم واحد مشخص می‌کنیم. این استراتژی‌ها شکسته می‌شه و با توجه به تیم‌های داخل هر قبیله ترجمه می‌شه به برنامه‌های فصلی (OKR)، که مجموعه‌ای از اهداف (objectives) و نتایج کلیدی (key results) هستند. در هر تیم اعضا بر اساس پارامترهای مختلف مثل هزینه‌ها، فایده‌ها و این که چقدر منابع انسانی نیازه تصمیم می‌گیرند که کدوم یکی از این اهداف رو انتخاب کنند و داخل برنامهٔ فصلی‌شون بیارند. به این ترتیب استراتژی‌های کلان سالانه در قالب ۴ تا برنامهٔ فصلی در سال توی تیم‌ها اولویت‌بندی می‌شه. البته به صورت ریزتر هم دنبالش می‌کنیم که می‌شه همون راه‌حل‌هایی که برای رسیدن به اون اهداف و نتایج کلیدی که توی تیم تعیین کردیم.
ساختار تیم‌ها و جایگاه اعضای صنف تجربهٔ کاربر توشون به چه شکله؟
- امیر باقری (طراح و مدیر دیزاین سیستم): هر کدوم از قبیله‌های دیوار روی یکی از خط‌های محصولی تمرکز داره که می‌تونند چندتا تیم داشته باشند. در واقع شکسته‌شدن به چند تیم برای تمرکزِ جزئی‌تر روی بخش‌های مختلف اون خط محصولیه. این تیم‌ها به صورت عملکرد متقابل (crossfunctional) کار می‌کنند و توی هر تیم حداقل یک نفر از تمام تخصص‌هایی که توی دیوار داریم حضور داره. هر کدوم از این تخصص‌ها خودشون توی دایره‌های دیگه‌ای منحصر به تخصصشون حضور دارند که بهشون چپتر می‌گیم. پس در واقع اعضای هر چپتر تخصص یکسان دارند. صنف تجربهٔ کاربر هم خودش شامل ۴ تا چپتر می‌شه: چپتر طراحی، چپتر کاربرپژوهی، چپتر تجربه‌نویسی و چپتر مهندسی - البته یک طراح دیداری هم در کنار این چپترها داریم. هر کدوم از اعضای چپترها به جز در چپتر تجربه‌نویسی و مهندسی به یک تیم اختصاص دارند و در اون بخش از محصول کار می‌کنند.
دینامیک بین تیم‌ها و چپترها به چه شکله؟
- امیر: تیم‌ها با توجه به بخشی از محصول که روش کار می‌کنند ممکنه جلساتی رو باهم داشته باشند؛ مثل جلسات محصولی، جلسات استراتژی، جلسات فصلی و ... . ما به عنوان اعضای صنف با توجه به این که بیشتر ارتباطمون با تیم محصولی‌مون هست، بیشتر جلسات هماهنگی کارهامون رو داریم که به صورت هفتگی برای به‌روزرسانی همدیگه برگزار می‌شه و راجع به کارهاییه که در هفته می‌کنیم و اگر لازم بود به همدیگه کمک می‌کنیم. جلسات هم‌آموزی هم داریم که سعی می‌کنیم یاد بدیم و یاد بگیریم. یک سری جلسات نقد دیزاین هم هست که مخاطبش بیشتر طراح‌ها است که راجع به دیزاین‌هایی که توی تیم‌های مختلف مشغول انجامش هستیم صحبت و بحث و به هم کمک می‌کنیم. ارتباطات جزئی‌تری هم مثل ارتباط مدیر محصول با طراح و یا با تحلیل‌گر داده و ... هست که توی تیم اتفاق می‌افته.
برای رشد و یادگیری چه کاری انجام می‌دید؟
- آزاده آقایی (لیدر سابق چپتر طراحی): من برداشت خودم رو از این سؤال توضیح می‌دم که متمرکز بر رشد طراح‌ها است. به طور کلی وقتی ما از رشد افراد توی حوزه‌ی دیزاین حرف می‌زنیم به سه حوزهٔ اصلی اشاره داریم:
۱. حوزهٔ محصولی: این که من چطور به عنوان یک طراح با کشف مسئله، با تعیین اهداف درست و به خصوص با حل مسئله روی محصول اثر می‌ذارم؟
۲. فرآیند و اجرا: که چطور دیزاین رو اجرا می‌کنم و به صورت قابل توسعه تحویل می‌دم؟
۳. حوزهٔ انسانی
صحبت دربارهٔ رشد طراحان توی سازمان متفاوته با رشد طراح توی آژانس‌های طراحی یا طراح فریلنسر. من راجع به رشد افراد توی سازمان صحبت می‌کنم و در بستر دیوار چون بستر خیلی مهمه. توی سازمانی مثل دیوار - همون‌طور که بچه‌ها توضیح دادند - تیم‌های محصولی زیادی وجود داره که همه‌شون در راستای یک هدف مشترک، استراتژی کلی و مشترک سازمان حرکت می‌کنند. این‌جا چند تا بستر وجود داره. یکی بستر چپتر یا صنفه، یکی بستر کلی محصول و یکی خود تیمیه که طراح توش فعالیت می‌کنه - این توضیح می‌تونه به هر تخصصی توی تجربهٔ کاربر بسط پیدا کنه. در این بسترهایی که توضیح دادم یک سری فرصت به طبع وجود داره که ناشی از شرایط خاص اون شرکت یا سازمان هم هست. ما این‌جا چند تا مورد رو لحاظ می‌کنیم:
- علاقه و استعداد شخصی خود طراح، ما چه نیازی توی تیم‌هامون داریم، و به طور کلی دیوار چه نیاز محصولی داره که آدم‌ها بتونند در اون راستا فرصتی براشون خلق بشه و رشد بکنند. برای رشد شخصی هر نفر با هر تخصصی سازمان بودجهٔ آموزشی تدارک می‌بینه تا بتونند هر چیزی که لازم دارند رو یاد بگیرند و در کارشون استفاده کنند.
- همچنین ممکنه طراحان بنا به نیازشون و مسائلی که در حال حلشون هستند در جریان کار، خودشون یاد بگیرند.
- در کنارش هم یک سری فرصت‌های رشد توی صنفمون داریم. یک، جلسات هم‌آموزیه که امیر هم مثال زد. ما الان ۳۱ نفر با ۵ تخصص مختلف هستیم و در کنار هم کار می‌کنیم. این به ما فضایی می‌ده که جمع بشیم و به همدیگه یاد بدیم و یاد بگیریم. فضای دیگه‌ای هم داریم مثل بلاگ دیزاین دیوار. یک بخش از این بلاگ اینه که آدم‌ها دارند با بیرون اشتراک تجربه می‌کنند. ما معتقدیم خود همین فرآیند اشتراک‌گذاری، خود فرآیند نوشتن و خود تلاشی که برای قابل درک بودن ارائه برای مخاطب بیرونی می‌کنیم و خود برقراری ارتباط باعث رشد می‌شه و ما رو ارائه‌دهنده‌ها و مرتبط‌های بهتری می‌کنه. ما باور داریم که جدا از این که با شما دانشمون رو به اشتراک می‌ذاریم، خودمون هم رشد می‌کنیم.
طراحی
تفاوت طراح محصول با طراح تجربهٔ کاربر چیه؟
- شایان: ما توی شرکت اصلن همچین تمایزی نداریم. ما این جا از UX به عنوان یک عبارت چتری استفاده می‌کنیم که چند تا بخش مختلف رو شامل می‌شه. کاری که طراح‌های تجربهٔ کاربر انجام می‌دند توی یک جای دیگه ممکنه به اسم طراح محصول باشه. پس تابع شرکت‌هاست که چه عنوانی رو به این مسئولیت‌ها می‌دند. پس برای ما توی دیوار تفاوت خاصی وجود نداره. پیشنهاد می‌کنم که زمان استخدام در هر جایی شرح وظایف اون عنوان رو بخونید و اگر می‌تونید با کسایی که در اون جایگاه کار می‌کنند صحبت کنید و بفهمید که انتظارات ازشون و مسئولیت‌هاشون چیه چون از روی عنوان خیلی چیزی متوجه نمی‌شه شد.
فرآیند حل مسئله‌تون چیه؟
- عاطفه راهدان (طراح): سؤال خیلی کلیه پس من هم خیلی کلی جواب می‌دم: با این پیش‌فرض که ما برنامه‌های فصلی داریم، وقتی می‌ریم سراغ مسئله‌ای، اولین کاری که باید بکنیم اینه که بگیم اون مسئله در راستای کدوم هدفمون و کدوم نتیجهٔ کلیدیه و چرا دنبال حل این مسئله هستیم. علاوه بر این هر مسئله اصولن یا از دل یک سری نقاط دردِ (pain point) کاربرها به دست اومده یا یک سری داده از کاربرهامون از راه پژوهش‌ها و تحلیل داده‌ها گرفتیم که به ما نشون می‌ده کاربر این مسئلهٔ خاص رو داره. توی این قسمت پژوهشگرها، بچه‌های داده و مدیرمحصول و طراح مشارکت می‌کنند تا بتونیم مسئله رو شفاف‌سازی بکنیم. خلاصه در گام اول باید بدونیم دقیقن مشکل کاربر چیه؟ توش عمیق می‌شیم و اگر لازم بود پژوهش بیشتری انجام می‌دیم. می‌بینیم که برای چه کسایی این مسئله رو حل می‌کنیم و اصلن چقدر حلش مهمه؟ بنابراین شفاف‌سازی یکی از اولین گام‌هاییه که توی فرآیندهامون طی می‌کنیم.
بعد از این که تعریف مسئله (problem statement) مشخص شد با تیممون ایده‌پردازی می‌کنیم که چه راه‌حل‌هایی به ذهنمون می‌رسه تا بتونیم این مسئله رو حل کنیم. خروجی این جلساتِ طوفان فکری یک سری نتیجه‌های اجراییه (actionable) که به یک راه‌حل منتخب ختم می‌شه. بر اساس تفاوت پروژه‌ها و تیم‌ها ممکنه یا به یک راه حل منتخب برسیم (که بر اساس اثرگذاری و هزینه بهش رسیدیم) و یا چند راه‌حل. که در این صورت ممکنه باز پژوهش کنیم یا تست انجام بدیم تا ببینیم کدوم بهتره. بنابراین این‌جا هم خیلی حالت‌های مختلفی اتفاق می‌افته.
حالا با این فرض که به یک راه‌حل منتخب رسیدیم باید مشخص کنیم که چطوری می‌تونیم اثرش رو اندازه بگیریم و چطور می فهمیم دیزاین و یا راه‌حلمون خوبه. بعد وارد دیزاین دیداری می‌شیم که در دیوار با استفاده از دیزاین سیستم «سنّت» انجام می‌شه. این‌جا هم طراح با مهندس‌های تجربهٔ کاربر و مدیر دیزاین سیستم و تجربه‌نویسمون وارد تعامل می‌شه تا بتونیم محصول رو به صورت دیداری هم طراحی بکنیم.
در تیم هم از توسعه‌دهنده‌ها به صورت مداوم در جلسات مختلف بازخورد می‌گیریم. در این‌جا هم حالت‌های مختلفی ممکنه اتفاق بیافته. امکان داره محصول رو یک‌باره توسعه بدیم یا اول یک پروتوتایپ رو تست کنیم و بعد از نتیجه‌اش توسعه بدیم. پس خروجی‌ها هم می‌تونه متفاوت باشه. بعد از مرحلهٔ توسعه، تضمین کیفیت (QA) وارد می‌شه تا از کیفیت چیزی که پیاده شده مطمئن بشیم.
در آخر با همون سنجه‌هایی (metrics) که در همکاری با پژوهشگر و تحلیل‌گر داده مشخص کرده بودیم ارزیابی می‌کنیم که این محصولی که طراحی شده، توسعه پیدا کرده و ریلیزش کردیم، چه اثری روی کل محصول می‌ذاره. آیا به نتیجهٔ مطلوبی که می‌خواستیم رسیده یا نه. آیا اون سنجه‌ها رو به قدری که انتظار داشتیم جابه‌جا کرده یا نه؟ بر اساس این نتایج گام‌های بعدی‌مون رو تعیین می‌کنیم.
دیزاین‌ها چطور بررسی و تأیید می‌شند؟
- شیوا شریف‌پور (طراح): یک چیز خیلی خوبی که من توی فرآیند دیوار دوست دارم اینه که از همون روز اول که می‌خوایم مسئله رو تعریف کنیم تا آخرش که تأیید می‌شه که بره روی محصول همه چی به صورت تیمی پیش می‌ره و طراح تک‌تک قدم‌ها رو در تعامل با بچه‌های محصول پیش می‌بره. مثلن ما از همون اول جلسات طوفان فکری داریم که ببینیم مسئله اولویت داره؟ خوبه؟ همون مسئله‌ایه که می‌خوایم حلش کنیم؟ چه راه‌حل‌هایی داریم؟ محدودیت‌هامون چیه؟ و ... جواب این سؤالات رو با بچه‌های توسعه، مدیرمحصول، بچه‌های داده و هر کسی که توی تیمه مشخص می‌کنیم و هرکسی از نقطه‌نظر خودش می‌تونه چیزی بهش اضافه کنه. بعد از شفاف‌شدن مسئله راه‌حل‌های انتخابی رو بررسی می‌کنیم، اگر داده‌ای لازم داره توی همین مسیر به دستش میاریم و در جلسات محصولی‌مون که هفتگی هستند از مدیرمحصول و حتا بچه‌های فنی مدام بازخورد می‌گیریم. اگه لازم بود تغییرات می‌دیم. به نظرم کلن این فرآیند خوبه چون تیمیه و من به عنوان طراح باید با توافق و تأیید باقی افراد تیمم برم جلو. این فرآیند انعطاف داره برای همین ممکنه توی تیم‌های مختلف به شکل‌های متفاوتی اجرا بشه. یک سری توافقات کلی هم باهم داریم مثل مستندسازی فرآیندهامون موقع تحویل، و توضیح این که به چه چیزهایی توجه کردیم و چی شد که اصلن این مسئله برامون مهم شد. یک مستندسازی برای تحویل به بچه‌های فنی داریم و همین‌طور به بچه‌های داده که چه اثراتی رو پیگیری کنند. همچنین با تجربه‌نویسمون هماهنگ می‌شیم که آیا متن‌ها خوبه و یا احتیاج به بهبود داره. و نهایتن فایل رو به مدیر دیزاین سیستممون تحویل می‌دیم که اون هم از لحاظ یک‌پارچگی و نیازمندی‌های دیزاین سیستم دیوار تطابقش می‌ده و می‌بره سمت توسعه روی محصول.
چه جوری یک طراح کارها رو به توسعه‌دهنده تحویل می‌ده (hand-off)؟
- امیر: ما کلن توی فرآیند طراحی‌مون - همون‌جور که شیوا هم اشاره کرد - مستندسازی اون کاری (task) که در دست داریم بخش مهمی حساب می‌شه که در سندهای مجزا انجامش می‌دیم. حتا کوچک‌ترین کارها برای خودشون سند جدا دارند و مشخص می‌کنند که چرا داریم این کار رو انجام می‌دیم و چرا سمت این مسئله اومدیم و ... در بررسی ابعاد مختلف کاری که داریم انجام می‌دیم به چالش‌های فنی‌ش هم فکر می‌کنیم. سعی می‌کنیم تا جای ممکن شفافش کنیم و تا ۱۰۰٪ همهٔ جوانبش رو ببینیم - هر چند که در نهایت همه چیز رو نمی‌شه دید - و کامل توضیح بدیم که برای چالش‌های مختلف اون کار چه واکنشی داشته باشیم و یا اگر کاربری به نوع دیگه‌ای باهاش برخورد کرد چه جوری بهش رسیدگی کنیم.
و توی تمام سندها قسمتی رو به بچه‌های فنی‌مون اختصاص می‌دیم تا مواردی که شاید توی دیزاین خیلی شفاف نباشه رو در زمان توسعهٔ تسک در نظر بگیرند. مثلن اگر اکشنی که یک کامپوننت داره تغییر بکنه و یا حتا حالت‌های (states) مختلف یک صفحه‌ای که دیزاین کردیم، تمامش رو میایم تعریف می‌کنیم و می‌نویسیم. برای فرآیند هندآف هم از فیگما استفاده می‌کنیم که دیزاین‌هامون رو بعد از این که از سمت تیم بررسی و تأیید می‌شند با فایل‌های اصلی دیوار مرج (merge) می‌کنیم. بچه‌های توسعهٔ تیممون هم از روی همون فایل‌ها دیزاین رو می‌بینند و کارشون رو ادامه می‌دند. ممکنه توضیحاتی توی خود فیگما و روی کامپوننت‌ها هم در قالب کامنت بذاریم تا بچه‌ها بدونند چه جوری باید اجراش کنند. باقی موارد رو هم سعی می‌کنیم جوری شفاف توی سند بیاریم که توسعه‌دهنده‌ها لازم نباشه سؤالی بپرسند. البته که ممکنه هیچ‌وقت به اون کاملی که دلمون می‌خواد نباشه و توی جلسات هماهنگی محصول تیم‌ها پرسیده بشند.
فایل‌های دیزاینتون که مدام آپدیت می‌شند رو چه جوری دسته‌بندی می‌کنید؟
- امیر: همون‌طور که اشاره کردم ابزار اصلی ما برای دیزاین فیگما هستش. اون‌جا سعی کردیم ساختاری دربیاریم که دستمون به قدری باز باشه که بتونم ایده‌پردازی (ideate) و ایتریت (iterate) بکنیم. همچنین فایل‌های مرجع دیوار رو کلن جدا کردیم. هر کدوم از قبیله‌ها و هر کدوم از طراح‌ها فضای مخصوص به خودشون رو دارند که طراحی‌ها و ایتریت رو اون‌جا انجام می‌دهند. یعنی مثلن فایل‌های دیزاین مربوط به قبیلهٔ املاک با فایل‌های دیزاین قبیلهٔ خودرو کاملن جدا هستند. مسئول هر کدوم از اون فایل‌ها هم طراح‌های همون قبایل هستند. بعد از این که همه چی تموم شد و فرآیند طراحی و انجام تسک و تأیید، نهایی شد و خواستیم مرجش کنیم، مدیر دیزاین میاد و با فایل‌های اصلی دیزاین دیوار مرجش می‌کنه.
کاربرپژوهی
معیارهای انتخاب روش پژوهشتون چی هستند؟
- روشنک حقیقی (کاربرپژوه): اصلی‌ترینش هدفمونه و این که دنبال چه چیزی هستیم. براساس اون می‌تونیم یک سری از روش‌ها رو انتخاب کنیم. معیار بعدی مدت زمانیه که ازمون می‌گیره. معمولن در تیم‌ها کارها باید در زمان مشخصی انجام بشه. گاهی شده که پژوهشی انجام بدیم ولی چون به موقع نرسیده بی‌فایده شده. موارد دیگه‌ای هم هستند مثل محدودیت‌های مالی و یا انسانی. کاری رو ممکنه لازم باشه با تعداد زیادی مصاحبه توی گروه‌های مختلف انجام بدیم که ۱۰ روز زمان نیاز داشته باشه. برای کاهش تعداد نیروی لازم و اون هزینه‌ای که باید بپردازیم ممکنه روش رو تغییر بدیم و از پرسشنامه استفاده کنیم.
به صورت کلی قانون خیلی مشخصی وجود نداره و هر پژوهشگر توی تیم خودش بسته به شرایطی که وجود داره تصمیم می‌گیره. در مورد روش‌های مختلف پژوهش و این که چرا باید یک جا تست کاربردپذیری بگیریم و یک جا پرسشنامه بدیم توی بلاگمون می‌تونید بخونید.
چطور کاربرهای مورد نیاز برای پژوهش رو پیدا می‌کنید؟
- امید حسین‌زاده (لیدر چپتر کاربرپژوهش): گام اولی که توی انتخاب کاربر برمی‌داریم شفاف‌سازی مسئله است که از دلش یک سری ویژگی‌های مطلوب برای کاربرهای موضوع پژوهشمون مشخص می‌شه. این ویژگی‌ها رو از ۲ راه می‌تونیم غربال کنیم. من راجع به کاربرهایی که برای پژوهش‌های خود دیوار انتخاب می‌کنیم صحبت می‌کنم که می‌شه بسطش داد به هر پژوهشی. گاهی این ویژگی‌ها رو در بعضی از رفتارهای کاربرها که از خودشون توی داده‌هامون ثبت می‌کنند پیدا می‌کنیم. رفتار رو هم به عنوان مثال می‌تونیم بگیم ثبت آگهی. پس مثلن ما برای انجام یک پژوهش در این باره به کاربرهایی که تعداد زیادی آگهی ثبت می‌کنند احتیاج داریم. گام اولمون اینه که از سمت داده یک غربال اولیه انجام می‌دیم. در مرحلهٔ دوم بعضی ویژگی‌ها هست که فکر می‌کنیم نمی‌تونیم از داخل داده دربیاریم. اینا رو تبدیل می‌کنیم به اسکرینر که یک غربالگر در قالب پرسشنامه است. طراحی اسکرینر یک سری ویژگی‌ها ومهارت‌ها رو نیاز داره تا بتونید از راهش جواب درست بگیرید و بتونید به وسیله‌ش کاربرهایی که از دل داده دراومده رو باز غربال دقیق‌تر کنید. این کلیت داستانه.
حالا بیاید راجع به محصولی که هنوز وجود نداره و داریم سبک‌سنگین می‌کنیم که بریم سمتش یا نه صحبت کنیم. انتخاب کاربر برای پژوهش در این‌جا خلاقیت خیلی بیشتری لازم داره و زور اسکرینر خیلی می‌چربه. چون باید اون غربال اولیه‌ای رو که با داده انجام می‌دادیم به شکل بهتری توی اسکرینر ترجمه کنیم.
در کل انتخاب کاربر از این دو مجرا می‌گذره. یکی غربالی که از داخل داده است و غالبا داده‌های رفتاریه و خیلی قابل اطمینانه و بعد داده‌هایی که گفتاری/بیانیه و از دل اسکرینر درمیاد.
نتایج این پژوهش‌ها رو چه جوری مستند می‌کنید؟
- امید: ۲ بخش داره:
۱. از چه ابزاری برای مستندسازی و فراخونی‌ش استفاده می‌کنیم؟
ما از ابزارهای عمومی سازمانی استفاده می‌کنیم که هم منظم هستند وهم پیدا کردن اسناد دیگه توش راحته و بین تمام تیم‌ها و کل محصول مشترکه.
۲. با چه روش و قالبی این‌ها رو مستند می‌کنیم؟
ما در حال حاضر قالبی ساختیم که همیشه بازنگری می‌کنیمش و به سمت بهتر کردنش پیش می‌ریم. به این شکل که گاهی به چالش‌هایی توی روش مستندسازی‌مون برمی‌خوریم که باعث می‌شه به این فکر کنیم که چه جوری بهترش کنیم.
نکته سر مستندسازی اینه که برای چه کسانی می‌خوای مستندش کنی و اون افراد هر کدوم چه نیازهایی دارند و بینشون اولویت‌بندی کنی. یک گزارش پژوهش ذی‌نفعان مختلفی داره. مثلن کسی که تقاضای پژوهش رو داده و یک سؤالی تو ذهنشه که به مرحله‌ی شفاف‌سازی رسوندیمش و رک و پوست‌کنده اون سؤال رو جواب می‌دیم. بخش دیگه افرادی هستند که صحت این اطلاعات رو می‌سنجند و بیشتر نقش رهبری دارند برای همینه که کیفیت این گزارش ها براشون مهمه. مدیرمحصول سؤال رو می‌پرسه و جواب رو از تو می‌گیره اما مسئولیت این که این فرآیندی که طی شده منطقی و درست بوده تو چپتر پژوهش تعریف می‌شه و بر عهدهٔ افرادیه که مسئولیت این بررسی رو دارند. گروه سوم هم افرادی هستند که در زمان ترفیع میان و ارزیابی می‌کنند که پژوهشگر چقدر تأثیرگذار بوده.
به همین ترتیب اولویت‌های روش مستندسازی و گزارش‌نویسی ما مشخص می‌شه. همیشه ما اول میایم در قسمت اول سؤال پژوهشی رو خیلی کامل و شفاف جواب می‌دیم و توی قسمت بعدی‌ش می‌گیم چه تحلیلی رخ داده و من چه‌ها دیدم که جواب رو به این صورت می‌گم. توی قسمت آخر هم به کمک متقاضی پژوهش که غالبن طراح و مدیرمحصول هستند می‌گیم که اثر این موضوع چی و روی کدوم طرح بوده. چون پژوهش اثراتش خیلی مشخص نیست و باید در طول زمان دنبالش کرد، این بخش کمک می‌کنه که ببینیم این کاری که کردیم کجا خودش رو نشون داده.
فرآیند تعیین سنجه توی ارزیابی کمی و کیفی دیوار چه جوریه؟
- امید: ما بعد از توافق روی شرایط مطلوب/نامطلوبمون می‌شینیم فکر می‌کنیم که این شرایط رو چطوری می‌تونیم رصد کنیم و چه سنجه‌ای برای ارزیابی‌ش معنی داره. کاری که در ادامه می‌کنیم اینه که میایم به کمک پژوهش دلایلی که این سنجه سر جاش نیست رو پیدا می‌کنیم و این طوری احتمال پیدا کردن مسئلهٔ درست‌تر و آزمون و خطای کمتر رو می‌بریم بالا. خلاصه که همه چیز به شفاف‌سازی هدف سؤالی که مطرح شده برمی‌گرده و اون‌جا سنجه رو خواهیم داشت.
- شیوا: همون‌طور که عاطفه هم جلوتر گفت، ما اول که می‌ریم سمت مسئله توی همون شروع طراحی و از راه همون او‌کی‌آر و نتایج کلیدی یک سری سنجه تعیین کردیم که نشون می‌ده چی رو می‌خوایم بهتر کنیم. بعدشه که می‌ریم سراغ راه‌حل. این‌جا میایم با بچه‌های داده و باقی اعضای تیم هم‌فکری می‌کنیم که این راه‌حلی که می‌خوایم پیاده کنیم کجاها رو تغییر می‌ده و کدوم‌هاش خوبه و کدوم‌هاش بده و چه جوری سنجه‌مون رو تغییر می‌ده.
تجربه‌نویسی
به صورت کلی برای یک محصول چطوری لحنش رو تعیین می‌کنید؟
- باهار ابراهیمی (تجربه‌نویس): این سؤال خیلی کلیه. کلن لحن محصول تابعی از خود محصول و جامعهٔ هدفیه که داره. جامعهٔ هدف هم همون کاربرهایی هستند که از اون محصول استفاده می‌کنند. از یک طرف چه کسایی هستند و قراره چه کاری کنند و از طرف دیگه محصول شما چیه و چه خدمتی می‌خواد ارائه بده و ارز‌ش‌هایی که داره چیه. بر اساس این‌ها می‌تونید دربارهٔ لحن تصمیم بگیرید. قاعدتن نکته‌های دیگه‌ای هم می‌تونه تأثیرگذار باشه.
در مورد دیوار بخوام صحبت کنم، قبل از این که من وارد دیوار بشم تقریبن لحن دیوار، بعد از اون مدت فعالیتش یک کم معلوم شده بود. الان ما داریم اون لحن رو بهبود می‌دیم. تا این‌جا می‌دونیم که لحنمون کاملن محاوره نیست و کاملن رسمی هم نیست. چیزی نزدیک به زبان معیاره.
کلماتی که نیاز به ترجمه دارند رو چه جوری باهاش برخورد می‌کنید؟
- باهار: برای مثال ما با این موضوع توی تعریف کامپوننت‌ها در سنت برخورد داشتیم. رویکردی که توی ترجمه پیش گرفتیم این بود که اگر می‌تونستیم اون واژه رو ترجمه کنیم و معناش همچنان باقی بمونه و تغییری نکنه، ترجمهٔ لفظی کردیم. اما جایی که احساس می‌کردیم ترجمه می‌تونه به معنا صدمه بزنه، همون لفظ رو استفاده کردیم و به معنا گرفتیم. در واقع توضیحش دادیم. مثل کامپوننت. در مورد این که ترجمه توی خود فلو‌ها بخواد اتفاق بیافته خیلی از موارد اصلن نیازی به ترجمه نداره. مثلن ما وقتی می‌خوایم ثبت نام بکنیم نیاز به فرم داریم که اون فرم‌ها نیاز به یک سری مشخصات دارند.
اما باز هم اگر نیاز به ترجمه داشته باشند، اون لحنی که انتخاب کردید می‌تونه شما رو راهنمایی کنه. فرض کنیم من می‌خوام «let's go» رو توی برنامه‌م داشته باشم و بگنجونمش. اگر لحن محصولی من یک لحن سرخوشانهٔ محاوره‌ای باشه احتمالن من «let's go» رو می‌نویسم «بزن بریم». اما اگر لحن رسمی باشه و نزدیک‌تر به زبان معیار احتمالن یکی از گزینه‌هام برای این ترجمه گزینهٔ «شروعه» که این خود شروع هم دیگه دقیقن ترجمهٔ اون عبارت نیست.
مهندسی تجربهٔ کاربر
چه جوری چالش‌هایی که با توسعه‌دهنده‌های فرانت‌اند دارید رو حل می‌کنید؟
- مهدی رحمان (لیدر سابق چپتر مهندسی): این چالش‌ها رو احتمالن همهٔ طراح‌ها داشته‌اند که چند بعد داره: یک سری چالش موقع تحویل طرح اتفاق می‌افته که مقداری‌ش وابسته به محدودیت‌های ابزاریه و مقداری‌ش وابسته به اینه که تلاش لازم برای شفاف‌کردن دیزاین رو به اندازهٔ کافی نداشتیم. ما توی تیم مهندسی کلن سعی می‌کنیم ابزارهایی بسازیم که اولن محدودیت‌های ابزار دیزاینی‌مون رو رفع بکنه؛ مثل پلاگین‌هایی که برای هندآف متن‌های RTL توی فیگما توسعه داده بودیم. بعضی اوقات هم کامپوننت‌ها یا میکروترنزیشن‌ها رو میایم توی یک محیط ایزوله با تأیید تیم فرانت‌اند توسعه می‌دیم و این‌جوری خیلی از مشکلات حل می‌شه.
یک سری دیگه چالش‌ها هم توی دیوار در فلوهای تکرارشونده داریم مثل فلوی ورود به حساب (log in) یا فلوی پرداختمون که این ها رو هم میایم توی دیزاین سیستم یک بار مستندش می‌کنیم و موردهای خاصش (corner cases) رو وارد می‌کنیم. دیگه توسعه‌دهنده به هر نقطه‌تماسی برسه منبعی برای رجوع بهش داره.
کلن این راهنماها که توی دیزاین سیستم داریم مزیتیه که خیلی از چالش‌هایی رو که با تیم فرانت‌اند داریم حل می‌کنه. ما مثلن الان توکن جنریک (generic token) و یک سری توکن طراحی (design token) داریم که همه روش توافق دارند و توی زبان طراحی‌مون قرار داده شده. از اون ور هم تیم مهندسی زمانی که می‌بینه چالشی ممکنه توی سرویسی که داریم توسعه می‌دیم پیش بیاد قبل از این که وارد مرحلهٔ توسعه بشه کتابخانه‌ها یا نمونه‌های مشابه‌ش رو بررسی و مقایسه می‌کنه و چک می‌کنه که چه جوری این نمونه‌های مشابه رو می‌شه توی محصول دیوار و با استاندارهایی که توی کل وب‌سایت دیوار و فرانت‌اند داریم پیاده‌ش کنیم. و مطمئن باشیم که بعدن هم می‌شه توی جاهای دیگهٔ محصول هم که می‌شه بهش نیاز داشت استفاده کنیم.
چه معیارهایی توی مستندسازی دیزاین سیستم براتون مهمه؟
- مهدی: کلن موقعی که سنّت‌دیزاین رو شروع کردیم اومدیم روی دیزاین سیستم‌های دیگه مثل material و Polaris و Carbon و چیزهای دیگه بنچ‌مارک کردیم و برای ساختاری که نیاز بود برای کامپوننت‌های پایه‌ایمون داشته باشیم خیلی الهام گرفتیم. پس اولین چیزی که در نظر گرفتیم ساختاربندی مستندات دیزاین برای کامپوننت‌ها و پایه‌ی دیزاینمون بود. این‌جا هم این بنچ‌مارک این طور پبش رفت که بعضی جاها لازم بود به یک سری رفتارهای خیلی معمول اون معماری اطلاعات اتکا کنیم و خیلی جاها هم نیاز بود که خودمون با توجه به نیاز خود محصول دیوار تغییراتی رو در نظر بگیریم. معیار بعدی از سمت کاربرهامون برامون تعیین می‌شد. این که رفتارشون با دیوار طی این چند سال چه جوری بوده و با چه روش‌ها یا راه‌حل‌ها و مسئله‌هایی اخت گرفته‌اند و حتا از چه دستگاه‌هایی استفاده می‌کنند. همهٔ این‌ها روی طراحی دیزاین سیستم و نحوهٔ مستندسازی‌ش تأثیر داشته.
در راستای تفکر دیزاینی‌مون و نحوهٔ مستندسازی‌مون مثلن یک سری کامپوننت که مخصوص محصول دیوار هستند رفتارهایی دارند توی جای‌جای محصول که ما به راحتی دیگه بعد از مدت‌ها استفاده ازشون می‌تونیم یک راهنما براشون داشته باشیم. این هم بخشی از معیارها بود که روی مستندها تأثیر می‌ذاشت.
مسئولیت‌های دیگه‌ای که به عهدهٔ چپتر مهندسیه چی هستند؟
- مهدی: ما یک فاصله‌ای داریم بین تعامل تیم طراحی و تیم توسعه. همون طور که امیر هم اشاره کرد توی تحویل طرح یک چیزهایی ممکنه جا بیفته و نیاز به جلساتی برای شفاف‌کردن تصمیمات لازم بشه. مهندس تجربهٔ کاربر به خاطر دانش چند‌بعدی و چند وجهی‌ای که داره هم می‌تونه با تیم طراحی تعامل کنه و هم با تیم توسعه یک زبان مشترک ایجاد بکنه. مهندس می‌تونه تیم طراحی رو از محدودیت‌هایی که سمت پیاده‌سازی فنی داریم مطلع کنه و از اون طرف هم می‌تونه زمانی که طرح به تیم توسعه تحویل داده می‌شه در راستای بهترین راه پیاده‌سازی دیداری (visual) و عملکردی (performance) و مسائلی مثل سئو راهنمایی‌شون بکنه.
در کنارش کلن وظیفهٔ نظارت به طراحی دیزاین سیستم و این که پیاده‌سازی‌ش به چه شکله و بعدن چه جوری نگهداری می‌شه تا یک حدی‌ش توی تیم مهندسی رسیدگی می‌شه. بخش دیگه‌ای هم که توی تیم مهندسی دیوار روش تمرکز داریم اینه که سمت وب دیزاین‌هایی که از سمت تیم‌های مختلف وارد می‌شه رو بر اساس دیزاین‌ها و راهنماهایی که توی سنّت داریم اعتبارسنجی می‌کنیم.
کتاب راهنمای مهندسی دیزاین رو هم من و نرگس که مهندس کیفیت دیواره باهم ترجمه کرده‌ایم که می‌تونه مفید باشه تا از جایگاه ساختار سازمانی تیم مهندسی توی دیوار یک بینشی داشته باشید.
بچه‌های فرانت‌اندی که علاقه به تجربهٔ کاربر دارند چه جوری می‌تونند به دیوار ملحق بشند؟
- مهدی: از این سوال من ۳ حالت رو برداشت می‌کنم:
۱. فرانت‌اندی که می‌خواد طراح محصول بشه، که خوبه منابعی رو که آزاده توی بلاگمون خیلی خوب معرفی کرده در شروع راهش بخونه. الان شیما، لیدر کنونی چپتر طراحی، هم می‌تونه خیلی خوب کمک بکنه. این شخص فرانت‌اند باید زمان خیلی بیشتری رو روی نحوهٔ شکل دادن هم تفکر حل مسئله و هم تفکر دیزاینی‌ش بذاره.
۲.فرانت‌اندی که می‌خواد مهندس تجربهٔ کاربر بشه، که در دوره‌های بهینه‌شده‌ای که به تعداد زیاد برای توسعه‌دهنده‌ها وجود داره شرکت کنه. همچنین برند و تجربهٔ کاربر و پایه‌های رابط کاربر رو یاد بگیره تا تعاملات بهتری با تیم طراحی‌ش داشته باشه. از اون ور هم اگر می‌خواد مهندس خوبی باشه باید اول تفکر سیستماتیک توی توسعه‌ی دیزاین سیستم داشته باشه و از اون ور هم بتونه تمام موردهای خاصی که یک کاربر ممکنه توی یک فلوی پیچیده بهش بربخوره رو ببینه و براش راه حل خوبی ارائه کنه.
۳. فرانت‌اندی که دنبال اینه که به عنوان فرانت‌اند بتونه تعامل بهتری با تیم تجربهٔ کاربر شرکتشون داشته باشه که خوبه با خود افراد تجربهٔ کاربری که باهاشون در ارتباطه صحبت کنه.
همکاری با صنف تجربهٔ کاربر دیوار
کارآموزی دارید یا نه؟ کی و چه جوری؟
- شیما (لیدر چپتر طراحی): ما یک دوره‌ای کارآموزی داشتیم و استخدام کردیم. در حال حاضر نداریمش اما بستگی به آینده داره که ببینیم خود بچه‌ها چقدر می‌تونند وقت بذارند. پس احتمال داره که در آینده باز هم بازش کنیم که از راه تلگرام اطلاع‌‌رسانی می‌کنیم.
- امید: توی پژوهش هم جواب من مثل شیما است. چون برامون کارآموزی خیلی مهمه باید زمانی که آدم‌ها بتونند انرژی بذارند داشته باشیم.
اعضای دیوار امکان دورکاری دارند. برای کارآموز هم چنین امکانی می‌تونید داشته باشید؟
- شیما: آره. البته امسال شیوهٔ حضورمون از سمت سازمان داره برنامه‌ریزی می‌شه که احتمال داره به سمت یک حالت هیبرید که بخشی‌ش دورکاری و بخشی‌ش حضوریه بره. اما در کل مانعی وجود نداره و سر کارآموزی قبلی هم باز بودیم که از همه جای ایران رزومه بفرستند. البته که تجربهٔ حضوری یک چیز دیگه است و شاید از راه دور سخت‌تر باشه اما ما سعی خودمون رو توی پیشبرد کارها داریم. به خصوص که دوره‌ی کرونا بهمون خیلی چیزها در این مورد و تعاملاتمون یاد داده. ما همیشه استقبال می‌کنیم که از همه جا افراد بتونند به دیوار بپیوندند.
- امید: شرکت متأسفانه خیلی دموکراته این‌جا و من خیلی از دورکاری ناراحتم. اگه زور من برسه که بخوام کارآموزی برگزار کنم، ترجیحم روی حضوریه. مخصوصن پژوهش خیلی کار میدانی‌ایه و اون تجربه‌ای که در محل داریم خیلی مهم و مؤثره. ولی فکر کنم که زورم نرسه و شرکت اجازه‌ٔ دورکاری بده.
کم‌تجربه‌ها برای استخدام در موقعیت پایه‌ای (junior) دیوار چه کار بکنند؟
- شیما: ما خیلی باتجربه رو این نمی‌بینیم که طراح رابط کاربر حرفه‌ای باشه. برای ما این معیار نیست. برای ما توانایی حل مسئلهٔ آدم‌ها مهمه و اصلن دیزاین رو توی چپتر طراحی حل مسئله می‌دونیم. کلن اگر آدم تحلیل‌گری هستید، کاملن می‌تونید مسئله رو شناسایی کنید، ببریدش جلو، راه‌حل بدید و طراحی کنید، این عالیه. نکته اینه که توی جایی که هستید چطوری تمرینش بکنید.
به نظرم قدم اول اینه که دید پرسشگری داشته باشید، که اصلن این کاری که می‌خوام انجام بدم و این مسئله‌ای که می‌خوام حل کنم چیه؟ چرا مسئله است و چرا مهمه؟ اگر پژوهشگر دارید ازش کمک بگیرید و برید از کاربرها داده جمع کنید که بفهمید اهمیت مسئله از کجا براتون بارز شده. در ادامه که می‌خواید راه‌حل بدید چطوری می‌فهمید که راه‌حلتون جواب داده و مسئله رو حل کردید؟ اگر بتونید این فرآیند رو در جایی که هستید هی تمرین بکنید، کاملن دارید این مهارت رو کسب می‌کنید. زمانی که این ذهنیت رو داشتید، برامون رزومه بفرستید.
باتجربه رو هم ما کسی می‌دونیم که می‌تونه مسئله رو در پیچیدگی‌های یک محیط پیچیده حل کنه و نیازمندی‌های بیشتری رو در نظر می‌گیره.
- امید: پژوهشگر باتجربه که نمی‌دونیم توی ایران چقدر هست. غالبن بچه‌ها توی این حوزه تازه شروع کردند و ما هم خودمون خیلی ادعایی نداریم و چند ساله که تجربه پیدا کردیم و شاید در مقایسه با بقیه است که قدیمی به نظر میایم. توی نقش‌های دیزاین و پژوهش مدل فکری خیلی مهم می‌شه. این که سؤال‌های درستی بپرسی و بتونی به شفاف‌شدن یک مسئله کمک کنی و از اون‌ور جرأت و شوق کار میدانی داشته باشی.
یک تمرین اینه که سعی کنید خودتون رو هی زیر سؤال ببرید. و همین‌جوری که دارید فکر می‌کنید ببینید که کجای فکرتون درسته و کجا نه. یک کتاب خیلی خوب هم به نام «با چرا شروع کنید» پیشنهاد می‌کنم که حتمن بخونید.
- مهدی: در مورد مهندسی هم می‌تونم بگم نگاه سیستمی به دیزاین با مطالعهٔ دیزاین سیستم‌ها و روش تصمیم‌گیری توی اون‌ها تمرین کنید. ما پادکستی هم توی دیوار داریم که دو شمارهٔ اولش مربوط به دیزاین سیستمه. سندهای سنّت چه سمت دیزاین و مستندهای فارسی، و چه سمت توسعه‌دهنده‌ها که در حال توسعه‌شون هستیم می‌تونه جای خوبی باشه برای این که نگاه افراد دربارهٔ آینده‌ٔ شغلی مهندس تجربهٔ کاربر شکل پیدا کنه.
آیا دانشگاه عامل مهمی توی استخدامه؟
- آزاده: جواب خیلی خلاصه‌ش «نه»ست. بیبنید که خود بچه‌های صنف تجربهٔ کاربر دیوار از چه زمینه‌های متفاوتی اومده‌اند: ما از مهندسی عمران، مهندسی معماری، مهندسی صنایع، مهندسی مکانیک، مهندسی نفت، فیزیک، گرافیک دیزاین، فناوری اطلاعات، مهندسی نرم‌افزار و ... داریم. به طور خلاصه تأکید می‌کنم که معیار ما دانشگاه نیست چون خروجی دیزاین‌محور و پژوهشی و هر چیز دیگه‌ای که نزدیک به انتظارات ما باشه از دل دانشگاه‌ها و فضاهای آکادمیک عمومن در نمیاد. بیشتر اون بحث تجربهٔ کار در یک تیم، تجربهٔ طراحی و توسعهٔ محصول در یک تیم و بحث توانایی تشخیص مسائل و کشفشون و حلشون و فرآیند حل مسئله، تعامل و این‌جور معیارهاست که برامون اهمیت داره.
با خوندن رزومه چطور تشخیص می‌دید کسی اهل مسئله است و از حلش لذت می‌بره یا نه؟
- شایان: سمت دیزاین علت این که رزومه خودش نشون‌دهنده‌ی مهارت دیزاینه اینه که اولین ابزار ارتباطی با کاربریه که رزومه رو بررسی می‌کنه. در واقع رزومه یک محصوله و ما بر اساس این محصول ارزیابی می‌کنیم که نیازمندی‌هایی که توی صفحه‌ی شرح شغلی نوشتیم با مهارت‌هایی که توی رزومه نوشتید همخوان هست یا نه. اگر هیچ‌جای رزومه اون مهارت رو نبینیم ممکنه ردش کنیم چون به هر حال مصاحبه گرفتن هم برامون پرهزینه است. پس این کمک می‌کنه که بتونیم بین گزینه‌هامون اولویت‌بندی بکنیم.
رزومه حتا تا حدی دانش و مهارت‌های طراحی و صفحه‌چینی رو هم بهمون نشون می‌ده و به طبع خوشحال‌تر می‌شیم که رزومه‌ها از یک قالبِ آماده نباشه. زمانی که می‌خواید نشون بدید متفاوت هستید نباید شما هم از ابزاری که همه ازش استفاده می‌کنند استفاده کنید.
چیز دیگه‌ای که در رزومه اهمیت داره مربوط به مسئولیت‌های طراحه که مایکروکپی‌های توی رابط رو خودش بتونه بنویسه. پس توی رزومه‌ای که می‌گیریم انتظار نداریم ۵۰ یا حتا ۲ تا غلط ببینیم.
اینا همه نشون‌دهندهٔ اینه که چقدر توی حل این مسئله یعنی رفع انتظار ما با اون نیازمندی‌هایی که توی شرح شغلی نوشتیم کسی دقت می‌کنه و براش اهمیت قائله. زمانی که رزومه اوکی شد، نه فقط در رزومه که در فرآیند مصاحبه با بررسی پورتفولیو و دادن تسک و ارزیابی توانایی حل مسئله توی قسمت بعدی مصاحبه متوجه توانایی حل مسئلهٔ شخص می‌شیم. پس مدیومش فقط روزمه نیست.
- شیوا: خیلی‌ها توی رزومه‌شون اولین نمونه کار رو که می‌ذارند اولویت‌بندی ذهنی خودشون رو که بیشتر سمت رابط کاربر و گرافیکه کامل مشخص می‌کنند و یا به فرآیند بیشتر توجه کرده و ارائه‌ش داده‌اند. ما در بررسی رزومه‌ها به این مورد هم توجه می‌کنیم، پس مطمئن باشید که متناسب با نیازی که توی شرکت داریم ارائه‌تون رو آماده کنید. به هر حال شما می‌تونید توانمند باشید اما متناسب با نیازهای شرکتمون نباشید.
- روشنک: خیلی خوبه که چیزی بیشتر از یک لیست از جاهایی که کار کردید و تجربه‌هایی که داشتید رو اضافه کنید. در واقع اون مهم‌ترین کاری که کردید یا تأثیری که گذاشتید رو اگر بتونید خلاصه بذارید به تصمیم‌گیری ما خیلی کمک می‌کنید تا این که فقط اسم برند و شرکتی که توش کار کردید عامل تصمیم‌گیری ما باشه.
- آزاده: اولن که ما باید بپذیریم فرآیند ثبت درخواست و مصاحبه فرصت بسیار محدود و مشخصی رو به افراد می‌ده که بتونند خودشون رو نشون بدند و بگند که من به اصطلاح با نیازمندی‌هاتون تطابق دارم یا نه. و از اون طرف هم فرصت بسیار محدودی رو به کاندیدا می‌ده که بتونه شرکت مورد نظرش رو توی همون زمان کمی که تعامل دارند بیشتر بشناسه. به هر حال یک فرآیند دو طرفه است. به هر شکل وقتی زمان خیلی محدوده، تک‌تک این تعاملات اهمیت پیدا می‌کنه. توی ایران ما معمولن رزومه‌های درست و ساختارمند نمی‌نویسیم. ولی اگر من بخوام به کسی بگم چطور طراح شدن رو به طور کلی شروع کنه و چطور حل مسئله‌ای که این قدر ازش حرف می‌زنیم رو تمرین کنه، می‌گم اول بره رزومه بنویسه. ما توی ایران مشکلی که توی خیلی از رزومه‌ها می‌بینیم اینه که بر محور مسئولیت‌هاست. خیلی کم دربارهٔ این که چه خلق ارزشی کردند و چه اثرگذاری‌ای داشته‌اند می‌شنویم. اگر کسی بتونه توی یک صفحه این اثرگذاری رو بیان کنه، همون رزومه با آدم حرف می‌زنه. حتا قبل از این که فرد وارد فرآیند مصاحبه بشه.
اگر بهتون لینک وب‌سایت بدیم که نمونه کار داره آیا می‌بینید یا نه؟
- شایان: وب‌سایت به دلایل مختلف برای ما مهم نیست. این رو درک می‌کنیم که خروجی یک وب‌سایت لزومن نشون‌دهنده‌ی مهارت دیزاینر نیست چون ذی‌نفعان پروژه قطعن از دیزاینر بیشتر هستند. شما حتا ممکنه با محصولی که رفته بالا کاملن مخالف باشید. پس ما نمی‌تونیم چیزی که می‌بینیم رو به مهارت حل مسئله ربطش بدیم. می‌خوام علاوه بر چیزهایی که آزاده گفت تأکید کنم که وقتی از محصول حرف می‌زنیم فرآیند خیلی مهم‌تر از خروجیه. یعنی شیوهٔ نگاه‌کردن و حل مسئله برامون خیلی مهم‌تره. به همین دلیل وب‌سایت گویا نیست چون نشون‌دهندهٔ پیچیدگی‌هایی که توی حل مساله و در تیممون داشتیم و محدودیت‌هایی که باهاش روبه‌رو شدیم نیست. البته سمت مهندسی ممکنه وب‌سایت رو نگاه کنیم چون اون‌جا می‌شه مهارت توسعه رو دید اما سمت دیزاین لزومن نه.
سن مهمه؟
- شایان: واسه ما مهم نیست اما به لحاظ آماری احتمالن توی بازهٔ ۲۰ تا ۴۰ سالگی قرار می‌گیرید.
فریلنسری توی پژوهشگر کاربر امکان‌پذیره؟
- امید: توی شرکت ما که نه. چون شرایط کار ما اینه که تعاملاتمون توی شفاف‌سازی مسئله خیلی مهمه و هماهنگ‌کردن با فریلنسر خیلی سخته.
- شایان: سمت دیزاین هم همین‌طوره. پیش اومده که کار رو برون‌سپاری کنیم اما کلن تلاشمون به «نه» هستش چون هزینه‌ی مکالمات و تعاملاتمون خیلی بالاتر از جذب نیرو می‌شه.
طراح‌های رابط کاربری (UI designer) که می‌خوان به عنوان طراح به دیوار بپیوند چه کار کنند؟
- شیما: به نظرم اول توی همون محصولی که هستند ترکیب مطالعه و تست‌کردن خیلی می‌تونه مفید باشه. و نمونه کار ببینند، یا با کاربرها صحبت کنند و به شکل‌های مختلف بخش‌های مختلف اون حرفه رو تست کنند تا علاقه‌ی واقعی‌شون مشخص بشه.
لشکرهای تک نفرهٔ تجربهٔ کاربر رو چه جوری پیش ببریم که تخصص‌های مختلفش رو دربربگیره؟
- آزاده: این شرح حال خیلی‌هاست. ما هم از تخصص‌گرایی شروع نکردیم و فقط از طراحی تجربهٔ کاربر شروع کردیم. بنا به نیازمون به تمرکز در کنار بزرگ‌شدن دیوار مجبور شدیم این تخصص‌ها رو تعریف کنیم تا بتونیم درست روشون وقت بذاریم. تو اولویتت این باشه که بفهمی چرا داری هر کاری رو می‌کنی. این که بریم و با یک سری کلمات قلنبه‌سلنبه مثل پژوهش و دیزاین سیستم آدم‌ها رو بمبارون کنیم تجربه نشون داده که کار نمی‌کنه. باید با فهمیدن مسئله شروع کرد و با داستان‌های موفقیت کوچیکی که هی برای خودت می‌سازی مسیر رو هموار کنی و آدم‌ها رو با خودت همراه و همسو کنی.
این بود پرسش و پاسخ‌های اولین رویداد «دیوار تجربه».
از بچه‌های صنف تجربهٔ کاربر تشکر می‌کنم که با اشتیاق در این برنامه مشارکت کردند و مرسی از شما که با حضورتون و حرف‌هاتون از ما حمایت کردید.
بعضی از لینک‌ها و راه‌های ارتباطی که در طول برنامه صحبتشون شد رو در پایین می‌تونید ببینید:
- بلاگ فارسی «دیزاین در دیوار» از تجربه‌های ما در پژوهش، طراحی و لیدرشیپ
- بلاگ انلگیسی «دیزاین در دیوار» در مدیوم
- کتاب راهنمای مهندسی دیزاین
- مستندات طراحی دیزاین سیستم سنّت
- مستندات توسعه‌ی دیزاین سیستم سنّت
- پادکست توضیح در مورد سنّت
یک خبر خوش هم داریم و این که رویداد دوم در ۶ اردیبهشت ۱۴۰۱ از ساعت ۱۶:۳۰ تا ۱۸:۰۰ قراره با بررسی یک نمونهٔ موردی برگزار بشه تا بهتر با فرآیند تعریف مسئله و حلش در کنار روش تعامل بچه‌های یک تیم و صنف تجربهٔ کاربر آشنا بشید.
از این راه می‌تونید ثبت نام کنید. امیدواریم ببینیمتون!
مطلبی دیگر از این انتشارات
مطالعهٔ موردی تفکیک آگهیهای کالا - قسمت اول: پژوهش
مطلبی دیگر از این انتشارات
زنگ خطرهای قبل از معامله
مطلبی دیگر از این انتشارات
داده‌های کیفی به کمک داده‌های کمی میآیند!