इंटरफेस डिज़ाइन के स्वर्ण नियम (2013)

 (cs.umd.edu)
4 पॉइंट द्वारा GN⁺ 2024-01-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Ben Shneiderman के इंटरफेस डिज़ाइन के 8 सिद्धांत अधिकांश interactive systems पर लागू किए जा सकने वाले व्यावहारिक मानदंड हैं, लेकिन हर design domain में उनकी जाँच और समायोजन की आवश्यकता होती है
  • सुसंगत terminology और behavior, universal usability, और informative feedback ऐसे बुनियादी तत्व हैं जो उपयोगकर्ताओं को state changes का अनुमान लगाने और उन्हें समझने में मदद करते हैं
  • workflow को शुरुआत·मध्य·अंत वाली इकाइयों में व्यवस्थित करना चाहिए, और completion के समय स्पष्ट confirmation देना चाहिए ताकि उपयोगकर्ता आसानी से अगले action पर बढ़ सकें
  • error prevention को प्राथमिकता देनी चाहिए, और error होने पर ठोस recovery guidance तथा आसान undo देकर उपयोगकर्ता की चिंता कम करनी चाहिए
  • अगर control की भावना और कम memory load को केंद्र में रखा जाए, तो mobile, desktop, और web interfaces में productivity और mastery की भावना बढ़ाई जा सकती है

सिद्धांतों की प्रकृति और लागू होने का दायरा

  • Ben Shneiderman ने user interface design के विशाल ज्ञान को कुछ Golden Rules में संक्षेपित किया और उन्हें अधिकांश interactive systems पर लागू किए जा सकने वाले दिशानिर्देशों के रूप में व्यवस्थित किया
  • ये सिद्धांत अनुभव से निकले हैं और 30 से अधिक वर्षों में परिष्कृत किए गए हैं, लेकिन कुछ विशेष design domains में अलग से validation और adjustment की आवश्यकता होती है
  • 1985 की शुरुआती सूची भी छात्रों और designers के लिए उपयोगी मार्गदर्शिका मानी गई, और Jakob Nielsen, Jeff Johnson आदि ने इसमें बदलाव और विस्तार जोड़े
  • यह संस्करण Designing the User Interface: Strategies for Effective Human-Computer Interaction: Sixth Edition के section 3.3.4 में शामिल है

इंटरफेस डिज़ाइन के 8 स्वर्ण नियम

  • सुसंगतता बनाए रखें

    • मिलती-जुलती परिस्थितियों में actions का क्रम सुसंगत होना चाहिए
    • prompts, menus, और help screens में एक जैसी terminology का उपयोग होना चाहिए
    • रंग, layout, capital letters का उपयोग, और fonts भी पूरे interface में सुसंगत होने चाहिए
    • delete command confirmation या password input को छिपाने जैसे अपवाद समझ में आने वाले और सीमित होने चाहिए

  • universal usability का समर्थन करें

    • विभिन्न उपयोगकर्ताओं की ज़रूरतों को पहचानते हुए ऐसा flexible design चाहिए जो content transformation को आसान बनाए
    • beginners और experts का अंतर, आयु समूह, disabilities, international differences, और technology diversity requirements के दायरे को बढ़ाते हैं
    • beginners के लिए explanation, और experts के लिए shortcuts तथा तेज़ progression features, interface quality की धारणा को बेहतर बनाते हैं

  • informative feedback दें

    • हर user action के साथ interface feedback होना चाहिए
    • बार-बार होने वाले छोटे actions के लिए साधारण response पर्याप्त है, लेकिन दुर्लभ और महत्वपूर्ण actions के लिए अधिक ठोस response आवश्यक है
    • अगर focus object को visually दिखाया जाए, तो changes को स्पष्ट रूप से दिखाना आसान हो जाता है

  • पूर्णता का एहसास देने वाला dialog flow डिज़ाइन करें

    • tasks के sequence को शुरुआत, मध्य, और अंत वाले समूहों में व्यवस्थित करना चाहिए
    • जब किसी task group का अंत होता है, तो informative feedback उपलब्धि, राहत, और अगले task की तैयारी का संकेत देता है
    • e-commerce websites में product selection से payment तक जाना और फिर स्पष्ट confirmation page के साथ transaction समाप्त करना इसका एक उदाहरण है

  • errors को रोकें

    • interface को जहाँ तक संभव हो इस तरह डिज़ाइन करना चाहिए कि उपयोगकर्ता गंभीर errors कर ही न सकें
    • जैसे अनुपयुक्त menu items को disable करना, या numeric input field में alphabetic characters को अनुमति न देना
    • यदि error हो जाए, तो सरल, रचनात्मक, और ठोस recovery instructions देनी चाहिए
    • किसी एक गलत postal code की वजह से पूरे name·address form को फिर से भरवाने के बजाय, केवल गलत हिस्से को ठीक करने के लिए मार्गदर्शन देना चाहिए
    • गलत action या तो interface state को बदले नहीं, या फिर state restore करने का तरीका साथ में दे

  • आसान undo की अनुमति दें

    • जहाँ तक संभव हो, actions reversible होने चाहिए
    • undo उपयोगकर्ताओं को यह भरोसा देता है कि वे errors रद्द कर सकते हैं, जिससे चिंता कम होती है और वे अनजाने विकल्पों को भी explore कर पाते हैं
    • undo की इकाई single action, data entry task, या name·address block जैसे task group हो सकती है

  • उपयोगकर्ता के हाथ में control बनाए रखें

    • experienced users यह गहराई से महसूस करना चाहते हैं कि वे interface को नियंत्रित कर रहे हैं और interface उनके actions पर प्रतिक्रिया दे रहा है
    • अप्रत्याशित बदलाव, परिचित behavior में परिवर्तन, उबाऊ data entry, आवश्यक जानकारी पाने में कठिनाई, और इच्छित परिणाम न बना पाने की स्थिति उपयोगकर्ताओं को असहज बनाती है

  • short-term memory load कम करें

    • मनुष्यों की short-term memory की information processing क्षमता सीमित होती है, और thumb rule के अनुसार लगभग “7±2 chunks” याद रखे जा सकते हैं
    • ऐसे interfaces से बचना चाहिए जहाँ उपयोगकर्ता को एक screen की जानकारी याद रखकर दूसरी screen पर उसका उपयोग करना पड़े
    • mobile phones को phone number दोबारा भरने की आवश्यकता नहीं होनी चाहिए, website location लगातार दिखनी चाहिए, और लंबे forms को एक screen में समेटा जाना चाहिए

डिज़ाइनर के लिए व्यावहारिक मानदंड

  • इन सिद्धांतों की हर environment के अनुसार व्याख्या·परिशोधन·विस्तार किया जाना चाहिए
  • सीमाएँ होने के बावजूद, ये mobile, desktop, और web designers के लिए एक अच्छा शुरुआती बिंदु हैं
  • simplified data entry, समझ में आने वाली presentation, और तेज़ तथा informative feedback उपयोगकर्ता की productivity बढ़ाने पर केंद्रित हैं
  • एक अच्छा interface उपयोगकर्ता को system के प्रति सक्षम होने·दक्षता होने·control होने की भावना दिलाने में मदद करना चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-11
Hacker News की रायें

  • UI के "design" में जरूरी तौर पर शामिल नहीं माना जाता, लेकिन performance भी अक्सर नज़रअंदाज़ हो जाती है
    खराब performance वाला UI इन सभी design rules को तोड़ने जैसा है। मेरा Sony Android smart TV दिखने में शानदार है, लेकिन UI इतना धीमा है कि असल में इस्तेमाल के लायक नहीं
    लगातार बदलता रहने वाला अस्थिर UI भी ज़्यादातर principles तोड़ता है। smart TV इस मामले में भी खास तौर पर खराब हैं; home screen layout और app icon की जगहें बिना किसी खास वजह के अक्सर बदल जाती हैं
    इसके अलावा, मेरी एक निजी शिकायत जो लगातार बढ़ती जा रही है, वह है बिना label वाले icons। अक्सर tooltip तक नहीं होता, और अगर button का नाम जानने के लिए documentation को Google करना पड़े, तो वह UI design खराब है

    • Snapchat के बहुत popular होने के बाद से मुझे लगने लगा कि खराब UI Gen Z feature है
      इस्तेमाल में मुश्किल interface की ओर युवा users खिंचते हैं, और उसकी जटिलता parents वाली generation को बाहर रखने वाले insider feature की तरह काम करती है
    • Performance design का हिस्सा है
      अच्छा designer developers से चर्चा करता है कि उसके proposed UI का performance पर क्या असर पड़ेगा, और जब engineering ऐसे technical फैसले लेती है जो user को दिखेंगे, तो trade-offs में मदद करता है
    • बिना label वाले icons के लिहाज से मैंने जो सबसे खराब software इस्तेमाल किया है, वह CATIA V5 था
      UI में न सिर्फ सैकड़ों छोटे icons थे, बल्कि documentation में भी उन्हीं icons का वैसे ही इस्तेमाल किया गया था। manual कुछ ऐसा था: "पहले [] click करें, फिर [] दबाएँ, और आखिर में [] पर जाकर [] करें"
      यह V5 के बहुत शुरुआती version की बात है, काफी पुरानी, उम्मीद है अब बेहतर हो गया होगा
    • UI design failure की सबसे बड़ी वजह users और requirements से अलग-थलग पड़ जाना है
      बाकी सब लगभग coding जैसा है
    • Spotify भी home screen layout और app icon की जगहें अक्सर बदलता है
      मैं हर सुबह वही दो news podcasts सुनता हूँ, लेकिन app की recommendations हर सुबह बिना किसी वजह के उलट-पुलट हो जाती हैं
      इससे भी ज्यादा चिढ़ाने वाली बात यह है कि app start होते समय एक पल के लिए कल वाला layout दिखाता है, फिर loading के कारण करीब 1 second रुकता है और फिर items को rearrange कर देता है। उसी क्षण हर बार हिलते हुए item पर गलत tap हो जाता है, जो बेहद frustrate करने वाला है

  • कुछ साल पहले साथ काम कर चुके एक designer ने बहुत अच्छे से समझाया था कि consistency क्यों महत्वपूर्ण है
    यह limited colour palette या ऐसे font choice का मामला नहीं है जिसे कोई notice भी न करे। छोटी-छोटी rules के पीछे भागते-भागते software भयानक बन जाता है। कुछ लोग गलती से सोचते हैं कि UI में variety जितनी कम होगी, consistency उतनी ज्यादा होगी
    असली बात है user को उस software का expert बनने देना
    उस designer ने Microsoft Office का उदाहरण दिया था। लोग Microsoft Office को "जानने" पर गर्व महसूस करते हैं, और "Office" की inertia महसूस करते हैं, इसलिए कई apps के बीच सहजता से आते-जाते हैं। Vim में भी मुझे वैसा ही एहसास होता है। बस पता होता है कि कोई चीज़ कैसे काम करनी चाहिए, और अच्छी तरह बनाया गया नया plugin आम तौर पर उस pattern का सम्मान करता है
    Office और (Neo)Vim बेहतरीन UI के उदाहरण नहीं हैं, लेकिन वे असाधारण रूप से stable हैं

    • मैं designer नहीं हूँ, लेकिन हमेशा जिस बात पर जोर देता हूँ वह यह है कि users ने पहले से कहीं और सीखे हुए UI elements और concepts का इस्तेमाल करके proficiency को bootstrap करने की ताकत बहुत बड़ी है
      उदाहरण के लिए, चार choices दिखाते समय आप brand theme लगे [Insert UI Library] का searchable checkbox combo box इस्तेमाल कर सकते हैं, या बस label लगे हुए सामान्य radio buttons या checkboxes दिखा सकते हैं। दूसरा विकल्प हर लिहाज से बेहतर है
      users सिर्फ गोल और चौकोर shapes देखकर समझ सकते हैं कि एक ही विकल्प चुनना है या कई; वे चारों choices देख सकते हैं; mobile keyboard "search" करने के लिए ऊपर आकर छोटे screen को और नहीं ढकता; और accessibility भी हमेशा लगभग 100% रहती है
      लेकिन यह option "हमारे design system के साथ cute लगता है" वाले criterion में fail हो जाता है, इसलिए designers आम तौर पर पहला option चुनते हैं; और इससे भी खराब, उसी तरीके को standard बना देते हैं, जिससे सामान्य widgets का इस्तेमाल "bug" बन जाता है
      नतीजा यह कि बहुत सारे "UX designers" aesthetics और branding की पूजा करते हैं और बाकी सब कुछ कुर्बान कर देते हैं। UI widgets brand या creativity दिखाने की जगह नहीं हैं। यह वैसा ही है जैसे हर अक्षर को logo जैसा बनाने के लिए custom font बना देना—ऐसा नहीं करना चाहिए। customers के लिए brand से ज्यादा जरूरी है कि वे अपना काम पूरा कर सकें
    • जब Microsoft ने सबसे plausible options ही दिखाते हुए "help" करने वाला adaptive ribbon पेश किया, तो कई लोगों के नाराज़ होने की एक वजह यह हो सकती है
      इसने जरूरी feature ढूँढने की क्षमता को काफी नुकसान पहुँचाया
    • user को software का expert बनने देना—यह वाक्यांश सच में शानदार है
      खुद को technical न मानने वाले किसी व्यक्ति को Excel में बेहद तेज़ी से काम करते देखना हमेशा खास होता है
      Microsoft के UI design rules काफी कमाल के हैं। वर्षों की consistency की वजह से लोग हर 1–2 साल में upgrade करने के बाद भी software इस्तेमाल करते रह सकते हैं। मैं यह Microsoft fan होने के कारण नहीं कह रहा
      upgrade का मूल उद्देश्य UX सुधारने वाले incremental changes हैं। हालांकि मुझे समझ नहीं आता कि जब Win 95 ने "कहीं भी right-click करने पर properties और deeper settings/details" का concept लाया, तो design team ने उसे reject क्यों नहीं किया। क्योंकि यह ऐसी invisible feature थी जो user को दिखाती ही नहीं थी कि right-click किया जा सकता है। Win 95 को शुरुआती कुछ बार इस्तेमाल करते समय शायद किसी को right-click समझ नहीं आया था
    • Programming language designer होने के कारण मैं इन समस्याओं के बारे में रोज़ सोचता हूँ
      मैं मानता हूँ कि proficiency relevant है, लेकिन consistency कैसे proficiency में बदलती है, इसे थोड़ा और जोड़कर समझाने की जरूरत लगती है
      Consistency का मतलब है कि user system के बारे में जो पहले से जानता है, उसे system के दूसरे हिस्सों तक compound interest की तरह फैलाना। अगर system consistent है, तो X और Y सीखने में लगाई गई मेहनत से Z और W भी समझ आ जाते हैं, क्योंकि वे उसी तरह काम करेंगे। inconsistent system में पहले की learning investment से मिलने वाला value बहुत कम हो जाता है
    • consistency की अहमियत से सहमत हूँ, लेकिन "Office और (Neo)Vim बेहतरीन UI नहीं हैं, लेकिन असाधारण रूप से stable हैं" इस बात से सहमत नहीं हूँ
      Office कम-से-कम long term में stable नहीं है। बदनाम ribbon stable और efficient Word UI से दुखद विचलन था, और Windows platform में Microsoft की समझ से परे regression ने समस्या और बढ़ा दी। उदाहरण के लिए applications से menu bar हटाना। आखिर उन्होंने ऐसा क्यों किया, समझ नहीं आता

  • एक और "नियम" जो मुझे लगता है कि होना चाहिए, वह है conceptual model को यूज़र के सामने उजागर करना
    अगर कोई व्यक्ति product के conceptual model को नहीं समझता, तो icon labels कितने भी अच्छे क्यों न हों, वह हमेशा उलझेगा। उदाहरण के लिए, किसी product की कल्पना करें जिसमें "New Configuration" command हो; सबसे पहले तो यह ही अस्पष्ट है कि "Configuration" क्या है। क्या यह कोई template है जिससे दूसरे objects define किए जाते हैं? कई options के bundles के बीच तेज़ी से switch करने का तरीका है? या folder जैसा कोई container है?
    UI ऐसा design होना चाहिए कि यूज़र केवल interface explore करके conceptual model का अनुमान लगा सके। यह हमेशा आसान काम नहीं होता

    • अच्छे interface का उद्देश्य implementation details छिपाते हुए यूज़र को उसके लक्ष्य तक guide करना है

  • "उदाहरण के लिए, जब यूज़र गलत postal code डालता है, तो उससे पूरा name-address form दोबारा न भरवाएं; सिर्फ गलत हिस्से को ठीक करने के लिए guide करें" वाला हिस्सा मेरी सबसे बड़ी शिकायत है, और यह आज भी अक्सर दिखता है
    multi-page forms में भी आगे-पीछे जाते समय यह सिद्धांत लागू रहना चाहिए
    "गलत action से interface state नहीं बदलनी चाहिए, और अगर बदल गई हो तो मूल state में लौटने का तरीका बताना चाहिए" भी महत्वपूर्ण है
    मोबाइल फोन और watch जैसे छोटे screens पर space बचाने की कोशिश में designers increasingly icons पर निर्भर हो रहे हैं। लेकिन कई icons अपरिचित होते हैं या समझने में मुश्किल होते हैं, और कभी-कभी तो दबाकर ही पता चलता है। ऐसे icons में गलती होने पर मूल state में वापस जाने का तरीका जरूर होना चाहिए

    • सही। अगर "Corvallis" डालें तो "Oregon या Montana?" पूछ लेना चाहिए, और अगर "97330" डाल दिया है तो बाकी बस skip कर देना चाहिए
    • सच में चिढ़ होती है
      email address और password से login करने की कोशिश करते समय भी यह पहले से एक समस्या है, लेकिन अगर मैंने "Forgot password" दबाया है, तो कृपया मुझे ऐसे form पर न भेजें जो अभी-अभी डाला हुआ वही email address फिर से मांगता हो

  • "अनुपयुक्त menu items को grey out करें" वाली बात पर एक शर्त है
    अगर grey out होने की वजह स्पष्ट नहीं है, तो ऐसा नहीं करना चाहिए। command को enabled रखें, और click करने पर अगर वह अभी इस्तेमाल नहीं हो सकती तो error message में बताएं कि क्यों नहीं हो सकती। यूज़र से यह पता लगवाना कि command disabled क्यों है, परेशान करने वाला है
    अपवाद वह स्थिति है जहां यूज़र के बहुत समय बर्बाद करने के बाद ही यह बताया जाने की बड़ी संभावना हो कि यह इस्तेमाल नहीं हो सकती
    संबंधित और पढ़ने के लिए: https://medium.com/@vedranio/james-bond-and-the-design-of-di...

    • menu item को grey out करके, click करने पर वही explanatory message दिखा दें तो कैसा रहेगा?
      यह दोनों तरफ के फायदे लेने का तरीका लगता है
    • फिर भी यूज़र के click करने से पहले यह बताने वाला consistent visual cue होना चाहिए कि वह action disabled है
    • एक अपवाद है: paid premium features
      एक to-do app ऐसा करता है। premium commands visually free commands से अलग नहीं दिखते, इसलिए वे बार-बार click हो जाते हैं, और हर बार पूरे flow को रोकने वाला signup prompt dialog खुल जाता है
      मेरे हिसाब से यह गंभीर UI error है
    • button को grey out रखें, लेकिन hover करने पर यह बताने वाला tooltip लगा दें कि इसे click क्यों नहीं किया जा सकता, कैसा रहेगा
    • सहमत नहीं। मौजूदा context में असंभव actions को disable करना मददगार होता है। बस क्यों, यह समझाना जरूरी है
      जो UI वजह बताए बिना सिर्फ कुछ actions को disable करता है, वह हमेशा गुस्सा दिलाता है

  • Nielsen की 10 usability heuristics अच्छी north star का काम करती हैं

    1. system status की visibility
    2. system और real world का match
    3. user control और freedom
    4. consistency और standards
    5. error prevention
    6. याद रखने की बजाय recognition
    7. flexibility और efficiency of use
    8. aesthetic और minimalist design
    9. error recognition, diagnosis, और recovery
    10. help और documentation
      https://www.nngroup.com/articles/ten-usability-heuristics/
    • इस Nielsen-Norman page और original page में फर्क साफ दिखता है
      NN page में information absorb करना कहीं आसान है, वह ज्यादा concise है, और page layout भी कहीं बेहतर है
      दोनों लेखों में सुनने लायक information और direction है, लेकिन irony यह है कि original page ने वही पुराने समान font size और paragraph conventions अपनाए हैं जिन्हें NN page ने छोड़ दिया है
      Hacker News भी इस information के कुछ हिस्से follow नहीं करता, यह frustrating है। मौजूदा comment edit करते समय "update" button दबाने के बाद feedback पर्याप्त स्पष्ट नहीं होता। शायद screen redraw होती है

  • ऐसी UI बंद होनी चाहिए जो जहां मैं अभी select करने वाला था, वहीं कुछ और डालकर गलत click करा देती है
    यह ऊपर के कुछ rules का उल्लंघन हो सकता है या शायद कम किया जा सकने वाला problem हो, लेकिन व्यक्तिगत रूप से यह सच में पागल कर देने वाली चीज है और मैं इसे खास तौर पर गंभीर गलती मानता हूं

    • Jira में story assignee बदलने की कोशिश करते समय दिखने वाला Unassigned/Automatic selection खास तौर पर याद आता है

  • एक महत्वपूर्ण rule छूट गया है। कभी यह इतना obvious लगता था कि static information और controls को अलग करना चाहिए
    साथ ही, जो controls लागू नहीं हो सकते उन्हें छिपाने के बजाय grey out करना चाहिए। इससे यूज़र सीखता है कि वह feature मौजूद है, कहां है, और उसे इस्तेमाल करने के लिए कौन-सी conditions पूरी करनी होंगी
    इससे जुड़ी बात: ऐसे hide-and-seek UI पर कभी निर्भर नहीं होना चाहिए जिसमें कुछ केवल तब दिखता है जब यूज़र संयोग से cursor उस पर ले जाए। हमें काम पूरा करना है, Advent calendar explore नहीं करना

  • मैंने जो एक golden rule सीखा है, वह यह है कि interface render होने के बाद elements अप्रत्याशित रूप से move नहीं होने चाहिए
    Google में यह समस्या खास तौर पर खराब है, जहां अंगूठा उठाने और screen tap करने के बीच button move हो जाता है, लेकिन ऐसा सिर्फ Google में नहीं है

    • अच्छा हो अगर इसे operating system level पर handle किया जाए
      अगर target touch होने से लगभग 0.25 second के भीतर नया दिखाई दिया है, तो touch event generate नहीं होना चाहिए। इंसानी reaction speed के हिसाब से कोई इतने जल्दी button aim करके press नहीं कर सकता

  • ये साफ तौर पर यूटोपिया के सुनहरे नियम हैं
    ज़्यादातर लोग ऐसे नियमों के खिलाफ नहीं होंगे
    फिर भी ज़्यादातर developers ने ऐसे interfaces के साथ काम किया होगा जो इन नियमों को अक्सर तोड़ते हैं। इसलिए नहीं कि वे समझे नहीं या चाहते नहीं थे, बल्कि इसलिए कि उस समय इसकी लागत बहुत ज़्यादा थी
    उदाहरण के लिए, वापस किया जा सकना बहुत कठिन है, और यह तभी संभव है जब application के नीचे की data structure शुरू से ही इसे ध्यान में रखकर बनाई गई हो। error prevention भी वैसा ही है: असल में error क्या है, यह ठीक-ठीक जानना अपने-आप में कठिन और महंगा है, और user की भाषा में बेहतरीन feedback देना उससे भी कहीं ज़्यादा जटिल है