Distorted Designers

সবাই কেমন আছেন? আশা করি সবাই ভালো আছেন এবং নিজ বাসাতে পরিবারের সাথে সুস্থ আছেন।

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

১. ডিসাইন চেক এর কোনো স্ট্যান্ডার্ড নিয়ম আছে কিনা?
২. কোনো টুল অথবা আপ ইউস করেন কিনা?
৩. যদি দেখেন ui ইস্যুস আছে তাহলে সেগুলো কি ভাবে এড্রেস করেন?
৪. আপনার কি স্বাধীনতা আছে প্রোডাক্ট রিলিজ থামিয়ে দেয়ার যদি কোনো ডিসাইন ইসু পান?
৫. মাঝে মাঝে আমাদের ডিজাইনারদের দেখা যায় প্রচুর কম্প্রোমাইস করতে। কারণ প্রোডাক্ট রিলিজ করার ডেডলাইন থাকে। এই ক্ষেত্রে আপনি বা আপনার কোম্পানি কি করে?

সরি ! অনেক প্রশ্ন করে ফেললাম

Thanks Shabbir bhai for bringing this up. I am replying in English as I can type faster

We call this "design review" but this is not an one-off session. This is a continuous process for us to minimise the conflict and maximise the output.

So when we finish the design we present to the scrum team and discuss. There they get the idea of the overall design approach and our thinking process. Although our scrum teams know that we are very strict (pixel perfect) as a designer, we still discuss the visual designs (spacing, sizes, colour etc.) It also help them sizing. Developers! if you have any concerns please discuss now.

During the development, we as a designer, always attend the daily scrum meeting and discuss the process. If any design related issue we discuss and fix. So this continues until the release. And before the release we have the final design review session along with other designers (1 or 2, depending on the project size).

Tips: During the develpment, you can share the progress with your team members (designers). Sometimes it is very helpful.

So answering your questions -

১. ডিসাইন চেক এর কোনো স্ট্যান্ডার্ড নিয়ম আছে কিনা?
We follow the above process. Don’t know how good is that but it works. However we are always looking for better process to improve.

২. কোনো টুল অথবা আপ ইউস করেন কিনা?
We share our sketch file and prototype link with the developers so that they can get the measurements. They have licences as well.

৩. যদি দেখেন ui ইস্যুস আছে তাহলে সেগুলো কি ভাবে এড্রেস করেন?
During the development we show them manually using the design file. But after the release we always mark (red) and explain where the issue is. This is also a good practice for documentation. Also developers realise that how carefully we consider those specifications.

below- sketch pages where we address issues. below- how we mark design issues. It works mostly for our developers who work in different countries (Philippines and New Zealand) ৪. আপনার কি স্বাধীনতা আছে প্রোডাক্ট রিলিজ থামিয়ে দেয়ার যদি কোনো ডিসাইন ইসু পান?
I never experienced this before. Also we don’t expect to come to this stage as we follow a better collaboration process. However if it happens then we address those issues and plan for after release fixing. We call this hot fix.

৫. মাঝে মাঝে আমাদের ডিজাইনারদের দেখা যায় প্রচুর কম্প্রোমাইস করতে। কারণ প্রোডাক্ট রিলিজ করার ডেডলাইন থাকে। এই ক্ষেত্রে আপনি বা আপনার কোম্পানি কি করে?

Here we decide what can be delivered in the planning meeting. For short-project-time we deliver with basic design and then improve over next few releases.

Good topic

আমরা আমাদের কোম্পানিতে এই স্টেপকে "ডিসাইন চেক"বলে থাকি। আমাদের কোনো QA টীম নেই, যার জন্য আমাদের ডিসাইনারদেরই কাজ টি সম্পন্ন করতে হয়.
আমাদের কাছে কোনো ডিসাইন প্রজেক্ট ডেভেলোপমেট প্রসেসর পর আসলে আমরা সেটি চেক করে তার প্রব্লেম গুলা ৩ ধরণের ভাগে ভাগ করি.
১. Major problemtic design issue (অবশ্যই সমাধান করতে হবে)
২. Secondary problemtic design issue ( মেজর ইসু সমাধান করার পর সময় থাকলে কাজ করতে হবে)
৩. Less problemtic design issue (সমাধান না করলেও চলবে)

ডিসাইন ওয়ার্কর সমস্যা গুলো খুঁজে সেটাকে দেখানোর জন্য আমরা স্ক্রিনশট ব্যবহার করি. আসিফ ভাই যেভাবে দেখিয়েছেন। সমস্যা গুলো "রেড মার্ক" করে চিহ্নিত করে দেয়া হয় যেন ডেভেলপার এবং ক্লায়েন্ট সহজে বুজতে পারে। তারপর সেগুলো কে এই ৩ ধরণের ভাগে ভাগ করা হয়।
অনেকেরই সময় কমের সমস্যা টি থাকে সেক্ষেত্রে তারা ১ম ভাগ নিয়ে আগে কাজ করে ফেলেন।

Ok, thanks everyone for your responses. I appreciate it!

Now, let me tell you what kind of process we follow in our company. I didn't mention it in my post before. Because I wanted to know your process first and then I wanted to compare it with ours

• After hand-off all the designs to our developers through Zeplin, they start working on it. Since we use Zeplin therefore we do not provide any design details. Such as spacing, sizes, colour etc.

• During the development phase, they directly come to us or call a quick meeting if they get any queries.

• After finish the initial development, they deploy their code to one of our testing servers and move their jira card to "Design check" column. We get notified when there is a card available in "Design Check" column.

• One of our designers pick up that card and start design check process.

• We also take screenshots and provide detailed design issues. For screenshot we use MonoSnap.

• If we see any major UI issues or any interaction issues then raise the flag as "Blocker" and hold the release. Yes, in our company we have this supreme power. But before we raise the flag we do lots of discussions with our developers, PO and VP.

• After that, they fix those issues and deploy it again for design check.

So basically the process is pretty much similar to what you guys do. I just wanted to double-check and wanted to make sure we are not doing anything unique and out of the box.

So, one thing we can say that, there is no standard rule for design check. You can set a process according to your project and company development process.

It's really a good topic. Thanks for share

১. ডিসাইন চেক এর কোনো স্ট্যান্ডার্ড নিয়ম আছে কিনা?

আমরা কোন ধরা বাধা নিয়ম মানি নাহ, কিন্তু ডেক্সটপ এন্ড মোবাইল ঠিক ঠাক মতেও দেয়কাই কিনা এন্ড চলে কিনা অইগলা মানি

২. কোনো টুল অথবা আপ ইউস করেন কিনা?

chrome developer tool ব্যবহার করি কিন্তু QA টিম তাদের বিভিন্ন ধরণের সফ্টওয়্যার ব্যবহার করে

৩. যদি দেখেন ui ইস্যুস আছে তাহলে সেগুলো কি ভাবে এড্রেস করেন?

আমাদের ui ux ue (front-end) একই টিমের অধীনে তাই আমরা সহজে আমাদের মূল বেসিক ui ইস্যুয়ে গুলা চেক করতে পারি, আমরা সমস্ত মার্কআপ জিনিস তৈরি করি এমনকি বেশিরভাগ ক্ষেত্রে আমরা js a অনেক কিছু করি তারপর ডেভলপমেন্ট টিমকে সরবরাহ করি এবং ডেভেলপমেন্ট করার টাইমে আমরা চেষ্টা করা হয় দেখাশোনা করার

৪. আপনার কি স্বাধীনতা আছে প্রোডাক্ট রিলিজ থামিয়ে দেয়ার যদি কোনো ডিসাইন ইসু পান?

টা খুব একটা নাই কিন্তু কোন ইস্যু থাকলে টিম মিলাজিলা কাজ করি এন্ড প্রোডাক্ট রিলিজ অটো পিছাই যাই

৫. মাঝে মাঝে আমাদের ডিজাইনারদের দেখা যায় প্রচুর কম্প্রোমাইস করতে। কারণ প্রোডাক্ট রিলিজ করার ডেডলাইন থাকে। এই ক্ষেত্রে আপনি বা আপনার কোম্পানি কি করে?

আমরা আগে ঠিক করা থাকে কতটুক নিয়া আমরা প্রোডাক্ট রিলিজ দিবো। তাই আমারা ডিজাইন করার সমেয়ে ওইটুক এ করি এন্ড ভবিষ্যতের চাহিদাও বজায় রাখার চেষ্টা করি

চমৎকার একটি টপিক তুলে ধরার জন্য ধন্যবাদ @Shabbir ভাই।

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

১। স্প্রিন্ট ব্রিফিং এর সময় ডিজাইনও ব্রিফ করা হয়। হ্যান্ড-অফ সাধারণত যেপলিনে করা হয়, সাথে প্রজেক্টভেদে প্রোটোটাইপ লিঙ্কও দেয়া হয়। আবার কিছু প্রজেক্টে ফিগমা ব্যবহার করা হয়। এসময় ডেভলপাররা, QA (এবং স্ক্রাম মাস্টার), প্রোডাক্ট ম্যানেজার আর ডিজাইন লিড সক্রিয় অংশগ্রহণ করে।
২। ডেইলি স্ট্যান্ডআপ স্ক্রামে ডেভেলপমেন্ট আপডেট জানা যায়। এর বাইরে কোন ইস্যু থাকলে সেটা QA-এর মাধ্যমে ডিজাইন লিডের কাছে আসে।
৩। কোন বিল্ড বা রিলিজ রেডি হলে QA ফাংশনালিটি চেক করার পর ডিজাইন চেক করার জন্য ডিজাইন টিমের দায়িত্বপ্রাপ্ত কোন ডিজাইনারের সাথে রিভিউ করতে বসে এবং বেশিরভাগ সময় নোট লিখে নেয়, প্রয়োজন হলে স্কিনশটের মাধ্যমে ফিডব্যাক দেয়া হয়।
৪। QA ফিডব্যাক ডেভদেরকে ব্রিফ করে আপডেট বুঝে নিয়ে আবার ডিজাইন টিমের সাথে বসে ডিজাইন আপ্রুভ করে রিলিজের প্রস্তুতি নিতে শুরু করে।

১. ডিসাইন চেক এর কোনো স্ট্যান্ডার্ড নিয়ম আছে কিনা?

জানা নেই। আমরা বিভিন্ন ট্রায়াল এন্ড এরর এর মাধ্যমে একটা প্রসেস দাড় করানোর চেষ্টা করছি। এখনো কিছু সমস্যা (ডকুমেন্টেশন, ফলোআপ ইত্যাদি) রয়ে গেছে।

২. কোনো টুল অথবা আপ ইউস করেন কিনা?

শুধু কানবান বোর্ড ব্যবহার করা হয়।

৩. যদি দেখেন ui ইস্যুস আছে তাহলে সেগুলো কি ভাবে এড্রেস করেন?

ছোটখাট ইস্যু হলে QA কে এড্রেস করলেই হয়ে যায়। সিরিয়াস কিছু হলে VP > CTO কে পর্যন্ত এড্রেস করা হয়।

৪. আপনার কি স্বাধীনতা আছে প্রোডাক্ট রিলিজ থামিয়ে দেয়ার যদি কোনো ডিসাইন ইসু পান?

এরকম কোন পরিস্থিতিতে পরিনি এখনো। মাইনর কিছু হলে কুইক প্যাচ দিয়ে ছেড়ে দেয়া হয়, বড় কিন্তু গুরুতর নয় এমন ফিচারে ইস্যু থাকলে সেটা পরের স্প্রিন্টে যোগ করা হয়।

৫. মাঝে মাঝে আমাদের ডিজাইনারদের দেখা যায় প্রচুর কম্প্রোমাইস করতে। কারণ প্রোডাক্ট রিলিজ করার ডেডলাইন থাকে। এই ক্ষেত্রে আপনি বা আপনার কোম্পানি কি করে?

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

Thanks Shad for sharing your process. Really good to know.