Some of these may be more pertinent while analyzing User Experience compared to composing User Experience.
Occam's Razor: What is this control meant to do?
Pareto: does this UX cover at least 80% of the user's needs? Are there critical cases in the remaining 20%?
Parkinson's Law is more of a bank shot, but think of it along with the Pareto Principle: Organize the UX so that the user can accomplish the most important tasks in the least time.
No. I’m saying if you squint hard enough, then maybe you can think of how these apply to UX, but they don’t directly indicate some insight of UX, in any way like the others do.
> Occam's Razor: What is this control meant to do?
If that’s how they mean to apply it, they should phrase it as “users make the inference about the control that requires the fewest assumptions about how to model the UI”. There’s a big difference between saying how users actually act, vs how you as an engineer should infer, or what you should optimize for.
And yes, if the latter is meant, then it’s applicable on some level, it’s just not specific to UX (just making inferences about data in general), and even then didn't make clear how it would apply in a UX scenario.
>Pareto: does this UX cover at least 80% of the user's needs? Are there critical cases in the remaining 20%?
That wouldn’t be the Pareto principle, that would be “check the 20% for if you’re missing something critical.”
Again, a tangential application, if you stretch, just not direct like the others.
>Parkinson's Law is more of a bank shot, but think of it along with the Pareto Principle: Organize the UX so that the user can accomplish the most important tasks in the least time.
That's orthogonal to Parkinson’s law, which says that time spent will bloat to its bounds. What you’ve described is a different principle, something like “minimize the time average spent to do tasks, thus giving more weight to the more frequent ones”.
LATE EDIT: With that said, those three should definitely be part of any UX engineer's mental toolkit ... but only in the sense that they should be part of any engineer's toolkit. The specific applicability to UX isn't obvious the way the others are, at least.
> "With that said, those three should definitely be part of any UX engineer's mental toolkit ... but only in the sense that they should be part of any engineer's toolkit. The specific applicability to UX isn't obvious the way the others are, at least."
I think that's fair. I will say that I appreciate this site, but I do think the author had to stretch a bit to get to 20 rules. For instance, I would have had a section just on the Gestalt Principles because they don't make much sense by themselves.
Yes, I also don't see how to apply the #14 "Any task will inflate until all of the available time is spent." to UX. It's more form the area of management.
