SriG's Blog

Some years ago, a designer assigned to my team and I became interested in a central question about recommendations.

We were working on shopping experiences, and it seemed obvious that people approached shopping with very different intentions. Sometimes you know more or less what you want. You are trying to solve a problem, find the right product, perhaps compare a few alternatives, and get on with your life. At other times you are browsing. You want to see what is out there, discover something you hadn’t considered, perhaps even be surprised.

These are not necessarily different kinds of shoppers. The same person can be highly mission-oriented on one visit and looking for inspiration on another.

The designer and I wanted to explore what those differences should mean for the recommendation experience itself. Should a mission-oriented experience emphasize precision and close alternatives? Should an exploratory experience deliberately introduce more diversity or novelty? How much should recommendations reflect what the system already knows about you, and when should they take you somewhere new?

We thought this was a design problem.

Design leadership did not.

The proposal was turned down. There were plenty of conventional interfaces that needed designing, designers supported multiple teams, and this was not seen as a particularly high-priority use of design resources. Perhaps it was not even considered part of the designer’s core job.

I have thought about that episode quite a bit since.

Nobody had made an explicit decision that user-centered design should stop where the recommendation algorithm began. It was simply where the organizational boundary had ended up.

Designing the algorithmic experience

Consider an ecommerce search-results page.

A designer may determine the placement of the search box, the appearance of the filters, the information shown on a product card, the spacing between results and what happens when you tap something.

But much of what determines whether the experience is any good comes from somewhere else.

Which products appear? In what order? Are the first twenty results essentially variations of the same thing? Does the system understand what you mean rather than just the words you typed? Does it favor familiar products or expose you to something new? How much does it personalize? When should it stop personalizing?

The same is true of a recommendation carousel, the home screen of a streaming service or a social-media feed.

From the user’s point of view, these are not interfaces surrounding an algorithm. The results are the search experience. The recommendations are the discovery experience. The sequence of posts is the feed.

The algorithm is making decisions that, in a less dynamic product, we would readily recognize as design decisions.

There is some evidence that organizations struggle with this boundary. Research on teams building AI-enabled products has found that the conventional separation between UX and technical development becomes difficult to maintain once model behavior itself shapes the user experience. Subramonyam and colleagues describe the need for “leaky abstractions” between UX practitioners and AI engineers because user needs, data, model behavior and interface decisions cannot really be separated cleanly [1]. Other work has documented similar difficulties for UX practitioners trying to engage with machine-learning teams and model-centric development practices [2].

This does not mean that designers are being negligent. In my own experience, the designer was eager to work on the problem. The organizational definition of design—and the way scarce design resources were allocated—made it difficult.

What about human-centered evaluation?

One response to this argument is that sophisticated recommendation and ranking systems already incorporate plenty of user feedback.

And they do.

Spotify has used interviews, behavioral data and satisfaction surveys to study music discovery and to develop measures of whether recommendations actually satisfy listeners [3]. YouTube has described supplementing watch time with surveys asking viewers how they valued the videos they watched [4]. Meta has used in-feed surveys about whether videos match users’ interests to train models that feed back into ranking [5]. Google has long used human quality raters to judge search results and help assess proposed changes to its ranking systems [6].

These are important advances over treating a click, a purchase or another minute of scrolling as proof of a good experience.

But I am not sure I would call all of them design.

Suppose we show people recommendations and ask whether they are relevant. We collect enough judgments to build a much better relevance model. We may now have a system whose objective is considerably closer to what users actually value.

We have improved the feedback loop.

But we have not necessarily asked what kind of recommendation experience we wanted to create in the first place. That was the question the designer and I wanted to investigate.

For a shopper with a clear mission, perhaps relevance really does dominate. But someone who is browsing may consider a recommendation set poor precisely because everything is too similar to what they have already seen. “Relevant” is not wrong; it is incomplete.

The design work lies in understanding those different states well enough to say what the system should do in each of them.

In other words, evaluation asks whether the algorithm succeeded. Design asks what success should look like.

That is a more consequential distinction than it may initially appear. Once a team has settled on click-through rate, conversion, watch time, relevance or any other measurable objective, data science has powerful tools for improving it. The difficult decision may have happened earlier, when somebody—explicitly or otherwise—decided that this was the thing worth optimizing.

UCD ought to have something to say at that point.

UCD has the methods

When I first started thinking about this gap, I wondered whether conventional UCD simply lacked the tools for working with algorithmically generated experiences.

There is a substantial body of research on human-centered recommender systems. Researchers have long argued that recommender systems should be evaluated on more than predictive accuracy, incorporating factors such as perceived usefulness and satisfaction [7]. Human-AI interaction research has similarly expanded design thinking beyond the visible interface to questions of expectations, control, failure, correction and adaptation over time [8].

I don’t think any of this requires exotic new research methods. We can put different recommendation sets in front of users and ask them to compare them. We can watch people shop and understand when they want help narrowing and when they want help exploring. We can investigate why a technically relevant set of results nevertheless feels monotonous. We can prototype different algorithmic behaviors just as we prototype different interaction behaviors.

I believe the core problem is what happens to those insights afterwards.

Design organizations are very good at translating research into screens, flows and interaction patterns. Machine-learning organizations are very good at translating objectives into labels, datasets, features, loss functions, ranking policies and metrics.

Algorithmic products require the first set of insights to make their way into the second set of artifacts.

That handoff is much less mature.

This is not universally true, and I don’t want to imply that nobody is designing algorithmic experiences. Spotify’s work on its “Shortcuts” feature is an interesting counterexample. The team developed a personalized area at the top of the Home screen by working on the UX and the recommendation logic together. What appeared there, how it was organized and how personalization worked were parts of the same product problem [9].

At eBay, we also built a personalized recommendation feed where the designer was involved throughout—not just in how the feed was presented, but in discussions about what kinds of recommendations it should contain and what the resulting experience should be. This kind of collaboration certainly happens. My point is that it is not yet treated consistently as part of the design remit.

Human-centered evaluation versus algorithmic experience design

The distinction is subtle but important. A survey used to improve a relevance model starts with an existing conception of what the algorithm should do and measures how well it does it. A conventional optimization loop might look roughly like this:

Algorithm → results → user behavior or judgment → metric → improved algorithm

Whereas designing the experience itself starts further upstream. A design-led process has more work before the algorithm enters the picture:

User intent → desired experience → properties of that experience → algorithm → results → evaluation

The second sequence is obviously messier. “Desired experience” does not arrive as a number. Terms such as inspiring, diverse, trustworthy or useful are frustratingly underspecified if your next task is to write an objective function.

But that is exactly why design and data science need to work on the problem together.

Take “inspiration.” A product manager could reasonably tell a recommendation team that shoppers want more inspirational recommendations. But what would the team optimize?

More novelty? More stylistic variation? Products from adjacent categories? Greater distance from the user’s historical preferences? A sequence that begins with familiar products and gradually becomes more exploratory?

Those are not interchangeable ideas.

A conversation between designers, researchers and data scientists can turn a fuzzy experiential goal into something that can be investigated, represented and eventually measured. The data scientist may also discover that the original conception was wrong: perhaps users move rapidly between exploratory and mission-oriented behavior, or some forms of diversity help while others simply make the system feel random.

The design should change in response.

The role of product management

Product managers already connect much of this work. A good PM understands the customer problem, works with design on the experience and works with data science on objectives and metrics. Without that role, none of this is likely to hang together.

But there is a cost if all communication between design and data science has to pass through product management. Some ideas lose important detail when translated into requirements. “Users want more inspiration” is one of them.

There is value in the person who has been observing users sitting directly with the person who understands how recommendation candidates are retrieved and ranked. One can push on what inspiration really means; the other can push on whether the proposed distinction is detectable, representable or even internally coherent.

This is not about bypassing the PM. It is about making the relationship triangular rather than sequential.

I have seen highly productive direct relationships between product and engineering, between product and design, and between product and data science. For algorithmic interfaces, the design–data science edge of that triangle deserves much more attention.

Perhaps we need a different design artifact

There may also be a practical problem here.

Designers have artifacts that make their intentions tangible. Wireframes, prototypes, interaction specifications and design systems can be discussed, critiqued and handed to engineering.

What is the equivalent artifact for the behavior of a recommender or a feed?

I don’t see one used consistently.

An algorithmic experience specification might be useful—not as another heavyweight document, but as a way of making the intended behavior of the system explicit.

For a particular experience, it could capture the user states that matter, examples of what good results look like in each state, the qualities the results should exhibit, and important failure modes.

For our shopping example, it might say that a mission-oriented recommendation set should remain close to the user’s expressed intent and make alternatives easy to compare. An exploratory set might be allowed to range further, but should still have a comprehensible connection to what brought the shopper there. Ten superficially different products that are effectively identical might be considered a failure even if each has a high predicted click probability.

Those statements are not yet metrics. That is fine. They give the team something worth trying to measure.

Human judgments can then help refine the criteria. Behavioral experiments can tell us whether the resulting experience actually changes outcomes. Eventually some of the judgments may be automated.

But the design intent has not been reverse-engineered from whatever happened to move CTR.

LLM judges make this more important, not less

The recent enthusiasm for LLMs as judges makes the issue especially timely.

It is becoming increasingly feasible to evaluate very large numbers of algorithmically generated outputs against fairly sophisticated criteria. An LLM could, for example, score recommendation slates for relevance, variety or coherence far more cheaply than a panel of human judges.

That solves a scaling problem. It does not tell us what to ask the judge.

If we ask a model to evaluate “diversity,” somebody still has to decide what diversity means for the experience. Across brands? Styles? Price points? Categories? Use cases? How much is useful? When does it become distracting? Should it matter to every shopper or primarily to someone in an exploratory state?

Automating judgment without answering those questions simply lets us optimize an underspecified idea faster.

The harder work remains human: understanding the experience we are trying to create.

Designing the part that matters

We have become remarkably sophisticated at designing the portions of digital products that someone explicitly places on the screen.

At the same time, an increasing share of what appears on that screen is selected by systems that no designer directly specifies.

That should change our idea of where design ends.

A beautifully designed search page with poor results is a poor search experience. A polished recommendation module full of near-identical products is a poor recommendation experience. An elegant feed that keeps showing you things you don’t want is not rescued by excellent interaction design.

The pixels still matter. But they are no longer the entire design surface.

Designers do not need to write ranking models. Data scientists do not need to become interaction designers. What needs to change is the assumption that the handoff between those disciplines occurs at the edge of the content.

For algorithmic products, my hope is that some of the most important design work happens beyond the visible interface—that the design surface does not end where the algorithm begins.

-SriG

References

[1] Subramonyam, H., Im, J., Seifert, C. & Adar, E. Solving Separation-of-Concerns Problems in Collaborative Design of Human-AI Systems through Leaky Abstractions. CHI 2022.

[2] Muralikumar, M. D. & McDonald, D. W. Analyzing Collaborative Challenges and Needs of UX Practitioners when Designing with AI/ML. Proceedings of the ACM on Human-Computer Interaction, 2024.

[3] Spotify Research. Understanding and Evaluating User Satisfaction with Music Discovery. 2018.

[4] YouTube. On YouTube’s Recommendation System. 2021.

[5] Meta Engineering. Adapting the Facebook Reels RecSys AI Model Based on User Feedback. 2026.

[6] Google Search Central. Search Quality Rater Guidelines and related documentation.

[7] Pu, P., Chen, L. & Hu, R. A User-Centric Evaluation Framework for Recommender Systems. RecSys 2011.

[8] Amershi, S. et al. Guidelines for Human-AI Interaction. CHI 2019.

[9] Spotify Engineering. Reach for the Top: How Spotify Built Shortcuts in Just Six Months. 2020.