Understanding four business terms can help you out of sticky design situations
It's essential to understand business needs as well as user needs
I never knew how much I would learn about doing business (or how crucial it would be) when I started my UX career.
I first got my taste of business when learning about Data-Informed UX Design, but it's since expanded to several topics. From learning about Project Management Dashboards to understanding metrics, I've found myself understanding more of the business side to get stakeholder buy-in for my ideas.
But you don't have to have an MBA to be a good designer. You only need to understand the 'business' language a little because that's a language that most of your team might know.
Business is a (mainly) universal language that teams know
There is a straightforward reason to know a little about business terms: design projects are, in essence, a series of decisions made by the team. This is why design communication is essential: you might have the perfect design, but if your team doesn't understand why it's designed that way, they might decide to take another approach.
In addition, not everyone might speak "Design": they might not know the difference between mockups and prototypes or understand the point of testing with five users.
This is why learning to speak in Business terms can be so effective: a lot of the team may understand the business side better or at least understand design recommendations aren't just because the designer feels a certain way.
So here are four business terms that you should know that can help you get out of 2 everyday sticky situations.
"Scope/MVP": A way to politely decline adding a new feature
Sometimes, you might have a C-level executive say, "X sounds like a great idea/feature. Why don't we implement it?"
It's tough to talk back to your bosses' boss, but fortunately, we can easily rely on two business terms: scope and MVP (Minimal Viable Product). When projects are created, project managers and the rest of the team establish the project's scope and what they're trying to accomplish. They’ll then choose a set of features within the scope to build as a Minimal Viable Product (MVP) that has the essential features necessary to push it out the door.
However, because this happens at the beginning of the project, people might forget about this and add new features (otherwise known as "Scope Creep"). This is usually when the project manager should step in and stop things, but that doesn't always happen.
In those cases, you should be the one to speak out. Why? You're one of the first to touch the new feature by sketching/designing it. This is when you can intervene in several ways.
Ways to use these concepts:
Send a response stating, "I'm not sure this might fit into our MVP, but it sounds like a great idea for version 2 of the product."
Send a response stating, "Is this within the scope of the current sprint/timeline?" If you're working within Agile, you can also mention the effort level/amount of hours you expect implementing this feature might take.
Ask the team how to prioritize this new feature. Many teams use MoSCoW prioritization (Must have, Should Have, Could Have, Won't Have), with only certain features being included in the MVP. People might object to this feature being a Must Have.
This way, you're politely declining to invest a lot of time and effort into a feature that won't be useful to users. But sometimes, you might want to do the opposite.
"ROI/UX KPIs": A way to justify costly changes that are good for users
Sometimes, you might find valuable usability changes that require time, effort, and resources. The most common example is when you think it's better to re-design a particular feature instead of band-aid fixes to the current design.
In these cases, you need to consider what's the best argument for this. Sometimes, your team might understand enough about design to be persuaded through design arguments (like user satisfaction or frustration). However, that's only sometimes the case.
This is where you can take a page from the business playbook and consider talking about things they care about: Return on Investment (ROI) and Key Performance Indicators (KPIs).
I've written an entire book on this topic, but in simple terms, there are two basic ways of doing this:
Find specific poor metrics and test solutions: Whether through Google Analytics or other sources, you want to keep an eye out for poor metrics your team cares about. When you find them, consider user-centric solutions that might fix them, and user-test your solutions to see if you can make a case for fixing a metric.
Make a case for the ROI of usability: This is a little broader in scope, but several resources mention the ROI of usability (~83% improvement), especially regarding valuable business metrics like conversation rate. In addition, pointing out how your design recommendations improve usability and likely will affect the bottom line may work.
In either case, understanding a few UX KPIs that are related to this might also help you in making these cases, such as:
Task Success Rate
User Error Rate
Search vs. Navigation
etc.
Learning to talk with the business in these terms can help you make more compelling points.
Making a connection with the business
When I started my design career, I was all about the users (and you might be too). I wanted to take a user-led approach, wanted to work for user-centric companies, and would always advocate for users.
This caused me to run headfirst into trouble, as businesses often had needs I wasn’t fully seeing. As a result, I've learned a bit about business practices and motivations to understand where stakeholders may be coming from.
I don't need to advocate for the business: I'm still (primarily) a user advocate as a Senior UX Designer. But learning about terms that the business understands, and explaining them in those terms, can help them empathize with your design recommendations.
So if you ever find yourself in either of these sticky situations, consider learning a little about these terms (and using them in your responses). That might be a more practical approach to get businesses to understand your (and the user's) perspective.
Want to become a UX professional? I’ve written a free e-book explaining how to make yourself an ideal UX candidate.
Kai Wong is a Senior Product Designer and a top Design Writer on Medium. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.