In today’s episode, I’m going to perhaps work myself out of some consulting engagements, but hey, that’s ok! True consulting is about service—not PPT decks with strategies and tiers of people attached to rate cards. Specifically today, I decided to reframe a topic and approach it from the opposite/negative side. So, instead of telling you when the right time is to get UX design help for your enterprise SAAS analytics or AI product(s), today I’m going to tell you when you should NOT get help! 

 

Reframing this was really fun and made me think a lot as I recorded the episode. Some of these reasons aren’t necessarily representative of what I believe, but rather what I’ve heard from clients and prospects over 25 years—what they believe. For each of these, I’m also giving a counterargument, so hopefully, you get both sides of the coin. 

 

Finally, analytical thinkers, especially data product managers it seems, often want to quantify all forms of value they produce in hard monetary units—and so in this episode, I’m also going to talk about other forms of value that products can create that are worth paying for—and how mushy things like “feelings” might just come into play ;-)  Ready?

 

 

Highlights/ Skip to:

(1:52) Going for short, easy wins

(4:29) When you think you have good design sense/taste 

(7:09) The impending changes coming with GenAI

(11:27) Concerns about "dumbing down" or oversimplifying technical analytics solutions that need to be powerful and flexible

(15:36) Agile and process FTW?

(18:59) UX design for and with platform products

(21:14) The risk of involving designers who don’t understand data, analytics, AI, or your complex domain considerations 

(30:09) Designing after the ML models have been trained—and it’s too late to go back 

(34:59) Not tapping professional design help when your user base is small , and you have routine access and exposure to them  

(40:01) Explaining the value of UX design investments to your stakeholders when you don’t 100% control the budget or decisions 

 

Quotes from Today’s Episode

“It is true that most impactful design often creates more product and engineering work because humans are messy. While there sometimes are these magic, small GUI-type changes that have big impact downstream, the big picture value of UX can be lost if you’re simply assigning low-level GUI improvement tasks and hoping to see a big product win. It always comes back to the game you’re playing inside your team: are you working to produce UX and business outcomes or shipping outputs on time? ” (3:18)

“If you’re building something that needs to generate revenue, there has to be a sense of trust and belief in the solution. We’ve all seen the challenges of this with LLMs. [when] you’re unable to get it to respond in a way that makes you feel confident that it understood the query to begin with. And then you start to have all these questions about, ‘Is the answer not in there,’ or ‘Am I not prompting it correctly?’ If you think that most of this is just an technical data science problem, then don’t bother to invest in UX design work… ” (9:52)

“Design is about, at a minimum, making it useful and usable, if not delightful. In order to do that, we need to understand the people that are going to use it. What would an improvement to this person’s life look like? Simplifying and dumbing things down is not always the answer. There are tools and solutions that need to be complex, flexible, and/or provide a lot of power – especially in an enterprise context. Working with a designer who solely insists on simplifying everything at all costs regardless of your stated business outcome goals is a red flag—and a reason not to invest in UX design—at least with them!“ (12:28)“I think what an analytics product manager [or] an AI product manager needs to accept is there are other ways to measure the value of UX design’s contribution to your product and to your organization. Let’s say that you have a mission-critical internal da

Podden och tillhörande omslagsbild på den här sidan tillhör Brian T. O’Neill from Designing for Analytics. Innehållet i podden är skapat av Brian T. O’Neill from Designing for Analytics och inte av, eller tillsammans med, Poddtoppen.