کتاب شکل‌دهی قسمت 2: اصول شکل‌دهی

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

وایرفریم‌ها بیش از حد دقیق هستند

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

من وایرفریم رو به طراحم می‌دم و بعد بهش می‌گم: «می‌دونم داری به این نگاه می‌کنی، ولی من نمی‌خوام اینو طراحی کنی. می‌خوام از اول بهش فکر کنی!» ولی این کار سخته وقتی یه چیز دقیق بهشون می‌دی.

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

کلمات هم خیلی انتزاعی هستند

در سمت دیگه‌ی ماجرا، پروژه‌هایی که خیلی مبهم تعریف می‌شن هم جواب نمی‌دن. وقتی یه پروژه با چند تا کلمه تعریف می‌شه، هیچ‌کس نمی‌دونه دقیقاً منظور چیه. مثلاً «ساخت ظاهر تقویم» یا «اضافه کردن نوتیفیکیشن گروهی» به‌نظر منطقی میان، ولی دقیقاً چی قراره انجام بشه؟ اعضای تیم اطلاعات کافی ندارن تا بتونن تصمیمات لازم رو بگیرن. نمی‌دونن چه چیزی رو باید اضافه کنن یا ازش صرف نظر کنن. یه برنامه‌نویس که تو همچین وضعیتی کار کرده بود می‌گفت:

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

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

بررسی موردی: تقویم نقطه‌ای

بیایید یه نمونه رو ببینیم از اینکه چطور می‌شه یه پروژه رو تو سطح مناسبی از جزئیات شکل‌دهی کرد.

ما نسخه سوم Basecamp رو بدون قابلیت تقویم لانچ کردیم. این نسخه یه قابلیت به نام “زمان‌بندی” داشت که فقط رویدادها رو یکی بعد از دیگری لیست می‌کرد، بدون اینکه یه ظاهر ماهانه، هفتگی یا روزانه‌ای وجود داشته باشه.

خیلی زود بعد از لانچ، مشتری‌ها از ما خواستن که به Basecamp «یه تقویم اضافه کنیم.» ما قبلاً تقویم ساخته بودیم و می‌دونستیم که چقدر پیچیده‌ است. ساخت یه تقویم درست و حسابی به راحتی شش ماه یا بیشتر زمان می‌بره.

این‌ها از اون چیزایی هستن که ساخت تقویم رو پیچیده می‌کنه:

• جابجا کردن رویدادها بین روزها با کشیدن و رها کردن

• مدیریت رویدادهای چند روزه به نحوی که درست نمایش داده بشن

• نمایش‌های مختلف مثل ماهانه، هفتگی، یا روزانه

• تغییر مدت زمان یک رویداد با کشیدن لبه‌ی اون

• استفاده از رنگ‌های مختلف برای دسته‌بندی رویدادها

• تفاوت تعاملات کاربران روی دسکتاپ و موبایل

نسخه‌های قبلی Basecamp تقویم داشتن و فقط حدود ۱۰٪ مشتری‌ها ازشون استفاده می‌کردن. به همین دلیل ما انگیزه‌ای نداشتیم که شش ماه روی تقویم وقت بذاریم. از طرف دیگه، اگه می‌تونستیم تو یه چرخه شش‌هفته‌ای کاری انجام بدیم که مشتریانی که ازمون درخواست تقویم داشتن رو راضی کنیم، آماده بودیم که انجامش بدیم.

با فقط شش هفته زمان، ما می‌تونستیم حدوداً یه دهم چیزی که مردم از شنیدن کلمه «تقویم» انتظار دارن بسازیم. سوال این بود: کدوم یک دهم؟

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

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

ما این سطح از دقت رو برای تعریف راه‌حل استفاده کردیم:

طرح کلی از مفهوم Dot Grid

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

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

در پایان پروژه، کار نهایی که طراحان و برنامه‌نویسان ایجاد کردند، به این شکل بود:

اسکرین شات Dot Grid وقتی که لانچ شد

این مثال کوچک چندین ویژگی کار شکل‌دهی شده را برجسته می‌کند.

ویژگی ۱: کار زمخته

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

ویژگی ۲: ولی حلّه

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

ویژگی ۲: چارچوب کار مشخصه

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

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

چه کسی شکل‌دهی را انجام می‌دهد؟

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

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

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

این کار همچنین یک کار استراتژیک است. تعیین اشتیاق و پیدا کردن یک راه‌حل نیاز به نقد مشکل دارد. ما چه چیزی را می‌خواهیم حل کنیم؟ چرا این موضوع اهمیت دارد؟ موفقیت چه چیزی را شامل می‌شود؟ کدام مشتریان تحت تأثیر قرار می‌گیرند؟ هزینه انجام این کار به جای کار دیگری چیست؟

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

دو مسیر

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

مراحل فرآیند شکل‌دهی

شکل‌دهی چهار مرحله اصلی دارد که در چهار فصل بعدی به آن‌ها می‌پردازیم.

1. تعریف مرزها: اول، باید بفهمیم که یک ایده خام چقدر ارزش زمانی دارد و چطور باید مشکل را تعریف کنیم. این کار مرزهای ابتدایی را برای شکل‌دهی به ما می‌دهد.

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

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

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