Fitts and Hick, measured on you
Both laws get quoted in design writing as vibes. Both are fitted equations with coefficients, and you can measure your own in about two minutes.
Fitts's law usually shows up in design writing as "bigger targets are easier to hit". Hick's law shows up as "fewer options is better". Both statements are true and neither is what the law says.
They are regression equations. Each has a fixed cost, a slope, and units. Run the experiments and you get numbers, and the numbers are more useful than the slogans because they tell you when the effect stops mattering.
Fitts
Movement time to a target depends on the ratio of distance to width, not on either one alone:
MT = a + b · log2(2D / W)
That log term is the index of difficulty, measured in bits. Doubling the distance and doubling the width leaves it unchanged, which is the part the "bigger is better" summary loses.
Fitts, measured on you
movement time = a + b · log2(2 · distance / width)
Click the small dot, then the target, as fast as you can without missing.
The scatter plot is your data. The line through it is the fit. a is your fixed overhead, the part that doesn't depend on the target at all: reaction, click, release. b is how much each additional bit of difficulty costs you.
1/b is throughput in bits per second, and it's roughly a property of the input device rather than the person. A mouse typically lands somewhere around 4 to 5 bits per second, a trackpad lower, a finger on a touchscreen lower still. If you ran the test on a trackpad and got a lower number than you expected, that's the device.
What it implies
The ratio being what matters is the actionable part. A 44px target in a toolbar you're already near is easier than a 44px target across the screen, and no amount of enlarging fixes distance.
That's the real argument for context menus, radial menus, and putting destructive actions far away rather than merely making them small. It's also the argument for screen edges: an edge has effectively infinite width in one direction, because you can't overshoot past it. The macOS menu bar is a Fitts optimization, and a menu bar with a 1px gap above it throws the whole benefit away.
Hick
Choosing between options takes time that scales with the log of the number of options:
RT = a + b · log2(n + 1)
Hick, measured on you
reaction time = a + b · log2(choices + 1)
Rest your fingers on the number keys. When one lights up, press it.
Log scaling is the point, and it's the part the "fewer options is better" summary inverts. Going from 2 choices to 4 costs you one bit. Going from 4 to 8 costs one more bit. Going from 8 to 16, one more.
Each doubling costs the same fixed amount, which means the marginal cost of an extra option falls as the list grows. Cutting a menu from 16 items to 8 saves you exactly as much as cutting it from 4 to 2, and the second one is a much bigger change to the product.
Where it doesn't apply
Hick's law describes choosing from a set the person has already surveyed, where each option is equally likely and they know what they're looking for.
That is not a navigation menu. It isn't a search result page either. Once the options are unfamiliar, unequally likely, or too numerous to survey, people stop choosing and start searching, and search is a different process with different scaling. This is why the law gets cited to justify hiding functionality and why that justification is usually wrong: a menu of 30 well-labeled items scanned visually beats a menu of 5 items that hides the one you need behind a submenu.
The fixed cost a dominates for small n anyway. At two options you're paying about 1.6 bits worth of decision, and most of your response time is the part that has nothing to do with deciding.
Reading your own numbers
The coefficients only compare against themselves. Your a includes your display latency, your input device, how warmed up you were, and how much you cared, so it isn't comparable to a published figure.
What is comparable is the shape. Both fits should have a positive slope and an r squared somewhere above 0.7 with clean data. If your Fitts r squared came out low, you probably rushed the small targets and missed, and the misses aren't in the data.
The one number worth carrying around is the Fitts throughput, because it converts directly into a design budget. At 4 bits per second, a target that sits 5 bits of difficulty away costs a user roughly 1.25 seconds every time they reach for it, and you can multiply that by how often they do.