When More Choice Makes a Website Harder to Use: Designing Service Pages for Meaningful Comparison

In 2000, psychologists Sheena Iyengar and Mark Lepper set up a tasting table at an upscale grocery store in California and ran what became one of the most quoted experiments in consumer behavior. One Saturday they put out 24 flavors of jam. Another Saturday, just six. The big display drew more people in: 60% of passing shoppers stopped to taste, compared with 40% at the smaller table. But when the researchers looked at who actually bought jam, it flipped. Only 3% of tasters at the 24-flavor table made a purchase, versus 30% at the six-flavor table (Iyengar & Lepper, 2000, summarized via AcaWiki). More options got attention. Fewer options closed the sale.
That result turned into shorthand for “more choice is bad.” But the study has a real limitation you should know about before building a strategy on it. Across both tables, shoppers bought 35 jars of jam in total. Statistician Jim Manzi has pointed out that using 35 purchases, collected over about ten hours in a single store, to make broad claims about choice is a stretch (Manzi, Uncontrolled, discussed here). The jam study is a real, well-documented finding. It doesn’t prove that trimming your service list will multiply your conversions.
Service pages for web development, ecommerce builds, and app projects run into a version of this problem all the time. A visitor sees three or four packages and leaves without picking any of them. Whether choice is good or bad is the wrong question. The better one is what makes a particular set of choices hard to evaluate, and that question has a fairly specific answer.

Why Service Pages Are Hard to Compare
Most of the confusion comes from a handful of habits. Package names use internal shorthand instead of describing outcomes, so “Growth” sits next to “Pro” with no obvious logic separating them. Feature lists keep growing without showing which features actually change the result for a given business. And scope language like “custom integration” gets used without saying what’s included or who owns what.
Nielsen Norman Group’s university-website usability research illustrates this problem. In one example, a West Virginia tuition table listed in-state tuition and fees at $9,648 and out-of-state tuition and fees at $27,360—a difference of $17,712 per year, calculated from the displayed figures. But the page did not explain what “in-state” and “out-of-state” meant, leaving a consequential distinction implicit. The point is not that NN/g measured a $17,712 misunderstanding; it is that the page made visitors work out what the options meant for themselves. (NN/g, “Explicitly State the Difference Between Options,” 2024)
The result has also proved difficult to replicate consistently. Benjamin Scheibehenne’s 2008 dissertation reports three field and laboratory replications involving 850 participants that did not reproduce the effect, including an attempt to repeat the supermarket jam experiment. The broader evidence remains mixed: a 2010 meta-analysis found an average effect close to zero, while a 2015 analysis found that choice overload becomes more likely under specific conditions. The jam study is a real finding, but it is not a reliably generalizable rule. (Scheibehenne, 2008; Scheibehenne et al., 2010; Chernev et al., 2015)
What the Research Says About Choice Overload
The jam study is one data point, not the final word. Two later meta-analyses tried to settle the question at scale, and they don’t fully agree.
Scheibehenne, Greifeneder, and Todd pooled 63 experimental conditions from 50 studies, covering 5,036 participants. They found that the average choice-overload effect was close to zero, with results swinging in both directions from one study to the next (Scheibehenne et al., 2010). By their numbers, choice overload shows up in some settings and not in others. It isn’t a universal law.
Chernev, Böckenholt, and Goodman took a different approach. Instead of averaging everything together, they analyzed 99 observations covering 7,202 participants to find out what actually drives the effect. They identified four factors: how complex the choice set is, how hard the comparison feels, how unsure people are about their own preferences, and what goal they’re pursuing. Once those four factors were taken into account, the effect of assortment size became statistically significant, unlike the near-zero average in the earlier review (Chernev et al., 2015). Read together, the two studies point the same way. The number of packages on a page matters far less than how complicated, uncertain, and effortful the comparison feels to the person making it.
Start With What the Buyer Can’t Compromise On
Before someone can weigh options properly, they need to know which of their requirements are fixed and which are flexible. NN/g’s research on decision strategies frames this as the difference between compensatory choices, where a weak attribute can be made up for by a strong one elsewhere, and noncompensatory choices, where missing one requirement rules an option out no matter what else it offers. Their testing also found a practical limit. Once a comparison tool shows more than about five items side by side, people stop comparing in detail and switch to quick elimination instead (NN/g, “Compensatory vs. Noncompensatory: 2 Decision-Making Strategies”).
A service page can help by bringing up the questions buyers are already asking themselves. What outcome am I trying to get? What systems does this need to connect to? What’s my real budget range? What happens after launch? Once someone knows which of these are non-negotiable, they can drop unsuitable options early, before they ever get to a detailed comparison.
What a Useful Comparison Needs to Show
Purpose and fit. What business problem is this built for, and when would someone pick it over the alternative?
Functionality and deliverables. What the buyer actually gets, described as outcomes rather than internal jargon.
Scope, inclusions, and exclusions. This is where confusion hides most often. A clear line between what’s covered and what isn’t saves everyone from finding out mid-project that something they assumed was included wasn’t.
Integrations and dependencies. If a build depends on connecting existing systems or migrating data, say so on the page. Don’t leave it for a proposal that arrives weeks later.
Cost and ongoing responsibility. The headline price rarely tells the whole story. Maintenance and recurring costs should be just as visible as the upfront fee.
Designing the Comparison Itself
Baymard Institute’s research on SaaS pricing pages is directly relevant here, because a SaaS plan matrix and a development-service comparison both help people choose between overlapping offerings. Baymard reported that plan matrices in its large-scale SaaS usability research contained an average of 40 distinct features. Its testing found that long, unorganized lists made features harder to locate and understand; some participants left the matrix to search for explanations of unfamiliar terms. Baymard warns that users who cannot find features important to their needs may conclude that a service does not offer them and drop it from consideration. Its recommended fix was not simply to reduce the number of features, but to group related features under clear headings, order groups by importance, and keep plan names and prices visible while scrolling. (Baymard Institute, “SaaS UX: 5 Ways to Improve the Scannability of the Plan Matrix,” 2021)
Baymard’s separate research on ecommerce comparison tools backs this up from another angle. Letting users hide attributes that don’t differ, and using consistent row styling so the eye can follow a row without losing its place, both made the comparison noticeably easier for people in testing (Baymard Institute, “4 Ways to Optimize the Comparison Feature for Scanning,” 2022).
Mobile needs its own note, because it’s easy to misread the accessibility standard here. WCAG’s Reflow criterion (1.4.10) does make an exception that lets data tables scroll in two directions instead of collapsing into one column. But the exception is narrow. It covers a table’s data cells because of the real two-dimensional relationship between row and column headers, and it doesn’t cover the headings or text around the table, which still have to reflow normally (W3C, “Understanding SC 1.4.10: Reflow”). A short five-row service comparison like the one above doesn’t need the exception at all. It can and should stack cleanly on a phone.
When a Table Isn’t Enough
Tables work best when the attributes being compared are stable and truly parallel. Custom development rarely works that way. When requirements vary too much to fit into rows and columns, a short requirements checklist plus a quick discovery call does more good than forcing the page to answer questions it can’t answer cleanly. Just make sure that call clears up real unknowns rather than repeating what the page should have said in the first place.
A Quick Checklist
Are the service categories described in terms a buyer would actually use?
Can someone tell, within seconds, which option is meant for them?
Are the real differences stated explicitly rather than implied?
Are scope boundaries and exclusions visible before contact is made?
Can visitors identify their own must-have requirements easily?
Are integration and dependency questions addressed up front?
Is the pricing logic, not just the number, understandable?
Does the comparison hold up cleanly on a phone screen?
Is there a clear next step when uncertainty remains?
Make the Differences Clearer, Not Just Fewer
Simplifying a service page by cutting options is a natural instinct, but the research doesn’t really support it as a fix on its own. Read carefully, the jam study shows a real effect resting on a thin evidence base. The two meta-analyses that followed suggest the real driver is how complex and uncertain the comparison feels, more than the number of options. And the UX testing closest to this problem, on SaaS plan matrices and comparison tables, points the same way: group what’s related, surface what’s different, and keep the essentials in view.
Get that right, and the number of packages on the page stops being the thing that matters. If you’re wondering whether your own service pages pass that test, Techosquare works through exactly this kind of comparison and structure problem with clients building out web, ecommerce, and app offerings, without starting from “let’s just cut some packages.”

About the author
Vineet Arora writes about UX research and decision design, examining how buyers actually evaluate options online and what separates a usable comparison from a confusing one. Drawing on usability findings from sources like Nielsen Norman Group and Baymard Institute, his work focuses on service page structure, comparison tables, and the choice architecture that helps visitors decide with confidence.