حسابدار من؛ طراحی یک اپلیکیشن مالی شخصیبرای مدیریت ساده‌تر پول و هزینه‌های روزمره

طراحی و توسعه یک اپلیکیشن مدیریت مالی شخصی با تمرکز بر ثبت تراکنش، انتقال بین حساب‌ها، لیست خرید، تجربه کاربری فارسی و معماری قابل توسعه

شروع پروژه؛ وقتی مدیریت مالی شخصی نباید پیچیده باشد

بسیاری از ابزارهای مدیریت مالی یا بیش از حد ساده‌اند، یا آن‌قدر قابلیت و نمودار دارند که کاربر برای انجام یک کار روزمره باید چند مرحله اضافی طی کند.

ایده «حسابدار من» از یک نیاز ساده شروع شد:

ساخت ابزاری که بتوان با آن وضعیت مالی روزمره را سریع ثبت و مدیریت کرد، بدون اینکه تجربه استفاده شبیه کار با یک نرم‌افزار حسابداری سازمانی باشد.

تمرکز پروژه از ابتدا روی سادگی بود.

کاربر باید بتواند حساب‌هایش را تعریف کند، درآمد و هزینه ثبت کند، انتقال بین حساب‌ها انجام دهد و در ادامه از ابزارهایی مثل لیست خرید هم استفاده کند؛ در یک رابط فارسی، روشن و قابل فهم.

این پروژه هنوز در حال توسعه و تکمیل است و قابلیت‌های آن مرحله‌به‌مرحله در حال گسترش هستند.

هدف؛ ساخت یک ابزار روزمره، نه فقط یک داشبورد مالی

هدف حسابدار من این نبود که مجموعه‌ای از نمودارهای جذاب تولید کند.

هدف این بود که کاربر واقعاً بتواند هر روز از آن استفاده کند.

ثبت یک هزینه نباید زمان‌بر باشد.

انتقال پول بین دو حساب نباید نیاز به ثبت دو تراکنش دستی داشته باشد.

لیست خرید نباید یک بخش جدا و بی‌ارتباط با مدیریت مالی باشد.

از ثبت اطلاعات تا مدیریت جریان پول

هر قابلیت پروژه براساس یک سؤال عملی طراحی شد.

الان چه مقدار پول در حساب‌ها وجود دارد؟

این ماه چقدر هزینه شده؟

درآمدها چقدر بوده‌اند؟

پولی که بین حساب‌ها جابه‌جا شده چطور ثبت شود؟

برای یک خرید آینده چقدر بودجه در نظر گرفته شده؟

این نگاه باعث شد محصول به‌جای اینکه حول Feature List ساخته شود، حول جریان‌های واقعی استفاده شکل بگیرد.

حساب‌ها؛ پایه اصلی ساختار مالی

اولین لایه سیستم، مدیریت حساب‌هاست.

کاربر می‌تواند حساب‌های مختلف خود را ثبت کند و تراکنش‌ها را به آن‌ها متصل نگه دارد.

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

در روند توسعه، قابلیت‌هایی مثل ویرایش حساب، انتخاب حساب پیش‌فرض، آرشیو و حذف نیز در نظر گرفته شدند.

حذف حساب بدون خراب کردن تاریخچه

یکی از مسائل مهم در طراحی این بخش، رفتار سیستم هنگام حذف حساب بود.

اگر یک حساب قبلاً در تراکنش‌ها استفاده شده باشد، حذف ساده آن می‌تواند تاریخچه مالی را خراب کند.

بنابراین قوانین حذف باید با وضعیت داده‌های مرتبط هماهنگ باشند.

در کنار آن، Undo برای بعضی عملیات‌ها در نظر گرفته شد تا اشتباه‌های کاربر به یک اقدام غیرقابل بازگشت تبدیل نشوند.

تراکنش‌ها؛ ثبت سریع درآمد و هزینه

هسته اصلی یک اپلیکیشن مالی، تراکنش‌ها هستند.

در حسابدار من، کاربر می‌تواند هزینه و درآمد را ثبت کند و خلاصه وضعیت ماهانه را ببیند.

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

کمتر کردن اصطکاک ثبت روزانه

در اپلیکیشن‌های مالی، هر مرحله اضافه می‌تواند باعث شود کاربر بعد از چند روز ثبت اطلاعات را کنار بگذارد.

به همین دلیل تلاش شد فرم‌ها تا حد ممکن مستقیم باشند.

کاربر نباید برای ثبت یک هزینه ساده وارد چند صفحه یا منوی تو در تو شود.

هدف این است که ثبت تراکنش تبدیل به رفتاری سریع و طبیعی شود.

انتقال بین حساب‌ها؛ یک عملیات، نه دو تراکنش جدا

انتقال پول بین حساب‌ها از نظر مالی نه درآمد است و نه هزینه.

اما اگر معماری داده درست نباشد، ممکن است در گزارش‌ها به شکل اشتباه محاسبه شود.

برای همین Transfer به‌عنوان یک نوع ارتباط مشخص بین تراکنش‌ها طراحی شد.

حفظ ارتباط دو طرف انتقال

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

این کار باعث می‌شود سیستم بداند خروج مبلغ از یک حساب و ورود آن به حساب دیگر، دو رویداد مستقل نیستند.

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

در رابط این بخش نیز جزئیاتی مثل نمایش لوگوی بانک، تاریخ، واحد تومان و فاصله‌گذاری عناصر بارها اصلاح شدند تا تجربه نهایی تمیزتر باشد.

تجربه کاربری فارسی؛ RTL فقط راست‌چین کردن نیست

یکی از بخش‌های مهم پروژه، طراحی رابط برای زبان فارسی بود.

RTL واقعی فقط به معنی قرار دادن direction: rtl روی صفحه نیست.

ترتیب آیکن، عنوان، فلش، فاصله‌ها و رفتار کامپوننت‌ها باید با الگوی خواندن فارسی هماهنگ باشد.

یک استاندارد ثابت برای کامپوننت‌ها

در ساختار رابط، الگوی ثابتی برای ردیف‌ها شکل گرفت:

آیکن و عنوان در سمت راست قرار می‌گیرند و اکشن یا فلش به سمت چپ منتقل می‌شود.

این استاندارد کمک می‌کند صفحات مختلف اپلیکیشن احساس یک محصول یکپارچه داشته باشند.

همچنین تلاش شد از راه‌حل‌هایی مثل row-reverse که می‌توانند در بعضی کامپوننت‌ها رفتارهای غیرمنتظره ایجاد کنند، تا حد امکان دوری شود.

لیست خرید؛ ترکیب برنامه‌ریزی با مدیریت مالی

یکی از قابلیت‌هایی که در ادامه توسعه پروژه اضافه شد، Shopping Lists بود.

هدف این بخش فقط ساخت یک Todo List دیگر نبود.

لیست خرید می‌تواند به برنامه‌ریزی مالی قبل از انجام خرید کمک کند.

کاربر هنگام ساخت لیست می‌تواند نام، تاریخ، مبلغ تخمینی، یادداشت و یادآوری را مشخص کند.

از یک لیست ساده تا جریان خرید

بعد از ساخت لیست، کاربر می‌تواند دسته‌بندی‌ها و زیرگروه‌های موردنظر را انتخاب کند.

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

همچنین امکان اضافه‌کردن دسته‌بندی جدید در جریان کار در نظر گرفته شد.

فقط آیتم‌هایی که واقعاً انتخاب شده‌اند در مرحله نهایی نمایش داده می‌شوند تا رابط شلوغ نشود.

Draft؛ وقتی داده نباید قبل از تأیید نهایی ذخیره شود

یکی از تصمیم‌های مهم در بخش Shopping List، زمان ایجاد واقعی لیست بود.

در نسخه‌ای از جریان، ممکن بود لیست قبل از اینکه کاربر مراحل انتخاب را تمام کند در دیتابیس ساخته شود.

این رفتار می‌توانست باعث ایجاد رکوردهای ناقص یا بدون استفاده شود.

برای همین جریان اصلاح شد تا لیست فقط بعد از تأیید کاربر ساخته شود.

داده باید بازتاب تصمیم واقعی کاربر باشد

این اصل در بخش‌های مختلف پروژه اهمیت دارد.

اگر کاربر هنوز عملیات را تمام نکرده، سیستم نباید فرض کند تصمیم نهایی گرفته شده است.

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

اجزای رابط؛ ساخت یک زبان بصری مشترک

با گسترش پروژه، کامپوننت‌های اختصاصی بیشتری برای بخش‌های مختلف ساخته شدند.

برای مثال Shopping Hero Card خلاصه وضعیت لیست‌ها را با Progress و اطلاعات اصلی نمایش می‌دهد.

Shopping Quick Actions نیز دسترسی سریع به عملیات پرتکرار را فراهم می‌کند.

قابلیت باید در جای درست دیده شود

وجود یک Feature به‌تنهایی کافی نیست.

کاربر باید بتواند آن را پیدا کند و بفهمد چه زمانی به دردش می‌خورد.

به همین دلیل معماری رابط و جای‌گذاری اکشن‌ها به اندازه خود قابلیت‌ها اهمیت پیدا کرد.

حتی نام برخی بخش‌ها نیز در طول توسعه تغییر کرد؛ برای مثال «قالب‌ها» به «لیست‌های آماده» تغییر کرد تا مفهوم آن برای کاربر واضح‌تر باشد.

موبایل؛ جزئیات کوچک، مشکلات بزرگ

در یک اپلیکیشن موبایل، مشکلاتی مثل Keyboard، Safe Area، ارتفاع صفحه و رفتار Scroll می‌توانند تجربه یک فرم ساده را خراب کنند.

در طول توسعه حسابدار من، چند مورد از این جنس اصلاح شدند.

Keyboard بخشی از UI است

وقتی کاربر در حال وارد کردن مبلغ یا عنوان است، باز شدن Keyboard نباید دکمه اصلی را پنهان کند یا باعث شود بخشی از فرم غیرقابل دسترس شود.

این نوع مشکلات معمولاً در Mockup دیده نمی‌شوند و فقط در نسخه قابل اجرا مشخص می‌شوند.

به همین دلیل بخش مهمی از توسعه پروژه به تست واقعی Screenها و اصلاح رفتار آن‌ها اختصاص پیدا کرده است.

معماری فنی؛ محصولی که باید قابل گسترش باقی بماند

حسابدار من با React Native و Expo توسعه داده می‌شود.

برای مدیریت State از Zustand و برای ذخیره‌سازی محلی از SQLite استفاده شده است.

این ترکیب برای پروژه‌ای که باید روی موبایل سریع باشد و بدون وابستگی دائمی به سرور نیز بتواند بخش مهمی از اطلاعات را مدیریت کند، انتخاب مناسبی بود.

تغییر Schema بدون از دست رفتن داده

با اضافه شدن قابلیت‌های جدید، ساختار دیتابیس نیز تغییر کرده است.

ستون‌هایی مانند اطلاعات انتقال، ارتباط حساب‌ها و داده‌های جدید به مرور به Schema اضافه شدند.

Migrationها باید به شکلی انجام شوند که نسخه‌های قبلی اپ بتوانند بدون پاک شدن اطلاعات کاربر به ساختار جدید منتقل شوند.

برای همین بررسی Schema و استفاده از Migrationهای کنترل‌شده بخشی از توسعه پروژه است.

پروژه‌ای که هنوز در حال تکمیل است

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

برخی قابلیت‌ها در حال تکمیل‌اند و بخش‌های دیگری نیز در Roadmap قرار دارند.

از جمله توسعه بیشتر Shopping Lists، تکمیل برخی جریان‌های مالی، Attachments برای تراکنش‌ها و بهبودهای بصری و تجربه کاربری.

Dark Mode نیز یکی از قابلیت‌هایی است که برای مراحل بعدی در نظر گرفته شده است.

ساخت محصول به‌صورت مرحله‌ای

برای این پروژه، توسعه مرحله‌ای یک تصمیم آگاهانه است.

به‌جای اینکه تعداد زیادی Feature به‌صورت هم‌زمان اضافه شوند، هر بخش ابتدا باید به یک نسخه قابل اجرا برسد، تست شود و سپس توسعه پیدا کند.

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

نتیجه؛ ساخت یک ابزار مالی که باید هر روز قابل استفاده باشد

چالش اصلی حسابدار من ساخت یک صفحه زیبا برای نمایش موجودی نبود.

چالش این بود که محصول در استفاده روزمره خسته‌کننده نشود.

ثبت هزینه، انتقال پول، مدیریت حساب و برنامه‌ریزی خرید باید سریع و قابل فهم باقی بمانند.

همزمان، معماری داده باید به‌اندازه کافی دقیق باشد تا با اضافه شدن گزارش‌ها و قابلیت‌های آینده، نیاز به بازسازی کامل سیستم وجود نداشته باشد.

حسابدار من هنوز در حال تکمیل است، اما همین روند توسعه نشان داده که در محصولات شخصی، کیفیت تجربه در جزئیات کوچک شکل می‌گیرد.

چیزی که از این پروژه یاد گرفتیم

محصول مالی شخصی زمانی ارزشمند می‌شود که استفاده از آن از خود مدیریت مالی سخت‌تر نباشد.

ساده بودن نتیجه تصمیم‌های زیاد است

یک رابط ساده معمولاً پشت صحنه ساده‌ای ندارد.

برای اینکه کاربر فقط یک دکمه بزند، باید درباره ساختار داده، خطاها، حالت‌های مختلف، رفتار Keyboard، حذف اطلاعات، انتقال بین حساب‌ها و ده‌ها جزئیات دیگر تصمیم گرفته شود.

در حسابدار من، هدف این است که این پیچیدگی در پشت محصول باقی بماند.

کاربر باید فقط کاری را ببیند که در همان لحظه به آن نیاز دارد.

و با ادامه توسعه، همین اصل قرار است پایه تصمیم‌های بعدی محصول باقی بماند.

Project Snapshot

Project Personal Finance — حسابدار من

Type NaarCode Lab / Internal Product

Status In Development / Work in Progress

Scope Product Design · Mobile UX · Financial Workflows · Account Management · Transactions · Transfers · Shopping Lists · Local Data Architecture

Platform Mobile Application

Technology React Native · Expo · SQLite · Zustand

Current Direction Continued development, workflow refinement, new financial features, and UX improvements.