جدال یا تعامل؟ ۱۰ راهکار برای پایانِ کشمکش تیم فنی و نویسنده تجربه کاربر
موش روی حلقۀ تکرارش می‌دود؛ اگر از دورِ باطل بیرون نپرد. کشمکش تیم فنی و نویسنده تجربه کاربر بی‌شباهت به این دورِ باطل نیست. چرا؟
دو تخصص در دو دنیای متفاوت برابرِ هم قرار می‌گیرند. جدال کنند یا تعامل؟ در ظاهر همگی تعامل را ترجیح می‌دهیم، امّا در عمل، بارها کار به جدال می‌کشد.
بیایید با یک مثالِ ظاهراً بی‌ربط به ماجرا نزدیک بشویم:
«مادرکشی» نام مستندی‌ست که به بحرانِ آب در ایران می‌پردازد. در این فیلم می‌فهمیم چه کسانی برای موضوعِ آب (تقسیم و اختصاص و مدیریت و…) تصمیم‌سازی می‌کنند: سیاست‌مداران و مهندسان.
آنچه مستند مادرکشی یادآوری می‌کند، اهمیتِ «انسانی» آب است: موضوعی که فن‌ورزان نمی‌توانند همۀ ابعادش را به‌خوبی ببینند، چون آن‌ها فن‌ورز (Technical) هستند نه متفکر یا مردم‌شناس، یا اقلیم‌شناس یا جامعه‌شناس.
بحران‌ها و نزاع‌های اجتماعی، خالی از سکنه شدنِ روستاها، تغییرهای اقلیمی و بسیاری دیگر از این پیامدهای تلخ در چند دهۀ گذشته، ناشی از تصمیم‌گیریِ تک‌بعدی در حوزۀ آب بوده است.
واقعیت این است: درهای اتاقی که در آن دربارۀ مهمترین عاملِ یکجانشینی تصمیم‌گیری می‌شود به روی کارشناسانِ حوزه‌های علوم انسانی و زیست‌محیطی بسته است. به همین دلیل است که فلان نمایندۀ مجلس به‌سودای انتخابِ مجدد قولِ سدسازی یا راه‌اندازی کارخانه در شهرش را می‌دهد و سپس با تحت فشار قراردادنِ وزرای پیشنهادی دولت‌ها، به وعده‌اش عمل می‌کند تا دورِ بعدی هم در کورس رقابت برنده باشد.
مستند مادرکشی یادآوری می‌کند که نمی‌توان برای موضوعات انسانی، «فن‌ورزانه» تصمیم گرفت.
نتیجه؟ نتیجه‌اش می‌شود احداثِ یک کارخانۀ آب‌بر (پرمصرف) در کویرهای اصفهان و یزد و کرمان. چه کسی این سیاست را اجرا می‌کند؟ مهندس، مهندسی که یک اجراکار، کننده و انجام‌دهنده است و شناختی از زوایای انسانی و محیط زیستی ندارد.
حالا تصور کنید دو گروهِ متفکران علوم انسانی (مردم‌شناسان و جامعه‌شناسانِ آب) در کنار مهندسانِ سدساز تصمیم‌سازی کنند. آیا نتیجه همین می‌شد که امروز در خبرها یا لوله‌های آب شهری می‌بینیم؟ آیا توسعۀ شهرها به همین منوال بود؟ آیا سدهای خشک ساخته می‌شدند؟
اما اگر امروز پای صحبت‌های مهندسان بنشینید از علوم انسانی بد می‌شنوید و برعکس. جدال ظاهراً جذابیتِ بیشتری دارد.
کشمکش بین تیم فنی و نویسنده تجربه کاربر
زمانی که پیشنهادِ پروژۀ تازه‌ای می‌رسد در دلم آرزو می‌کنم با دو گروه سر و کار نداشته باشم:
- مهندسان (در هر رشته‌ای اعم از برنامه‌نویسی، کامپیوتر، معماری و…)
- تاجران سنّتی
تجربۀ کار با هر دو طیف را داشته‌ام و اگر باز هم پیش بیاید، مشکلی از پذیرشِ چالشِ تازه ندارم. اما چرا آرزو می‌کنم طرفِ حسابم طراحان باشند و نه مهندسان؟
تیم‌های طراحی گرایشِ انسانی‌تری دارند. مواجهۀ بی‌پرده با کاربر و سر و کار داشتن با تحقیقات کاربر، از آن‌ها افرادی درک‌پذیر می‌سازد.
کشمکش تیم فنی و نویسنده تجربه کاربر زمانی رخ می‌دهد که یکی از طرفین یا هر دو طرف به‌جای حل مسئله با تکیه بر هم‌افزایی، روی مواضع و نظرهای خود پافشاری می‌کنند و حرف طرف مقابل را به‌طور مطلق رد می‌کنند.
هم‌افزایی یا جدال؟
دوستی دارم که می‌گوید «آدمِ مطمئن احمق است». راستش با او موافقم و در حین کار هم، هرگز مطمئن نیستم بی‌عیب یا کاملم. بارها در طول انجام پروژه‌های مختلف، از افراد عادی و بی‌ارتباط به تجربه‌نویسی یا طراحی تجربه مشورت می‌گیرم و دربارۀ چیزهایی که نمی‌دانم، پرس‌وجو می‌کنم.
اما من هم از کشمکش تیم فنی و نویسنده تجربه کاربر در امان نبوده‌ام. این کشمکش در اجرای پروژه‌هایی که بار فنی‌تری دارند جدی‌تر می‌شود، چرا که دانشِ یوایکس رایتر در زمینه‌های فنی، هم‌سطحِ یک متخصص نیست.
در این اوضاع چطور می‌توان از کشمکش تیم فنی و نویسنده تجربه کاربر کاست و با بیشترین هم‌افزایی و کمترین اصطکاکِ منفی کار را جلو برد؟
دلایل اصطکاک بین دو تیم تجربه‌نویس و فنی
مرورِ دلایل، مقدمۀ رسیدن به راه‌حل است:
خودمحوری و خودرأیی:
همۀ ما فکر می‌کنیم جهان متکی به تخصص ماست و تخصص‌های دیگر همگی ذیلِ تخصص ما قرار می‌گیرند. از این گذشته، تصور می‌کنیم چون در فلان موضوع دانش داریم، همه چیز را می‌دانیم.
اصرار بر الگوهای ذهنی:
ترجیح می‌دهیم الگوهای ذهنی‌مان را تکرار کنیم و به پیش‌فرض‌هایمان دست نزنیم.
آگاهی اندک دربارۀ تخصصِ طرف مقابل:
کشمکش تیم فنی و نویسنده تجربه کاربر پررنگ است چون سؤال‌های بسیاری دربارۀ کیفیت و چیستی تجربه‌نویسی باقی مانده. این حرفۀ نوپدید تا جاافتادن راه درازی در پیش دارد. طبیعی‌ست که «کسی که می‌نویسد» آنقدرها هم از سوی «مهندس» جدی گرفته نشود.
اصرار بر حفظ شأن خود:
نویسندگان و مهندسان هر دو انسان‌اند و انسان میلی ذاتی به تأیید دارد. ما دوست داریم دیگران را به تبعیت وادار کنیم. دوست داریم از دیگران جملۀ جادویی «بله، درست است» را بشنویم.
وقتی پای صحبت نویسندگان می‌نشینیم یا مطالب لینکدین‌شان را می‌خوانیم، پر از غرغرهایی از این دست است: «نمی‌فهمند، اهمیت نمی‌دهند، متوجه ویژگی‌ها و اقتضائات کار نیستند». من با غرغرکردنِ خالی موافق نیستم، ولی باید پذیرفت که این مضمون‌های پرتکرار بیراه نیستند.
اصالتِ فن و فن‌سالاری (Technocracy)
حلِ مسئله‌ها به کمک فن (مثل حل مشکل آب به کمک سدسازی یا حفر تونل یا انتقال آب خلیج فارس یا اجرای طرح زود و فرد یا قطع‌کردن برق برای کاهش مصرف و…) سابقۀ طولانی‌ای در سرزمین ما دارد.
اخته‌شدنِ «تفکر» و توقفِ زایاییِ «اندیشه»، سال‌هاست که ما را به مصرف‌کنندۀ فنونِ وارداتی تبدیل کرده است. سال‌هاست که متخصصانی که یک فن (مهندسی مکانیک، مهندسی عمران، مهندسی معماری، مهندسی غیره و غیره و غیره) بلدند، در رأس هرم تصمیم‌سازی می‌نشینند و از احترام اجتماعی بالاتری هم برخوردارند.
حکمرانانِ ما بابتِ زیاد شدنِ تعدادِ شرکت‌های دانش‌بنیان و استارتاپ‌ها جشن می‌گیرند، اما حقیقت این است که اغلب اندیشه‌ای وجود ندارد، بلکه تعدادِ کسانی که یک مهارت را بلدند بیشتر می‌شود، مهارتی که لزوماً برخاسته از نیازسنجی‌های بومی هم نیست.
یک فن‌ورز از یک جامعه‌شناسِ خبره یا روان‌شناسِ متبحر یا فیلسوف اعتبار بیشتری دارد، حال آنکه پیشرفت‌های فناورانۀ دنیای غرب، روی فلسفۀ غرب استوار است. (مثلاً فلسفۀ روشنگری غربی تحول جدی‌ای در ساختارهای جامعه و به‌تبع آن تغییرهای صنعتی ایجاد کرد).
همیشه گفته‌ام: ما باید بینِ عملۀ فن بودن و متفکر بودن دست به انتخاب بزنیم، وگرنه مسیرِ پیشِ روی ما، چیزی جز اجرای آنچه به‌اشتباه «علم» می‌نامیم نیست. علم مفهومی متفاوت از «مهارت» و «فن» است.
اقتضائات تجربه‌نویسی فنی (Technical UX Writing)
در طراحی فرایند و اجرای تجربه‌نویسی فنی در نظر گرفتن موضوعات مختلف ضروری‌ست. برخی از موارد مؤثر بر یوایکس رایتینگ فنی با سایر انواع تجربه‌نویسی یکسان است و برخی هم مقیاس وسیع‌تری دارد.
در ادامه برخی از نکاتی که در تجربه‌نویسی فنی اثرگذار است را فهرست کرده‌ام:
- بررسی Persona
- بررسی بازخوردهای دریافت‌شده در تیم پشتیبانی محصول
- بررسی نظرسنجی‌ها و نتایج تحقیقات کاربر
- آگاهی از نیازهای کاربر (ما باید بتوانیم قبل از ایجاد سؤال به کاربر پاسخِ راهنمایی‌کننده بدهیم.)
- لحن و صدا
- رسم‌الخط
- خطاها (طبقه‌بندی و شناسایی آثار هر خطا بر فرایند کاری کاربر و احساسات کاربر.)
- بازبینی چندباره و بهبود مداوم
- شناخت آثار و ارزش محصول (چه کار می‌کند؟ چطور؟)
- در نظر گرفتن فازهای توسعۀ محصول (چیزی ننویسید که در توسعۀ محصول به مشکل بخورد و بی‌معنی شود.)
- طراحی فرمولِ فراگیر برای کلیدها، پیام‌ها، ریزه‌نوشته‌ها
- فراگیری کارکرد هر بخش (این روند دائمی‌ست چون هر محصول به‌طور معمول قابلیت‌های تازه ارائه می‌کند.)
- درک مسیر کاربر در هر بخش یا مرحله
- درک این موضوع که کدام نوشته محصول/برند را به هدفش نزدیکتر می‌کند
- بررسی دقت و شفافیت مفاهیم و عملکرد درست‌شان
- ارائه پیشنهاد برای بهبود طراحی
- بررسی فضای اشغال‌شدۀ متن و رعایت تناسب‌شان با طراحی
- مرور، مرور و بازنویسی تا رسیدن به بهترین نسخه
می‌توانیم هر کاری را سرسری بگیریم. در این صورت نباید از نتیجۀ ناامیدکننده غافلگیر شویم. می‌توانیم به‌جای صرف زمان و انجام کار با کیفیت، همچنان به کشمکش تیم فنی و نویسنده تجربه کاربر دامن بزنیم و بدترین نتیجه را از تجربه‌نویسی فنی بگیریم.
این راه انسانی‌ست
ما برای چه کسی محصول طراحی می‌کنیم؟ برای انسان. آیا می‌شود انسانیت و ویژگی‌های انسانیِ این موجود را ندید گرفت و صرفاً فنی به ماجرا نگاه کرد؟
از طرف دیگر باید در نظر گرفت که تجربه‌نویسیِ فنی، نیازمند اشراف بر موضوعات و اصطلاحات فنی‌ست. شاید لازم نباشد مثل یک فن‌ورز بر موضوع متمرکز باشیم، اما لازم است به‌قدر کافی دربارۀ آن موضوع اطلاعات کسب کنیم.
اگر تخصص خود را محور قرار بدهیم، بی‌برووبرگرد به کشمکش تیم فنی و نویسنده تجربه کاربر دامن می‌زنیم.
راه‌کارهایی برای کاستن از کشمکش تیم فنی و نویسنده تجربه کاربر
- هم‌افزایی کنیم نه جدال: حل کشمکش تیم فنی و نویسنده تجربه کاربر جز به تعامل انسانی ممکن نمی‌شود. «همه چیز را همگان داند.» و ما همگان نیستیم. باید به تخصصِ دیگری اعتماد کنیم و برای خلق یک فرایندِ نتیجه‌بخش، هم‌افزایی کنیم.
- موضوعِ بحث و اختلاف‌نظر را از زاویۀ دیدِ طرف مقابل ببینیم. محصول تک‌وجهی نیست. اگر به حرف دیگری گوش بدهیم و دغدغۀ او را به‌خوبی بشنویم، به نتیجۀ بهتری می‌رسیم. اگر روی زاویۀ نگاه خودمان پافشاری کنیم موفقیتی در حل کشمکش تیم فنی و نویسنده تجربه کاربر کسب نمی‌کنیم.
- اقتضای کارِ طرف مقابل را درک کنیم و بپذیریم. بهتر است در ابتدای همکاری، قلق‌ها و اقتضائات کاری یکدیگر را بشنویم و از طرف مقابل بخواهیم دغدغه‌هایش را با ما مطرح کند. انتقالِ درست و کاملِ مفاهیم برای تیم فنی اهمیت بالایی دارد. از طرفِ دیگر، چکش‌کاریِ پیوستۀ ریزه‌نوشته‌ها هم برای تجربه‌نویس مهم است. گاهی ممکن است برای رسیدن به یک جملۀ چند کلمه‌ای، ساعت‌ها وقت صرف شود و چند صفحه متن نوشته شود.
- برای انتقالِ دقیق‌تر مفاهیم، از «متن» به‌جای «شفاهیات» استفاده کنیم. متن مکتوب همواره قابل تکیه‌تر از شفاهیاتی‌ست که ممکن است فراموش شوند.
- قبل از شروعِ کار، مفاهیم و فرایندها را برای یکدیگر شفاف کنید. فرایندها اصولِ تغییرناپذیر نیستند. مناسب‌ترین شیوه را متناسب با نیاز هر دو طرف طراحی کنید و در این زمینه منعطف باشید. روی سبکِ شخصی‌تان اصرار نکنید. تجربه‌نویسی یک کار تعاملی‌ست نه یک کار انفرادی.
- اگر تجربه‌نویس (یوایکس رایتر) هستید، برای فهم دقیق‌تر مفاهیم فنی از روش‌های مختلف استفاده کنید. جستجو و مطالعه، پرس‌وجو از متخصص و برگزاری جلسه‌های توجیهی روش‌های مفیدی هستند.
- بخش عمدۀ کشمکش تیم فنی و نویسنده تجربه کاربر ناشی از تازگیِ تجربه‌نویسی است. به‌عنوان تجربه‌نویس موظف هستید ویژگی‌ها، نتیجه‌ها و فرایندهای شفاف کاری‌تان را توضیح دهید.
- تجربه‌نویسی یک حرفۀ چندوجهی‌ست. ux writer یک میرزابنویس یا ویراستارِ صوری-زبانی نیست. از او توقع نداشته باشید عینِ جمله‌های شما را ویرایش و نهایی کند. تجربه‌نویس تلاش می‌کند مفاهیمی را که کژتابی دارند ساده کند، تلاش می‌کند طوری بنویسد که هر ریزه‌نوشته یا دکمه بیشترین بارِ «راهنمایی قبل از شکل‌گیری ابهام» را داشته باشد.
- عجله نکنید. کارِ تجربه‌نویس بی‌شباهت به کوه یخ نیست. تک‌جملۀ کوتاهی که در کارِ نهایی یا نسخۀ ابتدایی می‌بینید حاصلِ ساعت‌ها سر و کله زدن با کلمات مختلف است. نویسنده تجربه کاربر نمی‌تواند در لحظه تصمیم‌گیری کند چون برای نهایی‌کردن یک متن، به در نظر گرفتنِ یک منظومه به‌نام «design system» وابسته است.
- به‌جای اصرار روی حرف خود، راهکار بسازید. تجربه‌نویس به کمک شما می‌آید نه به جنگ شما.
تجربه‌نویس فنی
آیا آیندۀ بازار یوایکس رایتینگ شاهد ظهور تجربه‌نویس فنی خواهد بود؟ هیچ بعید نیست. اگر نیاز بازار به‌قدر کافی باشد، احتمالِ شکل‌گیری زیرشاخته‌هایی در حوزۀ تجربه‌نویسی بالاست.
حضور یک تجربه‌نویس فنی به رفع کشمکش تیم فنی و نویسنده تجربه کاربر منجر می‌شود. اما چنین متخصصی باید چه مهارت‌هایی داشته باشد؟ آیا صرفِ داشتن دانش فنی کفایت می‌کند؟ نه. ممکن است یک فن‌ورز با داشتن مهارت نسبی در نوشتن به فکرِ تجربه‌نویسی فنی بیفتد. اما اگرچه این کار بار کشمکش تیم فنی و نویسنده تجربه کاربر را کم و تیم فنی را خوشحال می‌کند، اما تضمینی نیست که کاربر هم خوشحال باشد.
بنابراین مهم است که یک تجربه‌نویس تمام‌وکمال باشد: ماهر در تجربه‌نویسی (به‌معنای نویسندۀ متخصص در حوزۀ تجربه کاربر) و ماهر در حوزۀ فنی.
مطالعۀ بیشتر
می‌توانید در زمینۀ تجربه‌نویسی فنی به مطلب خوب خانم اسنی سین در زتادیزاین رجوع کنید.
