Recently, the engineer on a dev team I work with sent out an article that talked about how design and development teams should constrain the users to save time and money. Sounds like an interesting topic of discussion. Here are my thoughts, for what it’s worth. 🙂
When we don’t constrain the users
Constraining the user–in other words intentionally define what, how, and when an inputs can be entered by the user–is a pretty ubiquitous (love sing that word) concept. In fact, here is a uxmatters.com article if you want to dive deeper later. The concept is literally all over the place. To design an appropriate constraint is a design best practice. The user experience situation that comes about when we aren’t diligent in blocking inappropriate inputs is that some users can become lost, disoriented, and confused. They may even be led to wrongly enter information, resulting in problems that are maybe 2 or 3 task into the future without even realizing it. Hopefully we’ve provided them with some way of recovering in those situations, but I imagine that we often forget.
Constrain the users, not the design and dev
If a design/dev team is spending time “fixing” corrupted data, then it’s likely we have fallen into piecemeal program land. Taking unsystematic or partial measures to resolve a rampant/unchecked situation like this just binds everyone’s availability up exponentially further. After we now take a brief awkward silent moment, I hope you realize that the dev/design team is now constrained. How’s that for some pie in your face!
Where does it start?
Designers are constantly talking about pattern libraries, design systems, and styleguides. You, the designer should know that it is you who are charged with being most aware of our best practices. When everyone’s given 8 hours to work, you likely spend your 8 hours learning and practicing design… not necessarily practicing meetings. Further, you aren’t likely spending your 8 hours trying to put on the hat of a developer. And yet, I think we’ve all seen both sides attempt to assert themselves as being smarter than the other. Ughh… the finger pointing blame game. Oh so fun.
Design a plan on how you want to constrain the users
The design decision. A plan to overcome a piecemeal approach to constraints… Probably needs to be born by the design team, approved by the decision maker, and implemented–to the tee–by the dev team. Full support from all. If the designer (who’s supposed to keep up and champion design best practices and concepts such as this) is being pulled in AFTER the design decision is being made, then knowing and adhering to design best practices falls on the decision maker. What a heavy weight to carry the job duties of someone else’s expertise. For that very obvious reason, many organizations place the UX team next to the marketing team on the business side.
So, how do we turn this ship around? Talk to users, other designers and developers. Fight the battle to get yourself at the decision makers table. Managers, you too should fight for your designers to be at these tables with full access to talk. Information blocking is the biggest power struggle I see daily. There needs to be an understanding of the fundamental concept that we aren’t better at the other teams job and they aren’t better at ours. If we respect each other’s roles, and understand each others goals, we will be in good shape to starting down the right path. Good luck.
Designers, developers, and strategists will say more on this topic. Especially on the topic of strategic placement of a UX or design team. The team I work on today was born on the IT side, so trust me when I say I have some credibility on this topic. I know how it feels to have my hands bound to a decision that is made without my research or design input. So, I encourage you to keep up the good fight. We win some of the battles, and logic will prevail!!! 🙂