Making Product Designs Intentionally Complex
There is a problem. A folklore is misinterpreted, yet again. The stories go something like:
A user looks at a product and blames himself for not being able to immediately figure out how to use it. But he shouldn't as it is NOT his fault but "bad" design. Moral of the Story: "Good designs should NOT confuse the user or make him question himself." WRONG!
It was late in the night, way past 2AM, when my phone beeped from an Instagram DM I received from Kunal Shah. For the few who don’t know him, he is a revered fintech entrepreneur having his previous company FreeCharge acquired in the biggest M&A in Indian Startup history and currently, his 2-year old venture, CRED, has been… wait you know what, fuck this journalist-style shallow intros. Let’s agree he is a big deal and you can Google about him later.
Anyways, Kunal responded to me essentially complaining about "confusing-the-heck-out-of-someone" UI of his product CRED. It is then that he stopped me in my strides to boldly deliver a crucial insight. I was taken aback when he revealed that that complexity was intentionally introduced.
In product design, we always say: "It is not a user's fault that she didn't understand how to use a product." And hence, designers obsess over creating obvious designs that users will comprehend with "utmost ease!"
But this is a flawed approach. There’s a fundamentally better mindset to guide users into making better use of technology. What was more unobvious to me was how complexity in CRED and as Kunal pointed out in many things is introduced to develop a cult-like following.

Complexity is Persuasive
When someone uses complex words, people think of them as smart. And when people figure out the complexity in something, they brag.
Proof of Work
LEGOs are the biggest toy brand in the world today, but a mere two decades ago, in the early 2000s, they were on the brink of bankruptcy. The story can be traced back to the flood of digital consoles that was about to take over culture and cause some people to say, "The era of instant gratification is here." Spearheaded by Nintendo, these games were simple to grasp, quick to play with immediate rewards. It was shaving off sales from all toy companies, including LEGOs.
LEGOs tried to "align" with the millennials by making their blocks bigger and sets simpler. LEGO sets that can be built in under an hour. But the opposite than what was expected, happened. LEGO sales further declined getting them ever so close to bankruptcy. This is when Martin Lindstorm, aka Mr. LEGO, took over. In 2004, during an ethnographic survey, he found himself at a German kid's home. He asked the kid, "What are you most proud of?" And instead, of pulling out his portable consoles and playstations, he pointed at a worn-off Adidas shoes with holes on a side. He said, "These are proof that I'm the best skateboarder in town."
Martin completely flipped LEGO's strategy to make their pieces smaller, smaller than ever, and sets more complex, larger than ever. It took a lot of hard work and time to build these new sets allowing the LEGO builders to take pride in their work. Such stories can now propagate through culture, more virally so in the era of Internet. And the rest, as they say...

This phenomena is nicely playing out in the recent success of note-taking apps like Notion and Roam Research. Type in "Notion" in YouTube's search bar to discover hundreds of videos of people showcasing how they've connected various aspects of their work and life with intricate linked-databases within Notion, creating custom dashboards for all things relevant.
The effort spent creates an attachment to the product and it gets more deeply infused into the identity of the user. #RoamCult is one of the common hashtags I stumble upon in my corner of Twitter.
Kunal pointed out that it is by design luxurious cars are made difficult to use, Temples are made harder to access and Snapchat was made difficult to figure out. Overcoming that difficulty, that proof of work shows as users proudly stand by the product.
Of course, complexity must ideally be justified by more effectiveness, but Kunal Shah essentially pointed out, that the Proof of Work creates a sunk-cost fallacy to stimulate almost a devout allegiance in the user.
At the end of our conversation, Kunal Shah summarized and cautioned in one line: "Easy come, easy go."

Will people make the effort?
It is hard to introduce complexity in a way that doesn’t overwhelm the user. A designer often finds himself in a situation to either introduce more advanced features v/s keeping things simple. This is most cribbed about at the beginning when you’re still trying to persuade the user into accommodating your product. This is where the “folklore around simplicity” directs most energy at. This is where I want to change the narrative to show you an opportunity where you can indeed introduce 'useful' complexity.
The GAP not utilized
When a user downloads an app, he wants it to do what he expects it to (and more). Hence if he couldn't figure out the UI immediately, he would put in the effort as he doesn't wish to continue searching in uncertainty for other solutions.
This is obvious to those who have been making products that user's must first buy before using. It is known that user's buying decisions are motivated by the product's function (but mostly, whatever brand-brain-washing they've bought into), but seldom the ease-of-use. The second purchase of the same product maybe, but rarely the first. And once bought, you can damn well be sure the users will put in the effort to figure it all out.
This is something they will never tell you during user testing and research. But in the wild, users are interested in finding the solution, not judging your product. Users will continue blaming themselves for not getting your product, especially when they've already been assured that the product will solve their need. This is real life.
For the labs of Reality, a designer must focus on the gap there is between "the user blaming himself for not getting a product" and "blaming the design and deciding to switch".
A designer can utilize this gap to introduce "useful" complexity into the designs.
The gap is where Snapchat can unexpectedly throw it's users into the camera viewfinder immediately after opening the app. This is confusing but helps the users acquire a very disposable sensibility towards pictures (I wrote about it here: section 3). And it is by realizing this gap, that CRED could bury the button for their primary utility: "Pay Credit Card Bill" under a tab, instead of keeping it front and center on the home screen. This decision sometimes gets my friend who knows nothing about CRED ask, "What is the function of this app?" But for CRED it introduces an opportunity to create not-yet-understood narratives of a credit card platform, front and centre. I personally think that Social Media platforms could've ditched the simplicity they tried to relentlessly maintain by introducing an AI Algorithm to manage the feeds, and instead create custom controls for users to filter through their own feeds. It would've kept the responsibility to control what a user sees away from the shoulders of social media platforms. Their regulation over the disproportional responsibility, they mistakenly took, is now at the center of the most heated conversations in the world.

The Better Question than "Is it simple?"
When I complained that CRED is anything but simple, Kunal's question transformed my thoughts. He asked: "Is it simple to use after the first-successful run?"
Think about a car. It is confusing and has a steep learning curve and I sometimes think as to why they wouldn't try a gaming controller kids grow up with. But as one learns how to drive, all of the controls get baked into the muscle memory in a way that makes sense and then driving becomes almost a passive thing to do. Complexity gets transformed into simplicity upon climbing the learning curve.
What is registered as complexity in common conversations, is often just "clumsy." The designer can hide away the complexity to not distract away from the beginner-level-simple. And then like a game, guide a user to more complex-levels. If beginner to pro is a gradient, I demand that it is the designer's job to guide the user up this path.
It is common to hear people evangelize, "it is *actually* easy", once they themselves have figured it out. Seen another way, it creates a unique habit for the sake of it and gets baked into the daily lifestyle. I would like to continue driving cars even with all the self driving cars. Driving orients my body in a way that stimulates a unique mental experience I enjoy even when I am merely picking up groceries.
The question "Is it simple to use after the first-successful run?" starts at a point of higher ambition in how we will help the user leverage the technology underneath. We're not constantly insecure that users won't pick us or distrusting of the users in their ability to learn. Instead the reality is, when you allow yourself to create complex designs, you can tame it to arrive at something simple, while not making the mistake of making it too simple. But when you relentlessly force the simpler, you'll most-probably make things 'clumsy' later on when you're demanded to add more features.
Complexity retains the essence that you can eventually distill out as David Perell explained with the anecdote of Picasso's Bull. There's a path-dependency to our questions, and "Is it simple to use?" sends you on a worse path than "Is it simple to use after the first successful run?"
When you allow yourself to create complex designs, while chasing simplicity, you follow a more ambitious path than the one where you start with something simple and accomodate more flows over time. Be ambitious. And trust your users to aspire a more effective use of technology.
Complexity can be good persuasion and gives your users bragging rights. It is a creator of sticky habits. For no sake, or some sake. It will be complex for some, not to others. They will identify with your product, others wont. But to belong or not belong is one of the fundamental insecurity marketing is built upon.