I'm working on a SAAS platform. All users must login, so user ID, location, affiliation etc. are almost always known. The platform also has substantial game components, recording user progress and achievements.

One of the goals of the platform is to provide a friction-free experience for the user. Much of the time this is accomplished by serving conditional views of page elements/modules depending upon the user's state. State here would include affiliation, location, progress and time.

Some use of conditional views is good and desirable, but I'm worried that sometimes we're compensating for muddy UI with user-specific (conditional) views. Also, some pretty complex logic is stacking up in the back end to make the conditional views work.

Is there a rule of thumb for how much conditionality is too much? Put another way, does complexity matter, if the user doesn't see it?


The only "rule of thumb" I can see applying is the 80/20 rule which I live by. In general it means that if you have an exhaustive list of all use cases, 20% of them will account for 80% of the activity on the system.

Therefore I try to design for 80% of all users, thus initially covering 20% of all use cases. In your case it sounds like you're getting past that initial 20%, so I would say to try and nail your core use cases on the head first, and then re-evaluate the granularity of your conditional views. If you feel the current granularity is causing maintainability issues, or are not providing enough value for the cost, then it may be time to back up a bit.

In theory, the complexity of the code shouldn't matter so long as it is cost-effective and provides added value to your solution.

  • That's a thoughtful answer, thanks. I think we do lose sight of the 80% in working through the edge cases. Probably a good way of dealing with that is by creating data-supported personas to help keep us on track.
    – RobC
    Apr 11 '12 at 21:37
  • I completely agree with you, excellent idea to have some personas around.
    – GotDibbs
    Apr 11 '12 at 21:51

Your Answer

