Why you'll never nail down requirements - Tog Paradox

One thing is certain in life, change. And one thing in life of product is certain, change of requirements. You may spent every dollar your company have on market research, UX studies or whole fleet of prototypes. Duh, go bigger - give your whole life to figure out what would be the best ever layout for that dashboard page you have to do. But the only thing certain is that after you launch it, a few weeks after devRequest will come in if you could tweak it a bit really.

This is very common feeling among any sort of product managers, developers or designers. All those feature and scope creeps. Changes of minds. After a few rounds a lot of us starts doubting:

What is so hard about gathering requirements that we can’t get it right?!

And answer is: nothing. And for most of us I’m almost certain that you are getting it right when you actually do it (as long as you don’t develop by gut feel alone). There are however two behavioural patters that influence you, your products and you users. Let’s look on the works of Mr. Tesler and then Mr. Tognazzini.

Tesler Law

According to Laws of UX, Tesler Law highlights the relation with system complexity vs user tasks. Tesler stated that for any system there is a certain amount of complexity which cannot be reduced. Every process does have some base complexity that has to be either handled by system or by user actions. There are dozen outcomes you can take from this law alone, just to name the few:

1. Complexity can also be noted here are ease of use, not just functionality scope.

2. Users get’s more “stupid” the more advanced systems they use as complexity is offloaded from them. Like we offload navigational skills to Google Maps.

3. If system is taking a lot of complexity in, user onboarding becomes the challenge.

4. The more complexity you pack in the more value you sell to end user.

Larry Tesler argues that, in most cases, an engineer should spend an extra week reducing the complexity of an application versus making millions of users spend an extra minute using the program because of the extra complexity.

Tog’s Paradox

But there is another… Bruce Tognazzini however disagreed with a Tesler considering only singular processes in vacuum. He formulated the paradox as a loophole in Tesler’s Law. Instead of believing that inherent complexity can be shifter form user to system with end sum remaining the same - Bruce Tognazzini proposes that people resist reductions of complexity in their lives. Sounds counterintuitive?

Not directly though. Everyone when asked directly would like an easier tool, app or life. Yet Tog underlines that when an application is simplified, users begin attempting more complex tasks. Effectively complexity keeps on growing on both sides, system & user.

People will strive to experience an equal or increasing level of complexity in their lives no matter what is done to reduce it.

– Bruce Tognazzini, The Complexity Paradox

Example

For instance, a basic CRM system designed to automate customer interactions might initially focus on basic functions like managing contacts and tracking communication history. Once core features are in users that experienced the efficiency gains from those may begin requesting more sophisticated tools. Integrate with LinkedIn, Teams, Google Meet. Include some AI to generate messages or do me a super-duper detailed dashboard. Each new feature brings added complexity to the system, requiring not only more robust infrastructure but also additional training and support. This mirrors Tognazzini’s idea that making tasks more efficient encourages the demand for additional use cases, driving the complexity of the software.

Type of the application does not matter much here. Look how banking apps are becoming more and more multipurpose. How MS Teams is incorporating broader spectrum of work oriented features. The most commonly mentioned example of it are usually social media platform like Instagram and Twitter/X. Intended with icreadibly basic aim of just sharing photos and quick thoughts with friends. Fast forward a few iterations of Tog Paradox and we’re looking by incredibly detailed and powerful platforms allowing you numerous ways to connect with your following, monetise your content, promote it - one may say more powerful stream than conventional media from early times of Insta.

Meaning for requirement engineering

It’s interesting to look at cases like that from the past, but what we can take from that for the future? Very simple sum-up:

For tech products it’s impossible to ensure that gathered requirements wont change

It’s just not a case. Every developed tech product will fall into Complexity Paradox. It reveals why attempts to finalise design requirements are often doomed to fail. With each feature released users will be encouraged to step it up a notch. The moment a product begins to solve its users’ core problems efficiently, it sparks a natural progression of second-order effects. As users save time and effort, they inevitably find new, more complex tasks to address, leading to feature requests that expand the scope far beyond what was initially anticipated.

Tog’s Paradox has significant implications for user experience design, particularly in how complexity impacts usability and user satisfaction over time. As products evolve and add features in response to user demands, the original simplicity and ease of use can degrade, leading to a more complex and sometimes overwhelming interface. This presents a core UX challenge: balancing the need for added functionality with maintaining an intuitive and accessible user experience.

TLDR; What to do then?

1. Products must be managed in a way that expanding features is always possible with a reason.

   1. Even if the business says they will never will

   2. It does not mean wrapping every line of code in facades and connectors. Writing not that shitty code is a good start.

2. Agility will always win over pre-work in dynamic products

   1. Deliver small and see what’s happen. Talk with users, they drive that dynamic.

   2. It doesn’t mean not to skip pre-work, just be aware that what you’ll find may notably change.

3. Products will always go into being more complex

   1. Even if they would to become “simpler” that will most likely be achieved by more complexity added, just hidden from the end user.

   2. Be aware that users are not permanent, make sure the complex features will match new users as much as a pro guys.