https://virgool.io/feed/@mohammadgholami fa 2026-07-06 06:03:13 https://files.virgool.io/upload/users/3951446/avatar/nB3fQs.jpg?height=120&width=120 https://virgool.io/@mohammadgholami https://virgool.io/@mohammadgholami/%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%AC%D8%B3%D8%AA-%D9%88%D8%AC%D9%88-%D8%AF%D8%B1-%D9%85%D8%AD%D8%B5%D9%88%D9%84%D8%A7%D8%AA-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86%DB%8C-%D9%81%D8%B1%D8%A7%D8%AA%D8%B1-%D8%A7%D8%B2-%DB%8C%DA%A9-%DA%A9%D8%A7%D8%AF%D8%B1-%D8%AC%D8%B3%D8%AA-%D9%88%D8%AC%D9%88-%D8%A7%D8%B3%D8%AA-vcrmjfjarbos طراحی تجربه پیدا کردن اطلاعات در سیستم‌های پیچیدهوقتی از Search حرف می‌زنیم، معمولاً یک تصویر ساده در ذهنمان داریم: یک کادر جست‌وجو، چند کلمه، یک دکمه، و فهرستی از نتایج.اما در محصولات سازمانی یا Enterprise Products، جست‌وجو به همین سادگی نیست. اینجا Search فقط یک قابلیت کوچک در رابط کاربری نیست؛ بخشی از تجربه تصمیم‌گیری کاربر است.کاربر سازمانی معمولاً فقط نمی‌خواهد «چیزی را پیدا کند». او می‌خواهد مطمئن شود چیزی را از دست نداده، نتیجه‌ای که دیده درست است، منبع آن قابل اعتماد است، و می‌تواند بر اساسش تصمیم بگیرد.همین تفاوت، Search در محصولات سازمانی را از جست‌وجوی معمولی یا Consumer Search جدا می‌کند.۱. چرا Enterprise Search با Consumer Search فرق دارد؟در محصولات مصرفی مثل گوگل، دیجی‌کالا یا شبکه‌های اجتماعی، سیستم با حجم زیادی از رفتارهای تکرارشونده سروکار دارد. میلیون‌ها کاربر پیش از شما چیزهای مشابهی جست‌وجو کرده‌اند، روی نتایج مشابهی کلیک کرده‌اند و به سیستم کمک کرده‌اند تا بهتر حدس بزند شما دنبال چه هستید.اما در یک محصول سازمانی، داده‌ها معمولاً تمیز، یکدست و قابل پیش‌بینی نیستند.ممکن است یک گزارش واحد با چند نام مختلف ذخیره شده باشد:گزارش فروش سه‌ماهه سومQ3 Sales Reportگزارش عملکرد فصل سومبرای انسان، این‌ها شاید به یک موضوع اشاره کنند. اما برای سیستم، ممکن است سه موجودیت کاملاً جدا باشند.حالا به این مسئله اضافه کنید: فایل‌های پراکنده در ابزارهای مختلف، سطح‌های دسترسی پیچیده، نسخه‌های قدیمی و جدید، تیم‌هایی با زبان تخصصی متفاوت، و کاربرانی که گاهی خودشان هم دقیق نمی‌دانند باید دنبال چه عبارتی بگردند.در چنین فضایی، مشکل اصلی فقط «پیدا کردن نتیجه» نیست. مشکل اصلی این است که کاربر بتواند به نتیجه اعتماد کند.۲. Search یک مسیر است، نه یک لحظهیکی از اشتباه‌های رایج در طراحی Search این است که آن را یک عمل ساده و یک‌مرحله‌ای ببینیم:کاربر چیزی می‌نویسد، سیستم نتیجه می‌دهد، تمام.اما در واقعیت، جست‌وجو بیشتر شبیه یک حلقه یا Search Loop است.کاربر با یک تصور ناقص شروع می‌کند، نتایج را می‌بیند، عبارت جست‌وجو را اصلاح می‌کند، فیلتر اضافه می‌کند، یک نتیجه را باز می‌کند، برمی‌گردد، دوباره جست‌وجو می‌کند و کم‌کم به چیزی که واقعاً نیاز دارد نزدیک می‌شود.پس طراح نباید فقط صفحه نتایج را طراحی کند. باید کل مسیر را ببیند:نوشتن Query، دیدن پیشنهادها، اصلاح عبارت، فیلتر کردن، دیدن Preview، بازگشت، و جست‌وجوی دوباره.یک تجربه خوب Search فقط نمی‌پرسد: «نتایج را چطور نمایش دهیم؟»سؤال مهم‌تر این است: «چطور کاربر را از ابهام به اطمینان برسانیم؟»۳. همه کاربران به یک شکل جست‌وجو نمی‌کننددر طراحی Search باید بدانیم کاربر با چه نوع نیازی وارد شده است. همه جست‌وجوها شبیه هم نیستند.Known-item Search: وقتی کاربر دنبال یک چیز مشخص استدر این حالت، کاربر تقریباً دقیق می‌داند چه می‌خواهد.مثلاً:«قرارداد شرکت X»«گزارش بودجه اردیبهشت»«فایل ارائه جلسه قبلی»اینجا سرعت و دقت اهمیت زیادی دارد. کاربر می‌خواهد سریع به همان چیزی برسد که در ذهن دارد. مشکل اینجاست که حتی در این حالت ساده هم نام‌گذاری‌های متفاوت، نسخه‌های تکراری یا نبود اطلاعات کافی درباره منبع می‌تواند تجربه را خراب کند.Exploratory Search: وقتی کاربر در حال کشف کردن استگاهی کاربر دقیق نمی‌داند دنبال چه چیزی است. او بیشتر می‌خواهد بگردد، مقایسه کند و تصویر کامل‌تری بسازد.مثلاً:«ببینم درباره رقبا چه گزارش‌هایی داریم.»«می‌خواهم وضعیت پروژه‌های امسال را بررسی کنم.»«دنبال الگوهایی در بازخوردهای مشتریان هستم.»اینجا Search بیشتر شبیه Browse کردن است. کاربر به فیلترهای خوب، دسته‌بندی معنادار، Preview کاربردی و امکان محدود کردن تدریجی نتایج نیاز دارد.Re-finding: وقتی کاربر می‌خواهد چیزی را دوباره پیدا کنداین حالت خیلی رایج است، اما در طراحی کمتر جدی گرفته می‌شود.کاربر قبلاً چیزی را دیده، اما حالا اسم دقیق، مسیر یا محل ذخیره آن را به خاطر ندارد.مثلاً:«همان گزارشی که هفته پیش دیدم.»«فایلی که سارا در جلسه نشان داد.»«سندی که درباره سیاست دورکاری بود.»اینجا قابلیت‌هایی مثل Search History، Recently Viewed، Bookmark و مسیرهای بازگشت اهمیت زیادی پیدا می‌کنند.پس قبل از طراحی باید بپرسیم: محصول ما برای کدام نوع جست‌وجو بهتر طراحی شده است؟ پیدا کردن چیز مشخص، کشف کردن، یا پیدا کردن دوباره؟۴. طراحی برای اطمینان: از Intent تا Trustاز اینجا به بعد، بیشتر چالش‌های Search یک ریشه مشترک دارند: کاربر باید بتواند از میان ابهام، شلوغی و محدودیت‌ها به یک نتیجه قابل اعتماد برسد.به همین دلیل، بخش‌هایی مثل Intent Ambiguity، Trust، Permission-aware Search، Zero Result UX و Faceted Search را نباید کاملاً جدا از هم دید. همه این‌ها بخشی از طراحی برای اطمینان هستند.ابهام در نیت کاربر یا Intent Ambiguityفرض کنید کاربر در سیستم شما کلمه «monitor» را جست‌وجو می‌کند.این کلمه می‌تواند به چند چیز اشاره کند:مانیتور سخت‌افزاری؛داشبورد پایش یا Monitoring Dashboard؛سیاست نظارت بر کارکنان؛یک تیکت پشتیبانی؛یا شاخص‌های پایش عملکرد.اینجا مسئله فقط الگوریتم نیست. طراحی هم باید کمک کند کاربر بدون شروع دوباره، منظورش را دقیق‌تر کند.مثلاً سیستم می‌تواند بر اساس زمینه کاری کاربر، یعنی Context، نتایج را اولویت‌بندی کند. اگر کاربر در پروژه زیرساخت کار می‌کند، نتایج مربوط به سخت‌افزار یا DevOps بالاتر بیاید. اگر در فضای منابع انسانی است، نتایج مربوط به Employee Monitoring Policy مهم‌تر شود.یا می‌تواند از همان ابتدا نوع محتوا را نشان دهد:Documents، Dashboards، Tickets، Peopleاین کار به کاربر کمک می‌کند خیلی سریع دامنه جست‌وجو را محدود کند.اعتماد یا Trustکاربر وقتی نتیجه‌ها را می‌بیند، فقط دنبال ارتباط ظاهری نیست. او ناخودآگاه می‌پرسد:«آیا این سیستم واقعاً من را فهمیده؟»«آیا این نتیجه هنوز معتبر است؟»«آیا منبعش قابل اعتماد است؟»برای ساختن Trust، چند چیز ساده اما حیاتی‌اند:منبع نتیجه یا Source Attribution باید روشن باشد. کاربر باید بداند نتیجه از کدام سند، تیم، پروژه یا ابزار آمده است.تاریخ آخرین به‌روزرسانی باید دیده شود. در محیط سازمانی، اطلاعات قدیمی می‌تواند تصمیم اشتباه بسازد.Preview باید واقعاً کمک‌کننده باشد. کاربر نباید مجبور شود برای فهمیدن هر نتیجه، آن را کامل باز کند.و سیستم بهتر است تا حدی Explainable باشد؛ یعنی توضیح دهد چرا این نتیجه نمایش داده شده است. حتی یک جمله کوتاه مثل «این نتیجه به دلیل تطابق با عنوان سند و محتوای مرتبط نمایش داده شده» می‌تواند اعتماد بسازد.سطح دسترسی یا Permission-aware Searchدر محصولات سازمانی، همه کاربران نباید همه چیز را ببینند. اما طراحی این موضوع ساده نیست.اگر فایلی وجود دارد ولی کاربر به آن دسترسی ندارد، سیستم باید چه کند؟یک راه این است که نتیجه کاملاً پنهان شود. این روش امن‌تر است، اما ممکن است کاربر فکر کند چنین اطلاعاتی اصلاً وجود ندارد.راه دیگر این است که وجود نتیجه نمایش داده شود، اما محتوا قفل باشد. مثلاً:«این سند وجود دارد، اما شما به آن دسترسی ندارید. می‌توانید درخواست دسترسی ارسال کنید.»این روش Discoverability بهتری دارد، اما برای همه سازمان‌ها مناسب نیست.نکته مهم این است که این تصمیم باید آگاهانه طراحی شود، نه اینکه فقط به پیش‌فرض سیستم سپرده شود.تجربه بدون نتیجه یا Zero Result UXصفحه «نتیجه‌ای پیدا نشد» نباید پایان مسیر باشد.در Enterprise Search، نبود نتیجه می‌تواند برداشت اشتباه بسازد. کاربر ممکن است فکر کند اطلاعاتی وجود ندارد، در حالی که شاید فقط عبارت متفاوتی استفاده کرده یا فیلتر اشتباهی فعال بوده است.یک Zero Result خوب باید مسیر بعدی پیشنهاد دهد:«شاید منظورتان این بود؟» برای اصلاح تایپپیشنهاد واژه‌های نزدیک از نظر معنانمایش محتوای مرتبطپیشنهاد حذف یا تغییر فیلترهایا حتی مسیر انسانی، مثل پرسیدن از مالک پروژه یا تیم پشتیبانیهدف این نیست که سیستم فقط شکست را اعلام کند. هدف این است که کاربر بتواند مسیر را ادامه دهد.جست‌وجوی چندوجهی یا Faceted Searchوقتی تعداد نتایج زیاد می‌شود، کاربر به کنترل بیشتری نیاز دارد. اینجاست که Faceted Search مهم می‌شود؛ یعنی فیلتر کردن نتایج بر اساس ویژگی‌هایی مثل نوع محتوا، تیم، پروژه، بازه زمانی، نویسنده، وضعیت نسخه یا سطح دسترسی.اما فیلتر زیاد هم می‌تواند تجربه را شلوغ و خسته‌کننده کند.پس فیلترها باید هوشمندانه طراحی شوند:فقط فیلترهای مهم اول نمایش داده شوند.فیلترها بر اساس نتایج واقعی تغییر کنند.پیش‌فرض‌ها با نقش و رفتار کاربر هماهنگ باشند.و کاربر همیشه بتواند بفهمد چه چیزی جست‌وجویش را محدود کرده است.کنترل خوب یعنی کاربر قدرت انتخاب داشته باشد، نه اینکه زیر فشار گزینه‌ها گم شود.۵. AI Search: وقتی سیستم به‌جای نتیجه، جواب می‌دهدبا ورود هوش مصنوعی، مدل جست‌وجو در حال تغییر است.قبلاً کاربر جست‌وجو می‌کرد، فهرستی از نتایج می‌دید و خودش نتیجه مناسب را انتخاب می‌کرد.اما در AI Search، سیستم می‌تواند مستقیماً یک پاسخ تولید کند.این تغییر تجربه را سریع‌تر می‌کند، اما خطر تازه‌ای هم دارد: اگر پاسخ اشتباه باشد، کاربر شاید اصلاً متوجه نشود.در مدل قدیمی، کاربر چند نتیجه را می‌دید و می‌توانست مقایسه کند. اما در مدل جدید، ممکن است فقط یک پاسخ نهایی ببیند. برای همین در AI Search، اعتماد از همیشه مهم‌تر است.هر پاسخ باید منبع داشته باشد.کاربر باید بتواند به سند اصلی برگردد.سیستم باید نشان دهد پاسخ با چه سطحی از اطمینان تولید شده است.و اگر پاسخ ناقص یا اشتباه بود، اصلاح آن باید ساده باشد.هوش مصنوعی نباید جای اعتماد را بگیرد. باید مسیر رسیدن به اعتماد را کوتاه‌تر کند.جمع‌بندی: مشکل Search همیشه خود Search نیستوقتی کاربر چیزی را پیدا نمی‌کند، همیشه مشکل از الگوریتم Search نیست.گاهی مشکل این است که سیستم نیت کاربر را خوب روشن نمی‌کند.گاهی منبع و تازگی نتیجه مشخص نیست.گاهی کاربر نمی‌فهمد چرا نتیجه‌ای نمایش داده شده.گاهی فیلترها بیش از حد پیچیده‌اند.گاهی نتیجه‌ای وجود دارد، اما پشت سطح دسترسی پنهان شده.و گاهی صفحه بدون نتیجه، هیچ مسیر بعدی پیشنهاد نمی‌دهد.در محصولات سازمانی، Search فقط برای پیدا کردن اطلاعات نیست. Search بخشی از فرآیند اعتمادسازی است.کاربر سازمانی فقط نمی‌خواهد چیزی را پیدا کند.او می‌خواهد مطمئن شود چیزی را از دست نداده است.تا وقتی این نیاز به اطمینان را در مرکز طراحی قرار ندهیم، ممکن است محصولی داشته باشیم که از نظر فنی Search دارد، اما کاربران همچنان ترجیح دهند جوابشان را از همکارشان بپرسند. محمد غلامی محمد غلامی Sat, 13 Jun 2026 19:05:21 +0330 https://virgool.io/@mohammadgholami/%DA%86%D8%B7%D9%88%D8%B1-%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D8%A8%D8%AF%D9%87%DB%8C-%D9%88%D8%B3%DB%8C%D9%84%D9%87-%D9%86%D9%82%D9%84%DB%8C%D9%87-%D8%B1%D8%A7-%D8%AF%D8%B1-%D8%A7%D9%BE%D9%84%DB%8C%DA%A9%DB%8C%D8%B4%D9%86-%D9%BE%D9%84%DB%8C%D8%B3-%D9%85%D9%86-%D8%A8%D8%A7%D8%B2%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%DA%A9%D8%B1%D8%AF%DB%8C%D9%85-jyxujkcgd5og مقدمهدر اپلیکیشن «پلیس من»، یکی از پرتکرارترین نقاط تماس کاربران، سرویس «بدهی‌های وسیله نقلیه» است؛ سرویسی که روزانه هزاران کاربر برای مشاهده و پرداخت خلافی، عوارض آزادراهی، طرح ترافیک و بدهی‌های شهرداری به آن مراجعه می‌کنند. برای بسیاری از کاربران، این سرویس نه‌تنها نقطه ورود به اپلیکیشن، بلکه تنها دلیل استفاده از آن است.در جریان بازطراحی کلی «پلیس من»، این سرویس یکی از مهم‌ترین فرصت‌ها برای خلق تجربه‌ای سریع، دقیق و متمایز از سایر رقبا بود. ما در تیم طراحی تصمیم گرفتیم صرفاً ظاهر رابط کاربری را تغییر ندهیم؛ بلکه از طریق بازمهندسی معماری اطلاعات، کاهش friction‌ در ورود داده، استفاده هوشمندانه از اطلاعات موجود و به‌کارگیری الگوهای آشنا، تجربه‌ای طراحی کنیم که هم کاربر را کمتر خسته کند و هم حس هوشمندی و اعتماد را تقویت کند.درک مسئله: چرا تجربه قبلی نیاز به بازطراحی داشت؟قبل از هر طراحی، باید دقیقاً بفهمیم که «چه چیزی» باید حل شود و «چرا» وضعیت فعلی برای کاربران مشکل‌ساز است. اینجا بخشی از بینش‌هایی است که در تحلیل نسخه پیشین سرویس به آن‌ها رسیدیم:۱. مسیر دستیابی پیچیدهدسته‌بندی خدمات بر اساس ساختار درونی سازمان (مثل پلیس راهور) بود، نه بر اساس مدل ذهنی کاربران. در نتیجه کاربر نمی‌دانست برای مشاهده خلافی باید به کجا برود. این موضوع یکی از منابع اصلی سردرگمی بود، به‌ویژه برای کاربران مسن یا کم‌سواد.۲. کشف‌پذیری ضعیف پلاک‌هابا اینکه پلاک‌های متعلق به کاربر در سامانه ذخیره بودند، رابط کاربری به‌گونه‌ای طراحی نشده بود که دسترسی سریع و آشکار به آن‌ها را فراهم کند. بسیاری از کاربران حتی نمی‌دانستند پلاک‌ها از قبل ثبت شده‌اند.۳. نبود امکان ذخیره و مدیریت پلاک‌های غیرکاربران فقط می‌توانستند استعلام خلافی خودروهایی را بگیرند که به نام خودشان ثبت شده بود. برای رانندگان تاکسی اینترنتی، مسئولان شرکت‌ها، یا حتی اعضای خانواده، این محدودیت آزاردهنده بود.۴. پراکندگی سرویس هافقط خلافی در دسترس بود و برای مشاهده سایر بدهی‌ها مانند عوارض آزادراهی یا طرح ترافیک، کاربران باید به اپلیکیشن های مختلف مراجعه می‌کردند.۵. نبود امکان اعتراضدر بررسی‌های اولیه و نیازسنجی‌های انجام‌شده، یکی از نیازهای پررنگ کاربران، امکان ثبت اعتراض به تخلفات رانندگی بود؛ قابلیتی که تاکنون در هیچ‌یک از محصولات مشابه ارائه نشده است. نبود این امکان در نسخه قبلی اپلیکیشن، باعث ایجاد نارضایتی، احساس بی‌عدالتی و در نهایت کاهش اعتماد کاربران به سیستم می‌شد. کاربران به دنبال راهی بودند تا در صورت وجود اشتباه یا ابهام، صدای خود را به گوش نهاد مربوطه برسانند. ما با درک این نیاز پنهان و مغفول، طراحی و اضافه‌کردن این قابلیت را در اولویت اقدامات آینده قرار دادیم.تعیین اهداف بازطراحیبا توجه به چالش‌ها، تیم طراحی شش هدف کلیدی را برای بازطراحی این سرویس تعریف کرد:۱. ساده‌سازی مسیر دستیابی۲. بهبود کشف‌پذیری پلاک‌ها۳. تجمیع تمامی بدهی‌ها در یک مکان۴. افزودن قابلیت اعتراض به جرایم۵. کاهش بار وارد کردن داده‌ها۶. امکان ذخیره و مدیریت پلاک‌های دیگرانراهکارها و مداخلات طراحی۱. بازطراحی معماری اطلاعات ما دسته‌بندی‌های اصلی را از نو تعریف کردیم. حالا تمام خدمات مرتبط با خودرو (خلافی، عوارض، طرح ترافیک) زیر یک برچسب واحد با نام «وسیله نقلیه» قرار گرفته‌اند. این هم‌راستایی با ذهن کاربر باعث کاهش بار شناختی و افزایش سرعت دسترسی شد.۲. استفاده از تکنیک کارت سورتینگ برای بهبود معماری اطلاعاتبرای شناسایی مدل ذهنی کاربران، از روش Card Sorting استفاده کردیم. داده‌های حاصل از این تست به ما کمک کرد تا دسته‌بندی‌هایی طراحی کنیم که برای کاربران طبیعی‌تر و قابل‌پیش‌بینی‌تر باشند.تکنیک کارت سورتینگ برای بهبود معماری اطلاعاتباز طراحی معماری اپلیکیشن۳. حذف نیاز به Data Entry غیرضروریبا اتصال به داده‌های موجود و استفاده از کد ملی، تمامی وسایل نقلیه ثبت‌شده به‌نام کاربر، به‌صورت خودکار بارگذاری می‌شوند. نتیجه: تجربه‌ای سریع، بی‌دردسر، و شخصی‌سازی‌شده.۴. بهبود کشف‌پذیری پلاک‌ها و ایجاد لیست پلاک‌های ثبت‌شدهدر نسخه قبلی، پلاک‌های کاربران در لایه‌های عمیق رابط کاربری دفن شده بودند و دسترسی به آنها مشکل بود. در نسخه جدید، لیست کامل پلاک‌های ثبت‌شده به نام کاربر در صفحه اصلی اپلیکیشن به‌صورت گرافیکی و برجسته نمایش داده می‌شود. این تغییر نه‌تنها تجربه کاربری را بهبود داد، بلکه باعث افزایش اعتماد کاربران شد. به‌علاوه، دسترسی به این اطلاعات از نقاط پرتکرار تعامل کاربر ممکن شد، که این کار باعث کاهش زمان و تلاش کاربر در جستجو و پرداخت بدهی‌ها می‌شود.نمایش مجموع خلافی در صفحه اصلی۵. افزایش حس شخصی‌سازی و هوشمندی اپلیکیشنیکی از نقاط قوت این بازطراحی این بود که به جای اضافه کردن ویژگی‌های جدید، ارزش یک قابلیت موجود احیا شد. به‌طور خاص، کاربران حالا می‌توانند به‌راحتی تمامی بدهی‌ها و پلاک‌های خود را در یک مکان واحد مشاهده کنند، بدون نیاز به وارد کردن اطلاعات دستی یا جستجو در قسمت‌های مختلف اپلیکیشن. این نوع از شخصی‌سازی باعث شد که اپلیکیشن حس هوشمندی و متناسب بودن با نیازهای کاربر را ایجاد کند.۶. قابلیت ذخیره و مدیریت پلاک‌های غیربه‌منظور رفع یکی از مهم‌ترین مشکلات کاربران، یعنی عدم امکان ذخیره و مدیریت پلاک‌های غیر (پلاک‌هایی که به نام کاربر نبودند)، این قابلیت به اپلیکیشن اضافه شد. کاربران اکنون می‌توانند پلاک‌های خودروهای دیگر را برای استعلام بدهی‌ها و پرداخت‌ها ذخیره کنند، که این امر باعث بهبود تجربه کاربری در شرایط مختلف (برای مثال، رانندگان تاکسی اینترنتی یا افرادی که چندین خودرو دارند) می‌شود.۷. هشدار برای دوبل شدن برخی از تخلفاتبرخی تخلفات هستند که با دیر کرد پرداخت آن ها توسط فرد متخلف جریمه آن دو برابر می شود.
درحال حاضر هیچ سرویس دهنده ای امکان اعلام این مورد را به کاربران ندارد و ما در اپلیکیشن پلیس من اولین ارائه دهنده این سرویس هستیم.نتیجه‌گیری و تأثیر بازطراحیاین بازطراحی باعث شد سرویس «بدهی‌های وسیله نقلیه» به تجربه‌ای سریع‌تر، ساده‌تر و هوشمندانه‌تر برای کاربران تبدیل شود. در تست‌های کاربری نهایی، کاربران در کمتر از نصف زمان قبلی توانستند بدهی خود را بررسی و پرداخت کنند. نرخ سردرگمی در پیدا کردن سرویس از بیش تر از ۶۰٪ به کمتر از ۱۰٪ رسید.از نظر کیفی، بازخوردهایی مثل «بالاخره می‌تونم راحت خلافی ماشین بابام رو ببینم» یا «چقدر راحت شد همه بدهی‌ها یکجا بودن»، نشان دادند که تغییرات ما دقیقاً در راستای خواسته‌های کاربران بوده‌اند.قدم بعدیدر نسخه‌های آینده، قصد داریم قابلیت‌های بیشتری را در همین راستا توسعه دهیم؛ از جمله:آمار تخلفات در قالب استوری بوردطراحی گیمیفیکیشن در جهت افزایش تعامل با محصول و ایجاد حس همدلی با کاربرانساخت پرسونای رانندگی برای هر کاربرطراحی تعاملات انسانی تر در بخش اعتراض به جرایماین پروژه بدون همکاری نزدیک و همدلی تیم محصول ممکن نبود. از بهراد آب‌نیکی و امیرحسین نژادجعفری، طراحان محصول، برای نقش مؤثرشان در تحلیل، ایده‌پردازی و اجرای راه‌حل‌ها، و از محمد گلناری، مدیر محصول پروژه، برای هدایت در طول مسیر، صمیمانه قدردانی می‌کنم. تجربه کار با این تیم برای من فرصتی ارزشمند و الهام‌بخش بود. محمد غلامی محمد غلامی Wed, 23 Jul 2025 12:28:37 +0330