اختبار فهم التصميم قبل اعتماده
التصميم يمكن أن يكون جميلًا ومفهومًا للمصمم والفريق، ثم يفشل أمام شخص يرى المنتج لأول مرة. السبب بسيط: الفريق يعرف كل شيء مسبقًا. يعرف أن اللون الأحمر يعني "حار"، وأن الاسم الصغير هو النكهة، وأن السهم يعني فتح الغطاء، وأن الكود A1 هو حجم العبوة. المستخدم لا يحمل هذه الخلفية.
اختبار الفهم البسيط قبل الاعتماد لا يحتاج دائمًا مختبرًا كبيرًا. يمكن أن يكون جلسة قصيرة مع أشخاص مناسبين يجيبون عن أسئلة محايدة ويؤدون مهامًا صغيرة. لكن يجب أن نكون دقيقين في ما نستنتجه: الاختبار النوعي يكشف مشاكل؛ لا يمنحك نسبة نجاح عامة للسوق.
ما الفرق بين Preference وComprehension؟
Preference: أي تصميم تحبه أكثر؟
Comprehension: ما اسم المنتج؟ أي نكهة هذه؟ أين تفتح العبوة؟ ما الفرق بين 250 g و500 g؟ ماذا تتوقع أن يحدث بعد مسح QR؟
كلاهما مفيد في سياقات مختلفة.
لكن إذا هدفك: "هل المعلومات واضحة؟" لا تسأل: "تحب التصميم؟"
قد يحب المستخدم تصميمًا لا يفهمه.
استخدم مهام واقعية
Nielsen Norman Group يعرّف Usability testing بأنه إعطاء مشارك مهام واقعية ومراقبة سلوكه والاستماع إلى ملاحظاته. ويوصي في اختبارات usability النوعية عادةً باستخدام مشاركين واقعيين، وأسئلة مفتوحة ومحايدة، وتجنب التأثير عليهم.
لتغليف: بدل: هل تعرف إن ده Spicy؟
قل: ما الذي تفهمه عن هذا المنتج؟
بدل: هل زر QR واضح؟
قل: لو كنت تريد معرفة طريقة الاستخدام، ماذا ستفعل؟
لا تعط الإجابة داخل السؤال.
حدد سؤال بحث واحد لكل Test
مثال: "هل المستخدم يميز النكهات؟"
لا تختبر في نفس 15 دقيقة:
- Logo.
- Color.
- Price.
- QR.
- Sustainability.
- Opening.
- Taste expectation.
- Brand trust.
التشتت يقلل جودة الملاحظات.
اعمل جلسات صغيرة: Test A — hierarchy. Test B — instructions. Test C — size comparison.
من هو المشارك المناسب؟
لو المنتج: Baby food. لا تختبر فقط مع مصممين.
لو المنتج: Industrial B2B label. لا تحتاج عينة من مراهقين.
اختر مستخدمًا قريبًا من:
- المشتري.
- العامل.
- الموزع.
- المستهلك.
حسب المهمة.
NN/g يوصي بتجنيد مشاركين واقعيين ممن سيقومون بالمهام في الحياة الفعلية.
لا يعني أن كل شخص يجب أن يكون Customer موجودًا فعليًا، لكن Profile يجب أن يكون مناسبًا للسؤال.
5–8 مشاركين: ماذا يعني الرقم؟
ورقة NN/g "Usability Testing 101" تقترح 5–8 مشاركين للاختبارات النوعية كإرشاد عملي شائع.
هذا لا يعني:
- 5 أشخاص يثبتون التصميم عالميًا.
- 8 يساوي Statistical significance.
- 5 مناسب لكل دراسة.
الاختبار النوعي يهدف لاكتشاف المشكلات والأنماط.
لو تريد نسبة مثل: "83% يفهمون الرمز" تحتاج Sample وتصميم بحث إحصائي مناسب.
لا تخلط.
اختبار 5 ثوانٍ
مفيد للواجهة.
اعرض التصميم 5 ثوانٍ. اخفه.
اسأل:
- ما المنتج؟
- ما العلامة؟
- ما النكهة؟
- ما المعلومة الأبرز؟
هذا يكشف hierarchy.
لكن لا تقل: "5-second test معيار علمي ثابت لكل Packaging."
هو Technique.
يمكن أن تستخدم 3 أو 5 أو 10 ثوانٍ حسب السؤال.
وسجل الوقت.
اختبار مسافة
اطبع العبوة بالحجم الحقيقي.
ضعها:
- 1 m.
- 2 m.
- 3 m.
اسأل: متى تقرأ:
- Brand?
- Product?
- Variant?
هذا مفيد للتصميم، لكنه ليس Shelf study كاملًا.
الطباعة والإضاءة والمحيط تؤثر.
سجل:
- المسافة.
- الإضاءة.
- حجم الطباعة.
لا تعمم.
اختبار Thumbnail
للEcommerce: اعرض 6 منتجات على Grid.
اسأل: اختار منتج الفستق 300 g.
راقب:
- الوقت.
- الأخطاء.
- هل يقرأ اللون أم الاسم؟
- هل يضغط منتجًا خاطئًا؟
لا تسأل: "هل Thumbnail واضح؟"
المهمة أفضل.
أسئلة Neutral
جيد: ماذا تتوقع أن يعني هذا الرمز؟
سيئ: هذا رمز إعادة التدوير، صح؟
جيد: أين ستبحث عن التحذير؟
سيئ: شايف التحذير تحت؟
جيد: ما أول شيء قرأته؟
سيئ: اسم المنتج واضح، صح؟
الميسر يجب أن يقلل تأثيره.
NN/g يوصي بالأسئلة المفتوحة والمحايدة والبقاء هادئًا أثناء المهمة.
لا تشرح التصميم قبل الاختبار
لو قلت: "الأزرق يعني النوع العادي والأحمر حار."
ثم سألت: "أي واحد حار؟"
الاختبار انتهى.
اعطِ Brief فقط كما يراه العميل.
لو Label فعلي: اعرضه بلا Pitch.
بعد المهمة يمكنك شرح.
ترتيب النسخ
لو تقارن A/B: نصف المشاركين يرى A أولًا. النصف B أولًا.
هذا يقلل Order effect.
لا تجعل الجميع يرى A ثم B.
لأنهم يتعلمون المهمة من A.
وإذا السؤال Blind: لا تقل: "A القديم وB الجديد."
هذا يخلق Bias لصالح الجديد.
قل: Version A. Version B.
سجل السلوك لا الرأي فقط
Participant يقول: "واضح."
لكنه يأخذ 20 ثانية للعثور على Flavor.
السلوك مهم.
سجل:
- Correct.
- Incorrect.
- Time.
- Hesitation.
- Quote.
- Navigation.
لا تجعل الوقت KPI ثابتًا إذا المهمة لا تحتاج سرعة.
لكن استخدمه للمقارنة.
مثال: 3 ليبل بهارات
هدف: تمييز الحرارة.
3 Variants: Mild. Medium. Hot.
Test: ضع الثلاثة أمام المشارك.
مهمة: "اختار الأقل حدة."
راقب.
ثم: "ما الذي ساعدك؟"
إذا الجميع يقول اللون، اسأل: "لو الصورة أبيض وأسود؟"
اختبر نسخة Grayscale.
قد تكتشف أن النص صغير.
الحل: تكبير Mild/Medium/Hot. اللون يصبح Cue ثانوي.
مثال: QR CTA
واجهة: Scan to discover more.
Test: "ماذا تتوقع بعد المسح؟"
إجابات:
- ingredients.
- game.
- brand story.
- discount.
هذا يعني CTA غامض.
جرب: Scan for brewing guide.
اختبر.
لا تحتاج أن تسأل "أي أحسن؟"
قياس التوقع.
اختبار Opening instruction
اعطِ العبوة.
قل: افتح المنتج كما تفعل عادة.
راقب:
- أين يمسك؟
- أين يبدأ؟
- هل يرى Tear notch؟
- هل يقرأ arrow؟
لا تقول: "افتح من السهم."
لو فشل: المشكلة قد تكون:
- graphics.
- physical design.
المصمم يحتاج يفرق.
لا يمكن للرسم يصلح notch سيئ.
Safety: لا تستخدم test لتجاوز المتطلبات
لو Warning مطلوب: لا تحذفه لأن 5 أشخاص لم يقرأوه.
Regulatory requirement مستقل.
اختبار الفهم يمكن أن يحسن:
- placement.
- hierarchy.
- wording within approved range.
لكن لا يلغي القانون.
نموذج Test script
Introduction "نختبر التصميم، مش بنختبرك أنت."
Task 1 "ما المنتج الذي تراه؟"
Task 2 "أي نسخة تختار لو أردت [variant]؟"
Task 3 "أين تجد الكمية؟"
Task 4 "ما الذي تتوقعه من QR؟"
Closing "إيه الحاجة اللي كانت محيرة؟"
لا تشرح أثناء المهام.
"نختبر التصميم، لا المستخدم"
هذه جملة تقلل قلق المشارك.
لو أخطأ: لا تقل: "لا، مش ده."
قل: "شكرًا."
ثم أكمل.
إذا صححت، ستغير سلوكه.
Remote test
ممكن:
- Screen share.
- Prototype.
- photos.
لكن Packaging physical:
- size.
- texture.
- reflection.
- opening. لن تظهر بالكامل.
Remote مناسب لـ:
- Ecommerce images.
- hierarchy.
- digital QR journey.
Physical test أفضل لـ:
- actual pack.
- opening.
- scale.
- print.
استخدم الطريقة المناسبة.
لا تستخدم المصمم كمشارك
الفريق يعرف الإجابة.
Internal review مهم للجودة.
لكن ليس Comprehension test.
يمكن استخدام موظفين من أقسام غير المشروع في early test.
ثم جمهور أقرب لاحقًا.
كيف تحلل النتائج؟
أنشئ Table:
| Task | P1 | P2 | P3 | Issue |
|---|---|---|---|---|
| identify product | ✓ | ✓ | ✓ | none |
| identify flavor | ✓ | ✗ | hesitation | flavor too small |
| find QR purpose | ? | ? | ? | CTA vague |
لا تحتاج Score مركب 87/100.
اكتب Issues.
Severity:
- Critical.
- High.
- Medium.
- Low.
حسب أثر الخطأ.
لا تخترع أرقام علمية للSeverity.
متى تغير التصميم؟
إذا 1 شخص يخطئ: هل هذا Noise؟
راقب السبب.
إذا الخطأ خطير: حتى مرة واحدة مهمة.
إذا 4/5 يخطئون: Pattern واضح.
لا تستخدم قاعدة: "أغير فقط لو 3 أشخاص."
السياق يحكم.
لا تسأل "لماذا" مباشرة دائمًا
بعد اختيار سريع: "إيه اللي خلاك تختار ده؟"
أفضل أحيانًا من: "ليه عملت غلط؟"
"لماذا" قد يجعل participant يخترع سببًا بعد القرار.
ركز على:
- ماذا رأيت؟
- ماذا توقعت؟
- ما الذي بحثت عنه؟
سلوك ثم تفسير.
Visual recall
بعد 10 ثوانٍ: اخفِ.
اسأل:
- أي لون تتذكر؟
- أي كلمة؟
- ما الشكل؟
هذا يقيس Memory limited.
لكن لا تعمم "Brand recall".
هي Session صغيرة.
قل: "في هذا الاختبار."
اختبار متعدد اللغات
لو العبوة عربي/إنجليزي: اختبر:
- قارئ عربي.
- قارئ إنجليزي.
- ثنائي اللغة.
لا تفترض أن Hierarchy نفسها تعمل.
سؤال: ما اللغة التي قرأتها أولًا؟
لو السوق يتطلب مساواة، راجع.
لكن المتطلبات القانونية يحددها السوق.
Consent والخصوصية
لو تسجل:
- Video.
- audio.
- face.
احصل على موافقة.
لا ترفع Recording إلى Cloud عشوائيًا.
حدد:
- الاستخدام.
- التخزين.
- من يشاهد.
هذا موضوع بحث أخلاقي وخصوصية، خاصة لو عملاء حقيقيون.
ماذا تكتب في Case study؟
صحيح: We ran five qualitative sessions focused on variant identification. Four participants selected the intended variant without assistance; one relied only on color. We increased the variant name and retested informally.
خطأ: 80% better usability.
لأن: 4/5 ليس "تحسن 80%" ما لم تقارن Baseline وتعريف Metric.
حتى 80% Success rate لعينة 5 يجب وصفها بحذر.
Iterative testing
Test v1. Fix. Test v2.
لا تستخدم نفس المشاركين دائمًا لو تعلموا الإجابة.
يمكن استخدام:
- بعض جدد.
- بعض سابقين لمراجعة issue محددة.
وثق.
الهدف ليس إثبات أن المصمم صح. الهدف العثور على الفشل قبل الطباعة.
متى تحتاج Research specialist؟
إذا:
- منتج عالي المخاطر.
- سوق كبير.
- Claims مهمة.
- Accessibility.
- أدوية/Medical.
- اختبار إحصائي.
استعن مختصًا.
المصمم يمكن يعمل Quick comprehension check. لا يجب أن يدعي أنه دراسة علمية كاملة.
Checklist
قبل:
- Research question.
- audience.
- task.
- neutral script.
- prototype.
- consent.
- note sheet.
أثناء:
- don't lead.
- observe.
- stay quiet.
- record behavior.
- ask open questions.
بعد:
- issue table.
- severity.
- evidence.
- design change.
- retest.
- no overclaim.
الخلاصة
اختبار فهم التصميم قبل اعتماده ليس تصويتًا على الجمال. هو طريقة لاكتشاف هل المستخدم يفهم المنتج، النكهة، الحجم، الرمز، طريقة الفتح أو الـCTA كما يتوقع الفريق. استخدم مهام واقعية وأسئلة محايدة، ولا تشرح التصميم قبل الاختبار. 5–8 مشاركين قد يكونون مفيدين في اختبار نوعي لاكتشاف مشاكل، لكنهم لا يصنعون حقيقة إحصائية عامة. اكتب ما حدث في العينة فعلًا، أصلح المشكلة، واختبر مرة أخرى. الهدف ليس إثبات أن التصميم جيد؛ الهدف أن تجد أين يمكن أن يفشل قبل أن يصبح الفشل مطبوعًا بالآلاف.
المصادر العربية
- Nielsen Norman Group — Usability Testing 101: https://media.nngroup.com/media/articles/attachments/Usability-Testing-101_SizeA4.pdf
- Nielsen Norman Group — How to Conduct Usability Studies: https://www.nngroup.com/reports/how-to-conduct-usability-studies/
- Figma — How we do design critiques at Figma: https://www.figma.com/blog/design-critiques-at-figma/
© 2026 FargPack. جميع الحقوق محفوظة للمحتوى الأصلي.
A design can look beautiful and completely obvious to the designer and project team, then confuse someone who sees the product for the first time. The reason is simple: the team already knows the answers. They know red means “hot,” the tiny line is the flavor, the arrow indicates where to open, and code A1 identifies a specific size. The user does not bring that background knowledge.
A simple comprehension test before approval does not always require a large research lab. It can be a short session with relevant participants performing small tasks and answering neutral questions. However, conclusions need discipline: qualitative testing can reveal problems; it does not automatically provide a general market success rate.
Preference and comprehension are different questions
Preference: Which design do you like more?
Comprehension: What is the product? Which flavor is this? Where would you open the package? What is the difference between 250 g and 500 g? What do you expect after scanning the QR code?
Both can matter.
But if the question is: “Is the information understandable?”
do not ask: “Do you like the design?”
A person can prefer a design they misunderstand.
Use realistic tasks
Nielsen Norman Group describes usability testing as giving participants realistic tasks while observing their behavior and listening to feedback. Its qualitative-testing guidance emphasizes realistic participants, neutral open-ended questions, and avoiding influence.
For packaging:
Instead of: Do you know this means spicy?
ask: What do you understand about this product?
Instead of: Is the QR code clear?
ask: If you wanted the preparation guide, what would you do?
Do not put the answer inside the question.
Define one research question at a time
Example: “Can users distinguish the variants?”
Do not try to test all of these in one short session:
- logo
- color
- price
- QR
- sustainability
- opening
- taste expectation
- brand trust
Focused sessions produce clearer evidence.
You can run:
Test A — hierarchy
Test B — instructions
Test C — size comparison
Recruit people who resemble the task audience
If the product is baby food, testing only with designers is weak.
If it is an industrial B2B label, a random teenage sample may not fit the task.
Recruit people reasonably close to:
- buyers
- operators
- consumers
- distributors
depending on the design question.
NN/g recommends recruiting realistic participants who would perform similar tasks in real situations.
They do not always need to be existing customers, but their profile should be relevant.
What does “5–8 participants” actually mean?
NN/g’s Usability Testing 101 material suggests roughly 5–8 participants for qualitative usability testing as a practical guideline.
That does not mean:
- five people prove universal usability
- eight create statistical significance
- five is correct for every study
Qualitative testing is mainly useful for discovering usability problems and patterns.
If you need a population percentage such as: “83% understand this symbol,” you need an appropriately designed quantitative study and sample.
Do not mix the two.
A five-second exposure can reveal hierarchy
Show a design briefly. Hide it.
Ask:
- What product was it?
- What brand?
- What flavor?
- What information stood out?
This can reveal whether the visual hierarchy matches the intended priority.
Do not present “five seconds” as a universal scientific packaging standard. It is a technique that can be adjusted depending on the research question.
Document the exposure time you actually used.
Distance testing can be useful for printed packs
Print the design at real size.
View it at:
- 1 meter
- 2 meters
- 3 meters
Ask when participants can identify:
- brand
- product
- variant
This is a practical design check, not a complete shelf-performance study.
Lighting, print quality, surrounding products, and viewing angle all influence the result.
Document the conditions.
Thumbnail testing is valuable for ecommerce
Show six products in a grid.
Task: Select the 300 g pistachio product.
Observe:
- time
- errors
- whether the participant uses color or text
- whether the wrong size is selected
This is stronger than asking: “Is the thumbnail clear?”
A task produces behavior.
Ask neutral questions
Good: What do you think this symbol means?
Bad: This is the recycling symbol, right?
Good: Where would you look for the warning?
Bad: Can you see the warning at the bottom?
Good: What did you read first?
Bad: The product name is clearer now, isn’t it?
Leading questions produce confirmation rather than evidence.
NN/g specifically recommends open-ended, neutral questions and avoiding participant influence.
Do not explain the design before the test
If you tell participants: “Blue means regular and red means spicy.”
then ask: “Which one is spicy?”
you are no longer testing the design.
Give only the context a real shopper would have.
After tasks are complete, you can explain the intended system.
Counterbalance A/B order
If you compare version A and version B:
- half the participants see A first
- half see B first
This reduces order effects.
If everyone sees A first, they may learn the category before evaluating B.
Also avoid saying: “A is old, B is new.”
That can bias people toward the redesign.
Use:
Version A
Version B
Record behavior, not only stated opinion
A participant may say: “It’s clear.”
But if they take twenty seconds to find the flavor, the behavior tells you something different.
Capture:
- correct/incorrect
- time where relevant
- hesitation
- selected element
- quote
- navigation path
Do not turn time into a KPI when speed does not matter.
Use it as a diagnostic signal.
Example: three spice labels
Goal: understand heat level.
Variants:
Mild
Medium
Hot
Task: “Choose the least spicy product.”
Observe.
Then ask: “What helped you decide?”
If everyone relies only on color, create a grayscale condition.
You may discover that the words Mild/Medium/Hot are too small.
The fix: increase textual differentiation so color becomes a secondary cue.
Example: QR call to action
Current text: Scan to discover more
Ask: “What do you expect after scanning?”
Answers might be:
- ingredients
- game
- brand story
- discount
That reveals an ambiguous promise.
Try: Scan for brewing guide
Test again.
The research question is not “Which copy do you prefer?” It is: “What destination do you expect?”
Test physical opening with the actual package
Give the participant the package.
Say: Open this as you normally would.
Observe:
- where they grip
- where they begin
- whether they find the tear notch
- whether they notice the arrow
Do not say: “Open it from the arrow.”
If the participant struggles, the cause may be graphic or structural.
Instruction graphics cannot fix a poorly engineered opening mechanism.
Separate communication failure from mechanical failure.
Testing does not override mandatory requirements
If a warning is legally required, do not remove it because five participants did not read it.
Testing can improve:
- position
- hierarchy
- approved wording
- visibility
but cannot cancel regulatory requirements.
The responsible regulatory framework remains independent of preference.
A simple test script
Introduction “We are testing the design, not testing you.”
Task 1 “What product do you think this is?”
Task 2 “Which version would you choose if you wanted [variant]?”
Task 3 “Where can you find the quantity?”
Task 4 “What would you expect from the QR code?”
Closing “Was anything confusing?”
Do not explain the answer during the tasks.
“We are testing the design, not you”
This helps reduce participant anxiety.
When they make an error: do not say, “No, that’s wrong.”
Say: “Thank you.”
Then continue.
Correcting participants changes later behavior.
Remote versus physical testing
Remote testing works well for:
- ecommerce thumbnails
- digital hierarchy
- QR landing-page expectations
- prototypes
Physical testing is stronger for:
- real package scale
- opening
- texture
- glare
- actual print
Choose the method that matches the question.
A screen photograph cannot fully reproduce a reflective foil label in hand.
The design team is not the test sample
Internal review is important.
But designers already know the system.
Use people outside the project for early checks.
Then use a more realistic target profile for important decisions.
A colleague from another department is often more informative than the designer who created the hierarchy.
Analyze results as issues, not one magical score
A simple table:
| Task | P1 | P2 | P3 | Issue |
|---|---|---|---|---|
| identify product | ✓ | ✓ | ✓ | none |
| identify flavor | ✓ | ✗ | hesitation | flavor too small |
| understand QR | ? | ? | ? | CTA vague |
You do not need an invented “87/100 usability score.”
The useful output is:
- issue
- evidence
- severity
- design response
Severity can be: Critical / High / Medium / Low based on project impact.
Do not present those labels as a standardized scientific scale unless you are using one.
When should one participant trigger a change?
There is no universal rule.
If one participant misses a minor decorative cue, it may be noise.
If one participant interprets a safety instruction dangerously, the issue may deserve immediate review.
If four out of five make the same variant error, the pattern is strong.
Context matters more than a simplistic threshold.
Be careful with “why” questions
After a selection, ask: “What did you notice that led you to that choice?”
This is often better than: “Why did you choose wrong?”
People sometimes rationalize choices after the fact.
Start with:
- what did you see?
- what did you expect?
- what were you looking for?
Behavior first, explanation second.
Recall tests need modest interpretation
After a ten-second exposure, you can ask:
- which color do you remember?
- which word?
- which shape?
That tells you something about immediate recall in the session.
It does not automatically establish: brand recall in the market
Say: “In this test…” rather than generalizing.
Test multilingual packaging with multilingual readers
For Arabic/English packs, recruit:
- Arabic readers
- English readers
- bilingual participants where relevant
Ask:
- Which language did you read first?
- Was one hierarchy dominant?
- Could you find the same information in both?
Do not assume mirrored layouts produce equal legibility.
Legal equality requirements are market-specific and should be checked independently.
Consent and privacy matter when recording
If you record:
- video
- audio
- faces
- screens
obtain informed consent.
Define:
- purpose
- storage
- access
- retention
Do not upload participant recordings casually to public cloud folders.
Even small design tests involve real people and data.
How to describe testing in a case study
Good: “We ran five qualitative sessions focused on variant identification. Four participants selected the intended variant without help; one relied on color only. We increased the variant-name size and ran another informal check.”
Bad: “80% better usability.”
Four out of five is not an “80% improvement” unless there is a clearly defined baseline and valid comparison.
Even “80% success rate” should be framed cautiously with such a small qualitative sample.
Test iteratively
Test v1. Fix. Test v2.
Avoid relying entirely on the same participants after they have learned the system.
You can reuse people for some questions, but bring new participants when you need fresh comprehension.
The goal is not to prove the designer was right. The goal is to find failure before large-scale production.
When to involve a research specialist
Consider specialist support when:
- the product is high-risk
- the market is very large
- accessibility requirements are central
- claims are high-stakes
- statistical inference is required
- medical or regulated interaction is involved
A designer can conduct a useful quick comprehension check.
They should not represent it as a full scientific market study.
Practical checklist
Before:
- research question
- target participant profile
- task
- neutral script
- prototype
- consent
- note sheet
During:
- do not lead
- observe first
- stay quiet
- record behavior
- use open questions
After:
- issue table
- evidence
- severity
- design change
- retest
- avoid overclaiming
Final takeaway
Design comprehension testing is not a beauty vote. It is a practical way to discover whether people understand the product, flavor, size, symbol, opening instruction, or call to action as the team expects. Use realistic tasks and neutral questions, and do not explain the design before testing it. A qualitative group of 5–8 participants can be useful for finding issues, but it does not create a universal statistical truth. Report what actually happened in the sample, fix the problem, and test again. The goal is not to prove the design is good — it is to find where it can fail before that failure is printed thousands of times.
English sources
- Nielsen Norman Group — Usability Testing 101: https://media.nngroup.com/media/articles/attachments/Usability-Testing-101_SizeA4.pdf
- Nielsen Norman Group — How to Conduct Usability Studies: https://www.nngroup.com/reports/how-to-conduct-usability-studies/
- Figma — How we do design critiques at Figma: https://www.figma.com/blog/design-critiques-at-figma/
© 2026 FargPack. All rights reserved for the original content.