ایده کتاب Atomic Design: طراحی اتمی

کتاب atomic design به تازگی مطالعه کتاب Atomic Design رو تموم کردم و در این پست، سعی میکنم تا خلاصه ای از محتوای کتاب رو که درباره یک متد فکری در طراحی رابط کاربری است با شما در میان بگذارم.

تاریخچه تغییر روش طراحی UI:

  1. یه زمانی (سالهای 80 تا 85) وقتی برای طراحی یک سایت به یک شخص/شرکت مراجعه میکردید، به شما می‌گفتند که تعرفه بر اساس تعداد صفحات است. مثلا 5 صفحه میخواهید میشه 500 تومان و هفت صفحه 700 تومان!
  2. کم کم استفاده از سیستمهای مدیریت محتوا، جای خودشون رو باز کردند و طراح‌ها هم به جای طراحی کردن صفحات، به طراحی قالبهای مخصوص CMS رو آوردند. یعنی یک قالب رو (که شامل چند صفحه بود) طراحی می‌کردند و تحویل شما می‌دادند و هر صفحه سایت که میخواست نمایش داده بشه، باید از یکی از صفحات اون قالب پیروی می‌کرد.
  3. این فرایند اینجا متوقف نمیشه. این روزها ما روی محصولاتی کار می کنیم که مثلا به مدت یک یا دو سال همچنان رشد خواهد کرد و بخش های جدیدی بهشون اضافه خواهد شد. در این وضعیت چه کنیم؟ چند صفحه طراحی کنیم؟ چند قالب؟ چند طرح ترکیبی؟

طراحیِ یک سیستمِ طراحی

کتاب Atomic Design توصیه میکنه که به جای طراحی صفحه، به طراحی المان های تشکیل دهنده صفحات رو بیاریم و اسمشو میگذاره طراحی اتمی. نویسنده (Brad Frost) میگه همانطور که موجودات از ارگانیزم ها تشکیل شده اند و ارگانیزم ها از ملکول ها و اون ملکول ها از اتم ها، ما هم باید در طراحی هایمان، این روند را در نظر بگیریم:

طراحی اتمی

این ساختار چگونه کار میکند؟

  1. ساده ترین المان های HTML ، در این مدل طراحی، اتم محسوب میشوند. مثلا TextBox را می توانیم یک اتم در نظر بگیریم یا Button یا Label را.
  2. حالا یک TextBox به همراه یک Button و یک Lable، روی هم یک ملکول را تشکیل میدهند. ملکولِ (همون کامپوننت) سرچ!
  3. حالا اگر چند ملکول (مثلا ملکولِ MenuBar و Logo و SearchBox) را کنار هم قرار دهیم، به ارگانیزم Header میرسیم.
  4. و از کنار هم قراردادن ارگانیزمِ هدر و باکس خبر و فوتر، به یک قالب می رسیم:

 طراحی اتمی رابط کاربری

در یک اپ موبایل هم می تواند همین روند را درنظر گرفت. بطور مثال برای اپ اینستگرام این پنج مرحله بصورت زیر قابل جداسازی است:

 طراحی اپ اینستگرام

ابزار ساخت سیستمِ طراحی اتمی:

کتاب یک ابزار پایه که در طراحی اتمی به کمک ما می‌آید را معرفی کرده است؛ patternlab.io یک سیستم طراحی برای ایجاد همه اتم های یک طرح (دموی این محصول) که به شما در مستندسازی مراحل طراحی نیز کمک میکند. این محصول از زبان قالب بندی mustache استفاده میکند که امکان include بخشهای کد را در صفحات HTML فراهم میکند. توضیحات مربوط به بکارگیری هریک از این ابزارها را با کلیک روی لینکهای خودشان مطالعه کنید. این ابزار امکان استفاده از داده های داینامیک را هم با فرمت json داره و برای ساخت و نمایش قالبها ابزار خوبیه. پترن‌لب همچنین امکان نمایش خروجی را در قالب سایز موبایل و تبلت بصورت ریسپانسیو فراهم کرده .

چه المان هایی را باید طراحی کنید؟

تقریبا تمام المان هایی که روی صفحه می بینید:
  • المان های جنرال: هدر، فوتر و بقیه المان های عمومی صفحه
  • المان های ناوبری: primary navigation, footer navigation, pagination, breadcrumbs, interactive component controls
  • عکس ها: logos, hero images, avatars, thumbnails, backgrounds,
  • آیکون ها: glasses, social icons, arrows, hamburgers, spinners, favicons
  • فرم ها: المان های تکست باکس و دکمه و …
  • المان های heading : مانند h1, h2 , ..
  • بلاک های متن، عکس ، تبلیغات، و …
  • لیست ها: ol , ul و المان های داخلی شون
  • مدیا : المان های پخش صوت و تصویر
  • المان های خارجی مانند ویجت ها و چیزهایی که روی هاست شما میزبانی نمیشوند.
  • پاپ آپ ها: انواع  alert , success , failure, tooltip, help
  • رنگ های المان ها (ابزار stylifyme.com و  cssstats.com )

تعامل با مشتریان

کتاب علاوه بر روشهای پیشنهادی برای طراحی رابط کاربری، روشهایی را برای تعامل با مشتریان مطرح میکند. همچنین برای آشنایی با مدل فکری مشتری پیشنهاد میکند از تست گات استفاده کنید که در لینک خودش، توضیحاتش رو می‌تونید ببینید. هزینه طراحی یک سیستم طراحی کمی بالاست و ممکنه مشتری شما علاقمند به تحویل گرفتن یک design system نباشه. کتاب روشهایی رو برای صحبت با مشتری و جلب اعتماد آنها در لزوم بکارگیری یک سیستم طراحی مطرح میکنه که به دردتون میخوره. از جمله اینکه داشتنِ یک design system در کل منجر به کاهش هزینه های آتی تیم در هنگام توسعه محصول میشود و همچنین باعث میشود تا محصول نهایی که در اسپرینت های مختلف توسعه می یابد، دارای انسجام طراحی باشد. نه اینکه در هر اسپرینت یه چیزی (که شاید هماهنگی طراحی چندانی هم با بخش های قبلی نداره) به طرح اضافه کنید.

تعامل با توسعه دهندگان از ابتدای کار

همانطور که میدانید، روش معماری آبشاری (waterfall) سالهاست که در طراحی نرم‌افزار منسوخ شده است و دلیل اصلی آن نیز مدل توسعه نرم‌افزار است؛ یعنی محصولی که در طول زمان رشد میکند و در حین طراحی هم تغییر می‌یابد و نمی‌توانیم از همان ابتدا، تمام مراحل بعدی را درست حدس بزنیم و طرح را طراحی کنیم و به دست تیم توسعه دهنده بدهیم و برویم پی کارمان!

طراحی آبشاری

کتاب Atomic Design پیشنهاد میکند که طراحان از همان ابتدا تعامل زیادی با توسعه دهندگان فرانت-اند (و حتی بک-اند) داشته باشند. زیرا چیزی که شما طراحی میکنید باید نهایتا توسط فرانت-اندکار به کد تبدیل شود و توسط بک-اند در محصول به کار گرفته شود. بنابراین در جلسات ابتدایی نیز نیازمند مشاوره و همفکری با تیم توسعه دهنده خواهید بود، اما نقش هر یک از شما با پیشرفت پروژه، کم یا زیاد میشود. مطابق شکل زیر:

پروسه طراحی ui

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *