11 Bad UX

App Prototyping Studio

Mick McQuaid

University of Texas at Austin

03 Nov 2026

Week ELEVEN

Popularization via bad design

Norman (2013) popularized the identification of bad design in its first edition in the eighties.

Don Norman is the single person who has done the most to popularize HCI in the public consciousness. He is a brilliant thinker and I don’t mean to criticize him for this, but one thing he did that brought him amazing popularity yet did little to educate people was to popularize the discussion of poor design. His most popular book is fraught with examples of bad design and it is inevitable that any teacher of HCI can boost course evals by allowing students to waste a lot of time critiquing bad design. The problem with this is that it is so hard to get design right that noticing that much of it is poor is, by itself, a minute step.

Most bad design examples remind us of the importance of signifiers and the danger of cognitive dissonance.

that aspect of a thing you can interact with that suggests how to interact with it

can be done well or poorly

central concept for individual user

often skeuomorphic

flat design opposes notion of need for signifiers

Why spend two days on it anyway?

Noticing bad design is cheap. Everyone in this room can do it already.

Diagnosing it precisely is a skill. Most people can’t.

Fixing it at a cost someone will pay is the job. Almost nobody does this without practice.

Your assignment is graded on the last two, not the first. This week is practice.

And your beta reports just came in. Some of the bad UX we look at this week is yours.

Vocabulary

Affordance. A relationship between a thing and a person: what the thing lets that person do. A handle affords grasping. A flat plate affords pushing.

Signifier. Any perceivable cue that tells you where to act and how. The word “Push.” The shape of the plate. Norman added this word in 2013 because people kept using “affordance” to mean it.

Mapping. The relationship between controls and their effects. Four burners, four knobs, which is which?

More vocabulary

Feedback. Something that tells you the action happened. The click, the light, the spinner.

Conceptual model. The story in your head about how the thing works. Usually simplified, often wrong, built from the signifiers you can see.

Constraints. Physical, cultural, semantic, and logical limits on what you can do. The USB-A plug that only fits one way after three tries.

The two gulfs

Gulf of execution. I know what I want. How do I do it with this thing?

Gulf of evaluation. I did something. What happened? Did it work?

Every example you photographed sits on one side or the other.

Pictures are good at showing the gulf of execution. The confused hand on the handle is a photograph.

Pictures are bad at showing the gulf of evaluation. “Nothing happened” doesn’t photograph.

Keep this in mind on Thursday. Your prototype’s worst failures are probably the ones you can’t photograph.

When the sign goes up, the design has failed

Norman: when simple things need pictures, labels, or instructions, the design has failed.

Every taped-on sign is a confession. Someone watched users fail and reached for a label instead of a redesign.

The sign is also evidence. It tells you exactly where the gulf is, because somebody had to stand there and watch.

Apps have stickers too: tooltips, coach marks, onboarding tours, “tap here to get started,” a help icon next to a field.

Not every sticker is wrong. But every sticker is a place you should have considered a redesign first.

Human error is design error

When people fail with a thing, they blame themselves. “I’m so stupid, I pushed the pull door.”

Norman’s chapter five argues that this is backwards. The design put a competent person in a position to fail.

Reason (1990) made the same argument about industrial accidents. The operator is the last link, not the cause.

Design consequence: when a tester fails your prototype, the finding is about your prototype.

You already know this from your beta reports. Reread your findings with this in mind: how many times did you write “the participant didn’t notice”?

Why competent people ship bad design

Cost. The push plate costs more than the handle that comes in the box.

Aesthetics. The architect wanted the same hardware on every door. Flat design wanted no borders.

Regulation. Fire code says this door opens outward, and the sign says what the code requires, not what the user needs.

Legacy. The elevator panel was retrofitted. The app has to match the website that shipped in 2014.

The buyer is not the user. The hospital administrator chose the software. The nurse uses it.

Nobody watched. Nobody tested it with a person who hadn’t built it.

Someone profits. The failure is the point. More on this in a minute.

Worked examples

The diagnosis template

Expected. What did the design lead the user to expect?

Actual. What actually happened?

Property. Which property of the design produced the gap? Name it with a word from the vocabulary slide (or the more vocabulary slide).

Fix. Redesign, not complaint. Show it.

Cost. What does the fix cost? Manufacturing, screen space, a tap, retraining, revenue.

Every example that follows gets run through this template. So does yours.

Exercise 1: Cold read

Rules

Seven pictures follow. No titles, no explanation, forty-five seconds each.

For each one, write three lines: expected, actual, property. Use a word from the vocabulary slide for the property.

If you can’t find the problem in forty-five seconds, write “can’t see it.” That is a finding about the picture, not about you.

Pair up. After the seventh picture, compare answers with your partner. Where you disagree about the property, argue until one of you changes.

Then I show the same pictures again with my diagnosis. Score yourself: same property or different?

1

2

3

4

5

6

7 Compare

With your partner: same property on how many of seven?

Which picture produced the most disagreement in the room? That’s the one worth talking about.

Which picture did the most people mark “can’t see it”? That picture fails the assignment, even though the design it shows is bad.

Now the reveal.

Worked examples

Flat design risks

Bad door

Bad and less bad door

Anti-ADA door

Bad dryer

The dryer is on the left, the washer on the right. The dryer door is hinged on the right, the side next to the washer. Open it and it swings into the gap between the two machines, exactly where your arms need to be when you move wet clothes across.

Expected: pull the clothes out of the washer and swing them into the dryer in one motion. Actual: the open door blocks the path, so you lift the load over the door or walk around it. Property: a constraint failure. The hookups in the room dictate which machine goes where, and the door is built so cheaply that the hinge can’t be moved to the other side. Neither the buyer nor the installer could fix it.

Fix: a reversible hinge, which many manufacturers do offer, or a door that drops down from the top so that the open door becomes a shelf for the wet load. Cost: a second set of hinge mounts and a latch that works on either side, or a heavier door assembly and the hardware to hold it level. Both cost more than the single fixed hinge, and the person who buys the machine rarely knows which side the hookups will be on until it’s in the room.

This is also a good example for Part 4. The steelman writes itself: the manufacturer doesn’t know the room, and the cheapest door is the one that sells.

Bad iPad

A 2010 iPad task manager, Taska, in the skeuomorphic style of the time. Ask the room to find the problem before you name it. Most will point at the wood grain. That isn’t it.

The real structure of the app is a cascade: pick a list on the left, see its items in the center, open one item’s details on the right. Three panels, left to right. Now look at what the panels signify. The left panel’s selected row is highlighted and leads your eye into the center. The right panel is a popover with a tail that points left, back at the center. Both side panels say “the action is in the middle.” Nothing says “read this left to right.” A new user has no idea that the right panel is downstream of the center, or that the left panel is upstream of it.

Expected: a visual hierarchy that tells you where you are in the cascade. Actual: two panels pointing inward at a third. Property: a mapping failure between the layout and the flow it represents. The pointers point the wrong way. Fix: make the hierarchy read left to right, with the detail panel visibly attached to the item it belongs to rather than floating over the list. The app was later redesigned along those lines. Cost: giving up the popover, which was the platform’s standard component at the time, and finding room for three persistent panels on a screen that was tight for it.

Bad iPad’s ancestor

A pair of restroom doors in a bar. Painted hands point across the doorframe. The hand labeled WOMEN is painted on the left door and points right. So which door is the women’s room? The one the hand is on, or the one it points to? A pointer is a signifier of direction, and these point at each other, so each door’s sign sends you to the other door.

This is the same failure as the iPad, which is why the two slides are paired. On the iPad, both side panels point at the center. On the doors, both signs point at the opposite door. In both cases, the pointers are present and legible and point the wrong way, and the result is worse than no pointer at all, because a wrong pointer is trusted.

Also worth saying: this one is fun, and that is a trap. The fix for the restroom doors is boring: a symbol on each door, no hands. Students should notice that the best fix is often the least interesting one.

Bad elevators

Why are these elevator buttons bad? There could be a variety of problems. You might be excused for thinking the bottom button means down in the picture on the right. You might be mystified about the meaning of the button on the left. The problems are compounded if you’re blind. There is no braille and no shape indicator (of course, Braille itself is a problem in that only ten percent of blind individuals read it).

Run the template on the right-hand panel. Expected: a labeled button per floor. Actual: three unlabeled buttons, one lit, and a label on only one of them. Property: a missing mapping between control and effect. Only “ROOF” has a mapping, and the lit button means either “you are here” or “you pressed this,” and nothing tells you which; that’s a feedback ambiguity on top of a mapping failure.

The left panel: one red button under a lot of fire iconography and no label. Is it an alarm? A call button? Does pressing it summon the fire department? Nobody will press it to find out, which means that if it matters, it fails.

Hotel showers

One well-traveled pundit claims that this is what he sees whenever he looks at a hotel shower! I tend to agree and I have to admit I waste a lot of water in hotels trying to figure out how to get the right temperature!

The picture is a metaphor, and it is worth unpacking what it says. A shower control is something you have to figure out fast, because the penalty for getting it wrong is scalding or freezing water, and the hotel’s control gives you no signifier for how. Nothing on the handle says which way is hot, whether turning or pulling changes the flow, or what the second ring does. You are solving a puzzle under time pressure with your skin as the feedback channel.

The cherry on top is the Rubik’s cube itself. Everyone knows that a few people can solve one in seconds, and that most of us never will. That is the expert-versus-novice gap built into the metaphor. The control is fine for the person who has used that exact model before, and hopeless for the guest meeting it for the first time, which in a hotel is everyone.

Also a good example of the cost of a fix: the thermostatic valve with a marked temperature scale exists and costs more, and the hotel’s buyer is not the hotel’s guest.

The same failures on a screen

Translate the doors into your prototype

Norman door. A card that looks tappable and isn’t. Text that looks like a link and isn’t. A button that looks disabled and isn’t.

Dryer door. The dialog that opens on top of the information you need to fill it in. The keyboard that covers the field you’re typing into. The layout was set before anyone knew what would be next to it.

Unlabeled elevator. An icon-only toolbar. Five icons, no words, and one of them deletes.

Rubik’s shower. Anything you must operate fast, under penalty, with no signifier for how. The alarm you can’t silence at 5 a.m. The car’s touchscreen climate control at highway speed. The payment terminal with a line behind you. Experts fly through it; everyone else gets burned.

Mystery red button. A destructive action with no label and no undo.

Taped-on sign. An onboarding tour that explains the navigation.

Failures that don’t photograph

Feedback. You tapped “order” and nothing happened, so you tapped again. Two orders.

State. Is it saved? Is it syncing? Which account am I in?

Mode. Caps lock. Edit mode. The same tap does something different and nothing tells you which mode you’re in.

Time. The spinner that never ends. The confirmation that arrives after you gave up.

Absence. The cancel path that was never designed because nobody drew the unhappy path.

These are most of what real usability failures look like, and almost none of your photos show them. That’s a limitation of the assignment, not of the failures.

Deliberate bad UX

Some bad UX is not a mistake. It is a product decision that benefits the business at the user’s expense.

Brignull (2023) coined the term dark patterns in 2010 and now prefers deceptive patterns. Same thing.

Gray et al. (2018) sorted them into five families: nagging, obstruction, sneaking, interface interference, and forced action.

Mathur et al. (2019) crawled about eleven thousand shopping sites and found deceptive patterns on roughly one in nine, with countdown timers that reset and “low stock” messages that were made up.

The FTC and the EU have both moved against the worst of these. Some of what you’ll find on your phone this week is now illegal in Europe.

The reason to include this is that the diagnosis template still works. Expected, actual, property. What changes is the fix: the property that produced the gap was chosen on purpose, so the cost of the fix is revenue, and the person who has to pay it is the business, not the user. This is why the assignment insists on naming the cost. A fix that doesn’t name who pays is not yet a design.

Examples to have ready: the subscription you can cancel only by phone (obstruction); the pre-checked newsletter box (sneaking); the “No thanks, I don’t want to save money” decline button (interface interference, specifically confirmshaming); the cookie banner where “accept all” is one tap and “reject” is five (interface interference); the account you cannot delete without a support ticket (forced action, obstruction).

Accidental dark patterns

You will not set out to deceive anyone. You might do it anyway.

Notifications default to on because you never designed the default.

The checkbox is pre-checked because the component came that way.

There is no cancel path because nobody drew the screen for “I changed my mind.”

The “skip” link is gray on gray because the designer wanted the primary button to pop.

Intent doesn’t matter to the user. The pattern does. Thursday’s audit covers this.

Why your good examples are harder

You have been bringing two examples of good design each week along with your sketches.

Most of you have found that harder than finding one bad example. That is not an accident.

Good design is invisible by construction. The push plate that works is never photographed, because nobody stopped to look at it.

The skill you are building is seeing what is working and saying why, in the same vocabulary.

Try it with your bad example: what, nearby, is working? Why?

Three ways a find goes wrong

Taste, misplaced blame, triviality, and the missing find

Taste. You don’t like it. Nobody can name a user, a task, and a gap. You have a preference, not a diagnosis.

Misplaced blame. The gap is real, but the property that produced it belongs to someone other than the designer you’re blaming. Your fix lands in the wrong place.

Triviality. The gap is real and the blame is right, but the fix is “add a sign,” everyone already knew, and nothing was learned.

The missing find. You show the fix and skip the problem. The reader has to reverse-engineer your diagnosis from your redesign.

The submissions so far include all of these. Let’s look at them. No names.

Craigslist and Yahoo

Two people submitted Craigslist. One submitted Yahoo’s home page, proposing less information and more visual hierarchy.

Both sites have looked roughly the same for decades. Both still have users who prefer them that way.

Recall Reinecke and Gajos (2014) from two weeks ago: preference for visual complexity varies by country, age, and education. Dense is not bad. Dense is a choice with an audience.

Craigslist loads instantly, works on any device, has no ads in the way, no infinite scroll, no deceptive patterns. Many “modern” sites can’t say that.

So: is there a gap? Name the user. Name the task. Say what they expected and what happened instead. If you can, you have a diagnosis. If you can’t, you have taste.

Workday

One person submitted the University’s Workday job site. Step one is labeled “Autofill with Resume.” Step three is a page of empty required fields for the jobs that were on the resume.

The diagnosis in the report is good. The label is a signifier that sets an expectation. The conceptual model it builds is “my resume fills the form.” The green checkmark is feedback that says done without saying what was done.

The fix: drop the duplicate fields and show the uploaded file instead. The report names the cost, which is that recruiters lose structured fields to filter on. That is the assignment done right.

Workday, continued

Now the steelman. Workday sells resume parsing and it works on resumes like yours, which all have the same layout. Someone configured this flow with the fields still required.

That someone is almost certainly the University, which set up this instance to connect students to campus employers. The applicant sees Workday’s logo and blames Workday.

The buyer is not the user. The fix lands on a configuration screen in an office that never sees an applicant retype their job title.

This is the best of the five, and the report is closer to a model answer than the slide can show without naming the student. Three things to pull out of it: the diagnosis uses three vocabulary words correctly and distinguishes them; it says explicitly that the problem is not discoverability but understanding what the system did; and the fix names its cost and proposes a test.

What the report could add is the steelman, which is where the misplaced-blame point lives. Workday’s own parser is reasonably good against a conventional one-page student resume, so the empty fields are most plausibly a configuration choice: either parsing was never enabled for this flow or the fields were left required regardless of what parsing filled in. Either way the fix is cheap and sits with the University’s Workday administrators, not with Workday the company and not with any individual campus employer. The applicant can’t see that from outside, and saying so would strengthen the report.

The five whys lesson is here in a live example: the retyped job title is the symptom. Why was it empty? Why was the field still required? Who decided? Who tested the flow as a student? Nobody, probably.

A fix without a find

One person submitted only the redesign: a sketch of a sidewalk trash can with four annotations. A 45-degree sloped lid against snow and water. A larger central throat. A steel mesh body for visibility. A concrete-mounted base.

There is no picture of the original. So read the fix backwards. Each annotation is a diagnosis in disguise.

Sloped lid: water pooled on the flat top. Larger throat: trash didn’t fit, so it piled up around the opening. Mesh body: people didn’t see the can and littered next to it. Concrete base: it tipped or walked away.

Four problems recovered from four fixes. That is a good sign about the fix.

It is still a failed submission as it stands, because the reader should never have to do this. The picture of the problem is what lets a stranger check whether your fix addresses it.

Use this as a two-minute exercise before you explain it: put the four annotations on the screen, hide the bullets, and ask the room to name the problem behind each one. They will get all four, which makes the point that a well-annotated fix encodes its diagnosis.

Then make the other point. The assignment asks for the picture of the problem first for a reason: without it, nobody can tell whether the fix is aimed at a real gap or an imagined one. Was the original can actually tipping? Was the throat actually too small? We have to take the designer’s word for it, and the whole point of the method is that we shouldn’t have to.

If the student is in the room and wants to describe the original can, that fills the gap and the sketch becomes a complete example on the spot. Don’t call on them.

The sketch itself is in the submissions folder as the baduxb.png for that student. Showing it from the folder is better than embedding student work in a slide deck that gets published.

Exercises, Tuesday

Diagnose, steelman, fix

Setup

There is a shared FigJam board with a parking area and six labeled regions: Signifier, Mapping, Feedback, Conceptual model, Constraint, Deliberate.

It is empty. You are going to fill it in the next half hour.

Work in pairs for Part 1 and in your project teams afterward.

Bring up the diagnosis template. You will fill it in several times.

Part 1: Preference or diagnosis?

In pairs. One of you takes Craigslist, the other takes the Yahoo home page. Open the site on your phone.

Write the strongest diagnosis you can: a named user, a named task, expected, actual, property. Three minutes.

Then switch sides. Write the strongest case that the site is a deliberate design serving an audience you aren’t part of. Who is that audience, and what would your fix cost them?

Read both to your partner. Decide together: diagnosis or taste?

Hands up when we regroup: how many of you ended up with a diagnosis that survived the second half?

Part 2: Live hunt

Fifteen minutes. Leave the room if you need to.

Find one instance of bad UX in the building or on your phone. Doors, the elevator, the restroom, the AV panel in this room, the vending machine, any app you used today.

Photograph it so a stranger can see the problem without you there. Screen record if the failure is one that a still image can’t show.

Post it to the parking area of the board with a sticky: expected, actual, property. No name.

If you haven’t submitted baduxa.png yet, this is your chance to find your example. Pick carefully. The report that follows is most of the grade.

Part 3: Sort the wall

Each person drags their own picture from the parking area into the region for its dominant failure.

If you can’t choose between two regions, put it on the border. That is information.

Look at the result. Which region is fullest? Which is empty?

The signifier region is always the fullest. Why? Because signifier failures photograph well and feedback failures don’t.

Your prototype has the opposite distribution. Hold that thought until Thursday.

Part 4: Steelman the designer

In your team, pick one picture from the wall that belongs to nobody on the team, or take Workday.

Write the most charitable explanation you can of why a competent person shipped this. Use the list: cost, aesthetics, regulation, legacy, buyer versus user, nobody watched, someone profits.

Now design a fix that survives that constraint. If the constraint was cost, your fix can’t cost more. If it was regulation, your fix has to pass inspection.

Sketch it. One drawing, in the FigJam, next to the picture.

Name the cost of your fix. Who pays? What do they give up?

Part 5: Five whys

Take your team’s chosen picture and ask why, five times.

Why did the user push? Because the handle looked like a push bar. Why was there a push bar? Because the architect specified matching hardware. Why matching? Because the catalog sells one handle for both sides. Why did nobody notice? Because nobody opened the door from the other side until after installation. Why not? Because nobody tested.

Stop when the answer is about a process rather than a part.

Your fix can land anywhere in the chain. The deepest fix is usually the cheapest per door and the hardest to get approved.

Part 6: Draft your diagnosis

Now write the diagnosis paragraph for your own example, the one you will submit. If you found it in the hunt, use that.

Expected, actual, property, fix, cost. Five sentences is enough for a first draft.

Swap with your partner from Part 1. Read theirs against four questions: Does it say what the user expected? Does it say what happened? Does it name a property using a word from today’s vocabulary? Does the fix name who pays?

Mark each question yes or no. Hand it back.

Revise before you leave. The report is more of your grade than the picture.

Exercises, Thursday

Turn the lens on your own prototype

Setup

Open your team’s current hifi prototype in Figma. It should include whatever you changed after the beta test.

Have your beta report findings open in another window.

Pair your team with another team. You will swap prototypes twice today.

Same template as Tuesday. Expected, actual, property, fix, cost.

Part 1: Bad UX hunt in a stranger’s prototype

Swap prototypes with your paired team. Don’t explain anything. The other team gets the link and nothing else.

Each person finds one failure from the Tuesday vocabulary and writes it up with the template. Screenshot it, or screen record it if the failure is a feedback or time failure that a still image can’t show.

Also look for one accidental dark pattern: a default, a pre-check, a missing cancel path, a gray-on-gray decline, a nag.

Deliver your findings to the owning team as a list, not a conversation. They read, they don’t argue.

Owning team: compare the list to your beta report. Anything here that your testers also hit and you didn’t fix?

Part 2: The sticker inventory

Back in your own prototype, list every place you explain the interface to the user: tooltips, coach marks, an onboarding tour, placeholder text that gives instructions, a help icon, “tap here,” “swipe to see more.”

Each one is a sticker. For each, decide: redesign so the sticker is unnecessary, or keep the sticker and say why.

Legitimate reasons to keep one: the concept is new to the user and no signifier can carry it; the regulation requires the text; the alternative costs more than the sticker.

“We ran out of time” is also a legitimate reason. Write it down anyway.

Pick one sticker to remove by redesign. Do it now.

Part 3: Make it worse

Duplicate one of your core screens in Figma.

Make exactly three deliberate changes that make it worse while keeping it plausible. Remove a signifier. Break a mapping. Drop a piece of feedback. Hide the primary action. Make a decline button look like a label.

Swap the broken screen with your paired team, without telling them what you changed.

They have five minutes to find the three changes.

If they found something you didn’t change, that failure was already in your design. If they couldn’t find one of your changes, the thing you removed wasn’t doing any work.

Part 4: Deceptive pattern audit

On your own phone, in any app you pay for, find the path to cancel. Count the taps. Count the taps to subscribe. Write both numbers down.

Classify what you found using Gray’s five families: nagging, obstruction, sneaking, interface interference, forced action.

Now open your own prototype and check: notification defaults, pre-checked boxes, the cancel path, the wording and styling of every decline button, any countdown or scarcity message, how account deletion works.

Fix one thing. If your prototype has no cancel path at all, that’s the one.

Part 5: What changed today

Each team: one slide, one minute. What did you change in the prototype today, and what finding drove it?

Format: expected, actual, property, fix, cost. The same five lines, applied to your own work.

This is a rehearsal. Your final presentation asks you to name at least one thing you got wrong and fixed. Today you got at least one.

Put the before and after screenshots somewhere your developers will see them. They need to know the change happened.

Optional: The sticker walk

If the weather and the schedule allow, take fifteen minutes and walk the building with a phone.

Photograph every taped-on sign, every handwritten label, every “please do not” near a control.

Each one is a confession. Each one tells you where a user failed and a staff member watched.

Back in the room, pick the three best and run the template. What would the no-sticker fix be, and who would have to pay for it?

This is also a pipeline for next year’s assignment, so send me the good ones.

Literature

Norman (2013) is the assigned reading. Chapter one is the vocabulary; chapter two has the gulfs and the seven stages of action; chapter five is human error; chapter four is constraints.

Reason (1990) is the human error book Norman draws on. The argument that the operator is the last link, not the cause, comes from here.

Brignull (2023) is the book by the person who coined “dark patterns.” Readable, with a large catalog of examples.

Gray et al. (2018) is the paper that gave us the five families of deceptive patterns used in Thursday’s audit.

Mathur et al. (2019) is the crawl of eleven thousand shopping sites. Read it for the method as much as the findings.

More literature

Krug (2005) is the short book on web usability whose title is the whole argument. Every sticker in your prototype makes the user think.

Johnson (2020) explains, from cognitive psychology, why the failures on the wall today happen to competent people.

Lidwell et al. (2010) is a reference of design principles, one per spread, including affordance, mapping, constraint, and feedback, with examples.

Nielsen (1994) is the heuristics paper from week eight. Norman’s vocabulary describes the thing; Nielsen’s list checks it. Use both.

END

References

Brignull, Harry. 2023. Deceptive Patterns: Exposing the Tricks Tech Companies Use to Control You. Testimonium Ltd.

Gray, Colin M., Yubo Kou, Bryan Battles, Joseph Hoggatt, and Austin L. Toombs. 2018. “The Dark (Patterns) Side of UX Design.” Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems (Montreal), CHI ’18, 1–14. https://doi.org/10.1145/3173574.3174108.

Johnson, Jeff. 2020. Designing with the Mind in Mind, 3rd Edition. Morgan Kaufman.

Krug, Steve. 2005. Don’t Make Me Think: A Common Sense Approach to the Web (2nd Edition). New Riders Publishing.

Lidwell, William, Kritina Holden, and Jill Butler. 2010. Universal Principles of Design: A Cross-Disciplinary Reference. Rockport.

Mathur, Arunesh, Gunes Acar, Michael J. Friedman, et al. 2019. “Dark Patterns at Scale: Findings from a Crawl of 11K Shopping Websites.” Proceedings of the ACM on Human-Computer Interaction 3 (CSCW): 81:1–32. https://doi.org/10.1145/3359183.

Nielsen, Jakob. 1994. “Enhancing the Explanatory Power of Usability Heuristics.” Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI’94) (New York, NY, USA), 152–58.

Norman, Donald A. 2013. The Design of Everyday Things, 2nd Edition. Basic Books.

Reason, James. 1990. Human Error. Cambridge University Press.

Reinecke, Katharina, and Krzysztof Z. Gajos. 2014. “Quantifying Visual Preferences Around the World.” Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (New York), CHI ’14, 11–20. https://doi.org/10.1145/2556288.2557052.

Colophon

This slideshow was produced using quarto

Fonts are Fira Sans, Fira Sans Light, and Victor Mono Nerd Font

Math is set in Fira Math via MathJax 4