How to positively operate within constraints

Constraints should not be seen as limitations but as a problem-solving tool

If you like this article, please don’t hesitate to click like♡ and restack⟳ ! It’s a quick way to make sure more people will get to enjoy it too.
And don’t hesitate to subscribe to my newsletter for free to receive my new articles right in your inbox!

When the mountain blocks your path, you have no choice but to climb it - so better accept it.

It’s been a while since I last wrote a design essay. As you might know, I’m a designer by trade with an interest in the theory of design particularly (and if you didn’t know yet, welcome to the side of the Critical Stack nobody enjoys but me!)

Today, I’d like to give you this extra weekly essay to talk about constraints and how they are not the killer of creativity we tend to think of them as.

This is not solely a designer thing. We all have constraints in our lives; they pop in and out of existence as we come across problems to solve. Hopefully, this short essay will help you reframe how you think about constraints and see them positively.

I’ve talked about problems before (as in, what is a problem) and the problem-solution dialectic, and constraints exist within those problems. A constraint cannot exist outside of a problem.

An example of a problem which I like to rely on is to imagine yourself stranded on a desert island. That is a problem in itself (though some might like the solitude!) but a more pressing problem is that you are getting hungry.

Being hungry is a problem, because it requires a solution. If there is no need for a solution, then there is no problem. If there’s no problem, then there’s no solution and life goes on.

The solution to being hungry on this desert island is finding a source of food, which requires foraging it, which requires looking for it, etc. All of these steps are part of the problem-solving process and we can use the design thinking method to help use figure out which steps are the best to take.

At the end of the design process, we have deployed a solution: we might, for example, decide to climb a coconut tree and shake the coconuts loose. I wrote more about this example and the design thinking process here, if you’re interested.

Regardless of this primer, I think everyone has some idea of what a problem and what a solution is, so let’s move on to constraints.

What is a constraint?

What are constraints specifically? We usually think of them as limiters, as compounding restrictions that prevent us from fully expressing ourselves or deploying the solution we might have wanted to.

For example, you might have a craving for a specific brand of soft drink right this instant. You drive to the store, and find that they ran out of the drink you expressly wanted. This is a constraint: it prevents you from deploying the solution you wanted to (in this case, purchasing X soft drink was the solution to the problem “I want X soft drink”).

Constraints are therefore naturally seen negatively. They are a hard limit on what we had expected to do and it’s disappointing to learn that things simply won’t go your way, and you can’t really change that. If the store doesn’t have the X brand of soft drinks, then they just don’t. They can’t magically summon new cans of it to the shelf. Of course, you could probably drive to another store! That’s a valid solution because a problem rarely only ever has a single solution to it. But for the sake of this example, let’s say that there’s 5 minutes left before closing and you won’t have time to go somewhere else.

In other words, a constraint puts a detour in your original plan. You built a solution that was right there (in this case the process of driving to the store, completed when you reached the soft drink aisle), and find out only at the very end that this is a no-go and you’ll have to come up with another solution, which means more effort put into this one problem that you’d rather just be done with.

Constraints also exist around our more professional projects, of course. In all lines of work, we bump into financial considerations (there’s no budget to do what you wanted to do), labor-power limitations (there’s more important things you could be doing with your labor), lack of know-how (you’re not familiar with what you’d have to do to solve this problem), and of course even management meddling (they keep changing the problem and thus force you to change the solution!)

All of these — and more — form constraints. Given enough time and resources, anyone could do anything. You could learn to produce music professionally if you had unlimited money to buy instruments, and the time and will to do it for 24 hours a day.

But that’s a bit unrealistic (unless you already know how to produce music I guess). You have to sleep, and you don’t have unlimited money to purchase equipment with. We see therefore that in all problems, we have constraints imposed on us by outside forces.

We operate within constraints individually (not enough time to learn to make music, no cans of X soft drink at the store), but we also operate within constraints collectively. In all collective work — be that at your workplace, your hobby club, your political activism — the same sort of limits apply. A common constraint I see often is wanting to do too much at once. No matter the size of your organization, whether you’re five people or a thousand, there comes a point eventually where you simply can’t keep up, and you’ll have to start prioritizing tasks if you want to keep moving forward. This means that you’ll have to say no to some things so that you can put effort in others that are more impactful, and so it’s a constraint: you are prevented from doing something by a lack of manpower.

The first step to operating within constraints is to know them explicitly

We’ve seen that we always have some sort of constraint imposed on us when solving problems; this is true for all problems, from the smallest (choosing a can of soft drink) to the biggest (e.g. building a new product from scratch).

➡️The first limiting constraint is that we can’t wish what we want into existence. To make something happen, we have to work for it.

All of this can feel paralyzing.

However, constraints shouldn’t feel paralyzing. They can actually be quite freeing if we reframe them positively.

The first step to help with this is to make a clear list of the constraints that are being imposed on you when confronted with a new problem. Do you have a deadline? What can you count on for sure? What do you know will not be available to you?

This isn’t necessarily just for the workplace. When writing a midterm paper, what do you have? You have the Internet at your disposal, you have other students, textbooks, you even have time available (provided you’re not reading this essay with 5 hours left to submit your paper!)

And what do you not have available? What shouldn’t you count on? You might not be able to ask the prof questions. You might not have a comfortable working space. You might not understand the subject.

These are constraints, and while they may seem like a hard stop on your ambitions to study, they actually help us be creative and solve our problems better, if we know how to frame them.

Constraints promote creativity

What I want to convey is that constraints actually help us develop our creativity. And I speak from experience; my work on ProleWiki, which is an online wiki similar to Wikipedia (in that we use the same underlying software) requires me to solve problems and build solutions all the time. And we have plenty of constraints whenever we try to do anything.

We have no money to build anything, for example. So that means we have to do things ourselves or find volunteers who might be willing to help out with their knowledge. We have a technological constraint: MediaWiki is very powerful, but that makes it complicated to learn as there are plenty of different components one has to know about. We have a collective limitation: we have plenty of editors who are not necessarily technically-minded, and so when we give them new tools to work with, we need to make sure they can quickly learn to use them.

And yet, we build solutions and deploy them and people really love them. So how do we do it?

Well, we actually started seeing constraints as freeing instead of limiting.

This is the complete opposite of what a constraint is supposed to be, and yet it works.

Ultimately, all these constraints force us to be creative with our problem-solving. I would define creativity firstly as the ability to deconstruct characteristics down to their most fundamental interactions and components. This allows us to see what we have available for what it is, and not for what we think it should be. In the second step (because otherwise we are only going through half the process), creativity is being able to use these characteristics in a different way than we ought to.

The Facebook component

Let me give you an example quickly to illustrate creativity. Back when Facebook started (hopefully this speaks to you), it was only possible to become friends with other users on the platform. The button was called “send a friend request”, i.e. implying that you are becoming this person’s friend.

This led to some users, often in older segments, to not want to add their family members as friends. I remember one telling me his dad didn’t want to friend him on Facebook because “I’m your dad, not your friend,” he said.

People saw the friend button for what it said on the tin: “click this to become friends,” and not as what the interaction actually did: allow you to see the other person’s posts and profile and vice versa.

Years later, Facebook added the follow button. Again, the difference was not entirely understood by the user base (not that they did much to explain it either way).

On the surface, both buttons (that of adding a friend and following a user) looked similar. In either case, whether you added someone as a friend or started following them, you ended up seeing their posts in your feed. This could certainly be confusing: why and when would you follow someone instead of adding them as a friend?

But the mechanics were deconstructed by Facebook users, and a very interesting difference appeared: friending was equivocal, meaning that if you sent a request to add someone as a friend and they accepted it, they would follow you and you would follow them. You would both see the others’ posts in your respective feeds. If either user removed the other from their friends list, this link would instantly be broken both ways. You would stop following them, and they would stop following you.

Following, on the other hand, was unilateral: first of all, you didn’t have to send a request — by simply clicking the button, you would start seeing the user’s posts in your feed, but they would not be seeing yours. Moreover, they didn’t need to confirm anything; you could follow them without their express approval and thus the interaction was instantaneous.

This deconstruction of the fundamental interaction (one-way vs two-way) opened up different ways of thinking and working with these mechanics. Suddenly, viral accounts started popping up: they didn’t need to open a page anymore, but could use their personal account to garner followers. Users who made careers out of social media started encouraging people to follow them instead of friending them: it was easier to click follow than the “send a friend request” button, and this allowed some accounts to grow massively by encouraging the use of this interaction over “friending”. Facebook wasn’t just for your real-life friends anymore, but for building an audience and community.

Constraints are freeing, not limiting

Seeing constraints as promoting creativity makes all the difference already.

On MediaWiki for example, we have pages, templates, modules, plugins (made by third-parties) and magic words. I won’t explain what all of these are so that you can feel as lost as I was when starting out, but that’s basically all we have available to make anything new on the wiki, such as our new homepage or the essays blog format.

These components form our constraints. We can’t say “sure, let me just quickly code a Python script to do this” — it won’t work. We can’t use Python on MediaWiki. We can’t use anything that’s not supported by the software.

In other words, we have very real technological constraints that we are forced to operate under whenever we want to do something.

But what I want to convey is that those constraints are actually very freeing.

The problem with having too many options is paralysis. You’ve probably felt that at the restaurant before (or so I’m told, it’s honestly never happened to me!): when there are too many options, we don’t know what to pick or how to proceed. We don’t know what the right choice is supposed to be and fear making the wrong one.

Whereas if there’s only one choice, the decision is made for us: we have to order the menu of the day and that’s that. The constraint of having just one choice means that the solution is self-evident and very effective.

Over time and over working on this project, I started seeing constraints as freeing. Instead of losing sight of the problem and thinking about outlandish solutions, we keep ourselves grounded in reality by knowing that will be able to find a solution with the tools available to us simply because we have to. We don’t have the option of failing: if we can’t do it successfully the first time around, then we have to rethink the problem so that we can find another way to do it.

That’s a trick I didn’t mention: if there is no solution to a problem, then you have the wrong problem and you need to change it until there is a solution.

One example of creativity we displayed in the process of learning how to work with MediaWiki is that we realized pages (e.g. wiki pages which users read) are usually used to do this, but we can actually put whatever we want in them so we can technically do that with them as well (whatever this and that are). We deconstructed what a ‘page’ was for MediaWiki down to its most fundamental characteristics, and from there we were able to repurpose them to fit our specific needs and problems.

More practically, you might think of pages as displaying information on a topic, because this is how most Wikipedia pages look like. But at their most basic level, they’re just a unique and defined place to hold and display written information. We can use page to write on topics, but we can also use them to keep track of stuff, we can run code on them, we can even display an entire dynamic homepage with them. Once we became creative with MediaWiki pages, infinite possibilities opened up and our constraints were pushed back.

I want to leave you with this piece of wisdom. Back when I worked on websites, I had a client who gave me many problems. Eventually, we had to update his website because he got hacked. This wasn’t an easy feat: not all software is created equal, and this one was notoriously difficult to update. Of course, when we attempted the much-needed updates (there were many), everything went wrong and the website kept throwing errors our way. I was starting to panic; this wasn’t supposed to happen. What would the client say when I told him his website was destroyed? How were we even going to tell him?

My colleague at the time reframed it for me. He said, “don’t think like that. We have to find a solution; failure is just not an option.”

It was true. We had to find a solution to bring that website back online, we couldn’t say “welp, it’s bonked, let’s just delete it and tell the client they have to close down their business.” It took some more work, but we eventually did fix this client’s website.

So when times are tough, think of it like that: you have to find a solution. Failure is just not an option.

Let’s recap

1. Constraints exist within problems. There is bound to be at least one constraint in a problem, even if it’s not readily apparent.

2. Problems have a solution: if there is no solution, then there is no problem. This is always true.

3. Constraints promote creativity.

4. Creativity is the ability to deconstruct components down to their fundamental characteristics. This opens up new ways of repurposing these components in unintended but deliberate ways.

5. When problem-solving, take the time to write down the constraints applicable to your problem somewhere.

6. Working within constraints improves creative thinking. Creative thinking improves working more comfortably within constraints.

7. Constraints are ultimately freeing as they prevent having too many options to work with, forcing us to keep our sights on the problem.

All of my writing is freely accessible and made possible by the generosity of readers like you. If you enjoyed this essay, please consider supporting me. I’m on Ko-fi, Patreon, Liberapay.

Bitcoin (BTC SegWit network) - bc1qcdla40c3ptyrejvx0lvrenszy3kqsvq9e2yryh

Ethereum (Ethereum network) - 0xd982B96B4Ff31917d72E399460904e6F8a42f812

Litecoin (Litecoin network) - LPvx9z9JEcDvu5XLHnWreYp1En6ueuWxca

Upgrade your Substack subscription for $5/month or $50/year:

Share this article: