Larry Pelty is one of the first design leaders to advocate for a transition from traditional product design to AI-driven product design. He believes that AI is an assistive technology for product designers, requiring completely different inputs and producing different outcomes compared to the products we have been working with for the last 20 years.

With 24 years of product design experience, not including his background as a digital artist, Larry is a seasoned leader who mentors designers worldwide and currently holds the position of Director of Product Design at Clari.

In this episode, Larry and Yuriy discuss how design leaders and their teams need to change their mindset to provide value in the AI era and collaborate cross-functionally to solve users' problems in critical moments.

Design challenges amidst sales tool consolidation

Yuriy, Cieden Co-Founder and CEO: Hi Larry, and welcome to the Cieden Podcast. We are excited to delve deep into your vision for the future of product design and AI.

Larry Pelty, Director of Product Design at Clari: Thank you. It's great to be here. I always love opportunities to have these kinds of conversations. So I'm definitely looking forward to them in the next hour or so.

Yuriy: So maybe you can tell us a few words about Clari, what it is, and how it's different from other sales software.

Larry: Sure. Clari is focused on revenue governance and management, as well as sales productivity and all the pieces related to that. You could think of that as within a sales process, Clari provides all of the products of the funnel all the way through closing the deal and implementation. Specifically, in the area that I work, I'm the director over two different product areas that deal with sales engagement, which includes a lot of our generative AI functions, and mutual action plans, which are another part of the process in which account executives interact with buying teams. It’s a very tightly coupled set of software with a lot of crossover into other areas like forecasting and account inspection. It’s a broad and complex platform.

Yuriy: From your design approach, do you think there is a difference in how your team approaches design for sales? Because there are so many different tools there.

Larry: There are. It's a very tight market, and what's happening within this market is a lot of consolidation. Years ago, there were many different types of tools, and companies were okay with having a tool for this and a tool for that. But everything has shifted toward consolidation. We need a platform to be all-inclusive. We're facing the same challenges as our competitors, and we're finding our own ways to solve these problems and think about this consolidation in unique ways. Every design team in this space is facing this same challenge.

Yuriy: And why do you think it happens now?

Larry: It's definitely tied to what happened with COVID. There was an expansion in the market, with companies making money and hiring more salespeople. But as the market shifted in the last year or so, companies are looking for efficiency, trying to cut costs. It doesn't make sense to pay for multiple tools when you can have most of the features in one platform, which is easier to maintain and requires fewer admins and integration teams. It's related to the market shift we see.

What to keep in mind while monitoring product markets

Yuriy: How do you approach market exploration and discovery? With the speed of development and many announcements, what's your process for that?

Larry: We have an amazing product marketing team constantly watching the market and conveying information to us from analysts and competitor announcements. We try to do this internally within the product team, but it’s difficult in addition to our roadmap and plans. It’s a collaborative effort. It’s important to understand what’s happening in the market, not to follow suit but to understand the why behind it. AI is being used in many ways in this space, and we need to understand what is being done to inform our product development process.

Yuriy: There are two trends: everything becoming a sales platform, and innovation in specific areas with super-focused tools. These smaller players are at risk of being copied or acquired by bigger players.

Larry: Yes, absolutely. Larger enterprise organizations are willing to take less cumulative capability for a more consolidated, easier-to-manage platform. Smaller players with hyper-focused features are at risk because enterprises will wait for their consolidated platform to catch up. Acquisitions are often the best outcome for these small players in this consolidating market.

How to measure UX design success

Yuriy: How do you measure the success of your design work?

Larry: That’s a difficult question. We talk about this within the team. Product organizations have regular rollouts, fixing bugs and releasing new features simultaneously. Measuring success involves a multi-tier approach, using qualitative information, user interviews, and data tracking systems. We correlate metrics like weekly active users and adoption rates with design changes. It's about looking between the lines, as we don't have one definitive data point to measure success.

Yuriy: Do you rely on intuition or just numbers?

Larry: Both. Jared Spool mentioned the idea of vanity metrics, which I think has meaning. And I think behind that, there was some meaning to that. For example, claiming that the success of a mobile app is due to an increase in weekly active users might not be entirely accurate. If we consider a specific use case, such as a mobile app providing an assistant capability for salespeople, increased usage may not necessarily indicate success. Salespeople might use the app when they're on site, at an airport, or traveling to meet a customer. Therefore, we should consider ways of measuring critical moments.

Instead of focusing on user frequency or adoption, we should ask whether the app solved a problem at a critical moment. Can we measure that? I'm not sure we can yet. This is where the qualitative aspect becomes important. We need to conduct interviews and understand user experiences. For instance, a user might say, "I don't use the app much, but in this one moment, it saved the deal." That, to me, signifies success.

Yuriy: Sometimes measuring in-app interaction isn't enough, as the best way to notify users might be through email or other methods. Disrupting users with notifications can kill the experience.

How we as designers identify what we do

Yuriy: I just came from a conference on AI in Montreal, and people have asked me, "What do you do?" 20 times a day. It's interesting because there are so many ways to describe what you do as a designer. Do you have a favorite way to describe the value you and your team provide to the company? You can talk about business metrics, user engagement—what's your approach?

Larry: That's a good question. Not that many years ago, I worked for an organization with lower UX maturity. It was similar then; we had pockets of teams that understood what my team and I did, and others who thought I was a graphic designer. Even outside the field, when explaining to friends or family what I do, I keep it basic: I solve problems. Users have needs; they want to accomplish something they can't because the feature or product doesn’t exist yet. I help solve these problems through design and product design. If there's interest, I delve deeper into the cognitive science and design aspects. Many of us face the challenge of explaining our role, especially in organizations or meetings where we're the sole designer among product managers and engineers who haven’t worked in a user-centered design process. The assumption is often that we're just graphic designers who will make things look pretty, but that's not what we do. It's one aspect, but we solve problems.

Yuriy: That's about strategy, perhaps, because you're not expecting someone to tell you what to do, even finding the problem, because sometimes people don't know what their problem is. It can go even higher. I like this approach. I will borrow it from you from time to time.

Larry: Hahaha.

Connecting the dots as a design leader

Yuriy: What is the hardest thing in the job of a design manager?

Larry: I would say it is really connecting the dots and thinking about an experience from a larger suite-wide perspective. At Clari, there are four distinct product areas with different designers in each area. There are natural silos, and they can happen because of that. As a design leader within the organization, and in past organizations as well, you have to be able to understand what is occurring in these different product areas. You have to think about the experience across the suite. You can't just think about the experience in Product A, Product B, and Product C. You have to consider it from a holistic perspective. It gets very difficult because you really have to pay attention. Even myself, there are other parts of the design team working on things that don't directly relate to my team's products, but I still have to understand them. I need to know what's going on because there's always the potential for identifying some challenge or connecting moment. I'll give you an example. A few weeks back, I was listening to a demo release about some new features in one of our conversational intelligence tools, which is managed by a different team located in India. I realized they talked about a particular pattern around mapping fields. One of my products has a similar thing, and the design is different. The first thing I did was surface this issue and immediately get the PMs on both sides. I wanted to make sure that both product areas understand that there is a pattern being used differently, which can create confusion and increase cognitive load if a user has both products in their suite. We need to fix that. It's very difficult, and I think any design manager has to really hone that skill. It's really about active listening, like listening to demos and product announcements and understanding any kind of internal happenings very deeply to be able to do better.

Yuriy: So there is no way for you to go on a long vacation because products are always developing, everything is so fast, and you need to always understand what's going on everywhere.

Larry: Yeah, I'll admit that taking a bit of vacation has been a little difficult, but I do love what I do, and I love the challenge of it all. As a design manager, you build up your team in such a way that reinforces that. It's not just me. The expectation should not be on me as a design leader alone to connect these dots. I tell my most junior designer that this is a skill I want to see evolve in their career. Everyone on the team should act almost like this mesh network, paying attention and surfacing relevant issues. This allows me to take vacations when I have really good people who are also listening.

Finding motivation in UX design after 20 years

Yuriy: 20 years in design, is it correct?

Larry: Yeah, a little more than 20, I guess about 24. That doesn't even count being a digital artist before that.

Yuriy: What makes you still stay in the industry? Because they say that after seven years, people usually regret their career choices and consider taking a different path. Did you ever have this kind of thought that you could also be not only a designer but maybe pursue another career?

Larry: That's an interesting question. To some degree, yes. I had the opportunity, fortunately, in the first two decades of my career, to work in different roles in different companies. I started off thinking I wanted to be in graphic design, maybe digital marketing, or lead a marketing team. I realized that was not for me. Then I thought about leading a cross-functional team of engineers, UX, and digital marketing because I love solving problems and thinking broadly. I did that for a startup and realized that maybe it wasn't for me. It refined my focus on UX and product design. Having had the opportunity to try different things and see my career evolve, I'd say it has focused me on doing what I love. As my career evolves, it's not about doing something else but diving deeper into AI product design. Not using AI to design products, but AI product design itself. We're approaching AI product design from the perspective of the last couple of decades of digital product design, and it’s different. I think those processes are evolving. I want to be a director or a leader of AI product design because it is much more challenging than traditional product design. It’s not about doing something else but focusing specifically on how my career evolves.

AI product design era

Yuriy: We also do a lot of R&D in patterns for AI implementation in applications. I think that’s the future for at least five years. When material design evolved, it didn’t cover the majority of topics at all. If you were designing enterprise apps or business applications, there weren't many guides you could refer to. It’s super interesting because you can experiment with everything. There are so many patterns not yet invented, and you can make a difference. I believe in the future, everybody will have to shift to the role of AI.

Larry: Absolutely. When I think about designers and bringing a better understanding of AI, even my own understanding is evolving month after month. I tell designers to think about AI differently. You have to consider AI as another actor in the process. It’s not just input-output. You now have this other thing that is person-like in a way, asking more questions, requiring more input, and having a conversation to ultimately lead to some outcome. It’s very different from the products we've been working with for the last 20 years. Designers need to stop thinking in traditional terms and start thinking about how the next five years will evolve. They need to be ready to learn and evolve with AI.

How designers can use AI as an assistant

Yuriy: Do you tell your designers that AI will take their jobs if they do not evolve?

Larry: Definitely not. I don't believe that at all. AI can do some amazing things from nothing to something in terms of generative processes, but does it necessarily solve a problem? No. AI should be an assistant for product designers. The way I use AI in my own process is micro-transactional. I don't use it to generate wireframes but to refine or provide ideas that I can then develop. It’s like having a conversation with a junior designer: "Here's what I'm thinking, run with that real quick, come back with some thoughts." Designers who embrace that process won't fear AI taking their jobs. Instead, AI will allow them to focus on what they do best and offload time-consuming tasks. For example, writing error messages in UX writing is not the most fun thing, but it needs to be done well. AI can handle this task, allowing designers to focus on preventing errors and solving bigger problems. If designers embrace these technologies, they will find a tremendous benefit in their own design work.

Yuriy: What I remember from my early career is having a lot of discussions with developers because I wanted to handle every possible error with a nice message. But the estimate for these changes was often bigger than developing the entire system. Sometimes handling all the cases when something can go wrong can take as much time as developing the system. So I agree, we need more time to focus on these cases. Usually, for many products, it’s acceptable for the user to somehow handle errors, while more features are prioritized.

Larry: Yes, absolutely. That's a great way to think about it. When the team is overloaded and there's no time to get together and think through problems, I encourage creating a prompt and running ideas through it to get feedback. If you have a design and are getting stuck, ask ChatGPT to do a heuristic analysis. I've done that before. You can get tunnel vision when working on an ongoing, evolving product. Asking what is wrong with a design can be very helpful. I'll use an image of a design and ask a custom GPT to identify issues. It actively tries to find things wrong, which can be very good for a designer.

Yuriy: Yeah, it also helps when you tell it what you actually want from the feedback, like making it more actionable or more result-oriented. This helps solve these types of problems. 

Rubber duck method in design

Yuriy: Do you know the rubber duck method? Developers use it, and we also use it in our agency. Our design director, Halena, used to gift small ducks to her teammates. She would say, before you present your designs to others, present them to this duck. You can do it silently to yourself, but the idea is that after you finish designing something, you have to explain it and then get the feedback. Usually, if you do it even to the toy, your mind will be in a mode where you realize, okay, this is not the best idea. I think I can find a better one, or we need to better describe what we are trying to achieve. This thought process helps. Discussing it with AI also helps because you need to communicate your requirements clearly—what the goals are, what you actually need. If you have these custom GPTs that force you to refine your question, it will help. For now, everybody thinks about AI as a chat interface, like an input field displaying information in text and graphics. But there is a huge opportunity with lots of different interactions when interfaces will be generated on the fly, super personalized to what we actually need in every specific use case.

Enhancing UX beyond chat interfaces

Larry: Absolutely, absolutely. The chat-focused interface tends to be a catch-all. It's like everyone thinks, hey, let's add a chat window, and then we've added AI. But there's a certain degree of cognitive load to that. A user is presented with a field that says, "ask me anything." Can you give me an example? What can I ask? Maybe people become more comfortable with it and find their own ways of interacting. Perhaps that's too broad. To your point, there are better ways we might find within the interface—something personalized to the user, something that asks questions, guides people, and provides natural language responses. The system asks what it wants to know, I answer, and if I'm not clear enough, it asks follow-up questions to refine the output or experience. We can think about natural language processing, but not necessarily just a chat window. For example, it asks you a question, you answer, and after this interaction, it builds something based on the conversation. Or you ask something, and it presents the information you need or constructs a visual display that answers your question. There are interesting possibilities, especially with complex software. Over the next couple of years, as these interaction patterns develop, it will be really interesting.

Design skills beyond the basics: AI literacy and soft skills

Yuriy: What do you think would be the most important skills for designers beyond what we already expect from them?

Larry: I would say there are a couple of ways to answer that. One we touched on is the knowledge around AI—understanding how AI works and its benefits to your process and the world. The other side is soft skills. People talk about soft skills a lot, but truly successful designers can communicate well and tell stories. In my mentorship practice, I've worked with several on their storytelling capability. You can have the most brilliant idea, but if you cannot communicate it succinctly, evoking emotion and excitement, your idea could get lost. Being able to push is a hard one for people. People don't like conflict. You might be a designer in a room full of engineers who say, no, we can't do that. It's too difficult. We can do it more simply this way. But you know your answer is solid because you've validated it with users. You have the support. As a designer, you need to push and hold your ground. That doesn't mean you will always win. I've sat in rooms with C-level executives and sometimes pivoted the conversation based on my data. Other times, I've been told, that's great, Larry, but no. It happens. The willingness and drive to do that is an incredibly critical skill for all designers. It doesn't matter if you're a manager, a leader, a lean UX designer, or an associate product designer. You need to communicate, tell the story, support it, and hold your ground if you think you're right. Not in an egotistical way, but by supporting it and not just giving in because someone is pushing against you.

Yuriy: And you need to know how to build alliances because, as a designer, you are responsible not only for your role but for building a culture where developers understand the value and are on your side. Maybe quality assurance engineers could be on your side too. If you are in your silo, only attending meetings once a week and trying to push decisions on people who interact daily, it will be harder.

Larry: Absolutely. That’s even more critical in organizations with low UX maturity. When you're a UX designer and people don't understand your role, you must meet individually with key engineers, product managers, and even stakeholders outside the product teams. In a past role in a lower UX maturity organization, I got to know VPs because I wanted them to understand the value my team brought. Over time, they saw the improved outcomes when we were involved. They might not have fully understood, but they couldn't deny the results. They would push for my team's involvement because they recognized the benefits.

The future of collaboration between designers, developers, and AI

Yuriy: How do you think collaboration between developers and designers will evolve? There are many videos saying that in a few years, there will be no development jobs because everything will be described by natural language. GitHub Copilot's announcements suggest that all software could be written just by natural language within a year. But developers comment that someone will still need to write requirements to tell the system what to look like and how it should work. Developers will still have work. But some say product managers write requirements, so why need developers? Others say designers know what to build, so they can write requirements. So why need developers?

Larry: It sounds scary, but I think that we do not have true artificial intelligence yet—human-level intelligence. That might be decades off. Humans have unique abilities to connect the dots and use intuition. Machines lack intuition. These tools should be assistants. Engineers have mundane tasks, just like designers. We create a design and then need different variants for error states, hover states, press states, focus states, accessibility, etc. I would love to say, "we created this design; now generate the variants based on these criteria." That's a mundane task. Engineers have similar tasks. Sure, AI can generate code from zero to one, but what about long-lived enterprise products with code from 20 years ago? Adding new code without considering the old hacks and workarounds could break things. Refactoring and eliminating technical debt require strategy and thought. You can't just replace code without understanding its impact. AI might create something small, but it won't understand design systems, platform inconsistencies, or our strategy to address these over time. Maybe one day software will reach that point, but not soon. Even as these technologies evolve, we must consider the human component.

Yuriy: Okay, thank you, Larry. We are almost out of time. Any final comments for our audience?

Larry: Embrace AI and learn how it can augment your process. Every designer should think about this. Also, think deeper about designing for AI products. Recognize that you need to shift your mindset. Think about how AI interacts with users and be ready to change and evolve your design process. And lastly, soft skills are incredibly important. Be able to support and validate your work, stand up for it, and tell your story in a way that excites people.

Yuriy: Thanks, Larry. I think we sparked some ideas in many designers and design managers. Do you agree with everything we discussed? Do you think designers will have to change, or will everything stay the same? Please leave your comments, and subscribe. We will have lots of other conversations on this topic. So stay tuned. Thank you, Larry.

Larry: Thank you.

That’s all for this time. If you think your colleague or friend could benefit from these tips, please share this episode with them. Thanks!