UI/UX Principles: Designing for Humans

Look at the fan regulator on your bedroom wall — the small dial or slider that controls your ceiling fan's speed. Now think about the last time you used a website or app that frustrated you: a "Submit" button that didn't look clickable, a payment screen that froze without telling you whether your money had actually left your account, or a form that rejected your phone number without saying why. Both the regulator and the app are interfaces between a human and a machine. One of them was probably designed thoughtfully. The other was not. This chapter is about the difference, and — more importantly — about the specific, testable principles that separate the two. These are not vague opinions about "good taste." They are principles you can check, measure, and even calculate, and they are the same principles product teams at companies like Zomato, PhonePe, and IRCTC apply (and sometimes forget to apply) every day.

Two Regulators, One Lesson: What UI and UX Actually Mean

Before we go further, we need to separate two words that get used almost interchangeably in casual conversation but mean different things to a designer: UI (User Interface) and UX (User Experience).

Consider the fan regulator again. The physical dial itself — its shape, the numbers printed on it, the click you feel as it turns — is the UI. It is the actual thing you touch and look at. Now imagine two different regulators. Regulator A has a smooth dial with no numbers, turns in a direction that doesn't match whether the fan speeds up or slows down, and gives no click or resistance as you turn it, so you're never sure if you've actually changed anything. Regulator B has numbers 1 to 5 printed clearly, turns clockwise to increase speed (matching how taps and volume knobs work almost everywhere else), and clicks firmly into each position. Both regulators are UI — physical interfaces. But using Regulator A is a confusing, frustrating experience, while using Regulator B is quick and confident. That entire journey — did you understand what to do, could you do it easily, did you trust that it worked, how did you feel afterward — is the UX.

So: UI is the set of things a user sees and interacts with — buttons, icons, screens, dials, menus. UX is the complete experience of a person trying to accomplish a goal using that UI, including how easy it was to learn, how efficient it was to use, how many mistakes it caused, and how the person felt at the end. A product can have a beautiful UI and a terrible UX — think of a gorgeous-looking app where you still can't figure out how to cancel a subscription. Good UI is one ingredient of good UX, but it is not the whole recipe. The rest of this chapter builds the specific principles that turn a UI into a good UX, one at a time, each grounded in something you can test.

Affordances and Signifiers: How an Object Tells You What To Do

The designer and cognitive scientist Don Norman wrote a book that is now famous under the title The Design of Everyday Things; it began life in 1988 as a different book, originally published under the title The Psychology of Everyday Things, and the now-classic title arrived with a later reissue. Whatever it was called, the book's central idea is one you have experienced yourself: a well-designed everyday object tells you how to use it just by looking at it, without any instructions.

Norman calls this an affordance — a property of an object that suggests how it can be used. A flat metal plate on a door affords pushing. A handle affords pulling. A chair's seat height and shape afford sitting. Affordances exist whether or not the designer intended them; a flat surface always affords pushing, even if the designer wanted you to pull it. When the actual affordance of an object doesn't match what the designer intended, you get the classic "push door with a pull handle" problem — so common in real buildings that designers now call any door you push when you should pull (or vice versa) a "Norman door."

A closely related idea is the signifier — a signal that communicates where an action should happen, separate from whether the action is physically possible everywhere. A "PUSH" label on a door is a signifier. A button's drop-shadow, making it look raised off the screen like a physical key, is a signifier that says "you can press this." Underlined blue text on a webpage is a signifier that says "this is clickable." In digital interfaces, affordances in the strict physical sense barely exist — a flat glass screen doesn't actually afford pushing any one pixel more than another. Almost everything a screen communicates about what is tappable is done through signifiers: shadows, borders, colour, and shape that mimic real-world push-ability. This is why a plain grey word sitting in the middle of a paragraph, with no underline, no colour change, and no border, is a common and serious UI mistake: nothing signifies that it can be tapped, so most users will simply never discover that it can.

Feedback: The System Must Talk Back

Open BHIM or any UPI app and send someone ₹200. Between the moment you tap "Pay" and the moment the transaction actually completes on the bank's servers, there is a real gap — sometimes a fraction of a second, sometimes several seconds if the network is slow. A well-designed payment screen shows you a spinning loader, then a green checkmark and "₹200 sent to Ramesh," and only then lets you leave the screen. A poorly designed one shows nothing during that gap — the button just sits there, unchanged, and you don't know if your tap registered at all. What do most people do in that second case? They tap "Pay" again. If the first tap does eventually go through and the second tap is also processed, ₹200 has now left the account twice.

This is the principle of feedback: every action a user takes must produce a visible, timely response from the system, proportional to how significant the action is. A button should visually change the instant it is tapped (even before the real work is done) so the user knows the tap registered. A long operation — uploading a photo, processing a payment, loading train seat availability on IRCTC — needs a progress indicator, not silence. And a completed action needs unambiguous confirmation, because "probably worked" is not good enough when real money or a reserved train berth is involved. Feedback is not decoration; it is how a system prevents the very common, very costly user behaviour of "nothing happened, so let me try again."

Mapping and Consistency: Controls Should Match Reality

Go back to the fan regulator: turning it clockwise increases the speed. This works because it matches a pattern you already know from volume knobs, gas stove dials, and screw-caps — clockwise generally means "more" or "tighter" in the physical world you grew up in. Norman calls this mapping: the relationship between a control and the effect it produces should mirror the user's existing mental model of how the world works, so that using the control feels obvious rather than memorised.

A four-burner gas stove is the classic example of mapping done badly. If the knob controlling the back-left burner is placed on the front-right of the control panel, you have to think — or read a tiny diagram — every single time, because the spatial layout of knobs doesn't match the spatial layout of burners. A well-mapped stove arranges its knobs in the same 2×2 layout as its burners, so the front-left knob controls the front-left burner without any thought at all.

Digital interfaces have their own version of mapping, usually called consistency. If swiping left deletes an email in your inbox app, but swiping left archives a message in your chat app, you will make mistakes moving between them — not because you're careless, but because your brain reasonably expects one gesture to mean one thing everywhere. This is why the back arrow, the hamburger menu (three horizontal lines) for navigation, and the magnifying glass for search look almost identical across nearly every Indian app, from Flipkart to PhonePe to Zomato: designers deliberately reuse the same signifiers so that skills you learn in one app transfer to the next, and so a control's meaning is consistent within an app too — the same icon should never mean two different things on two different screens of the same product.

Constraints: Designing So Mistakes Are Hard to Make

Try to select a date of birth in the past on the IRCTC ticket-booking calendar, and you'll notice something: the calendar simply will not let you pick a journey date before today. The past dates are greyed out and untappable. This is a constraint — a deliberate restriction built into the interface that makes an invalid action physically impossible to perform, rather than merely warning you after you've done it.

Constraints are a stronger and generally better tool than error messages. An error message that says "Journey date cannot be in the past" only appears after a user has already wasted time selecting the wrong date, typing in passenger details, and clicking submit. A constraint that greys out past dates from the start prevents the mistake from ever happening. The general design principle is: where possible, make the wrong action impossible or clearly unavailable, rather than merely detectable after the fact. A phone number field that only accepts 10 digits and rejects a letter the instant it's typed is a constraint; a dropdown of Indian states (instead of a free-text box where someone might type "Karnatka") is a constraint; a "Confirm Delete" dialog that requires typing the exact filename before deleting is a constraint aimed specifically at an irreversible, high-cost mistake.

Fitts's Law: The Mathematics of Reaching a Target

Everything so far has been about what a control communicates. Now we turn to something more precise: how long it physically takes a person to move their finger or cursor to a target and hit it, and — crucially — how a designer can calculate that time before the product even exists.

In 1954, psychologist Paul Fitts observed something that feels obvious once stated but has surprisingly exact mathematical structure: the time it takes to point at a target depends on two things — how far away the target is, and how big the target is. A far, small target takes longer to hit accurately than a close, large one. Fitts's Law puts a number on exactly how much longer, using a quantity called the Index of Difficulty (ID), measured in "bits":

ID = log2(D / W + 1)

where D is the distance from the starting point to the centre of the target, and W is the width of the target along the direction of movement. The total time to reach the target is then:

T = a + b * ID

where a and b are constants measured from real people using a real device (a touchscreen, a mouse, a trackpad) — they capture the base reaction time and the person's raw pointing speed. Before plugging in numbers, let's make sure the log2 (log base 2) part is not a mystery. log2(x) answers the question: "how many times do I have to double 1 to reach x?" Since 1 → 2 → 4 → 8 is three doublings, log2(8) = 3. Since 1 → 2 → 4 is two doublings, log2(4) = 2. For a number that isn't a clean power of 2, like 6, the answer sits between the two nearest powers — since 4 < 6 < 8, we know 2 < log2(6) < 3, and a calculator gives the exact value: log2(6) ≈ 2.585.

Now let's actually compute a movement time, using typical touchscreen constants a = 50 ms and b = 150 ms per bit (these vary by device and by person, but values in this range are commonly measured in touchscreen studies). Here is the calculation as a short program, so we can trace exactly what it does:

def fitts_time(D, W, a=50, b=150):
    import math
    ID = math.log2(D / W + 1)
    T = a + b * ID
    return T

print(round(fitts_time(100, 20), 1))
print(round(fitts_time(100, 10), 1))
print(round(fitts_time(50, 25), 1))

Tracing the first call, fitts_time(100, 20): D = 100 mm, W = 20 mm. First, D / W = 5, then 5 + 1 = 6, so ID = log2(6) ≈ 2.585 bits. Then T = 50 + 150 * 2.585 = 50 + 387.7 = 437.7 ms. So the first line prints 437.7 — a little under half a second to reach a 20 mm button 100 mm away. That is Worked Example 1: a normal-sized "Book Now" button.

Now trace the second call, fitts_time(100, 10): same distance, D = 100 mm, but the target is half as wide, W = 10 mm — think of a cramped little "×" close icon. D / W = 10, +1 = 11, ID = log2(11) ≈ 3.459 bits. T = 50 + 150 * 3.459 = 50 + 518.9 = 568.9 ms. So the second line prints 568.9. Notice the target got half as wide, but the time didn't double — it went up by about 130 ms, roughly a 30% slowdown. That's the signature of a logarithmic relationship: halving the width doesn't halve your speed, but it does reliably cost you real, measurable time, and — more importantly for real products — it reliably costs you accuracy, because more of your taps land just outside a small target and miss.

The third call, fitts_time(50, 25), is left partly to you: D = 50 mm, W = 25 mm, so D / W = 2, +1 = 3, ID = log2(3) ≈ 1.585 bits, and T = 50 + 150 * 1.585 = 50 + 237.7 = 287.7 ms. The third line prints 287.7 — noticeably faster than either earlier example, because both the distance shrank and the target grew. This is exactly why the biggest, most important button on a mobile screen — "Pay," "Book," "Confirm" — should also be the largest tappable element and placed where a thumb naturally rests, while a rarely-used, high-consequence action like "Delete Account" is often made small and placed somewhere a thumb has to stretch to reach — not by accident, but as a deliberate application of Fitts's Law to discourage accidental taps.

Colour, Contrast, and Designing for Every Eye

A design principle that is easy to skip and expensive to skip is contrast — how easily text or an icon can be distinguished from its background. The Web Content Accessibility Guidelines (WCAG), the standard most professional design teams build against, define a contrast ratio that ranges from 1:1 (two identical colours — completely invisible) to 21:1 (pure black on pure white — maximum possible contrast). For ordinary body text, WCAG's AA standard requires a ratio of at least 4.5:1. Pale grey text on a white background — the kind you see in disclaimers designers hope you won't read carefully — often measures around 2:1 or 3:1, which technically fails this standard even though a person with typical vision might still read it with effort. Both grey labels in the diagram above ("Cancel" and "thumb rests here") were deliberately chosen to clear the 4.5:1 bar, so that de-emphasising an element in this chapter's own example never means making it unreadable.

Contrast matters even more once you account for colour vision differences. Red-green colour blindness is the most common form: a widely cited estimate for populations of European descent puts it at roughly 8% of men (colour blindness is far rarer in women, because the relevant genes sit on the X chromosome). Studies of Indian male populations have commonly reported somewhat lower figures, often cited in the 4–6% range — the exact number varies by study and by which populations were sampled, and you should treat any single figure as an estimate rather than an exact constant. Still, the practical conclusion holds either way: in a class of forty boys, it is entirely plausible that two or three of your own classmates perceive red and green as similar, muddy shades rather than as clearly different colours. This is precisely why a well-designed interface never uses colour as the only signal for something important — a red border alone to mark an invalid form field, with no icon and no text, is invisible information to a meaningful fraction of users. The fix costs almost nothing: pair the red with a small warning icon and the word "Invalid," and the information reaches everyone, not just the majority.

Common Misconception, Corrected

A very common misconception — even among people who use the phrase "UI/UX" casually — is that UI/UX design is essentially about making an app or website "look pretty": choosing nice colours, a stylish font, maybe a mascot. This is wrong in an important way. Everything in this chapter — affordances, feedback, mapping, constraints, Fitts's Law, contrast ratios — is about function, not decoration. A screen can be visually stunning and still be an unusable, even harmful, piece of UX design if its delete button sits exactly where your thumb naturally rests (violating Fitts's Law in the dangerous direction), if it gives no feedback after a payment (violating the feedback principle), or if its only status signal is a colour that a meaningful fraction of users can't distinguish (violating accessible-contrast design). Conversely, a visually plain interface that gives instant feedback, uses consistent, well-mapped controls, prevents errors through constraints, and sizes its buttons correctly is genuinely well-designed, even without a single "beautiful" flourish. Good UI/UX is closer to engineering than to decorating — it is testable, measurable, and it can be wrong in ways a calculation can catch, exactly like a Fitts's Law time or a contrast ratio.

Check Yourself

1. A friend says, "This app looks amazing, so the UX must be great." Using this chapter's definitions, explain precisely what is wrong with that sentence.
2. Identify the affordance, the signifier, and the feedback in this scenario: you press a lift (elevator) button; it lights up; a few seconds later, a soft chime sounds and the doors open.
3. An IRCTC-style form lets you type any text into the "State" field, and only after you submit does it say "Invalid state name." Redesign this using the constraint principle. What UI element would you use instead, and why does it prevent the error rather than just report it?
4. Using T = a + b · log2(D/W + 1) with a = 50 ms and b = 150 ms/bit, calculate the movement time to a button that is D = 200 mm away and W = 40 mm wide. Show the value of D/W, then D/W + 1, then log2 of that, then the final T.
5. Two form fields both use red to mark an error, but one also shows a warning icon and the text "Required field," while the other shows only a red outline. Which one follows accessible design, and which specific population does the red-only version fail?

Answers to check against: (1) A great-looking UI is only one input to UX; the sentence conflates UI with UX and ignores feedback, mapping, constraints, and accessibility — all of which are invisible in a screenshot. (2) Affordance: the button's raised, pressable shape. Signifier: the button lighting up on press. Feedback: the chime plus doors opening, confirming the lift arrived. (3) A dropdown list (or autocomplete) of the 28 states and 8 union territories — it makes typing an invalid name physically impossible rather than merely detecting it afterward. (4) D/W = 200/40 = 5; 5 + 1 = 6; log2(6) ≈ 2.585; T = 50 + 150 × 2.585 = 50 + 387.7 = 437.7 ms. (5) The icon-plus-text version follows accessible design; the red-only version fails users with red-green colour blindness (and anyone using a black-and-white or low-brightness screen in bright sunlight).

Summary

UI is the interface itself — the buttons, screens, and controls a person sees and touches. UX is the entire experience of using that interface to reach a goal, including whether the person understood what to do, could do it quickly, avoided mistakes, and trusted the result. Norman's affordances and signifiers explain how an object communicates what can be done to it, largely through visual cues on a flat screen. Feedback means every action produces a visible, timely response, so users never have to guess whether something worked. Mapping and consistency mean controls should match a user's existing mental model and behave the same way everywhere within a product. Constraints prevent mistakes by making invalid actions impossible, rather than merely flagging them after the fact. Fitts's Law, T = a + b · log2(D/W + 1), gives an exact, calculable prediction of how long it takes to reach a target based on its distance and size — which is why critical buttons are made large and placed within easy reach, while dangerous, rarely-used actions are made deliberately small and distant. And contrast, governed by the WCAG 4.5:1 standard, together with never relying on colour alone, ensures the design works for the meaningful fraction of users whose colour vision differs from the majority's. None of this is about taste. Every principle in this chapter can be checked, measured, or calculated — which is exactly what separates professional UI/UX design from just picking colours that look nice.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where ui/ux principles: designing for humans is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting ui/ux principles: designing for humans to at least 3 other topics you have studied.