ইউআই-এর আগে অনুমোদন ম্যাট্রিক্স ডিজাইন করুন: স্ক্রিনের আগে নিয়ম নির্ধারণ করুন

পরিষ্কার ম্যাট্রিক্স ছাড়া স্ক্রিন কেন ব্যর্থ হয়

একটি পরিষ্কার স্ক্রিনও গম্ভীর প্রক্রিয়াকে ঢেকে রাখতে পারে। যদি অনুমোদন লজিক আগে নির্ধারণ না করা থাকে, ব্যবহারকারীরা Approve ও Reject বাটন দেখেও জানবে না কে কখন সিদ্ধান্ত নেবে, কিংবা পরের ধাপ কী হবে।

এই বিভ্রান্তি বাস্তবে দ্রুত দেখা দেয়। কেউ অনুরোধ জমা দেয়, এটি অ্যাপে আসে, এবং প্রথম প্রশ্নটি হয়— এটি কি ম্যানেজার, ফাইন্যান্স, নাকি দু'জনের কাছে যাবে? স্ক্রিনটি সম্পন্ন মনে হতে পারে, কিন্তু সিদ্ধান্ত পথ অনুপস্থিত থাকে।

এটি ঘটে কারণ স্ক্রিন নিয়মগুলোকে তাদের প্রকৃত জটিলতার তুলনায় সহজ দেখায়। একটি ফর্ম স্ট্যাটাস, মন্তব্য ও অ্যাকশন বাটন দেখাতে পারে, কিন্তু তা পেছনের বাস্তব অনুমোদন ম্যাট্রিক্স অনুমান করে দিতে পারে না। ব্যবসায় যদি পরিমাণের সীমা, বিভাগীয় নিয়ম, বা অস্থায়ী প্রতিনিধির ব্যবস্থা থাকে, তখনই UI ভাঙ্গতে শুরু করে।

প্রায়ই একটিমাত্র ব্যতিক্রমই কাজকে অ্যাপের বাইরে ঠেলে দেয়। হয়তো সাধারণত অনুমোদন বিভাগ প্রধানের কাছে যায়, কেবল জরুরী হলে, একটি নির্দিষ্ট পরিমাণের উপরে, অথবা অনুমোদনকারী অনুপস্থিত থাকলে অন্য পথ নেওয়া লাগে। যদি সেই কেস mapped না করা থাকে, মানুষ ইমেইল, চ্যাট বা স্প্রেডশীটে ফিরে যায়।

তারপর বড় সমস্যা দেখা দেয়: প্রতিটি টিম আলাদা নিয়ম প্রয়োগ শুরু করে। অপারেশন অনুরোধ একভাবে পাঠায়, ফাইন্যান্স অন্যভাবে, এবং সাপোর্ট HR-এর চেয়ে ভিন্নভাবে ব্যতিক্রম হ্যান্ডেল করে। অ্যাপটি হয় একক প্রসেসের বদলে অনিয়মিত সিদ্ধান্তের জন্য মাত্র একটি শেয়ার করা স্ক্রিন হয়ে যায়।

সতর্কতা চিহ্নগুলো সাধারণত সহজেই ধরা যায়:

• ব্যবহারকারীরা জিজ্ঞেস করে পরবর্তী ধাপ কার দায়িত্ব
• একই ধরনের অনুরোধ টিম অনুযায়ী ভিন্ন ফল পায়
• ব্যতিক্রম চ্যাট বা ইমেইলে হ্যান্ডেল হয়
• নীতির আপডেট স্ক্রিন পরিবর্তন বাধ্য করে, নিয়ম পরিবর্তন নয়

নীতির আপডেটগুলো এই দুর্বলতা দ্রুত উন্মোচন করে। যখন লজিক স্ক্রিনের মধ্যে গোপন থাকে, প্রতিটি থ্রেশহোল্ড বা ভূমিকা পরিবর্তন UI পুনর্নির্মাণে পরিণত হয়। ফলে দল ধীর হয়, নতুন ভুল জন্মায়, এবং ব্যবহারকারীদের আস্থা কমে যায়।

স্ক্রিনটি সিদ্ধান্ত পথকে প্রতিফলিত করা উচিত, সেটাই নির্ধারণ করা উচিত নয়। যদি ম্যাট্রিক্স প্রথমে পরিষ্কার থাকে, UI সহজ, স্থিতিশীল এবং ব্যবহারযোগ্য হয়ে ওঠে।

কোনো ওয়্যারফ্রেমের আগে কী ম্যাপ করবেন

স্ক্রিন নয়, সিদ্ধান্ত লজিক দিয়ে শুরু করুন। একটি শক্তিশালী অনুমোদন ম্যাট্রিক্স সাধারণত একটি খাঁটি টেবিল হিসেবে শুরু হয় যা বলে কে কী অনুমোদন করতে পারে, কোন শর্তে, এবং কেউ অস্থিত থাকে তখন কী ঘটে। যদি সেই লজিক দূষ্পষ্ট হয়, এমনকি পরিশীলিত ইন্টারফেসও মানুষকে বিভ্রান্ত করবে।

প্রতিটি অনুরোধ ধরনের জন্য অনুমোদন স্তরগুলো ক্রমানুসারে ম্যাপ করুন। প্রতিটি ধাপের জন্য ভূমিকা লিখে রাখুন এবং সেই ধাপ কী করতে পারে— অনুমোদন, প্রত্যাখ্যান, পর্যালোচনা, বা সম্পাদনার জন্য ফেরত পাঠানো। ব্যক্তিগত নামের চেয়ে ভূুমিকা ব্যবহার করুন কারণ মানুষ চলাচল করে, টিম বদলায়, আর প্রক্রিয়াটি টিকে থাকতে হবে।

তারপর রুট পরিবর্তনকারী নিয়মগুলো নির্ধারণ করুন। পরিমাণ সাধারণ ট্রিগার, কিন্তু প্রায়ই একটাই নয়। অনুমোদন ওয়ার্কফ্লো নিয়ম অঞ্চল, বিভাগ, বিক্রেতা প্রকার, অনুরোধ শ্রেণি, বা ঝুঁকি স্তরের ওপর নির্ভর করতে পারে। একই পরিমাণ এক টিমে সাধারণ হতে পারে, অন্যটিতে সংবেদনশীল।

অনুপস্থিতির নিয়মও দরকার। যদি প্রধান অনুমোদনকারী অনুপস্থিত থাকে, কে অবিলম্বে দায়িত্ব নেবে? ব্যাকআপ যদি সাময়িক হয়, তার কোন তারিখ প্রযোজ্য? তার ব্যতীত অনুরোধ আটকে থাকবে কারণ কেউ জানে না এই সপ্তাহে কার দায়িত্ব।

সময়সীমাও ততটুকুই গুরুত্বপূর্ণ। নির্ধারণ করুন যদি কোনো অনুরোধ নির্দিষ্ট সময়ে উত্তর না পায় তবে কী হবে। আপনি হতে পারেন এক দিনের পরে অনুস্মারক পাঠাবেন, দুই দিনের পরে স্কেলেট করবেন, তিন দিনের পরে অপারেশনকে জানাবেন। সেই সিদ্ধান্তগুলো স্ট্যাটাস লেবেল, নোটিফিকেশন ও কিউ ভিউকে প্রভাবিত করে, তাই স্ক্রিন ডিজাইন শুরু করার আগে এগুলো চূড়ান্ত করা উচিত।

একটি বাস্তবসম্মত ম্যাট্রিক্স সাধারণত পাঁচটি মৌলিক প্রশ্নের উত্তর দেয়:

• কোন শর্ত এই নিয়ম শুরু করে?
• এই স্তরে কোন ভূমিকা অনুমোদন করে?
• ব্যাকআপ কে?
• অনুমোদনকারীর কাছে কাজ করার কত সময় আছে?
• সময়সীমা মিস হলে কী হয়?

আপনি যদি আগে থেকেই এই প্রশ্নগুলোর উত্তর ম্যাপ করেন, বাকি নির্মাণ অনেক সহজ হয়ে যায়।

ধাপে ধাপে ম্যাট্রিক্স কীভাবে তৈরি করবেন

একটি টেবিল, হোয়াইটবোর্ড বা স্প্রেডশীট ব্যবহার করুন। এটিকে এতটাই সহজ রাখুন যাতে একটি ম্যানেজার, টিম লিড ও প্রক্রিয়া মালিক একবারে বুঝতে পারে।

প্রথমে, প্রত্যেক অনুরোধ ধরন তালিকাভুক্ত করুন যা অনুমোদন প্রয়োজন। সবকিছুকে একgeneric ফ্লোতে জোর করবেন না যদি ব্যবসা ইতিমধ্যে অনুরোধগুলো আলাদা ভাবে দেখে। একটি ক্রয় অনুরোধ, রিফান্ড, ডিসকাউন্ট অনুমোদন ও অ্যাক্সেস অনুরোধ প্রায়ই ভিন্ন অনুমোদনকারী, সীমা ও সময়সীমা প্রয়োজন।

এরপর প্রথম অনুমোদনকারী ও প্রতিটি সিদ্ধান্ত বিন্দু লিখুন। প্রত্যেক অনুরোধ ধরনের জন্য নোট করুন কে প্রথম পর্যালোচনা করে এবং অনুমোদন বা প্রত্যাখ্যানের পরে কী হয়। পথটি অনুসরণ করুন যতক্ষণ না আপনি চূড়ান্ত ফলাফল— অনুমোদিত, প্রত্যাখ্যাত, সম্পাদনার জন্য ফেরত, বা বাতিল—এ পৌঁছান।

তারপর রুট পরিবর্তনকারী থ্রেশহোল্ড যোগ করুন। এটাই পরে অনেক টিমকে আটকে দেয়। যদি $500 এর নিচের অনুরোধ টিম লিডের কাছে যায় কিন্তু $500 এর বেশি বিভাগীয় প্রধানের কাছে যায়, তা এখনই লিখে রাখুন। যদি জরুরি অনুরোধ একটি ধাপ বাদ দেয় বা দ্রুত পথ অনুসরণ করে, তা ও ক্যাপচার করুন।

তারপর ব্যতিক্রম, সময়সীমা ও চূড়ান্ত অবস্থা রেকর্ড করুন। অনুপস্থিত ডকুমেন্ট, ডুপ্লিকেট অনুরোধ, নীতি লঙ্ঘন ও অতিবিলম্বে অনুমোদনসহ কেসগুলো যোগ করুন। নিয়মটি তখনই সম্পন্ন হবে যখন আপনি জানেন সমস্যার সম্মুখীন হলে এটি কিভাবে আচরণ করবে।

শেষে, খসড়াটি মহার্ঘ্য যারা আজ অনুরোধ অনুমোদন করেন তাদের সাথে রিভিউ করুন। জিজ্ঞেস করুন কোথায় সাধারণত কাজ আটকে যায়, কোথায় মানুষ ধাপ বর্জন করে, এবং সাধারণ অনুমোদনকারী অনুপস্থিত হলে কী হয়। বাস্তব অভ্যাস প্রায়ই এমন নিয়ম প্রকাশ করে যেগুলো কখনোই ডকুমেন্ট করা হয়নি।

একটি ছোট উদাহরণ এটাকে সুস্পষ্ট করে। মনে করুন একটি ক্রয় অনুরোধ: অফিস সামগ্রী $200 এর নিচে গেলে টিম লিডের কাছে যায়, সফটওয়্যার $200 থেকে $2,000 এর মধ্যে গেলে বিভাগীয় ম্যানেজারের কাছে যায়, এবং এর বেশি হলে ফাইন্যান্সও দরকার। যদি ফর্মটি শুরুতেই পরিমাণ ও শ্রেণি ধরেনা, UI সঠিক পথে অনুরোধ পাঠাতে পারবে না।

মানুষ সহজে অনুসরণ করতে পারে এমন থ্রেশহোল্ড নির্ধারণ করুন

থ্রেশহোল্ড তখনই কাজ করে যখন মানুষ তা দ্রুত পড়ে এবং প্রতিবার একই সিদ্ধান্ত নেয়। যদি নিয়ম বলে "ছোট খরচ" বা "উচ্চ-ঝুঁকিপূর্ণ বিক্রেতা", ভিন্ন মানুষ ভিন্নভাবে ব্যাখ্যা করবে। বরং নির্দিষ্ট সংখ্যা, তারিখ ও নামকৃত শর্ত ব্যবহার করুন।

একটি স্পষ্ট নিয়ম এরকম শোনায়: "$1,000 পর্যন্ত টিম লিডের কাছে যায়। $1,001 থেকে $5,000 বিভাগীয় ম্যানেজারের কাছে যায়। $5,000 এর বেশি হলে ফাইন্যান্স ও ডাইরেক্টরের অনুমোদন লাগে।" কাউকে অনুমান করতে হবে না কোথায় অনুরোধ যাবে।

পরিমাণ সাধারণ, কিন্তু যদি আপনার প্রক্রিয়া অন্য ফ্যাক্টরের ওপর নির্ভর করে তবে এটিই কেবল ট্রিগার হওয়া উচিত নয়। নতুন বিক্রেতার কাছ থেকে সস্তা সফটওয়্যার কেনা অনুমোদনের চেয়ে অনুমোদিত সরবরাহকারীর বড় অর্ডার কম ঝুঁকিপূর্ণ হতে পারে।

অধিকাংশ টিমের জন্য ছোট একটি রাউটিং নিয়ম সেটই যথেষ্ট। সাধারণ উদাহরণ: পরিমাণ রেঞ্জ, বিক্রেতার অবস্থা, ক্রয়ের শ্রেণি, বিভাগ ও জরুরি অবস্থা। গুরুত্বপূর্ণ অংশটি নিয়মের সংখ্যা নয়—সবাই সেগুলো একইভাবে প্রয়োগ করে কিনা।

নিয়মগুলোর ক্রমও গুরুত্বপূর্ণ। যদি মানুষ জানে না কোন শর্তে প্রাধান্য রয়েছে, তারা একই অনুরোধ আলাদা ভাবে রুট করবে। একটি ক্রম বেছে নিন এবং ধারাবাহিকভাবে অনুসরণ করুন। হয়তো আপনি বিক্রেতা স্ট্যাটাস প্রথমে পরীক্ষা করবেন, তারপর শ্রেণি, তারপর পরিমাণ; বা পরিমাণকে প্রথমে চেক করে ব্যতিক্রম পরে হ্যান্ডেল করবেন। দুটো পদ্ধতিই কাজ করে যদি সবাই একই সিকোয়েন্স অনুসরণ করে।

এছাড়াও নির্ধারণ করুন কে কখন থ্রেশহোল্ড ওভাররাইড করতে পারে। না হলে স্টাফরা হয় দেরি করে প্রতীক্ষা করবে অথবা ইমেইল ও চ্যাটে প্রক্রিয়া বাইপাস করবে। "মাস-এন্ড ক্লোজের সময় ফাইন্যান্স ডাইরেক্টর সীমার উপরে অনুমোদন করতে পারেন" ব্যবহারিক। "সিনিয়র নেতৃত্ব ব্যতিক্রম করতে পারে" অস্পষ্ট।

একটি সহজ পরীক্ষা কাজ করে: একই উদাহরণ তিনজনকে দিন এবং জিজ্ঞাসা কোথায় এটি যাবে। যদি তিনটি ভিন্ন উত্তর দেন, থ্রেশহোল্ডগুলো এখনও অস্পষ্ট।

ব্যাকআপ অনুমোদনকারী, বদলি ও স্কেলেশনের পরিকল্পনা করুন

একটি শক্তিশালী ম্যাট্রিক্স প্রধান অনুমোদনকারী দিয়ে শেষ করে না। বাস্তব কাজ তখনই চলতে থাকে যখন কেউ ছুটিতে, অসুস্থ বা কেবল সময়মতো প্রতিক্রিয়া দেয় না। যদি আপনি আগে থেকেই তা পরিকল্পনা না করেন, স্ক্রিন neat দেখলেও প্রক্রিয়া নীরবে স্থবির হবে।

প্রতিটি গুরুত্বপূর্ণ ধাপের জন্য ব্যাকআপ অনুমোদনকারী নাম করে শুরু করুন। এটি এমন একজন ব্যক্তি বা ভূমিকা হওয়া উচিত যার প্রাসঙ্গিক কনটেক্সট আছে, কেবল "পরের ম্যানেজার" নয়। যদি ফাইন্যান্স লিড নির্দিষ্ট পরিমাণের ওপর ব্যয় অনুমোদন করে, সেই ব্যক্তি অনুপস্থিত হলে কে ইনবক্স নেবে তা সিদ্ধান্ত নিন।

স্থায়ী নয় এমন বদলি নিয়ন্ত্রণ থাকা উচিত। একটি বদলি কেবল নির্দিষ্ট সময়ের জন্য অনুমোদন অধিকার পাবে, যেমন ভ্যাকেশন বা পরিকল্পিত ছুটির তারিখ। এতে দায়িত্ব স্পষ্ট থাকে এবং কেউ অতিরিক্ত সময় অনুমোদন অ্যাক্সেস ধরে রাখে না।

একটি সহজ সেটআপ চারটি প্রশ্নের উত্তর দেয়: প্রধান অনুমোদনকারী কে, ব্যাকআপ কে, বদলি কতক্ষণ কাজ করতে পারে, এবং কখন অনুরোধ চেইন ধরে উপরে উঠবে।

স্কেলেশনগুলো স্পষ্ট ট্রিগারের ওপর ভিত্তি করে থাকা উচিত, অনুমানের ওপর নয়। সাধারণ ট্রিগারগুলোর মধ্যে সময়, পরিমাণ, ঝুঁকি বা অনুপস্থিত তথ্য আছে। উদাহরণস্বরূপ, যদি $10,000 এর ওপরে একটি ক্রয় অনুরোধ ২৪ ঘণ্টা টিকে থাকে, তা বিভাগীয় প্রধানের কাছে স্কেলেট করা হতে পারে।

স্কেলেশন পথ ছোট রাখুন। যদি কারও বুঝতে একটি জটিল ডায়াগ্রাম লাগবে যে পরবর্তী অনুমোদনকারী কে, নিয়মটি সম্ভবত খুব জটিল। সাধারণত এক বা দুইটা স্পষ্ট লাফ যথেষ্ট।

প্রতিটি সিদ্ধান্তও রেকর্ড করুন। কে অনুমোদন করেছে, কে বদলি হিসেবে কাজ করেছে, হস্তান্তর কখন হয়েছে, এবং কেন অনুরোধ স্কেলেট হয়েছে—এই ইতিহাস পরে কারো প্রশ্ন উঠলে দরকার হবে।

আর এক নিয়ম অত্যন্ত গুরুত্বপূর্ণ: লুপ এড়ান। একটি অনুরোধ কখনোই এমনভাবে ফিরবে না যার কাছে আগে থেকেই অনুমোদন করা হয়েছে, কিংবা একই ব্যক্তির বদলি যে একই ব্যক্তির জন্য কাজ করেছে তার কাছে ফিরে যাবে না। অ্যাপ লজিক তৈরি করার আগে ম্যাট্রিক্সে বৃত্তাকার পথ আছে কিনা চেক করে নিন।

সহজ উদাহরণ: ক্রয় অনুরোধ অনুমোদন

একটি ছোট কোম্পানি দৈনন্দিন জিনিস ক্রয় করছে ভাবুন। একজন কর্মী একটি ক্রয় অনুরোধ জমা দেয়—আইটেম, পরিমাণ, কারণ ও দরকারের তারিখ। রাউটিং নিয়ম দ্বারা চালিত হয়, অনলাইন থাকা ব্যক্তির ওপর নয়।

যদি অনুরোধ $420 হয়, এটি সরাসরি টিম লিডের কাছে যায়। এতে ছোট ক্রয়গুলো দ্রুত চলবে। $3,200 অনুরোধ টিম লিডকে স্কিপ করে বিভাগীয় ম্যানেজারের কাছে যায় কারণ বাজেট প্রভাব বেশি।

এখন ধরুন $7,800 নতুন সরঞ্জামের জন্য। বিভাগীয় ম্যানেজার এখনও পর্যালোচনা করে, কিন্তু সেটা যথেষ্ট নয়। $5,000 এর ওপরে হওয়ায় ফাইন্যান্সকেও পর্যালোচনা করতে হবে। স্পষ্ট ম্যাট্রিক্স এখানে সাহায্য করে: বড় পরিমাণ নিয়ন্ত্রণ বাড়ায় কিন্তু অনুমান কমায়।

অনুপস্থিতিও এখানে গুরুত্বপূর্ণ। যদি বিভাগীয় ম্যানেজার ছুটিতে থাকেন, অনুরোধ লিম্বোতে থাকা উচিত নয়। একটি নামকৃত বদলি স্বয়ংক্রিয়ভাবে এটি পাবে এবং নির্ধারিত সময়ের জন্য কাজ করতে পারবে।

সময়সীমা সম্পূর্ণ স্পষ্ট রাখা উচিত। কেউ যদি দুই দিনের মধ্যে কাজ না করে, অনুরোধ অপারেশনের কাছে স্কেলেট হবে। অপারেশন ফলো-আপ, পুনরায় নিয়োগ বা নিশ্চিত করতে পারে যে এটি কাজ আটকে রাখছে না।

এই উদাহরণে ম্যাট্রিক্স কয়েকটি সহজ কিন্তু গুরুত্বপূর্ণ প্রশ্নের উত্তর দেয়: কত টাকা অনুরোধ করা হচ্ছে, প্রতিটি পরিমাণে কোন ভূমিকা অনুমোদন করে, কখন ফাইন্যান্স যোগ হয়, অনুপস্থিতি কারা কভার করবে, এবং সময়সীমা মিস হলে কী হয়।

একবার এই উত্তরগুলো নির্ধারিত হলে, স্ক্রিন ডিজাইন স্বচ্ছ হয়ে যায়। ফর্মটিতে কেবল সঠিক ডেটা দরকার, এবং অনুরোধ পৃষ্ঠায় কেবল বর্তমান অনুমোদনকারী, কোনো বদলি আছে কি না, এবং স্কেলেশন ঘড়ি চালু আছে কিনা দেখানো লাগবে।

সাধারণ ভুল যা পুনরায় কাজ ছাড়ে

বেশিরভাগ পুনরায় কাজ একটি স্ক্রিন আঁকারও আগে শুরু হয়। দলগুলো অনুমোদন পথ অনুমান করে, তারপর UI-কে এমন নিয়মে ফিট করতে চায় যেগুলো কখনোই সম্মত হয়নি।

একটি সাধারণ ভুল হল অর্গ চার্ট কপি করে সেটাকে ওয়ার্কফ্লো বলা। তা আরও পরিষ্কার দেখাতে পারে, কিন্তু বাস্তব অনুরোধগুলো প্রায়ই পরিমাণ, ঝুঁকি, অবস্থান বা অনুরোধ প্রকার অনুসারে চলে। যদি ম্যাট্রিক্স তা উপেক্ষা করে, পরে স্ক্রিনগুলো অতিরিক্ত ক্ষেত্র, অতিরিক্ত স্টেট এবং অস্বস্তিকর ব্যতিক্রম নিয়ে ভরে উঠবে।

আরেকটি সমস্যা বিশেষ কেস ভুলে যাওয়া। জরুরি অনুরোধ, নিয়ন্ত্রিত ক্রয় বা ক্রস-টিম অনুরোধ প্রায়ই ভিন্ন পথ দরকার করে। যদি সেই ব্যতিক্রমগুলো আগে ম্যাপ না করা হয়, মানুষ ম্যানুয়াল ওয়ার্কআরাউন্ড চাইবে, আর ইন্টারফেস এক-অফ অপশনগুলোতে ভরে যাবে যা সবাইকে বিভ্রান্ত করবে।

দলগুলো সমস্যা তৈরি করে যখন তারা একই কাজ দুইজনকে দিয়ে দেয় কিন্তু বাইরের কোনো টায়-ব্রেক নিয়ম দেয় না। উভয়ই অনুমোদন করতে পারে হলে কে আগে করবে? যদি তারা اختلاف করে, কাদের সিদ্ধান্ত কার্যকর হবে? সেই উত্তর ছাড়া অনুরোধ ঘুরে বেড়ায় এবং ব্যবহারকারীর আস্থা হারায়।

বদলি নিয়মও দুর্বল জায়গা। একটি বদলি অনুপস্থিতি ঢাকতে হবে, স্থায়ী মালিক হয়ে যেতে নয়। যখন সাময়িক কভার এবং স্থায়ী মালিকানা যোগাে হয়ে যায়, রিপোর্টগুলো বিঘ্নিত হয় এবং দায়িত্ব অদৃশ্য হয়ে যায়।

রাউটিং চূড়ান্ত না হলে ফর্ম ডিজাইন করা পুনরায় কাজের আরেকটি কারণ। ফর্ম সম্পন্ন মনে হলেও একবার অনুমোদন নিয়ম চূড়ান্ত হলে প্রায়ই দেখা যায় অনুপস্থিত ক্ষেত্র যেমন পরিমাণ ব্যান্ড, বিভাগ, জরুরি বা নীতি ফ্ল্যাগ। তখন লেআউট, ভ্যালিডেশন ও নোটিফিকেশন সবকিছুই পরিবর্তন করতে হয়।

একটি দ্রুত বাস্তবতা পরীক্ষা তাড়াতাড়ি এইগুলিকে ধরা দেয়:

• কি দুইজন অনুমোদনকারী একই অনুরোধ একসাথে পেতে পারে?
• কুই পর্থক্য কি সাময়িক ব্যাকআপ ও স্থায়ী মালিকানার মধ্যে আছে?
• কি জরুরি বা নিয়ন্ত্রিত কেস আলাদা পথ অনুসরণ করে?
• কি প্রতিটি রাউটিং সিদ্ধান্ত এমন একটি ক্ষেত্রের ওপর নির্ভর করে যা ইতিমধ্যে আছে?
• যদি একজন অনুমোদনকারী কোম্পানি ছেড়ে চলে যায়, তখনও কি প্রক্রিয়াটি অর্থপূর্ণ থাকবে?

যদি কোনো উত্তর অস্পষ্ট হয়, সেখানে থামুন। স্ক্রিন পালিশ করার আগে ম্যাট্রিক্স ঠিক করুন।

স্ক্রিন ডিজাইন করার আগে ত্বরিত পরীক্ষা

ফর্ম বা স্ট্যাটাস ব্যাজ আঁকার আগে সাধারণ ভাষায় লজিক পরীক্ষা করুন। একটি ভাল অনুমোদন ম্যাট্রিক্স এমনভাবে সহজ হওয়া উচিত যে একটি ডায়াগ্রাম না খুলেই বোঝানো যায়। যদি একটি ম্যানেজার, ফাইন্যান্স লিড বা অপারেশন সহকর্মী প্রায় এক মিনিটে পুরো রুট বর্ণনা না করতে পারেন, প্রক্রিয়াটি এখনও UI কাজের জন্য অস্পষ্ট।

বাস্তব উদাহরণ দিয়ে দ্রুত রিভিউ চালান। একজনকে অনুরোধ থেকে চূড়ান্ত সিদ্ধান্ত পর্যন্ত সম্পূর্ণ রুট ব্যাখ্যা করতে বলুন। নিশ্চিত করুন প্রতিটি সম্ভাব্য ফলের পরের অনুমোদনকারী নামকৃত আছে, কেবল হ্যাপি পথ নয়। অস্পষ্ট থ্রেশহোল্ডগুলোকে স্পষ্ট নিয়মে পুনরায় লেখুন যেমন "$1,000 এবং তার নিচে" বা "10% এর বেশি ডিসকাউন্ট"। ব্যাকআপ ও স্কেলেশন নিয়মগুলো স্পষ্ট সময়সীমা ব্যবহার করুক— "২৪ ঘণ্টার পরে" বা "২ ব্যবসায়িক দিনের পরে"।

তারপর ট্রেসিবিলিটি পরীক্ষা করুন। পরে কেউ জিজ্ঞেস করবে কেন একটি অনুরোধ দেরি হয়েছে, কোন ব্যতিক্রম অনুমোদিত হয়েছিল, বা বদলি কখন ধরা পড়েছে—আপনার প্রক্রিয়াটি আগে থেকেই সেই প্রশ্নগুলোর উত্তর দেয়া উচিত। টাইমস্ট্যাম্প, সিদ্ধান্ত ইতিহাস ও স্পষ্ট স্ট্যাটাস পরিবর্তনগুলো অতিরিক্ত নয়; এগুলো নিয়মসেটের অংশ।

একটি সহজ পরিস্থিতি সাধারণত দুর্বলতাগুলো উন্মোচিত করে। ধরা যাক $4,800 ক্রয়ের অনুরোধ শুক্রবার বিকালে আসে যখন স্বাভাবিক অনুমোদনকারী নেই। পরবর্তী কে? সিস্টেম কতক্ষণ অপেক্ষা করবে? যদি ব্যাকআপও কিছু না করে, কি হবে? যদি সেই উত্তরগুলো লিখিত না থাকে, UI বিভ্রান্তি লুকিয়ে রাখবে সমস্যার সমাধান নয়।

এই পরীক্ষাগুলো পাস করলে স্ক্রিন ডিজাইন অনেক সহজ হয়। আর আপনি জানেন কি দেখাবে UI—অস্পষ্টতা নয়, নির্দিষ্ট নিয়মের প্রকাশ।

পরবর্তী ধাপ: ম্যাট্রিক্সকে কার্যকর অ্যাপে পরিণত করুন

নিয়মগুলো স্পষ্ট হলে, স্ক্রিন পালিশ করার আগে প্রক্রিয়াটি গড়ে তুলুন। লজিক, ডেটা ফিল্ড ও অনুমোদন স্টেট দিয়ে শুরু করুন। যদি রাউটিং কাজ করে, ইন্টারফেস ডিজাইন করা অনেক সহজ হয়। যদি রাউটিং এখনও পরিবর্তনশীল থাকে, সাজানো স্ক্রিন শুধু সমস্যা লুকিয়ে রাখবে।

একটি ব্যবহারিক প্রথম সংস্করণ সাধারণত বেসিকগুলোর মধ্যে থাকে: অনুরোধ ধরন, পরিমাণ, বিভাগ, বর্তমান অনুমোদনকারী, চূড়ান্ত স্ট্যাটাস এবং প্রতিটি সিদ্ধান্তের স্পষ্ট ইতিহাস। তারপর সেই নিয়মগুলো যোগ করুন যা অনুরোধকে এগিয়ে পাঠায়, ব্যাকআপ অনুমোদনকারীকে দেয়, বা কেউ সময়মত উত্তর না দিলে স্কেলেশন ট্রিগার করে।

প্রথম স্ক্রিনগুলো সহজ রাখুন। একজন রিকোয়েস্টার জমা দিতে, স্ট্যাটাস চেক করতে এবং ফলো‑আপ প্রশ্নের উত্তর দিতে পারবে। একজন অনুমোদনকারী পর্যালোচনা, অনুমোদন, প্রত্যাখ্যান বা পুনরায় নিয়োগ করতে পারবে। এতটুকুই প্রয়োজন প্রক্রিয়াটি দৈনন্দিন ব্যবহারিক কিনা পরীক্ষা করতে।

একটি যুক্তিসঙ্গত নির্মাণ ক্রম সরল:

• মূল ডেটা ফিল্ড ও স্ট্যাটাস মান নির্ধারণ করুন
• থ্রেশহোল্ড, ব্যাকআপ অনুমোদনকারী, বদলি ও স্কেলেশনের জন্য রাউটিং নিয়ম যোগ করুন
• রিকোয়েস্টার ও অনুমোদনকারীদের জন্য বেসিক স্ক্রিন তৈরি করুন
• নিশ্চয় করুন প্রতিটি চ্যানেল একই সুত্র ব্যবহার করে
• ব্যাপকভাবে রোল আউটের আগে একটি বাস্তব অনুরোধ শুরু থেকে শেষ পর্যন্ত পরীক্ষা করুন

এই শেয়ার করা সুত্র অনেক বেশি গুরুত্বপূর্ণ যেটা অনেক দল প্রত্যাশা করে না। যদি মোবাইলে এক স্ট্যাটাস দেখায়, ওয়েব প্যানেলে ভিন্ন দেখায়, এবং ব্যাকএন্ডে ভিন্ন থ্রেশহোল্ড থাকে, আস্থা দ্রুত মুছে যায়।

যদি আপনি AppMaster-এ এটা তৈরি করেন, একটি স্পষ্ট ম্যাট্রিক্স সেটআপকে অনেক সহজ করে দেয়। আপনি প্রথমে ডেটা, ব্যবসায়িক লজিক ও অনুমোদন ফ্লো মডেল করতে পারেন, তারপর একই প্রক্রিয়া ব্যাকএন্ড, ওয়েব ও মোবাইলে আলাদা করে লিখতে হয় না।

প্রথম পরীক্ষার জন্য একটি বাস্তব কেস ব্যবহার করুন। একটি প্রকৃত ক্রয় অনুরোধ চালান যার মধ্যে একটি থ্রেশহোল্ড, একটি বদলি অনুমোদনকারী ও একটি সময়মত স্কেলেশন আছে। দেখুন কোথায় মানুষ থমকে, কোন ডেটা তারা মিস করে, আর কোন স্ট্যাটাস লেবেলগুলো তাদের বিভ্রান্ত করে।

এরপর ভাষা ও লেআউট উন্নত করুন। যখন বাস্তব অনুরোধে প্রক্রিয়াটি কাজ করে, স্ক্রিনগুলো ডিজাইন করা সহজ হয় এবং এক সপ্তাহ পর পুনর্নির্মাণের সম্ভাবনা অনেক কমে যায়।