If U Seek: Design Maturity in Deep Tech

Jui Pandya joins If U Seek to talk about building design maturity in highly technical industries, making UX valuable to the business, and designing better systems when complexity is part of the work.

In this episode of If U Seek, Nikol Fotaki sits down with Jui, Head of Product Design at QbDVision, for a conversation about UX in complex, technical, and highly regulated environments.

In this conversation, Jui explores what it means to become the first designer in a technical team, how to advocate for UX without relying on design jargon, and why good design depends on the realities of the industry, the users, and the business.

You can find If U Seek on Spotify, Apple Podcasts, or YouTube Music.

Preview

What’s in this episode:

• What it feels like to join a highly technical organization as the first designer

• Why “good design” depends on context, industry, and user expectations

• Why UX advocacy needs to connect design decisions to business outcomes

• How to separate necessary complexity from unnecessary complexity in regulated workflows

• What research looks like when qualified users are limited and highly specialized

• Why UX in life sciences is not only about the product interface, but the entire system users interact with

Transcript

[00:00:00] What is even good design for you? And that could mean different based on what your business model is, what your industry context is, right? All that will define what that good design is. So just starting with the fact that good design is such a packed word. So how do you really unpack that?

When I joined QB Division I've seen that at multiple places, not just at QB Division. In many different industries that are deep tech. Our users were just on and on about praising our software. They're like, "This is brilliant. We love the design. "And our designs were good, right?

But I always see from the lens of there's always room for improvement, right? And like any startup and the normal product process, you're gonna make some trade-offs. You've deprioritized a few things to prioritize the other things. So there's always scope for improvement. So the overwhelming praise didn't really make sense at first, but it actually just made me wonder, am I missing something that I'm not understanding, right?

What is good design even here?

[00:01:15] Nikol Fotaki: Hello, everybody. This is Nikol Fotaki. Welcome to If You Seek. Today's guest is someone who sits at the crossroads of design, business, and deeply technical systems, and she's someone who generally can't shake the entrepreneurial itch, the kind that nudges you to build, experiment, and take ownership.

Jui Pandya is the head of product design at QBD Vision and a true product design hybrid. That entrepreneurial itch led her to do more than design. She actually founded and led a startup in the consumer electronics space. Building a hardware software company from the ground up taught her how to solve customer problems at every level, from hands-on product design to business strategy.

Before and after her startup journey, Jui worked across fintech life sciences, healthcare, and business intelligence, leading teams, managing stakeholders, and navigating both agency and in-house settings. [00:02:15] One idea kept proving itself over and over again, great design must drive real business outcomes.

Most recently, she brought that thinking to the Best Buy Alliance UX for Life Sciences Conference in New Jersey, where she spoke about integrating design talent into life sciences organizations. Today, we're exploring what it really takes to build design maturity inside highly technical industries and what it takes to scale UX where complexity is the norm.

Hi, Jui. Great to have you with us.

[00:02:50] Jui Pandya: Thank you. That is a very generous introduction. Thank you. It's,

[00:02:56] Nikol Fotaki: it is impressive.

[00:02:59] Jui Pandya: I'm really excited to be here. Thank you for inviting me, and really excited to dive in.

[00:03:05] Nikol Fotaki: Okay, so let's jump right in. You entered a space where most people weren't familiar with what design could [00:03:15] bring.

What was it like to step into that environment as the first designer and start shaping how people understand the value of UX?

[00:03:25] Jui Pandya: Yeah. Like your introduction, I worked in many different domains, and I also worked at different stages of the companies. So I worked for startups and I worked for, companies that were so established they were, like, two decades old and three decades old.

But the first ever time when I was a first ever designer at a company was at QB Division, which is where I work now. QB Division is a company that serves life sciences industry, so our customers would be pharma and biotech organizations, and we help them bring drugs to patients faster. So this team is brilliant.

And they ... When I joined, they already had a very well set workflow of how they work, and they were solving real problem. They were actually making the changes in the industry and driving, a [00:04:15] different way of how pharmaceutical organizations worked. But they never had design as an integral part of those workflows before.

And the closest I'd come to working like this before was I was once working in business development department at an agency where I was helping sell design services. But even then, when I was talking to those clients, they knew what they were looking for from the design services, right? Versus here I had to find my space.

So the question I really was asking was, "How do I find that space in an already high-performing team, and how do I integrate? And, where do I really fit there?" So I tried many approaches, and I failed multiple times before, something clicked.

[00:05:02] Nikol Fotaki: I see. Okay. That's really interesting.

So these different approaches what were some of the tactics you exper- you experimented with?

[00:05:12] Jui Pandya: Yeah. So the first ever [00:05:15] tactic, which is, which just comes naturally, my first instinct was just to educate, right? To show- Hey, these are some of the case studies and some ways how I've helped businesses before and how I've integrated in the businesses.

So how did I drive, better outcomes using design? And the team really was super reactive to this, where they were they appreciated all of this, but it didn't quite click for how to apply that in our specific context. And I was also using a bit of a design jargon there, like design thinking and discovery phases and system thinking and user-centered design, and these were jargons which it's hard for people to see through, right?

It's a lot of... It could sound like a lot of fluff really to people who are not from the domain. So there was a miss here. So that's one approach that definitely didn't work. Then I tried going into smaller rooms where teams were already doing their work, rather than creating a [00:06:15] different room for doing the design work.

So I would go in the smaller rooms, and I would just share opinions on the fly. And, I would get really positive feedback "Oh that's a good thing to consider," and, "That's a good point," right? And I would try and take these opportunities to say, "This is just normal product design," right?

And so now I created that relation which was missing when I was just showing example. But even this tac- tactic, like it built credibility, but what was really needed was doing it for the right project with the right visibility so that I can actually show the value. The right project was when the team started working on this brand-new area of our software, and everybody had their eyes on it.

Everybody was excited about it. So I started looking at the team's calendars and just self-inviting myself to those meetings. And the research was already done, but they [00:07:15] were just starting the solution definition. So it wasn't quite the beginning of the product development life cycle, but it was still early enough.

So I started contributing ideas on the user experience and so on, and a few days later, I realized that I was helping the UX strategy a lot already. So this also gave me an opportunity to ask the right questions at the right time. For example, how would our customers understand the value of what we're building here?

And how will our users feel this is helping them do their jobs better? And so I started working with marketing on positioning as well. And you know how important that is. You're- Yes ... you're right in that role. Yes. So you know, that, that connection is really important, right? You're building something, and you have to make sure that you're really collaborating with marketing to, to actually make an impact with what you're building.

[00:08:15] So it was the right time, and so I started working, and this project really helped me expand my horizon to show impact, in, in the broad product development life cycle and not just in the traditional design phase of that product development life cycle. I even ended up making some slides to launch this feature at one of our annual summits.

Yeah. And you know what I realized is a few days later a few years later now, when the new designers onboard, they already have a path carved, so they're not trying to find their space in that cross-functional collaboration, right? They already have a space. Now all they have to do is do their job. That is already hard enough, right?

And so I'm glad that it wasn't just the feature that I was working on, right? I was also creating that culture where everybody who's joining as new designers can thrive and start [00:09:15] doing their jobs so much more effectively than I was on my day one.

[00:09:20] Nikol Fotaki: Okay. So for designers listening who might be, stepping into a similar role, do you have any advice for someone becoming the first designer in an organization?

[00:09:31] Jui Pandya: Yeah. The main advice is just, you have to know that you are going to spend a lot of your time, at least early on, not doing the traditional design work. So you're gonna be building relationships. You're going to be finding the space. You're gonna be communicating value, and you're gonna create this alignment across teams.

So if that's the kind of a challenge that appeals to you, then this can be a very fulfilling job. But if you are more interested in the design craft where you wanna solve complex user problems and work on design systems, this may not be the right right thing. And you will get there, [00:10:15] right?

You will get to doing those things, but your first chapter will look slightly different. For me personally, I am so glad that I got this opportunity to do this rather than join a design-mature organization. How do you join an organization that is brilliant and help them be design mature?

[00:10:34] Nikol Fotaki: Ve- very powerful.

I think many designers will take a lot out of this. Okay. Your users are incredibly skilled. Scientists, engineers deeply technical people, but they're not used to intuitive, let's say, UX or modern design practices. How do you design for an audience that doesn't expect or even look for, good design in their tools?

[00:11:01] Jui Pandya: Yeah, that's a great question. So this is a good one because I had to wrap my head around this as well. But let me break this down a little bit. So anytime we talk about good design I always like to think about the outcomes [00:11:15] first. And, those outcomes will define what your success is for the good design, and that will then define your good design, right?

What is even good design for you? And that could mean different based on what your business model is, what your industry context is, right? All that will define what that good design is. So just starting with the fact that good design is such a packed word. So how do you really unpack that? So anyway, a story.

When I joined QB Division in... and not just i- I've seen that- this at multiple places, not just at QB Division. In many different industries that are deep tech. Our users were just on and on about praising our software. They're like, "This is brilliant. We love the design." And our designs were good, right?

But I always see from the lens of there's always room for improvement, right? And like any startup and the normal product process, you're gonna make [00:12:15] some trade-offs, right? You've deprioritized a few things to prioritize the other things. So there's always scope for improvement. So the overwhelming praise didn't really make sense at first, but it actually just made me wonder, am I missing something that I'm not understanding, right?

What is good design even here? So I decided to examine what are the tools they use, right? What is in their digital toolkits? How do they work today? And I'm generalizing here a little bit, but a lot of deep tech usually have some on-premise softwares in their toolkit which haven't updated in a long time.

They also have a lot of legacy systems, and most of their interfaces really look like from 1990s. So so that became very clear to me early on in my career, right? That these people have been eating military ration for years, so even if you give them a simple home-cooked meal, [00:13:15] it feels like fine dining to them.

So- Our users were actually genuinely impressed by what we delivered because they've grown accustomed to these outdated ways of working, and what we were giving them was way, way better than that. So our aspirations were, much higher, but what we were giving was already a good, a significant change in their workflows already.

Yeah, so this really shaped a little bit of our design strategy. So when we think about good design and innovation what our philosophy is really that our scientist, what they really want is we are fundamentally transforming their workflows. They are hopping in and out of all these fragmented systems from, those are outdated.

How do we make that experience cohesive and give them a single source of truth? We are introducing entirely new data models. They have this massive [00:14:15] amount of data. How do you architect that in a way that is scalable? And we're also changing how they think about their processes. A lot of the, these technical industries, they have so much history, and that history can result in biases.

So how do you overcome that, right? And help them think different. So these are the kind of problems that really means good design for us. So if we are solving these problems, that's really good design. When it comes to the design patterns, right? When we think about the UX trends and pattern trends and everything, we try to reuse patterns as much as we can.

So we don't try to reinvent every aspect of the user experience design. So instead of just being, trying to be pioneers in every interaction, we are just relying on the design industry and the patterns that they've established over the years that work, and just [00:15:15] fitting that intelligently to our context.

So yeah that's pretty much how we think of good design.

[00:15:24] Nikol Fotaki: Impressive. Impressive.

[00:15:26] Jui Pandya: Yeah.

[00:15:28] Nikol Fotaki: That shift in how you define good design, it's really fascinating. It- has this changed how you approach user testing at all?

[00:15:39] Jui Pandya: Yeah, no, that's a great point. So we actually had one user test, which kind of also contributed to the strategy and just op- my eye- opened my eyes on good design as well, the definition of good design for us as well.

So we were once testing something on Useberry. We put out a test and, we were expecting some feedback on the navigation flow and interaction design, but- Instead, the main feedback we got was on mental models and how do we do change management, right? We're using these tools [00:16:15] today, how do we get to your tool?

We barely heard anything about interaction design. So this has taught us that it's best for us to test mental models rather than interaction design, and be clear at that point. We'll talk about testing in more detail, but that's essentially how we approach testing. So yeah, it does change based on the definition of your good design, how you approach testing, for sure.

[00:16:40] Nikol Fotaki: It really reframes the idea that good design isn't universal. It depends entirely on context as you sh- just said. Okay. So in highly regulated or technical industries product roadmaps tend to be packed and inflexible. How do you advocate for UX improvements when there's very little space for design-driven changes?

[00:17:06] Jui Pandya: Yeah, that's that's an interesting topic again. Recently one of my teammates attended a conference and came back with an interesting question. So [00:17:15] someone there said, "A lot of today's software becomes tomorrow's middleware," so why invest in that software, especially the UI and UX? And this got me thinking about how we justify UX investments, so especially in B2B environment.

So I have a couple of tools that I always go to, but let me share what my perspective is on the question that my friend heard at the conference. So for some businesses, UX is clearly their competitive advantage, right? So that's what sets them apart in the market. But for others, the calculation can be slightly different.

So you really need to ask, what is poor UX really costing us? So think about the training time. If your software is taking too long to train on it can take weeks instead of days or sometimes months, then calculate that cost and think about the delays. That could cause delays in going to market faster and you could lose some opportunities.

[00:18:15] So if poor UX is costing you, let's say, $50 million, and fixing that would cost you $2 million, the answer is really simple, right? The math is doing the job for you. But this brings us to the core of what I think of UX advocacy. It's understanding the business impact. Now, measuring this impact is not always straightforward, and I know so many design leaders in the industry are talking about this.

How do you really quantify this? That could be a whole another talk, right? But once you understand it, you can plot- The UX investments against everything else on the roadmap, and you can compare the impact. Now, it is possible that UX does not fit there and the math actually works against you.

That's when you face the hard truth, and then you just have to accept that. Another thing that is really important when it comes to UX advocacy, which I learned not very early in [00:19:15] my career, not early enough, is leadership factor. If your leadership has experienced the impact of good UX in their past roles, then the conversation changes completely.

If they haven't, then you're doing the job of selling, pitching, convincing. Otherwise, your job is just to surface the opportunities, not to sell them. So it's really important to just understand this, understand your audience, right? It's literally that principle, so that you know who you are advocating to.

Because a lot of the times we we become really excited about what we are advocating for and ... But it's important to also factor in who you're advocating to, what's their background.

[00:20:00] Nikol Fotaki: Okay. And how would you solve, a problem that the business is already trying to solve, let's say?

[00:20:07] Jui Pandya: Yeah. No, actually, that is

I can share an example of just an internal team goals, right? So one [00:20:15] of the ways is what is your internal team struggling with, right? If you ask yourself that question if the answer is efficiency what is what your team is struggling with, or is it that you're rapidly growing, you're scaling, and now because of that you're facing consistency challenges across different products or product areas, then this is a place where something like a design system initiative might make perfect sense, and it could make a perfect business case.

So imagine that your engineering team is growing from 20 to 50 people, which is you're more than doubling now. Now suddenly every team is building all your buttons differently. One team spends three days creating a dropdown menu, which the other team already built last month. And all the new hires, both engineers and designers, take longer to onboard because the patterns are not consistent.

So a design system solves these problems around velocity and scale. So [00:21:15] when you frame it this way, you're not really asking for UX investments. You're proposing an operations solution. So you're reducing the redundant work, you're speeding up the onboarding, you're preventing the technical debt that will show up from inconsistent implement- implementation.

So what you then do is the three-day dropdown example, that And becomes CR implementation, and you can multiply that for every component, every team, every feature, so on, right? You get your numbers. And so this is another tool that I go to, which is just essentially about framing, right? In this example, a design system is framed as an operational efficiency initiative.

And yeah that's another example of just, again, we all come back to numbers all the time, right? But another way to look at advocating for UX has nothing to do with numbers. It's literally about identifying common wins. So you don't have to fur- furnish new numbers now. [00:22:15] You're just finding where your UX improvements align with what the business already wants to achieve.

So you're not fighting for a separate space on the roadmap, you're just showing how will the design expedite or help solve and, get the already already defined goals. So I was actually in a discussion recently, and one of my teammates said, "Maybe they're all the same things," right?

UX does not need separate space. They're not mutually exclusive. So you don't have to always segregate UX improvements. They can just fit naturally with the roadmap that you have. So the key is really just understanding that when you have a packed roadmap, UX is not really fighting for its own space.

It's stru- it's finding its natural place in the business journey. If you are advocating for something that makes [00:23:15] sense for the business journey and the goals that you have, it will find its place naturally. So sometimes that also could mean waiting for the right business stage. What is not important when you are, in your in your early days of startup could be important once you get to, for example, series B or something.

And sometimes it also means reframing the work, the design system example, right? But it always means connecting design decisions to the business outcomes.

[00:23:47] Nikol Fotaki: Yeah that idea of aligning UX with existing business priorities, it really feels like a huge unlock for the business, yeah.

So as your team grows, you're also shaping how PMs, engineers, and technical experts collaborate with design. What have you learned about building cross-functional alignment in an environment that's developing its design maturity?

[00:24:12] Jui Pandya: Yeah. The culture, right? We [00:24:15] started talking about this in the first first few minutes already. This is... I love this topic personally because, the culture itself is going to define how successful you are going to be. And sometimes you land in places where you have that culture already, and sometimes you have to create that.

So I... this is a topic that personally interests me a lot. So I think it all comes down to you're shaping how everyone around you understands what design can do, but what's important is how do you fit in their world? So at QB Division, our team works with all the scientists and product managers and everybody who's brilliant at what they do, and they've built systems around how to handle this complexity.

But like I shared in early on I learned that the cross-functional alignment would- comes from working together on these problems. So how do you help them do their jobs [00:25:15] better, or how do you take some things off your plate? So for example, you just have to be genuinely curious about what motivates each function.

So product managers would think about the roadmaps and market differentiation. The engineers will think about the system architecture, the technical debt. You could have domain experts as well, or regulatory professionals in regulated industries. They are thinking about the compliance, the risk. The legal team also thinks about that.

You could have sales and customer success who's in charge of selling and adopting, so they think about does the mental model match the what you're building. So design's job is just really to help these people see that y- design and user experiences actually support all of these things. So again, in my experience, this all comes back to common wins.

So common wins have mostly [00:26:15] helped, cross-functional partners see design's role and build that culture. So product managers would start bringing design early in their, in the conversations because they saw how it helped them meet their goals, and engineers would appreciate someone to think through the user's mental model before they start building so that they don't have to go back and change their data models, 'cause that is really messy to change later on.

So- It's essentially just, finding that collaborative space, helping people do their jobs better, meet them where they are rather than bringing them to where you are. So you integrate first and then spread that thinking. And on spreading that thinking bit, another key thing is design maturity really grows when you create space for everybody to con- contribute.

So not only you are contributing and helping with their jobs, but how do you help them contribute so they get excited [00:27:15] about things? So what you could do is just open the doors, let the product managers sketch out the workflows, let the engineers surface usability concerns. So this is not essentially design by committee by any means.

What we're doing is just we're owning the practice, but we're sharing the lens of looking at the things. And these are just some things that I use to, to help, that culture to help that culture reinforce these values.

[00:27:47] Nikol Fotaki: Okay. Very interesting. And how has that culture shift impacted new designers joining the organization?

[00:27:55] Jui Pandya: Yeah. I've ... this is great. Yeah. As the design function grows the culture that we're building, it means that, again, when the new designers join, they don't have to prove the value the same way. They will join a team where cross-functional partners have already understood how design fits in product [00:28:15] development.

They'll have product managers who will involve them early, and they're always thinking user-focused. You'll have engineers who are, again, thinking user-focused and surfacing all those usability concerns. So they really see designers as collaborators. And this really matters because what we're building is one thing, but culture is going to help you build, next things easier and better and faster and all of that.

So design culture is about future and how do you scale things as well. So it's not really just about today. It's about creating that environment where we can scale and, where the next design hire can just come and focus on start solving the user problems, which is what they do the best, and they're not trying to convince to get a seat at the table.

[00:29:07] Nikol Fotaki: Very important. So yeah for designers trying to build design culture in their own organizations, any [00:29:15] advice for them?

[00:29:17] Jui Pandya: Yeah. The most important lesson for me is just meet people where they are, right? So if you're building a design culture from scratch, your early wins will matter a lot.

That will create your future feature. So if you have the opportunity, choose the projects that will demonstrate this value across functions. And you have to build relationships on collaboration. How do you work cross-functionally? And you just have to create the space for design to spread organically through the team.

[00:29:49] Nikol Fotaki: It sounds like culture is something you build through small, consistent actions.

Tools used by scientific and manufacturing teams often mirror the complexity of the work itself. Strict processes, heavy documentation, compliance requirements. How do you simplify or improve UX when the underlying workflows are complicated and often non-negotiable?[00:30:15]

[00:30:15] Jui Pandya: Yeah. So when I first entered the workforce the first-ever system, and that was regulated, that I worked on, was electronic health records. So whenever I saw any redundancy or complexity, the solution in my mind was so simple. Why don't you just simplify it? But I realized that you can't always, take things away because they exist because of some compliance reasons which could be non-negotiable.

I faced the same in finance software and now in pharmaceutical industry. So there's a natural urge for designers when we encounter a complex process, we look for steps to remove simplify. That principle is really ingrained in our brains. But in regulated workflows, when you have some things that are non-negotiable, what you can do is you can make each step clearer, faster, and less prone to error.

So you're not reducing the amount of steps, but you're just making those steps easier. That is the first thing that you can do, [00:31:15] and that's a slightly different design skill than taking everything off and simplifying it. But the most useful thing that I've found is knowing the distinction between necessary complexity and unnecessary complexity, and these are very easy to get mingled.

And I've done this especially early in my career, where I didn't really understand the difference, and I would just take everything out of face value. So necessary complexity could be something that is coming from some compliance and regulatory restrictions and things like that, which you can't do anything about it.

But there is some unnecessary complexity as well, where you could have bad integrations, and you could have manual data transfer between tools, and workflows that are shaped by the legacy system and the way that things have worked in the past, and they just have never [00:32:15] been questioned because it is so complicated.

So the true design challenge really is to decouple- complexity into these buckets, necessary and unnecessary, so that you can take actions that are that are the right way of doing things, and then act on it accordingly. There is an example here. So imagine that, a user is spending 40 minutes in generating a report that is very important for compliance reasons.

And, but really if you l- look deeper, you'll probably realize that 20 of those minutes, those steps are important for compliance, but the other 20 is just because you, your system just doesn't load fast enough, right? Or you have some data that is in a different format in a different system, and you're just reformatting it.

So how do you really hunt for these things? That becomes the real design challenge and a detective work really. The other thing [00:33:15] is, these constraints are real. They're not going away. But again it's also about figuring out ... I always use the Pareto principle. So there's a natural urge for designers to make a perfect user experience for all the scenarios.

But what I find is that what are you really optimizing your designs for versus what are you accommodating? So you could optimize your design for the first 80% of the scenarios, and the 20% of the scenarios you could just accommodate your designs for. If you try to optimize for everything, then even your 80% scenarios will have a good enough design, but not a really optimized design.

And this is really hard to understand for someone who's just entering because, you have a natural urge to make a perfect user experience for the whole flow. And I also had a hard time digesting this. But it just comes [00:34:15] with maturity that, you're willing to make these trade-offs and you are in fact advocating for some of these trade-offs as well, which sometimes sounds counterintuitive, but, it's all for the best.

[00:34:28] Nikol Fotaki: Yeah. This clarity under constraints really captures this challenge here. Okay. Unlike consumer platforms where research can scale quickly, deep tech domains face unique challenges limited user pools, specialized domain language a- and internal only testers. How do you still gather re- reliable insights and structured feedback under these constraints?

And what role do tools like Useberry play?

[00:35:00] Jui Pandya: Yeah, no, this is good. We're talking about Usevery and this Usevery podcast. I'm excited for this question especially because it does-- research does come with constraints in these industries where deep tech and [00:35:15] regulations and a lot of domain-heavy terminology.

So we can't just go on, a recruitment website and get a bunch of users to test something that we're building, right? These-- our testers really need specialized knowledge, and they have to know the jargons and everything. They have to understand the pharmaceutical process just to make sense of what we're testing.

So getting just 30 minutes with five qualified users is quite an undertaking for us. And it's not because, these people are not available, but it's because we can't afford to tire these participants, right? We can't keep going back to the same people because there is a niche pool. Otherwise, it'll result in fatigue and overload for them, which we don't want.

So when you don't have an endless supply of users, every outreach that you have has to be meaningful and respectful of their time. So that constraints [00:36:15] just-- That, that constraint just pushed us to ask this question to ourselves. It's do we actually need to validate everything? What do we need to validate?

And what can we trust to our own expertise? So now having worked in a lot of consumer tech industries as well, especially my startup I learned that, there's a natural urge. You wanna test test, validate everything from the users, right? But that's impractical for us. So what are the users the right source of truth for?

What do we learn from them? So th- we usually go to them for how do they think about their work? What are they trying to accomplish and how? What are their workflows? How their mental models have been shaped by years of experience working with the same tools and processes. But users are not always the right source of truth for us for interaction-level decisions, at least in our context, because again, it goes back to the [00:37:15] definition of good design.

So we wouldn't test how should a loading state behave, right? And what pattern should we use for this complex form? Those decisions belong to the design expertise for us, and understanding that distinction allows you to make really every research touchpoint count. And we've developed what I think of it as a three-circle model And I think this can scale very well to deep tech industry, other de- deep tech industries as well, where specialized knowledge is needed for testing and so on, right?

So think of three concentric circles. The outer circle is your external users. So these are your actual people in the industry with the specialized knowledge who are going to use your system. They know every- everything about this industry. And when we engage with them, we are just getting the high-level insights on mental [00:38:15] model, business goals, workflows.

We just need to understand how they think about their work and what they're trying to accomplish. So we would get something like directional signals on on the product product shaping from them. Then the middle circle for us would be internal users, our subject matter experts, who also know the industry so well because a lot of these will be, will have worked in the industry before they would work for us.

So they understand the industry and regulations and everything. They help us validate and refine the solution in terms of the workflows itself, and they also try to help us spot where whatever we're proposing as a solution might conflict with some of the regulatory requirements that we could be mi- missing.

Then comes the inner circle where the inter- interaction design happens, and this is where we rely on our judgment, our expertise. So we take mental models and [00:39:15] workflows that are validated with both the circles, so externally and internally, and we would make decisions on the user-facing information architecture, the navigation, and the inter- interface design.

So we're applying our craft to translate those learnings to designs. That is not where we actively do research, and I've seen this in health- healthcare as well, and a little bit in, in finance as well. So yeah, this really scales to a lot of the regulated industries.

[00:39:48] Nikol Fotaki: R- Very interesting. So you talked about how you think of research but what are some things that you research?

[00:39:57] Jui Pandya: Yeah that's good. Yeah. Yeah. So this could be slightly different for different regulated industries, at least for the ones that are building something from scratch that does not exist in this in, in the industry on this planet at all. [00:40:15] Then you have to do this different approach.

We can't just go to our users and say, and ask what we're what they would want because, you will run into this faster horse problem. They are going to suggest some some incremental updates based on the tools they're using now- Because not everybody, they're good at the science part, but they're not good at imagining how their workflow.

That is our job. That's not their job to imagine anyway. So we wouldn't do that. And we can't even go to a competitor because we are the first ones in the industry to have this c- this product segment at all. So we can't just say, let's do a competitive analysis and see what they're doing well, they're not doing well," right?

All this to say that what we are researching is really validating. So our approach is always just come up with a stance, right? How ... Based on your [00:41:15] knowledge, how do you solve a problem? And then go out there and either validate or invalidate, and based on that, iterate and so on. So what we are researching we are not doing the traditional research because that doesn't always work.

In most cases, and I'm generalizing here a little bit, is we're just validating.

That's all it is.

[00:41:37] Nikol Fotaki: I see. I see. And I'm also very interested what your research toolkit looks like.

[00:41:45] Jui Pandya: Oh, that's a great question. Useberry is definitely in our research toolkit.

[00:41:49] Nikol Fotaki: Yes.

[00:41:49] Jui Pandya: We have a limited participant pool, right? That is not going away, and that's why it's even important that we use efficient ways to validate our thinking. And so a tool like Useberry really helps us. So what, how we use Useberry is we set up focused usability tests for experts where, they are testing it on their own schedule.

And [00:42:15] even though we're testing for mental models and workflows with them, Useberry lets us understand the navigation patterns, which will give us insights on the things that we are relying on our craft for, but we're indirectly testing that as well. So this just gives us this behavioral data so that we can make decisions.

But again, these tools work because we have the three circle model, right? So we just have different tools based on the stage we are at. So Useberry would be something for user testing. Otherwise, we rely on a lot of, in, in-person communication as well. When we meet for conferences, we're always finding those nuggets.

So that's a lot of casual conversation that are driving these nuggets as well, and then we also rely on, just organizing the research in documents and Miro boards based on every instance Another technique which we use for validation is [00:43:15] analogies. So a lot of the times you're thinking that all of these problems are really industry problems.

If you're in the science industry, then you think of them as science problems, and otherwise, it's a finance problem. But a lot of these times the problems are really about the data architecture. So in those cases, you can just strip the f- the jargons away, and you can use analogies.

For example, instead of a drug recipe, if you just convert to cake recipe, right? Then now we are inviting a lot more people in the room to contribute. Everybody understands cake recipes. Even though you've never baked a cake in your life, you will understand that. So now we are inviting the data architects and the engineers in the room, and they are validating your data structure.

So that's not really a tool, but that's a technique that has helped us a lot just to figure out if we are thinking about the architecture right. So yeah, what we are trying to do is [00:44:15] just work with fewer touchpoints, and this just forces us to be more disciplined about what we are trying to learn from each one.

So this research just requires more creativity and structure, but it is totally doable and fun.

[00:44:32] Nikol Fotaki: As design maturity grows in technical industries, where do you see the biggest opportunities for UX to transform how scientists and engineers and manufacturing experts work?

[00:44:45] Jui Pandya: Yeah. So everything I talked about today building the design culture, navigating the research constraints, and then designing for regulated industries, these are all lived experiences, and that has made me realize one thing, that UX in these industries isn't just about UX.

Now, that sounds like a strange thing for me to say, especially on a user testing podcast. S- but this in the highest form of [00:45:15] ambition for this work. The biggest opportunity, in my opinion, in this space is where UX stops being a discipline and starts being a property of the whole system. So in your traditional B2C software, great UX can carry your work to an exte- carry your product to your ex- to an extent.

In regulated industries like life sciences, UX alone won't get you far. The real transformation will happen when you combine UX with also customer experience. You're broadening your horizon, and even do service design. So this means being in those data model discussions, influencing your customer's business processes, and how are they making d- decisions around their business processes.

designing the change management part into everything that you're working on, not just treating it as a launch communication problem. So a lot of these things which you can get away with in, [00:46:15] in some industries, I don't think you can get away with in these industries. So when you operate at that level, the experience you're designing, it's not just within the product, it's the entire system that the user interacts with.

[00:46:30] Nikol Fotaki: And what does this mean for the designers who might be entering these spaces?

[00:46:36] Jui Pandya: Yeah, for designers this orientation could help. So the most important work that you do may not look like traditional design work, especially in a few years when these industries become design mature in the true sense.

So the designers who make the biggest impact are the ones who treat UX, customer experience, service design, all these as unified practice, and who are willing to work wherever there is a leverage and a need and an opportunity. So again, this is not just one department's job, right? This is collaborative.

[00:47:15] You have to go cross-functional here. So the true magic happens when you're working with other departments, influencing them, and achieving this unified practice by not just doing it yourself, but ins- influencing and persuading other people. And this is the kind of transformation we are building toward at QB Division as well, and this is where I believe that this field has its most meaningful work ahead.

[00:47:42] Nikol Fotaki: Jee, thank you so much for joining us and sharing all this very interesting information knowledge. It's a real, it's a real honor to have you on If You Seek. Thanks so much.

[00:47:53] Jui Pandya: Likewise. Thank you.

[00:47:56] Nikol Fotaki: We'll also link to Jee in the show notes. Thank you to everyone listening. This was If You Seek by Useberry.

See you next time.

For more exciting content, follow us on our social channels. Your reviews mean the world to us, so don't forget to leave one. And of course, hit that subscribe button to stay updated on our latest [00:48:15] episodes. If You Seek is a platform for discussions and personal insights. The opinions presented by guests are independent and do not represent the official position of the host, Useberry, or our sponsors.