از بین بردن بلاتکلیفی بین تجربه کاربری و تجربه توسعه دهنده – قسمت دوم

84
در قسمت قبلی مقاله رفع بلاتکلیفی تجربه کاربری و تجربه توسعه دهنده با تفاوت تجربه کاربری و تجربه توسعه دهنده آشنا شدید، در این قسمت قرار است باهم یاد بگیریم که چگونه با ارائه راهکار این بلاتکلیفی را ازبین ببریم، پس با ما همراه باشید

 

چگونه می توانیم بن بست و شکاف بین تجربه کاربری و تجربه توسعه دهنده را از بین ببریم؟

این درست است که یک نفر همیشه هزینه را پرداخت می‌کند ولی راه‌هایی برای نزدیک شدن به UX و DX وجود دارد که هزینه ها را پایین نگه می‌دارد یا در بهترین سناریوها، به توسعه دهندگان این امکان را می‌دهد که یک‌بار هزینه را بپردازند و مزایای DX را بدون هیچ گونه معامله‌ای که به UX منجر شود، بدست آورند.

  • درک هزینه یک تجربه کاربری برجسته

در هر پروژه داده‌شده، ما باید از تجربه کاربری ایده‌آل به عنوان نقطه شروع مان استفاده کنیم.

این تجربه کاربری باید از پژوهش کاربر، آزمایش lo-fi و یک فرآیند طراحی تکراری ساخته شود تا اطمینان حاصل شود که دقیقا همان چیزی است که کاربرانمان می‌خواهند.

هنگامی که فهمیدیم تجربه کاربری ایده‌آل چیست، باید طراحی ملاحظات تجربه کاربری را در مورد کارهای فنی آغاز کنیم. این فرآیند تجزیه و تحلیل مفاهیم انتزاعی مانند “احساس سریع” در معیارهای عینی است: چگونه می‌توانیم بسنجیم که یک هدف UX برآورده شده است؟

با تبدیل کردن اهداف UX به پیامدهای قابل‌اندازه‌گیری، می‌توانیم ایده ای از تاثیرگذاری هم از دیدگاه UX و هم از منظر DX به دست آوریم.

درک هزینه یک تجربه کاربری برجستهیک ماتریکس اولویت‌بندی برای تعیین اینکه آیا مزایا از هزینه یک کار خاص بیشتر است یا نه.

از دیدگاه برنامه‌ریزی می‌توانیم ایده‌ای به دست آوریم که بفهمیم کدام وظایف می‌توانند بیش‌ترین تاثیر را بر UX داشته باشند و این به بالاترین سطح تلاش از طرف توسعه دهندگان نیاز دارد. این کار به ما کمک می‌کند هزینه‌ها و اثرات متقابل را بفهمیم: اگر کاری پرتلاش و کم اثر باشد، شاید بهتر است اجازه دهیم کاربران هزینه آن را پرداخت کنند. اما اگر چیزی در تجربه کاربری تاثیر زیادی داشته باشد، احتمالا ایده خوبی نیست که به نفع تجربه توسعه دهنده خوب از آن صرف‌نظر کنید.

 

  • هزینه را هنگام انتخاب راه حل ها در نظر بگیرید

هنگامی که ما قادر به درک هزینه نسبی و اثرات یک کار معین هستیم، می‌توانیم آن را به طور دقیق تجزیه و تحلیل کنیم. ما می‌دانیم که چقدر سخت است تا یک مشکل را حل کنیم، پس می‌توانیم به چگونگی حل کردن آن بپردازیم. به طور کلی سه مقوله اصلی برای حل مشکلات وجود دارد:

  • راه حل خود را از ابتدا بسازید.
  • درباره آنچه که باهوش‌ترین افراد جامعه انجام می‌دهند، تحقیق کنید و یافته‌های خود را در یک راه‌حل سفارشی اعمال کنید.
  • با استفاه از یک راه حل آماده تلاش‌های انبوه جامعه متن‌باز را به کار بگیرید.

هر مقوله با سبک و سنگین کردن همراه است و دانستن اینکه آیا هزینه از مزایای هر مشکل معینی بیشتر است، نیازمند کار در مورد الزامات پروژه است. بدون یک نقشه روشن از آنچه ساخته خواهد شد و هزینه ای که برای ساخت آن وجود دارد – هر تصمیمی که در مورد ابزار گرفته می‌شود، فقط یک حدس و گمان است.

  • زمانی که راه‌حل خودتان را ابداع می کنید

در ابتدای کار به عنوان یک معمار فرانت اند در IBM، من یک پروژه را هدایت کردم تا یک لایه GraphQL را برای تیم‌های فرانت اند آماده کنم تا به سرعت برنامه‌ها را در معماری مبتنی بر میکروسرویس مان ایجاد کنم. ما با ابزارهای متن‌باز شروع کردیم، اما در آن زمان هیچ چیزی برای حل چالش‌های خاصی که با آن مواجه بودیم، وجود نداشت. ما ساختن GrMPS را که در اواخر سال ۲۰۱۷ متن باز کرده بودیم، پایان دادیم تا تمایل و خواسته ویژه مان را شروع کنیم.

در این وضعیت، ساختن یک چیز سفارشی، کم هزینه ترین گزینه ما بود: ما می‌دانستیم که GraphQL مشکل اساسی و مهم ما را حل می کند، اما هیچ ابزاری برای اجرای GraphQL در معماری میکروسرویس وجود نداشت. هزینه انتقال از میکروسرویس ها بسیار بالا بود و هزینه نگه داشتن اشیا به همان شکلی که بودند در دراز مدت قابل‌کنترل نبود. ما زمانی را صرف ایجاد ابزار لازم برای پرداخت سود سهام از طریق افزایش بهره‌وری و بهبود DX برای تیم‌هایمان کردیم.

با این حال، نکته مهم در این داستان این است که IBM، یک شرکت نادر با تیمی بزرگ و حرفه ای است که به یک تیم از توسعه دهندگان اجازه می دهد تا تمام‌وقت کار کنند و ابزارهای سطح پایین ایجاد کنند – ابزارهایی که فقط برای شروع کار بر روی هدف واقعی لازم است – بندرت امکان پذیر است.

و در حالی که DX برای تیم‌هایی که با لایه داده‌های بهبود یافته کار می‌کردند، بهبود پیدا کرد، DX در ساخت ابزارها برای تیم ما  بسیار ناهنجار بود.

گاهی اوقات تلاش و ریسک اضافی ارزشی طولانی مدت دارد، اما همانطور که اریک لی می‌گوید:

هر سطری از کدها که می‌نویسید یک مسئولیت است، نه یک چیز با ارزش. قبل از انتخاب یک راه‌حل سفارشی، به این فکر کنید که آیا منابع لازم برای مدیریت این مسئولیت را دارید یا نه.

  • زمانی که تحقیق و درس‌هایی از متخصصان در این زمینه را به کار می گیرید

یک گام بالاتر از گزینه ابزارها این است که ما قادر به اجرای تحقیقات متخصصان صنعت هستیم. ما دیگر راه‌حل‌ها را ابداع نمی‌کنیم؛ ما در حال اجرای راه‌حل‌های طراحی‌شده توسط متخصصان پیشرو در این زمینه خاص هستیم.

با یک تحقیق کوچک، به لطف متخصصانی مانند لئونی واتسون و مارسی ساتون، ما به بهترین شیوه های دستیابی به صنعت دسترسی داریم. برای استانداردهای وب از طریق جفری زلدمن و استل ویل و برای عملکرد از طریق تیم کادلک و ادی عثمانی دسترسی داریم.

با استفاده از دانش جمعی متخصصان پیشرو در وب، ما نه تنها بهترین تجارب و شیوه های فعلی را می فهمیم، بلکه با اجرای بهترین روش ها، خودمان به یک متخصص تبدیل می شویم.

اما وب به سرعت حرکت می‌کند و برای هر راه‌حل، ما زمان کافی برای تحقیق و پیاده‌سازی داریم و شاهد پیشرفت‌های عمده‌ای خواهیم بود. بهترین تجارب و روش ها نیز حتی بی ارزش می شوند و حتی بهترین توسعه دهندگان نمی‌توانند از کل پیشرفت های صنعت استفاده کنند. این به این معنی است که در حالی که ما آخرین تکنیک‌ها را در یک حوزه از برنامه خود اجرا می‌کنیم، بخش‌های دیگر کهنه خواهند شد.

در حالی که یادگیری همه این شیوه‌های جدید واقعا عالی است، تجربه توسعه دهنده اجرای آن راه‌حل‌ها ممکن است نسبتا دشوار باشد – در بسیاری از موارد هزینه اش آنقدر بالا است که یک تیم خاص استطاعت پرداخت آن را ندارد.

یادگیری مداوم و پیوسته، یک بخش کاملا ضروری برای کسی که توسعه دهنده وب است، می باشد – ما باید همیشه برای یادگیری و بهبود کار کنیم – اما اگر تنها رویکرد ما برای ارائه یک تجربه کاربری بزرگ و عالی است، معیار خوبی نیست.

به گفته جیم یانگ:

ما باید آن را سبک و سنگین کنیم و باید تصمیمی را اتخاذ کنیم که DX تیم را بهبود بخشد. هدف ما این است که تیم سازنده تر شود و ما باید بدانیم که در کجا باید خط بین درک جزئیات غیراصولی هر بخش از برنامه مان و ارائه یک تجربه با کیفیت بالا به کاربران مان در زمان مناسب را ترسیم کنیم.

به بیان دیگر، حفظ بهترین تجارب و شیوه های صنعت، ابزاری عالی برای سنجش اثرات بین ایجاد راه‌حل ها یا استفاده از یک ابزار موجود است، اما ما باید این حقیقت را بپذیریم که هیچ راهی وجود ندارد که بتوانیم از هر چیزی که در صنعت اتفاق می افتد باخبر شویم.

  • زمانی که از راه حل های آماده و غیرسفارشی استفاده می کنید

در حالی که پیگیری چشم‌انداز در حال تغییر و رو به رشد، دشوار است، اکوسیستم رو به رشد از ابزارهای متن باز هنوز هم یک منبع باور نکردنی و از پیش پرداخت شده DX است.

ده‌ها نفر از افراد فوق‌العاده باهوش و مشتاق در تلاشند تا مشکلات را در وب حل کنند و بسیاری از آن راه‌حل‌ها، متن‌باز هستند. این کار به توسعه دهندگانی مثل من و شما امکان دسترسی بی‌سابقه به راه‌حل‌های پیش‌پرداخت را می‌دهد: جامعه قبلا هزینه را پرداخت کرده است، بنابراین من و شما می‌توانیم تجربه کاربری شگفت انگیزی ارائه کنیم، بدون اینکه تجربه توسعه دهنده را رها کنیم.

این کلاس از ابزارها با توجه به UX و DX در ذهن طراحی شده است.

با تکامل بهترین تجارب و روش ها، هر پروژه صدها نفر از مشارکت کنندگان را دارد که باهم کار می‌کنند تا اطمینان حاصل کنند که این ابزارها همیشه از بهترین رویکرد ممکن استفاده می‌کنند و هر یک از آن‌ها یک اکوسیستم از مباحث آموزشی، مثال ها، مقالات و بحث ها ایجاد کرده‌اند تا DX را بهتر کنند.

با بهره‌گیری از تخصص جمعی جامعه وب، ما قادر به صرف‌نظر کردن از تمام اندوه و سرخوردگی ناشی از درک این چیزها هستیم؛ جامعه متن‌باز هزینه را از جانب ما جبران کرده‌است. ما می‌توانیم از یک DX کاملا بهبود یافته لذت ببریم، مطمئن باشیم که بسیاری از سخت‌ترین بخش‌های ایجاد تجربه کاربری خوب از قبل درنظر گرفته شده اند.

سبک و سنگین کردن – به این دلیل که همیشه حداقل یک مورد وجود دارد – این است که ما باید فرضیات و محدودیت‌های این چارچوب را قبول کنیم و در قالب آن ها کار کنیم تا DX عالی را به دست آوریم. چون دوباره، به محض اینکه بیرون از مسیر سعادت قدم برداریم، دوباره به خودمان وابسته هستیم. قبل از اتخاذ هر راه‌حل – چه متن باز باشد، چه SaaS، یا سفارشی – مهم است که درک کاملی از آنچه که سعی داریم انجام دهیم، داشته باشیم و این درک را با اهداف و محدودیت‌های یک ابزار پیشنهادی مقایسه کنیم. در غیر این صورت، ما در حال اجرای یک خطر قابل‌توجه هستیم: که بهبود DX امروز به دین فنی فردا تبدیل خواهد شد.

اگر بخواهیم آن سبک سنگین کردن را بپذیریم، ما خود را در موقعیت خوبی می‌یابیم: با اطمینان از این که UX یک بررسی درجه یک در هر سطحی از ابزارهای تکنولوژیک ما است و ما در محیطی کار می‌کنیم که برای ارائه دادن DX باورنکردنی به تیم‌های ما بهینه‌سازی شده‌است.

  • بن بست یک مشکل طراحی (قابل حل) است

این وسوسه کننده است که UX و DX را به عنوان نیروهای مخالف بیان می‌کنند: برای اینکه یکی بهتر شود، دیگری باید بدتر شود و در بسیاری از برنامه‌ها که قطعا اینطور به نظر می‌رسد.

DX با هزینه UX یک مشکل طراحی است.

اگر نرم‌افزاری بگونه ای طراحی شود که زندگی توسعه دهندگان را بدون در نظر گرفتن کاربر، آسان‌تر کند، تعجبی ندارد که مشکلات بعدا بوجود آیند.

اگر نیازهای کاربر در هسته هر تصمیم در نظر گرفته نشده باشد، ما می‌بینیم که مشکلاتی به وجود می آیند: به جای این که تشخیص دهند که اگر سایتی در موبایل بیشتر از سه ثانیه طول بکشد تا بارگذاری شود، کاربران آن را ترک می کنند، پروژه‌های ما به پایان می رسند و دو برابر طول می‌کشد تا در اتصالات ۴G و حتی ۳G بارگذاری شوند.

ما صدها کیلوبایت را می‌فرستیم، چون بهینه ‌سازی تصاویر و یا از بین بردن کد استفاده نشده خسته‌کننده است. به عبارت ساده: ما تنبل می‌شویم و مصرف کنندگان ما از آن رنج می‌برند.

به طور مشابه، اگر یک تیم، ابزارهای خود را نادیده بگیرد و فقط در ارائه تجربه کاربری عالی تمرکز کند، توسعه دهندگان رنج خواهند برد. چک لیست های کامل از فرایندهای دستی می‌تواند تضمین کند که تجربه کاربری پروژه‌های ما از سطح بالایی برخوردار هستند، اما این تلاش سختی است که یک تجربه کاربری بد را برای تیم‌ها برای نوشتن کد ایجاد می‌کند. در یک صنعت پر از توسعه دهندگان که دوست دارند نوآوری کنند و بسازند، چک لیست ها تمایل دارند که تعامل کارکنان را بکشند که در نهایت برای کاربران، توسعه دهندگان و کل شرکت بد است.

اما اگر ما در ابتدای پروژه، هر دو طرف را در نظر بگیریم، قادر به تشخیص اثرات متقابل آن ها هستیم. قبل از بروز مشکلات تصمیم‌های طراحی هوشمندی می‌گیریم. ما می‌توانیم هم UX و هم DX را به عنوان نگرانی‌های درجه یک درمان کنیم و از قرار دادن آن‌ها در تضاد با یکدیگر جلوگیری کنیم، یا حداقل، می‌توانیم سبک سنگین کردن ها را در زمانی که درگیری‌ها و تضادها رخ می‌دهند به حداقل برسانیم.

ما می‌توانیم یک تجربه عالی برای کاربران خود فراهم کنیم، در حالی که یک مجموعه قوی از ابزارها و چارچوب هایی ایجاد می کنیم که توسعه را در طول کل پروژه، لذت بخش و مناسب می‌سازند. چه ما این کار را با انتخاب ابزارهای موجود برای انجام کار بر روی صفحات خود انجام دهیم، چه با صرف زمان مناسب برای برنامه‌ریزی صحیح راه حل های سفارشی و یا ترکیبی از آن، ما می‌توانیم یک تلاش آگاهانه برای اتخاذ تصمیمات طراحی هوشمند داشته باشیم، بنابراین ما می‌توانیم هم کاربران و هم توسعه دهندگان را خوشحال نگه داریم.

منبع Alistapart
ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.