Interview with Praneet Koppula - UX Manager at MathWorks

Praneet Koppula, UX Manager at MathWorks, sat down with us over coffee (virtually) and talked to us about his journey from being an engineer to a designer, how to ace a design interview and more!

1. On setting a framework of UX Leadership

When I could bring people together, there was a lot of work to be done. I was the first UX person and that company and I were going in from an organization, which had only designers. Going to a company where you’re the sole designer with 7,000 other employees, nobody understood what you were saying. Which meant you needed to bring in more people along with you, either as designers or as non-designers. If you have to be successful on a project, it’s not about what you do, but it’s about if the other people understand what you’re doing. I was very naïve in my very first meeting, I called a few product managers and said, “Hey, I’m a UX specialist now, let’s talk about your products and how we can improve them. And they were like, “What do you mean?” You guys hired me, I’m here for a reason.

When you get into a leadership role or being a lead in any sort of project, that hits you. You wonder, “what is my role here?”. My role is not to go draw pretty pictures or draw lines and communicate these ideas. My role is to bring these people along the journey in the design process.

And that was a big learning for me. It felt like moving to a country where I don’t speak their language. And one week into my move there people are like, “What do you mean by UX? My products are very successful. We are the leading company in the country. So why do we need to improve any of this?” Six months down the line, I had product managers waiting for my time asking me to come along for meetings.

My entire journey over there, I was teaching other people, even the designers, maybe not as much. I bank on other people in my team to help design, help teach the UX skills needed. I think that is the key thing that helped with junior folks on my team even now is “How do you bring along your cross-functional teams, along with you understanding what you’re doing and why is it important?” because the success of your project depends on when everybody believes in the same thing.

You could design something in a silo and it probably is the best idea on the best interface that anybody has ever designed in the world for that use case, however, it will not get shipped unless people around you believe in you and believe in the process you’re doing to come up with this idea.

As a group of people, maybe the thing that your design is not a hundred percent perfect, but it will be the best thing that will get shipped. It’s not just about designing, it’s also about how do you get this out into the market and how do you bring people along with you, on that journey to understand what are the good practices of design by making the right choices.

Over a period, people started treating me as an expert. “Why don’t I just come to you? You tell me whether this is okay”. I always said no, as I never wanted to be a gatekeeper. As UX designers, we should uphold the values of user experience and customer experience, but not really a gatekeeper on shipping things. If the organization treats you as a gatekeeper, they always come to you or the teams will optimize ways of getting approval from you.

2. Advice to Junior designers who are struggling to get their voices heard

When I interview people in the US or in India, the most successful people or the most evolved designers, irrespective of that experience are the people who went through some of these same experiences. This is somebody else’s story. They’ve shared with me saying that they’ve joined a small team as their first designer in the team. Their biggest learning from working with the team was that the first few months they went off designing something because they didn’t want to get influenced by existing ideas in the team. And that was their biggest failure. They’d present designs without the team knowing about what they were working on, so they weren’t able to inform them about constraints or any other problems.

Today’s design is more appreciated, at least on paper. But when the rubber hits the road, it’s still cross-functional teams trying to work with each other. And they’re all experts at what they’re doing. If I, as a designer, go to this team and say, “Hey, I’ve understood the problems that your interface has, and here is how you solve it; it’s backed by all this research. It is backed by all the best principles and best practices. And I’ve taken inspiration from all these impressive designs that are on Dribbble.”

And people could still show you why it may still not work. A person from marketing or product will point out why it won’t work. But if you work with these people from the start and do same the things that you as a designer would do, and you also incorporate the technical feasibility and business viability into that process, “here’s a reason my front end engineer can’t make this happen and what’s the alternative” and then you iterate it. That knowledge would improve your design process and put you in a better position than where you were before.

3. On processes

When I talk to junior designers, they’re not afraid of their craft. Today a lot of UX design is accepted. The conversation is changing where they’re not asking me about “how do I learn about this? How do I go learn about this tool or this process?“, instead they’re asking me “How do I be successful? How do I make sure my idea sellsHow do I make sure my design works in this context? Why is it that this team is not as excited as I am about this solution?”

The process of how design is integrated into software processes is still taking a lot of time. So when I’m talking to any engineer, they’d be like, Oh, we follow this agile methodology. This is how we ship code. You talk to 10 designers, I’m sure you will not hear the same design process at that organization because there are no standardizations on how design works at a company. Every company is different. They all figured out how to make it work at that company.

You could take an engineer out and have them work in a new setting and they’d probably get used to that; irrespective of what tooling they use, they’ll get used to it much quicker than a designer. If you take a designer out and put them in a new organization, they’ll take a much longer time to get used to that organization setting, on how is design accepted at that company, etc.

So I think for a junior designer who’s getting into that senior role or a lead role, listening skills become very important for them to understand, because if you need to get a design to this new framework, it’s not just what’s written on a process document, but it’s also about how people work at that company.

You need to listen to them; you need to understand them to influence them and bring them along with you on your journey, on the design process. It’s both communication skills of listening and influencing that play an important part. And then the other big piece is, we’ve always talked about UX people as the people who are ensuring our end customers are having a delightful experience, so we need to bring those customer stories back to the company or the teams we’re working in.

How effectively can you do that? Can you influence your teams in a way that they see the pain that you saw that your users were facing? How can you effectively tell those stories to your teams?

That transition from a junior to a senior or a lead designer is not so much about what design processes, design tools or methods that you use. It’s the non-designer skills like your listening skills, selling and negotiating your idea, that designers have to learn and pick up really quick to be a successful lead or with a bigger design team.

4. On skills that designers need to have

Learning how to negotiate: There’s a misconception around negotiation where people believe it’s about you entering a conversation and you’re winning it. You’re not just selling your idea, you’re actually making something much better.

The key to negotiation is actively seeking a happy medium. And that doesn’t happen naturally for people. They’re thinking, I’m going into this conversation, my job is to make sure everybody is aligned with my idea. That never happens. And it leads to a lot of heartache and disappointment and frustration at the end of this process.

However, if you enter these conversations saying “Here’s an idea, how do I make this better and ship this?”. Your idea itself might get transformed, but you were the catalyst as the designer to get to that end state. You’re basically applying all your design skills in a non-design context. That’s how you become a catalyst and make sure you’re shipping better design. You’re stopping the bad choices. It’s not about good design, but it’s about stopping the bad choices by a set of people, so you get a better design at the end of that project.

5. On the design process at MathWorks

One reason I enjoy working at MathWorks is that the process is not set in stone. We don’t have rules or guidelines. We have the best practices in everything that we do. How do you have a successful product? Here are the 13 habits of highly successful teams at MathWorks. The number one habit, or that a team starts with understanding the users and their goals. This is what all developers, engineers, product people, everybody goes through initial orientation training irrespective of the team you join.

The number one best practice is to always think about who your user is and what is their goal. Then we can figure out how your product or your feature fits into achieving that goal for the user.

Even before UX existed at MathWorks for close to 20 years, they were very customer-driven.  When the first product came out, their response was taking in the feedback of the customers and working on that. So their customer focus and oriented-ness is embedded into the DNA of MathWorks and the culture. In fact, there were product teams where I worked with, where I was not the one who had the most customer interaction.

In that context, our role as UX people at MathWorks is to start any project by asking this question, “Who are we doing for? We know the motivation for this feature, but who’s going to use this. Why would they use us? What’s their end goal?”Then let’s see whether our motivation for working on this feature or the product fits that end goal for the user. Maybe we have existing information or we understand the problems. We understand the pain points. Or maybe we should invest some time to go figure out what those end goals are. You’re no more trying to sell why talk to customers or talk to users or doing user research.

“Why don’t we know this information? So let’s go get this information, and how do we get this information? Who do we talk to? Do we talk to somebody internally or do we talk to somebody externally?” And so you’re doing user research even without knowing, and I don’t have to tell my team or the project team how the contextual interview went. I’d quickly jot down those notes, create an instrument, go back, and say do you feel like we are asking all the right questions.

I always review all of this with the QE on the team document, doc writer on the team, engineers, engineering managers, program managers. They can all look at this and because they’ve had experiences talking to these customers in the past, they would probably say “we should probably talk to this kind of persona and not that kind of persona” because in our past we understood that these customers don’t do this and a lot of internal iteration happens.

We are a highly analytical and logical company. We always want to have data to support what we are doing. What it means is somebody who’s looking at product marketing comes with product marketing data. Somebody who is looking at UX would come back with UX data to support whatever we are doing. When teams work on a new product idea or a feature, they go to senior management and say, “here’s our solution; and here’s the problem statement; here is the foundation of what we’re going to do.” Invariably, the senior management almost always asked them, “what were the other ideas that you discarded? What were your alternate designs?”

This is what designers strive for. We want to iterate on the ideas. We want to generate multiple alternate designs before you pick the right design.

Without a designer trying to enforce that, even the senior management would ask “what are the ideas you discarded?”, this has been embedded in MathWorks’ culture. In almost every design review, we always discuss all the alternates we didn’t consider.

6. On mentorship and the Product Design Fellowship:

One of the biggest takeaways for me from being a mentor or being a mentee is the space to learn. When I say that as a mentor, I probably know the end state or what needs to get to the end state; if I enforce that on a mentee or a person who I’m working with, they will not learn. Would you catch a fish or teach someone to fish? A lot of times as a mentor or a coach or a manager, I hold back and tell myself I should have some more patience for this person to come along the journey. My job is to steer them and let them go on their journey; steer them away from poor decisions. If you go experience the same thing, it’ll give you the wisdom of what works and what doesn’t work.

7. What do you look for while hiring a designer?

I think my answer will come from the practices we’ve had at MathWorks. The craft is important. There’s the craft of the designing or how they approach user research or UX design is important. That’s not what I’d be talking to somebody in my first conversation. I already have seen enough in that resume and portfolio to know they have at least the basics, depending on the level of experience that I’m hiring for. My first conversations and interviews are around understanding this person.

Two things I look for are their listening skills, it’s really hard, and it’s counterintuitive for people in an interview to understand that they’re not there just to talk, they’re also here to listen. I have a conversation based interview, I’m trying to understand if they’re catching on to what I’m seeing. Maybe I’m giving them a nudge and I see if they’re incorporating in that conversation. These are the things I’d be looking for because as a UX person you’re always evangelizing; You’re always working against a mountain.

Even before you’re hired at MathWorks, you’ll work on a brief project with a manager. We give you enough guidelines on what that presentation could be like. I always offer my help and time to an interview candidate to say, “Here’s what we expect. You have one week before you come in for the interviews. You can use me as a resource to help iterate on your presentation.” I always make sure I say at the beginning and end of my email to use me as a resource. Someone who sends me their completed presentation a day before the interview vs someone who sends me a draft and asks for my thoughts and questions about it before going ahead with the complete assignment. This way, I get to assess this person’s learning ability. How would they adjust? Would they fit into the culture at MathWorks? We end up going back and forth and have a conversation. Plus, they also get to see how it would be like working with a manager. I see it as a two-way street. I’ve hired about 15 people so far, and I’ve always gotten feedback that they’re this is by far the best interview process that they’ve been a part of.

8. A book you read recently? It can be outside design, anything.

Taming Hal- I think it’s super interesting. It’s written by A. Degani, who’s a researcher at an aviation company. His younger brother passed away in an airplane accident. It was a small aircraft, and he was piloting the aircraft which crashed and he passed away. This guy who works at an aviation company started understanding, “why do we always call it a human error. Maybe it’s a systems error. Maybe it’s an interface error.” It’s a brilliant book to understand the technology around us and why it’s called a human error.

9. Design to you is… ?

Amalgamation. Where people from different disciplines come together and design affects a lot of disciplines.

Learn with Praneet

Praneet is a mentor on The Product Design Fellowship, that starts in Jan 2021. Grow your skills in Product Design and get hired at top design teams.

Learn more
Be in the know

We publish guides & interviews, organize events, courses, and programs to help you explore and learn design.

Can we keep you posted?