People form a visual impression of a product in about 50 milliseconds, and after judging its credibility based on its appearance, they begin to assess the rest. Does it help me do my job more effectively? Can I get the work done using it? Appearance, utility, usability; a product can look nice and fail at the rest.
Appearance buys attention, not adoption
We extend more patience to things that look good — the aesthetic-usability effect, where an attractive interface is judged easier to use.
A clean, on-brand product earns the first moment of attention and a little goodwill, but it does little to drive adoption. These days, almost everyone uses a design system to deliver that visual consistency. But with the pressure to ship faster using AI, the risk now is that teams put their energy into appearance and shortchange the other dimensions that determine whether that solution will be incorporated into how users work.
What kills adoption
One of the most common calls I got as a UX leader was a client whose new solution wasn’t being adopted. The client was bewildered, after all the money and effort, that their great idea hadn’t become everyone’s new favorite solution. Were there interface and usability issues? Sometimes. But it was usually one of two things: (1) the community already had too many tools, never rationalized or integrated — I had one client who’d built more than 70 solutions for their salesforce and then wondered why use was low — or (2) the tool solved a problem the user didn’t have. It was an idea from HQ or sales ops that was low on the field’s priority list, or it was never clear how it worked with tools they already used. That’s utility, and it has undermined more projects than I can count.
Utility and usability are what decide it
The two factors that determine whether a solution will be used are utility — is this for me? — and usability — can I do this? These can only be achieved by understanding the user. This is the human side of product adoption — the part features alone don’t solve.
Even deep expertise isn’t enough
When we built the Javelin Sales Compensation Scorecard at ZS — now the Reports product, JSCR — we had every advantage. At the time, ZS processed compensation for a large share of US pharmaceutical sales reps. We evaluated sanitized scorecards from client projects and found that about 80% shared the same core elements. In spite of all that data, we only had anecdotal evidence about what the reps wanted to see, so we iterated and validated the design with reps and managers before we shipped. That ensured the solution reflected the rep’s actual needs rather than our assumptions. Years of domain expertise didn’t change the fact that we still had to engage with users. Building with AI is no different in that regard.
Design for the first session, not everyday use
Most teams optimize for everyday use, but the first session has a different objective; it needs to help the user realize value, so they decide the product is worth the effort to learn and incorporate into their work. IBM’s framework for product experience reminds us of these fundamentals. It names “Get Started” — how do I get value? — as its own distinct experience, separate from everyday use.
Scope it to the one or two things a new user needs to accomplish, and you have the opportunity to create a more sticky experience in the long run.
Where AI fits
None of this is an argument against AI; I have no doubt that using AI solutions will make interfaces more polished and ship features faster than ever. What it won’t do is determine what “for me” means for your user, or design that first-use experience. That still requires observing or speaking with users. Depend on AI before you’ve done that work and you’ve missed the mark, but gotten there faster.
What this means if you’re scaling
If you’re scaling fast, appearance is the easy part. The harder, more important question is the ecosystem your solution will succeed in. What is already competing for your users’ time and attention? A tool can be well-designed and even useful and still lose, because it’s the seventy-first thing asking for time and attention. Understand that ecosystem before you build — what people already use, and what you’re asking them to make room for — and you’ll know whether you’re solving a problem they have, or just adding to the pile. It’s the user side of what I argued on Tuesday: the teams that win encode who they’re building for, not just how it looks.
Leave a Reply