You optimized the endpoint. Your resend email API responds in under half a second. And yet users still open support tick

நீங்கள் endpoint-ஐ மேம்படுத்திவிட்டீர்கள். உங்கள் resend-email API அரை விநாடிக்கும் குறைவான நேரத்தில் பதிலளிக்கிறது. இருப்பினும், இணைப்பு வரவில்லை என்று கூறி பயனர்கள் இன்னும் support tickets-களைத் திறக்கிறார்கள். அவர்கள் இருமுறை கிளிக் செய்கிறார்கள். இன்பாக்ஸைச் சரிபார்க்கும் முன்பே அந்தச் செயல்பாட்டை விட்டுவிடுகிறார்கள். ஏதோ ஒன்று இன்னும் பழுதாகியிருப்பதாகத் தோன்றுகிறது.

இந்தத் தொடர்பின்மை பெரும்பாலும் infrastructure-இல் இல்லை, interface-இல் தான் உள்ளது. ஒரு backend 400 மில்லி விநாடிகளில் 200 OK-ஐத் திருப்பி அனுப்பலாம், ஆனால் frontend ஒரு தாவித் தாவி நகரும் layout மற்றும் மின்னும் banner-உடன் பதிலளித்தால், பயனர் எப்படியும் தோல்வியையே உணர்வார். ஒருவர் ஒரு பொத்தானைக் கிளிக் செய்யும் போது, திரையானது அவரது கர்சருக்குக் கீழே நகர்ந்தால், அவர் feedback loops அல்லது network latency பற்றிச் சிந்திப்பதில்லை. ஆப் (app) பழுதாகிவிட்டது என்றுதான் நினைக்கிறார்.

உண்மையான பிரச்சனை அரிதாகவே வேகத்தைப் பற்றியது

React குழுக்கள் பெரும்பாலும் email confirmation-ஐ ஒரு எளிய state machine ஆகக் கருதுகிறார்கள்: idle, loading, success, error. Component ஒரு mutation-ஐத் தூண்டி, isLoading-ஐ true என அமைத்து, பின்னர் promise தீரும்போது ஒரு செய்தியை மாற்றுகிறது. அந்த மாற்றத்தின் போதுதான் பாதிப்பு ஏற்படுகிறது. Browser layout-ஐ மீண்டும் கணக்கிடுகிறது, பாதிக்கப்பட்ட பகுதியை மீண்டும் வரைகிறது (repaints), மேலும் சில நேரங்களில் முழு கார்டு அல்லது பக்கத்தையும் மறுசீரமைக்கிறது (reflows). பயனர் அமைதியை எதிர்பார்த்த இடத்தில் இயக்கத்தைக் காண்கிறார். அவர்களுக்கு, அந்தச் செயல் உறுதிப்படுத்தப்படவில்லை; அது துடித்தது (convulsed) போலத் தோன்றுகிறது.

இதனால்தான் நேரத்தை விட உணர்தலே (perception) முக்கியமானது. இருநூறு மில்லி விநாடிகள் எடுக்கும் ஒரு நிலையற்ற இடைமுகத்தை விட, ஐந்நூறு மில்லி விநாடிகள் எடுக்கும் ஒரு நிலையான இடைமுகம் வேகமாகவும் பாதுகாப்பாகவும் உணரப்படுகிறது. பயனர்களால் latency-ஐ அளவிட முடியாது, ஆனால் அவர்களால் நம்பிக்கையை (confidence) அளவிட முடியும். UI தடுமாறும்போது, கோரிக்கையும் (request) அதனுடன் சேர்ந்து தடுமாறிவிட்டது என்று அவர்கள் கருதுகிறார்கள்.

மோசமான feedback நம்பிக்கையைச் சிதைக்கும் மூன்று வழிகள்

மோசமான உறுதிப்படுத்தல் feedback பொதுவாக மூன்று பொறிகளில் விழுகிறது; எதைத் தேட வேண்டும் என்று தெரிந்தால் அவற்றை எளிதில் கண்டறியலாம்.

Distance. பயனர் படிவத்தின் (form) கீழ்ப்பகுதியில் கிளிக் செய்திருக்கும் போது, அதன் மேற்புறத்தில் உள்ள ஒரு global banner-இல் வெற்றிச் செய்தி தோன்றுவது, பார்வையின் தொடர்ச்சியைத் துண்டிக்கிறது. கண் நகர்கிறது; கை காத்திருக்கிறது; கிளிக் தோல்வியடைந்துவிட்டது என்று மூளை கருதுகிறது. Feedback என்பது அதைத் தூண்டிய செயலுக்கு அருகிலேயே இருக்க வேண்டும்.

Noise. பூஜ்ஜியத்திலிருந்து முழு அளவு வரை பெரிதாகும் spinners, துள்ளிக் குதிக்கும் checkmarks, அல்லது ஒரு சாதாரண மின்னஞ்சல் அனுப்பலைக் கொண்டாடும் வகையில் fade-in ஆகும் modals ஆகியவை தங்களுக்குத் தேவையில்லாத கவனத்தை ஈர்க்கின்றன. அவை ஒரு எளிய உறுதிப்படுத்தலை ஒரு நாடகத் தயாரிப்பாக மாற்றுகின்றன. Vestibular disorders உள்ள பயனர்களுக்கு, அதிகப்படியான இயக்கம் எரிச்சலூட்டுவது மட்டுமல்ல, உடல் ரீதியாகவும் அசௌகரியத்தை ஏற்படுத்துகிறது.

Layout shift. ஒரு பொத்தானுக்குக் கீழே புதிய பத்தியைச் சேர்ப்பது அடுத்த form field-ஐக் கீழே தள்ளுகிறது. Footer நகர்கிறது. திரையின் கீழ் பகுதி உள்ள உள்ளடக்கம் (content) மறுசீரமைக்கப்படுகிறது. இது usability மற்றும் accessibility ஆகிய இரண்டையும் சமமாகப் பாதிக்கிறது. ஒரு switch device அல்லது துல்லியமான eye tracking பயன்படுத்தும் நபர், அடுத்த இலக்கை நோக்கி நகரத் தொடங்கியிருக்கும் போது, அது திடீரென இடம் மாறக்கூடும். உங்கள் backend 400ms-இல் பதிலளித்தாலும், ஒரு தடுமாறும் UI அந்தச் செயல்முறையை மெதுவாகவும் பாதுகாப்பற்றதாகவும் உணரச் செய்கிறது. உங்கள் ஆப் அமைதியான, தெளிவான சமிக்ஞைகளை வழங்கத் தவறுவதால், பயனர்கள் இன்பாக்ஸைத் தாங்களாகவே திறக்க வேண்டியிருக்கும்.

செயல்பாட்டை ஒரு வாசிப்புத் தொடராக (Reading Sequence) மறுபரிசீலனை செய்யுங்கள்

Email confirmation-ஐ loading மற்றும் success நிலைகளுக்கு இடையிலான ஒரு toggle ஆகப் பார்ப்பதை நிறுத்துங்கள். பயனர் ஒரே பார்வையில் உள்வாங்கும் ஒரு வாசிப்புத் தொடராக அதைப் பாருங்கள். உங்களிடமே நான்கு குறிப்பிட்ட கேள்விகளைக் கேட்டுக்கொள்ளுங்கள்.

கிளிக் செய்தவுடன் அந்த நபர் உடனடியாகப் பார்ப்பது என்ன? பதில் 'ஒன்றுமில்லை' என்றோ அல்லது பொத்தான் அப்படியே உறைந்துவிட்டாலோ (freezes), நீங்கள் ஏற்கனவே அவர்களை இழந்துவிட்டீர்கள் என்று அர்த்தம். சிஸ்டம் அந்தத் தகவலைப் பெற்றுக்கொண்டது என்று சொல்லும் ஒரு உடனடி, உள்ளூர் மாற்றம் (local change) இருக்க வேண்டும்.

ஒரு screen reader என்ன அறிவிக்கிறது? ஒரு கண்ணியமான, இடையூறு செய்யாத update, பயனர் தற்போதைய சூழலைத் தொடர அனுமதிக்கிறது. அந்த அறிவிப்பு ஒரு siren போல இல்லாமல், ஒரு footnote போல இருக்க வேண்டும்.

காத்திருக்கும் போது layout எவ்வளவு நகர்கிறது? சிறந்த முறையில், பூஜ்ஜியம். பயனர் வருவதற்கு முன்பே ஒதுக்கப்பட்ட இடத்தையே waiting state ஆக்கிரமித்திருக்க வேண்டும்.

மின்னஞ்சல் அனுப்ப நேரம் எடுத்தால் என்ன குறிப்புத் தெரியும்படி இருக்கும்? நெட்வொர்க்குகள் தடுமாறலாம். கோரிக்கை (request) சில விநாடிகளுக்கு மேல் நீடித்தால், ஏதோ ஒன்று நடந்து கொண்டிருக்கிறது என்பதைப் பயனர் அறிவார்களா, அல்லது அந்த அமைதி அவர்களைப் பதற்றமடையச் செய்கிறதா? ஒரு நிலையான, அமைதியான indicator பதற்றத்தைத் தவிர்க்கிறது.

அமைதியான உறுதிப்படுத்தல் feedback-க்கான நான்கு விதிகள்

நான்கு நடைமுறை கட்டுப்பாடுகளைப் பின்பற்றுவதன் மூலம் பெரும்பாலான உறுதிப்படுத்தல் செயல்பாடுகளை நீங்கள் சரிசெய்யலாம்.

செயலுக்கு அருகிலுள்ள ஒரு நிலையான பகுதியில் செய்தியை வைத்திருங்கள். Feedback தேவைப்படுவதற்கு முன்பே அதற்கான இடத்தைப் ஒதுக்கி வையுங்கள். ஒரு குறிப்பிட்ட min-height கொண்ட container அல்லது செய்தி ஸ்லாட்டைத் தாங்கும் CSS grid row-வைப் பயன்படுத்துங்கள். உரை தோன்றும் போது, அது சுற்றியுள்ள உள்ளடக்கத்தைத் தள்ளக்கூடாது. அந்தச் செயல் எங்கு நிகழ்ந்ததோ, அங்கேயே உறுதிப்படுத்தலும் இருக்க வேண்டும்.

அணுகல்தன்மைக்காக (accessibility) role="status" மற்றும் aria-live="polite" ஆகியவற்றைப் பயன்படுத்தவும். உங்கள் மார்க்அப்பில் முதல் ரெண்டரிலிருந்தே இருக்கும் ஒரு லைவ் ரீஜியனை (live region) உருவாக்கவும். நிலை (state) மாறும்போது, React அந்தப் பகுதிக்குள் இருக்கும் டெக்ஸ்ட் நோடைப் புதுப்பிக்கும். ஸ்கிரீன் ரீடர்கள் கீபோர்டு ஃபோகஸைத் திருடாமலோ அல்லது பயனரைத் தொந்தரவு செய்யாமலோ அந்த மாற்றத்தை அறிவிக்கும். சாதாரண உறுதிப்படுத்தல்களுக்கு ஒருபோதும் aria-live="assertive" என்பதைப் பயன்படுத்த வேண்டாம். அது சத்தமாக கத்துவதற்குச் சமம்.

பட்டனை அன்மவுண்ட் (unmount) செய்ய வேண்டாம். ஒரு செய்தியைக் காட்ட பட்டனை DOM-லிருந்து நீக்கும்போது, நீங்கள் கீபோர்டு பயனர்களைக் குழப்பமடையச் செய்கிறீர்கள். அவர்களின் ஃபோகஸ் மறைந்துவிடும். ஸ்கிரீன் ரீடர்கள் தெரியாத மேல்நிலை உறுப்புகளில் (ancestors) வந்துவிடும். அதற்குப் பதிலாக, பட்டனை மவுண்ட் செய்யப்பட்ட நிலையிலேயே வைத்திருக்கவும். aria-disabled மூலம் அதை முடக்கி (disable), அதன் லேபிளை "Sending..." அல்லது "Sent" என மாற்றவும், அல்லது ஒரு கவுண்ட்டவுன் டைமராக மாற்றவும். அந்த உறுப்பு (element) அங்கேயே இருக்கும், அதன் நிலை மட்டுமே மாறும்.

prefers-reduced-motion-ஐ மதிக்கவும். அனைவரும் கொண்டாட்டங்களை விரும்பவில்லை. எந்தவொரு மாற்றங்களையும் (transitions) ஒரு மீடியா குவெரியில் (media query) வைக்கவும். பயனர் தனது இயக்க முறைமையிடம் (operating system) இயக்கத்தைக் குறைக்கக் கேட்டிருந்தால், அவர்களுக்கு உடனடி உரை மாற்றம் அல்லது மென்மையான ஒபாசிட்டி ஃபேட் (opacity fade) மாற்றத்தைக் கொடுக்கவும். குதிப்புகள், சுழற்சிகள் அல்லது ஸ்லைடுகள் வேண்டாம். இயக்கத்தைக் குறைப்பது என்பது பொருளைக் குறைப்பது அல்ல.

செயல்படும் ஒரு நிலையான முறை

சிறந்த முறை சலிப்படையச் செய்யும் வகையில் இருப்பதுதான் அதன் நோக்கம்.

முதல் ரெண்டரிலிருந்தே செய்திக்கான இடத்தைத் ஒதுக்கி வைக்கவும். பட்டனுக்குக் கீழே நேரடியாக ஒரு சிறிய, காலியாக இருக்கும் கொள்கலனை (container) வைக்கவும். அதற்கு ஒரு நிலையான அல்லது குறைந்தபட்ச உயரத்தைக் கொடுங்கள், அப்போதுதான் உரை உள்ளீடு செய்யும்போது அடுத்த பகுதி கீழே தள்ளப்படாது. குளோபல் டோஸ்ட்களைப் (global toasts) பயன்படுத்துவதற்குப் பதிலாக, பின்னூட்டத்தை (feedback) பட்டனுக்கு அருகிலேயே வைத்திருக்கவும். டோஸ்ட்கள் கணினி முழுவதிலும் ஏற்படும் பிழைகளுக்குப் பயனுள்ளவை, ஆனால் ஒரு சாதாரண மின்னஞ்சல் உறுதிப்படுத்தலுக்கு அவை கவனத்தைச் சிதறடித்து, கண்களைத் தேட வைக்கும்.

குறைந்தபட்ச இயக்கத்தைப் பயன்படுத்தவும். நீங்கள் அனிமேட் செய்ய வேண்டுமென்றால், மாற்றங்களை இருநூறு மில்லிசெகண்டுகளுக்குக் குறைவாக வைத்திருக்கவும், மேலும் அவற்றை ஒபாசிட்டி அல்லது மென்மையான நிற மாற்றத்திற்கு மட்டுமே வரம்புப்படுத்தவும். லேஅவுட் மறுகணக்கீட்டிற்கு (layout recalculation) வழிவகுக்கும் பிளாக்-லெவல் எலிமெண்ட்களைச் சேர்ப்பதையோ அல்லது நீக்குவதையோ தவிர்க்கவும். பட்டனுக்குள்ளேயே ஒரு லோடிங் நிலையை (loading state) காட்ட வேண்டுமென்றால், ஒரு எளிய உரை மாற்றம் அல்லது நிலையான ஐகானைப் பயன்படுத்தவும். பட்டனின் அளவை மாற்ற வேண்டாம், அதை ஆட்ட வேண்டாம், மற்றும் திரையை மின்னச் செய்ய வேண்டாம்.

வெற்றி நிலை (success state) வரும்போது, ஒரு சிறிய, நிலையான குறிப்பைக் காட்டவும். "Check your inbox" என்பது போதுமானது. அதை மூன்று வினாடிகளுக்குப் பிறகு தானாகவே மறைந்துவிட (auto-dismiss) விடாதீர்கள். தவறான நேரத்தில் பார்வையைத் திருப்பிய பயனர், என்ன நடந்தது என்று குழப்பமடைய வேண்டிய அவசியமில்லை.

இது ஏன் நேரத்தை மிச்சப்படுத்துகிறது

இந்தச் சிறிய விவரங்களை நீங்கள் சரிசெய்யும்போது, உங்கள் உள்கட்டமைப்பு பட்ஜெட்டுடன் (infrastructure budget) தொடர்பில்லாத உண்மையான முடிவுகளைப் பார்ப்பீர்கள்.

ஒரே பட்டனில் குறைவான இரட்டை கிளிக்குகள் (double clicks). முடக்கப்பட்ட நிலை (disabled state) மற்றும் உள்ளூர் பின்னூட்டம் (local feedback), முதல் கிளிக் பதிவு செய்யப்பட்டதைத் தெளிவாக உணர்த்தும்.

'Send' என்பதைக் கிளிக் செய்த பிறகு செயல்முறையை (flow) பாதியிலேயே விட்டுச் செல்லும் பயனர்கள் குறைவு. அமைதியான சிக்னல்கள் சிஸ்டம் வேலை செய்கிறது என்பதை மூளைக்குத் தெரிவிப்பதால், பயனர்கள் காத்திருப்பார்கள்.

மின்னஞ்சல் உண்மையில் வந்தும், வரவில்லை என்று புகார் செய்யும் சப்போர்ட் டிக்கெட்டுகள் (support tickets) குறையும். அந்த டிக்கெட்டுகளில் பெரும்பாலானவை மின்னஞ்சல் விடுபட்டதால் அல்ல, இடைமுகப் பதற்றத்தினால் (interface panic) ஏற்படுபவை.

வேகமாக உணரப்படும் செயல்திறன் (perceived performance). ஒரே மாதிரியான தாமதங்கள் (latencies) இருந்தாலும், ஒரு நிலையான UI எப்போதும் குழப்பமான ஒன்றை விட வேகமானதாகத் தோன்றும்.

இதைக் கண்காணிக்க உங்களுக்கு சிக்கலான கருவிகள் தேவையில்லை. நகல் கோரிக்கைகளுக்காக (duplicate requests) உங்கள் எரர் லாக்ஸ்களைப் (error logs) பார்க்கவும். உங்கள் சப்போர்ட் கியூவைக் (support queue) கவனிக்கவும். உறுதிப்படுத்தல் திரையில் பயனர்களின் தக்கவைப்பு (retention) மூலம் நிலைத்தன்மையைக் கணக்கிடவும். அமைதியான, கணிக்கக்கூடிய இடைமுகம் (predictable interface), சிஸ்டம் என்ன செய்கிறது என்பதைத் தெரிந்து வைத்திருக்கிறது என்பதைக் குறிக்கிறது. அந்தத் துல்லியமான கணிக்கக்கூடிய தன்மையே நம்பிக்கையை உருவாக்குகிறது.