Design constraints are limitations on what designers can do with a design. These limitations are byproducts of having deadlines, budgets, brand guidelines (and similar guidelines), laws and regulations, finite resources, and limited deciding power in terms of tools and processes. On the surface, having design constraints can feel like a bad thing; however, they can actually be extremely useful.
In this article, we’ll look at the different types of design constraints and learn how to not just reframe them in a positive way but utilize them to produce better outcomes.
If we think about design constraints, the first thing that comes to mind is probably deadlines. Pretty much all projects have deadlines, even when it seems unnecessary. They’re rarely fun to have (anxiety-inducing, in fact) since they can make us feel as if we need to rush, leading to work of lesser quality.
Simply put, having a budget means having less money to spend, a difficult situation to be in considering that it takes money to make money (or so people say, anyway). So with less money to spend on tools, staff, and the like, it’s understandable that budgets make product teams a little nervous.
Also, due to day-to-day running costs, a smaller budget often means a tighter deadline since projects that run longer cost more.
Branding is important because it helps customers to understand who the business is as if it were a person, and branding helps customers to recognize the business in the future. One of the most crucial parts of a brand is its visual identity (its colors, fonts, and so on).
While I do love working on projects where the visual identity has already been crafted (it means less work for me to do), brand guidelines don’t always translate well to screens because brand designers sometimes lack expertise in app/web accessibility. Sometimes I have to start a project with, “Thanks for the guidelines that you sent over, but those colors/fonts/etc. don’t meet today’s accessibility standards, which you’re required to meet by law.”
Add this to the fact that you just might not like their branding/visual identity or agree that it’s the right message or look for them. The same could be said for other guidelines and requirements in general. Putting aside the fact that research is the be-all and end-all anyway, since neither us nor the business are the actual customers/users, the reality is that higher-ups sometimes make decisions that we have to accept, no matter how absurd they are.
Applicable laws and regulations can also limit the number of approaches that we’re able to take, especially when they concern accessibility or data protection. Designers rarely complain about this type of design constraint though, since inclusion and privacy is always a good thing, even if it requires more work.
There are several ways for the lack of infinite resources to impact the way that we go about solving problems. Putting aside money and bandwidth (which are technically resources) since we went over those already, it goes without saying that not having the right knowledge, skills, or tools can also be a frustrating design constraint to have.
In addition, if we consider the fact that we’re not actually solving problems as much as we’re helping people to solve their own problems, then we’re also constrained by their resources to do so. For instance, if their internet speeds were substandard, then we’d need to limit the use of heavy visual aesthetics such as images, videos, and fonts. Similarly, if their internet stability were unreliable, then synchronous communication would be the wrong approach for, say, a collaboration tool.
Sometimes, our idea of the perfect product relies on users living in a perfect world, which they might not be, making some features, designs, and/or approaches just not possible. We can only solve problems to the extent that design constraints allow us to.
Tools (e.g., design tools) and processes (e.g., product design frameworks) used aren’t always decided by the designers that use them. Sometimes they’re decided by a product manager who has to think about the efficiency of the overall product design workflow, which includes other stakeholders such as developers.
Sometimes they’re decided by a product owner, project manager, project sponsor, or even the client, any of which might need to impose strict budgets or deadlines. Also, clients might want you to use certain tools and/or processes because it’s what they know or what they’ve heard is best.
Other times you might be joining a team that’s already using a specific setup that they don’t want to change (either for good reasons, or for the same bad reasons mentioned above).
Think you might prefer unlimited freedom? Be careful what you wish for. Those without design constraints often say that having too many options leads to analysis paralysis, the inability to make decisions efficiently. Also, more options means more roads untraveled, leading to FOMO and what ifs.
Besides, being limited to certain choices doesn’t necessarily mean being limited to certain outcomes. Often enough there are alternative options that are, at least, almost as good as what you originally envisioned. In other words, don’t confuse design constraints with design restraints.
Let’s look at the different types of design constraints again, this time in a more positive way.
When it comes to deadlines, keep the pareto principle (sometimes referred to as the 80/20 rule) in mind. What the 80/20 rule means in a design context is that approximately 20 percent of the work put in determines how approximately 80 percent of the product turns out, meaning that time gained from not having a deadline isn’t likely to have much of an impact anyway. This might not seem true to a perfectionist and is definitely not a hard rule, but it’s something to keep in mind.
If you’re wondering if you should just ship it, yes, you probably should.
As exciting as it is to start a project with awesome tools sporting awesome features at our disposal, I’d argue that many of them require so much maintenance that they work against us. This is in addition to the hole that they burn in our pockets, which isn’t desirable considering that the primary outcome is to make those pockets heavier. Here are some costly mistakes that I see over and over again:
Keep it simple!
Starting a project knowing that the fonts/colors/etc. have already been picked out is truly a blessing — I wouldn’t write this design constraint off just yet. That being said, if something isn’t accessible or doesn’t fulfil an actual need, then you’ll need to open the lines of communication and explain that. Here’s a great approach that always works for me:
“There are a few things in the brand guidelines that are really incredible but need to be optimized for apps and websites. Would you be open to creating a design system? This would be similiar to the brand guidelines except that it would take our apps and websites into consideration too, resulting in a consistent visual identity across all forms of media.”
Laws and regulations don’t actually prevent us from doing anything. In fact, they require that we do more, such as including policies (e.g., privacy policies) and friction (e.g., cookie consent banners and marketing email opt-ins). Complying with laws and regulations obviously requires more work, but it’s also more user first, and that’s why we’re here, right?
Alternatively, consider designing in a way that said laws and regulations don’t apply (while still practicing ethical design, of course). For example, consider just avoiding cookies (many of them are unnecessary) and forgoing email lists (many of them are never used). As a designer, these things are probably out of your hands, but they’re definitely things that can be debated as a team.
Having (or users having) finite resources is probably my favorite design constraint because it forces designers to get creative; it makes the project challenging in a fun and exciting way. Also, being constrained to a limited number of possible approaches reduces analysis paralysis and anxiety in general, helping the project to chug along at a steadier, more predictable pace.
Having limited deciding power in terms of tools and processes can be a huge bummer, however, bad tools and processes usually reveal themselves pretty quickly. If not, detailing the negative ways that they’re impacting the product and/or business is often enough to convince those in control that a shake up is needed.
Some of the usual culprits include:
It’s important to voice these concerns if you believe that your productivity is being significantly reduced. However, if it’s more a case of things not being the way that you prefer them, then it’s probably best to just let it go and have everyone use x or do y.
Otherwise, you’ll just end up in the situation you’re trying to avoid where there are too many tools, disconnected workflows, endless notifications (but never the right ones), “did you see my message on x?”, “where’s the file?” — basically, collaboration hell. This isn’t a design constraint to avoid or embrace, it’s just about moving the goalposts so that everyone can score (be productive).
All-in-all, design constraints aren’t so bad. They only appear to be bad on the surface because it’s human nature to want what we can’t have. The way that I get through this is to think of the upsides first:
If you have any other pros or cons to add, feel free to do so in the comment section below, and thanks for reading!
Header image source: IconScout
LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Nostalgia-driven aesthetics is a real thing. In this blog, I talk all about 90s website designs — from grunge-inspired typography to quirky GIFs and clashing colors — and what you can learn from them.
You’ll need to read this blog through and through to know what’s working and what’s not in your design. In this one, I break down key performance metrics like task error rates and system performance.
Users see a product; designers see layers. The 5 UX design layers — strategy, scope, structure, skeleton, and surface — help build UIs step by step.
This blog’s all about learning to set up, manage, and use design tokens in design system — all to enable scalable, consistent, and efficient collaboration between designers and developers.
Learn more →
