اولین کاری که برای شروع باید انجام بدیم، ست کردن و هماهنگی جلسه بریف هست. برای چی؟ برای اینکه با ذهنیت یا به قول معروف perspective کارفرما یا کلاینت آشنا بشیم. و برای مسیری که شروع کردیم، same page باشیم.
بعد از اینکه زمان و ددلاین پروژه را مشخص کردیم، تمام تسکهایی که موظف هستیم انجام بدیم را توی اسپرینت های مشخصی طبقه بندی میکنیم. البته ابزار gantt chart هم به ما کمک میکنه تا بر اساس ددلاینی که داریم، تسک ها رو مدیریت کنیم. که من این برنامه ریزی رو همون ابتدا توی ابزار کاربردی click up انجام میدم. و برای اساین کردن تسک ها بین تیم فنی و دیزاین از Jira یا Trello استفاده میکنیم.
خب، حالا یه ذهنیت کلی از کارهایی که باید انجام بدیم داریم. ما یه پروداکت مدیریت آموزشی می‌خوایم. درسته؟
اولین کار این هست که دسته بندی کاربرهامون را مشخص میکنیم. باید چند دسته کاربر به صورت کاملا مجزا از محصول ما استفاده میکنند.
توی این پروداکت، سه ساید کلی کاربر داریم، که نیاز هست برای هرکدام، پرتال کاربری و ui kit جداگانه‌ای طراحی و دیزاین کنیم.
نکته: صفحه ی لندینگ فقط و منحصرا برای ساید یوزر هست. و باقی سایدها فقط دشبورد انحصاری خودشان را دارند.
الف) یوزر: کاربران اصلی ما هستند. ارتقای دسترسی‌پذیری، کاربردپذیری و عملکردی پروداکت بیشتر برای این دسته ازیو کاربران انجام میشه. که در این محصول شامل دو دسته میشود. دانشجوها و مدرسین. که هرکدام پرتال و صفحه کاربری متفاوت و مجزای خودشان را دارند.
ب) آدیت: تقریبا پشتیبان سایت یا پروداکت محسوب میشوند، حین ثبت نام و ارایه فیچرها و امکاناتی که نیاز به حضور یک فرد دیگه هست، این کاربران در دشبورد اختصاصی خودشون، به نیازهای یوزرها رسیدگی میکنند.
پ) ادمین: این ساید تحت کنترل فاندرها، مدیر محصول، مالک محصول، کلاینت یا کارفرما هست. و شامل فیچرها و امکاناتی برای نظارت بر آدیت ها و عملکرد اونهاست.
سپس مراحل ریسرچ یا Empathise تجربه کاربری شروع میشود.
نکته: بسته به نیاز و اسکیل پروداکت، ابزارها و فریم ورک های متفاوتی برای انجام آن به کار می رود و نمیتوان یک نسخه کلی ریسرچ برای تمام محصولات دیجیتال ارایه داد.
حالا که داریم طبق پنج استپ معروف و معمول design thinking پیش میریم، پس بهتره یه گریزی هم بزنیم به اون رفرنس و یه review دوباره ازش بکنیم.
من برای این پروداکت مدیریت آموزشی با کاربران داوطلب و از هر سه ساید مصاحبه رو در رو انجام دادم. و برای پروژه‌ای مشابه از ابزارهای ساخت survey صرفا و فقط از کاربران(یوزرها) استفاده کردم. تا بتونم حجم دیتای بیشتری در بازه زمانی کمتری دریافت کنم.
سپس از فریم ورک afinity diagram دیتای جمع‌آوری شده از مصاحبه ها و پرسشنامه ها را طبقه بندی کردم.
بعد از اون باید دیتای پراکنده رو به information های کاربردی تبدیل کنیم و برای هر دسته‌بندی تایتل مشخصی ارایه بدیم.
اینجوری راحت‌تر میتونیم need و goal و want و motivation کاربر رو تشخیص بدیم.
نکته: یه نکته بگم. Want کاربر همون ابراز نیازی هست که کاربر توی مصاحبه، به زبون میاره. ما باید از طریق اون به need کاربر برسیم تا بتونیم نسبت به اون نیازهای اصلی راه حل های بهتری ارایه بدیم. برای استخراج نیازهای کاربر از دیتای خام مصاحبه، فریم وورک Jobs To Be Done هم وجود داره. اما با توجه به اسکیل پروژه ما لزومی به استفاده ازش نیست.
خب مرحله. Empathise یا همدلی با کاربر برای این پروداکت تموم شد. حالا نوبت مرحله define میرسه.
توی این مرحله، بر اساس دیتایی که توی afiinity diagram جمع آوری کردیم، نیاز ها یا همون need های کاربر رو در سه context متفاوت بررسی میکنیم.
براساس مدل کانو، کاربران سه دسته(البته اصلی پنچ دسته‌ست اما دو نوع از اونها رو تو این پروژه به کار نبردم) نیاز دارند.
یک: نیازهای پایه ( basic need ) : نیازهایی هستند که باید و حتما توی محصول برطرف بشوند. یعنی sulotion های اصلی باید برای این نیازها ارایه بشه. و توی نسخه mvp پروداکت، باید برای تمام این نیازها راه حلی ارایه داده باشیم.
دو: نیازهای عملکردی ( performance need ): نیازهایی هستند که کاربر، طی استفاده از پروداکت، برطرف شدنشون رو میخواد. اما اگه توی نسخه های اولیه اونها برطرف نشن، احتمال اینکه پروداکت اون کاربران رو از دست بده، زیاد نیست.
سه: نیازهای انگیزشی ( Excitement need ): اینها نیازهایی هستند که اگه برطرف بشوند کاربران satisfied به کاربران delighted تبدیل میشود. و این دقیقا همون اتفاقی هست که یک محصول رو با محصولات مشابه خودش، در مارکت مشابه، متمایز میکنه.
نکته: برای نیازها هم لازمه که معلول و چرایی (insight) اون نیاز رو از خروجی‌ای که از داده‌های مصاحبه و پرسشنامه به دست آمده بررسی کنیم.
من در کنار نیازهای کاربر که بدست اوردم، motivation و challenge ها یا frustration های کاربر رو هم در کنار information جمع اوری شده قرار دادم. این اطلاعات ما رو در مسیر طراحی و ساخت پرسونای کاربر کمک میکنه.
حالا نوبت طراحی و ساخت پروسناست.
نکته: اهداف مارکتینگ این پروداکت ایجاب میکرد که بیشتر روی بهبود تجربه کاربرانی کار کنیم که already از دانشجویان اون پروداکت بودند و یا قبلا دوره ای شرکت کرده، و حالا به روشهای متفاوتی قرار هست دوباره به آکادمی برگردند و در دوره ها شرکت کنند. برای همین چالشهای پرسونای محصول، با پرسونایی که مطلقا هیچ ارتباطی با پروداکتهای مشابه نداشته، کمی تفاوت دارد.
نکته: دیتای پرسوناها، کمی نسبت به نسخه‌س اصلی پروژه متفاوت هستند. و من اجازه انتشار اطلاعات دقیق رو نداشتم.
پرسونا توی اسکلت اولیه نیاز به داده های دموگرافیک فرضی داره.
در حقیقت، پرسوانا نماینده ای از تمام کاربرهای احتکالی ما هست که پتانسیل استفاده از محصول ما رو دارند. یعنی ما پرسونا رو طراحی میکنیم تا یه دید کلی و شفاف از کاربرمون داشته باشیم.
من برای این پروداکت، با توجه به اینکه یوزرهای ما به دو دسته دانشجوها و مدرسین تقسیم میشوند، دو پرسونا با context های متفاوت طراحی کردم و همچنین دو یوزر جرنی کلی و فرضی برای محصول، بهشون ضمیمه کردم.
قبل از اینکه وارد مرحله ideate بشیم، من ترجیح دادم که یه benchmark یا تحلیل رقبا از پروداکت های مشابه جمع آوری کنم. این بنچمارک شامل مقایسه فیچرهای کلی، مقایسه جنرال سایت مپ، و همچنین، طراحی یه table کلی برای فیچرهایی هست که فکر میکنیم به صورت فرضی برای پروداکت خودمون مورد استفاده قرار خواهند گرفت و نقش حیاتی دارند.
بعد نوبت مرحله ideate یا همون brainstorming هست. مرحله محبوبم.
اینجا لازمه که یه جسله مفصل با کارفرما و تیم دیزاین تنظیم کنیم و با توجه به دیتایی که از پرسونای محصول در دسترس داریم، فیچرها و ساختار کلی و inormdtion architecture یا general user flow محصول رو طراحی کنیم. این اقدامات مسیر طراحی wireframe ها رو برامون هموار میکنه.
بعد از اون، وارد مرحله design میشیم. که شامل طراحی اسکچ ها روی کاغد، سپس طراحی وایرفریم ها در فیگما، و بعد از اون طراحی یو آی و prototype محصول خواهد بود. که طی جلسات متعدد و همفکری تیم دیزاین و فنی، به نتیجه قابل قبولی خواهد رسید.
بعد از همه اینها. نسخه mvp پروداکت آماده لانچ و تحویل به تیم فنی هست.
بعد از اینکه محصول روی سرور بالا اومد، ما از طریق ابزارهای تست، مثل hotjar، و دیگر ابزارهای کاربردی که به ما heatmap و خروجی دیتای کاربران در حین استفاده از محصول رو میدن استفاده میکنیم.، سعی میکنیم تا تست کاربرد پذیری یا همون usability test رو به بهترین نحو انجام بدیم، تا در نسخه‌های بعدی با دید بازتری تغییرات لازمه رو اعمال کنیم، و همچنین کاربر satisfied رو به کاربر delighted تبدیل کنیم. یا به زبان ساده تر، از یه کاربر خوشحال، یه کاربر وفادار بسازیم و بهترین تجربه کاربری رو برای اونها به ارمغان بیاریم.
ممنونم که وقت گذاشتید و کیس استادی من رو مطالعه کردید.(قلب)
