خروجی بررسی UX راهاندازی ساختمان و عضویت
روش مرجع
این خروجی طبق استاندارد بررسی UX صفحهبهصفحه تکمیل میشود.
وضعیت خروجی
| مورد | مقدار |
|---|---|
| وضعیت کل | در حال بررسی |
| محدوده فعال | Dashboard راهاندازی و واحدها |
| صفحه فعال | WF-08 |
| صفحه بعد | WF-09 |
| آخرین بازبینی | 2026-08-05 |
| منبع وایرفریم | وایرفریمهای ماژول |
برنامه بررسی
| نوبت | محدوده | شناسهها | وضعیت |
|---|---|---|---|
| ۱ | ورود و احراز هویت | WF-01 و WF-02 |
تکمیل |
| ۲ | مسیریابی کاربر | WF-03 |
تکمیل |
| ۳ | مشخصات ساختمان و اشتراک | WF-04 تا WF-06 |
مسیرهای اصلی تکمیل؛ Stateهای عمومی خطا باز |
| ۴ | Provisioning و Dashboard راهاندازی | WF-07 و WF-08 |
WF-08 تکمیل؛ WF-07 در انتظار |
| ۵ | واحدها و عضویت | WF-09 تا WF-16 |
در انتظار |
| ۶ | تیم مدیریت و کارکنان | WF-17 تا WF-20 |
در انتظار |
| ۷ | تنظیمات مالی و قبض | WF-21 تا WF-27 |
در انتظار |
| ۸ | امکانات ساکنان | WF-28 تا WF-31 |
تکمیل؛ Flow نهایی در Figma |
| ۹ | اطلاعات تکمیلی | WF-31A و WF-31B |
تکمیل؛ Flow نهایی در Figma |
| ۱۰ | تجربه دعوتشده | WF-32 و WF-33 |
در انتظار |
| ۱۱ | تغییر مدیر راهاندازی | WF-34 و WF-35 |
در انتظار |
یافتههای مشترک فعلی
| شناسه | یافته | اثر | وضعیت |
|---|---|---|---|
UX-F-01 |
اندازه مرجع نهایی UI برابر 402 × 874 px است؛ قاب 390 × 844 px فقط مرجع تاریخی وایرفریم باقی میماند. |
Review و تحویل UI بر مبنای 402 × 874 px انجام میشود. |
حلشده |
UX-F-02 |
مسیر ورود برای ورود، ثبتنام و پذیرش دعوت مشترک است. | متن صفحه نباید فقط یکی از این سه مسیر را القا کند. | قطعی |
UX-F-03 |
شماره موبایل تنها داده لازم در نقطه شروع است. | اطلاعات تکمیلی نباید پیش از شناسایی Context درخواست شوند. | قطعی |
UX-F-04 |
کاربر دارای عضویت فعال، دعوت در انتظار و کاربر جدید پس از OTP مسیرهای متفاوت دارند. | تصمیم Routing باید بعد از احراز هویت باشد. | قطعی |
UX-F-05 |
انتخاب دوره و بازبینی مبلغ نهایی در یک صفحه ادغام شدهاند. | کاربر پیش از درگاه، دوره، ریز محاسبات، مالیات، مبلغ نهایی و اختیار ثبت را در یک Context تأیید میکند. | قطعی |
UX-F-06 |
چکلیست راهاندازی از طریق کارت موقت در صفحه اصلی Current Building در دسترس است. | لمس تمام سطح کارت یا دکمه «ادامه راهاندازی»، WF-08 را باز میکند. کارت تا حلشدن هر پنج بخش نمایش داده و پس از تکمیل حذف میشود؛ دادهها در مدیریت ساختمان قابل ویرایش میمانند. |
قطعی |
SPLASH-01 — آغاز اپلیکیشن
| مورد | خروجی |
|---|---|
| وضعیت | نسخه ثابت نهایی؛ Motion در انتظار |
| Actor | کاربری که اپلیکیشن را اجرا میکند |
| هدف کاربر | دریافت بازخورد فوری از اجرای اپ و ورود روان به تجربه |
| نقطه ورود | اجرای اپلیکیشن |
| خروجی موفق در اولین تجربه | انتقال خودکار به INTRO-01 |
| Action اصلی | ندارد |
| Permission | عمومی |
| Frame فعلی | Splash |
نقش صفحه
اسپلش نقطه آغاز تجربه است و باید بدون درخواست اقدام از کاربر، هویت تریپیلون را نمایش دهد. در تجربه اول، پس از آمادهشدن اپ مستقیماً به Intro منتقل میشود.
جریان تأییدشده فعلی
اجرای اپ ← SPLASH-01 ← INTRO-01 ← WF-01
تصمیمهای ثبتشده
- نسخه فعلی Static است و انیمیشن در مرحله بعد طراحی میشود.
- صفحه هیچ CTA یا تعامل مستقیمی ندارد.
- انتقال به Intro خودکار است و نباید به لمس کاربر وابسته باشد.
- اسپلش نباید صرفاً برای تکمیل یک زمان ثابت، شروع تجربه را بیدلیل به تأخیر بیندازد.
- در نسخه Motion باید تنظیم Reduce Motion سیستمعامل رعایت شود.
سؤالات باز
- حداقل و حداکثر زمان نمایش اسپلش چقدر است؟
- کاربر دارای Session معتبر پس از اسپلش به کدام مقصد هدایت میشود؟
- Motion لوگو، نوع Transition و Easing چه مشخصاتی دارند؟
INTRO-01 — معرفی تریپیلون
| مورد | خروجی |
|---|---|
| وضعیت | نهایی و مستندشده |
| Actor | کاربری که Splash را دیده و هنوز وارد جریان احراز هویت نشده است |
| هدف کاربر | درک سریع کاربرد تریپیلون و شروع استفاده |
| نقطه ورود | پایان Splash در اولین تجربه ورود |
| خروجی موفق | انتقال به WF-01 |
| Action اصلی | شروع کنید |
| Action فرعی | ندارد |
| Permission | عمومی |
| خروجی Writing | بخش INTRO-01 |
| Frame اصلی | Intro |
| Frame اطلاعات | About Bottom Sheet |
مسئله و Context
این صفحه پس از Splash و پیش از درخواست شماره موبایل نمایش داده میشود. نمای اصلی باید ارزش محصول را در چند ثانیه منتقل کند؛ توضیح کاملتر درباره نام و قابلیتهای تریپیلون فقط با اقدام آگاهانه کاربر و از طریق آیکن اطلاعات در دسترس است.
ساختار و حالتها
| حالت | هدف | محتوای اصلی | اقدام |
|---|---|---|---|
| Default | معرفی سریع ارزش محصول | تصویر، لوگو، عنوان، توضیح کوتاه و CTA | «شروع کنید» یا آیکن اطلاعات |
| About Open | توضیح داستان نام و دامنه کاربرد | باتمشیت «درباره تریپیلون» روی پسزمینه محو و تیرهشده | مطالعه محتوا و بستن Sheet |
تعاملها
| محرک | نتیجه |
|---|---|
| لمس «شروع کنید» | انتقال به WF-01 برای ورود با شماره موبایل |
| لمس آیکن اطلاعات | بازشدن باتمشیت «درباره تریپیلون» |
| بازشدن باتمشیت | کاهش تمرکز بصری پسزمینه با Blur و Scrim و انتقال تمرکز به محتوا |
| محتوای بلند در ارتفاعهای کوتاهتر | اسکرول عمودی داخل باتمشیت بدون جابهجایی صفحه زیرین |
تصمیمهای ثبتشده
- نام برند در متن فارسی دقیقاً «تریپیلون» نوشته میشود.
- عنوان حداکثر دو خط و توضیح حداکثر دو خط در اندازه مرجع است.
- پیام روی سادگی و یکپارچگی مدیریت ساختمان تمرکز میکند.
- تصویر انسانی در فضای ساختمان، زمینه اصلی صفحه است و گرادیان تیره خوانایی متن پایین صفحه را حفظ میکند.
- آیکن اطلاعات حفظ میشود و دسترسی اختیاری به داستان نام و معرفی قابلیتها میدهد.
- ارتباط نام «تریپیلون» با «تالار شورا» و مفهوم گفتوگو و تصمیمگیری جمعی، داستان برند را شکل میدهد.
- CTA «شروع کنید» کاربر را به ورود با شماره موبایل میبرد.
- متن نهایی صفحه و باتمشیت در خروجی UX Writing ثبت شده است.
سؤالات باز
- صفحه فقط در اولین اجرای اپ نمایش داده شود یا پس از هر خروج از حساب؟
- بستن باتمشیت علاوه بر Swipe Down با لمس Scrim نیز انجام شود؟
WF-01 — ورود با شماره موبایل
| مورد | خروجی |
|---|---|
| وضعیت | مسیر اصلی نهایی؛ حالتهای خطا باز |
| Actor | کاربر جدید، عضو موجود یا دعوتشده |
| هدف کاربر | شروع امن و سریع ورود به تریپیلون |
| نقطه ورود | اجرای اپ بدون Session معتبر |
| خروجی موفق | ارسال کد تأیید و انتقال به WF-02 |
| Action اصلی | ارسال کد تأیید |
| Action فرعی | فعلاً ندارد |
| Permission | عمومی |
| خروجی Writing | بخش WF-01 |
| Frame پیشفرض | Default |
| Frame ورود شماره | Focused / Filled |
| Frame ارسال | Loading |
مسئله و Context
کاربر هنوز شناسایی نشده و سیستم نمیداند عضو ساختمان، دعوتشده یا متقاضی ایجاد ساختمان است. صفحه باید فقط شماره موبایل را دریافت کند و درباره مسیر بعدی وعده نادرست ندهد.
ساختار اطلاعات
- هویت بصری تریپیلون
- عنوان «ورود یا ثبتنام»
- توضیح کاربرد شماره موبایل
- فیلد شماره موبایل با Floating Label
- متن پذیرش شرایط استفاده و سیاست حریم خصوصی
- CTA «ارسال کد تأیید»
حالتها و رفتار نهایی
| حالت | رفتار | وضعیت |
|---|---|---|
| Default | فیلد خالی، Floating Label در موقعیت اولیه و CTA غیرفعال | نهایی |
| Focus | Label به بالای فیلد منتقل میشود، Border به رنگ Accent درمیآید و کیبورد عددی باز میشود | نهایی |
| Filled | شماره حفظ میشود و پس از معتبرشدن، CTA فعال است | نهایی |
| Keyboard Open | کل کارت بالای کیبورد Float میشود و تصویر پسزمینه ثابت میماند | نهایی |
| Loading | کیبورد بسته، شماره حفظ، ارسال تکراری مسدود و CTA با Spinner و «در حال ارسال کد» نمایش داده میشود | نهایی |
| Validation Error | شماره نامعتبر با پیام Inline و بدون حذف مقدار | طراحی نشده |
| Network Error | شماره حفظ و امکان تلاش دوباره نمایش داده میشود | طراحی نشده |
| Rate Limited | زمان یا امکان تلاش بعدی اعلام میشود | در انتظار Rule |
تصمیمهای ثبتشده
- شماره موبایل تنها ورودی این صفحه است.
- عنوان صفحه «ورود یا ثبتنام» است، چون این نقطه ورود بین کاربر جدید و موجود مشترک است.
- فیلد از الگوی Floating Label استفاده میکند و Label در حالت Filled بالا باقی میماند.
- اعداد فارسی و انگلیسی پذیرفته و پیش از ارسال Normalize میشوند.
- مقدار شماره با جهت
LTRنمایش داده میشود. - CTA تا معتبرشدن شماره غیرفعال است.
- کل کارت با بازشدن کیبورد Float میشود و با فاصله امن بالای آن قرار میگیرد.
- لمس خارج کارت، کیبورد را میبندد ولی مقدار شماره را پاک نمیکند.
- با شروع ارسال، کیبورد بسته میشود و شماره تا مشخصشدن نتیجه حفظ میشود.
- شرایط استفاده و سیاست حریم خصوصی پیش از CTA در دسترساند.
- تشخیص مسیر کاربر پیش از OTP نمایش داده نمیشود.
- ارسال موفق کاربر را به
WF-02منتقل میکند.
سؤالات باز
- محدودیت Rate Limit و زمان نمایش آن چیست؟
- رفتار و متن نهایی Validation Error و خطاهای ارسال چگونه در UI نمایش داده میشوند؟
WF-02 — ورود کد تأیید
| مورد | خروجی |
|---|---|
| وضعیت | نهایی و مستندشده |
| Actor | کاربری که شماره موبایل معتبر را در WF-01 ثبت کرده است |
| هدف کاربر | تأیید مالکیت شماره موبایل و ادامه ورود یا ثبتنام |
| نقطه ورود | ارسال موفق کد از WF-01 |
| خروجی موفق | تأیید کد و انتقال به WF-03 برای مسیریابی |
| Action اصلی | بررسی خودکار پس از ورود رقم ششم |
| Actionهای فرعی | ویرایش شماره موبایل، ارسال دوباره کد و تلاش دوباره برای Resend |
| Permission | عمومی |
| خروجی Writing | بخش WF-02 |
| Section نهایی | OTP Flow |
مسئله و Context
کاربر باید بدون Action اضافه، کد ششرقمی پیامکشده را وارد کند. صفحه باید شماره مقصد را قابل تشخیص نگه دارد، کد را پس از تکمیل خودکار بررسی کند و تفاوت میان «کد نامعتبر»، «کد منقضی» و «شکست ارسال مجدد» را روشن نشان دهد.
حالتها و رفتار نهایی
| حالت | رفتار | وضعیت |
|---|---|---|
| Focus / Empty | کارت بالای کیبورد Float، فیلد Focus و Countdown فعال است | نهایی |
| Verifying | پس از ورود رقم ششم، ورودی موقتاً قفل و «در حال بررسی کد» با Spinner نمایش داده میشود | نهایی |
| Invalid Code | فیلد و پیام Inline قرمز؛ مقدار کد برای اصلاح حفظ میشود | نهایی |
| Expired Code | پایان اعتبار کد مستقل از Countdown Resend اعلام و Action ارسال دوباره فعال میشود | نهایی |
| Resend Available | پس از پایان Countdown، Action «ارسال دوباره کد» نمایش داده میشود | نهایی |
| Resending | ارسال تکراری مسدود و «در حال ارسال دوباره» با Spinner نمایش داده میشود | نهایی |
| Resend Failed | پیام «کد ارسال نشد.» و Action «تلاش دوباره» نمایش داده میشود | نهایی |
| Resent | پیام گذرای «کد جدید ارسال شد.» اعلام و Countdown از ابتدا آغاز میشود | رفتار نهایی؛ Frame مستقل لازم نیست |
تصمیمهای ثبتشده
- کد تأیید ششرقمی است.
- فیلد از الگوی Floating Label استفاده میکند و یک ورودی منطقی واحد است.
- اعداد فارسی و انگلیسی و Paste کامل کد پذیرفته و پیش از بررسی Normalize میشوند.
- OTP AutoFill سیستمعامل پشتیبانی میشود.
- کد و شماره Maskشده با جهت
LTRنمایش داده میشوند. - الگوی Mask در UI برابر
۰۹۱۲****۰۸۰است. - با ورود رقم ششم، بررسی کد بدون CTA جداگانه آغاز میشود.
- کارت با بازشدن کیبورد Float میشود و روی Keyboard Insets واقعی قرار میگیرد.
- کنترل بازگشت، کاربر را برای ویرایش شماره به
WF-01میبرد. - تایمر Resend با رفتن اپ به پسزمینه از ابتدا شروع نمیشود.
- ارسال دوباره فقط با اقدام کاربر انجام میشود و خودکار نیست.
- شکست Resend از خطای اعتبار کد جداست؛ «تلاش دوباره» در این Context یک Action است.
- در موفقیت Resend، پیام گذرا برای Screen Reader نیز اعلام میشود.
سؤالات باز
- مدت دقیق اعتبار خود کد تأیید چقدر است؟
- پس از چند کد نامعتبر، Rate Limit یا قفل موقت اعمال میشود؟
- با ارسال کد جدید، کد قبلی بلافاصله باطل میشود یا تا پایان اعتبار معتبر میماند؟
WF-03 — شروع بدون عضویت و دعوت
| مورد | خروجی |
|---|---|
| وضعیت | نهایی و مستندشده |
| Actor | کاربر احرازشدهای که عضویت فعال و دعوت در انتظار ندارد |
| هدف کاربر | انتخاب میان ثبت ساختمان جدید و انتظار برای دریافت دعوت |
| نقطه ورود | تأیید موفق OTP و پایان بررسی عضویتها و دعوتها |
| خروجی موفق مسیر ثبت | انتقال به WF-04 و آغاز ثبت ساختمان جدید |
| خروجی مسیر دعوت | ماندن در همین Context و بررسی دوباره دعوتها |
| Actionهای اصلی | ثبت ساختمان جدید، بررسی دوباره دعوتها |
| Action فرعی | تغییر شماره موبایل و احراز دوباره آن |
| Permission | عمومی؛ هر کاربر احرازشده میتواند ثبت ساختمان را آغاز کند |
| خروجی Writing | بخش WF-03 |
| Section نهایی | No Invitation Flow |
مسئله و Context
پس از OTP، سامانه مطمئن شده است که شماره موبایل نه عضویت فعال و نه دعوت در انتظار دارد. کاربر باید بتواند بدون نیاز به تأیید ادمین، ثبت ساختمان جدید را آغاز کند یا درصورتیکه منتظر دعوت مدیر ساختمان است، وضعیت دعوت را با همان شماره بررسی کند.
این صفحه مقصد عمومی همه کاربران نیست. کاربر دارای عضویت فعال مستقیماً وارد Context معتبر میشود و میتواند بعداً از صفحه اصلی ساختمان دیگری ثبت کند. دعوت موجود نیز پیش از گزینه ثبت ساختمان به مسیر متناسب با نوع دعوت هدایت میشود.
ساختار اطلاعات
- هویت بصری تریپیلون
- راهنمای انتخاب مسیر شروع
- کارت اصلی «ثبت ساختمان جدید»
- کارت ثانویه «منتظر دعوت هستم»
- Bottom Sheet راهنمای پیدانکردن دعوت
- شماره موبایل Maskشده، بررسی دوباره و تغییر شماره موبایل
حالتها و رفتار نهایی
| حالت | رفتار | وضعیت |
|---|---|---|
| No Membership / No Invitation | دو مسیر «ثبت ساختمان جدید» و «منتظر دعوت هستم» نمایش داده میشوند | نهایی |
| Help Sheet Open | پسزمینه با Blur و Scrim غیرفعال و توضیح شماره مبنای دعوت نمایش داده میشود | نهایی |
| Checking | درخواست تکراری مسدود و CTA با Spinner و «در حال بررسی» نمایش داده میشود | نهایی |
| Empty Result | پیام خنثی «دعوت جدیدی برای این شماره پیدا نشد.» داخل Sheet نمایش داده میشود | نهایی |
| Network Error | پیام Inline بازیابیپذیر و CTA «تلاش دوباره» نمایش داده میشود | نهایی |
| Invitation Found | Sheet بسته و کاربر براساس نوع و تعداد دعوتها به Context یا مسیر بررسی دعوت هدایت میشود | رفتار نهایی؛ Frame مستقل ندارد |
| Change Mobile | درخواست جاری لغو و کاربر برای ورود و تأیید شماره دیگر به WF-01 بازگردانده میشود |
نهایی |
تصمیمهای ثبتشده
- ثبت ساختمان Self-service است و همه کاربران احرازشده میتوانند آن را آغاز کنند.
- ایجاد ساختمان به تأیید ادمین پلتفرم نیاز ندارد؛ ایجاد نهایی پس از پرداخت معتبر انجام میشود.
- این صفحه فقط برای وضعیت همزمان «بدون عضویت فعال» و «بدون دعوت در انتظار» نمایش داده میشود.
- کارت ثبت ساختمان مسیر اصلی و کارت انتظار دعوت مسیر ثانویه است.
- بررسی دعوت در همان Bottom Sheet انجام میشود و نتیجه خالی یا خطای شبکه کاربر را به صفحه دیگری نمیبرد.
- نتیجه خالی Error نیست و با رنگ خنثی نمایش داده میشود؛ خطای شبکه Feedback بازیابیپذیر دارد.
- شماره موبایل Maskشده با جهت
LTRنمایش داده میشود. - هنگام Checking فقط یک درخواست فعال است و Action تکراری پذیرفته نمیشود.
- تغییر شماره موبایل به معنی بازگشت به احراز هویت است؛ درخواست بررسی جاری باید لغو شود.
- اگر دعوت پیدا شود، Context فعلی بهصورت ناگهانی تغییر نمیکند و Routing براساس نوع دعوت انجام میشود.
- رابطه عادی مالک، مستأجر یا ساکن صفحه پذیرش یا رد عضویت ندارد؛ Role حساس به تصمیم مستقل کاربر هدایت میشود.
- Bottom Sheet با کنترل بستن، Swipe Down و لمس Scrim بسته میشود و Focus هنگام بازشدن به آن منتقل میشود.
موارد خارج از این خروجی
- نمایش و تصمیم درباره Roleهای حساس در
WF-32وWF-33 - انتخاب میان چند ساختمان فعال در Context Switcher صفحه اصلی
- ثبت مشخصات و خرید اشتراک ساختمان از
WF-04به بعد
WF-04 — ثبت مشخصات پایه ساختمان
| مورد | خروجی |
|---|---|
| وضعیت | مسیر اصلی نهایی؛ حالتهای Validation و خطای ذخیره باز |
| Actor | متقاضی راهاندازی ساختمان |
| هدف کاربر | ثبت نام ساختمان و تعداد تجمیعی واحدها برای محاسبه قیمت اشتراک |
| نقطه ورود | انتخاب «ثبت ساختمان جدید» در WF-03 یا انتخاب همین Action از صفحه اصلی |
| خروجی موفق | ذخیره اطلاعات معتبر درخواست و انتقال به WF-05 برای مشاهده قیمت |
| Action اصلی | مشاهده قیمت |
| Action فرعی | بازگشت به مبدأ شروع ثبت ساختمان |
| Permission | هر کاربر احرازشده |
| سناریوی مرجع | SET-02 و BR-SET-01 تا BR-SET-01B |
| خروجی Writing | بخش WF-04 |
| Section نهایی | Basic Information |
مسئله و Context
کاربر در اولین مرحله از فرایند دومرحلهای ثبت ساختمان قرار دارد. این مرحله باید فقط دادههای ضروری قیمتگذاری را دریافت کند و کاربر را با آدرس، بلوک، طبقه، امکانات یا ساختار تفصیلی درگیر نکند. ثبت این فرم ساختمان فعال ایجاد نمیکند؛ اطلاعات در درخواست راهاندازی ذخیره و برای محاسبه قیمت استفاده میشوند.
ساختار اطلاعات
- App Bar با عنوان «مشخصات پایه»، کنترل بازگشت و نشانگر «مرحله ۱ از ۲»
- آیکن ساختمان، عنوان انسانی صفحه و توضیح کوتاه
- فیلد نام ساختمان
- بخش تعداد واحدها و توضیح مبنای محاسبه قیمت
- گروه واحدهای مسکونی، تجاری و اداری با ورودی عددی مستقل
- خلاصه مجموع واحدها و حداقل لازم برای خرید آنلاین
- CTA «مشاهده قیمت»
حالتها و رفتار
| حالت | رفتار | وضعیت |
|---|---|---|
| Filled / Valid | نام ساختمان و تعداد معتبر وارد شده، مجموع بهروز و CTA فعال است | نهایی |
| Empty Name | ادامه مسیر مسدود و خطای همان فیلد نمایش داده میشود | طراحی نشده |
| Invalid Unit Count | فیلد منفی، اعشاری یا غیرعددی مشخص و ادامه مسیر مسدود میشود | طراحی نشده |
| Total Below Minimum | مجموع کمتر از ۲ بهصورت Inline اعلام و CTA غیرفعال میماند | طراحی نشده |
| Saving / Pricing | ورودی و CTA تکراری موقتاً قفل و وضعیت «در حال محاسبه قیمت» نمایش داده میشود | طراحی نشده |
| Save Failed | مقادیر حفظ و امکان تلاش دوباره بدون ایجاد درخواست تکراری نمایش داده میشود | طراحی نشده |
| Return With Draft | آخرین اطلاعات ذخیرهشده نمایش و قیمت بعدی با آخرین تعداد معتبر محاسبه میشود | رفتار قطعی؛ Frame مستقل ندارد |
تصمیمهای ثبتشده
- «مرحله ۱ از ۲» وضعیت اطلاعاتی است و با سطح کمرنگ نمایش داده میشود؛ ظاهر دکمه یا Progress Bar جداگانه ندارد.
- نام ساختمان و تعداد واحدهای مسکونی، تجاری و اداری تنها ورودیهای این مرحلهاند.
- آدرس، بلوک، طبقه و ساختار تفصیلی بعد از فعالشدن ساختمان تکمیل میشوند.
- هر نوع واحد میتواند مقدار صفر داشته باشد.
- تعداد واحد فقط عدد صحیح نامنفی است و سقف ندارد.
- مجموع سه نوع واحد بهصورت زنده محاسبه و نمایش داده میشود.
- مجموع معتبر برای ادامه حداقل ۲ واحد است.
- تعرفه هر سه نوع واحد در نسخه فعلی برابر است.
- شباهت یا تکراریبودن نام ساختمان مانع ادامه مسیر نیست.
- CTA فقط با نام غیرخالی، مقادیر معتبر و مجموع حداقل ۲ فعال میشود.
- اعداد فارسی و انگلیسی پذیرفته و پیش از ذخیره Normalize میشوند.
- کیبورد ورودی تعداد واحدها عددی است و فیلد Focusشده باید با بازشدن کیبورد قابل مشاهده بماند.
- بازگشت پیش از پرداخت اطلاعات ذخیرهشده را از بین نمیبرد.
- اگر کاربر عضو از صفحه اصلی این مسیر را آغاز کند، Current Context ساختمان فعلی او تغییر نمیکند.
- «مشاهده قیمت» ابتدا اطلاعات معتبر را ذخیره و سپس کاربر را وارد مرحله قیمتگذاری میکند.
سؤالات باز
- حداکثر طول نام ساختمان و کاراکترهای مجاز چیست؟
- ذخیره Draft در هر تغییر انجام میشود یا فقط با Action «مشاهده قیمت»؟
- متن و نمایش نهایی حالت Saving و خطای ذخیره چگونه باشد؟
WF-05 — انتخاب و پرداخت اشتراک
| مورد | خروجی |
|---|---|
| وضعیت | مسیر اصلی نهایی؛ Stateهای Loading و Error باز |
| Actor | متقاضی راهاندازی ساختمان |
| هدف کاربر | انتخاب دوره، بازبینی مبلغ نهایی و انجام پرداخت |
| نقطه ورود | تکمیل موفق WF-04 |
| خروجی موفق | ثبت Quote و اختیار، سپس انتقال به درگاه پرداخت |
| Action اصلی | پرداخت و راهاندازی |
| Action فرعی | ویرایش مشخصات؛ بازگشت |
| Permission | هر کاربر احرازشده دارای Setup Request معتبر |
| سناریوی مرجع | SET-03، SET-04، BR-SET-02B و BR-PAY-01 |
| خروجی Writing | بخش WF-05 |
| Section نهایی | Setup Payment Flow |
ساختار اطلاعات
- App Bar با عنوان «انتخاب اشتراک»، بازگشت و نشانگر «مرحله ۲ از ۲»
- کارت خلاصه ساختمان با نام، تعداد واحد محاسبهشده و Action ویرایش
- گروه انتخاب دوره سهماهه یا دوازدهماهه
- نشان «یک ماه رایگان» و توضیح «۱۲ ماه خدمت با هزینه ۱۱ ماه» برای دوره سالانه
- رسید محاسبات با ردیفهای اشتراک، تخفیف دوره در صورت اعمال، شارژ اولیه پیامک، مالیات و مبلغ نهایی
- تأیید Self-Declaration برای اختیار ثبت و مسئولیت اطلاعات
- CTA «پرداخت و راهاندازی»
رفتار و قواعد
- تغییر دوره، همه ردیفهای رسید و مبلغ قابل پرداخت را فوری بهروز میکند.
- قیمت هر دو دوره باید پیش از انتخاب قابل مقایسه باشد.
- مبلغهای UI از Quote معتبر سرور میآیند؛ مقدارهای نمونه Figma قرارداد محاسباتی نیستند.
- دوره دوازدهماهه ۱۲ ماه خدمت با هزینه ۱۱ ماه دارد.
- مالیات و عوارض فقط بر مبلغ اشتراک پس از تخفیف محاسبه میشود؛ شارژ اولیه پیامک مشمول مالیات نیست.
- CTA تا انتخاب دوره، دریافت Quote معتبر و تأیید Self-Declaration غیرفعال است.
- ویرایش مشخصات کاربر را با حفظ Draft به
WF-04میبرد و Quote قبلی پس از تغییر داده نامعتبر میشود. - ارسال پرداخت تکراری تا مشخصشدن نتیجه Request قبلی مسدود است.
حالتهای باقیمانده
| حالت | وضعیت |
|---|---|
| Loading Quote | طراحی نشده |
| Quote Failed | طراحی نشده |
| Stale Quote | رفتار قطعی؛ Frame طراحی نشده |
| Payment Starting | طراحی نشده |
| Self-Declaration Unchecked | رفتار قطعی؛ نمونه Disabled باز |
WF-06 — وضعیت پرداخت
| مورد | خروجی |
|---|---|
| وضعیت | چهار State اصلی نهایی |
| Actor | متقاضی پرداختکننده |
| هدف کاربر | دریافت نتیجه قطعی پرداخت بدون خطر پرداخت یا ساختمان تکراری |
| نقطه ورود | بازگشت از درگاه یا نتیجه نامشخص Callback |
| خروجی موفق | ورود به Dashboard فقط پس از تأیید پرداخت و تکمیل Provisioning |
| Action اصلی | وابسته به State؛ بهروزرسانی وضعیت، ورود به داشبورد یا پرداخت و راهاندازی |
| Permission | مالک Payment Attempt و Setup Request |
| سناریوی مرجع | SET-04، ALT-SET-04B، ALT-SET-04C، ERR-SET-15 |
| خروجی Writing | بخش WF-06 |
| Section نهایی | Payment Flow |
ساختار مشترک
- App Bar غیرتعاملی «وضعیت پرداخت» بدون کنترل بازگشت
- آیکن، عنوان و توضیح State
- کارت اطلاعات شامل ساختمان، مبلغ و شناسه پیگیری قابل کپی
- پیام ایمنی در State نامشخص
- Action متناسب با State در پایین صفحه
Stateهای نهایی
| State | محتوا | Action | رفتار |
|---|---|---|---|
| Pending / Auto Check | «در حال بررسی پرداخت» | ندارد | Polling خودکار؛ Action تکراری مسدود |
| Pending / Delayed | نتیجه پس از مهلت معمول هنوز قطعی نیست | «بهروزرسانی وضعیت» | بررسی دستی بهعنوان Fallback؛ نه مسیر اصلی |
| Success / Ready | «پرداخت با موفقیت انجام شد» و «همهچیز برای شروع آماده است.» | «ورود به داشبورد» | فقط بعد از تأیید پرداخت و تکمیل Provisioning |
| Failed / Definitive | «تراکنش ناموفق بود» | «پرداخت و راهاندازی» | ایجاد Payment Attempt جدید فقط پس از نتیجه ناموفق قطعی |
رفتار و ایمنی
- در Pending نتیجه موفق یا ناموفق حدس زده نمیشود.
- درخواستهای Polling و بهروزرسانی Idempotent هستند و وجه یا ساختمان تکراری ایجاد نمیکنند.
- دکمه بهروزرسانی فقط پس از طولانیشدن بررسی یا خطای موقت قابل دسترس است.
- مبلغ، ساختمان و شناسه پیگیری در همه Stateها ثابت و مطابق Payment Attempt هستند.
- کپی شناسه پیگیری با پیام «شناسه پیگیری کپی شد» تأیید میشود.
- تغییر State برای Screen Reader در Live Region مناسب اعلام میشود.
HOME-SETUP-01 — ورودی راهاندازی در صفحه اصلی
| مورد | خروجی |
|---|---|
| وضعیت | مسیر اصلی نهایی و مستندشده |
| Actor | مدیر راهاندازی ساختمان |
| هدف کاربر | مشاهده سریع پیشرفت و ادامه راهاندازی از صفحه اصلی Current Building |
| نقطه ورود | ورود به صفحه اصلی پس از فعالشدن ساختمان |
| خروجی موفق | بازشدن WF-08 برای همان Current Building |
| Action اصلی | ادامه راهاندازی |
| Action جایگزین | لمس تمام سطح کارت |
| Permission | مدیر راهاندازی یا Role مجاز مدیریت ساختمان |
| خروجی Writing | بخش HOME-SETUP-01 |
| Frame نهایی | HomePage |
ساختار اطلاعات
- Context Switcher با Role و نام Current Building
- کارت موقت راهاندازی با عنوان و آیکن هدف
- Progress Bar و شمارنده بخشهای تکمیلشده
- CTA تمامعرض «ادامه راهاندازی»
رفتار و قواعد
- Context Switcher در Frame با الگوی «مدیر راهاندازی | ساختمان فراز» نمایش داده شده و هر دو مقدار Dynamic هستند.
- شمارنده با الگوی «
{resolvedCount}بخش از ۵ بخش تکمیل شده» نمایش داده میشود. - مقدار Progress Bar برابر
{resolvedCount} / 5است؛ نمونه یک بخش تعیین تکلیف شده، مقدار۲۰٪دارد. - لمس کارت یا CTA مقصد یکسان
WF-08دارد و Current Building را تغییر نمیدهد. - کارت تا زمانی نمایش داده میشود که حداقل یک بخش حلنشده باقی مانده باشد.
- پس از حلشدن هر پنج بخش، کارت بدون نمایش State کامل از صفحه اصلی حذف و داشبورد ساختمان باز میشود.
- ورودی ثانویه در مدیریت ساختمان بعد از حذف کارت باقی میماند.
- حداقل ارتفاع CTA و سایر کنترلها
44 pxاست؛ CTA نهایی Frame ارتفاع54 pxدارد. - Progress Bar برای Screen Reader با متن شمارنده و درصد قابلدسترسی اعلام میشود.
WF-08 — Dashboard راهاندازی
| مورد | خروجی |
|---|---|
| وضعیت | مسیر اصلی نهایی و مستندشده |
| Actor | مدیر راهاندازی ساختمان |
| هدف کاربر | مشاهده وضعیت پنج بخش و ادامه تکمیل اطلاعات با ترتیب دلخواه |
| نقطه ورود | کارت موقت راهاندازی در صفحه اصلی یا ورودی ثانویه مدیریت ساختمان |
| خروجی موفق | ورود به یکی از بخشهای WF-09، WF-17، WF-21، WF-28 یا WF-31A |
| پایان قابل قبول | بازگشت به صفحه اصلی و ادامه در مراجعه بعدی بدون ازدسترفتن Draft |
| Action اصلی | انتخاب یکی از پنج ردیف راهاندازی |
| Permission | مدیر راهاندازی یا Role مجاز مدیریت ساختمان |
| خروجی Writing | بخش WF-08 |
| Frame نهایی | building information progress |
ساختار اطلاعات
- App Bar با عنوان «تکمیل راهاندازی» و Action بازگشت
- تصویر و نام Current Building
- راهنمای «بخشها را با هر ترتیبی که میخواهید تکمیل کنید.»
- Progress Bar و شمارنده بخشهای تکمیلشده
- فهرست پنج بخش با آیکن، عنوان، توضیح و Label وضعیت
- پیام غیرمسدودکننده ادامه در آینده
بخشها و مقصدها
| بخش | محتوای خلاصه | مقصد |
|---|---|---|
| واحدها و ساکنان | ثبت فهرست واحدها و ارتباط افراد | WF-09 |
| تیم ساختمان | انتخاب مسئولیتها و تعیین افراد | WF-17 |
| تنظیمات مالی و شارژ | محاسبه شارژ، قبضها و حساب ساختمان | WF-21 |
| امکانات ساکنان | ثبت امکانات و ایجاد هزینه رزرو | WF-28 |
| اطلاعات تکمیلی | ثبت آدرس و انتخاب تصویر | WF-31A |
وضعیت و پیشرفت
- شمارنده کلی بر اساس تعداد بخشهای حلشده است و با الگوی «
{resolvedCount}بخش از ۵ بخش تکمیل شده» نمایش داده میشود. - بخش
COMPLETEDبا Label «تکمیل شده» نمایش داده میشود. - بخش
IN_PROGRESSبا Label «در حال تکمیل{percent}٪» نمایش داده میشود. - بخش
NOT_STARTEDبا Label «تکمیل نشده» و بدون درصد صفر نمایش داده میشود. - درصد بخش فعال مستقل از نسبت پیشرفت کلی پنج بخش است.
- وضعیت هر بخش علاوه بر رنگ، با متن صریح اعلام میشود.
رفتار و دسترسپذیری
- ترتیب بخشها پیشنهادی است و هیچ ردیفی به تکمیل ردیف قبلی وابسته نیست.
- تمام سطح هر ردیف محدوده لمس ورود به بخش است؛ عنوان بخش نام دسترسپذیر Action محسوب میشود.
- Action بازگشت کاربر را به صفحه اصلی Current Building برمیگرداند و Draftهای ذخیرهشده حفظ میشوند.
- نام ساختمان داده پویا است و نباید به «ساختمان فراز» Hard-code شود.
- Progress Bar برای Screen Reader با مقدار متنی شمارنده کلی اعلام میشود.
- پیام پایین صفحه Informational است و نباید بهصورت Warning یا مانع ادامه برداشت شود.
- حداقل محدوده لمس کنترلها
44 × 44 pxاست.
بررسی سه Flow راهاندازی تکمیلی
واحدها و ساکنان
- Empty State و دو Action «افزودن واحد» و «ورود از اکسل» روشناند.
- وضعیت سکونت Segmented Control «دارای ساکن / بدون ساکن» است، نه Switch. واحد بدون ساکن میتواند مالک داشته باشد.
- «رابطه با واحد» از «نقش در اپ» جداست و ارسال دعوت Side Effect اختیاری ثبت دستی است.
- Import بدون موبایل مجاز است و Warning میدهد؛ دعوت فقط برای شخص دارای موبایل انجام میشود.
تیم ساختمان
- ادغام مدیریت، هیئتمدیره و کارکنان، Dashboard را سادهتر میکند.
- انتخاب مسئولیت و تعیین افراد دو مرحله جدا میمانند.
BUILDING_ADMINاجباری و قفلشده است؛ دسترسی پیشفرض فقط توضیح داده میشود و Onboarding محل ویرایش Permission نیست.- جستوجو و ثبت شخص جدید در یک Context درست است، مشروط به تشخیص موبایل تکراری.
- Cardinality در CTA صریح است: «تأیید مسئول» برای یک نفر و «تأیید اعضا» برای چند نفر.
برنامه شارژ و حساب
- دو مسیر «شروع سریع» و «محاسبه دقیق» هر دو به Preview شفاف ختم میشوند.
- شروع سریع سه روش «یکسان، گروهی، واحدبهواحد» دارد. گروه و استثنای واحدی Actionهای جدا هستند.
- زمان صدور و مهلت پرداخت مشخصه برنامهاند و در هر گروه تکرار نمیشوند.
- هر ردیف محاسبه دقیق یک مبنا دارد؛ ترکیب چند مبنا فقط با فرمول و وزن صریح معتبر است.
- آب قبض جداگانه و مبتنی بر Snapshot نفرات دوره است؛ سیاست واحد خالی باید در Preview دیده شود.
- «چرا این مبلغ؟» ورودی، قاعده، تاریخ اثر و گردکردن را توضیح میدهد و نقطه تمایز محصول است.
- همه مبالغ UI با توماناند و عنوان Sheet صحیح «افزودن قبض یا هزینه متغیر» است.
- ذخیره برنامه Publish نیست؛ موفقیت به صفحه اصلی و شکست به Draft قابل Retry ختم میشود.
WF-28 تا WF-31 — امکانات ساکنان
| مورد | خروجی |
|---|---|
| وضعیت | نهایی و آماده تحویل |
| Actor | مدیر راهاندازی ساختمان |
| هدف | ثبت سریع Facilityهای قابل رزرو و حداقل قواعد فعالسازی |
| نقطه ورود | ردیف «امکانات ساکنان» در WF-08 |
| خروجی موفق | نبود امکانات رزروپذیر ثبت شده یا حداقل یک Facility فعال است |
| پایان قابل قبول | Draft حفظ و ادامه از داشبورد در مراجعه بعدی |
| منبع طراحی | امکانات ساختمان در Figma |
ساختار نهایی Flow
- ورودی از صفحه اصلی و Setup Dashboard
- تصمیم وجود یا نبود امکانات قابل رزرو
- انتخاب از کاتالوگ یا افزودن امکان سفارشی
- انتخاب مدل رزرو: ساعتی، سانس ثابت یا روز کامل
- نمایش تنظیمات کوتاه و شرطی همان مدل
- تعیین رایگان/پولی، مبلغ و تأیید رزرو
- بازبینی خلاصه و فعالسازی
- بازگشت به Setup Dashboard یا افزودن Facility دیگر
تصمیمهای UX
- «استفاده آزاد» در Setup اولیه نمایش داده نمیشود؛ این Flow فقط برای منابع قابل رزرو است.
- ساعتی، سانسی و روز کامل سه مدل مستقلاند و فرم یکسان ندارند.
- مدل روز کامل ساعت قابل انتخاب به ساکن نمیدهد و کل تاریخ را برای آمادهسازی، استفاده و نظافت مسدود میکند.
- مدل سانسی حداقل یک ردیف شروع/پایان و Action افزودن سانس دارد.
- مدل ساعتی بازه ساعت قابل رزرو و مدت/گام رزرو را دریافت میکند.
- مبلغ با «تومان» نمایش داده میشود و واحد قیمت از مدل رزرو تبعیت میکند.
- تنظیمات پیشرفته با پیام Informational به داشبورد بعد از Setup موکول شدهاند.
- تجهیزات و زیرساختها از کاتالوگ این Flow حذف شدهاند.
Stateهای تحویل
| State | رفتار |
|---|---|
| No Facility | ماژول رزرو فعال نمیشود و بخش NOT_APPLICABLE حلشده است |
| Catalog Default | CTA تا انتخاب حداقل یک امکان غیرفعال است |
| Custom Facility | نام معتبر لازم است و مورد به انتخابها افزوده میشود |
| Incomplete Rules | Facility در Draft میماند و فیلد مرتبط خطا میگیرد |
| Review | نام امکان، مدل رزرو، زمان، قیمت و تأیید بهصورت خلاصه دیده میشوند |
| Active | Facility در فهرست خلاصه فعال نمایش داده میشود |
| Save Failed | دادهها حفظ و Retry امن نمایش داده میشود |
WF-31A و WF-31B — اطلاعات تکمیلی
| مورد | خروجی |
|---|---|
| وضعیت | نهایی و آماده تحویل |
| Actor | مدیر راهاندازی ساختمان |
| هدف | ثبت اختیاری نشانی و تصویر و پایان Setup اولیه |
| نقطه ورود | ردیف «اطلاعات تکمیلی» در WF-08 |
| خروجی موفق | تصمیم دو مرحله ذخیره و بخش حلشده است |
| منبع طراحی | اطلاعات تکمیلی در Figma |
مرحله ۱ از ۲ — نشانی
- عنوان صفحه از نام Current Building ساخته میشود: «ساختمان
{buildingName}کجاست؟» - استان، شهر، نشانی کامل، پلاک و کد پستی دریافت میشوند.
- پیام «پر کردن این بخش اجباری نیست» باید قبل از CTA و با ظاهر Informational نمایش داده شود.
- خالیبودن فیلدها مانع ادامه نیست؛ داده واردشده نامعتبر مانع ذخیره همان مرحله است.
مرحله ۲ از ۲ — تصویر ساختمان
- کاربر میتواند تصویر
jpg،pngیاwebpتا سقف۲ MBبارگذاری کند. - Divider «یا» مسیر بارگذاری را از انتخاب آواتارهای آماده جدا میکند.
- انتخاب فایل و انتخاب آواتار دو مسیر جایگزیناند؛ آخرین انتخاب معتبر Preview میشود.
- بدون انتخاب تصویر، Fallback سیستم حفظ و Flow قابل تکمیل است.
پایان راهاندازی
- تأیید مرحله دوم، وضعیت «اطلاعات تکمیلی» را حلشده میکند.
- اگر هر پنج بخش حل شده باشند، کارت موقت راهاندازی حذف و داشبورد ساختمان باز میشود.
- Setup کامل مانع ویرایش بعدی نیست؛ آدرس، تصویر و Facilityها از داشبورد قابل ویرایشاند.
- پایان Signup/Setup باید با وضعیت ذخیرهشده و بدون وابستگی به حضور تصویر یا آدرس اختیاری رخ دهد.
Decision Log
| تاریخ | تصمیم | صفحات متأثر | وضعیت |
|---|---|---|---|
2026-07-30 |
بررسی از WF-01 و سپس WF-02 آغاز میشود. |
ورود و OTP | قطعی |
2026-07-30 |
راهنماهای روش کار در scenario-guides و خروجیها در پوشه ماژول نگهداری میشوند. |
همه صفحات | قطعی |
2026-07-30 |
نسخه ثابت Splash پیش از Intro قرار میگیرد و Motion آن در مرحله بعد طراحی میشود. | SPLASH-01 و INTRO-01 |
قطعی |
2026-07-30 |
صفحه Intro با تصویر انسانی، آیکن اطلاعات، CTA و باتمشیت معرفی نام و قابلیتها نهایی شد. | INTRO-01 |
قطعی |
2026-07-30 |
مسیر اصلی ورود شماره موبایل با حالتهای Default، Focus/Filled، Keyboard Open و Loading نهایی شد. | WF-01 |
قطعی |
2026-07-30 |
اندازه مرجع UI محصول 402 × 874 px است. |
همه صفحههای موبایل | قطعی |
2026-07-30 |
Yekan Bakh فونت نهایی رابط فارسی محصول است. | همه صفحههای فارسی | قطعی |
2026-07-30 |
Componentها و Tokenها بر مبنای Design System اختصاصی تریپیلون ساخته میشوند. | همه ماژولها | قطعی |
2026-07-30 |
Dark Mode در فاز بعد طراحی میشود و جزو محدوده فعلی نیست. | همه صفحهها | قطعی |
2026-07-31 |
فلوی OTP با بررسی خودکار، خطا، انقضا و Resend در Section واحد Figma نهایی شد. | WF-02 |
قطعی |
2026-07-31 |
مسیر کاربر بدون عضویت و دعوت با ثبت ساختمان، راهنمای انتظار دعوت و حالتهای بررسی مجدد نهایی شد. | WF-03 |
قطعی |
2026-07-31 |
مسیر اصلی ثبت مشخصات پایه با نشانگر مرحله، گروه یکپارچه واحدها، مجموع زنده و CTA مشاهده قیمت نهایی شد. | WF-04 |
قطعی |
2026-07-31 |
انتخاب دوره و بازبینی پرداخت در مرحله ۲ از ۲ ادغام و با کارت ساختمان، رسید مالی، Self-Declaration و CTA پرداخت نهایی شد. | WF-05 |
قطعی |
2026-08-01 |
مالیات فقط بر مبلغ اشتراک پس از تخفیف محاسبه و شارژ اولیه پیامک از پایه مالیات خارج شد. | WF-05، SET-04 |
قطعی |
2026-08-01 |
وضعیت پرداخت با بررسی خودکار، Fallback دستی، موفقیت آماده و شکست قطعی نهایی شد. | WF-06 |
قطعی |
2026-08-05 |
ورودی چکلیست راهاندازی بهصورت کارت موقت در صفحه اصلی قرار میگیرد و پس از تکمیل بخشها حذف میشود. | HOME-SETUP-01، WF-08 |
قطعی |
2026-08-05 |
Dashboard راهاندازی با ردیفهای مستقل، شمارنده بخشهای تکمیلشده، وضعیت متنی هر بخش و پیام ادامه در آینده نهایی شد. | WF-08 |
قطعی |
2026-08-05 |
کارت موقت صفحه اصلی با Context Switcher، پیشرفت یکپارچه و CTA ادامه راهاندازی نهایی شد. | HOME-SETUP-01 |
قطعی |
2026-08-14 |
تیم مدیریت و کارکنان در «تیم ساختمان» ادغام و ویرایش دسترسی از Onboarding حذف شد. | WF-08، WF-17 تا WF-20 |
قطعی |
2026-08-14 |
تیم مدیریت و کارکنان در یک بخش «تیم ساختمان» ادغام شدند. | HOME-SETUP-01، WF-08 |
قطعی |
2026-08-22 |
«امکانات ساکنان» و «اطلاعات تکمیلی» مستقل شدند؛ Dashboard پنج بخش و مخرج پیشرفت ۵ دارد. | HOME-SETUP-01، WF-08، WF-28 تا WF-31B |
قطعی |
2026-09-12 |
تب جابهجایی بین مشخصات واحد و افراد وضوح کافی نداشت؛ ثبت دستی به Flow تمامصفحه دومرحلهای تبدیل شد. | WF-09 تا WF-16 |
قطعی |
2026-09-12 |
مساحت و تعداد ساکنان به اطلاعات اصلی واحد افزوده شدند؛ سایر مشخصات، قبض و حیوان خانگی به زیرفرایندهای اختیاری منتقل شدند. | WF-09 تا WF-16 |
قطعی |
2026-09-12 |
رابطه فرد میتواند مالکیت/اجاره را همزمان با سکونت نگه دارد و نقش پیشنهادی اپ از فرم حذف شد. | WF-09 تا WF-16 |
قطعی |
2026-08-14 |
تنظیمات مالی به برنامه پنجمرحلهای شارژ، قبض متغیر، بازبینی شفاف و حساب ساختمان توسعه یافت. | WF-21 تا WF-27 |
قطعی |