Lead product designer at Aparat
طراحی محصول، رقابتی از منظر فیچر!
این مبحث برای کسانی که طراح محصول هستند، مدیر محصول هستند یا قصد دارند به سمت طراحی محصول بیان میتونه مفید باشه.
من میخوام بحث رو با یک مثال شروع کنم…
فرض کنید برای خرید خودرو بین دو گزینه هم سطح از نظر اقتصادی قرار گرفته اید، چه معیار هایی را برای مقایسه دو خودرو در نظر میگیرید؟
چه معیارهایی باعث ترجیح دادن یک خودرو نسبت به خودروی هم سطح خود می شود؟
خودروهایی که وظیفه ی حمل و نقل را بعهده دارند و اگر فاقد این وظیفه و هدف باشند، به بازار معرفی نمی شوند… پس هر دو گزینه امکان حرکت کردن دارند.
حتما برای پاسخ به این سوال از کلمه آپشن یا امکانات استفاده میکنید و پس از اینکه ظاهر خودروی مورد نظر را با سلیقه خود انتخاب کردید به سراغ مهمترین معیار یعنی همان امکانات میروید.
در این وضعیت به احتمال زیاد، شما چک لیستی از امکانات هر دو مورد تهیه خواهید کرد و آن ها را در معرض مقایسه قرار می دهید و در نهایت آن مورد را که به نیاز های شما جواب مثبت داده باشد و در عین حال با سلیقه ی شما هم سو باشد را انتخاب می کنید.
میتوان گفت مهمترین معیار انتخاب بین چند محصول همسطح همان امکانات و آپشنهای آن محصول هستند.
حال میخواهیم این مثال را در محصولات آنلاین بسط دهم:
در فضای آنلاین نیز اکثر محصولات دارای رقبا و سرویس های مشابه هستند که کاربران با توجه به نیازهایشان و امکاناتی که آن محصول در اختیارشان قرار می دهد، یکی را انتخاب می کنند. همانطور که اکثرا اطلاع دارید این امکانات در محصول دیجیتال همان فیچر ها هستند.فیچرهایی که به محصول شما مزیت رقابتی و برتری نسبت به سایر سرویس های مشابه می دهد و دلایل انتخاب سرویس شما را از سمت کاربران شکل میدهند.
بعنوان مثال، میتوانید صفحه ای از سرویس Basecamp رو مشاهده کنید، که در آن، فیچرهای سرویسش را به معرض مقایسه با سرویس های مختلف قرار داده است و در این امر اسکیل کمپانی های مختلف، تعداد نیرو و حتی اهداف اون بیزینس ها برایش اهمیتی ندارد، تنها چیزی که در اینجا نقش بازی میکند و اهمیت زیادی برای مقایسه و تصمیم گرفتن کاربر دارد، فیچرهای محصول هستند.
بنابراین:
۱. فیچرها به محصول شما مزیت رقابتی و برتری نسبت به سایر محصولات مشابه میدهد و دلایل انتخاب محصول شما از سمت کاربران هستند.
۲.“کاربران” و “نیازهای کاربران” بالاترین اولویت در شکلگیری یک فیچر (یا آپشن در حوزههای دیگر) را دارند. (که در ادامه به بررسی این دلیل این اولویت خواهم پرداخت)
طبق مثالی که زده شد، موضوع بحثی که بدنبال آن هستیم مشخص شد، فیچر! که در پنج مورد زیر بدان میپردازم:
۱. فیچر چیست؟
۲.کانالهای فیچر ریکوئست چه هستند؟
۳. فیچرهای خوب از کجا میآیند؟
۴.انواع فیچر ریکوئستها کدامند؟
۵.نحوه ایجاد یک فیچر به چه شکل است؟
فیچر چیست؟
فیچرها امکانات و ابزار اضافی محصول شما هستند که در راستای اهداف و چشم انداز محصول اضافه می شوند و به محصول شما پر و بال میدهند. مثل کرم شکلاتی روی بستنی قیفی. اگر بدرستی و براساس نیاز کاربران به محصول اضافه شوند، باعث رشد و تقویت محصول می شوند و اگر با نیاز آن ها سازگار نباشد، شما منابع زیادی از تیم و محصول خود را هدر داده اید!
هشدارررررر!!!!!
بر اساس این تعاریف باید توجه داشت، راه اندازی هر فیچر برتری و در بازار رقابتی به همراه نمیآورد.
پس فیچرهای خوب از کجا می آیند؟
برای پاسخ به این سوال باید با مفهوم فیچر ریکوئست(Feature Request) آشنا شویم، درواقع هر امکان یا فیچری که قرار است به محصول اضافه شود، از کانالی به تیم محصول پیشنهاد میشود درواقع این پیشنهاد همان فیچر ریکوئست است.هر کدام از این گروهها به احتمال زیاد به شما پیشنهاد راه اندازی یک فیچر را در نقاط مختلف محصول میدهند:
- بخش فروش و مارکتینگ
- مدیران و سهامداران
- تیم توسعه
- تیم پشتیبانی
اگرچه که ایدههای این گروهها (تیم فروش و مارکتینگ، مدیران و سهامداران و تیم توسعه) احتمالا با محصول و اهداف تجاری محصول منطبق است و حتی درک زیادی از مشتریان نیز دارند، اما با توجه به دو واژه "کاربران" و "نیاز کاربران" که در ابتدا گفتم، تیم توسعه، تیم فروش و مدیران و سهامداران، مشتریان شما نیستند!
پس نیاز است تا ایدههای آنها را نیز توسط کاربران (مشتریان) به اعتبارسنجی گذاشتهشود. نباید صرف اینکه این درخواستها از کانال تیم توسعه و یا سهامداران آمده، آن را سریعا در مرحله اجرا قرار دهیم.همچنین نباید به درخواست یک کاربر، فیچری را خلق و اجرا کرد. شما باید کل بازار کاربرانتنان را ببینید! نه فقط به یک نفر یا به اقلیت کاربران گوش دهید!
و اما بخش پشتیبانی محصول؛
این بخش بطور مداوم با کاربران (مشتریان) در ارتباط مستقیم است این جا درست جایی است که بیشترین درخواست فیچر اتفاق میافتد، اکثر درخواستها از سوی مشتریان کنونی محصول میآید که یا متوجه چیزی میشوند که محصول را بهبود میبخشد یا چیزی را میبینند که به آن نیاز جدی دارند! از این حیث تیم محصول درحد امکان باید اوقاتی را بطور مستقیم با کاربران (مشتریان) بگذراند.
این نوع درخواست ها باید بررسی شوند تا اگر به مقدار کافی خوب هستند و با اهداف محصول هم سو هستند، آن ها را در صف اجرا قرار داد. بنابراین فیچر ریکوئست هایی که از سمت کاربران می آید و با اهداف محصول هم سو هستند، بهترین فیچر ها جهت اجرا می باشند.
هدف همیشه باید خلق فیچرهایی باشد که به نفع همه کاربران است، نه فقط یک کاربر خاص. شما باید کل بازار کاربران را در نظر بگیرید، اولویت خلق واجرا نباید با اقلیت کاربران یا صاحبان محصول یا مدیران مارکت باشد.
پس فیچر ریکوءست هایی که از کانال کاربران می آیند، اولویت بالاتری نسبت به بقیه کانال های ورودی دارند. اما همیشه آنها درست نیستند! مشتریان همیشه نمیدانند چه چیزی برای آنها بهتر است. اما بازخوردهای آن ها می تواند ما را متوجه مشکلات اساسی کند که کاربر در محصول تجربه کرده است.
بنابراین،به این نکات در مورد فیچر ریکوئستهای بخش پشتیبانی می توان اشاره کرد:
- تیم محصول درحد امکان باید اوقاتی را بطور مستقیم با کاربران (مشتریان) بگذراند.
- این نوع درخواستها باید بررسی شوند اگر با اهداف محصول هم سو باشند، باید آنها را در صف اجرا قرار داد.
- هدف همیشه باید خلق امکان و فیچریهایی باشد که از سمت عموم کاربران میآید نه فقط یک کاربر خاص.
- شما باید کل بازار کاربران را در نظر بگیرید، اولویت خلق واجرا نباید با اقلیت کاربران یا صاحبان محصول یا مدیران مارکت باشد.
تمرکز روی نیازهای کاربران به معنای حفاظت از محصول و نگهداری کاربران است.
قبل از اینکه به درخواست فیچری پاسخ دهید، در اولین سطح، از خود بپرسید:
۱.آیا این امکان محصول را به چشمانداز و اهداف اصلی بیزینسی خود نزدیک میکند؟
۲. آیا کاربران با دیدن این امکان احساس خوشایندی دارند؟
۳. آیا این امکان به محصول شما ارزش و بهایی میدهد؟یا اینکه صرفا این یک ایده "جالب" است.
فیچرها را برای دلایل مختلف انتخاب کنید، نه صرفا بدلیل جالب بودن.
باید توجه داشت که همه درخواستها یکسان نیستند، بنابراین مهم است که بین آنها تفاوت قائل شویم تا بتوانیم راحت تر آنها را مدیریت کنیم، پس:
انواع درخواست های فیچر را بشناسیم!
گزارش مشکلات:
هنگامی که کاربر یا تیممحصول، تیم توسعه، پشتیبانی و... متوجه میشود چیزی در محصول شما بدرستی کار نمیکند.
بهبود فیچر:
پیشنهادهایی برای فیچری که میتواند کمی بهتر شود.
فیچرهای جدید:
ایدههایی برای اضافه کردن فیچرهای جدید که میتواند به محصول اضافه شود.
این نوع درخواست است که از ابتدا حول آن صحبت کرده ایم. برای رسیدگی و راهاندازی فیچر جدید باید به چند اصل توجه داشت که در این بخش به آنها میپردازیم:
چند اصل برای راهاندازی فیچر جدید:
۱.هزینه پیچیدگی محصول !
با هر ابزار و فیچری که به محصول اضافه میکنیم، سطح پیچیدگی آن را به واسطه تغییرات ظاهری (UI)، گزینههای جدید روی دشبورد محصول، یک یا دو صفحه جدید و… بالا میبرید، همه این موارد نباید عملکرد اصلی محصولتان را مختل کنند.
فیچرها نه رایگان ایجاد و نه رایگان نگهداری میشوند! بنابراین علاوه بر اینکه باید کانالهای ورودی درخواست فیچر، ارزشمندی، نیاز کاربران را بررسی میکنید باید به هزینه اجرا و نگهداری نیز باید دقت کرد.
۲.اولویتبندی و توازن!
علاوه بر در نظر گرفتن هزینههای مربوط به اجرا فیچر جدید، الزامیست که مطمئن شوید اولویتهای خود را هنگام تصمیمگیری برای اضافه کردن و یا عدم اضافه کردن آن فیچر بدرستی چیدهاید!
اگر محصول شما غرق در انجام کارهای فنی، رفع مشکلات مختلف و بروزرسانیهای زیرساختی است، زمان مناسبی برای ساختن فیچر جدید و جذاب نیست زیرا حفظ نقشه راه سالم محصول است که توازن و نگهداری محصول را حفظ میکند.
۳.فیچرهای بدرد نخور ایجاد نکنید!
زمانی که فیچرهای زیادی به محصول خود اضافه میکنید، کاربرانتان را حین کارکردن با محصول، در معرض خستگی و کلافگی قرار میدهید، از این رو برای ایجاد و برنامه ریزی یک فیچر حتما نیاز است تا با احتیاط زیاد قدم بردارید و درمورد اینکه چه بازخوردهایی بعد از راه اندازی این فیچر دریافت خواهید کرد فکر کنید!
کلام آخر!
با توجه به بررسی درخواستهای فیچر باید گفت، یک مدیر محصول و طراح محصول خوب، نه تنها با کلمه "نه" راحت است، بلکه آماده است تا با کلمه "چرا" به شیوهای مناسب فیچر ریکوئست را پیگیری کند. در واقع این پیگیری به معنای استخراج برخی اطلاعات برای بررسی اهمیت آن فیچر برای محصول است و تا حد امکان از ایجاد فیچر های بدرد نخور جلوگیری کند.
در اینجا، بخش اول این مقاله به پایان رسید، و نکته ای که در این زمان نیاز است که بدانیم، این است که خیلی از مدیران محصول در چرخه توسعه محصول، اولویت را با ایجاد و راه اندازی فیچر محصول می گذارند که درواقع این دیدگاه اشتباه است، چرا که راه اندازی یک فیچر فقط آغاز فرآیند است…
آغاز فرآیندی که درموردش در ادامه توضیح خواهم داد...
این مقاله آمیخته از تجریبات و اطلاعات شخصی به همراه استخراج مطالب از uservoice.com و craft.io و ... میباشد.
مطلبی دیگر از این انتشارات
چک لیست طراحی Date Picker
مطلبی دیگر از این انتشارات
یک نقشهی ذهنی(Mind Map) برای مراحل طراحی تجربه کاربر
مطلبی دیگر از این انتشارات
محاسبه معیارهای کلیدی (KPI) در اپلیکیشن های موبایل