How no code borrows from games to alleviate the pain of work
Far from the hype of ‘gamification’, no code platforms quietly copied their best ideas from game mechanics, adding to an advancing mission to turn all work into play.
Contents
TL;DR
The market for no code is sized at 16bn$ (2021) and is slated to grow at a blistering 29% every year to breach 160bn$ by 2030. Is no code a tech revolution or an approach which was been evolving steadily all along? No code’s beating heart was built on the foundation of how we play games, and spoiler alert: the current state has been a long time in the making. The no code industry has already inhaled the codex on games, learning how to alleviate the pain of work. We’ll be wise to copy the approach and study our connection to games in building the next generation of work tools.
Our Connection To Games
It's a matter of historical record that when Mark Twain created his account on Medium way back in June of 1896, he was flying well under the radar. After spending a few days not making any headway being accepted into Medium’s writer monetization program, he was stumped. In a fit of unmetered rage, he logged off, cleared his cookies, and uninstalled Chrome. After almost a month of playing hard to get, he circled back to publish his first story (well more like a quip).
Love what you do, and you’ll never work a day in your life. Work and play are just words used to describe the same thing under differing conditions.
It's widely speculated if this was a case of Twain’s understudy pushing Publish prematurely on what was actually a research stub. But Twain never posted his expanded thesis, and for the large part, the post remained ignored by the audience. It didn’t receive any claps.
Four decades later, Dutch historian Johan Huizinga, was looking for inspiration for his new book and discovered Twain’s micro-post in his feed (a recent algorithm change at Medium prioritising short-form content was partly to blame).
It clearly made an impression on JH, as the book which went on to be published later in 1935 was named ‘Homo Ludens’. Loosely translated — humans love to play. In an exclusive launch interview (circa 1935) organized by the publishers, JH spoke extensively about his inspirations, going on to claim that our culture itself is generated from play. Unsurprisingly, the as-yet-obscure quote by Twain shot to fame shortly after.
It wasn’t until May 18th, 2019 that Apple CEO Tim Cook entered the chat, taking a cold hard stare at Twain’s original research stub. Dismissing Twain’s thesis as total hokum, Cook argued that when passion collides with a job to be done, working hard is a natural outcome. The larger the collision, the easier the hard work becomes. Work is always work. There are no playful shortcuts. Pack accordingly!
I believe what Tim meant was — when you enjoy doing the jobs (no pun intended), the effort you put into working befits the sense of purpose, accomplishment and emotional alignment you get out of it. The jobs become games worth playing. Although I’ll add a disclaimer here — any job can be a game, but not for everybody. People have intrinsic differences, which leads them to evaluate some games as more worthy than others.
If you have any doubts about how much toil people volunteer for while playing casual games, look no further than Gloomhaven. Launched in 2015 on Kickstarter, the board game has 17 playable characters, 95 missions, numerous scenarios, a breathtaking collection of playable elements including cards, tiles and tokens, not to mention the “fun” of optimizing your inventory while managing personal side-quests. The rule book itself runs into a hulking 82 pages; I’ve completed entire courses at college reading fewer pages than that. It’s quite likely that the seasons will have changed by the time you step outside after finishing this game. Perhaps not so “gloomy” is that the game went on to sell more than 120,000 copies and has been received with widespread acclaim; some even going so far as to call it the best board game of all time!
All this might sound like a crazy exception, and partly it is, but it really isn’t as out there as you might expect. There are dozens of similar games, each with its own devoted fan base.
Another disclaimer is warranted — increasing difficulty of gameplay is inversely proportional to player reach. You might be able to recruit fewer and fewer participants (albeit more fanatical ones) as your game becomes more and more complex. It sounds reasonable that this should be the case right? The longer it takes for players to “find their own game within the game” the higher the odds it will have a smaller (and perhaps more fanatical) audience. This is a choice you make as a game designer.
But how can the knowledge of games help inform the design of work, the thing we spend a third of our lives doing?
Finding The Games Within The Work
If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.
— Antoine de Saint-Exupéry
Just remember how satisfying it feels to finally complete a long overdue inbox cleanup, or check off that last item on a todo list, the momentary catharsis you experience when you’re designing that pristine structure for a shared project folder (before your colleagues get their claws in). These feelings are the results of game mechanics we unconsciously invent to eat a task at hand. It’s just the way we’re wired to get painful stuff done.
On the other hand, there is a limit to how well we can manifest these mechanics for each task, and it doesn’t work most of the time (unless you’re in a version of OASIS in Ready Player One, in which case I’d love an invite). Ask a teen to start saving and investing pocket money and that's immediately labelled a chore (no game). Then ask them to fire up Death Stranding on their PC, and they’re totally game. Ask Dad to choose and he’ll jump at the chance to check on his investment portfolio and get busy re-allocating funds between asset classes. Who in their right mind would want to play a Sisyphean porter delivering mail where the core challenge involves walking hours, balancing heavy cargo, and delivering mail on their back? That’s 60 hours of my life I’m never getting back.
The task obviously has an intrinsic affinity with an individual. It’s not the same for everyone, and we saw this in the case of our board games as well. Does this mean we can’t ever make playing Investor a worthy game for teens?
The answer is an emphatic yes!
As students of our user's behaviour, our job is to understand that the drive to see the ‘game in the task’ is innate. Unlike in the case of Gloomhaven’s 82-page rule book, where the product targeted a niche audience, the solutions we’re looking to build need more mass appeal — general games. This really aligns well with the current wave of product-led thinking in building products. So we’ll do it by leaning heavily on designing the mechanics of our product so that users can cross over into game territory within our product as quickly as possible, with no extra help.
I can’t stress enough how different this approach is from “gamification”. To me, that’s a term often used to depict the retrograde tactic of building the product first, and later waking up to solve a user retention problem. It makes the whole thing into a sellable framework for consultants. Honestly, anyone whose been in the “gamification” business long enough knows, it solves nothing long-term and drives user habits towards the wrong thing.
Eric Klopfer, Professor at the Education Arcade at MIT puts it aptly.
The problem with this approach is that it merely creates chocolate-covered broccoli. The learning and outcomes aren’t tied in any way to the game dynamics. And this simply is not effective in promoting learning or change in any way.
A game isn’t a magical ploy or a tactic to make broccoli interesting. Rather it’s an outcome you achieve only when your user feels joy in — chomping broccoli; hold the dips!
Well enough about that now. I just had to get that out of my system.
Building Games Worth Playing
In the evaluation stage of any product, there’s a brief window of exploration in which a user will suspend judgement and invest time and effort in the hope of the game emerging. In product speak, we know this as the window of evaluation or time to value — beyond which, the user will either decide to abandon further investment (drop off) or become convinced of the value and label the experience as worthwhile (activation). The longer the window a product requires, the larger the risk of losing the user before reaching point activation.
This is an oversimplification. Let's slow down for a moment to see a bit more detail.
- The point of activation is not a preset point in your user's journey which you know or plan for before launch, rather it’s a collection of events which the user has experienced which are highly correlated to long-term engagement. If you could directly ask your users, this would be the point at which the whole thing started “feeling like a game”
- The time span of the activation window will vary among user cohorts. Yes, people are different; remember the preset affinity we spoke about earlier? But in general, when you group users into unbiased cohorts the differences should even out, otherwise, there’s something worth investigating there
- If you have more than a single feature in your product, the activation window isn’t one single event but a repeating cascade
Now you already know why most no code platforms really shine — they drastically undercut the need for prior knowledge, while still helping you get productive outcomes fast (within hours if not minutes). Unbeknownst to the end user, behind the scenes of those intuitive GUIs, these platforms adopt some pretty uncommon common-sense mechanics to make it feel like a more approachable game. These have the effect of reducing the size of the evaluation window by orders of magnitude and opening up the game, from being accessible to only 1% of people (coders) to almost anyone who can work a mouse.
There’s a prominent democratisation of access angle here which is what we’re interested in this article. But don’t be fooled for a moment, this isn’t as much about speeding up time to value, ROIs for coders and developers who are scrambling to build their no code competencies to meet demand.
What No Code Stole From Games
Although there isn’t a common theme or recipe describing all the no code tools out there, each one leans more heavily on one mechanic over another, there are some recurring traits we’ll talk about now. Don’t look at it as an exhaustive list of mechanics though, and I’ll look at adding more over time. ‘Social collaboration’ is a key mechanic which I’ve deliberately omitted as it deserves a larger treatment in itself.
1. Sprinkle surmountable challenges
Verily, I say unto thee, if thou removest the user friction, they shall journey on through more swiftly, that they may reach the point of activation with great haste.
— Unknown
The common wisdom says removing user friction is a good thing. It reduces deviations from expected behaviour and keeps the user on a steady drumbeat towards Mt. Activation. What we often miss is the flip side(because it seems to have none). Chelsea Thrupp has a brilliant take on the trade-offs for friction as implemented in TikTok or Tesla which is relevant here. In our zeal to remove too much friction, we can actually rob the user of the satisfaction of accomplishment. Friction when introduced in a planned way can make the user start feeling invested (think stick) in your product. Games understand all too well, which is why they often use two different scales of challenges. They can often introduce notoriously expansive quests or missions, and then at a smaller “daily scale” they keep pricking with small tactically placed friction like managing inventory, and completing side-quests. These allow the user to experience success regularly, and alleviate the burden of exploring the larger challenge.
In the Death Stranding universe, you wake up in a world filled with existential problems needing urgent solving — freeing the country’s president-designate being held by a terrorist, delivering crucial cargo over long distances (in manual mode aka walking), and a vespuccian megatask of reconnecting an America now gone dark. It also imposes several surmountable challenges to help lock down your focus and keep you from getting disoriented. You can carry a limited load so you need to prioritise your backpack inventory to survive (or usually die). You have limited endurance and balance, so you can’t go on steep terrain. Rain is a dangerous time accelerant which hyper-ages anything it touches and thins the membrane between the world and that of the dead, so plan ahead to stay far from rainfall. Got it? It even turns your bladder into something you need to manage as a weapon to fend off ectoplasmic entities along the way. These mechanics are not accidental. They’re deliberate constraints placed as a continuous stream of micro-challenges (read ‘good friction’) which offer you a chance at satisfaction at every turn, all the while progressing onwards in the larger mission.
Now let’s see how Zapier does this beautifully with somewhat less audacity. In Zapier, you can create Zaps (steps of interconnected actions) to build workflows and solve a problem like automating a large repetitive task. But each logical step is constrained to a selection from one of 26 prefabricated blocks.
These constraints keep the beginner from going nuts trying to learn a hundred open canvas ways of implementing one action, something insurmountable. You have the pleasure of stringing together multiple blocks (each simple to understand in themselves) to get the result you want. The problem of creating the entire workflow might be hard, but selecting a block along the way, dragging and snapping it into place at each step isn’t. With each blocky step forward you construct one of the walls of your own bespoke Lego house. You experience the joy of overcoming a surmountable challenge, all the while proceeding towards your larger goal, getting more and more invested in the platform, and prone to activation. Just imagine how satisfying Zapier would be if it decided to eliminate all friction and pre-build the entire library of automations itself. It would also mean having a paltry 1000 instead of the millions of automations, it’s users have hand-built over the years by investing their own time on the platform.
🕹️ Zapier has over 3mn users and is a 5bn$ platform built on breaking large problems down into surmountable challenges.
2. Create permanent scaffolding
Scaffolding is a term commonly used in construction. These are the metal or wooden grid of hollow pipes and beams which are mounted around a structure being erected, making it easier for workers to access difficult-to-reach parts of the building. These are usually temporary and come off after the project is complete.
In the software world, you constantly see scaffolding in games and productivity tools where a dense or complex function is abstracted into a simplified super layer.
Traditional mouse and keyboard work best for playing top-down perspective games like Diablo 3. The situation changes drastically when players join in from consoles like Playstation and Nintendo Switch have joysticks to control motion and aim. Studies have shown that console controllers are at a disadvantage compared to PC mice. So what do we do, Diablo 3 implements something called ‘aim-assist’ for console players which scaffolds the usability gap and helps console gamers have an ‘even’ experience. It’s fair to say how even this scaffolding really is, is hotly debated.
With Teleport (a no code webpage designer), there’s an example I like to give for scaffolding — how you can create a button animation for a web page. So elements in HTML have these states for defining how the element’s appearance changes when a user interacts with it. Coders implement this interaction in the underlying CSS code using something called pseudo-classes. But Teleport doesn’t want you to learn CSS. Using a graphical interface, it facades the underlying complexity, making customizing the appearances for all the interaction states as simple as clicking a button. This is an example of permanent scaffolding, where the abstraction layer is frozen on top of an underlying functionality to simplify interaction and boost speed.
This might seem similar in intent to constraints, and it is, but the approach is to create a 1:1 replica of the underlying functionality.
🕹️ TeleportHQ is an exciting new web design tool fighting against the no code tide of vendor lock-in, allowing you to port your work to any platform. They recently closed a 2.2mn$ funding round.
3. Disclose complexity progressively
Progressive disclosure is a well-understood interaction strategy where the system initially reduces choices for the user to select from by only showing the most relevant options. Over time additional features or options may be exposed. New users benefit from this approach facing less need for upfront investment and reduced chances of getting overwhelmed and consequent drop off. From our multi-featured product activation example earlier as well this seems to fit in perfectly as a continuous process of discovery.
While tutorials or training episodes are used in many games, almost all games use a system of levels to ramp up the complexity as players get more conversant with an environment.
A good example of progressive disclosure within Bubble (a no code for full-stack web apps) is the plugin system. Using plugins, Bubble keeps its core interface simple, while keeping additional features hidden away. As users come across a use case which requires a plugin, they can simply choose to add it from Bubble’s vast marketplace.
As the user becomes comfortable integrating the first plugin into their project, they can add the next and the next, and the complexity grows progressively from there-on.
🕹️ Bubble has over 350 plugins and is one of the most feature-complete no code app development stacks in the market.
4. Realtime Feedback
Coders have it hard. Often they have a long wait between making a code change and then compiling, packing, integrating their change, and triggering the right scenario to finally render the impact. The cost of this is reduced experimentation, and developers tend to create changes in larger-sized chunks to reduce the overhead cost involved in rendering. Things have been easier lately with the advent of DevOps-friendly strategies like hot module reload for web or app development or Android Studios’ instant run, but games can wipe the floor with all of them when it comes to giving feedback en rapidé.
In Hearthstone, a turn-based strategy game, playing cards take on new meaning as they move around, glow, or fall asleep, literally acting out the actions you command them to make. Characters speak out loud with witty remarks, reaffirming when they get hurt or make an advance, and tooltips and overlays are thoughtfully scattered all over the interface to guide you about the next action. It just makes the whole experience that much more intuitive from the get go.
Carrd.co is a no code landing page generator. One of the things it also does is give proactive feedback between actions. Say you’re trying to move a stack of button elements, it will highlight the allowed drop points on the screen with subtle highlighter bars.
With feedback in advance, the user can be clear about what options she has even before she can make a mistake. This kind of visual hand-holding is crucial to speeding up trial and error and allows the user more time for creative exploration. Ultimately this is a good user experience, especially for a user with no experience in layout organization.
🕹️ Carrd is a bootstrapped no code startup which scaled to +1m$ in ARR, and currently hosts over 4mn landing pages.
The Future Of Work Is Play
No code is a narrow subset of a larger category I like to call ‘playable tech’. These are products which are generally designed to obviate the need to understand the product itself and help users with little to no prior experience to start getting outcomes right away (even if they’re scratchy) and then iterate fast. No lengthy tutorials, no reading up user manuals, paging through lengthy how-to books, or taking an online class. Play tech is immersive, (good) challenging, backgrounded, continuously self-explicatory, and often built around engaging communities that expand the platform. They help the user adventure as far down the rabbit hole as they’d like, with an oxygen tank and a hard reset button.
The good thing is this kind of tech is becoming more and more ubiquitous in almost all domains— whether it’s Canva for graphic design, Memberstack for building monetizable communities, or Biteable for creating product explainer videos, Notion for organizing work, the list is endless.
We’re in a full-blown arms race to background software and forefront outcomes and I for one can’t wait to see playable tech over our work.
Enjoyed this article, see something I missed or have a differing viewpoint? I’d love to hear from you. Let me know in the comments below.
Image Credits: Images by catalyststuff, upklyak on freepik
