How you can use “seeing is believing” to challenge poor requirements
User testing is a powerful tool for challenging arbitrary project constraints
Few things are as frustrating as arbitrary constraints that prevent you from implementing an easy design solution.
As UX Designers, we may have gotten used to swapping stories about nightmare clients, where you had to design with some truly awful constraints. Still, I never thought that voicing concerns about arbitrary constraints might ever change anything until recently.
For my project, nobody could understand why the default list was sorted the way it was in multiple tables of names. Furthermore, it didn't follow any typical ordering pattern, such as by alphabetical last name or office district.
Instead, tables just defaulted to a jumble of data values, resulting in nearly every user's extra (and automated) click to sort the table every time the page refreshed. But what was strange was that nobody could immediately tell me why this was: this had just been accepted as something that tables did. It took some digging (and a helpful developer) to realize that these tables were being sorted by some hidden identifier generated when the users submitted a form.
It didn't take much effort or convincing to change the form to be sorted by the last name, but if I hadn't pressed that point, I'm pretty sure that tables would stay in their messed up sorting format: it was a small enough issue that we would have ignored it, but it existed for no reason.
This example is why learning to challenge constraints can be an essential skill for many Designers to learn.
I'm not a person who likes confrontation, so I understand if you may be reluctant to spend time challenging the requirements that the business puts forth. But one of the best ways to convince you that this is necessary is to phrase constraints in a way that makes you stop and think: "We've always done it this way."
The danger of "We've always done it this way."
When you hear that phrase, what's your first instinct as a UX practitioner? Then, of course, we immediately hone in on this as something that we should dig deeper into for many of us.
After all, UX is a somewhat new field, and a lot of work that we do challenges organizational thinking while advocating for our users. As a result, some of you have heard this phrase more than others.
https://nationalcioreview.com/leadership/weve-always-done-it-this-way/
So why wouldn't we take the same approach when we're faced with a constraint?
I get it, though: sometimes you're a freelancer working for a big client, or you're a junior designer not trying to rock the boat in a large organization. As a result, it feels like when you're given a constraint, you can do absolutely nothing.
Except that's not entirely true: you can ask why something is the way that it is. Even if you don't intend to change anything, asking your stakeholders to explicitly spell out why things are the way they are might influence your organization. Sometimes, when people don't know why things are the way they are, they might be willing to do away with the constraint.
In addition, understanding where the constraint is coming from can also help you know whether it's worth challenging or not.
Sometimes, the constraint comes from a genuine place: for example, if the database structure can't handle the type of design interaction you're proposing or some other valid issue.
This type of thing can be particularly true with legal or organizational policy. Sometimes, the threat of linking systems with Personally Identifiable Information (PII) with public-facing ones means that they can't implement your well-intentioned design suggestion. Sometimes, it just comes from a client's desire, which means that it's also hard to challenge: If your client likes blue and wants everything blue (and also his logo is blue), then that may be what you have to do.
However, that doesn't mean that's always the case. Sometimes, what you're battling is inertia. It's been done this way for a long time, so why not design in this way? But before you challenge everything that looks strange, ask yourself one question is this constraint going to make designing a solution more complicated (or even impossible)?
Understanding when to challenge arbitrary constraints
When Gerry Gaffney, Director at Information & Design Australia, took on a project with a client to re-design a form, he faced two constraints that the client had established a while ago: the form needed to be fax-able and fit on two pages.
Both of these constraints seemed to make his job impossible: the sheer amount of information and fields required made it so that this constraint hampered his ability to complete a more usable form. These constraints came out of a time when faxing was commonplace and had just stuck around.
After fighting back against the constraint, he was allowed to test a new design consisting of six pages. Once he got user feedback, it turned out that the users liked the organization of the form and didn't have any problems with its length.
This is not an uncommon situation: the company created many of these constraints to simplify things for users. As a result, hearing the user's voice a contrary opinion can help break them out of holding on to this constraint. So the first step is to understand if a constraint is arbitrary or not.
There tend to be four major categories of constraints that pop up, and your ability to influence them varies depending on what type of constraint this is:
Design Constraints:
These are most likely very arbitrary, but sometimes clients are quite strong-willed in the decisions around them. It may be helpful to point at UX best practices to try and make sure that you're not causing a lot of problems.
You may also want to push to create a brand or style guide to capture these constraints for future reference explicitly. However, some clients may not be thrilled to capture down their design preferences on a style sheet and instead may be willing to negotiate at that point.
Database constraints:
This constraint can often be brought up when developing forms, data entry, or other interactions like propagating info. As such, addressing these constraints usually involves an in-depth session sitting down with your engineering or developer team and a product owner/manager to understand the issues faced.
Developers are hopefully able to explain, in simple terms, why what you're proposing is facing problems, if not how the database is structured. However, one thing to remember is that we are designing something easy for users, not for databases.
As a result, while we understand there may be technical constraints, we also want to emphasize that we should seek solutions prioritizing the users. Having a Product owner or manager at these meetings will also probably help you with this process.
Marketing constraints:
While a little old-fashioned, sometimes you'll run into constraints based around the idea that "Marketing Research is the same as UX Research."
As a result, sometimes, there are views from the marketing department (like organizational standards or marketing personas instead of design personas) that may act as constraints. Often, the constraints they wish to impose may either be outdated or not relevant to our subset of users. As a result, it may be best to seek out more user research and data to help provide an updated, UX-centric view on how things are.
This may involve interviews, surveys, analytics, or any number of sources.
Organizational/Project owner constraints:
Lastly, and most importantly, are constraints that come from the Project Owner or Manager. Some of these are tied into legal and organizational constraints that I mentioned earlier, where there's little else but to get creative with your designs. But sometimes, there isn't any reason for the constraints, except that "We've always done things this way."
This is what you should always be on the lookout for. If it seems like an arbitrary constraint, you should seek out a UX advocate within your organization to help drive user test. These might be executives that see the value of UX, people at the support or help desk, or other project executives that your team interacts with.
Because, for the most part, all you need to do is get resources and permission to run a user test.
Seeing is believing: the high-impact user test.
We all know that inviting stakeholders to user testing is one of the most potent ways to change their minds about a design.
As soon as they see, for example, how much a design improves a user's performance, we may persuade them much more manageable than several back-and-forth meetings about the subject.This means it's also an ideal place to challenge constraints that you find arbitrary. But this shouldn't be a process you struggle through every week with your projects: all you need to do is get permission to get to the user testing phase.
Suppose you can get your team to observe users with no problem without the arbitrary constraint (or have an alternate design with the constraint that users find frustrating). In that case, that may be the critical point to convince your team that perhaps this constraint is unnecessary.
But to have that happen, that means you have to be right about what you believe. If you're challenging constraints with a user test, sometimes you might have to fund the studies out of your pocket, or you might have to reach beyond your immediate team to get approval.
If you try to challenge the constraints with a different design, but it turns out that your team was right all along, you can damage future interactions and the credibility of user research.
This is why challenging these constraints should only come when you're confident that getting rid of them would create a better user experience.
Fortunately, with iterative design testing as well as user interviews, you can often find these answers directly from our users: if they're complaining about something seeming arbitrary, frustrating, and otherwise useless, then perhaps you have a case to stand on there.
In addition, they often have a greater understanding of how systems interact with one another and have a solid workflow that either utilizes the business process or works around it. But even if you have to work with constraints, it's not the end of the world.
Constraints drive creativity
Some of my most creative design solutions came from working with what seemed like arbitrary (but necessary) design constraints.
It's not the end of the world if you design with several limitations: intelligent constraints drive creativity. However, these projects can sometimes be the best places to flex your design muscles, as solutions you would otherwise have not considered become viable.
But that doesn't mean that you should accept every constraint you're given without thinking: often, these constraints come from arbitrary places and will only worsen your design. So if you want to make sure that you're not making design decisions on arbitrary constraints, take a moment and dig deeper.
These things can help you understand if you're designing something that best fits both the business and the user.
Kai Wong is a UX Specialist, Author, and Data Visualization advocate. His latest book, Data Persuasion, talks about learning Data Visualization from a Designer’s perspective and how UX can benefit Data Visualization.