डिज़ाइन समझौता है

• अच्छा डिज़ाइन प्रतिस्पर्धी जरूरतों के बीच सही समझौता चुनने का काम है
• समझौता निर्णय लेना और प्राथमिकताएँ तय करना है; जिस पल आप एक चीज़ चुनते हैं, बाकी विकल्प स्वाभाविक रूप से बाहर हो जाते हैं
• ट्रेड-ऑफ वह संबंध है जिसमें किसी कमजोरी को स्वीकार कर ताकत हासिल की जाती है; एक तरफ जितना अधिक वजन देंगे, दूसरी तरफ उतनी कमजोर होगी
• बेहतरीन products स्पष्ट रूप से तय करते हैं कि वे किस चीज़ में अच्छे नहीं होंगे, और उसकी कीमत पर किसी खास क्षेत्र में उत्कृष्ट बनने वाला स्पष्ट दृष्टिकोण रखते हैं
• अगर आप हर व्यक्ति और हर feature को संतुष्ट करने की कोशिश करेंगे, तो किसी एक में भी उत्कृष्ट होना कठिन होगा; इसलिए target users के अनुरूप समझौता जरूरी है

---

समझौता डिज़ाइन का सार है

• समझौता अच्छा या बुरा नहीं, बल्कि रोज़ किया जाने वाला निर्णय लेना और प्राथमिकताएँ तय करना है
• यह दो प्रतिस्पर्धी जरूरतों के बीच संतुलन खोजने और यह तय करने की प्रक्रिया है कि कौन-सी तरफ ज्यादा महत्वपूर्ण है
• किसी product के बारे में यह दावा करना कि “कोई समझौता नहीं किया गया” या “कोई समझौता नहीं है”, संभव नहीं है
  • जैसे ही आप कोई खास approach चुनते हैं, दूसरे विकल्प बाहर हो जाते हैं
• अहम बात यह नहीं कि समझौता मौजूद है या नहीं, बल्कि यह है कि कौन-सा समझौता चुना गया

ताकत और कमजोरी, दोनों चुनने वाले products

• ट्रेड-ऑफ कमजोरी और ताकत के संबंध को दिखाता है
  • एक कमजोरी स्वीकार करने के बदले एक ताकत मिलती है
  • एक तरफ जितना ज्यादा वजन देंगे, दूसरे हिस्से उतने कमजोर होंगे
• स्पष्ट ट्रेड-ऑफ product की कमजोरियों को सामने लाता है, लेकिन ऐसे कठिन चुनाव करना ही डिज़ाइन की भूमिका है
• स्पष्ट पहचान वाले products यह साफ तय करते हैं कि वे किस चीज़ में अच्छे नहीं होंगे, और इसके बजाय दूसरे क्षेत्रों में कहीं बेहतर performance पाने की कोशिश करते हैं
• हर किसी को आकर्षित करना संभव नहीं है
  • अगर लक्ष्य wide range of features में हर जगह अच्छा product बनाना है, तो इसका मतलब है कि आपने किसी खास क्षेत्र में उत्कृष्ट न होने का चुनाव किया है
  • target users के लिए यह उचित चुनाव हो सकता है, लेकिन यह भी एक साफ समझौता है
• अच्छा डिज़ाइन स्पष्ट रुख के आधार पर target users के लिए सही समझौता चुनता है

[GN⁺]

Hacker News की रायें

• आजकल सिर्फ designers ही नहीं, बहुत से लोग समझौते को कमजोरी मानते हैं, लेकिन आप हमेशा वह नहीं पा सकते जो चाहते हैं
  मेरे करियर में समझौता करने की कला सबसे मूल्यवान क्षमताओं में से एक रही है, और आज भी मैं इसका इस्तेमाल टीम के साथ यथार्थवादी सहमति बिंदु खोजने में करता हूँ

  • यहाँ केवल इच्छाशक्ति की लड़ाई में जीत-हार पर ध्यान है, लेकिन ideas खुद भी टकरा सकते हैं या विरोधाभासी हो सकते हैं
    आकर्षक ideas भी गहराई से देखने पर अक्सर ठीक से स्थापित नहीं होते, इसलिए अकेले design करते समय भी implement हो सकने वाला system बनाने के लिए अप्रमाणित ideas से समझौता करना पड़ता है
  • मैं इसे उल्टा देखता हूँ। जैसे ही design प्रक्रिया को समझौता या रियायत जैसे शब्दों में बयान करते हैं, उसे इच्छाशक्ति की लड़ाई बना देते हैं
    design affordances, patterns, constraints और trade-offs से निपटता है; इसमें जरूरी नहीं कि किसी से बहस या टकराव हो। दी गई परिस्थितियों में सबसे अच्छा design खोजने का केवल एक ही तरीका नहीं होता, और सहमति खोजने की प्रक्रिया में भी विचारों को आपस में लड़वाने की जरूरत नहीं है
    feedback मिलते ही अगर आपको लगता है कि आपको मुकाबला करना होगा, तो समस्या design से ज्यादा टकराव-केंद्रित सोच में हो सकती है
  • वह गाना https://en.wikipedia.org/wiki/You_Can%27t_Always_Get_What_Yo... है
  • समझौता वह तरीका है जिसमें दोनों पक्ष हारते हैं, और मूल रूप से इसका मतलब दो पक्षों द्वारा मध्यस्थ के फैसले को मानने का वादा था
    कभी-कभी https://meta.wikimedia.org/wiki/The_Wrong_Version या Northern Ireland peace process की तरह समझौता सबसे अच्छा और जरूरी भी होता है। लेकिन फर्क को आधा-आधा बाँटने के बजाय अगर दोनों पक्ष मिलकर कोई creative समाधान खोजें जिसे दोनों पसंद करें, तो सभी जीत सकते हैं; और अक्सर दोनों ही चीजों को समझौता कह दिया जाता है
    समस्या को creative तरीके से सुलझाकर पारस्परिक लाभ पाने की बात पर downvote करने की वजह समझना मुश्किल है

• समझौता designer के toolbox का आखिरी उपाय होना चाहिए। पहले जिस समस्या को हल करना है उसका scope लगातार संकरा करें और सभी संभावनाएँ आजमाएँ; फिर जब सही समाधान न हो या समय खत्म हो जाए, तभी इसे चुनें
  समझौता अक्सर समस्या का scope ठीक से तय किए बिना, ऐसी समस्या को आंशिक रूप से हल करने का नतीजा होता है जिसे शुरू में हल करने की जरूरत ही नहीं थी। हालांकि एक समस्या हल करने के बदले दूसरी छोड़ने के अर्थ में यह सचमुच trade-off है

  • मेरा अनुभव अलग है। हर निर्णय किसी एक use case या principle को दूसरे से ऊपर रखता है
    अच्छा design तब निकलता है जब हर निर्णय में क्या महत्वपूर्ण है और क्या छोड़ा जा सकता है, यह कहने की vision और conviction हो
  • यह compromise की definition पर निर्भर करता है। अगर screen size, loading time और average user की attention span तक को compromise कहा जाए, तो पूरा design कई conditions को coordinate करने का काम है
    दूसरी ओर, अगर इसका मतलब management को खुश करने के लिए एक और floating ad footer जोड़ने जैसा compromise है, तो वह सचमुच आखिरी उपाय होना चाहिए
  • किसी को समस्या दें तो वह समाधान खोज सकता है, लेकिन dilemma दें तो समझौता लगभग अपरिहार्य हो जाता है

• बुनियादी premise से ही सहमत होना मुश्किल है। compromise और trade-off समानार्थी नहीं हैं
  compromise का उल्टा है कुछ लोगों को अलग-थलग करने की कीमत पर भी intended users के लिए ज्यादा सटीक मजबूत निर्णय लेना, और यह बल्कि बेहतरीन हो सकता है

  • हर decision में trade-off होता है, चाहे हम उसे पहचानें या नहीं
    मजबूत decision से बचना भी sharp differentiation के बजाय मन की शांति या non-alienation चुनने का decision है, इसलिए बस इंतजार करने के बजाय जानबूझकर trade-off चुनने की सलाह दूँगा
  • यह इस धारणा पर निर्भर करता है कि intended user base स्पष्ट है, और इसी तरह की धारणाओं ने research process में personas बनवाए
    लेकिन बहुत से designs ऐसे हैं जिन्हें किसी खास user group से आगे बढ़कर ज्यादा व्यापक reach करनी और alienation घटाना होता है। requirements का सही analysis करना मुश्किल है और लोगों की जरूरतें भी बदलती हैं, इसलिए संकरे target के लिए perfect product उल्टा खराब भी हो सकता है
    किसी खास हाथ के size/shape और gestures के लिए बनाया गया mouse अक्सर target users के लिए भी बदतर हो जाता है। ऐसा product ज्यादा सुविधाजनक होता है जिसमें grip और task-specific usage बदलने की गुंजाइश हो, और सबसे अच्छे mice आम तौर पर tolerant और flexible होते हैं। खासकर Apple trackpad और Kensington-style trackball हाथ की विशेषताओं से लगभग अप्रभावित रहते हैं

• अगर constraints fixed हैं, तो कई dimensions में trade-off चुनना पड़ता है, और वही compromise है
  लेकिन constraints fixed नहीं होते; उन्हें optimize किया जा सकता है या नई techniques खोजकर requirements की space को ही बदला जा सकता है। जैसे बेहतर compression algorithms और नए, तेज chips नए computations को संभव बनाते हैं, वैसे ही ज्यादा effort से compromise की boundaries भी खिसकाई जा सकती हैं

  • theory में सही है, लेकिन business में उलटी mindset ज्यादा उपयोगी रही
    जो potential constraint लक्ष्य से टकराता नहीं है, उसे actual constraint मानना चाहिए। theory में X, Y, Z को दोबारा बनाया जा सकता हो, फिर भी इस project में वास्तव में क्या संभव है यह देखना चाहिए, और मैं social constraints तक को वास्तविक constraints मानकर management को बताता हूँ

• Scott Jenson की The Simplicity Shift पढ़कर मेरी जिंदगी का turning point आया
  यह उस समय लिखी गई किताब है जब mobile UI बहुत सीमित था; इसमें priority तय करने और design की completeness बनाए रखते हुए usable और affordable UI बनाने के compromises की बात है। दूसरों के साथ collaborate करके अच्छी तरह काम करने वाला common ground खोजने के तरीके भी इसमें काफी बताए गए हैं
  https://jenson.org/The-Simplicity-Shift.pdf एक छोटा PDF है

• एक non-native speaker के तौर पर मेरे लिए compromise और trade-off बिल्कुल समान नहीं हैं, और इस लेख में दूसरा शब्द ज्यादा उपयुक्त लगता है
  trade-off सीधे दिखाता है कि एक goal के लिए design दूसरे goal की कीमत पर चुना जा रहा है, लेकिन compromise में यह अर्थ स्पष्ट रूप से शामिल नहीं होता

• मूल्य तब चाहिए होते हैं जब मुश्किल decisions लेने हों, केवल आसान decisions लेने हों तो नहीं
  लेकिन values भी आपस में टकराती हैं, इसलिए एक साथ केवल कुछ ही प्राथमिक हो सकती हैं। किसी संघर्ष कर रहे employee का ध्यान रखकर लिया गया decision उस customer के लिए बुरा हो सकता है जिसका schedule पहले ही late है, या उस value के लिए जो speed को महत्व देती है

• यह marketing phrasing पर निशाना है या किसी व्यापक cultural phenomenon की बात कर रहा है, यह स्पष्ट नहीं है
  goal हासिल करने के लिए वास्तव में किए जाने वाले compromises और customers के goals पर compromise नहीं करने का प्रचार करने वाली public-facing phrasing अलग चीजें हैं, इसलिए यह अलग समस्या नहीं लगती

• जरूरी नहीं। higher-level design layering या ज्यादा sophisticated mechanisms के जरिए दोनों पक्षों के लाभ बचाते हुए दिखाई देने वाले tension और opposition को हल कर सकता है
  convenience और security में से एक चुनकर diluted compromise point खोजना naive design है। अच्छा design यह है कि security को convenience के ऊपर इस तरह layer किया जाए कि user को किसी एक को चुनना या कमजोर करना न पड़े, और बेहतरीन कंपनियों ने दिखने वाले विरोधाभासों को design से हल किया है

  • आजकल दोनों use cases को अच्छी तरह पूरा करने वाले समाधान को भी perfect compromise कहा जाता है
    compromise की etymology रियायत से आई है, इस तथ्य से अलग, यह language preference का फर्क ज्यादा लगता है
  • कभी-कभी अच्छे design में कोई compromise बिल्कुल नहीं होना चाहिए
    NO choice की अनुमति न देने के नतीजे दिखाने वाला प्रतिनिधि उदाहरण 737 MAX disaster है

• शब्दों के अर्थ बार-बार बदलकर इस्तेमाल किए गए हैं, जिससे लेख पढ़ना मुश्किल हो जाता है