“If you don’t want to work within constraints, become an artist.” That is what one of my design lecturers told me when I was at university back when the web wasn’t even a thing.
That has turned out to be one of the most useful pieces of advice I ever received in my career and has led me to embrace and even enjoy working within constraints, which probably explains why I tend to specialize in highly regulated sectors with enormous amounts of stakeholders and legacy.
So, if you find working within constraints challenging, this is the post for you. In it, I hope to change your attitude towards constraints and provide practical ways of dealing with even the most frustrating barriers.
But let’s begin by looking at the kind of constraints you could find yourself facing.
Constraints On Every Side
The constraints we face come in all shapes and sizes, from technical constraints due to legacy technology or backwards compatibility to legal constraints relating to compliance requirements or accessibility.
Then there can be inadequate availability of images, video, and text or simply a lack of access to stakeholders.
However, the biggest two, without a doubt, are a lack of time and a lack of resources (either money or people). In fact, it is rare to encounter a project where somebody is not in a hurry, and you have enough resources to do the job properly!
It is easy to let all of these obstacles demoralize you, but I would encourage you to embrace, rather than resist, their constraints.
Why You Should Embrace Your Constraints
Constraints are not a set of necessary evils we have to endure. Instead, they are the core of what shapes the work we do.
- Constraints provide a clear set of guidelines and limitations, which can help focus the design process and prevent scope creep.
- Constraints help to build trust with clients or stakeholders, as they can see that the designer is able to work within their limitations and still deliver a high-quality product.
- But most importantly of all, constraints can lead to more creative and innovative solutions, as designers are forced to think creatively within the given limitations.
I have done some of my best work over the years precisely because of the constraints placed upon me, not despite them.
Also, some constraints are a good idea. Ensuring a site is accessible just makes sense, as does limiting the time and money an organization is willing to invest.
Not that you should blindly accept every constraint placed upon you.
Know When To Push Back Against Constraints
Unsurprisingly, I would encourage you to challenge constraints that are based on incorrect assumptions or outdated information. However, you won’t come across those that frequently.
More common are constraints that make sense from “a certain point of view.” However, these kinds of constraints are not always right within the context of the project and its long-term objectives.
For example, attempting to deliver a project within a strict budget and on an aggressive schedule may reduce the cost to the organization. But it will substantially increase the risk of the project failing, and so ultimately, the money and time that were spent will be wasted.
Another common example is compliance constraints. These constraints exist to protect the organization from possible risk, but many larger organizations become so risk-averse that they undermine their competitiveness in the market. They swap one type of risk for another.
The key in these situations is to demonstrate the cost of any constraint placed upon you.
Demonstrating The Cost Of An Unhealthy Constraint
Often, those who impose constraints upon you do not see the problems these constraints create. This is usually because they are only thinking in terms of their own area of responsibility. For example, a compliance officer is only going to be thinking about compliance and not the broader user experience. Equally, the IT department is going to be more focused on security and privacy than conversion or usability.
Ultimately the decision of whether to enforce a constraint or not comes down to balancing multiple factors. Therefore, what you need to do is
You can demonstrate the cost in one of three ways. You can either focus on the damage that a constraint causes, the cost of not taking an action the constraint prevents, or the lost opportunities imposed by the constraint.
Let’s look at each to help you see more clearly how this can work.
Highlight The Hidden Damage Of A Constraint
I once worked for a consumer electronics company. One of their biggest sellers was a kettle that included a water filter which prevented limescale build-up (I know, I work on the most exciting projects!)
The company insisted that when somebody added the kettle to their shopping cart, we should automatically add a set of water filters as well.
This is a well-known dark pattern that damages the user experience, but I also knew that it was increasing the average order value, a key metric the e-commerce team tracked.
To combat this constraint, I knew I had to demonstrate that it was causing damage that the e-commerce team and leadership were unaware of. So, I took the following steps:
- I gathered evidence on social media of users complaining about this issue.
- I contacted the customer support team to get some metrics about the number of complaints.
- I contacted the returns team to find out how many people returned the filters.
- I looked on review sites to see the number of negative reviews relating to filters.
Sure enough, I found substantial evidence that this was a major issue among consumers. But I didn’t stop there. I wanted to associate a financial cost with the decision, so I made some estimates:
- I made my best guess at the cost of combating the negative reviews, referencing various sources I found online.
- I researched the average cost of dealing with a complaint and combined it with the data from the customer services team to guess the overall cost of dealing with filter complaints.
- I used a similar approach to work out an approximate cost of processing returned filters.
Now, let me be clear, these were nothing more than guesses on my part. My figures were not accurate, and people in the company were quick to challenge them. But associating a dollar value with the problem got their attention!
I agreed that my figures were probably wildly off and suggested we did some proper research to find out the real cost.
You don’t need hard data to demonstrate there is a problem. An educated guess is good enough to start a discussion.
Of course, not all constraints are actively causing damage. Some are merely preventing some better action from being taken. In these cases, you need a different approach.
Focus On The Cost Of Inaction
Over time, an organization establishes processes and procedures that have been proven to work for them. The bigger the organization, the more standard operating procedures they have, and the more constraints you encounter.
Well-established companies become so afraid of losing their position that they become extremely risk-averse, and so place considerable constraints on any project.
People succeed in organizations like this by doing what has been done before. This can be problematic for those of us who work in digital because most of what we are trying to do is new.
To combat this bias towards the status quo, we need to demonstrate the cost of inaction. Put another way, we need to show management that if they do not do things differently, it will threaten the market position the organization has established.
In most cases, the best approach is to focus on the competition. Do a bit of research and show that the competition is less risk-averse and gaining market share as a result. Keep mentioning how they are doing things differently and how that threatens your organization’s market position.
Another tactic is to demonstrate how customer expectations have changed and that if the company does not act, they will begin to lose market share.
This is particularly easy to do because users’ expectations regarding digital have skyrocketed in recent years.
“The last best experience that anyone has anywhere becomes the minimum expectation for the experiences they want everywhere.”
— Bridget van Kranlingen, Senior Vice President of IBM Global Markets
Put another way, users are comparing your organization’s subpar digital experience to the very best of what they are interacting with online, even when that comparison is not fair.
A bit of user research goes a long way in this regard. For example, consider running a system usability scale survey to compare your digital platforms to this industry benchmark. Alternatively, run a survey asking how important the digital experience is to customers.
While fear of losing market share is a big motivator to well-established businesses, younger, hungrier businesses tend to be more motivated by lost opportunities.
Demonstrate Lost Opportunities
Your management, stakeholders, and colleagues often do not realize what they are missing out on because of the constraints they place upon you. It, therefore, falls to you to demonstrate those opportunities.
Sometimes, you can make this case with analytics. For example, recently, I was working with a client who insisted on having a pricing page on their website, despite the fact the page showed no pricing! Instead, the page had a request pricing form.
They wanted to keep the page because they were afraid to lose the handful of leads that came via the page. However, I was able to convince them otherwise by pointing out that the page was actively alienating the majority of users who visited it, effectively losing them leads.
I did this by demonstrating the page had a higher bounce rate than any other page on the site, was the most common exit page, and had the lowest dwell time.
But analytics is not my favorite approach for demonstrating lost opportunities. Instead, I typically turn to prototyping.
I use this approach all the time. Imagine, for example, that you have been told that a particular technology stack imposes a set of restrictive constraints on how an interface is designed. By prototyping what the interface could be if you were free from those constraints, you can make a powerful case for changing the technology stack.
Having a prototype gives you something to test against. You can use usability testing to provide hard evidence of how much it improves the user experience, findability, and even conversion.
Even more significantly, a prototype will excite internal stakeholders. If your prototype is compelling enough, they will want that solution, and that changes the conversation.
Instead of you having to justify why the IT stack needs to be changed, now the IT team has to justify why their IT stack cannot accommodate your solution. Stakeholders and management will want to know why they cannot have what they have fallen in love with.
Of course, people will not always fall in love with your prototype, and ultimately, many of your attempts to overcome constraints will fail despite your best efforts, and you need to accept that.
Conceding Defeat With Grace
Let’s be clear. It is your job to demonstrate to management or clients that a constraint placed upon you is unhealthy. They cannot be expected to know instinctively. They do not have your perspective on the project and so cannot see what you see.
This means that if they fail to remove the constraint you consider unhealthy, it is your failing to demonstrate the problem, not their fault.
Sure, you might consider them shortsighted or naive. But ultimately, you failed to make your case.
Also, it is important to note that you don’t always have the whole picture. A decision may be bad from a user experience perspective, for example, but it may be the right thing for the business. There will always be other factors at play that you are unaware of.
So when you fail to make your case, accept that with grace and do your best to work within the constraints given to you.
Ultimately your working relationship with management, colleagues, and clients is more important than your professional pride and getting your way.
(vf, yk, il)