حالا که محدودیتهای مربوط به تمایلات (appetite) و مشکلی که در حال حل آن هستیم را مشخص کردهایم، وقت آن رسیده که از یک ایده صرفاً کلامی به عناصر یک راهحل نرمافزاری برسیم. ممکن است دهها راه مختلف برای رویکرد به حل یک مشکل وجود داشته باشد. بنابراین، مهم است که بتوانیم سریع حرکت کنیم و ایدههای مختلف زیادی را پوشش دهیم، بدون اینکه در جزئیات گرفتار شویم.
دو چیز ما را قادر میسازد تا در این مرحله با سرعت مناسب حرکت کنیم.
اولاً، باید افراد مناسب – یا هیچکس – را در اتاق داشته باشیم. یا به تنهایی کار میکنیم یا با یک شریک قابل اعتماد که میتواند همگام با ما پیش برود. کسی که بتوانیم با او به صورت مختصر و مفید صحبت کنیم، پیشزمینه دانش مشابهی داشته باشد، و بتوانیم هنگام پرش بین ایدهها با او صریح باشیم.
ثانیاً، باید از پرداختن به جزئیات نامناسب در طراحیها و اسکچ ها پرهیز کنیم. اگر با وایرفریمها یا طرحبندیهای بصری خاص شروع کنیم، درگیر جزئیات غیرضروری میشویم و نمیتوانیم به گستردگی لازم ایدهها را بررسی کنیم.
چالش اینجا این است که به اندازهای شفاف و ملموس باشیم که در مورد یک راهحل خاص پیشرفت کنیم، بدون اینکه درگیر جزئیات ریز شویم. سوالاتی که تلاش میکنیم به آنها پاسخ دهیم عبارتند از:
• چیز جدید در کجای سیستم فعلی قرار میگیرد؟
• چگونه به آن دسترسی پیدا میکنید؟
• اجزا یا تعاملات کلیدی کدامند؟
• شما را به کجا میبرد؟
برای حفظ سطح مناسب جزئیات و ثبت افکارمان به همان سرعتی که به ذهن میرسند، به صورت دستی با استفاده از دو تکنیک نمونهسازی کار میکنیم: بردبوردینگ (Breadboarding) و اسکچهای با ماژیک ضخیم (Fat Marker Sketches). این روشها به ما اجازه میدهند تا به سرعت نسخههای مختلفی از جریانهای کاری کامل را طراحی کنیم تا بتوانیم جوانب مثبت و منفی هر رویکرد را مورد بحث قرار دهیم و در طول مسیر با آنچه در مورد آن صحبت میکنیم، هماهنگ بمانیم.
ما مفهومی را از مهندسی برق وام میگیریم تا به ما در طراحی در سطح مناسب انتزاع کمک کند. بردبورد یک نمونه اولیه مهندسی برق است که تمام اجزا و سیمکشی یک دستگاه واقعی را دارد، اما طراحی صنعتی (ظاهری) ندارد.
تصمیمگیری برای قرار دادن یک چراغ نشانگر و یک دستگیره چرخشی، بسیار متفاوت است از بحث در مورد جنس بدنه، اینکه دستگیره باید سمت چپ چراغ باشد یا راست، گوشهها چقدر باید تیز باشند و غیره.
به همین ترتیب، ما میتوانیم اجزا و اتصالات کلیدی یک ایده رابط کاربری را بدون تعیین یک طراحی بصری خاص، اسکچ بزنیم و در مورد آنها بحث کنیم. برای این کار، میتوانیم از یک شورتهند ساده استفاده کنیم. سه چیز اساسی وجود دارد که ما آنها را ترسیم میکنیم:
• مکانها (Places): اینها چیزهایی هستند که میتوانید به آنها ناوبری کنید، مانند صفحهها، دیالوگها یا منوهای بازشونده.
• افوردنسها (Affordances): اینها چیزهایی هستند که کاربر میتواند روی آنها عمل کند، مانند دکمهها و فیلدها. ما متن رابط کاربری را نیز یک افوردنس در نظر میگیریم. خواندن آن عملی است که اطلاعاتی برای اقدامات بعدی به کاربر میدهد.
• خطوط اتصال (Connection lines): اینها نشان میدهند که چگونه افوردنسها کاربر را از مکانی به مکان دیگر میبرند.
ما برای همه چیز به جای تصاویر از کلمات استفاده خواهیم کرد. موارد مهم، اجزایی هستند که شناسایی میکنیم و اتصالات آنها. آنها به ما اجازه میدهند تا یک ایده را اجرا کرده و قضاوت کنیم که آیا توالی اقدامات به مورد استفاده (use case) که قصد حل آن را داریم، خدمت میکند یا خیر.
مثال
فرض کنید محصول ما یک ابزار فاکتوردهی است. ما در حال بررسی افزودن یک ویژگی جدید به نام «پرداخت خودکار» (Autopay) هستیم تا مشتریانِ مشتریانمان بتوانند فاکتورهای آتی را به صورت خودکار پرداخت کنند.
چگونه پرداخت خودکار را فعال میکنید؟ چه چیزهایی درگیر هستند؟ میتوانیم یک نقطه شروع را انتخاب کنیم و بگوییم که مشتری به یک فاکتور رسیده است. این مکان اول ماست. ما آن را با نوشتن نام مکان و کشیدن یک خط زیر آن ترسیم میکنیم.
روی فاکتور، ما فکر میکنیم میتوانیم یک دکمه جدید برای «فعال کردن پرداخت خودکار» اضافه کنیم. این یک افوردنس است. افوردنسها زیر خط قرار میگیرند تا نشان دهند که در آن مکان یافت میشوند.
آن دکمه به کجا میرود؟ به محلی برای تنظیم پرداخت خودکار. لازم نیست مشخص کنیم که آیا این یک صفحه جداگانه است یا یک مودال پاپآپ یا چه چیزی. از دیدگاه اتصالات (topology)، همه آنها یکسان هستند. بیایید یک خط اتصال از دکمه به صفحه «تنظیم پرداخت خودکار» رسم کنیم.
حالا میتوانیم در مورد محتوای آن صفحه صحبت کنیم. آیا در اینجا اطلاعات کارت اعتباری را درخواست میکنیم؟ آیا کارتی از قبل در پرونده وجود دارد؟ در مورد روشهای پرداخت دیگر مانند ACH چطور؟
فقط با نوشتن کلمات زیر خط، بحثها و مناقشاتی درباره اینکه چه چیزی باید ساخته شود، شکل میگیرد.
همانطور که به آن فکر میکنیم، تصمیم میگیریم که جزئیات کارت اعتباری را در اینجا درخواست کنیم و لوگوی موسسه مالی (جنبهای از دامنه در این محصول خاص) را نشان دهیم.
بسیار ساده به نظر میرسد. اما صبر کنید – آیا فاکتور اصلی را واقعاً پرداخت کردهایم یا خیر؟ هممم. حالا هم سوالات کاربردی (functional) و هم سوالات رابط کاربری (interface) داریم. فعال کردن پرداخت خودکار دقیقاً چه کاری انجام میدهد؟ آیا فقط برای آینده اعمال میشود یا اینکه پرداخت با پرداخت خودکار برای اولین بار، فاکتور فعلی را نیز تسویه میکند؟ و کجا این رفتار را توضیح دهیم؟. ما به دلیل چند کلمه و فلش در بردبورد، شروع به طرح سوالات و بحثهای عمیقتری کردهایم.
از آنجا که ما از یک نشانه گذاری بسیار سبک استفاده میکنیم و درگیر وایرفریمها نیستیم، میتوانیم به سرعت در اطراف پرش کنیم و احتمالات مختلف را بررسی کنیم.
میتوانیم یک گزینه به صفحه تنظیمات اضافه کنیم…
اما حالا مسئولیتهای صفحه تایید را پیچیده میکنیم. اگر الان مانده حساب را پرداخت کنید، باید یک رسید نشان دهیم. آیا صفحه تأیید باید شرطی داشته باشد که گاهی اوقات رسید مبلغی که تازه پرداخت شده را نشان دهد؟
یک رویکرد کاملاً متفاوت چطور؟ به جای شروع از یک فاکتور، پرداخت خودکار را به عنوان یک گزینه هنگام انجام پرداخت در نظر بگیریم. به این ترتیب هیچ ابهامی در مورد اینکه آیا مبلغ فعلی پرداخت میشود وجود ندارد. میتوانیم یک فراخوانی اضافی "پرداخت خودکار فعال شد" را به صفحه تأیید پرداخت موجود اضافه کنیم.
ترسیم این طرح به ما یادآوری کرد که فرم پرداخت فعلی علاوه بر کارت اعتباری، از ACH نیز پشتیبانی میکند. ما بحث کرده و تأیید میکنیم که میتوانیم از ACH نیز استفاده کنیم.
بعد از فعال شدن پرداخت خودکار چه میشود؟ چگونه مشتری آن را غیرفعال میکند؟. تا این نقطه، بسیاری از مشتریان در سیستم نام کاربری یا رمز عبور نداشتند. آنها از طریق لینکهای توکنیزهشده فاکتورها را یکی یکی پرداخت میکردند. ممکن است به طور طبیعی تصور شود که اکنون که مشتری چیزی مانند پرداخت خودکار را فعال کرده است، به نام کاربری و رمز عبور و محلی برای مدیریت آن نیاز دارد.
در این مورد، تیم تصمیم گرفت که اضافه کردن جریانهای نام کاربری/رمز عبور برای "تمایلات" (appetite) آنها در آن زمان بیش از حد از محدوده پروژه (scope) بود. با تفکر استراتژیک در مورد آنچه از مشتریان خود میدانستند، به این نتیجه رسیدند که اگر مشتریان فاکتوردهنده مجبور باشند با فاکتوردهنده تماس بگیرند و از او بخواهند پرداخت خودکار را غیرفعال کند، مشکلی پیش نخواهد آمد. در این صورت، میتوانیم یک گزینه واحد برای غیرفعال کردن پرداخت خودکار را در صفحه جزئیات مشتری که از قبل به فاکتوردهندگان ارائه میکردیم، اضافه کنیم. ما جریان را اینگونه طراحی کردیم:
این مثال، سطح تفکر و سرعت حرکتی را که باید در مرحله بردبوردینگ هدف قرار دهیم، نشان میدهد. نوشتن جریانها ما را با سوالاتی روبرو میکند که در ابتدا به آنها فکر نکرده بودیم و ایدههای طراحی را تحریک میکند، بدون اینکه ما را با انتخابهای بصری بیاهمیت منحرف کند.
هنگامی که به جایی میرسیم که مورد استفاده را اجرا میکنیم و جریان مناسب به نظر میرسد، عناصر مورد نیاز برای شروع تعریف روشنتر پروژه را در دست داریم. ما در حال ملموستر شدن هستیم، در حالی که هنوز مقدار زیادی از جزئیات را کنار گذاشتهایم.
گاهی اوقات ایدهای که در ذهن داریم، یک ایده بصری است. بردبوردینگ در این حالت به درستی هدف را نمیرساند زیرا آرایش دوبعدی عناصر مشکل اساسی است. در این حالت، ما همچنان نمیخواهیم وقت خود را با وایرفریمها یا دقت غیرضروری هدر دهیم. در عوض، از اسکچ های با ماژیک ضخیم استفاده میکنیم.
یک اسکچ با ماژیک ضخیم، اسکچی است که با ضربات قلمی آنقدر پهن کشیده میشود که اضافه کردن جزئیات دشوار یا غیرممکن است. ما در ابتدا این کار را با ماژیکهای شارپی با نوک بزرگتر روی کاغذ انجام میدادیم. امروزه این کار را روی آیپد با تنظیم اندازه قلم روی قطر بزرگ نیز انجام میدهیم.
در اینجا یک مثال آورده شده است. ما اغلب در لیستهای وظایف (to-do lists) بیسکمپ (Basecamp) خود، وظایف ساختگی ایجاد میکردیم که به عنوان جداکننده عمل میکردند. ما یک آیتم مانند "--- نیاز به تست ---" ایجاد میکردیم و آیتمها را زیر آن قرار میدادیم. ایده داشتیم که نوعی ویژگی جداکننده رسمی را در ابزار وظایف خود ایجاد کنیم تا این راهکار موقت را به یک عملکرد درجه یک در لیستهای وظایف تبدیل کنیم.
باید پیامدهای اضافه کردن یک جداکننده را بررسی میکردیم. به ایده تقریبی رسیدیم که افزودن یک جداکننده، لیست را به وظایف «آزاد» در بالای جداکننده و وظایف «گروهبندی شده» در پایین تقسیم میکند. افزودن جداکنندههای بعدی، گروههای بیشتری را در زیر آیتمهای «آزاد» در بالا اضافه میکند.
میتوانستیم آیتمها را از طریق یک افوردنس در هر گروه، از جمله گروه «آزاد» در بالا، اضافه کنیم.
کمی نگران بودیم که دکمههای «اضافه کردن» ممکن است انسجام لیست را به هم بزنند، و گروهها ممکن است بیش از حد از لیستهای موجود در صفحه جدا شوند. در مورد امکان قرار دادن افوردنس «اضافه کردن» در منویی که قبلاً در سمت چپ هر آیتم وظیفه داشتیم، صحبت کردیم.
این نشانه گذاری بسیار کمتر از بردبوردها محدودکننده است، که البته معایبی هم دارد. ممکن است یک نوار کناری (sidebar) را ترسیم کنیم و به یک عنصر طرحبندی مانند آن وابسته شویم، حتی اگر یک عنصر اصلی نباشد. اما تا زمانی که مراقب این موضوع باشیم، همچنان وضعیتمان بسیار بهتر از زمانی است که با ایجاد زودهنگام وایرفریمها، در جزئیات گرفتار شویم.
ممکن است کمی مضحک به نظر برسد که اسکچ های با ماژیک ضخیم را یک تکنیک یا ابزار بنامیم. دلیل نام بردن از آنها این است که ما به راحتی به سطح نامناسبی از دقت (fidelity) میپریم. نامگذاری این مرحله اولیه و خشن و استفاده از یک ابزار خاص برای آن، به ما کمک میکند تا فرآیند خلاقیت خود را تقسیمبندی کنیم و مطمئن شویم که به جزئیات یک ایده خاص نپریدهایم، در حالی که هنوز میدان را به اندازه کافی بررسی نکردهایم.
عناصر، خروجی هستند
در مورد مثال پرداخت خودکار، ما به چند عنصر مشخص رسیدیم:
• یک چکباکس جدید "استفاده از این برای پرداخت خودکار؟" در صفحه موجود "پرداخت یک فاکتور".
• یک گزینه "غیرفعال کردن پرداخت خودکار" در سمت فاکتوردهنده.
برای پروژه "گروههای وظایف" (To-Do Groups)، عناصر عبارت بودند از:
• وظایف "آزاد" (loose) بالای گروه اول مستقیماً به والد تعلق دارند.
• وظایف "گروهبندی شده" (grouped) در زیر وظایف آزاد ظاهر میشوند.
• ما میخواهیم یک افوردنس "اضافه کردن" را در هر بخش امتحان کنیم، اما اگر از نظر بصری کار نکرد، مشکلی نداریم که برای قرار دادن وظایف در موقعیت مورد نظر، به منوی اقدام (action menu) تکیه کنیم.
به همین ترتیب، هنگامی که راهحل ساده شده برای نمایش رویدادها در یک شبکه تقویم را طراحی کردیم، از رویکرد ماژیک ضخیم استفاده کردیم.
این کار ما را قادر ساخت تا عناصر اصلی راهحل را مشخص کنیم:
• یک شبکه تقویم ماهانه ۲-تایی (۲ ماه در کنار هم).
• نقطهها برای رویدادها، بدون نشانگرهای کشیده (spanned pills).
• یک لیست رویدادها به سبک تقویم (agenda-style) در زیر که با لمس یک نقطه، رویداد مربوطه را به نمایش در میآورد.
این لیست عناصر در مقایسه با عبارت "تقویم ماهانه" بسیار محدود و خاص است. دقیقاً همان نوع محدودسازی که امیدواریم از طریق فرآیند شکلدهی (shaping) به آن دست یابیم.
فضایی برای طراحان
بعداً، زمانی که نوبت به مشارکت یک طراح میرسد، نمیخواهید مجبور باشید بگویید "میدانم که اینطور ترسیم کردم، اما این را نادیده بگیرید...". صرف نظر از آنچه میگویید، هر گونه ماکت (mockup) خاص، کاری را که دیگران پس از شما انجام میدهند، تحت تأثیر قرار میدهد – به خصوص اگر در موقعیت بالاتری نسبت به آنها باشید. آنها هر جزئیات در ماکتهای اولیه را به عنوان جهتدهی تلقی خواهند کرد، حتی اگر شما چنین قصدی نداشته باشید.
کار کردن در "سطح انتزاع" مناسب نه تنها تضمین میکند که با سرعت مناسب حرکت میکنیم، بلکه این فضای مهم برای خلاقیت را در مراحل بعدی نیز باقی میگذارد.
با حذف جزئیات، روشهای بردبورد و ماژیک ضخیم فضایی برای طراحان در مراحل بعدی پروژه ایجاد میکنند.
این یک تم (theme) در فرآیند شکلدهی (shaping) است. ما پروژه را خاصتر و ملموستر میکنیم، اما همچنان فضای زیادی را برای تصمیمگیریها و انتخابها در آینده باقی میگذاریم. این یک مشخصات (spec) نیست. بیشتر شبیه مرزها و قوانین یک بازی است. وقتی زمان بازی فرا برسد، میتواند به روشهای بیشماری پیش برود.
هنوز قابل تحویل نیست
این مرحله از شکلدهی هنوز به طور کامل در حوزه خصوصی شما قرار دارد. طبیعی است که محصولات این مرحله – روی دیوار یا در دفترچه یادداشت شما – برای هر کسی که با شما نبوده، کم و بیش ناخوانا باشد.
ما از یک ایده مبهم، مانند "پرداخت خودکار" یا "گروههای وظایف"، به یک رویکرد خاص و تعدادی عناصر ملموس رسیدهایم. اما شکلی که در دست داریم هنوز بسیار خام و عمدتاً در حد یک طرح کلی است.
کاری که ما انجام دادهایم، رسیدن به یک رویکرد برای حل مشکل است. اما ممکن است برخی ناشناختههای قابل توجه یا چیزهایی وجود داشته باشند که باید قبل از اینکه این را برای تیم جهت ساخت با موفقیت ایمن بدانیم، به آنها بپردازیم.
گام بعدی انجام آزمایش تنش (stress-testing) و کاهش ریسک (de-risking) است. ما میخواهیم شکافها و چالشهایی را بررسی کنیم که میتوانند پروژه را از ارسال در "محدودیت زمانی" (fixed time appetite) که برای آن در نظر گرفتهایم، بازدارند.
پس از آن، خواهیم دید که چگونه مفهوم شکلگرفته (shaped concept) را در یک نوشتار برای ارائه (pitching) جمعبندی کنیم.
بدون خط مونتاژ (No conveyor belt)
همچنین به خاطر داشته باشید که در این مرحله، میتوانیم پروژه را رها کنیم. ما روی آن شرط نبستهایم. هیچ تعهد یا قولی در مورد آن ندادهایم. کاری که انجام دادهایم، افزودن ارزش به ایده خام با عملیاتیتر کردن آن است. ما به یک گزینه خوب نزدیکتر شدهایم که بعداً میتوانیم هنگام تخصیص منابع، برای آن لابی کنیم.
