کتاب شکل‌دهی قسمت 4: پیدا کردن عناصر

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

با سرعت مناسب حرکت کنید

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

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

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

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

• این ویژگی جدید کجای سیستم فعلی قرار می‌گیرد؟

• چطور به آن دسترسی پیدا می‌کنید؟

• اجزا و کامپوننت‌های اصلی و یا تعاملات و اینترکشن‌های کلیدی آن چیست؟

• شما را به چه سمتی می‌برد؟

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

بردبوردینگ

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

تصمیم‌گیری در مورد افزودن یک چراغ نشانگر و یک دکمه چرخشی بسیار متفاوت از بحث در مورد جنس شاسی، مکان قرارگیری دکمه نسبت به چراغ (سمت چپ یا راست)، یا میزان تیزی گوشه‌ها و غیره است.

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

• مکان‌ها: چیزهایی هستند که می‌توانید به آنها دسترسی پیدا کنید، مانند صفحات، دیالوگ‌ها یا منوهای پاپ‌آپ.

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

• خطوط اتصال: این خطوط نشان می‌دهند که ابزارها چگونه کاربر را از یک مکان به مکان دیگر هدایت می‌کنند.

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

مثال

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

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

روی فاکتور، در نظر داریم یک دکمه جدید برای «فعال کردن پرداخت خودکار» اضافه کنیم. این یک ابزار (Affordance) است. ابزار در زیر خط قرار می‌گیرند تا نشان دهند که می‌توان آن‌ها را در آن مکان پیدا کرد.

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

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

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

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

به نظر ساده می‌آید. ولی صبر کنید — آیا ما واقعاً فاکتور اصلی را پرداخت کردیم یا نه؟ همم. حالا ما هم با سوالات عملکردی و هم سوالات رابط کاربری مواجه هستیم. فعال کردن Autopay دقیقاً چه کاری انجام می‌دهد؟ آیا فقط برای فاکتورهای آینده اعمال می‌شود یا پرداخت اولین بار با Autopay هم شامل پرداخت فاکتور فعلی می‌شود؟ و کجا باید این رفتار را توضیح دهیم؟ ما به سوالات عمیق‌تر و بحث‌های بیشتری رسیدیم که فقط از چند کلمه و فلش روی بردبرد تحریک شده است.

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

می‌توانیم یک گزینه به صفحه Setup اضافه کنیم…

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

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

ترسیم این موضوع به ما یادآوری کرد که فرم پرداخت فعلی علاوه بر کارت اعتباری از ACH پشتیبانی می‌کند. ما بحث کردیم و تأیید کردیم که می‌توانیم از ACH نیز استفاده کنیم.

حالا بعد از فعال شدن Autopay چه؟ چگونه مشتری می‌تواند آن را غیرفعال کند؟ تا این مرحله، بسیاری از مشتریان در سیستم نام کاربری یا رمز عبور نداشتند. آنها از لینک‌های توکنیزه شده برای پرداخت فاکتورها یکی یکی استفاده می‌کردند. ممکن است به طور طبیعی فرض کنیم که حالا که مشتری چیزی مانند Autopay دارد، به یک نام کاربری و رمز عبور و مکانی برای مدیریت آن نیاز دارد.

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

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

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

اسکچ‌های با ماژیک بزرگ

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

اسکچ ماژیک بزرگ، اسکیچ‌هایی است که با ماژیک‌هایی با نوک‌های بسیار بزرگ کشیده می‌شوند به طوری که افزودن جزئیات دشوار یا غیرممکن است. ما در ابتدا این کار را با ماژیک‌های Sharpie با نوک بزرگ روی کاغذ انجام می‌دادیم. امروزه هم همچنان این کار را روی iPadها با تنظیم قطر قلم به اندازه‌ی بزرگ انجام می‌دهیم.

در اینجا یک مثال آورده شده است. ما متوجه شدیم که اغلب در لیست کارهای Basecamp خود، کارهای جعلی ایجاد می‌کنیم که به عنوان جداکننده عمل می‌کنند. ما موردی مانند “––– نیاز به تست –––“ را ایجاد می‌کردیم و موارد زیر آن را قرار می‌دادیم. ما ایده‌ای داشتیم برای ایجاد نوعی ویژگی رسمی جداکننده در ابزار کارهای خود تا این راهکار موقتی را به یک عملکرد کلاس اول در to do listها تبدیل کنیم.

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

ما می‌توانیم موارد را از طریق برخی از امکانات درون هر گروه اضافه کنیم، از جمله گروه “loose” در بالا.

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

این نشانه‌گذاری نسبت به breadboardها محدودیت کمتری دارد اما معایبی نیز دارد. ممکن است ما یک نوار کناری بکشیم و به یک عنصر طراحی مانند آن وابسته شویم، حتی اگر این عنصر جزء اصلی نباشد. اما به شرطی که به این نکته توجه داشته باشیم، هنوز از این نظر بهتر خواهیم بود که به دام جزئیات ریز wireframe‌ها نیفتیم.

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