محصول / بخش: طراحی end-to-end پنل بکآفیس برای تیمهای CRM و محصول نمادنو
پلتفرم: Admin Dashboard ( Desktop)
نقش: طراح محصول (مالکیت کامل)
پس از گسترش سوپر اپ مالی نمادنو، با افزایش سرویسها و رشد کاربران، نیاز به یک پنل بکآفیس جامع و ساختارمند به یک ضرورت عملیاتی تبدیل شد.
من بهعنوان Product Designer مسئول طراحی end-to-end این داشبورد برای تیمهای CRM و Product بودم.
این پروژه در بازهای چندماهه انجام شد و شامل:
این یک پروژه UI نبود. این پروژه طراحی «سیستم کنترل عملیاتی» برای یک اکوسیستم مالی چندسرویسی بود.
سوپراپ شامل دامنههای زیر بود:
هرکدام دارای:
همزمان، پنل باید پاسخگوی دو تیم با ذهنیت متفاوت میبود:
CRM Team
Product Team
چگونه میتوان یک سیستم چنددامنهای با حساسیت مالی بالا را به ساختاری تبدیل کرد که هم قابل کنترل باشد و هم قابل درک؟
در ابتدا پنل بر اساس لیست سرویسها تعریف شده بود. اما این رویکرد باعث میشد:
مسئله فقط تنوع سرویس نبود؛ مسئله این بود که هر سرویس چندین نوع عملیات، وضعیت، و مدل مالی متفاوت داشت.
همچنین بخش های زیر دارای ریسک مالی و امنیتی بودند:
در این نقطه تصمیم گرفتم مسئله را بازتعریف کنم:
به جای طراحی بر اساس سرویس، باید بر اساس «نوع تعامل عملیاتی» طراحی کنم.
معماری اطلاعات را در سه لایه بازطراحی کردم:
Observability Layer
پیشخوان، گزارشها، رفتار کاربران، تراکنشها تمرکز بر دید کلان و تصمیمسازی
Governance Layer
مدیریت نقشها، مدیریت اپلیکیشن، تنظیمات کیف پول، مدیریت سرمایه تمرکز بر کنترل ساختار سیستم
Execution Layer
تمام عملیات بانکی، سرمایهگذاری، اعتباردهی، بیمه، کاربران تمرکز بر اقدام مستقیم
نتیجه:
با توجه به ماهیت مالی سیستم، طراحی دسترسی به یک تصمیم حیاتی تبدیل شد.
من از ابتدا طراحی را بر اساس زیر پایهگذاری کردم:
این موضوع زمانبرترین بخش پروژه بود زیرا:
بخش مدیریت مالی بیشترین پیچیدگی را داشت که شامل چالشهای زیر بود:
من تصمیم گرفتم:
این تصمیمها باعث شد پنل از یک ابزار نمایشی به یک سیستم قابل اتکا تبدیل شود.
با توجه به تعداد زیاد ماژولها (بیش از 20 ماژول عملیاتی)، اگر هرکدام ساختار مستقل داشتند، سیستم بهشدت ناپایدار میشد.
بنابراین الگوهای زیر را تعریف کردم:
این استانداردسازی باعث شد:
این پروژه به دلایل زیر چندین ماه زمان برد و شامل iterationهای متعدد بود:
بخش زیادی از زمان صرف موارد زیر شد:
این پروژه یک طراحی سریع نبود؛ یک فرآیند تحلیلی و بازطراحی چندمرحلهای بود.
در حال حاضر سیستم پیادهسازی شده و در حال اتصال کامل به تیم CRM است.
KPI های رسمی در حال جمعآوری هستند و طی ماههای آینده قابل اندازهگیری خواهند بود.
با این حال، از نظر ساختاری: