طراحی داشبورد ادمین سوپر اپ مالی نمادنو

طراحی سیستم مدیریت و کنترل برای یک اکوسیستم مالی چندسرویسی

محصول / بخش: طراحی 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

تمام عملیات بانکی، سرمایه‌گذاری، اعتباردهی، بیمه، کاربران
 تمرکز بر اقدام مستقیم

نتیجه:

طراحی سیستم براساس نقش

با توجه به ماهیت مالی سیستم، طراحی دسترسی به یک تصمیم حیاتی تبدیل شد.
من از ابتدا طراحی را بر اساس زیر پایه‌گذاری کردم:

  • Role hierarchy
  • Permission granularity
  • Module-level restriction
  • Action-level validation

این موضوع زمان‌برترین بخش پروژه بود زیرا:

  • هر دامنه مالی نیاز به سطح دسترسی متفاوت داشت
  • برخی عملیات دارای ریسک مالی مستقیم بودند
  • باید از خطای انسانی جلوگیری می‌شد

چالش‌های سیستم مالی

بخش مدیریت مالی بیشترین پیچیدگی را داشت که شامل چالش‌های زیر بود:

  • تراکنش‌های چندمرحله‌ای
  • وضعیت‌های مختلف (Pending, Failed, Settled, Reversed…)
  • تعامل با سرویس‌های بیرونی
  • مدیریت خطاهای بانکی

من تصمیم گرفتم:

  • یک State System استاندارد برای تمام تراکنش‌ها تعریف کنم
  • Timeline-based transaction view طراحی کنم
  • عملیات پرریسک را دارای تأیید چندمرحله‌ای کنم
  • Log visibility را به‌عنوان بخشی از تجربه طراحی در نظر بگیرم

این تصمیم‌ها باعث شد پنل از یک ابزار نمایشی به یک سیستم قابل اتکا تبدیل شود.

سیستم سازی طراحی

با توجه به تعداد زیاد ماژول‌ها (بیش از 20 ماژول عملیاتی)، اگر هرکدام ساختار مستقل داشتند، سیستم به‌شدت ناپایدار می‌شد.
بنابراین الگوهای زیر را تعریف کردم:

  • Pattern مشترک جستجو
  • Pattern نمایش وضعیت
  • Pattern اقدام
  • Pattern ثبت لاگ

این استانداردسازی باعث شد:

  • زمان آموزش اپراتورها کاهش یابد
  • توسعه آینده ساده‌تر شود
  • تجربه کار در کل سیستم همگن شود

زمان و Iteration

این پروژه به دلایل زیر چندین ماه زمان برد و شامل iterationهای متعدد بود:

  • تعدد دامنه‌های مالی
  • نیاز به هم‌راستاسازی با تیم فنی
  • بررسی سناریوهای ریسک
  • بازطراحی چندباره معماری اطلاعات

بخش زیادی از زمان صرف موارد زیر شد:

  • بازتعریف ساختار
  • هم‌ترازی با تیم محصول
  • بررسی edge caseهای مالی
  • و بازنگری مدل دسترسی شد

این پروژه یک طراحی سریع نبود؛
 یک فرآیند تحلیلی و بازطراحی چندمرحله‌ای بود.

وضعیت فعلی و تاثیرات

در حال حاضر سیستم پیاده‌سازی شده و در حال اتصال کامل به تیم CRM است.

KPI های رسمی در حال جمع‌آوری هستند و طی ماه‌های آینده قابل اندازه‌گیری خواهند بود.

با این حال، از نظر ساختاری:

  • معماری اطلاعات تثبیت شده
  • مدل دسترسی استاندارد شده
  • ساختار مالی قابل مدیریت شده
  • سیستم آماده توسعه سرویس‌های جدید است

یادگیری‌های کلیدی

  • طراحی پنل مالی، طراحی «کنترل ریسک» است نه فقط طراحی صفحه
  • امنیت و دسترسی باید از ابتدا وارد معماری شوند
  • ساختار ذهنی اپراتور با ساختار فنی سیستم متفاوت است
  • سیستم‌های پیچیده نیاز به لایه‌بندی دارند، نه لیست‌سازی