UX Principles for Product Managers

Hick's Law states that the time it takes a person to make a decision increases with the number and complexity of choices available. This has a direct, practical implication for interface design: a screen presenting many options simultaneously — a long navigation menu, an extensive settings page, a form with many equally weighted fields — increases the cognitive burden and decision time for every person who encounters it, regardless of how well each individual option is designed.

This does not mean fewer options are always better in an absolute sense — some tasks genuinely require presenting many options (a product catalog, for instance) — but it does mean that unnecessary choice proliferation carries a real cost, and that progressive disclosure (revealing options only as needed, rather than presenting everything simultaneously) is often a legitimate design response to Hick's Law, one a PM can advocate for at the level of "should we reduce the number of simultaneous choices here" without dictating the specific visual mechanism (a dropdown, a multi-step wizard, a search-first interface) design should use to achieve it.

Fitts's Law describes the relationship between the time required to move to and successfully select a target and two factors: the target's size and its distance from the user's current position. Larger, closer targets are faster and easier to select accurately; smaller, more distant targets take longer and are more error-prone.

This principle has direct, practical implications for interaction design that a PM can evaluate without needing to specify exact pixel measurements: is a frequently used action (like a primary call-to-action button) sized and positioned appropriately for its importance and frequency of use, or is it small and tucked into a corner, forcing users to move precisely to a small, distant target repeatedly? A PM applying Fitts's Law as a review lens asks "is this important, frequent action easy to reach and hit reliably?" — a what-level question — rather than specifying "make the button exactly 48 pixels tall and position it at these exact coordinates," which is properly a design implementation decision.

Cognitive load refers to the total amount of mental effort being used in a person's working memory at a given moment. Interfaces that require a user to remember multiple pieces of information simultaneously, track state across several screens, or process several unrelated decisions at once impose higher cognitive load than interfaces that surface only what's immediately relevant, reduce the need to hold information in memory across steps, and clearly indicate current state.

A practical, PM-relevant application of this principle: reviewing a multi-step flow (echoing Lesson 15's journey maps and Lesson 25's wireframes) and asking, at each step, whether the user is being asked to remember something from a previous step that the interface could instead simply display again, or whether multiple, unrelated decisions have been bundled into a single screen when they could be sequenced or grouped more coherently. This is a question about the user's cognitive experience — squarely within a PM's legitimate concern, since it connects directly to the validated pain points and jobs (Lessons 6 and 16) the solution is meant to serve — without dictating the specific visual or interaction design used to reduce that load.

A closely related, highly practical principle: recognition (identifying something correctly when it's presented, such as choosing the right option from a visible list) is generally easier and faster for people than recall (retrieving information from memory without any cue, such as remembering and typing an exact command or a previously seen value). Interfaces that favor recognition — showing available options, previously entered information, or relevant context directly, rather than requiring a user to remember and re-enter or re-derive it — generally reduce user effort and error.

A practical example: an interface requiring a user to remember an account number from a previous screen and manually re-type it later favors recall; an interface that instead displays the relevant account information directly at the point where it's needed favors recognition. A PM reviewing a design can legitimately ask "are we requiring users to recall information we could instead simply show them again," a what-level observation, without specifying exactly how a designer should visually surface that information.

A specific, important failure pattern — directly extending Lesson 22's over-specification warning — is a PM using these UX principles (or any design knowledge) as license to dictate specific visual or interaction design solutions, rather than raising the underlying cognitive or usability concern and trusting design expertise to determine the best specific execution. "This button needs to be blue and 60 pixels wide" is design dictation; "this frequently used action seems hard to locate and select reliably — can we make it easier to find and hit?" is legitimate UX evaluation, appropriately pitched at the level of the underlying principle (Fitts's Law, in this case) rather than a specific implementation prescription.

This distinction matters for the same reason Lesson 22 emphasized it at the level of a PRD: a PM's UX knowledge, however genuine, is not equivalent to a trained designer's expertise in visual design, interaction patterns, accessibility standards, and the many other considerations that inform a well-executed specific solution. A PM who has learned these principles well enough to notice a real problem has done valuable, legitimate work; a PM who uses that same knowledge to unilaterally prescribe the specific fix has overstepped into a domain where a different kind of expertise deserves to lead.