The Language Map

It’s often all there in your mind and on the screen, but somehow gets lost in translation…

Photo by Uday Mittal on Unsplash

As a Product Designer, I have encountered multiple occasions on which, despite having a workable, optimal solution, I was unable to explain its viability to my team of product owners, business analysts and project managers. Many-a-times, after a few rounds of feedback from business and users, my team realised that viability of which I failed to convince them. It used to leave me feeling helpless and frustrated.

It took me months to realise that I wasn’t lacking in resolution, execution or even design thinking. Nor were my communication skills betraying me. It was actually my choice of jargon and construction of pitches that was failing me. My innocuous premises that so tightly wrapped my solutions with the reasoning I deemed best, deriving from my knowledge of the theory of design, fell short in practice.

In other words, I was not speaking the language that product owners, business analysts and project managers understood. We as UX designers believe in showing rather than explaining, and assume that people will be able to understand our vision. That is not true; it is important to know that design-related conversations in cross-functional teams need to be low-context.

That’s when I began mapping business language to design solutions. Instead of simply justifying UI solutions with proven UX laws, I explained how the proposed solution can benefit the business. I thus realised the power of explicit verbal communication, supportive research and rapid user-testing through my experience of working in a cross-functional team.

Here are some of the methodologies that you as a UX designer can employ to support your solutions-

Tie design solutions to KPIs-

KPIs or Key Performance Indicators are the driving forces behind business decisions. If your design solutions address one or more of the general business KPIs, it would definitely be much easier to convince your product owner to adopt them.

Let us take an example- say you are designing a fraudulent transaction resolution feature for a fintech platform, and you decide to add a text area input for the customer to explain their issue. As a designer, you know that a free text input in conjunction with a document uploader will help shorten the user journey to raise a ticket for fraud resolution. Additionally, it will also help mitigate frustration in a state of panic by increasing the sense of control for the user.

This is how you can explain this solution to the product owner- This small addition helps to reduce the company’s ‘Cost per resolution’, because it saves the cost and time required for a customer support representative to call the customer and understand the exact problem. This action, multiplied several times for millions of customers, will save the company a lot of expenses in dispute resolution.

Explanations like these require a little bit of generic business operational knowledge, and a bit of google search for the exact terminology. With practice, these terminologies will be embedded in your mind map to be readily used.

Support your solutions with benchmarking-

Nothing supports design solutions more strongly than solid benchmarking. Competition is crucial for businesses. Thus, if your design solutions either align with competitors’ solutions or better, have an edge over the competition, they are bound to fly with business stakeholders.

Product requirements usually stem from two streams- business goals and competition. When a product owner approaches you with business requirements for a new feature or service improvement, know that they are based on some market and competitive research. Try to extract this information with the right questions to know where to begin benchmarking- whether to study a competitor’s product or conduct aspirational benchmarking. Sometimes the ‘5 why’ questions help to get to the core reason behind a particular feature requirement.

As a general rule, know the business’s primary competitors- explore their products. Try to stay up-to-date with the latest news and customer reviews from App Store and Google Play Store. This will help you to reduce the time that you would require for benchmarking.

Conduct guerrilla testing-

This is a double-edged sword, in the sense that it readily either validates your solution or dismisses it, thus rendering instant feedback for your designs. Business stakeholders thrive on active feedback. Thus, feedback from people other than yourself or your design team can help assure the product owner of the viability of your solution.

You can involve your colleagues working on other areas of the project or other projects altogether, your friends, family, or even members from your social circle and LinkedIn community for guerrilla testing. It can be accomplished by a simple screen-series or prototype demo and gaining their feedback through open-ended questions/random poll. Avoid including people who may have a biased outlook towards the project, like other stakeholders or designers in your own team.

It is of course important to know here that rapid user-testing is not a fool-proof method to test the credibility of design. Every feature implementation will have to be thoroughly tested within CUGs before a full-blown market launch. Therefore, be ready for any future iterations and changes despite receiving a positive feedback from rapid user-testing/guerrilla testing.

Most of these methodologies require one to step outside one’s scope of work- you may be a UI designer whose core focus may not be user research or benchmarking. Nevertheless, take that extra step, because a short detour can potentially set you miles ahead in your design delivery. With these methodologies, you can elevate your pitch to eliminate discipline-related language barriers and effectively communicate with business stakeholders in high-context.

I would love to know your thoughts about these methodologies and any other methodologies that you find beneficial in your day-to-day interactions with your cross-functional teams. I would also be open for discussions around process design, product strategy, business innovation and UX design in general.

If you like this article, please acknowledge with a clap or two. Also feel free to comment your thoughts and critiques!