Lego is an ingenious invention in that there is value in the individual blocks, but unlimited value in what you can build with them. Sure, you get the instructions with a new set to build the race car, but what really rocks is the super jet-powered drone boat that you come up with yourself. Oh, and that drone boat? Yep, it has lasers attached.

This notion of plugging bricks together is becoming more and more prevalent in technology. There are tools such as Zapier, which allow you to connect together different components to automate business workflow:

There is Axe Edit, which is used to produce audio patches for the Axe FX line of guitar processors:

We have even seen this model in action for teaching kids rudimentary methods of programming and logic, such as with Scratch:

Part of the reason this block-based model works is that building things is intrinsically intuitive to us. There is a reason why Lego has been so popular with kids for the last 69 years: we like to build things from a very early age.

There are also various psychological benefits with this kind of block-based collaboration, such as increased communication between builders of their intention and key concepts, generating social capital for active participation, increased speech and communication, and a focus on central problem solving and implementing and testing hypotheses. It is no surprise that Lego is increasingly used in team building and problem solving workshops.

This block-based approach clearly works. What I find interesting though is just how powerful of an approach this is not just for structuring collaborative tools, but also how you can build engagement and communities around it.

Why This Works

There are 5 key areas that I think are important to highlight here.

#1. Connecting together blocks is simple and intuitive

As mentioned above, clicking together blocks is a fundamentally intuitive approach to building things. We think about what we want to do, select a block, connect it to another block, and see if it works. We do this via trial and error and it builds a mental model of not just how the blocks work, but how combinations of blocks work.

For example, in Zapier, once I understand (1) what two blocks do (such as Google Docs and WordPress), and (2) how to click them together, I can immediately generate value and improve my business. This results in a very low learning curve, and a very quick route to experiencing value (which is often not the case as products get more and more complex.)

#2. Each new block expands the potential and value of the tool

When I understand this core approach of how to connect blocks together, it also generates a sense of unlimited potential.

“All I need to do is learn what all the blocks do, and I could build anything!”

This is the same “aha!” moment many kids have with Lego.

As such, when a tool adds new blocks (such as when new services are added in Zapier) it expands this sense of potential.

This is enormously gratifying. It converts the tool from being a very specific Swiss army knife with a very specific set of blades and applications, into this:

Importantly though, because we already understand how to click together blocks, each new block provides expanded value with a limited cost in understanding how to harness it: you already know how to plug them together.

#3. This model maps well to seemingly very specific problems

When most people evaluate a tool or service, they have a very specific set of problems they want to solve, but they want to ensure the tool or service can serve them well into the future (and with unseen future problems.)

This can be frustrating. For example, there are a zillion marketing tools all of which have great features, but all of which are missing something key to my specific work. I just deal with it, presuming that only I need that specific feature as opposed to the general audience needing it.

With this block-based on model, you just connect together the right blocks that are very specific to your needs. Zapier is another good example here: I have used it to automate elements of my business that are likely completely specific to me.

All of this means that evaluating and choosing a tool is much easier: we know that we can ultimately solve almost any problem if we have the right set of blocks available.

#4. We have to do the creative thinking for prospective users/customers.

Speaking of which, the risk of the block-based approach is that you need your audience to be able to have the creativity to come up with the right combinations of blocks to solve their problems. They need to be able to understand the components of their problem and how they map to the tool.

I love how Zapier solves this. On their website you can click on the tools/platforms you use (here, I selected Google Sheets and Gmail), and it will suggest combinations:

This is really important. While the suggested zaps might not map to problems the user has, it will start to seal in their brain the notion of how these blocks can be combined to generate interesting outcomes. I suspect the conversation rate from that page into new trials is pretty high. 🙂

#5. There is a clear opportunity for segmenting and building communities

When I work with clients in the early stages of a community strategy engagement, we discuss what kinds of community they want to build. Building a community of users is very different to building a community of contributors.

The communities that succeed provide a simple way of adding value to the broader ecosystem around the product/tool. With these kinds of block-based tools, putting together a combination of blocks and sharing it with your fellow community members is a really simple way of participating. We have seen this, for example, with the AxeChange community which has hundreds of submitted patches for sounds that you can load into your Axe FX:

Interestingly though, you could also produce communities where (1) people could contribute blocks that could be available in the tool, and (2) people contribute to the tool itself (such as with an open source community.)

These three communities (block combinations, contributed blocks, and tool contributions) require very, very different community strategies, but all have very clear (yet different) potential for generating value with varying degrees of technical expertise.

I suspect we are going to continue to see more and more companies taking this approach to using blocks to build combinations and pipelines. It is one of the most elegant approaches I have seen for not just providing an intuitive way for people to work, but also for quick and efficient on-boarding, clear community participation, and always expanding value and potential.

What do you think? Have you seen other examples of these kinds of interfaces that work well? Have you seen some examples that don’t work well? Share your insight in the comments!