قانون تسلر (Tesler’s Law) یا اصل حفظ پیچیدگی
برای هر سیستم، مقدار مشخصی از سادگی وجود داره که نمی تونیم افزایشش بدیم، در عوض، باید در توسعه ی محصول یا در تعاملِ با کاربر، باهاش برخورد بشه.
سوال اساسی اینه که چه کسی باید با این پیچیدگی ذاتی برخورد کنه؟ کاربر یا تیم توسعه ی محصول؟ این مسئله موقع در نظر گرفتن طراحی رابط های کاربری و به طور گسترده تر نحوه ی تعامل انسان ها با فناوری، یک سوال اساسیه. هدف اصلی ما به عنوان طراح،کاهش پیچیدگی خدمات و محصولات ساخته ی ما، برای کاربرهاست. اما در هر فرایند پیچیدگی ذاتی وجود داره و به ناچار به نقطه ای می رسیم که نمیشه پیچیدگی رو کاهش داد و فقط از مکانی به مکان دیگه منتقل میشه. توی این مرحله، پیچیدگی ذاتی یا در رابط کاربری یا در فرایندها و گردش کار طراح ها و توسعه دهنده ها راه پیدا می کنه.
ریشه های قانون تسلر رو میشه در اواسط دهه ی ۱۹۸۰ جستجو کرد، زمانی که Larry Tesler، خالق تعامل ماندگار (Copy/Paste) دانشمند کامپیوتر شرکت زیراکس PARC متوجه شد، نحوه ی تعامل کاربر با یک برنامه به اندازه ی عملکرد برنامه اهمیت داره. بعدها، لری به اپل پیوست و روی توسعه ی چارچوب شی گرای MacApp کار کرد، در اون جا بود که تفکرش در مورد پیچیدگی و نرم افزار رو رسمی کرد و شاید براتون جالب باشه که بدونید این دیدگاه رو یه اپل فروخت.
برآورد ارزش (یا هزینه) برای کاربر
هم در تجربه کاربر و هم در مدیریت محصول، الگوهایی رو در اطراف کار و تعامل با دیگران مشاهده می کنیم. یکی از این الگوها اینه که ساده سازی یک سیستم برای کاربرها اغلب به معنای انتقال پیچیدگی به بخش دیگه ای از سیستمه. زمان حذف پیچیدگی کاربر، این پیچیدگی از سیستم حذف نمیشه بلکه از کاربرها به تیم توسعه منتقل میشه. شما وقتی به عنوان یک مدیر محصول، بین طراح تجربه ی کاربر و یک توسعه دهنده قرار می گیرید، این موضوع به طور کامل براتون شفاف میشه، اون ها به دنبال این هستن که شما تصمیم بگیرید آیا انتقال پیچیدگی به سمت سیستم باشه یا کاربر؟
با مشاهده ی مداوم این الگوها، میشه نتیجه گرفت که پیچیدگی مشابه انرژیه. قانون حفاظت از انرژی میگه که کل انرژی یک سیستم جدا شده ثابت می مونه، نمیشه اون رو ایجاد کرد یا از بین برد. در عوض، انرژی از شکلی به شکل دیگه تبدیل میشه. با این حساب، ما فکر کردیم که باید قانون حفظ پیچیدگی وجود داشته باشه و معلوم میشه که وجود داره.
برای پاسخ به سوال اصلی “آیا ارزش داره زمان تیم توسعه برای از بین بردن پیچیدگی برای کاربر صرف بشه یا نه؟” تسلر پاسخ داده: “مگر اینکه موقعیت انحصاری پایداری داشته باشید، زمان مشتری باید برای شما مهمتر از زمان شما باشد.”
در اینجا یکی از راه های برآورد ارزش یا هزینه برای کاربرها برای تجزیه و تحلیل هزینه و سود هست. در این صورت، ما ارزش یا هزینه رو برای کاربرها در مدت یک هفته محاسبه می کنیم. برای انجام این کار ، موارد زیر رو با هم ضرب کنید:
میانگین فراوانی در هفته که کاربر با پیچیدگی موردنظر روبرو میشه
تعداد کاربرهای فعال در هفته
ارزش/هزینه، واحدیه که نشون میده یک کاربر واحد از تغییر یا هزینه ی متحمل شده ی کاربرها به دلیل پیچیدگی مورد نظر چه چیزی دریافت می کنه.
برای مثال، فرض کنید کاربرها با پیچیدگی روبرو میشن که می تونیم اون رو سه بار در هفته حذف کنیم، ۱٫۰۰۰٫۰۰۰ کاربر فعال در هفته وجود داره و فرض کنید این پیچیدگی برای هر بار مواجهه، ۵ دقیقه برای کاربرها هزینه داره. ما ۳ * ۱،۰۰۰،۰۰۰ * .۵ = ۱،۵۰۰،۰۰۰ ثانیه یا ۲۵،۰۰۰ دقیقه یا ۴۱۶ ساعت یا کمی بیش از ۱۷ روز رو محاسبه می کنیم. علاوه بر این ، این فقط معیاری از زمان بازگشت به کاربرها برای یک هفته هست.
در این مثال، ما بر اساس یک هفته استفاده از نرم افزار، ارزش رو برای کاربر تخمین می زنیم، اما شما می تونید از هر بازه ی زمانی که بیشترین کاربرد رو برای مورد استفاده ی شما داره، برای مثال سالانه یا عمر مشتری استفاده کنید.
شما می تونید ارزش رو در کاهش زمان گردش کار، ارزش دلار یا حتی ابزار مفید اندازه گیری کنید. مطلوبیت در اقتصاد خرد برای نشان دادن رضایت مصرف کننده استفاده میشه و زمان در نظر گرفتن مزایای ملموس یا هزینه های تاخیر کمتر، مثل راحتی استفاده، مفید هست.
ساده تر شدن
یک گزینه ی دیگه هم وجود داره، حذف ویژگی ها می تونه سطح پیچیدگی رو به طور کامل از سیستم حذف کنه. ویژگی های کم ارزش می تونن بر بی نظمی رابط کاربری افزوده و بار شناختی رو برای کاربرها افزایش بدن. این امر باعث میشه مردم بیشتر از اون چه که باید فکر کنن. به هم ریختگی رابط کاربری باعث میشه تا کاربرها برای رفع نیازشون بیش از حد تلاش کنن و در عین حال سطح دشواری نرم افزار رو افزایش بدن، که این موضوع باعث کاهش کاراییشون میشه.
مهم نیست که چطور این کار رو انجام می دید، حذف پیچیدگی می تونه ارزش نرم افزار شما رو برای کاربرها افزایش بده، اما هنگام تصمیم گیری درباره ی محصول، قانون حفظ پیچیدگی رو در نظر داشته باشید.
مثال های قانون تسلر
یکی از روش های رایج برای نشون دادن قانون تسلر، ایمیل هست. زمان نوشتن یک ایمیل، دو اطلاعات مورد نیاز وجود داره: این پیام از طرف شما (چه کسی) هست و باید به چه کسی ارسال بشه. اگه هرکدوم از این موارد وجود نداشته باشه، ایمیل قابل ارسال نیست، بنابراین این موضوع یک پیچیدگی ضروریه و باید وجود داشته باشه. برای کاهش این پیچیدگی، یک سرویس گیرنده ی ایمیل مدرن دو کار رو انجام میده: آدرس فرستنده رو از قبل پر میکنه (می تونه این کار رو انجام بده چون از آدرس ایمیل مطلع هست) و با شروع به تایپ آدرس، بر اساس ایمیل های قبلی و یا مخاطبین فرستنده، پیشنهاداتی رو برای گیرنده ارائه بده (تصویر ۱). پیچیدگی به طور کامل از بین نرفته، فقط برای کاهش تلاش مورد نیاز کاربر، سرویس ایمیل سعی در کم کردن مراحل flowی کاربر و انتزاع فرایند کرده است.
به عبارت دیگه، تجربه ی نوشتن ایمیل با انتقال پیچیدگی پر کردن فرستنده و در صورت امکان آدرس گیرنده به سرویس گیرنده ی ایمیل، ساده تر میشه، که تیم طراحی و توسعه هنگام ساخت این بار پیچیدگی رو سمت سیستم در نظر گرفتن.
با برداشتن این گام، Gmail از هوش مصنوعی (AI) درون ایمیل های شما از طریق ویژگی ای به نام Smart Compose (تصویر ۲) استفاده می کنه. این ویژگی هوشمند می تونه اونچه رو که تایپ کردید اسکن کنه و از اون برای پیشنهاد کلمات و عبارات برای اتمام جملات خود استفاده کنه، بنابراین در تایپ و زمان اضافی شما صرفه جویی میشه. لازم به ذکره که Smart Compose اولین ویژگی صرفه جویی در زمان نیست که از طریق هوش مصنوعی به Gmail معرفی میشه، همچنین Smart Reply وجود داره که یک ایمیل رو برای زمینه اسکن می کنه و چندین گزینه ی پاسخ سریع مرتبط رو پیشنهاد می کنه.
یکی دیگه از موارد قانون تسلر که به طور معمول می تونه رعایت بشه، فرایند پرداخت هست که توی سایت های خرید آنلاین یافت میشه. خرید اقلام به صورت آنلاین مشتری ها رو ملزم می کنه که اطلاعات تکراری زیادی از جمله جزئیات صورتحساب و ارسال رو ارائه بدن. برای ساده سازی این فرایند برای مشتری ها، معمولاً می بینیم که فروشگاه های آنلاین به کاربرها این امکان رو میدن تا آدرس حمل و نقلشون، اطلاعات مربوط رو از آدرس صورتحساب به ارث ببرن (تصویر ۳).
این گزینه در بسیاری از موارد فرایند تسویه حساب رو برای مشتری ها ساده می کنه، چون مانع از این میشه که برای حمل و نقل، اطلاعات تکراری رو وارد کنن.
تجربه ی حاصله برای مشتری ها بطور موثر ساده شده، در حالی که پیچیدگی لازم برای فعال کردن این ویژگی از قبل به طراح ها و توسعه دهنده های مسئول پیاده سازی اون محصول منتقل شده است.
ساده کردن فرایند پرداخت حتی بیشتر خدمات مثل Apple Pay (تصویر ۴)، که پرداخت اقلام رو هم به صورت آنلاین و هم به صورت حضوری برای مشتری ها حتی ساده تر می کنه. بعد از ایجاد حساب، افرادی که از Apple Pay یا خدمات پرداخت مشابه استفاده می کنن. می تونن به سادگی، با انتخاب گزینه در زمان پرداخت و تأیید جزئیات خریدشون، اقلام رو خریداری کنن، بدون نیاز به وارد کردن اطلاعات اضافی. بنابراین تجربه ی مشتری به میزان قابل توجهی پیچیده نمی شه و پیچیدگی دوباره به طراح ها و توسعه دهنده های مسئول خدمات منتقل میشه.
خرده‌فروشی حوزه‌ایه که در اون می‌تونید راه‌های ابتکاری زیادی برای کاهش دادن پیچیدگی از دوش کاربرها پیدا کنید. برای مثال، فروشگاه های Amazon Go رو در نظر بگیرید (تصویر ۵)، که تجربه خرید بدون پرداخت رو فراهم می کنه.
این روش ابتدا به عنوان یک آزمایش در مرکز شهر سیاتل انجام شد، اما حالا در مناطق بزرگ شهری در سراسر ایالات متحده استفاده میشه. با نصب برنامه ی Amazon Go روی تلفن هوشمند خود، مشتری می تونه به سادگی آنچه رو که نیاز داره برداشته اسکن کنه .
و از فروشگاه خارج بشه، بدون اینکه نیازی به منتظر موندن توی صف، اسکن اقلام یا حتی پرداخت در فروشگاه باشه. کمی بعد، مشتری رسیدش رو از طریق اپلیکیشن دریافت می کنه و حساب آمازونش شارژ میشه.
وقتی سادگی به انتزاع تبدیل می شود
یک هدف مهم برای طراح ها اینه که پیچیدگی های غیر ضروری رو برای کاربرهای محصولات و خدماتی که طراحی می کنن حذف کنن. تا این محصولات تا حد امکان ساده و ظریف بشن. به هر حال، تجربه های خوب کاربرها اغلب اون هایی هستن که راحت و شهودی درک میشن. و موانعی که ممکنه کاربر رو از رسیدن به اهدافش دور کنه، حذف میشه.
اما تعادلی وجود داره که زمان تلاش برای سادگی باید رعایت بشه، و مهم اینه که اون رو زیاد پیش نگیرید.
وقتی رابط کاربری تا حد انتزاع ساده شده، دیگه اطلاعات کافی برای تصمیم گیری آگاهانه در دسترس کاربرها نیست. به عبارت دیگه، میزان اطلاعات بصری ارائه شده کاهش یافته تا رابط کاربری کمتر پیچیده به نظر برسه. اما این امر منجر به فقدان نشانه های کافی برای راهنمایی افراد در فرایند یا اطلاعات مورد نیاز اون ها شده. برای مثال، (آیکون گرافی) Iconography رو در نظر بگیرید. نمادها می تونن با ارائه ی یک روش جایگزین برای انتقال اطلاعات بصری که فضای کمتری نسبت به برچسب های متن اشغال می کنه. به ساده سازی یک رابط کمک کنن، اما همچنین می تونن منجر به ابهام بشن (تصویر۶).
این موضوع به ویژه زمانی صادقه که آیکون ها با برچسب های متنی همراه نباشن و تفسیر رو به کاربر واگذار کنیم. به استثنای چند مورد، آیکون ها به ندرت معنای جهانی دارن، اون ها می تونن برای افراد مختلف معانی متفاوتی داشته باشن. برای افزایش ابهام، نمادهای مرتبط با اقدامات خاص همیشه یک عملکرد رو از یک رابط به رابط دیگه انجام نمیدن. زمانی که از آیکون گرافی استفاده میشه و معنای واضحی رو منتقل نمی کنه. یا اقدامی ثابت انجام نمی ده، به یک نویز بصری تبدیل میشه و مانعی برای انجام وظایف محسوب میشه.
نتیجه گیری
قانون تسلر برای طراح ها مهمه که از اون آگاه باشن. چون مربوط به یک چالش اساسیه که ما در طول کار با اون روبرو هستیم: نحوه ی مدیریت پیچیدگی.
اول باید بپذیریم که در هر فرایند مقدار پیچیدگی لازم وجود خواهد داشت. که نمی تونیم اون رو حذف کنیم، صرف نظر از اینکه فرایند در نتیجه ی فرایند طراحی چقدر ساده شده. همه چیز از یک ایمیل گرفته تا یک فرایند پرداخت بسیار پیچیده، دارای پیچیدگی ذاتیه که باید مدیریت بشه. به عنوان طراح، ما وظیفه داریم پیچیدگی ذاتی رو از واسط های کاربریمون حذف کنیم. در غیر این صورت این پیچیدگی رو برای کاربرهامون ارسال می کنیم. این می تونه باعث سردرگمی، سرخوردگی و تجربه بد کاربر بشه. در صورت امکان، طراح ها و توسعه دهندگان باید پیچیدگی رو مدیریت کنن، در حالی که مراقبن تا حد انتزاع بیش از حد ساده نشن.
