When I get on a call with a new prospect about helping them with some sort of product/UI/UX design issue for an analytics SAAS or enterprise application, it's typically after a period of "DIY" investment that isn't progressing the way they had hoped.

It might be that they're not seeing the results quickly after "doing a lot," there are internal debates about "what's right for the user," there's a loud opinion/voice about design that needs to be "checked," or they're starting a new initiative—and this time, they've learned it's a lot faster and cheaper to do the design at the beginning instead of at the end 😉

All of these things are ok—it shows growth when somebody raises their hand and says, "I know I/we need outside help."

I imagine most of you have done DIY projects at home yourself; and I love how YouTube has given us access to so much more information. The challenge is often not knowing what you don't know about a project or initiative.

And the not-knowing manifests itself in the form of taking a lot longer to get results, and spending a lot more money (frequently).

Why?

Because we often end up focusing on building the tech and, "getting it out there so we can get feedback."

The thing is, getting feedback quickly isn't really the goal of product.

The goal of product is to produce value/benefits/outcomes.

I believe Marty Cagan frames this as "time to value" which I really like. If you accept this framing, then you realize that shipping the technology artifact is the beginning, not the end, of the game—and that you get no points in this game for simply shopping the tech.

The points in this game comes when the price the user is paying in dollars or time is lower than the value they perceive they are getting.

For your business, this can be all sorts of increase KPI metrics; for actual end users, it means "did we make this person's life better by _____"? The latter can be measured, but most founders and product leaders can only define the business metrics; the additional sales revenue they want to capture, the increased product adoption, or reduced attrition.

However, the user's life being improved is inherently tied up in all of this. If they're not buying , not renewing, or not using, then the end user isn't seeing the value—even if the buyer upstairs in the C-suite buys into all the theoretical gains that your SAAS analytics or enterprise AI solution is providing.

So, where might things have gone wrong for you when you tried doing your own UI/UX design - or having an untrained developer/engineer handle it?

Here's are 10 things I often see or here when I get on calls with founders and product leaders.

1. You see UI/UX/data viz design as something that is the role of "front-end development" or an analyst. After all, you grabbed a UI/design library that is built with JS/CSS components, and hell, what are you paying this person for if not that? What you didn't see is that you've been asking the team to go go go -- to move faster -- which means shortcuts are taken. It means developers don't want to customize or have to deal with one-off components that sit outside the framework they chose—which they chose because you stated that speed was #1 goal. They've really been tasked to build the front-end. So, when your home has a remodel project, and the builder shows up, what might their reaction be when you ask them to come up with some blueprints first—and you expect them to be both good, in service of your business goals, and you want to "like" the design too.
2. You have a developer/engineer or jr. designer who "likes" doing the UI/UX/viz  work—but lacks the skill to do it well—yet nobody knows there is a skill gap because they're "the best" on your team. While the interest might be better than indifference, speed is still the driving metric the team is operating—speed to deliver sprints/outputs on a schedule. The thing is, you really don't know if they're doing it well or not—beyond your personal opinion about whether the design is "good." So, it's mostly just opinion wars—and maybe you're too busy to think about all the countless small-design choices that ultimately add up into the "UX" that is perceived by your users and customers. Where are the results of the work though?
3. Despite doing your design "in-house," and creating a lot of UI artifacts, you're not seeing progress on your business goals.In other words, it's clear your design resources are doing work, but that work is not translating into the biz our customer results you seek to create. Or worse, you don't actually know if the design is "better" beyond how it looks to you, let alone on the right track, because you don't know what the right success metrics or signals are to tell you if progress is being made.
4. The "magic, vision, or your IP/special sauce—the things that are supposed to make your enterprise AI or SAAS analytics product a powerful alternative to the status quo—simply aren't manifesting themselves in a clear way that customers love. This often happens when your designers/UX resources do not understand how you're currently (or going to) create impact in the market through your unique combination of tech+data+UX. They don't know why buyers buy, or why users stick around. Or, the strategy you gave them is simply too "in the clouds" to be what I call "design-actionable." Worse, they might have jumped in anyways with design because—after all—designers gonna design, right?
5. To get started, you found a dashboard template, competitor UI, a UI from some other context that you think might "fit", or a design library and then customized it—because you're masking the fact you're not comfortable doing, or having your current team, do the hard 0-to-1 design yourself.  Deep inside, you probably know that shortcuts often don't produce outsized results—and if you were redoing your bathroom at home for the "first time", you probably wouldn't take shortcuts unless you knew what you were doing—because you had built a lot of bathrooms before.
6. You built an MVP/POC to prove out your tech. And the longer you used it, the more intuitive it got—so instead of tossing it out as a POC instead of a product, you kept building on top of it. Until you realized nobody else understood it. Need I say more on that? You probably went native, plain and simple.
7. You're afraid to make the UI/UX too opinionated and resort to offering "customization" early on as a way to ensure all possible users can do [insert job/workflow/tax] their way.  After all, you wouldn't want to lose a customer, so best to support all of them. Unfortunately though, nobody is understanding the value, the mental model, or the utility of your solution because all the work has been pushed down to them in the form of customization.
8. You abstracted aspects of the product to make things easier for engineering, or so you could build your product on top of your own API—but your data/object/technical model does not match users' mental model. So in effect, you prioritized making engineering's life easier or faster above customer value. The thing is, enabling your data or engineering teams to be able to move more quickly doesn't mean they are moving in the right direction. More velocity? Maybe; but if you're not going the right direction, does it matter?
9. You believe you know good design when you see it. After all, you have eyes, and you know what "easy to use" feels like. (Insert comments about your favorite Apple product or iPhone, which you want your product to emulate). Maybe you even hired a designer to take your UI and "make the visualizations and UI look good" for demos or whatever—but despite passing your aesthetic test, you're not seeing your KPIs move. You want that Apple design feel, and you assume when that feel arrives, you'll see the outcomes you seek. So far though, they're not appearing—and while now you're not embarrassed anymore to show your UI, you realize that customer's don't really care how you feel about it nor do they care if it is Apple-like.
10. Because your data science/AI/ML modeling was successful, difficult, and expensive, you didn't give much thought to the UI/UX "around it," because the outsize value of your AI should be obvious. Except, it kinda wasn't to end users. In fact, maybe it was threatening in its accuracy or power—it was almost too good. And that made users nervous. Maybe technically right model does not = a desirable, usable, and useful interface and customer experience.

Learning Figma is the least of your challenges, just like understanding Python isn't going to make somebody a solid data scientist. DIY product/UI/UX design is fine—if you have the time, budget, and patience for things to take longer than you'd like, to deal with the ambiguity inherent in product design work, and you're comfortable starting over when you've sunk too much cost into a direction that's not serving your customers or your business.

If you're doing it "right," customers and users should recognize the value of your solution, find it delightful/usable, or perhaps not even comment on it because the UI/UX is so invisible to them—and as a result, buyers will be buying, because the value is obvious.

Photo by Volodymyr Hryshchenko on Unsplash