এই track-এর প্রতিটা technique — nudge, hook, engagement mechanics — একটা আসল metric উন্নত করবে তা নিয়ে একটা hypothesis, কোনো গ্যারান্টি না। Testing হলো কীভাবে একটা design সিদ্ধান্ত "আমরা বিশ্বাস করি এটা সাহায্য করে" থেকে "আমরা মেপেছি এটা করে"-তে যায়।
আসল user-দের random-এ দুটো group-এ ভাগ করুন: একটা বর্তমান design দেখে (control), অন্যটা নতুন design দেখে (variant)। যে metric গুরুত্বপূর্ণ (signup, completion rate, task-এ সময়) তা দুই group-এর জন্য মাপুন, আর তুলনা করুন। Split random হওয়ায়, group-দুটোর মধ্যে যেকোনো আসল পার্থক্য design পরিবর্তনের জন্য দায়ী, কে দেখেছে তার জন্য না।
| ধরন | কী বদলায় | কখন ব্যবহার করবেন |
|---|---|---|
| A/B (বা A/B/n) testing | একটা element, আলাদা — একটা button রং, একটা headline, একটা flow step | স্পষ্ট before/after সহ একটা নির্দিষ্ট পরিবর্তন test করা |
| Multivariate testing | একসাথে একাধিক element, combination test করা | কয়েকটা পরিবর্তন কীভাবে interact করে তা বোঝা — significance-এ পৌঁছাতে অনেক বেশি traffic দরকার |
একবারে test করা একটা বড় redesign-এর বদলে, incremental testing ক্রমান্বয়ে ছোট, আলাদাভাবে-testable পরিবর্তন ship করে — প্রতিটার প্রভাব নিজে থেকেই measurable, আর metric-এর ক্ষতি করা একটা পরিবর্তন কাজ করছিল এমন বাকি সবকিছু না হারিয়ে revert করা যায়।
| ভুল | কেন এটা একটা সমস্যা |
|---|---|
| খুব তাড়াতাড়ি একটা result significant বলা | ছোট sample size noisy result দেয় যা প্রায়ই বেশি data-তে উল্টে যায় |
| একটা অস্বাভাবিক সময়ে test করা | একটা holiday, একটা marketing campaign, বা একটা outage দুই group-এর behavior-কেই অসমানভাবে skew করে |
| ভুল metric-এর জন্য optimize করা | একটা পরিবর্তন যা click বাড়ায় কিন্তু আসল task completion কমায় আসলে জেতা না |
| যথেষ্ট traffic ছাড়া একসাথে অনেক variant চালানো | sample-কে এতটা পাতলা করে যে কোনোটার জন্যই একটা confident সিদ্ধান্তে পৌঁছানো যায় না |
Design process-এর সাথে ফিরে যায়
এটা এই কোর্সের আগের Double Diamond process-এর সাথে loop বন্ধ করে — Define আর Develop একটা সমাধান প্রস্তাব করে, Deliver এটা ship করে, আর testing হলো loop কীভাবে নিশ্চিত করে এটা done বলার আগে আসলেই কাজ করেছে।