https://virgool.io/feed/@faezeuxi طراح رابط و تجربه کاربری‌ام. درباره طراحی محصول، تجربه کاربری، و دنیای دیجیتال می‌نویسم. ساده‌سازی، دغدغه‌ی همیشگی منه. fa 2026-04-14 09:06:14 https://files.virgool.io/upload/users/4061053/avatar/avatar.png?height=120&width=120 https://virgool.io/@faezeuxi https://virgool.io/@faezeuxi/%D9%85%D8%B5%D8%A7%D8%AD%D8%A8%D9%87-ux-%D8%AF%D8%A7%D8%B1%DB%8C-%D9%82%D8%A8%D9%84%D8%B4-%D8%A8%D8%A7%DB%8C%D8%AF-%D9%88%D8%A7%DB%8C%D8%AA-%D8%A8%D8%B1%D8%AF-%DA%86%D9%84%D9%86%D8%AC-%D8%B1%D9%88-%D8%A8%D8%B4%D9%86%D8%A7%D8%B3%DB%8C-uhxqqdkt4hci اگر تا حالا در مصاحبه UX شرکت کرده‌اید، حتما با بخش وایت‌برد چلنج مواجه شدید. این قسمت از مصاحبه می‌تواند ترسناک به نظر برسد، اما با شناخت درست مراحل، اشتباهات رایج و تمرین عملی، می‌توانید برنده شوید. در این مقاله، همه چیز درباره وایت‌برد چلنج، از اصول اولیه تا تکنیک‌های حرفه‌ای، آورده شده است.وایت‌برد چلنج چیه و چرا باید براش آماده باشیم؟تصور کن وارد یه مصاحبه کاری به‌عنوان طراح UI/UX می‌شی. مصاحبه‌کننده یه ماژیک می‌ده دستت و می‌گه:«فرض کن باید یه اپلیکیشن برای رزرو تاکسی طراحی کنی. چطور شروع می‌کنی؟»این همون وایت‌برد چلنج (Whiteboard Challenge) ـه؛ یکی از محبوب‌ترین روش‌های شرکت‌ها برای ارزیابی طراح‌ها.توی این چالش، شما باید در مدت کوتاهی (معمولاً ۳۰ تا ۶۰ دقیقه) نشون بدی چطور یه مسئله رو می‌فهمی، تقسیم‌بندی می‌کنی و به یه راه‌حل اولیه می‌رسی.اما نکته مهم اینجاست:وایت‌برد چلنج قرار نیست طراحی نهایی یا پیکسل‌پرفکت ازت بخواد. هدف اصلیش اینه که ببینه چطور فکر می‌کنی و ایده‌هات رو منتقل می‌کنی.وایت‌برد چلنج دقیقاً چیه؟وایت‌برد چلنج در واقع یه تمرین طراحی سریعه. مصاحبه‌کننده یه مسئله بهت می‌ده (مثل ساده‌تر کردن فرآیند خرید بلیت یا طراحی اپ سفارش غذا) و تو باید روی وایت‌برد یا حتی کاغذ مراحل کار رو نشون بدی:اول مسئله رو شفاف کنی (با پرسیدن سؤال)بعد نیازهای کاربر رو تعریف کنییه وایرفریم یا فلو ساده بکشیو در نهایت منطق و دلیل انتخاب‌هات رو توضیح بدیاین تمرین با تسک‌های خانگی (Take-home Assignment) فرق داره؛ چون توی خونه فرصت داری تحقیق کنی و روی جزئیات کار کنی، ولی توی وایت‌برد چلنج همه‌چی زنده، سریع و جلوی چشم مصاحبه‌کننده اتفاق می‌افته.چرا شرکت‌ها از وایت‌برد چلنج استفاده می‌کنن؟بذار رک بگیم: مصاحبه‌کننده دنبال دیدن یه طراحی چشمگیر یا وایرفریم خوشگل نیست. چیزی که براش مهمه ایناست:نحوه فکر کردن 🧠آیا می‌تونی مسئله رو تحلیل کنی یا مستقیم می‌پری وسط طراحی؟تمرکز روی کاربر 👤راه‌حلت برای کاربر واقعاً قابل استفاده‌ست یا فقط برای خودت منطقیه؟مهارت حل مسئله 🔎چطور مسئله رو به بخش‌های کوچک‌تر تقسیم می‌کنی و مرحله‌به‌مرحله جلو می‌ری؟توانایی ارتباط و توضیح دادن 🗣️می‌تونی ایده‌هات رو واضح و قابل فهم توضیح بدی، جوری که تیم فنی یا مدیر محصول هم بفهمن؟به‌عبارت ساده: وایت‌برد چلنج بیشتر از اینکه یه تست طراحی باشه، یه تست طرز فکر و شیوه کار کردن توئه.مراحل انجام وایت‌برد چلنجبرای اینکه توی این چالش دستپاچه نشی، بهتره مراحلش رو به شکل یه چارچوب ساده توی ذهنت داشته باشی:Clarify → شفاف‌سازی مسئلهسؤال بپرس!چه کسی کاربره؟ چه شرایطی داره؟ چه محدودیت‌هایی هست؟هرچی سؤال دقیق‌تر، راه‌حل هوشمندانه‌تر.Define → تعریف نیازها و سناریویه پرسونای سریع بساز (مثلاً: «کاربر من یه مادر پرمشغله‌ست که وقت زیادی برای اپ نداره»).سناریوی اصلی کاربر رو مشخص کن.Ideate → ایده‌پردازی و ترسیم وایرفریمجریان اصلی کار (User Flow) رو روی وایت‌برد بکش.وارد جزئیات ریز UI نشو؛ تمرکز روی مسیر و تجربه کاربر باشه.Explain → توضیح دادندلیل انتخاب‌هاتو بگو: «این مسیر رو کوتاه‌تر کردم چون برای کاربر مهمه سریع برسه به هدفش.»حتی اگه طراحی‌ت کامل نیست، شفافیت در منطق خیلی امتیاز بزرگیه.اشتباهات رایج در وایت‌برد چلنج (و چطور ازشون دوری کنیم)اینکه توی وایت‌برد چلنج گیر بیفتی خیلی راحته. بیشتر طراح‌ها دقیقاً همین جاها خراب می‌کنن:بدون سؤال شروع کردن ❌مستقیم می‌رن سراغ کشیدن وایرفریم، بدون اینکه بفهمن کاربر کیه یا اصلاً مسئله دقیقاً چیه.👉 همیشه اول چند تا سؤال هوشمند بپرس. حتی اگه جواب کامل نگرفتی، نشون می‌ده داری درست فکر می‌کنی.غرق شدن توی جزئیات UI 🎨خیلی‌ها به جای تمرکز روی جریان کار، شروع می‌کنن دکمه‌ها و رنگ‌ها رو توضیح دادن.👉 یادت باشه، اینجا جای طراحی نهایی نیست. مسیر کاربر مهم‌تر از رنگ و استایل دکمه‌ست.نادیده گرفتن کاربر 👤بعضی‌ها فقط به راه‌حل فکر می‌کنن، نه به کاربر. مثلاً می‌گن: «خب اینو اینجا می‌ذارم که سریع‌تر بشه» ولی توضیح نمی‌دن چرا برای کاربر بهتره.👉 هر جا ایده می‌دی، دلیلش رو از نگاه کاربر بگو.بی‌نظمی و شلوغ‌کاری 🌀یه سری‌ها کل وایت‌برد رو پر می‌کنن با خطوط و باکس و فلش، طوری که خود مصاحبه‌کننده هم گیج می‌شه.👉 ساده و مرتب بکش، طوری که کسی اولین بار نگاه می‌کنه سریع بفهمه چی به چیه.ساکت بودن موقع طراحی 🤐خیلی‌ها موقع کشیدن چیزی نمی‌گن. آخرش که مصاحبه‌کننده می‌پرسه «چرا اینو اینطوری زدی؟» تازه شروع می‌کنن توضیح دادن.👉 از همون اول با صدای بلند فکر کن. توضیح دادن حین طراحی نشون می‌ده کنترل اوضاع دست توئه.چطور برای وایت‌برد چلنج آماده بشیم؟مثل هر امتحان دیگه، وایت‌برد چلنج هم با تمرین راحت‌تر می‌شه. چند تا نکته‌ی کلیدی:تمرین با مسئله‌های ساختگی 📝از دوستت بخواه یه مسئله طراحی ازت بپرسه (مثلاً «یه اپ برای مدیریت خرج‌های روزانه بساز») و تو ۳۰ دقیقه روی کاغذ یا وایت‌برد تمرین کن.با صدای بلند فکر کن 🗣️عادت کن موقع کشیدن، منطق پشت کارت رو توضیح بدی. این‌جوری توی مصاحبه هم راحت‌تر می‌شی.سریع پرسونا و فلو بساز 👤➡️📊لازم نیست خیلی وارد جزئیات شی. فقط یه کاربر فرضی ساده و مسیر اصلیش رو مشخص کن.مدیریت زمان ⏱️یادت باشه معمولاً کل چالش بین ۳۰ تا ۶۰ دقیقه‌ست. وقتت رو برای کشیدن جزئیات هدر نده. بهتره یه وایرفریم ساده داشته باشی + توضیح خوب.مرتب و ساده بکش 🔲از باکس‌ها و فلش‌های ساده استفاده کن. کسی دنبال زیبایی نیست، دنبال وضوحه.سناریوهای مشابه ببین 👀توی اینترنت نمونه‌های Whiteboard Challenge زیاده. مرور اون‌ها کمک می‌کنه دستت بیاد سؤال‌ها معمولاً چه شکلی‌ان.مثال‌های واقعی از وایت‌برد چلنجبرای اینکه دستت بیاد دقیقاً چه‌جوری سؤالات مطرح می‌شن، این چند نمونه رو ببین:«یه اپلیکیشن برای سفارش غذا طراحی کن که کاربر بتونه سریع غذای موردعلاقه‌ش رو پیدا کنه.»«فرآیند رزرو بلیت قطار رو ساده‌تر کن، طوری که کاربر سردرگم نشه.»«یه راه‌حل طراحی کن تا دانشجوها بتونن راحت‌تر هزینه‌های ماهانه‌شون رو مدیریت کنن.»«برای یه فروشگاه اینترنتی، صفحه‌ی پرداخت رو طوری طراحی کن که کمترین ریزش رو داشته باشه.»این سؤال‌ها ساده به‌نظر می‌رسن، اما نکته مهم اینجاست که جواب درست مطلقی وجود نداره. مصاحبه‌کننده بیشتر دنبال اینه ببینه چطور فکر می‌کنی، نه اینکه چه چیزی طراحی می‌کنی.جمع‌بندیوایت‌برد چلنج شاید در نگاه اول یه تمرین طراحی به‌نظر بیاد، اما در واقع آزمونی برای طرز فکر، توانایی حل مسئله و مهارت توضیح دادنه.یادت باشه:قرار نیست طراحی نهایی ارائه بدی.قرار نیست همه‌چیز کامل باشه.فقط باید نشون بدی چطور مسئله رو می‌شکنی، از نگاه کاربر نگاه می‌کنی و راه‌حل منطقی ارائه می‌دی.پس اگر جلوی وایت‌برد قرار گرفتی، نترس! مثل یه گفت‌وگو بهش نگاه کن. سؤال بپرس، ایده بده، و دلیل انتخاب‌هات رو توضیح بده. همین کافیه تا مصاحبه‌کننده بفهمه با یه طراح واقعی طرفه. فائزه ملکی | faezeuxi فائزه ملکی | faezeuxi Mon, 08 Sep 2025 01:02:56 +0330 https://virgool.io/@faezeuxi/%DA%86%D8%B1%D8%A7-%D9%BE%D9%88%D8%B1%D8%AA%D9%81%D9%88%D9%84%DB%8C%D9%88%DB%8C-%D8%B4%D9%85%D8%A7-%D8%AF%D8%B1-%DB%B2%DB%B0%DB%B2%DB%B5-%D8%AF%DB%8C%DA%AF%D9%87-%D8%A7%D8%B3%D8%AA%D8%AE%D8%AF%D8%A7%D9%85%D8%AA%D9%88%D9%86-%D9%86%D9%85%DB%8C-%DA%A9%D9%86%D9%87-%D9%88-%DA%86%D9%87-%DA%A9%D8%A7%D8%B1-%D8%A8%D8%A7%DB%8C%D8%AF-%D8%A8%DA%A9%D9%86%DB%8C%D8%AF-mhplqbf8wmkz اینا دغدغه خیلی هاست از جمله خودم:ساعت‌ها وقت گذاشتی یه کیس‌استادی طولانی نوشتی، وایرفریم و موکاپ پشت موکاپ.اما ریکروتر حتی کامل بازش نکرده.کلی پروژه توی فیگما داری، اما وقتی می‌خوای بذاری تو پرتفولیو، حس می‌کنی «همه شبیه هم شدن».می‌خوای کارت رو خاص نشون بدی، اما گیر کردی بین این همه «پورتفولیوی تکراری».و بدتر از همه: 🤯 هوش مصنوعی الان در چند ثانیه می‌تونه یه UI قشنگ تحویل بده.پس تو چه فرقی داری؟این دقیقاً همون چیزی‌ـه که خیلی از طراح‌ها ۲۰۲۵ دارن باهاش دست‌و‌پنجه نرم می‌کنن.اسمشو گذاشتن: بحران پورتفولیو.چرا مدل کیس‌استادی‌های فعلی دیگه جواب نمیدن؟بذار رک بگم:📌 فرمتِ «اول تحقیق کردم، بعد وایرفریم کشیدم، آخرش طراحی نهایی» دیگه کار نمی‌کنه.چرا؟ریکروتر کمتر از ۲ دقیقه وقت داره پورتفولیو ببینه.مشتری‌ها غرق در ده‌ها پورتفولیو مشابه‌ن.کیس‌استادی‌های طولانی شده‌ن مثل مقاله‌های مدرسه: خشک، بدون روح، بدون تمایز.و خب… نتیجه کارت معلوم نیست.چیزی که همه اشتباه می‌کننتصور کن یه ریکروتر میاد پورتفولیوتو باز می‌کنه:❌ می‌بینه پر از اسکرین‌شات بدون توضیحه.❌ یا یه عالمه متن کلیشه‌ای: «ما پرسونا ساختیم، تست کاربری کردیم…»❌ یا فقط یه UI قشنگ.نتیجه؟ → بعد از ۵ ثانیه می‌ره.کاری که باید بکنی اینه که:پورتفولیو رو از «مستندات» به «ماشین شفافیت» تبدیل کنی.نسل جدید پورتفولیو چه شکلیه؟بیایم با هم مرور کنیم:۱. ده ثانیه اول، همه‌چیزه🔑 تو همون چند ثانیه باید بفهمونیش:تو کی هستی؟چه مشکلی رو حل می‌کنی؟چه ارزشی میاری؟✅ مثال خوب:«به استارتاپ‌های فین‌تک کمک می‌کنم فرایندهای مالی پیچیده رو ساده کنن. (نتیجه: ↑۲۰٪ نرخ ثبت‌نام)»❌ مثال بد:«من عاشق طراحی هستم از وقتی بچه بودم…»۲. شروع با ارزش بیزنس، نه پرسونا📌 ریکروتر دنبال داستان پرسونا نیست. دنبال اینه ببینه کارت چه اثری گذاشته.✅ مثال خوب:«چالش: ۳۰٪ کاربران رزرو پزشک رو نیمه‌کاره رها می‌کردن.راه‌حل: ساده‌سازی جریان رزرو + progress bar.نتیجه: تکمیل رزرو ↑۲۰٪.»❌ مثال بد:«ما ۵ پرسونا ساختیم: علی ۲۲ ساله، سارا کارمند اداری…»۳. کیس‌استادی باید مثل توییت باشه، نه رمان📌 فرمت outcome-first:مشکل (۱ جمله)محدودیتتصمیم کلیدییک تصویرنتیجه✅ مثال:«مشکل: ۴۰٪ کاربرها فرم ثبت‌نام رو رها می‌کردن.محدودیت: بدون بودجه برای فیچر جدید.تصمیم: حذف فیلدهای اضافی + دکمه ثبت با گوگل.نتیجه: نرخ تکمیل ↑۳۵٪.»۴. برای سه مخاطب بنویس👔 ۱. ریکروتر (مدیر منابع انسانی)دغدغه: وقت نداره. فقط می‌خواد سریع بفهمه «این آدم به چه دردی می‌خوره؟»باید تو همون تیتر یا کارت پروژه قانعش کنی.✅ مثال خوب:کارت پروژه روی صفحه اصلی پورتفولیو:«کاهش زمان ثبت‌نام اپلیکیشن ۵۰٪ با یک تغییر ساده در فرم»❌ مثال بد:«طراحی مجدد صفحه ثبت‌نام» (خیلی کلی، معلوم نیست نتیجه چی بوده).💼 ۲. کارفرما یا مدیر محصول (کسی که می‌خواد تو رو استخدام کنه)دغدغه: تاثیر کارت روی بیزنس.باید براش توضیح بدی کارت چطور باعث رشد، صرفه‌جویی یا بهبود تجربه شده.✅ مثال خوب:«بعد از طراحی مجدد جریان رزرو، تماس‌های پشتیبانی ۳۰٪ کاهش پیدا کرد. این یعنی ماهیانه ۴۰۰ ساعت صرفه‌جویی برای تیم ساپورت.»❌ مثال بد:«ما یک progress bar اضافه کردیم.» (خوبه، ولی اثر بیزنسی رو نشون نمی‌ده).🎨 ۳. همکار طراح یا دیزاین‌لیددغدغه: کیفیت تفکر و عمق کاری که کردی.اینجاست که می‌تونی جزئیات یا مقاله جانبی بذاری تا نشون بدی چطور فکر می‌کنی.✅ مثال خوب:لینک جانبی در انتهای کیس‌استادی:«🔗 مقاله: چطور سیستم دیزاین X رو ساختم.»یا:«🔗 ویدیو ۲ دقیقه‌ای: پشت صحنه تست‌های کاربری این پروژه.»❌ مثال بد:فقط چند عکس از وایرفریم‌ها بدون هیچ توضیحی.📌 پس فرمول ساده‌ش اینه:برای ریکروتر → تیتر نتیجه‌محور (Outcome توی یک خط).برای کارفرما → توضیح اثر بیزنسی (صرفه‌جویی، رشد، عدد).برای طراح همکار → جزئیات و پشت‌صحنه (چطور فکر کردی، چه فریم‌ورکی داشتی).۵. صدای شخصی‌ات رو بیار✅ مثال:«۳ اصلی که همیشه تو طراحی دنبال می‌کنم:۱. وضوح۲. حذف اضافی‌ها۳. تمرکز روی اثر واقعی.»این چیزی‌ـه که تو رو متمایز می‌کنه، نه اینکه نوشتی «Figma بلدم».🎯 مثال کامل: اپ رزرو پزشکبیایم با یه کیس استادی واقعی، فرمت جدید رو ببینیم:مشکل: ۳۰٪ کاربران وسط رزرو سردرگم می‌شدن.محدودیت: فقط وقت داشتیم یه فیچر اضافه کنیم.تصمیم: progress bar مرحله‌ای طراحی شد + امکان تغییر نوبت بدون تماس.نتیجه: تماس پشتیبانی ↓۳۰٪، کنسلی ↓۲۰٪، رضایت کاربران ↑درس شخصی: «اول فکر می‌کردم چت آنلاین لازمه، ولی فهمیدم یه progress bar ساده کل مشکل رو حل می‌کنه.»📌 می‌بینی؟ این خیلی کوتاه‌تر و تاثیرگذارت‌تر از یه کیس‌استادی ۳۰ صفحه‌ایه.پلی‌بوک سریع برای پرتفولیوی آینده‌دار۱. صفحه اصلی = معرفی سریع + دستاورد اصلی۲. هر پروژه = مشکل --> محدودیت --> تصمیم --> تصویر --> نتیجه۳. نوشتن برای سه مخاطب (ریکروتر، کارفرما، طراح)۴. نتایج رو همیشه با عدد و داده نشون بده۵. صدای شخصی و فلسفه کارت رو بیار۶. پورتفولیو رو مثل یک محصول زنده، مرتب آپدیت کنجمع‌بندی🔮 در ۲۰۲۵ پورتفولیوها دیگه درباره‌ی «ظاهر قشنگ» نیستن.بلکه درباره‌ی اینن که:چطور فکر می‌کنیچه تصمیمی گرفتیو چه اثری گذاشتیپورتفولیوی خوب امروز باید اعتماد بسازه، شفاف باشه و outcome-first.این یعنی هم فرصت‌های بهتری می‌گیری، هم پورتفولیوت بین بقیه گم نمی‌شه.💡 حالا تو بگو:اگه همین فردا بخوای پرتفولیوتو تغییر بدی، اولین تغییری که میدی چیه؟دوست دارم نظر شما رو هم درباره تجربیاتتون توی این زمینه بدونم👇 توی کامنت بنویس، لایک کن اگه مفید بود و با دوستات به اشتراک بذار تا اونا هم پرتفولیوشون رو آپدیت کنن. فائزه ملکی | faezeuxi فائزه ملکی | faezeuxi Thu, 28 Aug 2025 21:58:53 +0330 https://virgool.io/@faezeuxi/%D9%85%D8%AF%D8%AA-%D8%B2%D9%85%D8%A7%D9%86-%D8%A7%D9%86%D8%AC%D8%A7%D9%85-%DA%A9%D8%A7%D8%B1-%D9%85%D8%B9%DB%8C%D8%A7%D8%B1%DB%8C-%DA%A9%D9%87-%D8%AA%D9%81%D8%A7%D9%88%D8%AA-%D8%A8%DB%8C%D9%86-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%AE%D9%88%D8%A8-%D9%88-%D8%B9%D8%A7%D9%84%DB%8C-%D8%B1%D9%88-%D9%86%D8%B4%D9%88%D9%86-%D9%85%DB%8C-%D8%AF%D9%87-pukno4xat6d7 Time on Task یعنی چی؟به‌طور ساده، Time on Task یعنی مدت زمانی که کاربر برای انجام یک وظیفه مشخص صرف می‌کنه. این زمان از اولین اقدام واقعی کاربر (مثل کلیک، جستجو یا لمس) شروع می‌شه و وقتی کار به پایان رسید، متوقف می‌شه.🔹 مثال ساده:فرض کنید می‌خواید به دوستتون پیامک بدید:وظیفه: ارسال پیامکشروع: وقتی وارد اپ پیام‌رسان می‌شیدپایان: وقتی پیام ارسال شدTime on Task: فاصله بین ورود به اپ و ارسال پیام🔹 مثال UX:وظیفه = «یک گوشی Samsung A54 پیدا کنید و به سبد خرید اضافه کنید.»زمان از لحظه اولین کلیک روی جستجو یا دسته‌بندی شروع می‌شه و وقتی محصول در سبد خرید ثبت شد، پایان می‌گیره.چرا Time on Task مهمه؟معیار کارایی (Efficiency)زمان کوتاه + موفقیت = مسیر روان و طراحی خوب.مثال ساده: وقتی می‌خواید شیرینی بخرید و سریع توی قفسه پیدا می‌کنید، مسیر ساده بوده.مثال UX: اگر کاربران بیشتر در ۲ دقیقه گوشی رو پیدا کنن، طراحی مسیر درست و ساده بوده.نشونه پیچیدگیزمان طولانی = مشکل یا گیجی در طراحیمثال ساده: دنبال یک لباس در فروشگاه می‌گردید اما هیچ تابلویی راهنمایی نمی‌کنه، ۱۰ دقیقه طول می‌کشه تا پیدا کنید.مثال UX: کاربر ۱۰ دقیقه طول کشیده چون فیلترها گیج‌کننده بوده.مقایسه طراحی‌هامی‌تونید دو نسخه از یک صفحه رو با هم بسنجید.مثال ساده: نسخه جدید قفسه‌ها مرتب‌تره و سریع‌تر پیدا می‌کنید.مثال UX: نسخه A = ۳ دقیقه، نسخه B = ۲ دقیقه → نسخه B بهتره.نیاز به ترکیب با متریک‌های دیگهزمان به تنهایی کافی نیست؛ با نرخ موفقیت و خطاها هم بررسی بشه.مثال: شاید کاربر در ۱ دقیقه مسیر رو رها کنه (زمان کوتاه)، ولی موفق نشده → داده قابل استفاده نیست.مراحل اندازه‌گیری Time on Taskتعریف وظیفه واضحبد: «محصول رو بررسی کن» → پایان مشخص نیستخوب: «گوشی A54 رو به سبد خرید اضافه کن» → پایان روشن و قابل اندازه‌گیریشروع تایمراولین اقدام کاربر، مثل کلیک روی جستجو یا لمس صفحهپایان تایمروقتی وظیفه کامل شد، مثل افزودن محصول به سبدثبت موفقیت یا شکستمثال: کاربر ۸ دقیقه تلاش کرد ولی محصول رو پیدا نکرد → شکستثبت یادداشت‌های کیفیمثال: «دو بار برگشت عقب»، «روی دکمه اشتباه کلیک کرد»نکات مهم در تحلیلفقط موفق‌ها رو تحلیل کنید → شکست‌ها زمان معنادار ندارنداز میانه (Median) استفاده کنید → یک کاربر خیلی کند میانگین رو خراب می‌کنهداده‌های پرت رو یادداشت کنید → کندی اینترنت، مشکل مرورگرشروع و پایان رو دقیق تعریف کنید → همه آزمایش‌کننده‌ها یکسان اندازه‌گیری کنندتحلیل و تصمیم‌گیریمیانه زمان موفق‌ها = پایه مقایسه طراحی‌هامثال ساده: اگر ۵ نفر موفق شدند پیامک رو در ۳۰، ۴۰، ۳۵، ۳۲ و ۳۸ ثانیه بفرستند، میانه = ۳۵ ثانیه → این زمان معیار اصلی ماست.بخش‌بندی داده‌ها = موبایل vs دسکتاپمثال UX: کاربران دسکتاپ گوشی رو در ۲ دقیقه پیدا کردند، کاربران موبایل ۳ دقیقه → می‌فهمیم نسخه موبایل نیاز به بهینه‌سازی دارد.روندها = قبل و بعد از تغییر طراحیمثال UX: نسخه قدیمی سایت ۴ دقیقه طول می‌کشید تا محصول پیدا شود، بعد از تغییر طراحی ۲ دقیقه → طراحی جدید مؤثر بوده.ترکیب با متریک‌های دیگر = زمان + موفقیت + خطامثال: کاربر در ۱ دقیقه مسیر رو رها کرد (زمان کوتاه)، اما موفق نشد → داده ارزش تحلیل ندارد، باید موفقیت هم بررسی شود.خطاهای رایجمحاسبه میانگین همه (حتی شکست‌ها)مثال: کاربری که ۱۰ دقیقه تلاش کرده ولی موفق نشده، میانگین را بالا می‌برد → نتیجه اشتباه می‌شود.پایان مبهم وظیفهمثال: «محصول رو بررسی کن» → کاربر نمی‌داند چه زمانی وظیفه تمام شده است.نادیده گرفتن داده‌های پرتمثال: اینترنت کاربر کند بوده یا مرورگر مشکل داشته → ثبت نکردن این موارد باعث تحلیل اشتباه می‌شود.اشتباه گرفتن Time on Task با «زمان حضور در صفحه»مثال: کاربر ۱۰ دقیقه صفحه محصول بوده ولی فقط ۳ دقیقه فعال کار کرده → زمان واقعی روی وظیفه کمتر است.جمع‌بندیTime on Task یک عدد ساده است، اما اگر درست اندازه‌گیری شود، شاخص قدرتمندی برای تصمیم‌گیری است.مثال ساده: وقتی پیامک را سریع می‌فرستید، مسیر روان است. وقتی دیر می‌کنید یا گیج می‌شوید، اصطکاک تجربه وجود دارد.مثال UX: هر ثانیه اضافه در پیدا کردن محصول نشان‌دهنده مشکل در مسیر طراحی است. با تعریف واضح وظایف، ثبت دقیق و تحلیل همراه با مثال‌ها، می‌توانیم تجربه کاربر را ساده‌تر و محصول را کارآمدتر کنیم.💬 شما تا حالا از Time on Task توی پروژه‌هاتون استفاده کردین؟به نظرتون چه تجربه‌ها یا چالش‌هایی داره؟خوشحال می‌شم توی کامنت‌ها نظرتون رو بنویسین.و اگه این مطلب براتون مفید بود، لایک کردنش باعث می‌شه افراد بیشتری بتونن ببیننش 🙌 فائزه ملکی | faezeuxi فائزه ملکی | faezeuxi Tue, 26 Aug 2025 16:31:02 +0330 https://virgool.io/@faezeuxi/%D9%87%D9%88%D8%B4-%D9%85%D8%B5%D9%86%D9%88%D8%B9%DB%8C-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%B1%D9%88-%D8%A7%D8%B2-%D8%A8%DB%8C%D9%86-%D9%86%D9%85%DB%8C-%D8%A8%D8%B1%D9%87%E2%80%94%D8%AE%D9%88%D8%AF%D9%85%D9%88%D9%86-%D8%AF%D8%A7%D8%B1%DB%8C%D9%85-%D8%A7%DB%8C%D9%86-%DA%A9%D8%A7%D8%B1-%D8%B1%D9%88-%D9%85%DB%8C-%DA%A9%D9%86%DB%8C%D9%85-sa3re4x6pd1i شغل‌مون واقعاً در امانِ؟تا همین چند وقت پیش، مطمئن بودم شغلم در امانه؛ باور داشتم هوش مصنوعی نمی‌تونه تهدیدش کنه. هنوزم تا حدی همین فکر رو دارم. اما وقتی دیدم چه سرعتی مردم دارن سراغ ابزارهای AI می‌رن، دیگه چندان مطمئن نیستم. آَره، حق دارن؛ این ابزارها سریعن، قابل‌اعتمادن و در نگاه اول جواب می‌دن. خودم هم دارم ازشون استفاده می‌کنم، ولی اینکه وسط خلاقیت بذاریمشون؟ مَغروره اصلاً قبول ندارم!هوش مصنوعی خلاق نیست؛ فقط تقلیدگره. بر اساس الگوهای گذشته عمل می‌کنه — خیلی‌ها ایده‌شون همینه که “خُب، سریع و قابل‌قبول باشه، دیگه!” و این صداهایی که در MIT درباره‌ی این موضوع حرف می‌زنن، دقیقاً بهم ماجرارو گوشزد می‌کنن.ما هم دل‌مون از طراحی واقعی خالی شده...واژه‌هایی مثل «همدلی» و «همکاری در خلق» رو دهه‌هاست داشتیم تکرار می‌کردیم. ولی وقتی کاره جدی می‌شه، و فشار بودجه یا زمان می‌رسه، این چیزها اولویت نیستن. خیلی از طراح‌ها — کلی شنیدم — حتی نمی‌تونن طراحی فراگیر رو به‌خوبی اجرا کنن.هوش مصنوعی دقیقا اینجا به کمک میاد: یه راه‌حل ارزون، سریع و ظاهراً قابل‌قبول. اما قَطعاً این یعنی استاندارد و تکراری شدن همه چیز. اگر طراحی‌مون واقعاً همدلانه نیست، AI که بخواد از همون‌ چیزها کپی کنه، نتیجه‌اش هم همینه.اصلاً چقدر «خلاقیت» توی طراحی‌مون داریم؟بذار رک باشم: بیشتر ماها داریم در چارچوب‌هایی کار می‌کنیم که قبلاً تعیین شدن — گایدلاین‌های دسترسی، سیستم‌های طراحی، کتابخانه‌های آماده فیگما. کاری که می‌کنیم فقط وصل کردن نقطه‌هاست. هوش مصنوعی هم دقیقاً همین رو می‌کنه.دو تا چیز مهمه:آیا کسی که با این ابزارها کار می‌کنه، بلدِ بتونه هوش مصنوعی رو کنترل کنه؟ جلوی سوگیری رو بگیره؟آیا وقتی وقت می‌خریم، اون وقت واقعاً صرف تفکر، تحقیق و ایده‌های جدید می‌شه؟ یا فقط سریع‌تر سر پروژه بعدی می‌ریم؟اگر جواب نه باشه، واقعاً داریم خلاقیت‌مون رو در ازای یه توهم «پیشرفت» هزینه می‌کنیم.هوش مصنوعی فقط تقلید می‌کنه... و بازتولید سوگیری هم کارشه.این ابزارها خلاق نیستن. فقط چیزی رو می‌سازن که قبلا توی اینترنت یا منابع دیگر بوده؛ فقط کپی بهتر. اما این یعنی ما داریم همان سوگیری‌ها رو دوباره و دوباره تولید می‌کنیم.مثلاً اون تحقیق Gender Shades نشون داد AI تا ۳۵٪ افراد با پوست تیره رو اشتباه شناسایی کرده — چون داده‌های آموزشی خودش مشکل‌دار بودن. این دقیقا یعنی AI از همون سقف‌ها و اشتباهات یاد می‌گیره، نه چیز بهتر.مولی رایت استنسون می‌گه:«داده‌ها متعلق به گذشته‌اند. مشکل اینه که باعث تکرار سوگیری‌های گذشته می‌شن، نه کشف راه‌حل‌های جدید.»پس ما داریم ابزارای آینده رو روی بستر پیش‌فرضی می‌سازیم که خودش مشکل‌داره!لزوماً باید همیشه خلاقانه باشیم؟ نه. ولی با فکر باشیم.نمی‌گم هر فرم لاگین یا پروسه‌ای باید انقلابی باشه. نه. بعضی از بهترین تجربه‌ها اصلاً به چشم نمی‌آن. اما ما (یا حداقل باید) این نقاط رو با دقت و آگاهی وصل کنیم، نه مثل ماشین فقط چسبوندن طرح‌های تکراری.اگر همه چیز رو صرفاً به AI بسپریم، اصلاً جای ما چیه؟ چه چیزی از ما در این فرایند می‌مونه؟ چطور می‌تونیم پیشرفت کنیم توی طراحی وقتی همه‌چی رو سپردیم به ابزار؟یاد اون دوره‌های پرهیجان خلاقیتدهه‌ی ۹۰ تا اوایل ۲۰۰۰ جایی بود که تازه UX و طراحی جان گرفته بود. هرکس یه ایده دیوونه‌وار داشت — گوشی‌های عجیب، کنترلرهای متفاوت و تجربه‌هایی که احتمالاً ۸۰٪ شون شکست خوردن؛ ولی با عشق و جسارت تجربه شدن.خیلی زود سیستم‌ها تبدیل شدن به اپل، اندروید و استانداردهای مینیمال؛ و عجیب بودن منسوخ شد. UX اما اومد نظم بده و جا باز کرد. مفید بود، ولی یه چیز گم شد: بُعد خلاق و «چی میشه اگه؟» که از یاد رفت و آدم‌ها عادت کردن به «چی آینده‌اِش؟»حالا AI هم داره از همین چارچوب‌ها تقلید می‌کنه؛ به چشمِ فرهنگ استفاده ما از گذشته. آیا مشکل اون تکنولوژیِ تکراریه؟ یا مشکل خودمونه که سال‌ها قبل از AI مسیرمونو انتخاب کردیم؟مشکل، AI نیست؛ ما هستیم.من خودم تجربه‌های خوبی با ابزارهای هوش مصنوعی داشتم؛ ولی همیشه نظرم رو می‌گم، اعتبار و سوگیری‌ش رو چک می‌کنم. دلیلش اینه که اعتقاد دارم «هدف، تقویت انسانه، نه جایگزینی ما» (همون جمله شنیدرمن). ما باید بدونیم AI چیکار می‌کنه، چی می‌تونه و چه زمانی نباید ازش استفاده کرد. این سواد نباید فقط برای کسایی باشه که با UX یا کدنویسی سروکار دارن؛ باید همه تیم — شامل مارکتینگ، QA، UX و... — بدانند و مسئولیت‌پذیر باشند.داشتن چارچوب و مستندسازی: کی از چه ابزاری استفاده می‌کنه؟ در چه مرحله‌ای؟ کِی بهتره رسماً با فکر انسانی ادامه بدیم؟ این‌ها نباید دستور بالا به پایین باشه؛ باید مشارکتی ساخته بشه.وقت ذخیره شده رو کجا صرف کنیم؟AI می‌تونه کارهای تکراری رو انجام بده — خوبه! ولی مهم اینه که با اون وقت ذخیره‌شده چی کار کنیم: فقط پروژه‌های بیشتر تحویل بدیم؟ یا به تحقیق، تفکر واگرا و طراحی جسورانه برسیم؟اون‌جاست که نوآوری زنده می‌مونه. بدونش، فقط توی یه چرخه‌ی بی‌روح گرفتار می‌مونیم.جمع‌بندیAI خودش هیچ مشکلی نیست. اون فقط نشون‌دهنده‌ی شرایطی هست که ما قبلاً ساختیم. درواقع، مشکل جایی غیر اونجاست.طراحی امروزی ما مدت‌هاست در مسیر استاندارد و بدون ریسک افتاده؛ حالا فقط اسمش شده AI. اگر نمی‌خوایم فقط تماشاگر باشیم، باید با هم روی آموزش، اخلاق حرفه‌ای، و تحقیق و توسعه‌ کار کنیم؛ نه فقط ابزار و اتوماسیون.چون ارزش واقعی طراحی در سرعت نیست — در تفکر انسانی، همدلی و تجربه‌محوریه. چیزایی که هیچ ماشینی نمی‌تونه جایگزین‌شون بشهمقاله از Kym Primroseزبان اصلی : https://uxdesign.cc/ai-wont-kill-ux-we-will-6ab68db1f1e3 فائزه ملکی | faezeuxi فائزه ملکی | faezeuxi Thu, 07 Aug 2025 14:40:10 +0330 https://virgool.io/@faezeuxi/%D8%AA%DB%8C%D9%85-%D8%B4%D9%85%D8%A7-%D9%88%D8%A7%D9%82%D8%B9%D8%A7%D9%8B-%DB%8C%DA%A9-%D8%AA%DB%8C%D9%85%D9%87-%DB%8C%D8%A7-%D9%81%D9%82%D8%B7-%DA%86%D9%86%D8%AF-%D9%86%D9%81%D8%B1-%D8%B1%D9%88%DB%8C-%DB%8C%DA%A9-%D9%BE%D8%B1%D9%88%DA%98%D9%87-ezugj3dlfgb9 تا حالا تو تیمی کار کردی که همه فقط دنبال انجام دادن تسک خودشون بودن؟ نه خبری از همکاری واقعی بود، نه حسی از یک هدف مشترک؟این مقاله درباره‌ی همین مشکله: اینکه خیلی از تیم‌هایی که اسمشون تیمه، در واقع فقط یه سری آدم‌ان که کنار هم کار می‌کنن. توی این مقاله می‌خوایم بفهمیم چی باعث می‌شه یه گروه، واقعاً تبدیل به یک «تیم» بشه — تیمی که برای یک هدف مشخص تلاش می‌کنه، به هم اعتماد داره و نتیجه‌ی کارش از جمعِ توانایی‌های فردی فراتر می‌ره.🎯 یک مثال واقعی (A Real-Life Example)چند وقت پیش با تیمی در یک استارتاپ همکاری داشتم که قراره بود نسخه‌ی جدیدی از اپلیکیشنشون رو طراحی کنیم. هرکس مشغول کار خودش بود: طراح طراحی می‌کرد، دولوپر فقط به تسک خودش فکر می‌کرد، و مدیر پروژه صرفاً دنبال اینکه کارها به‌موقع تحویل داده بشه. هیچ‌کس دقیق نمی‌دونست بقیه چرا این تصمیم‌ها رو گرفتن یا هدف اصلی دقیقاً چیه. همه چیز تبدیل شده بود به یک سری کار بی‌روح که باید تیک می‌خورد.وقتی هم به مشکلات برخوردیم، به‌جای همکاری، انگشت اتهام به‌سمت همدیگه نشونه رفت. چون از اول هیچ هدف مشترک واقعی‌ای شکل نگرفته بود و اعتماد لازم بین اعضا نبود.🧩 تیم واقعی چطوری شکل می‌گیره؟یه تیم واقعی، اول از همه، یه هدف مشترک واضح داره. چیزی فراتر از "تموم کردن پروژه". هدفی که همه بتونن باهاش ارتباط برقرار کنن و بهش باور داشته باشن.دوم اینکه، اعضای تیم به هم اعتماد دارن و می‌تونن آزادانه ایده‌ها، نگرانی‌ها و بازخوردهاشون رو بیان کنن.و مهم‌تر از همه: اعضای تیم نتیجه‌ی نهایی رو مال خودشون می‌دونن، نه فقط بخشی که خودشون روش کار کردن.🛠️ چطور تیمم رو متعهد به هدف مشترک کنم؟(بر اساس روش Align on Your Impact Goals از IDEO)وقتی اعضای تیم تصویر روشنی از مقصد نداشته باشن، حرکتشون کند و پراکنده‌ست. اما وقتی همه به یک هدف واقعی و مشخص متعهد می‌شن، حتی با منابع محدود هم می‌تونن نتایج بزرگ خلق کنن.برای اینکه تیممون واقعاً متعهد بشه، فقط گفتن یه جمله انگیزشی یا نوشتن یه ویژن روی دیوار کافی نیست. باید همه با هم به درک مشترکی برسیم — اینکه دقیقاً چی برامون مهمه، دنبال چه تغییری هستیم، و چطوری می‌فهمیم به اون تغییر رسیدیم؟برای این کار، می‌تونیم از تکنیک Align on Your Impact Goals استفاده کنیم؛ یک روش ساده، مشارکتی، و عمیق که به کمک اون می‌تونیم اهداف تأثیرگذار تیممون رو اولویت‌بندی و شفاف کنیم.📌 مثال واقعی: طراحی اپلیکیشنی برای سالمندانفرض کنید شما طراح یک اپلیکیشن جدید برای سالمندان هستید. تیم شامل افراد مختلفی از جمله طراح، توسعه‌دهنده، مدیر محصول و نماینده‌ای از سازمان بازنشستگیه. هر کسی یه دیدگاه خاص درباره اینکه "موفقیت پروژه" یعنی چی داره:طراح فکر می‌کنه موفقیته وقتی‌یه که اپلیکیشن ساده و خوانا باشه.توسعه‌دهنده موفقیت رو در عدم وجود باگ و عملکرد روان می‌دونه.مدیر محصول می‌خواد نرخ استفاده از اپ بالا باشه.نماینده سازمان هدفش کاهش تماس‌های تلفنی از سمت سالمندانه.اگه بدون شفاف‌سازی پیش بریم، این اختلاف دیدگاه‌ها تو تصمیم‌گیری‌ها، اولویت‌ها و حتی تست‌های نهایی خودش رو نشون می‌ده و در نهایت باعث نارضایتی یا ناکامی می‌شه.🚀 حالا چطور این تفاوت‌ها رو تبدیل به تعهد می‌کنیم؟۱. جمع‌آوری اهداف مختلف از زبان اعضااز همه اعضای تیم بخواین به این سؤال جواب بدن:«اگه پروژه موفق باشه، چه تغییری در دنیای بیرون اتفاق افتاده؟»پاسخ‌ها رو روی یادداشت‌ چسب‌دار یا ابزار دیجیتال بنویسید.مثلاً:«سالمندان خودشون می‌تونن نوبت دکتر بگیرن»«پشتیبانی تلفنی کاهش پیدا می‌کنه»«افراد مسن با خیال راحت از اپ استفاده می‌کنن»«بیشتر از ۶۰٪ سالمندان ماهی یک بار از اپ استفاده می‌کنن»۲. مرتب‌سازی اهداف در یک نردبان تأثیراکنون وقتشه اهداف جمع‌آوری‌شده رو در یک نردبان از پایین‌ترین تا بالاترین سطح تأثیر بچینید.نمونه نردبان برای مثال بالا:🎯 سطح هدف : بالاترین تأثیر --> سالمندان احساس استقلال بیشتری می‌کنن.🔽 سطح میانی : سالمندان خودشون نوبت می‌گیرن بدون تماس با پشتیبانی.🔽 سطح پایین‌تر : اپ بدون نیاز به آموزش خاص قابل استفاده‌ست.🔽 سطح آخر : ورودی‌ها --> فونت خوانا انتخاب شده، طراحی ساده‌ست، راهنمای گام‌به‌گام دارهمرتب‌سازی به تیم کمک می‌کنه متوجه بشه که خروجی‌های ظاهری (مثل طراحی ساده) فقط «وسیله»‌ای برای رسیدن به هدف واقعی هستن.۳. انتخاب و اولویت‌بندی اهداف نهاییبعد از دسته‌بندی، با رأی‌گیری یا اجماع تصمیم بگیرید که کدوم اهداف برای تیم در این پروژه خاص، واقعاً مهم و قابل اندازه‌گیری هستن.مثلاً تیم به این نتیجه می‌رسه:«حداقل ۷۰٪ از کاربران بالای ۶۰ سال بتونن بدون کمک نوبت بگیرن»«تماس‌های پشتیبانی تا ۴۰٪ کاهش پیدا کنه»این‌ها تبدیل می‌شن به اهداف مشترک قابل پیگیری تیم.🧩 نتیجه این فرآیند چیه؟تعهد تیم بیشتر می‌شه چون تو انتخاب اهداف مشارکت داشته.تصمیم‌گیری‌ها سریع‌تر می‌شن چون تیم می‌دونه کدوم تغییرها ارزش دارن.رضایت نهایی از پروژه بالا می‌ره چون همه بدون گیج شدن روی یه چشم‌انداز کار کردن.میتونید برگه راهنمای این روش رو از اینجا دانلود کنید و توی تیم تون ازش استفاده کنید.🔄 حالا نوبت شماست!👈 پروژه‌ی بعدی‌تون رو بدون توافق تیمی درباره هدف شروع نکنید. یک جلسه ساده برگزار کنید، اهداف رو شفاف کنید، نردبون بسازید و اجازه بدید تیم واقعاً متحد بشه، نه فقط همکار. فائزه ملکی | faezeuxi فائزه ملکی | faezeuxi Mon, 04 Aug 2025 02:24:15 +0330 https://virgool.io/@faezeuxi/%F0%9F%93%8C-%DA%86%D8%B7%D9%88%D8%B1-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%86%D9%82%D8%B4%D9%87-%D9%87%D9%85%D8%AF%D9%84%DB%8C-%D8%AF%D8%A7%D8%AF%D9%87-%D8%AC%D9%85%D8%B9-%DA%A9%D9%86%DB%8C%D9%85-%D8%B1%D8%A7%D9%87%D9%86%D9%85%D8%A7%DB%8C-%D8%B9%D9%85%D9%84%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AF%DB%8C%D8%B2%D8%A7%DB%8C%D9%86%D8%B1%D9%87%D8%A7-ugddb5a9flrb در پست قبلی توضیح دادم که نقشه همدلی (Empathy Map) یکی از ابزارهای ساده اما مؤثر برای درک عمیق کاربران در مراحل ابتدایی طراحی تجربه کاربریه.و در پست دوم، به این پرداختیم که بعد از ساخت نقشه همدلی، باید چه کارهایی انجام بدیم.اما سؤال مهمی که باقی می‌مونه اینه:اطلاعات این نقشه رو از کجا بیاریم؟جواب کوتاه:نه از حدس تیم! بلکه از داده‌های واقعی کاربران.در این پست، ۷ روش کاربردی برای جمع‌آوری این داده‌ها رو می‌نویسم؛ چیزی که کمک می‌کنه نقشه‌ات واقعی، مفید و قابل اعتماد باشه.۱. 🎙 مصاحبه با کاربران (User Interviews)گفت‌وگوی نیمه‌ساختاریافته با کاربران واقعیکمک می‌کنه بفهمی کاربر دقیقاً چی می‌گه، فکر می‌کنه، احساس می‌کنه، و انجام می‌دهبهترین روش برای جمع‌آوری داده‌های کیفی🛠 ابزار: Zoom، Google Meet، یا حضوری🕒 زمان: ۲۰ تا ۴۵ دقیقه۲. 👀 مشاهده مستقیم (Field Observation / Shadowing)دیدن کاربر در حال استفاده از محصول یا انجام فعالیت واقعیمخصوصاً برای فهمیدن رفتارهای ناخودآگاه یا مسائل محیطی خیلی مؤثره💡 گاهی کاربر نمی‌تونه دقیق بگه مشکلش چیه، اما از نگاه کردن به رفتارش می‌تونی بفهمی.۳. 🧪 تست کاربرد پذیری (Usability Testing)از کاربر بخواه با محصول کار کنه و در حین انجام، تجربه‌اش رو توضیح بدهبرای کشف گره‌های ذهنی و حرکتی عالیهمعمولاً برای بخش‌های Doing و Thinking مفیده۴. 💬 تحلیل داده‌های پشتیبانی / چت / تماس کاربرانمرور مکالمات تیم پشتیبانی با کاربرانبررسی سوال‌ها، اعتراض‌ها یا مشکلات رایجداده‌های خوبی برای بخش‌های Saying و Feeling۵. 📋 نظرسنجی و فرم‌های بازخوردبررسی فرم‌های آنلاین، مثل Google Form، فرم‌های رضایت یا NPSاگر سوالات باز (Open-ended) داشته باشه، گنج اطلاعاتی برای نقشه همدلیه۶. 📊 داده‌های رفتاری (Behavioral Data)استفاده از ابزارهایی مثل Hotjar، Google Analytics یا FullStoryمی‌فهمی کاربران واقعاً کجا کلیک می‌کنن، کجا رها می‌کنن، کجا گیر می‌کنن📌 داده‌های دقیق و کمی برای بخش Doing۷. 🗂 رجوع به تحقیقات قبلی یا پرسونای موجوداگه تیم تحقیقاتی قبلاً پرسونا یا Journey Map تهیه کرده باشهبررسی کن که اطلاعاتش هنوز معتبر و مرتبط هست یا نهدر صورت تایید، می‌تونه منبع خوبی باشه✅ نتیجه‌گیریساختن نقشه همدلی، فقط یک تمرین بصری نیست؛ یه فرآینده که باید با داده‌های واقعی تغذیه بشه.و این داده‌ها رو هم می‌شه با ترکیب این ۷ روش جمع کرد — بسته به نوع پروژه و منابع در دسترس.اگه خواستی، می‌تونم کمکت کنم تا برای پروژه‌ات یک چک‌لیست اختصاصی جمع‌آوری دیتا برای نقشه همدلی درست کنیم.👈 کافیه توی کامنت بهم بگی! فائزه ملکی | faezeuxi فائزه ملکی | faezeuxi Sat, 02 Aug 2025 23:42:56 +0330 https://virgool.io/@faezeuxi/%D8%A8%D8%B9%D8%AF-%D8%A7%D8%B2-%D9%86%D9%82%D8%B4%D9%87-%D9%87%D9%85%D8%AF%D9%84%DB%8C-%D9%86%D9%88%D8%A8%D8%AA-%DA%86%DB%8C%D9%87-paysc4qzdenz در مقاله قبلی درباره ابزار ساده‌ای به نام نقشه همدلی (Empathy Map) نوشتم؛ ابزاری که کمک می‌کنه ذهن، احساسات و نیازهای واقعی کاربر رو بهتر درک کنیم.اما حالا فرض کنیم نقشه همدلی رو ساختیم. نیازها و نقطه‌دردهای کاربر رو درآوردیم.سؤال مهم اینه:حالا باید چی کار کنیم؟🎯 سناریو واقعی: رزرو نوبت چشم‌پزشکیتوی یکی از پروژه‌هایی که روش کار کردم (رزرو نوبت برای کلینیک دکتر مکارمی)، از طریق همدلی با کاربران متوجه شدیم:"کاربر نمی‌دونه کی نوبت آزاد می‌شه، منشی هم دیر جواب می‌ده. فرآیند گرفتن وقت خیلی طولانیه."این‌جور شناخت‌ها پایه‌ طراحی واقعی‌ان. اما قدم بعدی چیه؟مراحل بعد از ساخت نقشه همدلی:۱. تعریف دقیق مسئلهبا شناخت دقیق‌تر از کاربر، حالا می‌تونیم مسئله‌ رو دوباره تعریف کنیم:❌ قبلاً: سیستم رزرو پیچیده‌ست✅ حالا: کاربر نمی‌تونه به‌موقع نوبت بگیره چون اطلاعات در لحظه در دسترس نیست و ارتباط با منشی کند و زمان‌بره.۲. اولویت‌بندی نیازهاهمه نیازها رو نمی‌تونیم همزمان حل کنیم. باید ببینیم:کدوم نیاز تکرار بیشتری داشته؟کدوم درد روی اعتماد کاربر تأثیر بیشتری گذاشته؟کدومش در بازه فعلی قابل حل کردنه؟در این پروژه، عدم دسترسی به نوبت‌های آزاد و کندی ارتباط با منشی، در اولویت قرار گرفت.۳. ایده‌پردازی هدف‌دارحالا می‌دونیم قراره چی رو حل کنیم، پس ایده‌هامون باید دقیق‌تر باشن.مثلاً با تکنیک «چطور می‌تونیم...؟» (How Might We):چطور می‌تونیم به کاربر اطلاع بدیم نوبت جدید باز شده؟چطور می‌تونیم رزرو یا جابه‌جایی نوبت رو بدون تماس با منشی ممکن کنیم؟بر اساس این سؤالات، ایده‌هایی شکل گرفت مثل:اعلان (Notification) زمان خالیسیستم رزرو جایگزینچت آنلاین با منشی۴. طراحی راه‌حلحالا که راه‌حل‌ها مشخص شدن، طراحی باید بر اساس همین نیازها انجام بشه.📱 در طراحی UI این پروژه، ویژگی‌های جدیدی اضافه کردم مثل:دکمه «درخواست نوبت سریع»بخش "نوبت‌های آزاد جدید"چت پشتیبانی در صفحه اصلی۵. تست و اصلاحدر آخر، نسخه اولیه طراحی‌شده رو با چند کاربر واقعی تست کردیم:آیا می‌تونن راحت نوبت آزاد رو پیدا کنن؟از چت استفاده می‌کنن؟حسشون نسبت به فرآیند رزرو تغییر کرده؟بازخوردها باعث شد قبل از توسعه نهایی، بعضی چیزها رو دوباره طراحی کنیم.جمع‌بندینقشه همدلی، شروع همدلیه، نه پایانش.بعد از شناخت نیازهای واقعی، باید:مسئله رو دوباره تعریف کنیمنیازها رو اولویت‌بندی کنیمایده‌پردازی هدف‌دار انجام بدیمطراحی رو بر اساس اون پیش ببریمتست کنیم و اصلاح کنیماین چرخه باعث می‌شه طراحی‌هامون از حد "زیبا بودن" فراتر برن، و واقعاً به درد کاربر بخورن.📖 اگه پست قبلی درباره نقشه همدلی رو نخوندی، اینجاست:🔗 چرا بعضی از طراحی‌های ما شکست می‌خورند؟ (نقشه همدلی)💬 تجربه مشابهی داشتی؟ توی کامنت‌ها بنویس :) فائزه ملکی | faezeuxi فائزه ملکی | faezeuxi Sat, 02 Aug 2025 02:05:05 +0330 https://virgool.io/@faezeuxi/%DA%86%D8%B1%D8%A7-%D8%A8%D8%B9%D8%B6%DB%8C-%D8%A7%D8%B2-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D9%87%D8%A7%DB%8C-%D9%85%D8%A7-%D8%B4%DA%A9%D8%B3%D8%AA-%D9%85%DB%8C-%D8%AE%D9%88%D8%B1%D9%86%D8%AF-cxt3upzgshgv نقشه همدلی؛ ابزاری برای ورود به دنیای واقعی کاربرآیا تا به حال محصول یا سرویسی طراحی کرده‌اید که از نظر خودتان بی‌نقص بوده، اما کاربران هیچ علاقه‌ای به آن نشان نداده‌اند؟ما طراحان و مدیران محصول بارها با این چالش مواجه شده‌ایم.اغلب اوقات، دلیل شکست این است که داریم برای خودمان طراحی می‌کنیم، نه برای کسی که قرار است از آن استفاده کند.ما تصور می‌کنیم می‌دانیم کاربران چه می‌خواهند، چه احساسی دارند و چگونه رفتار می‌کنند—در حالی که این‌ها فقط فرضیات هستند، نه واقعیت.اینجاست که نقشه همدلی (Empathy Map) وارد بازی می‌شود.🧠 نقشه همدلی چیست و چرا اهمیت دارد؟نقشه همدلی یک ابزار بصری ساده اما قدرتمند است که کمک می‌کند از دنیای فرضیات خارج شویم و واقعاً وارد ذهن و دنیای کاربران شویم.به‌جای تمرکز روی ویژگی‌های محصول، این ابزار ما را وادار می‌کند ببینیم کاربر:چه می‌گوید (Says)چه فکر می‌کند (Thinks)چه کاری انجام می‌دهد (Does)چه احساسی دارد (Feels)نمونه از نقشه همدلیچرا باید از نقشه همدلی استفاده کنیم؟✅ دور شدن از حدس و گمانبر اساس داده‌های واقعی مثل مصاحبه‌ها و مشاهدات ساخته می‌شود، نه برداشت‌های ذهنی ما.✅ ایجاد درک مشترک در تیمهمه اعضای تیم، تصویری یکسان و عمیق از کاربر دارند و تصمیم‌گیری‌ها هدفمندتر می‌شود.✅ تمرکز بر انسان، نه محصولبه‌جای تمرکز بر فیچرهای بیشتر، روی حل مشکلات واقعی کاربران متمرکز می‌شوید.چطور یک نقشه همدلی بسازیم؟ (مثال فرضی)فرض کنید قرار است اپلیکیشنی برای کمک به دانشجویان در مدیریت زمان طراحی کنید.بعد از مصاحبه با چند دانشجو، اطلاعات را در قالب ۴ بخش اصلی وارد نقشه می‌کنید:۱. می‌گوید (Says)نقل‌قول‌های مستقیم از کاربر:«همیشه برنامه می‌ریزم اما بهش عمل نمی‌کنم.»«واقعاً از استرس شب امتحان خسته شدم.»۲. فکر می‌کند (Thinks)لایه‌های درونی‌تر ذهن کاربر که به زبان نمی‌آورد:«شاید من به اندازه کافی باهوش نیستم.»«این کارها از من برنمیاد.»۳. انجام می‌دهد (Does)رفتارهای واقعی کاربر در زندگی روزمره:«برنامه‌ریزی می‌کنه ولی زود رهاش می‌کنه.»«شب امتحان بیداره و قهوه می‌نوشه.»۴. احساس می‌کند (Feels)احساساتی که در مصاحبه‌ها دیده یا حس می‌شوند:«احساس گناه، اضطراب، ناامیدی و فشار.»📌 تمپلیت آماده برای نقشه همدلی در Figmaبرای ساخت نقشه همدلی به راحتی می‌تونید از این فایل آماده استفاده کنید:👉 مشاهده و کپی تمپلیت در Figmaبعد از ساخت نقشه چه کنیم؟در مثال دانشجو، می‌فهمیم که مشکل اصلی فقط "مدیریت زمان" نیست، بلکه احساس ناتوانی و استرس پشت آن است.در نتیجه، ایده‌هایی که مطرح می‌کنیم واقع‌گرایانه‌تر و همدلانه‌تر خواهند بود:💡 «چطور می‌تونیم حس گناه رو به حس پیشرفت تبدیل کنیم؟»💡 «چطور برنامه‌ریزی رو به کاری ساده و لذت‌بخش تبدیل کنیم؟»❓ آیا همیشه باید از نقشه همدلی استفاده کنیم؟پاسخ کوتاه: نه همیشه.✅ مثال کاربردی:فرض کنید در حال طراحی یک اپلیکیشن مدیریت مالی برای نوجوانان هستید.در این سن، نگرانی‌هایی مثل «نکنه اشتباه کنم» یا «من هیچی از پول نمی‌فهمم» در ذهن‌شان هست، اما ممکنه نگن.نقشه همدلی کمک می‌کنه این ترس‌های پنهان رو بشناسید و راه‌حل‌هایی طراحی کنید که حس امنیت بده.❌ مثال ساده:حالا فرض کنید قراره فقط رنگ دکمه "ثبت سفارش" در صفحه پرداخت رو از خاکستری به سبز تغییر بدید.این یک بهبود کوچک در UI هست و نیازی به شناخت عمیق احساسات کاربر نیست.در این شرایط، تست A/B یا مشاهدات رفتاری کافی هستند.💬 شما چی فکر می‌کنید؟تا حالا از نقشه همدلی استفاده کردید؟ یا پروژه‌ای داشتید که حس کردید بهش نیاز دارید؟تجربه‌هاتون رو حتماً در بخش نظرات برام بنویسید. خوشحال می‌شم بخونم 🌱 فائزه ملکی | faezeuxi فائزه ملکی | faezeuxi Fri, 01 Aug 2025 17:00:00 +0330