# softwarebehavior.com · full text --- title: "How fast do you judge a homepage?" code: JZ-002 series: Perception published: 2026-10 updated: 2026-11-01 author: Joost van der Zwan canonical: https://softwarebehavior.com/notes/jz-002 skill: studio-jz-first-glance license: CC BY 4.0 --- # How fast do you judge a homepage? Field Note JZ-002 · Perception · First impressions **50 ms** enough to judge appeal ## The guess 5 seconds sounds fair: time to scan, read and decide. ## What the research found People judge how visually appealing a homepage is in 50 ms, shorter than a blink. Ratings after 50 ms matched ratings after 500 ms closely (r = 0.95), and pages kept their score when people saw them a second time. ## Why The gut votes first. Before anyone reads a word, layout and color have already set an impression, and later looks tend to confirm it. ## What to do - Get layout, color and visual hierarchy right before polishing copy. They are judged first. - Keep the first screen calm and clearly structured; one clear focal point beats many competing ones. - Test the first impression directly: show the screen for a fraction of a second and ask how appealing it feels, then compare versions. ## What not to do - Count on content to rescue a weak first look. People decide before they read a word. - Treat a good first impression as proof the page is easy to use. Appeal and usability are different questions. ## Limits - The study measured visual appeal, not usability or conversion. - People agreed with each other less at 50 ms than at 500 ms, so a 50 ms rating is a strong but rough signal. - Tested with homepages on desktop screens in a lab. ## Example - Before: A homepage with a dense hero: five headlines, three buttons, a carousel and a busy photo. - After: One headline, one supporting line, one primary action and plenty of space; tested as a quick flash against the old version. ## Sources - Lindgaard, G., Fernandes, G., Dudek, C. & Brown, J. (2006). Attention web designers: You have 50 milliseconds to make a good first impression! Behaviour & Information Technology, 25(2), 115–126. https://doi.org/10.1080/01449290500330448 ## Use with your AI This note is also a skill: `studio-jz-first-glance` (version 1.0.0). Download: https://softwarebehavior.com/skills/studio-jz-first-glance.zip · All skills: https://softwarebehavior.com/field-kit Software Behavior Field Notes by Joost van der Zwan · Studio JZ · CC BY 4.0 · softwarebehavior.com --- --- title: "Which is read faster, short lines or long lines?" code: JZ-003 series: Perception published: 2026-10 updated: 2026-11-01 author: Joost van der Zwan canonical: https://softwarebehavior.com/notes/jz-003 skill: studio-jz-line-length license: CC BY 4.0 --- # Which is read faster, short lines or long lines? Field Note JZ-003 · Perception · Line length **100** characters per line read fastest ## The guess Short lines look easier: calm and readable. ## What the research found Reading from screen, text set at 100 characters per line was read faster than text at 25. But people rated about 55 characters per line as easiest to read, and a later study found 55 was understood better than 100. Speed, understanding and preference point in different directions. ## Why Every new line is a jump back to the left edge, so long lines mean fewer jumps and less scrolling. Faster is not the same as clearer. ## What to do - Decide what the text is for. For skimming and scanning, a wider measure is fine; for study and understanding, aim for about 55 characters per line. - Set the measure in characters (for example max-width in ch units), not in pixels, so it holds across type sizes. - Test with your own content, typeface and devices. ## What not to do - Pick a line length by feel alone. What feels easiest is not what is read fastest or understood best. - Present one line length as best for every purpose. ## Limits - These studies used one typeface and size on desktop screens; mobile was not tested. - Speed, understanding and preference were measured separately and can conflict. - Status: the comprehension finding for 55 characters is being checked in the full paper; this skill ships when it is confirmed. ## Example - Before: A help article spread across a full-width 1400 px column, about 160 characters per line. - After: Body text capped at about 60ch for the article, with a wider layout kept for tables and code. ## Sources - Dyson, M. C. & Kipping, G. J. (1998). The effects of line length and method of movement on patterns of reading from screen. Visible Language, 32, 150–181. - Dyson, M. C. & Haselgrove, M. (2001). The influence of reading speed and line length on the effectiveness of reading from screen. International Journal of Human-Computer Studies, 54, 585–612. - Dyson, M. C. (2004). How physical text layout affects reading from screen. Behaviour & Information Technology, 23(6), 377–393. ## Use with your AI This note is also a skill: `studio-jz-line-length` (version 1.0.0, in review). All skills: https://softwarebehavior.com/field-kit Software Behavior Field Notes by Joost van der Zwan · Studio JZ · CC BY 4.0 · softwarebehavior.com --- --- title: "What makes a screen look easy to use?" code: JZ-004 series: Perception published: 2026-10 updated: 2026-11-01 author: Joost van der Zwan canonical: https://softwarebehavior.com/notes/jz-004 skill: studio-jz-looks-or-rules license: CC BY 4.0 --- # What makes a screen look easy to use? Field Note JZ-004 · Perception · Pretty feels easier **252** people rated 26 ATM layouts ## The guess Usability rules win: grouping, order, safe spacing. ## What the research found 252 people rated 26 ATM screen layouts that all used exactly the same keys. How easy a layout looked went together with how beautiful it looked (r = 0.59), and barely with most of the usability rules designers rely on. The one exception was a familiar, phone-style keypad. ## Why Before use, looks are all people have. Beauty and familiarity stand in for ease until people actually try the screen. ## What to do - Polish what people see first. A calm, well-composed layout earns the first try. - Use patterns people already know (a phone-style keypad, standard form layouts): familiarity makes a screen look easier. - Then test real use. Looking easy and being easy are separate questions. ## What not to do - Mistake looking easy for being easy. A polished screen still needs a usability test. - Swap a familiar pattern for a novel one just because it looks fresher. ## Limits - People rated the layouts without using them, so this is about how easy a screen looks, not how well it works. - ATM layouts in Japan; a later study in Israel found the same pattern. ## Example - Before: A plain but functional payment form, rated hard to use by stakeholders at first sight. - After: The same fields and order, with consistent alignment, spacing and a familiar card-number layout; then a five-person usability test to check real ease. ## Sources - Kurosu, M. & Kashimura, K. (1995). Apparent usability vs. inherent usability: experimental analysis on the determinants of the apparent usability. CHI ’95 Conference Companion, 292–293. https://doi.org/10.1145/223355.223680 - Tractinsky, N. (1997). Aesthetics and apparent usability: empirically assessing cultural and methodological issues. Proceedings of CHI ’97, 115–122. ## Use with your AI This note is also a skill: `studio-jz-looks-or-rules` (version 1.0.0). Download: https://softwarebehavior.com/skills/studio-jz-looks-or-rules.zip · All skills: https://softwarebehavior.com/field-kit Software Behavior Field Notes by Joost van der Zwan · Studio JZ · CC BY 4.0 · softwarebehavior.com --- --- title: "Should your app show its work?" code: JZ-005 series: Perception published: 2026-11 updated: 2026-11-01 author: Joost van der Zwan canonical: https://softwarebehavior.com/notes/jz-005 skill: studio-jz-show-the-work license: CC BY 4.0 --- # Should your app show its work? Field Note JZ-005 · Perception · Show the work **5** experiments with the same finding ## The guess Faster always wins: every second of waiting feels like a cost. ## What the research found In five experiments with simulated travel and dating sites, people often preferred a site that showed its work as it happened over one that returned identical results instantly, even when they had to wait longer. Seeing the effort raised how much they valued the service. ## Why Seen effort invites reciprocity: people felt they owed the service something back. ## What to do - Replace a generic spinner with the steps the system really takes, in plain words: "Checking 14 airlines", "Comparing fares", "Sorting by price". - Show each step as it happens and mark finished steps. - Keep the steps truthful and in the order they really run. ## What not to do - Invent steps or show progress that does not match real work. - Slow down a result that is already fast so it looks busier. - Keep animating once the result is ready. ## Limits - Simulated travel and dating sites; the studies measured preference and perceived value, not task success. - The paper also tests where the effect stops. It is never a reason to make anything slower. ## Example - Before: A spinner with "Searching…". - After: "Checking 14 airlines ✓ · Comparing fares ✓ · Sorting by price…" (illustrative wording). ## Sources - Buell, R. W. & Norton, M. I. (2011). The Labor Illusion: How Operational Transparency Increases Perceived Value. Management Science, 57(9), 1564–1579. https://doi.org/10.1287/mnsc.1110.1376 ## Use with your AI This note is also a skill: `studio-jz-show-the-work` (version 1.0.0). Download: https://softwarebehavior.com/skills/studio-jz-show-the-work.zip · All skills: https://softwarebehavior.com/field-kit Software Behavior Field Notes by Joost van der Zwan · Studio JZ · CC BY 4.0 · softwarebehavior.com --- --- title: "Can your AI survive one mistake?" code: JZ-006 series: Behavior published: 2026-11 updated: 2026-11-01 author: Joost van der Zwan canonical: https://softwarebehavior.com/notes/jz-006 skill: studio-jz-algorithm-miss license: CC BY 4.0 --- # Can your AI survive one mistake? Field Note JZ-006 · Behavior · One mistake **15–29%** more error, trusting themselves ## The guess Better tools get forgiven: a model that is right more often keeps its users. ## What the research found In forecasting tests with a bonus for accuracy, people who watched a statistical model make mistakes chose their own judgment instead, though the model was better: their own forecasts had 15–29% more error. A follow-up study found the way back: when people could adjust the model's forecast, even slightly, they were far more willing to use it. ## Why The same mistake cost a model more trust than it cost a person. A small say in the result was enough to bring people back. ## What to do - Let people adjust what the system gives them: edit a suggestion, nudge a forecast, re-rank results. Even a small degree of control helps. - Design the moment the system is wrong before it happens: acknowledge it, make correction easy, keep the person in charge. - Set honest expectations about accuracy up front. ## What not to do - Make the output take-it-or-leave-it. - Promise a model that never errs. One visible mistake costs more than a modest claim. ## Limits - Lab forecasting tasks with a bonus at stake, not everyday products. - The studies measured whether people chose the model, not how they used it over months. ## Example - Before: A sales forecast shown as one fixed number; after one bad month the team stops opening it. - After: The forecast with a small adjustment control (for example ±10%) and a note on how often it has been within range (illustrative). ## Sources - Dietvorst, B. J., Simmons, J. P. & Massey, C. (2015). Algorithm aversion: People erroneously avoid algorithms after seeing them err. Journal of Experimental Psychology: General, 144(1), 114–126. https://doi.org/10.1037/xge0000033 - Dietvorst, B. J., Simmons, J. P. & Massey, C. (2018). Overcoming algorithm aversion: People will use imperfect algorithms if they can (even slightly) modify them. Management Science, 64(3), 1155–1170. https://doi.org/10.1287/mnsc.2016.2643 ## Use with your AI This note is also a skill: `studio-jz-algorithm-miss` (version 1.0.0). Download: https://softwarebehavior.com/skills/studio-jz-algorithm-miss.zip · All skills: https://softwarebehavior.com/field-kit Software Behavior Field Notes by Joost van der Zwan · Studio JZ · CC BY 4.0 · softwarebehavior.com --- --- title: "Should onboarding start at zero?" code: JZ-007 series: Perception published: 2026-11 updated: 2026-11-01 author: Joost van der Zwan canonical: https://softwarebehavior.com/notes/jz-007 skill: studio-jz-head-start license: CC BY 4.0 --- # Should onboarding start at zero? Field Note JZ-007 · Perception · Two free stamps **34%** of head-start cards completed ## The guess Free stamps don't count: people only care how many steps are left. ## What the research found At a car wash, some customers got a loyalty card that needed 8 stamps; others got one that needed 10, with 2 already stamped. The same eight washes to go. 34% of the head-start cards were completed, against 19% of the plain ones, and they were filled sooner too. ## Why A goal that is already under way feels closer, so people keep going. ## What to do - Count what people already did — account created, email confirmed, first project made — and show it as progress. - Start progress bars and checklists with that progress visible, not at zero. - Keep the number of remaining steps honest. ## What not to do - Show an empty bar when people have already done part of the work. - Add fake steps just to tick them off. ## Limits - One field study, at one car wash, with one kind of card. - The head start was two free stamps. In a product, count steps people really took. - Status: the completion figures are being checked in the full paper; this skill ships when they are confirmed. ## Example - Before: "Set up your workspace · 0 of 6 done" right after sign-up. - After: "Set up your workspace · 2 of 8 done" with "Account created" and "Email confirmed" already ticked (illustrative). ## Sources - Nunes, J. C. & Drèze, X. (2006). The Endowed Progress Effect: How Artificial Advancement Increases Effort. Journal of Consumer Research, 32(4), 504–512. https://doi.org/10.1086/500480 ## Use with your AI This note is also a skill: `studio-jz-head-start` (version 1.0.0, in review). All skills: https://softwarebehavior.com/field-kit Software Behavior Field Notes by Joost van der Zwan · Studio JZ · CC BY 4.0 · softwarebehavior.com --- # Frameworks used in reviews From The Product Architect by Joost van der Zwan (https://softwarebehavior.com/frameworks). These are the book's frameworks, not studies: label findings that rest on them as "framework, not a study". ## The Product Beneath the Interface Layered stack · Chapter 2. The book's defining lens. Names the system layers that shape what the visible UI can honestly express. - State - Memory - Permissions - Timing - Confidence - Autonomy - Orchestration - Recovery - Visibility Use in a review: Check whether the screen honestly shows the system state, timing, confidence and recovery behind it. ## Negotiated Software Loop Loop · Chapter 3. Describes the new contract between user and machine in probabilistic systems: intent, interpretation, suggestion, review, delegation, report back, correction, adaptation. - Intent - Interpretation - Suggestion - Review - Delegation - Report back - Correction - Adaptation Use in a review: For AI and probabilistic features, check how the system and the person take turns and who has the last word. ## Behavior Design Questions List · Chapter 4. A working list of questions to ask when designing behavior rather than interaction. - Notice - Infer - Act - Ask - Reveal - Reverse - Back off Use in a review: Ask all seven questions of any feature that acts on its own. ## The Trust Stack Layered stack · Chapter 7. Names the structural materials of trust in intelligent systems, from expressive at the top to foundational at the bottom. - Legibility - Reversibility - Controllability - Recoverability - Consistency - Restraint Use in a review: Check each layer from the bottom up; trust fails at the lowest missing layer. ## Workflow Authorship Canvas Canvas · Chapter 5. A canvas for redesigning a workflow rather than wrapping it in better UI. - Trigger - Context - Decision points - Handoffs - Repetition - Bottlenecks - System assistance - Human control Use in a review: For a flow, map where decisions, handoffs and repetition sit before judging the screens. ## Layers of Product Value Layered stack · Chapter 1. Shows how product value appears across surface, flow, logic, behavior, and strategy. - Surface - Flow - Logic - Behavior - Strategy Use in a review: Say at which layer each finding sits, so a surface fix is not mistaken for a behavior fix. ## Behavior Prototype Checklist List · Chapter 11. Scopes a prototype as an instrument for a named risk, from a sketch or clickable flow to running behavior. - Assumption - Trigger - System response - Visibility - User control - Failure case - Recovery path Use in a review: When a finding needs testing, scope the prototype that would test it. ## Behavior Spec List · Chapter 4. A structured template for separating exact rules, interpretive assistance, evidence, measured reliability, authority, consequences, recovery, correction, and backoff. - Trigger - Inputs - Confidence - System action - User control - Visibility - Correction - Backoff - Autonomy level - Intent preview Use in a review: For AI behavior, check that the spec separates exact rules from interpretive help and covers recovery and backoff. ## Operational Taste Test List · Chapter 8. Converts taste from aesthetic preference into a set of operational decisions: what to automate, where to keep friction, what should not exist at all. - Does this deserve automation? - Does this deserve friction? - Does this need visibility? - Does this need restraint? - Does this simplify the user's work? - Should this exist at all? Use in a review: For each automated step, ask whether it deserves automation, friction, visibility or restraint. Software Behavior Field Notes by Joost van der Zwan · Studio JZ · CC BY 4.0 · softwarebehavior.com