پول، نحوه تعامل کاربران با محصولات دیجیتال را تغییر میدهد.
ممکن است یک الگوی ناواضح در مسیریابی یک شبکه اجتماعی فقط آزاردهنده باشد یا کند بودن یک صفحه در یک اپلیکیشن سرگرمی فقط کاربر را کلافه کند. اما همین اصطکاک زمانی که کاربر در حال بررسی موجودی حساب، انتقال وجه، احراز هویت یا سرمایهگذاری است، معنای کاملا متفاوتی پیدا میکند.
کاربر در یک محصول مالی فقط با یک رابط کاربری تعامل نمیکند؛ او در حال تصمیمگیری درباره چیزی ارزشمند است.
همین موضوع است که طراحی تجربه کاربری اپلیکیشنهای فینتک را از طراحی محصولات دیجیتال معمولی متمایز میکند. یک محصول مالی باید سیستمهای پیچیده را ساده و قابلفهم کند، بدون اینکه این سادگی به ابهام تبدیل شود. کاربر نباید برای استفاده از یک اپلیکیشن بانکی مجبور باشد شبکههای پرداخت، معماری لجر، سیستمهای احراز هویت یا الزامات رگولاتوری را بشناسد. در عین حال، رابط کاربری نباید اطلاعاتی را که برای تصمیمگیری آگاهانه لازم است از او پنهان کند.
بنابراین مسئله اصلی، حذف پیچیدگی نیست.
مسئله، تبدیل پیچیدگی به وضوح است.
پشت یک صفحه به ظاهر ساده بانکی ممکن است مجموعهای از فرایندهای KYC و AML، APIهای بانکداری، پردازشگرهای پرداخت، وضعیتهای مختلف تراکنش، سیستمهای تشخیص تقلب، لجرهای دوطرفه، فرایندهای تطبیق حساب و الزامات قانونی قرار داشته باشد. هرکدام از این اجزا میتوانند روی چیزی که کاربر میبیند، زمان نمایش آن و اتفاقی که بعد از لمس یک دکمه رخ میدهد تأثیر بگذارند.
تجربه کاربری خوب در فینتک در نقطه اتصال این دو دنیا شکل میگیرد: پیچیدگی سیستم مالی و سادگیای که کاربران از محصولات دیجیتال مدرن انتظار دارند.
بهترین تجربههای بانکی وانمود نمیکنند که سیستم پشت محصول ساده است؛ بلکه کاری میکنند که این پیچیدگی برای کاربر قابلفهم، قابلپیشبینی و قابلاعتماد باشد.
چرا اعتماد، پایه تجربه کاربری در فینتک است؟
اعتماد در تمام محصولات دیجیتال اهمیت دارد، اما در محصولات مالی موضوع در سطح دیگری قرار میگیرد.
کاربر هنگام ورود به یک اپلیکیشن بانکی فقط در حال دریافت اطلاعات نیست. او میخواهد مطمئن شود پولش سر جای خودش است، یک پرداخت را انجام دهد، وجهی را منتقل کند، پساندازش را سرمایهگذاری کند یا اطلاعات شخصی و مالی حساسی را در اختیار یک سرویس قرار دهد.
بنابراین هر تعامل در یک محصول مالی به یک سؤال ضمنی پاسخ میدهد:
«آیا میتوانم به چیزی که این محصول به من میگوید اعتماد کنم؟»
یک رابط کاربری ضعیف میتواند حتی زمانی که سیستم در پسزمینه کاملا درست کار میکند، در کاربر احساس خطا ایجاد کند.
مثلاً تأخیر در بهروزرسانی موجودی ممکن است این تصور را ایجاد کند که پول کاربر ناپدید شده است. وضعیت نامشخص یک پرداخت میتواند این نگرانی را ایجاد کند که تراکنش دوبار انجام شده. یک پیام خطای عمومی هم کاربر را در موقعیتی قرار میدهد که نمیداند دوباره تلاش کند، منتظر بماند یا با پشتیبانی تماس بگیرد.
این لحظات فقط اصطکاک تجربه کاربری ایجاد نمیکنند؛ اضطراب ایجاد میکنند.
برای شرکتهای فینتک، این اضطراب میتواند پیامدهای مستقیمی برای کسبوکار داشته باشد. آنبوردینگ پیچیده باعث ریزش کاربر میشود، مسیرهای نامشخص تراکنش تعداد درخواستهای پشتیبانی را افزایش میدهند و معماری ضعیف اطلاعات میتواند تعامل با قابلیتهای مالی را کاهش دهد.
به همین دلیل، طراحی اپلیکیشن بانکی باید همزمان دو کار انجام دهد:
کاهش تلاش ذهنی غیرضروری و افزایش اطمینان در تصمیمهای مالی مهم.
رسیدن به این نقطه نیازمند شناخت عمیقتر محصول است؛ نه فقط طراحی صفحه، بلکه درک اتفاقی که پشت آن صفحه رخ میدهد و چیزی که سیستم واقعا میتواند تضمین کند.
اعتماد، قبل از اولین تراکنش شروع میشود
اعتماد در یک محصول مالی از لحظه جابهجایی پول شروع نمیشود؛ خیلی زودتر شکل میگیرد.
برای یک کاربر جدید، یکی از اولین تعاملات جدی ممکن است احراز هویت باشد. محصول ممکن است برای فعالکردن یک سرویس مالی از او شماره تلفن، نام قانونی، مدرک شناسایی، آدرس، تاریخ تولد یا اطلاعات بیومتریک بخواهد.
از نگاه کسبوکار، جمعآوری این اطلاعات ممکن است برای KYC، مبارزه با پولشویی، جلوگیری از تقلب یا رعایت الزامات قانونی ضروری باشد. اما از نگاه کاربر، همه اینها اطلاعات حساسی هستند که محصولی که هنوز به آن اعتماد نکرده از او درخواست میکند.
اینجاست که یکی از مهمترین چالشهای تجربه کاربری احراز هویت و آنبردینگ در فینتک شکل میگیرد.
هدف نباید حذف مراحل باشد. بعضی مراحل را نمیتوان و نباید حذف کرد. مسئله این است که کاربر بداند چرا این اطلاعات از او درخواست میشود و چه زمانی باید آنها را ارائه کند.
یک فرم طولانی که از همان ابتدا همه اطلاعات موردنیاز را مطالبه میکند، میتواند قبل از اینکه کاربر حتی ارزش محصول را تجربه کرده باشد، حس یک فرایند اداری و سنگین ایجاد کند. در مقابل، رویکرد افشای تدریجی اطلاعات را زمانی درخواست میکند که واقعا به آن نیاز است؛ در کنار آن، دلیل درخواست را توضیح میدهد و کاربر را با تصمیمها و اطلاعاتی که هنوز برایش معنایی ندارند، مواجه نمیکند.
در اینجا زمینه اهمیت زیادی دارد.
درخواست یک مدرک شناسایی بدون هیچ توضیحی، تجربهای متفاوت از زمانی ایجاد میکند که محصول توضیح میدهد احراز هویت برای فعالسازی انتقال وجه یا ارائه یک سرویس مالی ضروری است. الزام همان الزام است، اما درک کاربر از آن تغییر کرده است.
تجربه کاربری مالی خوب، الزامات قانونی را پنهان نمیکند؛ آنها را قابلفهم میکند.
همین اصل درباره امنیت نیز صدق میکند.
روشهای احراز هویت مدرن مانند بیومتریک، Passkey، احراز هویت دستگاه و مکانیزمهای امنیتی مبتنی بر ریسک میتوانند امنیت را تا حد زیادی بدون ایجاد وقفه دائمی در تجربه کاربر فراهم کنند.
کاربری که فقط موجودی حسابش را بررسی میکند، نباید همان سطح از اصطکاکی را تجربه کند که هنگام تأیید یک انتقال وجه سنگین وجود دارد.
اینجاست که یکی از اصول مهم طراحی تجربه کاربری امن برای اپلیکیشنهای موبایل بانکی مطرح میشود:
میزان اصطکاک باید متناسب با میزان ریسک باشد.
اقدامات کمریسک میتوانند سریع و ساده باقی بمانند. اقدامات پرریسک به احراز هویت قویتر، تأیید شفافتر و فرصت بیشتری برای بررسی نیاز دارند.
وقتی امنیت در زمان درست و به دلیل درست وارد تجربه میشود، بهجای ایجاد اصطکاک، اعتماد ایجاد میکند.
پول را قابلفهم کنید
وقتی کاربر وارد یک محصول مالی میشود، چالش بعدی این است که بتواند بهسادگی بفهمد چه اتفاقی برای پولش در حال رخ دادن است.
سیستمهای مالی بهطور طبیعی حجم زیادی از اطلاعات فنی تولید میکنند؛ از شناسه تراکنش و کدهای مجوز گرفته تا وضعیت تسویه، شناسه پذیرنده، زمان تراکنش، پاسخ پردازشگر و شماره حساب. این اطلاعات ممکن است برای سیستمها معنادار باشند، اما در واقع برای کسی که از اپلیکیشن استفاده میکند، معنایی ندارند.
کاربر نمیخواهد TXN_99482_LA را تفسیر کند. میخواهد بداند پولش کجا رفته است.
اینجاست که طراحی اپلیکیشن مالی دیگر به چیدمان اطلاعات روی صفحه محدود نمیشود. رابط کاربری باید دادههای خام و فنی سیستم مالی را به مدلی تبدیل کند که برای انسان قابل درک باشد.
یک تراکنش باید بتواند در کوتاهترین زمان به چند سؤال ساده پاسخ دهد:
چه اتفاقی افتاده؟ پول کجا رفته؟ چه مقدار بوده؟ چه زمانی انجام شده؟ و الان در چه وضعیتی قرار دارد؟
این موضوع میتواند به معنای نمایش نام قابلشناسایی پذیرنده یا گیرنده، مبلغ، تاریخ و زمان، دستهبندی، روش پرداخت و در صورت نیاز موقعیت مکانی یا اطلاعات مرجع تراکنش باشد.
ممکن است دادههای پشت سیستم همچنان پیچیده و حتی نامرتب باشند؛ اما تجربه کاربر نباید اینطور باشد.
این شفافیت زمانی اهمیت بیشتری پیدا میکند که تراکنش هنوز نهایی نشده باشد.
یک تراکنش مالی فقط دو حالت «موفق» یا «ناموفق» ندارد. بسته به سیستم پرداخت، ممکن است تراکنش در وضعیتهایی مانند تأیید اولیه، در حال پردازش، در انتظار، تکمیلشده، ردشده، برگشتخورده یا منقضیشده قرار بگیرد.
کاربر نیازی ندارد بداند پشت هرکدام از این وضعیتها چه اتفاقی در زیرساخت پرداخت افتاده است؛ اما باید بداند هر وضعیت برای پول او چه معنایی دارد.
فرض کنید کاربر یک پرداخت کارتی انجام داده و فقط این پیام را میبیند:
در انتظار
همین یک کلمه چند سؤال مهم ایجاد میکند:
آیا پول از حسابم کم شده؟ دوباره پرداخت کنم؟ فروشنده پول را دریافت کرده؟ مبلغ نهایی تغییر میکند؟
یک تجربه بهتر میتواند توضیح دهد که پرداخت هنوز در حال پردازش است و مبلغ نمایشدادهشده ممکن است پس از نهاییشدن تراکنش تغییر کند.
جزئیات دقیق این رفتار به سیستم مالی و زیرساخت پرداخت بستگی دارد، اما اصل تجربه کاربری همیشه یکسان است:
وقتی وضعیت پول نامشخص است، رابط کاربری باید از میزان این ابهام کم کند.
به همین دلیل صفحههای تأیید نیز بخش مهمی از تجربه مالی هستند.
پیش از انجام یک انتقال وجه با مبلغ بالا، کاربر باید بتواند بهسرعت بررسی کند که پول برای چه کسی ارسال میشود، مبلغ چقدر است، از کدام حساب برداشت میشود، چه زمانی به مقصد میرسد و آیا کارمزدی وجود دارد یا نه.
هدف صفحه تأیید این نیست که کاربر را مجبور کند بیشتر فکر کند.
هدف این است که مطمئن شویم درباره چیزهای درست فکر میکند.
برای چیزی که واقعا در سیستم اتفاق میافتد طراحی کنید
یکی از مهمترین تفاوتهای طراحی تجربه کاربری در فینتک با بسیاری از محصولات دیجیتال معمولی، زمانی آشکار میشود که رابط کاربری با معماری واقعی سیستم روبهرو میشود.
یک طراح ممکن است یک «موجودی حساب» ببیند.
یک مهندس ممکن است پشت همان عدد، لجر، پردازشگر پرداخت، API بانکداری، جریان رویدادها، فرایند تسویه و سیستم تطبیق حساب را ببیند.
اما کاربر فقط یک عدد میبیند.
و آن عدد باید برایش معنا داشته باشد.
برای مثال، فرض کنید کاربر ۱.۰۰۰.۰۰۰ تومان موجودی قابلاستفاده دارد و یک پرداخت ۲۰۰.۰۰۰ تومانی انجام میدهد. بسته به معماری سیستم، ممکن است موجودی قابلاستفاده بلافاصله به ۸۰۰.۰۰۰ تومان کاهش پیدا کند، در حالی که موجودی ثبتشده در لجر تا زمان نهاییشدن تراکنش همچنان ۱۰۰۰ دلار باقی بماند.
از نظر فنی، هر دو عدد میتوانند درست باشند.
اما از نگاه کاربر، دیدن دو عدد متفاوت ممکن است شبیه یک خطا به نظر برسد.
اینجاست که طراحی UI/UX محصولات مالی باید واقعیت بکاند را بپذیرد، نه اینکه بر اساس یک نسخه ایدهآل و سادهشده از سیستم طراحی شود.
در جایی که این تفاوت برای کاربر اهمیت دارد، نمایش جداگانه موجودی قابلاستفاده و موجودی فعلی میتواند این موضوع را شفاف کند. رابط کاربری لازم نیست حسابداری دوطرفه را به کاربر آموزش دهد؛ کافی است به زبان ساده توضیح دهد که چرا این دو عدد با هم تفاوت دارند.
همین مسئله درباره تأخیر API نیز وجود دارد.
فرض کنید کاربر یک انتقال وجه را ثبت میکند، اما API بانک چند ثانیه زمان نیاز دارد تا وضعیت نهایی تراکنش را برگرداند. طراحیای که در Figma بلافاصله از «ارسال» به «موفق» میرسد، ممکن است بسیار تمیز به نظر برسد؛ اما اگر سیستم در دنیای واقعی چنین رفتاری نداشته باشد، همین طراحی میتواند تجربهای گمراهکننده ایجاد کند.
محصول واقعی باید برای همین وضعیت میانی و ناخوشایند آماده باشد:
کاربر اقدام خود را انجام داده، اما سیستم هنوز از نتیجه نهایی مطمئن نیست.
در چنین شرایطی ممکن است به یک وضعیت «در حال پردازش»، تأیید با تأخیر، بررسی مجدد وضعیت تراکنش یا حتی اعلان پس از نهاییشدن نیاز باشد.
همین مشکل زمانی جدیتر میشود که اتصال اینترنت درست بعد از ارسال انتقال قطع شود.
اگر اپلیکیشن فقط یک خطا نمایش دهد، کاربر ممکن است دوباره تلاش کند. اما اگر درخواست اول واقعا به بانک رسیده باشد، تلاش دوم میتواند خطر ایجاد یک تراکنش تکراری را به همراه داشته باشد.
یک تجربه قابلاعتماد باید بین چیزی که سیستم میداند و چیزی که هنوز نمیداند تفاوت قائل شود.
برای مثال:
در بررسی وضعیت انتقال شما ارتباط قطع شد. هنوز نمیتوانیم تأیید کنیم که تراکنش انجام شده است. لطفا انتقال را دوباره ثبت نکنید.
جزئیات دقیق این رفتار به معماری سیستم بستگی دارد، اما اصل طراحی گستردهتر از آن است:
کاربر را درباره وضعیت یک اقدام مالی در حدس و گمان رها نکنید.
به همین دلیل طراحی تجربه کاربری در فینتک نمیتواند فقط یک لایه بصری باشد که بعد از تصمیمهای مهندسی روی محصول قرار میگیرد.
طراح باید بداند سیستم چه وضعیتهایی میتواند ایجاد کند. مهندس نیز باید بداند کاربر برای درک این وضعیتها به چه اطلاعاتی نیاز دارد.
بهترین تجربهها زمانی شکل میگیرند که این دو دیدگاه از همان ابتدای فرایند طراحی و توسعه در کنار یکدیگر قرار بگیرند.
دادههای مالی را به تصمیم تبدیل کنید
محصولات مالی حجم زیادی از اطلاعات تولید میکنند؛ از تراکنشها و موجودی حساب گرفته تا دستهبندی هزینهها، اشتراکها، پسانداز، سرمایهگذاری، اعتبار و پرداختهای دورهای. همه این دادهها میتوانند به کاربر کمک کنند تصویر بهتری از وضعیت مالی خود داشته باشد.
اما داده بیشتر، الزاما به معنای محصول بهتر نیست.
ممکن است یک داشبورد پر از نمودار و عدد باشد و کاربر همچنان با یک سؤال ساده روبهرو شود:
«خب، حالا با این اطلاعات باید چه کار کنم؟»
اینجاست که الگوهای مدرن طراحی تجربه کاربری نئوبانکها باید فراتر از نمایش اطلاعات حرکت کنند. یک رابط مالی خوب فقط به کاربر نمیگوید چه اتفاقی افتاده؛ کمک میکند بفهمد این اتفاق چه معنایی دارد و، در صورت نیاز، قدم بعدی چیست.
برای مثال، بهجای اینکه فقط نشان دهیم ۲۴ درصد از هزینههای ماهانه کاربر مربوط به حملونقل بوده، میتوانیم به او نشان دهیم که هزینه حملونقلش نسبت به میانگین ماههای اخیر به شکل قابلتوجهی افزایش پیدا کرده است.
یا بهجای نمایش یک نمودار ساده از میزان پسانداز، میتوانیم مشخص کنیم چه مقدار تا رسیدن به هدف باقی مانده و برای رسیدن به آن هدف، ماهانه چه میزان باید پسانداز شود.
تفاوت شاید کوچک به نظر برسد، اما مهم است.
یک رویکرد فقط اطلاعات ارائه میکند؛ رویکرد دیگر به کاربر در تصمیمگیری کمک میکند.
البته این به معنای تبدیل کردن هر اپلیکیشن بانکی به یک مشاور مالی خودکار نیست. وقتی یک محصول بینش یا پیشنهاد مالی ارائه میکند، کاربر باید بتواند بفهمد چرا این اطلاعات به او نمایش داده شده و در صورت نیاز، چه اقدامی میتواند انجام دهد. این موضوع زمانی اهمیت بیشتری پیدا میکند که چنین پیشنهادهایی بتوانند روی تصمیمهای مالی مهم تأثیر بگذارند.
همین منطق درباره نمایش بصری دادههای مالی هم صدق میکند. یک نمودار تنها زمانی مفید است که کاربر دقیاً بداند اعداد آن چه چیزی را نشان میدهند. تراکنشهای در انتظار، مبالغ برگشتی، انتقال بین حسابها، ارزش سرمایهگذاریها و تراکنشهای نهاییشده ممکن است همگی به شکل متفاوتی نیاز به نمایش داشته باشند.
اینجاست که دوباره ارتباط میان طراحی تجربه کاربری و سیستم مالی زیرساختی اهمیت پیدا میکند. نمودار فقط یک کامپوننت بصری روی دادههای خام نیست؛ در واقع نمایشی از وضعیتهای مالی مختلف است و اگر این وضعیتها درست تعریف یا تفسیر نشوند، حتی بهترین طراحی بصری هم میتواند کاربر را گمراه کند.
هدف این نیست که دادههای مالی پیچیدهتر یا پیشرفتهتر به نظر برسند.
هدف این است که برای کاربر مفید باشند.
برای خطا، ریسک و واقعیت انسانی طراحی کنید
کیفیت یک محصول مالی فقط زمانی مشخص نمیشود که همهچیز طبق برنامه پیش میرود. اتفاقا زمانی که چیزی درست کار نمیکند، تجربه واقعی محصول بیشتر خودش را نشان میدهد.
در یک اپلیکیشن اجتماعی، نمایش یک پیام خطا ممکن است فقط آزاردهنده باشد. اما در یک اپلیکیشن مالی، همان پیام میتواند فورا باعث نگرانی کاربر شود.
فرض کنید کاربر یک انتقال وجه را انجام داده و با این پیام مواجه میشود:
مشکلی پیش آمد.
سیستم ممکن است به طور دقیق بداند چه اتفاقی افتاده است؛ اما کاربر نمیداند.
دوباره تلاش کند؟ صبر کند؟ پول منتقل شده یا نه؟ موجودی حسابش را بررسی کند؟ با پشتیبانی تماس بگیرد؟
یک وضعیت خطای خوب در محصول مالی باید به سه سؤال ساده پاسخ دهد:
چه اتفاقی افتاد؟ چه معنایی دارد؟ حالا باید چه کار کنم؟
برای مثال:
انتقال وجه انجام نشد، چون بانک مقصد موقتا در دسترس نیست. مبلغی از حساب شما کسر نشده است. لطفا کمی بعد دوباره تلاش کنید.
این پیام کمی طولانیتر است، اما ابهام را از بین میبرد و قدم بعدی را مشخص میکند. همین رویکرد در احراز هویت، پرداخت با کارت، واریز و برداشت، تأیید هویت و مدیریت حساب نیز اهمیت دارد.
موضوع مشابهی درباره دسترسپذیری وجود دارد. دسترسپذیری در محصولات مالی فقط یک الزام یا چکلیست طراحی نیست؛ میتواند به طور مستقیم احتمال وقوع یک اشتباه پرهزینه را کاهش دهد.
مبالغ مالی باید سلسلهمراتب بصری واضحی داشته باشند. اطلاعات مهم نباید فقط با رنگ منتقل شوند. نواحی قابل لمس باید اندازه مناسبی داشته باشند، متن باید کنتراست کافی داشته باشد و اقدامات مهم باید با برچسبهای کاملا واضح نمایش داده شوند.
اما زمینه هم به همان اندازه اهمیت دارد.
بین این دو نمایش تفاوت زیادی وجود دارد:
۵۰,۰۰۰,۰۰۰- ریال
و:
انتقال ۵۰,۰۰۰,۰۰۰ ریال به عباس احدی
گزینه دوم اطلاعاتی را در اختیار کاربر قرار میدهد که برای بررسی و تأیید عملیات لازم است.
هرچه مبلغ و پیامد یک اقدام بیشتر باشد، این موضوع اهمیت بیشتری پیدا میکند. یک خرید ۵۰۰۰ تومانی و انتقال ۵۰ میلیون تومانی نباید دقیقا از یک الگوی تعاملی پیروی کنند.
بنابراین سؤال درست فقط این نیست:
چطور اصطکاک را از تجربه حذف کنیم؟
سؤال مهمتر این است:
کجا این اصطکاک از کاربر محافظت میکند و کجا فقط سرعت او را کم میکند؟
این یکی از اصول مهم تجربه کاربری اپلیکیشنهای بانکی است. یک محصول مالی خوب قرار نیست تمام اصطکاکها را حذف کند؛ بلکه اصطکاک را جایی قرار میدهد که به کاربر کمک میکند مکث کند، اطلاعات را بررسی کند و تصمیم مطمئنتری بگیرد و در بقیه مسیر، تجربه را تا جای ممکن ساده و روان نگه میدارد.
ساخت محصول مالی برای رشد و مقیاسپذیری
محصولات فینتک بهندرت برای همیشه در محدوده قابلیتهای اولیه خود باقی میمانند.
ممکن است نسخه اول یک محصول فقط شامل حساب، کارت، انتقال وجه و تاریخچه تراکنشها باشد. اما با گذشت زمان، همان محصول میتواند به حوزههایی مثل پسانداز، سرمایهگذاری، وام، بیمه، پاداش، پرداختهای بینالمللی یا بانکداری کسبوکار گسترش پیدا کند.
با رشد محصول، یکپارچگی و ثبات تجربه اهمیت بیشتری پیدا میکند.
یک دیزاین سیستم میتواند پایه این یکپارچگی باشد، اما یک دیزاین سیستم بالغ در فینتک نباید فقط رنگها، تایپوگرافی و کامپوننتهای قابل استفاده مجدد را تعریف کند.
باید رفتار محصول را هم مشخص کند.
تراکنش در انتظار چگونه نمایش داده میشود؟ محصول چطور موجودی قابل استفاده را از موجودی نهاییشده تفکیک میکند؟ اقدامات پرریسک چگونه تأیید میشوند؟ اگر درخواست API با تأخیر مواجه شود چه اتفاقی میافتد؟ تراکنش برگشتخورده چگونه نمایش داده میشود؟ مبالغ، کارمزدها، تاریخها و ارزهای مختلف چگونه باید قالببندی شوند؟
اینها تصمیمهای جداگانه و یکباره در رابط کاربری نیستند. اینها الگوهای تکرارشونده محصول هستند.
وقتی این الگوها از ابتدا تعریف شوند، تیم میتواند قابلیتهای جدید را توسعه دهد، بدون اینکه هر بار منطق اصلی تعاملات را از ابتدا طراحی کند.
اینجاست که ارتباط میان طراحی محصول، مهندسی، کامپلاینس و امنیت اهمیت ویژهای پیدا میکند.
یک دیزاین سیستم میتواند محصول را از نظر بصری یکپارچه کند؛ اما تنها نگاه مشترک به محصول است که میتواند رفتار آن را هم یکپارچه نگه دارد.
هرچه محصول بزرگتر و پیچیدهتر میشود، این تفاوت ارزش بیشتری پیدا میکند.
یک تجربه کاربری فینتک خوب چه شکلی است؟
تجربه کاربری خوب در فینتک به این معنا نیست که یک اپلیکیشن بانکی را شبیه یک شبکه اجتماعی طراحی کنیم.
مسئله این است که بفهمیم کدام بخش از پیچیدگی باید توسط سیستم مدیریت شود و کدام بخش را کاربر باید ببیند و درک کند.
کاربر نباید برای استفاده از یک محصول بانکی، زیرساختهای بانکی را بشناسد. اما باید همیشه اطلاعات کافی در اختیار داشته باشد تا بفهمد با پولش چه اتفاقی در حال رخ دادن است.
این موضوع به ترکیبی از چند اصل نیاز دارد: آنبوردینگ شفاف، امنیت متناسب با میزان ریسک، تراکنشهای قابل فهم، دادههای مالی معنادار، نمایش شفاف وضعیتهای سیستم، بازیابی مناسب از خطاها، تعاملات در دسترس و یک دیزاین سیستم که بتواند همزمان با رشد محصول توسعه پیدا کند.
اما مهمتر از همه، طراحان باید با سیستم مالی طراحی کنند، نه در اطراف آن.
وقتی طراح محصول محدودیتهای دفترکل، APIها، شبکههای پرداخت، الزامات قانونی و مدل امنیتی محصول را درک میکند، میتواند تصمیمهای تجربه کاربری بهتری بگیرد. از طرف دیگر، وقتی مهندسان هم مدل ذهنی کاربر را درک کنند، میتوانند وضعیتهای مختلف سیستم را به شکلی در اختیار رابط کاربری قرار دهند که برای کاربر قابل فهمتر باشد.
نتیجه فقط یک رابط کاربری تمیزتر نیست.
نتیجه محصولی است که قابل پیشبینی به نظر میرسد.
و قابل پیشبینی بودن، یکی از پایههای اصلی اعتماد است.
جمعبندی
در نهایت، طراحی تجربه کاربری در فینتک درباره ساختن یک رابطه قابل اعتماد میان انسان و سیستمهای مالی است.بهترین محصولات سعی نمیکنند تمام اصطکاکهای تجربه را حذف کنند. آنها میان اصطکاکی که از کاربر محافظت میکند و اصطکاکی که فقط مانع او میشود، تفاوت قائل میشوند.
آنها فرایند آنبوردینگ را بدون تضعیف الزامات قانونی قابل فهم میکنند. تراکنشها را شفاف نگه میدارند، بدون اینکه کاربر را با پیچیدگیهای فنی غیرضروری مواجه کنند. دادههای مالی را به اطلاعاتی تبدیل میکنند که به تصمیمگیری کمک میکند. محدودیتهای بکاند را نادیده نمیگیرند و در زمان بروز خطا، اطلاعات کافی در اختیار کاربر قرار میدهند تا بفهمد چه اتفاقی افتاده و قدم بعدی چیست.
برای بنیانگذاران فینتک، تیمهای نئوبانک و مدیران محصولات مالی، این یعنی تجربه کاربری نباید با طراحی صفحهها شروع شود.
باید از کاربر، سیستم مالی و تصمیمهایی که این دو را به هم متصل میکنند شروع شود.
فرصت واقعی در طراحی محصولات فینتک همینجاست:
نه پنهان کردن پیچیدگی، بلکه مهار کردن آن.
اگر در حال ساخت یک محصول فینتک جدید هستید، تجربه یک اپلیکیشن بانکی را بازطراحی میکنید یا میخواهید یک فرایند مالی پیچیده را سادهتر کنید، استودیو youx میتواند با ترکیب استراتژی محصول، طراحی تجربه کاربری و درک واقعیتهای فنی، به شما کمک کند محصولی بسازید که کاربران بتوانند آن را بفهمند و به آن اعتماد کنند.
