Praneet Koppula, UX Manager at MathWorks Talks About Processes, Skills which Designers must Consider

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

I went from a design agency to a company where I was the sole designer with 7,000 other employees, nobody understood what I did. Which meant I needed to bring in more people along with me, 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.” They were very puzzled did not know what UX means

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 at that company, I was teaching other people and evangelizing the role of design and UX. I bank on other people in my team to help design, help teach the UX skills needed. I think that is the key thing 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 or 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 your process to come up with this idea.

Products are shipped by a group of people, your design need not be a hundred percent perfect, but it needs to 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 an approval from you.

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

The most successful people or the most evolved designers, irrespective of their experience are the people who figured it out. A junior designer recently shared this this experience: 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 the next version of the software. 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 design is more appreciated in organizations. 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.

3. On processes

When I talk to junior designers, they’re not afraid of their craft. 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 on this solution?”

The process on how design is integrated into software processes is still immature. When I ask engineering about their process, 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 standardization on how design works at a 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 rigid. We have the best practices in everything that we do. How do you have a successful product? A few years back based on learnings product teams, MathWorks has come up with 13 habits of highly successful teams. The number one habit in that list is that every product/feature starts with understanding the users and their goals. We share these habits to everyone who joins the company and help set the culture.

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 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, “We know the motivation for this feature, but who’s going to use this. Why would they use this feature or product? 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 on the problems and the pain points.If not, invest some time to go figure out what those end goals are. You’re no more trying to convince on why talking to customers and doing user research is needed.

“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?” That’s the beginning of the user research plan. 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 my instruments, research plans with quality engineers, doc, developers and program managers on the team. 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” 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. 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.

6. On mentorship and the Product Design Fellowship:

One of the biggest takeaways for me for 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 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 design task 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.” 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. We do get feedback on our interview process and we do hear that candidates enjoy the interview process as well.

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

Taming Hal- I think it’s super interesting. Asaf, who worked 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.

-Team at ownpath

For regular updates, please follow us on Twitter, Instagram, and LinkedIn.
You may also like to read