AI In Your Product: Magic or Transparency

Yes, AI is pretty nifty. But when integrating AI into your product, you have two paths:

One—seamlessly integrate AI into the product, making it feel like magic for the user. The product is smarter, which makes the user feel smarter. Until it isn't. Sometimes, AI things go wonky (technical term, I'm sure), leaving your users frustrated and blaming your product.

Or two—call out that it's powered by AI. However, this could prevent users from trusting your product or make them opt out of using that feature or product altogether.

Which path do you choose? When and why?

The answer, of course, depends on the experience you're designing—and your users' tolerance for unpredictability.

If your AI feature is additive—something that enhances but doesn't make or break the core workflow—magic might be the way to go. Think auto-tagging content, generating a first draft, or suggesting an action. The risk is low, the payoff is high, and when it works, it feels delightful. When it doesn't, users can easily course-correct.

But if the AI is critical to success—driving decisions, surfacing key insights, or replacing a human task—it might be better to show your work. Users want to understand what's happening under the hood. They want transparency, clarity, and sometimes even a little control. Acknowledge the AI, set expectations, and design affordances that allow users to review, edit, or override as needed.

There's also a third path: contextual transparency. You don't need a flashing "AI did this" badge on every screen—but you can signal it thoughtfully. A well-placed tooltip, a short explainer on first use, or subtle visual cues that communicate what's automated versus manual. Transparency without fear. Trust without overwhelm.

Ultimately, it comes down to trust, clarity, and control. Not just what the AI does—but how you help the user understand what just happened, what they can do about it, and whether they feel empowered or undermined by the experience.

Because the real magic isn't that AI is in your product. It's when your user still feels in charge—even when they're not.

5 Tips to Improve Your UX Team

Building a great UX team is more than just hiring ‘better designers’. Even the best designers will fail if their work environment doesn’t set them up for success. Over the past decade of leading, building, and growing user experience teams, there are five key areas I focus on that result in noticeable and speedy improvements.

Resourcing

It’s hard for a UX team to be successful if you don’t have the team to keep up with the demand. The backlog only gets bigger and the design debt builds up. You need to ensure the UX team is staffed appropriately to the Product and Engineering teams you’re working with.

If the Product team is bigger than the UX team, the workload demands will quickly surpass the team’s capacity. From there, the UX team could get a reputation for being slow or the bottleneck, or worse, teams start to work around the UX team resulting in poor experiences making their way to your users.

If the Engineering team is bigger than the UX team, then they’ll quickly burn through the work that has been properly researched, designed, and validated. Now engineers don’t have anything to work on, and again, the UX team gets a reputation for being slow.

My rule of thumb for UX team staffing is typically 1:1:1—one product manager to one UX designer to one engineering team. This is only a starting place; you may need to increase or decrease those numbers, and it may vary by team. For example, one team might only work on a set of APIs, so they’re not likely to need a dedicated UX designer.

Team Culture

A UX team one of the few jobs where 25% of our role is criticizing others’ work. If the team doesn’t have a healthy culture and strong guidelines for healthy critiques, then the team will spiral out of control. There are several great resources on creating a healthy environment for critiques. Below are two of my favorite:

• Book: Discussing Design: Improving Communication and Collaboration through Critique
• How to Cultivate Healthy Design Feedback

Beyond critiques, the team has to like and trust each other. That means you need to create time and space for people to connect at the human level. I found that a monthly happy hour or brunch (for international teams) helps, as long as the time is engaging and helps build connections between each other.

Streamline Processes

Every new design hire brings their ideas of how work should be done. Right or wrong, those ideas are typically different from how the team is currently operating. When teams aren’t operating under the same processes or quality standards, you have a misalignment. With your team, define your design processes, critique processes, escalation process, file storage and labeling, documentation standards, meeting cadence, etc. Write it down and have the team all sign off on it. Now the team can work on fun parts of the job and solve real problems and make users happy.

And by the way, you just wrote 95% of the onboarding docs for all your new hires. Good job, you.

Prioritization

There likely will never be enough designers to do everything, which means you need to work with your counterparts to determine how the UX team can deliver the most value for the company and users.

Now, prioritization isn’t just saying ‘no’ to people. Every decision has to have a reason, and you have to realize that you’re not a dictator… others have to agree with your decisions.

Your team should focus on projects that move the needle on your business KPIs. That’s it. That is the framework that should be used with all your Product cohorts when prioritizing design workstreams. You should be asking:

• What KPIs does this project support?
• Is it more important than X, Y, or Z?
• Do we have the skillsets to deliver a quality outcome?

Be Visible

Make the design work visible to the company. This could be regular newsletters where you share design prototypes or research insights. Or it could be smaller, maybe a regular email to the senior leaders of the top 3-5 design wins or outcomes. It could also be presenting at the company All Hands meetings, or giving your team shout-outs regularly in front of others. The important part is to socialize the work and impact the UX team is doing.

It’s That Simple… in Theory

Easy, right? Of course not. That's why they pay you the ‘big bucks’. Not all of the areas will be problem areas for you and your team. But hopefully, this can serve as a guide for areas to evaluate and look for hot spots or areas you can improve.

The Case for Outputs

Scrolling through twitter I stumbled across Barry’s post—Your Mission is to Produce Outcomes, Not Outputs—it got my interest immediately. As I was reading Barry’s post, I found myself nodding my head. A lot of good points. But I think it’s easy to miss what Barry is stressing, which is essentially to deliver value you can measure. So many people interpret this as ‘skip documentation and just ship something’. But that’s not the case at all. Sure, outputs aren’t typically a business model, but they’re tools that enable speed and quality.

In many cases, the maturity and size of the team determine the need for outputs. For a small, stable team, where the vision is clear and there are no blockers, many outputs could be skipped. But for large teams, often with various layers of stakeholders, outputs can help a team fire on all cylinders, reduce duplication, and quickly transfer context.

Yes, businesses survive on outcomes

Essentially Barry is saying the only real deliverable that matters is the outcome—the thing that moves the needle. Process maps don’t generate value, but a product that eliminates those process pain points might be worth more than gold. Outcome-based businesses value results. If your customers don’t succeed your effort is wasted—regardless of all the output you create along the way.

So many times, teams are showing dashboards of vanity metrics, or chart porn. These outputs make the team look busy, but it’s the same type of busy as hamsters on their wheels.

However, there can be a case made for outputs with outcomes. Outputs can be key to making sure outcomes are targeted, relevant, and impactful.

Outputs help makes success repeatable

Some products just work—AirBNB, Instagram, etc. There was a clear hole, the founders knew the space and how to solve it, and they nailed it. In these cases, the founders were scratching their own itch—they knew the problem space well. So why doesn’t everyone just do that? Well, it’s hard. And often times, teams are paid to scratch someone else’s itch. A lot of teams have found that a process can help them repeatedly hone a solution into a valuable product. A process, or checklist, is a way of ensuring you don’t forget key steps when you’re tired, excited, or just pressed for time.

These checklists often generate outputs that serve as inputs into next steps. For example, in the product design world, we generate personas to better understand the type of users we’re targeting—these are typically in the form of presentation slides or poster outputs. We then use those personas to map their journey in a given scenario and highlight their pain points (typically delivered as a poster). Then we co-create solutions around those pain points, validate, then integrate those solutions into our product. We follow this process whether it’s a new product or existing, digital or physical. It always works. If we jumped right into the journey map, we might gloss over one of our most important personas.

But checklists aren’t just for product development or innovation. Many industries use checklists to ensure a thorough job is complete—safety inspectors, pilots, and even busy shoppers. In fact, pilots depend on them for every flight. Yet we don’t say ‘a pilots job is to fly, not check lists’.

Checklists help us stay on track, and follow a process we’ve proven to work.

Outputs can reduce duplication

Often times different products within a business or organization will share similar users, scenarios, workflows, etc. In those cases, teams often dig up past project outputs to get a better understanding of what we know, what we don’t know, and what to validate. Now, typically we don’t take those old outputs as gospel, but it provides a baseline to validate and build on.

Without those past outputs, we start over fresh. This not only burns additional cycles, but it can start to negatively impact your stakeholders. If you interview a key executive every year asking similar questions each time, by the third time they might not accept your call.

Similar to history, if you don’t learn from your past outputs, you’re doomed to repeat the same discovery.

Outputs transfer knowledge

But the most powerful use of outputs is to preserve the context of the work. It could be helping the customer understand the impact of your findings or vision, or merely to educate so they can empathize better.

In large enterprise companies, it’s not usual for teams to morph over time—team members get promoted, move to other teams, or even other companies. Outputs help the team document knowledge along the project in meaningful ways, onboard new team members, and quickly answer ‘why are we doing this?’.

Rather than depending on tribal knowledge over time, new team members can review a few key outputs and get up to speed in no time.

Outputs create the outcome

Okay, not really. But often times, a proven process often generates and iterates outputs, and those outputs become inputs for future steps, and so-on. Those outputs and iterations will help ensure you’re making good decisions. It will help make sure your final solution is on point. It will help track your success, and know when you get there.

Move fast but don’t break things

Facebook’s motto used to be ‘Move Fast and Break Things’. Now, I have no idea how Facebook actually works, but hearing that motto and things like ‘Outcomes over Outputs’ always conjures images of bus-boys rushing to clean tables and get dirty dishes back to the kitchen only to have a bin full of broken dishware.

Barry is right—don’t fetishize outputs, because outcomes are the real value. But don’t throw outputs out the window; just find the right output. Realize they’re tools that can often help large teams get to value faster and more often.

Perils of A/B Testing

I’ve been enamored with SquareSpace lately after testing it for my wife’s business site. It’s an amazing tool. Once everything was in place using their free trial, I went into the billing section to purchase the service. That’s where my confusion began.

During the free trial I’ve looked at SquareSpace’s pricing plans several times and they’ve always had an $8 Personal plan, $16 Professional plan, and $24 Business plan, billed annually.

But this time their plans didn’t show any sign of the annual discount: plans were now $10, $20, and $30. I accepted this as the normal cost of doing business—I waited too long to purchase and they’ve raised their rates.

A few days later SquareSpaces rolls out a new feature and posts about it on their blog—Commerce for All (emphasis added):

… That’s why we’ve added the ability to accept donations or cash gifts, as well as sell a single item, to our new Personal plan, which starts at just $8 per month

… For those folks who have basic e-commerce needs without integrations, we’ve created our new Professional plan – with the ability to sell up to 20 products – starting at $16 per month.

For more information on each of our plans, please visit our pricing page. Please note that with this update, our plan pricing remains the same.

Now I’m starting to question my purchase, and for that matter, SquareSpace. I paid 20% more for my product, but a company communication posted after my purchase advertises a lower price and reinforces that prices didn’t change. Hmm.

I decide to go into my SquareSpace Admin section to see if changing my plan gives me the current prices listed on their website. But the Billing section doesn’t even list the correct plans (Personal, Professional, Business) available:

Even more confusing, I singed up for the Business plan which is advertised to have unlimited pages, products, and users. If the Business plan gives you unlimited everything, then what is the Unlimited plan? And why is it cheaper than my current plan?

After a few emails back and forth with SquareSpace, everything was settled. It seems that I purchased in the middle of their A/B testing and just happened to be the lucky winner of a higher rate: $360 vs $288 for the year.

That in itself is not the problem. Like I said earlier, I accepted that the rates raised. But everything on the site pointed to lower rates than what I paid, and no reference to the higher rates I was charged. This led me to believe it was a genuine billing mistake.

The issue is the lack of consistency:

• Different prices depending on the day
• No explanation of pricing changes or testing in the support area
• New blog posts referencing the ‘old’ prices
• Admin panel showing plan names that I had never seen before

Suggestions for Smoother Testing

1. Don’t reference constants (such as a price) in blog posts. Sure this isn’t possible all the time, and you certainly don’t want to alienate readers by being coy with key information such as price. However, things change; especially prices. In SquareSpace’s case, they could have referenced plan names rather than prices to future-proof their content.
2. Perform a content audit before the A/B testing phase. This audit gives visibility to times where you might have talked about an item/topic that is the subject of an A/B test. This also segues into the topic of modifying content of previous blog posts or writings. Is it okay to do? I don’t know, but I think it heavily depends on the company culture, topic, and method of communication. In the case of SquareSpace, I think it would be perfectly fine to edit past posts to remove all references to prices.
3. Keep updated internal documentation on where key data is referenced. That way when a company decides to move forward with A/B testing, they could reference their internal wiki page on that topic. A page about pricing might say something to the affect of ‘Prices and plan names are listed on …/pricing/ and plan names are listed on …/admin/billing/’. This gives you a checklist of things to update before rolling out the test.
4. Keep user’s experiences consistent. I signed up for SquareSpace’s free trial when the $8/16/$24 plans were active. But when I clicked the ‘Trial Account — Upgrade Now’ button I saw different prices; I should have seen the same prices that convinced me to create my free trial in the first place. The same thing goes for the email SquareSpace sent saying ‘Your 14 day trial is almost up… upgrade now’. Only new users should be funneled into the A/B test, not users in the middle of the trial/conversion process.
5. Communicate the test outcomes to your customer service team. Your customer service team is the first line of defense, and often the face of the company for most customers. They should be kept up to date or every customer-facing decision. This cuts down confusion and enables your service reps to solve customer issues at lightening fast speeds. It seems as SquareSpace got this one right!

When All Else Fails

Even if you have the best execution plan ever planned in the history of planning, hiccups will inevitably occur. And when they do, you need to have a top-notch customer service team at the ready to deal with issues. SquareSpace had exactly that.