طراح تجربه کاربر در دیوار
چطور ارتباط طراح تجربهٔ کاربر و تیم فنی را بهینه‌تر کنیم؟
در روزهای پایانی اوکیآر پاییز ۱۴۰۰ تیم استخدام دیوار، جلسهٔ رترویی برگزار کردیم تا اعضای تیم نظراتشون رو دربارهٔ فصلی که طی کرده بودیم بدن. حین جلسه از سمت من، طراح تجربهٔ کاربر تیم استخدام، و توسعه‌دهندگان تیم موضوعی در رابطه با بهینه کردن ارتباط بین طراح و تیم فنی مطرح شد. همه‌مون هم‌نظر بودیم که این ارتباط جای بهبود داره تا در طول پروسهٔ اجرای طرح‌ها چالش کمتری داشته باشیم. بعد از شنیدن نظرات افراد مختلف تیم، تصمیم به اقدام‌های جدیدی گرفتیم که تاثیر بسیار مثبتی در بهبود این رابطه در اوکیآر زمستانمون داشت.
در راستای این موضوع من تصمیم گرفتم قدم بلندتری برای بهینه‌تر کردن ارتباط طراح تجربهٔ کاربر و تیم فنی بردارم. اونچه که در این مطلب می‌خونید حاصل تجربهٔ شخصی من و تعدادی از طراحان تجربهٔ کاربر دیوار، توسعه‌دهندگان و کارشناس‌های QA است که در طول دو هفتهٔ گذشته تجربیاتشون رو با من به اشتراک گذاشتن.
قبل از هر چیز باید به این موضوع اشاره کنم که از تعاملاتم با سایر تیم‌ها متوجه شدم در هر تیم، ارتباط طراح و اعضای فنی (توسعه‌دهنگان و کارشناسان QA) شکل‌های مختلفی داره که ناشی از تفاوت خصوصیات فردی افراد یک تیم، تیم لیدر و مدیر محصوله. یعنی حتی در یک شرکت مثل دیوار هم ممکنه این فرایندها و ارتباطات در تیم‌های محصولی تفاوت‌هایی داشته باشه. اما من در این مقاله در مورد نقاط مشترک ارتباط طراح و اعضای فنی می‌گم که بهبود اون‌ها می‌تونه برایند کلی این رابطه رو بهتر کنه.
برای شفاف‌تر کردن موضوع، این ارتباط رو در دو بخش «در طول فرایند طراحی» و «در زمان تحویل طرح» بررسی می‌کنم.
۱. ارتباط بین طراح و توسعه‌دهنده در طول فرایند طراحی
حضور تیم فنی در جلسات ایده‌پردازی محصول
تمام طراحانی که من باهاشون صحبت کردم معتقد بودن که حضور اعضای فنی تیم در جلسات ایده پردازی تاثیر مثبتی داره. نقطه‌نظر یک توسعه‌دهنده می‌تونه از تیم محصولی (مدیر محصول، طراح UX، پژوهشگر، دیتا آنالیست) خیلی متفاوت باشه و همین تفاوت باعث میشه گاهی نظرات و ایده‌های جدیدی مطرح بشه. این حضور، آگاهی محصولی تیم فنی رو هم بهبود می‌ده و موجب تعهد بیشترشون در پیاده‌سازی طرح میشه. در واقع این از مزیت‌های طراحی در تیم‌های cross-functional است که خوبه ازش استفاده کنیم.
برای اینکه این جلسات ایده‌پردازی خروجی بهتری داشته باشه و اعضای کم‌صحبت هم توش مشارکت کنن، ما سراغ پلتفرم‌هایی مثل Miro یا FigJam رفتیم که تعاملی‌تر هستن. ما در تیم استخدام چند وقتی هست که از روش Lightning Decision Jam برای جلسات طوفان فکری استفاده می‌کنیم و تجربهٔ خوبی باهاش داشتیم. تمپلیتش هم به صورت آماده در Miro موجوده و در این ویدیو هم توضیحات کاملش هست.
ارتباط مستمر طراح و توسعه‌دهنده در طول طراحی راه حل
یکی از اقدام‌های موثری که در تیم استخدام برای بهبود این رابطه کردیم، اختصاص دادن یک توسعه‌دهنده رو(ترجیحا شخصی که قراره طرح رو پیاده‌سازی کنه) همراه با طراح مسئول حل مسئله می‌کنیم.. این یعنی من طراح کاملا می‌دونستم که سوالات فنیم رو باید از کی بپرسم و اون شخص هم خودش رو مسئول پاسخگویی به این سوالات می‌دونست. من تمام راه حل‌هایی رو که در نهایت بهشون رسیده بودم رو قبل از نظرخواهی از تیم محصولی به توسعه‌دهنده نشون می‌دادم و دربارهٔ هزینه فنی هر کدوم صحبت می‌کردیم. هر جا که توسعه‌دهنده نسبت به تخمین اجرای فنی یک طرح مطمئن نبود، سراغ پیدا کردن پاسخ می‌رفت و در نهایت من تمام تخمین‌های فنی برای هر ایده رو مستند می‌کردم.
این مستندسازی دو تا خوبی داشت. یکی اینکه باعث می‌شد وقتی نظرات تیم محصولی رو دربارهٔ ایده‌ها می‌گرفتم، هزینهٔ فنی هر طرح رو هم در نظر بگیریم و دوم اینکه اگر توسعه‌دهندهٔ نهایی طرح به هر دلیل تغییر می‌کرد، نیازی به هماهنگی دوباره و پرس و جو برای تخمین‌های فنی نداشت.
این ارتباط در طول حل مسئله موجب میشه که طراح قبل از صرف وقت زیاد برای یک طرح از محدودیت‌های فنی آگاه بشه و در لحظهٔ تحویل طرح با محدودیت غیرمنتظره‌ای مواجه نشه.
افزایش دانش طراحان نسبت به محدودیت‌های فنی
در مقاله‌های مختلفی که دربارهٔ بهبود رابطهٔ طراح و توسعه‌دهنده خوندم، طراح رو به داشتن دانش سطحی HTML و CSS ترغیب می‌کردن. این دانش هنوز جایی بکار من نیومده. اما آگاهی از موضوعی که قطعا می‌تونه به منِ طراح کمک کنه؛ اطلاع از محدودیت‌های زیرساخت فنی محصوله.
برای این کار بهترین روش بسنده نکردن به پاسخ «هزینهٔ فنی‌اش زیاده» و یا «شدنی نیست» توسعه‌دهندگانه. در ادامهٔ چنین جوابی پرسیدن چراهای متوالی باعث میشه تا کم‌کم آگاهی‌مون نسبت به محدودیت‌ها بالا بره و در نهایت دانش فنی‌مون بیشتر بشه.
یک راه دیگه هم می‌تونه این باشه که از تیم‌لیدر فنی بخوایم برامون یه وقتی بذاره و ساختار فنی محصول رو توضیح بده.
دیدگاه MVP طراحان در مواجه با طراحی فیچرهای بزرگ و جدید
معمولا وقتی طراح قصد داره تغییر بزرگی رو در محصول ایجاد کنه و یا فیچر جدیدی رو طراحی کنه، بخشی از طراحی رو براساس فرضیات انجام می‌ده. چون هنوز دادهٔ دقیقی از فیچر نداریم که بهش استناد کنیم. در این شرایط ممکنه فرضیات ما بعد از پیاده‌سازی فیچری با هزینهٔ فنی زیاد، غلط از آب در بیاد و همین باعث سرخوردگی خودمون و تیم فنی بشه. تفکر MVP (Minimum viable product) در محصول و طراحی فیچری که کمترین تغییرات رو برای برطرف کردن نیاز اساسی ما ایجاد کنه، باعث میشه قبل از اثبات فرضیات‌مون فشار زیادی روی تیم فنی نیاریم و بعد از بررسی داده‌های مربوط به MVP تصمیم‌های مطمئن‌تری بگیریم. در واقع توسعهٔ یک فیچر بزرگ رو در iterationهای بیشتری انجام بدیم.
۲.ارتباط طراح، توسعه‌دهنده و کارشناس QA بعد از تکمیل طراحی
مستندسازی طرح و ملاحظات فنی
ما در صنف تجربهٔ کاربر دیوار مستندسازی رو خیلی جدی می‌گیریم. هر طرح در یک سند جداگانه ارائه میشه که شامل تمام فرایند طراحی، یافته‌ها و دلایل طراح برای طرحیه که ارائه کرده. در کنار این سند، سندی به اسم ملاحظهٔ فنی طرح داریم که تحویل توسعه‌دهنده و QA می‌دیم. از اونجایی که گاهی سند طراحی طولانی میشه و از حوصلهٔ تیم فنی خارجه، در تیم استخدام ما برای این دو مورد سندهای جدایی تهیه می‌کنیم.
سند ملاحظات فنی همراه با فایل نهایی طرح در فیگما تنها چیزیه که توسعه‌دهنده برای پیاده‌سازی طرح بهش نیاز داره.
این سند فلوی کاربر رو خلاصه توضیح می‌ده و شامل مواردی مثل کاربران هدف، ارورهایی که کاربر ممکنه باهاش مواجه بشه و اکشن‌لاگ‌هایی‌ست که برای سنجش اثرگذاری طرح بهشون نیاز داریم.
سناریو‌نویسی با QA بلافاصله بعد از نهایی شدن طرح
مورد جذابی که در صحبت با علی رستگار، لیدر چپتر QA، بهش رسیدیم این بود که بعد از نهایی شدن طرح، سناریوی مسیر کاربر رو بلافاصله با تیم QA مستند کنیم. گاهی وقتا ممکنه بین نهایی شدن یک طرح و پیاده‌سازی اون فاصله بیفته و در زمان پیاده‌سازی طراح درگیر موضوع دیگه‌ای باشه و یا از تیم رفته باشه. با وجود اینکه مستندسازی این مشکل رو تا حد خیلی خوبی برطرف می‌کنه ولی طبق تجربهٔ علی، بهتره که طراح و کارشناس QA بلافاصله بعد نهایی شدن طرح و در زمانی که طراح حضور ذهنی کامل‌تری نسبت به مسئله داره، یک بار فلوی کاربر رو دقیق با هم بررسی کنند و نیروی QA این سناریو رو برای تست فیچر در آینده مکتوب داشته باشه.
همراهی توسعه‌دهنده در طول پیاده‌سازی
تمام موارد مطرح‌شده در این مطلب برای آگاهی‌بخشی توسعه‌دهنده از طرحه و کمک می‌کنه که در فرایند پیاده‌سازی ابهام کمتری وجود داشته باشه. اما بهرحال گاهی توسعه‌دهنده در حین اجرای طرح با سوالاتی مواجه میشه که باید از طراح بپرسه. ما به عنوان طراح تجربهٔ کاربر خودمون رو نسبت به پیاده‌سازی دقیق طرح‌مون مسئول می‌دونیم و در طول پیاده‌سازی همراه توسعه‌دهنده هستیم تا به ابهاماتش پاسخ بدیم.
تست طرح همراه با QA
هر چقدر هم که تخمین‌های دقیقی از هزینهٔ فنی یک طرح قبل از اجرا داشته باشیم باز این امکان هست که توسعه‌دهنده در حین اجرا با محدودیت جدیدی مواجه بشه که قبلا بهش فکر نکرده بودیم. این محدودیت ممکنه باعث بشه ما تغییراتی در طرح ایجاد کنیم. اینجا باید مطمئن بشیم که کارشناس QA از این تغییر آگاه شده و در زمان تست اپ با سناریوی غیرمنتظره‌ای مواجه نمی‌شه. خودمون هم بعد از پایان توسعه همراه QA تست طرح رو انجام می‌دیم. چون در نهایت هیچ‌کس به اندازهٔ ما به جزییات طرح‌مون مسلط نیست.
این موارد خلاصه‌ای از تجربیات من و همکارانم در دیوار بود. ممکنه بعضی از موارد برای طراحانی که در تیم‌های کوچک‌تر و یا فریلنس کار می‌کنند کارآمد نباشه. برای همین به نظرم این ویدیو که راهنمای تحویل طرح به توسعه‌دهنده‌ست برای این افراد می‌تونه خیلی مفید باشه.
اگر شما راه و روش دیگه‌ای رو برای بهبود ارتباط بین طراحان و تیم فنی تجربه کردید، ممنون میشم در قسمت کامنت‌ها باهامون به اشتراک بذارید.
طراحان تجربهٔ کاربر: شیوا شریف‌پور، شیما شرفی نیا، احسان رحیمی، بهنام صبح‌خیز
توسعه‌دهندگان: هادی طباطبایی، دانیال عرفانیان
کارشناسان QA: علی رستگار، پرندوش اسکندری
مطلبی دیگر از این انتشارات
پرسش و پاسخهای اولین جلسهٔ دیوارِ تجربه
مطلبی دیگر از این انتشارات
داده‌های کیفی به کمک داده‌های کمی میآیند!
مطلبی دیگر از این انتشارات
گذر پژوهشگر از سرویسدهنده به همکار