این دفعه همراه محمداسماعیل پدران عزیز رفتیم سراغ نقش و اهمیت تجربه کاربری در دنیای اجایل؛ بوم تجربه کاربری ناب رو میتونید از اینجا دانلود کنید.
مقدمه اپیزود و معرفی موضوع و مهمان
سلام! به یه قسمت دیگه از پادکست اجایل گپ خوش اومدید.
من پدرام کشاورزی‌ام و تو این اپیزود قراره بریم سراغ یکی از اون مرزهای مبهم دنیای چابک؛
جایی که طراحی و توسعه به‌هم می‌رسن، ولی گاهی هم از هم جدا می‌شن...
بله! موضوع امروز: طراحان UI و UX در تیم‌های چابک.
شاید تو تیم خودت یه طراح داری، یا شاید خودت طراح باشی.
یا شاید همیشه برات سؤال بوده که:
– یه طراح دقیقاً چطور باید تو تیم اسکرام جا بگیره؟
– آیا باید تسک بگیره؟ تو بکلاگ بیاد؟ یا جدا از تیم باشه؟
– اصلاً طراحی یه چیزه، توسعه یه چیز دیگه‌ست. چطوری اینا باید با هم هم‌مسیر شن؟
تو این قسمت، با محمد اسماعیل پدران صحبت کردم—یکی از طراحان تجربه کاربری که نه فقط سال‌ها تو فضای دیزاین کار کرده، بلکه تو تیم‌های اسکرامی واقعی بوده، چالش‌ها رو لمس کرده، و دنبال پاسخ‌های کاربردیه.
تو این گفت‌وگو درباره‌ی چیزهایی صحبت کردیم مثل:
مدل PSU برای جایگاه‌یابی نقش‌ها
تفاوت طراحی محصول با طراحی رابط
دوگانگی بین Discovery و Delivery
Lean UX و Dual-track Agile
نقش MVP در هم‌راستایی تیم
و البته اینکه یه طراح چطوری می‌تونه صدای کاربر رو به گوش تیم برسونه بدون اینکه تو کشمکش‌ها گم بشه!
پس اگه می‌خوای بدونی نقش طراح تجربه کاربری دقیقاً کجای تیمه، چه مدلی از همکاری براش مناسب‌تره، و چطور می‌شه اون مرز مبهم بین «دیزاین» و «دِولوپ» رو شفاف کرد… با من همراه باش تو این اپیزود.
شروع گفت‌وگو با محمد اسماعیل پدران؛ از معماری تا تجربه‌ی کاربری در تیم‌های چابک
– [پدرام]: خب محمد جان، خیلی خوشحالم که اینجایی. توی فضای تجربه کاربری، مخصوصاً توی تیم‌های چابک، آدمی هستی که هم بلدی عمیق فکر کنی، هم با عمل گره خورده‌ای.
اول بگو اصلاً چی شد که از معماری رفتی سمت طراحی تجربه کاربری؟
– [محمد]: راستش پدرام، قصه از اونجا شروع شد که همیشه برام مهم بود بدونم کارم واقعاً به درد کی می‌خوره.
تو معماری، گاهی این فاصله بین ایده و استفاده نهایی خیلی زیاده. ولی وقتی با طراحی محصول آشنا شدم، دیدم اینجا می‌تونی با کاربر زنده کار کنی، فیدبک بگیری، و سریع‌تر تاثیر کارت رو ببینی.
همین باعث شد کم‌کم بیام سمت UX. بعدش هم افتادم تو تیم‌های اسکرامی—جایی که همه چی خیلی واقعی‌تره.
– [پدرام]: خیلی جالبه. چون خیلی از آدم‌هایی که تو فضای طراحی هستن، مسیرشون از گرافیک یا هنر اومده. ولی تو با یه ذهنیت سیستمی اومدی—و این احتمالاً رو نگاهت به همکاری تو تیم هم تأثیر گذاشته، درسته؟
– [محمد]: کاملاً! چون اون نگاه معماری باعث شد که همیشه به ساختارها و ارتباط‌ها فکر کنم.
وقتی وارد یه تیم اجایل می‌شی، می‌فهمی که دیزاین فقط یه لایه زیبا نیست؛ یه جور «چسب» بین نیاز کاربر، منطق بیزینس و توانایی فنی تیمه.
و اگه این چسب درست کار نکنه، تیم نمی‌تونه محصول درستی بسازه—even اگه همه اجزاش به ظاهر درست باشن.
– [پدرام]: خیلی باهات موافقم. یه وقتایی یه طراحی عالی داریم، یه تیم قوی، ولی انگار یه چیزی بینشون گم شده.
و همون‌جاست که دیزاینر اگه فقط روی خروجی تمرکز کنه، نه روی فرآیند، به مشکل می‌خوره.
– [محمد]: آره، و اونجا دقیقاً بحث «جایگاه دیزاینر» تو تیم میاد وسط—که قراره تو ادامه حسابی راجع بهش حرف بزنیم.
مدل PSU؛ سه‌ضلعی دیدگاه طراح تجربه کاربری در تیم چابک
– [پدرام]: خب محمد، گفتی که دیزاین یه جور چسبه بین نیاز کاربر، بیزینس و تیم.
من می‌دونم یه مدل مفهومی برات خیلی مهمه تو این فضا—مدل PSU.
می‌خوای یه کم درباره‌ش توضیح بدی؟
– [محمد]: حتماً. PSU یه مدل ساده ولی خیلی کاربردیه. مخففه‌ی:
Product
Service
User
یعنی یه طراح تجربه کاربری نه فقط به محصول فکر می‌کنه، بلکه همزمان باید بفهمه:
این محصول تو چه «سرویسی» تعریف می‌شه، و اون سرویس قراره چه «نیاز انسانی‌ای» رو حل کنه.
و خب وقتی می‌خوای توی یه تیم اجایل باشی، اگه فقط از زاویه‌ی Product یا فقط User نگاه کنی، یه ضلع همیشه کمه.
– [پدرام]: خیلی جالبه. چون معمولاً طراحها یا خیلی عاشق کاربر می‌شن، یا غرق UI.
ولی این نگاه PSU باعث می‌شه یه جور تعادل بین «هدف بیزینس»، «نیاز کاربر»، و «قابلیت اجرایی» ایجاد بشه.
– [محمد]: دقیقاً! و اتفاقاً همین سه‌تا ضلع می‌تونن نقطه‌ی گفت‌وگوی مشترک بین طراح، دولوپر، و PO باشن.
یعنی اگه یه طراح فقط به User فکر کنه و ندونه تیم فنی چی رو می‌تونه پیاده کنه، یا بیزینس دنبال چه ارزشی هست،
ممکنه راه‌حل‌هایی بده که هرگز اجرا نشن—یا بدتر، اجرا بشن ولی به درد نخورن.
– [پدرام]: یعنی یه طراح تجربه کاربری واقعی باید هم empathic باشه، هم strategic، هم technical-aware؟
– [محمد]: کاملاً! و اینجاست که چالش شروع می‌شه. چون توی فریم‌ورک‌هایی مثل Scrum، این نقش مشخص نشده.
ما یه PO داریم، یه تیم توسعه داریم، ولی طراح تجربه کاربری بین اینا یه‌جورایی «نقش خاکستری» داره.
و اگه این ambiguity مدیریت نشه، یا طراح خودش ندونه چجوری خودش رو تو این ساختار جا بده،
ممکنه یا حذف بشه، یا فقط به یه «ویجت‌زن» تبدیل شه.
طراح تجربه کاربری در اسکرام؛ عضو تیم توسعه یا نقش مستقل؟
– [پدرام]: خب محمد، حالا بیایم شفاف‌تر صحبت کنیم. توی اسکرام ما یه Product Owner داریم، یه تیم توسعه، و یه اسکرام مستر.
ولی هیچ اشاره مستقیمی به نقش طراح UX نشده.
تو تجربه‌ت، یه طراح بهتره عضو تیم توسعه باشه؟ یا بیرون از تیم؟ یا یه جور نقش بینابینی؟
– [محمد]: سوال خوبیه. به‌نظر من هیچ جواب واحدی نداره. بستگی داره به بلوغ سازمان، فرهنگ تیم، و حتی حجم کاری.
ولی اگه بخوام یه جواب کاربردی بدم، می‌گم:
طراح باید "درگیر" باشه، نه الزاماً "وابسته".
یعنی چی؟
یعنی نباید طراح توی اتاقی جدا بشینه، چیزی طراحی کنه، بعد بده دست تیم و بره.
باید داخل چرخه‌ی گفت‌وگو باشه. داخل Dailyها، داخل Planning، داخل Backlog Refinement.
ولی در عین حال، ممکنه تمام‌وقت عضوی از تیم توسعه هم نباشه.
– [پدرام]: یعنی شبیه به یه consultant داخلی عمل کنه؟ کسی که دسترسی‌اش همیشگیه، ولی مال تیم نیست؟
– [محمد]: تو بعضی سازمان‌ها آره، دقیقاً همین مدله. ولی وقتی یه محصول داره رشد می‌کنه،
و طراح قراره مدام با تحقیقات کاربر، تست فرضیه، و ارزیابی تجربه سروکار داشته باشه،
حضورش تو تیم توسعه باید خیلی نزدیک باشه.
وگرنه تیم فقط خروجی رو می‌بینه، نه فرآیند طراحی رو.
– [پدرام]: و اینجاست که اون شکاف بین «دیزاین» و «دِولوپ» ایجاد می‌شه. چون وقتی طراحی جدا اتفاق می‌افته، ارتباطش با واقعیت‌های فنی و بیزینسی قطع می‌شه.
– [محمد]: دقیقاً. این شکاف معمولاً باعث می‌شه طراح فکر کنه «تیم توسعه منو درک نمی‌کنه»
و توسعه‌دهنده هم بگه «دیزاینر یه چیز رویایی داده که ما نمی‌تونیم بسازیم!»
و اگه ما بخوایم چابک باشیم—واقعاً چابک—باید این ارتباط همیشه در جریان باشه.
و این یعنی، یا طراح باید تو تیم جا بگیره، یا ساختار تیم باید طوری باشه که طراح دائماً درگیر تصمیم‌سازی باشه، نه فقط خروجی‌سازی.
Dual-track Agile؛ طراحی و توسعه روی دو ریل موازی
– [پدرام]: خب محمد، گفتی که طراح نباید فقط خروجی بده، باید توی تصمیم‌سازی حضور داشته باشه.
حالا یکی از مدل‌هایی که این مسئله رو حل می‌کنه، Dual-track Agile یا همون دو مسیر موازیه.
می‌خوای یه کم برامون توضیح بدی که این مدل چیه و چطوری کار می‌کنه؟
– [محمد]: حتماً. توی مدل Dual-track، ما دوتا مسیر همزمان داریم:
۱. Discovery: مسیر کشف، که توش تحقیق می‌کنیم، فرضیه می‌سازیم، تست می‌کنیم، یاد می‌گیریم.
۲. Delivery: مسیر تحویل، که توش آیتم‌هایی که اعتبارسنجی شدن، پیاده‌سازی می‌شن.
توی این مدل، طراحها و محصول‌گراها بیشتر توی Discovery فعالن، ولی ارتباطشون با مسیر Delivery قطع نمی‌شه.
یعنی کشفیات هر لحظه می‌تونن بیفتن توی بکلاگ تیم و وارد جریان تحویل بشن.
– [پدرام]: یعنی یه جور موازی‌کاری هدفمنده؟ نه اینکه «طراح جدا باشه»، بلکه «دوتا جریان مکمل» باشن؟
– [محمد]: دقیقاً!
تو مدل سنتی، طراح اول طراحی می‌کنه، بعد می‌ده دست توسعه.
تو اسکرام نابالغ هم، گاهی طراح تلاش می‌کنه توی اسپرینت کنار توسعه‌دهنده باشه، ولی چون فرآیند تحقیق زمان‌بره، از اسپرینت عقب می‌افته.
Dual-track Agile می‌گه: مشکلی نداره! اجازه بده این دوتا جریان با هم حرکت کنن.
فقط مهمه که هماهنگ باشن، نه همزمان.
طراحها می‌تونن یه اسپرینت جلوتر کار کنن، یا همزمان با توسعه، ولی در فاز متفاوت.
– [پدرام]: خیلی جالبه. چون این مدل به طراح این فرصت رو می‌ده که با آرامش، ولی هم‌راستا با تیم، حرکت کنه.
و همزمان، تیم توسعه هم از زمین واقعیت جدا نمی‌شه.
– [محمد]: آره، و اینجاست که MVP، Hypothesis، و Continuous Validation هم معنی پیدا می‌کنن.
یعنی طراحی، بخشی از ساخت محصول می‌شه، نه صرفاً تولید قاب یا ظاهر.
این مدل کمک می‌کنه که اون «چسب» PSU که درباره‌ش حرف زدیم، واقعاً کار کنه.
و دیگه لازم نیست طراح همیشه دنبال توجیه کردن باشه؛ چون از اول توی مسیر بوده، نه بیرونش.
Lean UX؛ طراحی چابک، سریع و هم‌راستا با تیم
– [پدرام]: خب محمد، یه مفهوم دیگه‌ای هم هست که این روزها خیلی سر زبون‌هاست: Lean UX.
می‌دونی که تو دنیای اجایل، همه‌چی باید Lean باشه! ولی Lean UX دقیقاً یعنی چی؟ و چه فرقی با طراحی سنتی داره؟
– [محمد]: خیلی سؤال خوبیه. Lean UX یعنی:
تمرکز کمتر روی سند و داکیومنت و خروجی‌های حجیم،
و تمرکز بیشتر روی یادگیری مستمر، تست سریع فرضیه‌ها، و همکاری تیمی.
برخلاف طراحی کلاسیک که اول یه سند مفصل می‌نویسیم، بعد وایرفریم، بعد طراحی نهایی...
تو Lean UX می‌گی: بیاید یه فرضیه بسازیم، سریع یه چیزی تست کنیم، فیدبک بگیریم، یاد بگیریم، اصلاح کنیم.
– [پدرام]: یعنی یه جور «طراحی به‌مثابه آزمایش»؟
– [محمد]: دقیقاً! تو Lean UX می‌خوای بدونی «آیا راه‌حلی که داری طراحی می‌کنی واقعاً به یه مشکل واقعی جواب می‌ده یا نه؟»
و به‌جای اینکه انرژی‌تو بذاری روی سندهای قطور، می‌ذاری روی تعامل با کاربر، مشارکت با تیم، و تجربه‌ی واقعی.
– [پدرام]: و اینجا طراح دیگه یه «تحویل‌دهنده‌ی خروجی» نیست، بلکه می‌شه یه «تسهیل‌گر یادگیری تیم».
– [محمد]: آره، و نکته‌ی مهمش اینه که Lean UX فقط مال طراح نیست.
یه طراح UX توی تیم چابک باید با توسعه‌دهنده، PO، و حتی ذی‌نفع‌ها بشینه کنار هم و فرضیه بسازه.
با هم تصمیم بگیرن که چی باید تست بشه، و با هم مسئول باشن برای یادگیری از نتیجه.
یعنی دیگه دیزاین یه مرحله قبل از توسعه نیست. خودش بخشی از چرخه‌ی یادگیری محصوله.
– [پدرام]: و این دقیقاً اون چیزیه که Agile ازمون می‌خواد. یادگیری مستمر، انطباق، و پاسخ به تغییر.
نه فقط برای کد، بلکه برای طراحی هم.
حضور طراح در بکلاگ؛ چطور طراحی وارد جریان اسپرینت بشه؟
– [پدرام]: خب محمد، بریم سراغ بکلاگ.
یکی از سؤال‌هایی که خیلی‌وقت‌ها ازم می‌پرسن اینه:
طراح تجربه کاربری باید آیتم طراحی رو تو بکلاگ بیاره یا نه؟
اصلاً تسک طراحی، استوری طراحی، جاش تو Product Backlog هست؟ یا باید جدا باشه؟
– [محمد]: واقعیت اینه که طراحی، اگه قراره بخشی از محصول باشه، باید تو بکلاگ هم دیده بشه.
نه فقط دیده بشه، بلکه با همون شفافیت، پذیرش، و خروجی قابل بررسی که برای آیتم‌های فنی داریم.
مثلاً اگه ما یه صفحه‌ی جدید داریم که نیاز به طراحی اولیه داره،
اون طراحی می‌تونه یه Story باشه با Definition of Done مشخص: مثلاً وایرفریم تاییدشده با تیم.
اگه قراره بره تست کاربر، اونم می‌تونه یه آیتم باشه.
یعنی ما طراحی رو از «یه اتفاق ذهنی تو Slack» می‌اریم توی یه «آیتم واقعی که قابل پیگیریه».
– [پدرام]: خیلی نکته‌ی مهمیه. چون گاهی طراحا یه گوشه دارن کار خودشونو می‌کنن و PO هم نمی‌دونه دقیقاً چی در جریانه.
– [محمد]: آره. این باعث می‌شه شفافیت از بین بره. و چیزی که توی اجایل خیلی براش ارزش قائلیم همینه دیگه: شفافیت.
اگه تیم ندونه طراحی در چه وضعیه، نمی‌تونه براش برنامه‌ریزی کنه.
اگه PO ندونه چه فرضیه‌ای در حال تست شدنه، نمی‌تونه ارزشش رو ارزیابی کنه.
برای همین طراحی هم باید تو Backlog بیاد—با همون شفافیت، همون اولویت‌بندی، و همون مسئولیت‌پذیری.
– [پدرام]: یعنی دیزاینر هم تو Sprint Planning باید حضور فعال داشته باشه، آیتم‌هاشو بزنه، Definition of Done طراحی رو تعریف کنه، و حتی تو Review بیاد نتیجه‌شو نشون بده.
– [محمد]: دقیقاً! اون‌وقت طراحی می‌شه یه «بخش زنده از جریان توسعه» نه یه جزیره‌ی جدا.
تعامل طراح با ذی‌نفعان؛ صدای کاربر تو تصمیم‌سازی تیم
– [پدرام]: خب محمد، حالا بیایم بیرون از تیم توسعه.
یکی از جاهایی که خیلی وقت‌ها طراحها یا نادیده گرفته می‌شن یا بیش‌ازحد فشار روشونه، ارتباط با Stakeholderهاست.
تو چی فکر می‌کنی؟ طراح باید با ذی‌نفع‌ها در تماس باشه؟ یا فقط PO این کار رو بکنه؟
– [محمد]: من می‌گم صدای طراح تجربه کاربری، اگه قراره صدای کاربر باشه، باید تو اتاق تصمیم‌سازی شنیده بشه.
ولی این به این معنی نیست که همیشه به‌جای PO بره جلسه یا ارتباطات رسمی رو برعهده بگیره.
بلکه باید کنار PO باشه، مخصوصاً اون‌جایی که قراره تصمیم درباره تجربه‌ی واقعی کاربر گرفته بشه.
– [پدرام]: یعنی مثلاً اگه قراره یه فیچر جدید طراحی بشه که تجربه‌ی کاربر رو عوض کنه، طراح باید توی اون گفت‌وگو باشه، درسته؟
– [محمد]: دقیقاً. چون خیلی وقت‌ها Stakeholder فقط از زاویه‌ی بیزینسی یا فروش به ماجرا نگاه می‌کنه.
وظیفه‌ی طراح اینه که اونجا یه صدای دیگه بیاره؛ صدای آدمی که قراره از محصول استفاده کنه.
نه برای مقابله، برای تکمیل تصمیم.
– [پدرام]: یعنی طراح یه‌جور «مدافع تجربه کاربر» توی فرآیندهای سازمانیه؟
– [محمد]: خیلی قشنگ گفتی.
در واقع نقش طراح UX در جلسات Stakeholder، می‌تونه مثل یه مترجم باشه؛
کسی که بین زبان بیزینس و زبان نیازهای انسانی، یه پل بزنه.
البته برای این کار، طراح باید بتونه خوب گوش بده، خوب تحلیل کنه، و با قاطعیت ولی بدون تعصب صحبت کنه.
– [پدرام]: و اینجاست که باز می‌رسیم به موضوعی که از اول گفتی: طراح نباید فقط «خروجی‌محور» باشه، باید «تأثیرمحور» باشه.
یعنی نه فقط طراحی کنه، بلکه تو تأثیر تصمیمات روی تجربه‌ی کاربر هم مشارکت داشته باشه.
– [محمد]: دقیقاً همین. و اگه این فضا باز بشه، تیم هم ازش نفع می‌بره، هم کاربر نهایی.
جمع‌بندی و دعوت به تأمل برای شنونده‌ها
– [پدرام]: خب محمد جان، خیلی گفت‌وگوی مفصل، واقعی و پر از تجربه بود.
از مسیر حرفه‌ایت تا مدل PSU، از حضور طراح تو بکلاگ و تیم توسعه، تا تعاملش با Stakeholderها...
فکر می‌کنم یه نقشه‌ی خوب ساختیم از جایگاه واقعی یه طراح تجربه کاربری تو تیم‌های چابک.
– [محمد]: مرسی از تو پدرام، برای اینکه فضا دادی به یه گفت‌وگو که معمولاً یا سطحی برگزار می‌شه، یا اصلاً اتفاق نمی‌افته.
امیدوارم این اپیزود بتونه یه تلنگر باشه—چه برای طراح‌هایی که تو تیم‌های اجایلن، چه برای تیم‌هایی که دنبال تعامل بهتر با دیزاین هستن.
– [پدرام]: و حالا نوبت شماست که فکر کنید.
سؤال من برای شما که این اپیزود رو شنیدید اینه:
تو تیم شما، طراح تجربه کاربری کجای تصمیم‌سازی قرار داره؟
توی بکلاگه؟ تو جلسه‌ها هست؟ آیا واقعاً صدای کاربر از زبونش شنیده می‌شه یا فقط تحویل‌دهنده‌ی UIه؟
اگه دوست داشتید، تجربه‌هاتون رو با ما به اشتراک بذارید.
چه توی وبسایت اجایل گپ، چه توی لینکدین، یا جاهایی که پادکست رو دنبال می‌کنید.
و یادتون نره:
وبسایت اجایل گپ، فقط جایی برای شنیدن نیست؛
اونجا میتونید اپیزودها رو بر اساس موضوع مرور کنید، لایک و کامنت بذارید، متن کامل هر اپیزود رو بخونید،
و اگه خواستید، ایمیلتون رو ثبت کنید تا به‌محض انتشار اپیزود جدید، مستقیم مطلع بشید.
تا قسمت بعدی، بدرود.
با ذهنی باز، و تیمی هم‌راستا.
