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