Skip to main content

UX & UI Real World Vademecum

Part III: The Scientific Process

Design is not art, it is problem solving. We don't wait for divine inspiration; we use a scientific method to extract the solution from data.

Research and Empathy​

13. Empathy as Data Mining​

It's Not Just "Being Nice"

What it does: Gathers raw qualitative data to understand the real problem to solve.

The Analogy: In a factory, if a machine breaks, you don't start unscrewing bolts at random. First, you ask the operator: "What were you doing? What noise did it make? When does it happen?". This is the Empathy phase. You aren't trying to make the operator like you; you are trying to diagnose the failure.

The Engineer's Bias: We tend to want the solution immediately ("Ah, we need a database!"). Empathy forces you to stay in the problem ("Wait, maybe a database isn't needed, maybe the button just needs to be bigger because they wear gloves").

14. Contextual Inquiry (Sherlock Holmes in the Factory)​

The Clean Room Interview is a Lie

What it does: Gathers the truth by observing the user in their natural habitat, not what the user says they do.

The Analogy: If you ask a person "How do you use this machine?", they will give you the manual version. If you observe them working, you'll see they stuck a post-it on the screen with the password because they forget it, and they kick the machine to make it start.

The Columbo Method: Don't be the expert. Be the Apprentice. Let the user (the Master) teach you the job. And ask "naïve" questions like Lieutenant Columbo: "Excuse me, one last thing... why did you write that number on your hand?". That is where you discover the real design problems that no questionnaire will ever reveal.

User Modeling​

15. Personas: The Scalpel​

The RPG Character Sheet

What it does: Creates a user archetype based on data to avoid designing for yourself (or for no one).

The Analogy: The Swiss Army knife does everything (scissors, knife, corkscrew), but it does it poorly. A scalpel does only one thing, but it does it perfectly. A Persona is your target.

  • Name: Mario the Operator.
  • Skill: High manual dexterity, low computer literacy.
  • Weakness: In a rush, hates reading long texts.

The Elastic User: Without a defined Persona, the development team will use the elastic user. When convenient, the user is an "expert" (so no instructions). When convenient, they are "stupid" (so we remove features).
The Anti-Persona: Define who you are not designing for (e.g., the hacker or the prankster). You need this to create security constraints without ruining Mario's experience.

16. User Journey Map​

The Movie Script

What it does: Maps the entire experience, not just clicks on the screen, to find external pain points.

The Analogy: Google Maps shows you the road, but it doesn't tell you if it's raining, if there's traffic, or if you'll be stressed because you're late. The User Journey is the emotional story of the trip.

Beyond the Screen: The Journey doesn't start when the user opens the app.

  • Before: The user is frustrated because they lost a paper document.
  • During: Opens your app to solve the problem.
  • After: Do they feel relieved or even angrier? Often UX problems are not in the software, but in the context (e.g., the app requires internet, but there is no signal in the warehouse). Only the User Journey reveals these "plot holes."

Validation and QA​

17. Nielsen's 10 Heuristics​

The Pilot's Checklist

What it does: It is a universal checklist to find usability holes.

The Analogy: Before taking off, a pilot doesn't go by "gut feeling." They have a checklist: "Flaps? Check. Fuel? Check." Heuristics are your pre-flight checklist. They aren't for creating; they are for not crashing. Run through this list before every release.

  1. Visibility of System Status
  • The Principle: The system must never keep you in the dark.
  • The Analogy: If you press the elevator button and it doesn't light up, you press it 10 more times in anger.
  • Practice: Spinners, progress bars, breadcrumbs. If the user asks "Is it stuck?", you failed.
  1. Match Between System and Real World
  • The Principle: Speak the user's language, not the database's.
  • The Analogy: Don't say "Write error on /dev/null", say "Trash is full."
  • Practice: Use familiar icons and terms (Folders, Desktop, Cart) instead of technical terms (Directory, Root, Query).
  1. User Control and Freedom
  • The Principle: The user clicks by mistake. Give them a way out.
  • The Analogy: The Emergency Exit with the panic bar. It doesn't matter how you got in, you must be able to get out immediately.
  • Practice: The "Undo" button is sacred. Never trap the user in a modal without an "X" to close it.
  1. Consistency and Standards
  • The Principle: Don't get creative with conventions.
  • The Analogy: Imagine a car where the brake is on the right and the accelerator is on the left. Chaos.
  • Practice: If red means "Stop" everywhere, don't use it for "Go." Follow Jakob's Law: the user expects your site to work like everyone else's.
  1. Error Prevention
  • The Principle: Good design stops the problem at the source.
  • The Analogy: The USB-C port (or the polarized plug). You cannot plug it in the wrong way.
  • Practice: Instead of giving a "Wrong date format" error, use a calendar that only lets you click valid dates. Disable the "Submit" button if the form is empty.
  1. Recognition Rather Than Recall
  • The Principle: Minimize cognitive load. Human RAM is limited.
  • The Analogy: A multiple-choice exam (Recognition) is easier than an open-ended essay exam (Recall).
  • Practice: Show recent history instead of making them retype the search. Show visible menu items, don't hide them behind terminal commands.
  1. Flexibility and Efficiency of Use
  • The Principle: Welcome novices, but speed up experts.
  • The Analogy: The city has standard roads for tourists, but taxi drivers know the shortcuts.
  • Practice: Keyboard shortcuts (Ctrl+C, Ctrl+V), macros, dashboard customization for "Power Users."
  1. Aesthetic and Minimalist Design
  • The Principle: Every extra unit of information competes with the relevant units.
  • The Analogy: The Signal-to-Noise ratio. If you shout 10 things at once, no one understands any of them.
  • Practice: It's not just "making white space." It's removing everything that doesn't serve the user's current goal. If it’s not needed, it’s noise.
  1. Help Users Recognize, Diagnose, and Recover from Errors
  • The Principle: Error messages must be written in human language and suggest a solution.
  • The Analogy: A doctor saying "Code 404" is useless. A doctor saying "You have a fever (Problem), take this (Solution)" is useful.
  • Practice: Never "Unknown Error." Always: "Connection lost (What), Try again shortly (How to fix)."
  1. Help and Documentation
  • The Principle: The system should be usable without instructions, but if they are needed, they must be easy to find.
  • The Analogy: The lifeboat. You hope never to use it, but if the ship sinks, it must be there and ready to use.
  • Practice: Contextual FAQs, search bar in the help center, and above all: don't write giant manuals, write task-focused guides ("How to do X").

Practical Use: Before handing over the design, run through the list. If you violate a heuristic, you must have a damn good reason.