مقدمه
ارائه بهترین تجربه به کاربران یک کار چالش برانگیز برای متخصصان UX است. نه به این دلیل که این یک علم موشکی است، بلکه دفاع از تصمیمات ما با سهامداران برای تأیید آنها، آن را چالش برانگیز می کند.
من معتقدم که این کاملا طبیعی است. اما در مورد ما، زمانی پیچیده می شود که آن ذینفعان واقعاً کار ما را درک نکنند.
مثلا:
سوال. آیا PM (مدیر محصول) شما اولویت های خود را با نادیده گرفتن نیازهای کاربر تغییر می دهد؟
سوال. آیا PM شما می خواهد ویژگی های جدیدی را در اسرع وقت در راس یک MVP بد توسعه بیاورد؟
سوال. آیا PM شما دامنه را کاهش می دهد و باعث اختلال در UX کلی در جریان کاربر می شود؟
اگر پاسخ بله است! و با این حال، شما در UX محصول خود به خطر نیفتید… شما قبلاً مهارت را شکسته اید. اما اگر پاسخ شما بله است و در مواجهه با PM خود مشکل دارید، پس این برای شماست، دوست من! ما در این با هم هستیمپ
این مقاله چگونه کمک خواهد کرد؟
در این قسمت اول از سری مهارت‌های ناشناخته به عنوان طراح محصول، تجربیات واقعی خود را از ایجاد یک رابطه عالی با محصولات شما، به‌ویژه PM و تیم‌های مرتبط به اشتراک خواهم گذاشت.
من همچنین یک فرمول ۳ مرحله‌ای ساده را به اشتراک می‌گذارم تا مطمئن شوم که PM شما معنی واقعی صحبت کردن را درک می‌کند
بیایید شروع کنیم – درک مشکل
بیایید با کمی قدردانی از محصولات محبوبمان شروع کنیم (زیرا در نیمه دوم مطمئن هستم که آنها من را رد خواهند کرد)
افرادی که محصول تولید می کنند، هجوم کنندگان واقعی هستند. آنها مطمئن می شوند که همه تیم های دیگر مانند فناوری، طراحی، تجزیه و تحلیل و غیره در یک صفحه هستند.
مسئولیت‌های کلیدی آنها شامل نوشتن PRD، مدیریت اولویت‌های برنامه‌نویس با تیم فناوری و درک روندهای کلی بازار و تصمیم‌گیری است. در حالی که ۲ مورد اول خوب است، آخرین مورد ۲ نگرانی معمولی را برای طراحان ایجاد می کند:
۱-راه اندازی محصولات (یا ویژگی ها) و راه اندازی سریع آنها ⏳
این منجر به قطع بی‌رحمانه دامنه محصول می‌شود که بر جریان کلی کاربر تأثیر می‌گذارد.
۲-قربانی کردن کاربر برای معیارها 😈
غرق شدن در افزایش سریع متریک به دلیل یک تغییر جزئی بدون درک مدل ذهنی کاربر و در نتیجه منجر به کاهش ناگهانی در همان متریک پس از ۲ هفته می شود.
(بر اساس تجربه شخصی من)
حتی با موقعیتی مواجه خواهید شد که یکی از این دو نگرانی برای توجیه دیگری استفاده شود، مانند
“متریکی که ما حل می کنیم اولویت نیست، بنابراین می توانیم دامنه را محدود کنیم و در زمان خود صرفه جویی کنیم” یا “ما فقط به یک MVP سریع نیاز داریم، زیرا هیچ یک از معیارهای کلیدی ما را تحت تاثیر قرار نمی دهد.”
و در هر صورت، ممکن است در تقلب USER احساس گناه کنید.
این متعاقباً منجر به ۲ وضعیت می شود:
۱-عدم تخصیص زمان برای آزمایش قابلیت استفاده به منظور راه اندازی زودهنگام.
۲-درخواست پشتیبان گیری از هر تصمیمی با اعداد و ارقام سخت و نه فقط بینش کاربران تا بتوانند بهترین تصمیم تجاری را بگیرند.
📣 بله، مدیران محصول معمولاً بیشتر به سمت اعداد افراد طیف متمایل می شوند.
تعریف مشکل
به عنوان متخصصان UX برای انجام کاری که می خواهیم انجام دهیم، باید ارزش UX را به سهامداران خود بفروشیم. مشکل این است که PM های ما همیشه به همان زبان ما صحبت نمی کنند – در حالی که ما با کاربران صحبت می کنیم، آنها برای تجارت صحبت می کنند. بنابراین، ما باید نیازهای کاربر را به ارزش تجاری تبدیل کنیم.
چگونه این کار را انجام دهیم؟ 🤔
اینم جواب…
ممکن است PM های ما واقعاً به اصول UX ما علاقه نداشته باشند، اما قطعاً به آنچه برای آنها مهم است علاقه مند هستند … “متریک کلیدی” آنها. بنابراین هر بار که راه حل خود را به آنها ارائه می دهیم، باید متریک محور باشد، یعنی اینکه طراحی من چگونه بر عملکرد محصول تأثیر می گذارد و در نتیجه بر متریک تأثیر می گذارد.
این فقط کاربران نهایی نیستند که ما طراحان باید با آنها همدلی کنیم.
هنگامی که راه حل ما آماده شد، نحوه ارائه آن به PM های خود تصمیم می گیرد که چقدر زود ارسال شود
و برای انجام این کار، ما باید یک مایل بیشتر با همدلی با PM ها نیز پیش برویم.
چیزی که ما نیاز داریم یک تغییر ساده در نحوه ارائه است. فقط مشاهده کنید که دیگران چگونه درک می کنند و به عنوان یک طراح، ما برای انجام این کار ساخته شده ایم. پس از همه، به همین دلیل است که ما وجود داریم – ارائه بهترین تجربه به کاربران خود.
⭐️ من این را به عنوان یک مهارت (غیر مستند، ناشناخته و ناشناخته) که با گذشت زمان به دست می‌آورم ترجیح می‌دهم و از نشان دادن آن در CV خود احساس غرور می‌کنم 🙂
هک سریع: فرمول مخفی ۳ مرحله ای
در چنین مواردی، برای مذاکره با PM خود، اغلب از فرمول InDoBy پیروی می کنم – (باور کنید این برای من کاملاً مؤثر بوده است)
بنابراین فرمول می گوید:
برای دستیابی به “x”، باید “y” را حل کنیم، که با ایجاد “z” قابل انجام است.
تقسیم آن به ۳ قسمت:
بخش ۱: برای دستیابی به “x”
در مورد آنچه که کسب و کار باید به دست آورد، هدف محصول فکر کنید. برای این کار، باید به خوبی از آنچه در چشم انداز/نقشه راه PM ها وجود دارد آگاه باشید.
به عنوان مثال. به منظور دستیابی به ۹۰٪ مجوز همگام سازی تماس توسط کاربران در اولین بازدید ~
بخش ۲: ما باید “y” را حل کنیم
سعی کنید مشکل / شکی که کاربر ممکن است داشته باشد را حل کنید و به همین دلیل است که از محصول به طور کامل استفاده نمی کند.
به عنوان مثال. ~ به آنها بفهمانید که همگام سازی مخاطبین کاملاً ایمن است و به آنها کمک می کند دوستان خود را که قبلاً از برنامه استفاده می کردند پیدا کنند
قسمت ۳: که می تواند با ایجاد “z” انجام شود
اکنون زمانی است که راه‌حل‌های طراحی خود را به نمایش می‌گذاریم و مطمئن می‌شویم که اهمیت تمام جریان‌های طراحی، استدلال UX، گزینه‌های UI و غیره را توضیح می‌دهیم.
به عنوان مثال. ~ این کار را می توان با استفاده از این گزینه، آن اشاره و غیره انجام داد.
به منظور دستیابی به ۹۰٪ مجوز همگام سازی تماس توسط کاربران در اولین بازدید،
به آنها بفهمانید که همگام سازی مخاطبین کاملاً ایمن است و به آنها کمک می کند دوستان خود را که قبلاً از برنامه استفاده می کردند پیدا کنند.
این کار را می توان با استفاده از این گزینه / آن اشاره / این کپی و غیره انجام داد.
نتیجه
متأسفانه، ما می توانیم طراحان باورنکردنی باشیم، اما تنها زمانی ارزشمند است که بتوانیم ارزش کار خود را به دیگران منتقل کنیم.
