https://virgool.ir/feed/@ehsan.collabfa2026-11-11 18:47:27https://files.virgool.ir/upload/users/4958172/avatar/avatar.pnghttps://virgool.ir/@ehsan.collabhttps://virgool.ir/@ehsan.collab/وقتی-مشکل-کاربر-نمی-دانم-چه-بنویسم-است-مروری-بر-ماژول-تقویم-محتوایی-هوشمند-b7awwqnuzujsصفحه اصلی ماژول انتشار محتوامحتواچی ابزاری ایرانی برای مدیریت، زمان‌بندی و انتشار محتوای شبکه‌های اجتماعی است؛ شبیه Buffer و Hootsuite، برای کسب‌وکارهای کوچک اینستاگرامی، تلگرامی و آنلاین‌شاپ‌ها. کاربران می‌توانند چند شبکه را از یک‌جا مدیریت کنند و محتوا را زمان‌بندی و منتشر کنند.در حین آزمایش ماژول انتشار محتوا که برای فاز اول برنامه‌ریزی شده بود، به مشکل دیگری برخوردیم: کاربران ما نمی‌دانستند اصلاً باید چه چیزی را منتشر کنند؛ انتشار برنامه‌ریزی‌شده محتوا، مسئله بعدی بود.

در این مطالعه موردی، به بررسی، ایده پردازی و طراحی راه‌حل برای این مشکل میپردازم.نقش من و تیمدر خرداد ۱۴۰۴، من به‌عنوان طراح محصول به این پروژه اضافه شدم و تا پایان مهر ۱۴۰۴ روی آن کار کردم. در این پروژه، علاوه بر ایده‌پردازی محصول، مسئولیت تحقیق کاربر، طراحی تجربه و رابط کاربری و دیزاین‌سیستم را بر عهده داشتم و برای بررسی نیازهای محتوا و تصمیم‌های مرتبط با محصول، با تیم مارکتینگ و سایر اعضای تیم همکاری نزدیک داشتم. فاز اول پروژه حدود پنج ماه زمان داشت و هدف تیم، آماده‌سازی آن برای کمپین شب یلدای ۱۴۰۴ بود.
طراح محصول: احسان معصومیمدیر پروژه: محبوبه امیدی
بیان مسئلهاز آنجایی که کاربران هدف محصول، صاحبان کسب‌وکارهای کوچک بودند، نه ادمین‌های حرفه‌ای شبکه‌های اجتماعی یا شرکت‌هایی با تیم محتوا، ما برای کمک به تولید محتوا یک چت‌بات داخلی به نام MohtavaGPT توسعه داده بودیم. کاربران می‌توانستند با قابلیت‌هایی مثل گسترش متن، تنظیم لحن و اصلاح املا و گرامر، متن خود را آماده کنند.فرض اولیه ما این بود که با وجود این ابزار، کاربران می‌توانند مسیر ایجاد و انتشار محتوا را بدون مشکل جدی طی کنند. اما این فرض نیاز به اعتبارسنجی داشت؛ برای همین تصمیم گرفتیم جریان اصلی محصول را با کاربران هدف بررسی کنیم.در مراحل ابتدایی، کاربران در کارهایی مثل اتصال اکانت‌ها و تنظیم اطلاعات برند نسبتاً راحت بودند؛ اما مشکل زمانی ظاهر شد که از آن‌ها خواستیم یک پست واقعی برای انتشار بسازند. معمولاً وارد بخش ایجاد محتوا می‌شدند، اما بعد از چند لحظه مکث می‌کردند.
در این تست، مسئله فقط این نبود که کاربران نمی‌دانستند چطور متن بنویسند؛ آن‌ها برای انتخاب اینکه چه محتوایی باید بسازند هم به کمک نیاز داشتند. اینجا متوجه شدیم MohtavaGPT می‌توانست در نوشتن کمک کند، اما بیشتر زمانی که کاربر از قبل ایده‌ای برای نوشتن داشت.MohtavaGPT / ابزاری که میتوانست به کاربر برای نوشتن متن خود کمک کند.چالش‌های کلیدی:زمان اجرای فاز اول محصول تا قبل از آذر ۱۴۰۴ بود. اگر نمی‌توانستیم مشکل «کاربر نمی‌داند چه چیزی بنویسد» را حل کنیم، خطر این وجود داشت که در مقایسه با رقبا مزیت مشخصی نداشته باشیم و محتواچی صرفاً به محصول دیگری برای مدیریت، زمان‌بندی و انتشار محتوای شبکه‌های اجتماعی تبدیل شود.تیم طراحی و مارکتینگ کوچک بود و در آن مقطع، به دلیل هزینه‌های عملیاتی، امکان گسترش تیم‌ها را نداشتیم.تحقیقنظرسنجی اولیه: از بیش از ۹۰ صاحب کسب‌وکار، عمدتاً آنلاین‌شاپ‌ها، درباره بزرگ‌ترین مشکلات و نیازهایشان سؤال کردیم. تحلیل پاسخ‌ها حدود دو هفته طول کشید.تست کاربردپذیری و مصاحبه: رای بررسی کاربردپذیری، یک تست مبتنی بر وظیفه (Task-based) با ۱۰ نفر از کاربران هدف انجام دادیم. هر شرکت‌کننده بین ۲ تا ۴ سناریوی مرتبط با جریان اصلی محصول را انجام می‌داد؛ از راه‌اندازی برند و اتصال شبکه‌های اجتماعی تا ایجاد و انتشار محتوا.بنچمارک: تجربه انتشار محتوا را در ۶ پلتفرم مشابه بررسی کردم تا الگوهای مناسب و نقاط ضعف تجربه کاربری آن‌ها را برای تصمیم‌های طراحی خودمان بشناسم.بینش‌های تحقیق:۶ نفر از ۱۰ شرکت‌کننده، در مرحله نوشتن متن متوقف شدند؛ ۴ نفر دیگر متن کوتاهی نوشتند یا از منبع دیگری کپی کردند.در میان راه‌حل‌هایی که مشاهده یا در گفت‌وگوها مطرح شد، کپی از رقبا یا گرفتن ایده از ChatGPT هم وجود داشت؛ راه‌حل‌هایی که لزوماً به برنامه مشخصی برای تولید محتوا منتهی نمی‌شدند.این یافته‌ها فرض اولیه ما را به چالش کشیدند: MohtavaGPT به بهبود متن کمک می‌کرد، اما به‌تنهایی مسئله شروع ایده‌پردازی را برای کاربران این تست حل نمی‌کرد.معیارهای موفقیت:کاهش تعداد کاربرانی که در مرحله ایجاد محتوا متوقف می‌شوند.افزایش استفاده کاربران از ماژول تقویم محتوایی هوشمندافزایش نرخ تکمیل مسیر ساخت تقویم.کاهش زمان رسیدن به اولین پست زمان‌بندی‌شده.بررسی میزان استفاده کاربران از ماژول در پلن‌های پولی و نیاز آن‌ها به شارژ مجدد توکن. (چون این ماژول فقط در پلن‌های پولی موجود بود و در صورت اتمام توکن موجود در پلن، قابلیت شارژ مجدد داشت).ایجاد چارچوب حل مسئله:بعد از آنکه مشخص شد مسئله کاربران این تست، بیش از خود نوشتن، شروع ایده‌پردازی برای محتواست، باید برای آن راه‌حلی پیدا می‌کردم. معمولاً در مرحله بارش فکری ایده‌های زیادی مطرح می‌شود، اما نیاز داشتم معیارهایی داشته باشم تا بتوانم بعد از ایده‌پردازی، راه‌حل‌ها را ارزیابی و با هم مقایسه کنم. در نهایت به این اصول رسیدم:کاهش بار ذهنی (Cognitive Load): راه‌حل نهایی باید تصمیم‌گیری کاربر درباره ایده تولید محتوا را آسان‌تر کند.مقیاس‌پذیری (Scalability): راه‌حل باید با افزایش کاربران و پیچیدگی محصول قابل توسعه باشد، بدون اینکه هر بار از ابتدا طراحی شود.مزیت رقابتی: باید دلیل مشخصی برای انتخاب محتواچی در مقایسه با ابزارهای مشابه ایجاد کند.هزینه عملیاتی: هزینه طراحی، توسعه و نگهداری راه‌حل باید با منابع در دسترس تیم تناسب داشته باشد.درآمد زایی: باید بررسی کنیم راه‌حل چه ظرفیتی برای ایجاد ارزش در پلن‌های پولی دارد.ایده های اصلی در بارش فکری:از آنجایی که برای این مسئله در محصول خودمان راه‌حل مشخصی نداشتیم و زمان محدودی تا آماده‌سازی فاز اول باقی مانده بود، می‌خواستم از اولین ایده‌ای که به ذهنم می‌رسید فراتر بروم و گزینه‌های متفاوت را بررسی کنم. برای این کار از روش Crazy 8s استفاده کردم.در نهایت، چهار ایده اصلی که از این مرحله به دست آمد به شرح زیر بود:آموزش ویدیویی: یک کانال آپارات راه‌اندازی کنیم و محتوای آموزشی درباره تولید محتوا در اختیار کاربران بگذاریم.پشتیبانی اختصاصی برای کاربران پولی: برای کاربرانی که اشتراک پولی تهیه می‌کنند، پشتیبانی اختصاصی در نظر بگیریم تا در تولید محتوا کمکشان کند.ایجاد کتابخانه و قالب: در صفحه ایجاد محتوا، بانک ایده و قالب ایجاد کنیم تا کاربر متناسب با نیازش از آن استفاده کند.ایجاد دستیار هوشمند تولید محتوا: یک دستیار مبتنی بر هوش مصنوعی توسعه دهیم که به کاربران برای ایده‌پردازی و آماده‌سازی محتوا کمک کند.ارزیابی ایده ها:چهار ایده پیدا کرده بودم، اما باید آن‌ها را بر اساس همان معیارهای حل مسئله ارزیابی می‌کردم:پس از جلسات بررسی ایده با مدیر پروژه و مدیرعامل، در نهایت ایده دستیار هوشمند انتخاب شد. این گزینه در ارزیابی تیم نسبت به سایر راه‌حل‌ها مناسب‌تر به نظر می‌رسید. بااین‌حال، در معیار هزینه عملیاتی نقطه‌ضعف داشت؛ چون توسعه و نگهداری آن ارزان نبود.در مقابل، پشتیبانی اختصاصی هم با افزایش تعداد کاربران به نیروی انسانی بیشتری نیاز پیدا می‌کرد. از نظر تیم، امکان ارائه دستیار هوشمند در پلن‌های پولی، مقیاس‌پذیری و ظرفیت ایجاد تمایز، این هزینه اولیه را توجیه‌پذیرتر می‌کرد. به همین دلیل این ایده را به‌عنوان مسیر نهایی برای طراحی انتخاب کردیم.تعریف مسئله جدیدفهمیده بودیم که می‌خواهیم از یک دستیار هوشمند تولید محتوا برای حل مشکل کاربر استفاده کنیم. اما چگونه؟ اصلاً دستیار هوشمند تولید محتوا دقیقاً چیست؟ چه ویژگی‌هایی باید داشته باشد؟ کاربر چگونه باید با آن تعامل کند؟ خروجی‌ها چگونه باید تعریف شوند؟ این‌ها سؤال‌هایی بودند که بعد از انتخاب راه‌حل برایم مطرح شدند.
برای پاسخ، سراغ این سؤال رفتم: یک ادمین شبکه‌های اجتماعی چگونه محتوای خود را ایجاد و برای انتشار برنامه‌ریزی می‌کند؟ به همین منظور، با تیم مارکتینگ و بخش تولید محتوا صحبت کردم. از این گفت‌وگو متوجه شدم که آن‌ها برنامه محتوایی را با پاسخ دادن به چند سؤال شکل می‌دهند:فرکانس پست گذاریروز های پست گذاریهدف پست گذارینوع محتوای پست هافرمت پست هاچالش های فعلی کسب و کارزمان های پست گذاریپس راه‌حل نهایی برای طراحی ماژول دستیار هوشمند باید شامل مجموعه‌ای از سؤال‌ها می‌شد که کاربر به آن‌ها پاسخ می‌داد و هوش مصنوعی بر اساس پاسخ‌ها، تقویم محتوایی هوشمند را پیشنهاد می‌کرد. به‌جای اینکه فقط برای یک پست ایده تولید کنیم، می‌خواستیم کاربر برای چند روز یا چند هفته پیش رو، نقطه شروع مشخصی برای برنامه‌ریزی محتوا داشته باشد.این تغییر از «تولید یک متن» به «پیشنهاد یک برنامه محتوایی»، منطق انتخاب تقویم هوشمند بود؛ برنامه‌ای که کاربر بتواند پیش از انتشار آن را بررسی و ویرایش کند.صفحه ورود Wizard و شروع ایجاد تقویم محتوایی هوشمندچالش های طراحیبه درک کلی از عملکرد ماژول رسیده بودم، اما در طراحی با چالش‌های زیر روبه‌رو شدم:حجم زیاد سوال ها: ایجاد تقویم محتوایی هوشمند به پاسخ کاربران به چند سؤال نیاز داشت؛ از تعیین هدف و نوع محتوا تا انتخاب اکانت‌ها و زمان‌بندی انتشار. باید راهی پیدا می‌کردم که این سؤال‌ها باعث خستگی یا رها کردن مسیر نشوند.ممکن بود کاربر نداد چه پاسخی بدهد: هنگام مواجهه با سؤال‌هایی مثل «چالش‌های فعلی کسب‌وکار»، کاربر ممکن بود نداند دقیقاً منظور چیست یا چطور پاسخ بدهد. بنابراین طراحی باید هم برای پاسخ دادن به او ایده می‌داد و هم امکان ارائه پاسخ شخصی را باز می‌گذاشت.اصول طراحیبرای حل چالش های طراحی سراغ این اصول رفتم:سؤال‌ها مرحله‌به‌مرحله پرسیده شوند:بر اساس اصل آشکارسازی تدریجی (Progressive Disclosure) و با هدف کاهش بار ذهنی، تصمیم گرفتم به‌جای نمایش همه سؤال‌ها در یک فرم طولانی، آن‌ها را به مراحل کوچک‌تر در یک جریان Wizard تقسیم کنم.نمونه ای از سوالاتی که برای هر مرحله طراحی شده بود و به ترتیب پرسیده میشدسؤال‌ها پاسخ‌های از پیش طراحی‌شده داشته باشند:چون ممکن بود کاربر نداند چه پاسخی بدهد، بر اساس اصل «تشخیص به‌جای یادآوری» (Recognition Rather Than Recall)، برای سؤال‌ها گزینه‌های پیشنهادی در نظر گرفتم تا شروع پاسخ دادن آسان‌تر شود.جواب های از پیش طراحی شده که کاربر میتواند از بین آنها انتخاب کندپاسخ‌ها انعطاف‌پذیر باشند: بر اساس اصل «انعطاف‌پذیری و کارایی استفاده» (Flexibility and Efficiency of Use)، تنها به گزینه‌های آماده اکتفا نکردم و امکان وارد کردن پاسخ اختصاصی را نیز گذاشتم؛ چون همه کسب‌وکارها هدف‌ها و شرایط یکسانی ندارند.کاربر میتوانست پاسخ جدیدی متناسب با هدف و شرایط خود بنویسدبعد از تکمیل ویزارد، چه اتفاقی می‌افتاد؟صفحه‌هایی که تا اینجا نشان دادم، مربوط به جمع‌آوری اطلاعات از کاربر بودند. اما مسیر ایجاد تقویم به پایان ویزارد محدود نمی‌شد. باید مشخص می‌کردم کاربر چطور اطلاعاتش را پیش از شروع تولید بررسی کند، هنگام ساخته‌شدن محتوا چه چیزی ببیند و بعد از آماده‌شدن پست‌ها چه کنترلی روی آن‌ها داشته باشد.بررسی نهایی پاسخ‌ها:بعد از آخرین مرحله ویزارد، یک صفحه مرور نهایی طراحی کردم تا کاربر بتواند اطلاعاتی را که وارد کرده بود دوباره ببیند و اگر جایی اشتباه شده بود، پیش از شروع ساخت تقویم آن را اصلاح کند. چون پیشنهادهای هوش مصنوعی بر اساس همین پاسخ‌ها ساخته می‌شدند، لازم بود کاربر فرصت بازبینی آن‌ها را داشته باشد.کاربر پیش از آغاز ساخت تقویم، پاسخ‌های ثبت‌شده را بررسی و در صورت نیاز اصلاح می‌کرد.ساخت تقویم بدون نگه‌داشتن کاربر در ویزارد:تولید چند پست با هوش مصنوعی زمان‌بر بود. برای همین تصمیم گرفتیم کاربر مجبور نباشد تا پایان پردازش در همان صفحه منتظر بماند. بعد از ثبت درخواست، ویزارد بسته می‌شد و کاربر به صفحه اصلی ماژول انتشار محتوا برمی‌گشت. در همان صفحه، یک پیام کوتاه (Toast) به او نشان می‌دادیم که پست‌هایش در حال ساخته‌شدن هستند.پس از بسته‌شدن ویزارد، وضعیت تولید محتوا در صفحه اصلی با یک پیام کوتاه اطلاع‌رسانی می‌شد.پیش‌نویس‌ها و بازبینی انسانی:بعد از پایان کار هوش مصنوعی، تمام پست‌های پیشنهادی در وضعیت پیش‌نویس (Draft) قرار می‌گرفتند؛ نه اینکه مستقیم منتشر شوند. کاربر باید محتوا را بررسی می‌کرد، تغییرات لازم را انجام می‌داد و پست‌ها را برای انتشار آماده می‌کرد. هدفم این بود که هوش مصنوعی سختیِ شروع ایده‌پردازی و آماده‌کردن پیشنهادهای اولیه را کمتر کند، اما تصمیم نهایی درباره محتوای منتشرشده همچنان در اختیار صاحب کسب‌وکار بماند.ساخت خودکار محتوا به‌معنای انتشار خودکار نبود؛ پست‌ها ابتدا برای بررسی انسان ذخیره می‌شدند.در نتیجه، راه‌حل فقط یک ویزارد برای پاسخ‌دادن به سؤال‌ها نبود؛ مسیری بود از بررسی اطلاعات و درخواست ساخت تقویم تا آماده‌شدن پیش‌نویس‌هایی که کاربر روی آن‌ها کنترل داشت.ارزیابی و نتایج:به دلیل خروج من از شرکت در مهر ۱۴۰۴، تست نهایی و مشاهده رفتار کاربران پس از انتشار محصول را شخصاً دنبال نکردم؛ بنابراین داده‌ای از عملکرد واقعی ماژول بعد از انتشار در اختیار ندارم.آنچه در زمان حضورم مشاهده کردم، نتیجه تست کاربردپذیری مسیر اولیه محصول بود؛ تستی که نشان داد کاربران در مرحله انتخاب موضوع محتوا به کمک بیشتری نیاز دارند. بر اساس همین یافته، طراحی راه‌حل از «کمک به نوشتن متن» به «کمک به تصمیم‌گیری و برنامه‌ریزی محتوا» تغییر جهت داد.این تغییر، خروجی مشخص فرایند طراحی و تصمیم‌گیری تیم بود. تأثیر آن بر استفاده کاربران، زمان ساخت محتوا یا درآمدزایی محصول، نیاز به اندازه‌گیری پس از انتشار داشت.آنچه که آموختم:این پروژه به من یاد داد که گاهی کاربر درباره «نوشتن» حرف می‌زند، اما ممکن است مسئله اصلی‌اش یک مرحله عقب‌تر باشد: اینکه «باید چه چیزی بنویسد؟».همچنین یاد گرفتم وقتی در جریان بررسی محصول با مسئله‌ای پیش‌بینی‌نشده روبه‌رو می‌شویم، بهتر است به فرضیه‌های اولیه برگردیم و دوباره آن‌ها را اعتبارسنجی کنیم. همین بازنگری می‌تواند مسیر طراحی را تغییر دهد و فرصتی برای ایجاد ارزش متفاوت در محصول بسازد.احسان معصومیاحسان معصومیWed, 14 Oct 2026 19:05:18 +0330