Day 10: Fewer SharePoint web parts, clearer pages

Illustration of a thoughtful consultant holding a single puzzle piece while studying a table covered with puzzle pieces shaped like SharePoint web parts, representing deliberate page design.

Modern SharePoint web parts are powerful, flexible, and dangerously easy to abuse. Almost every usability problem I see on SharePoint pages today starts the same way: someone opens the toolbox, sees how many options are available, and assumes more choice will automatically lead to a better page.

In practice, the opposite is usually true. Choice overload kills clarity. When users land on a page filled with web parts, sections, feeds, buttons, and calls to action, they do not feel empowered. They feel unsure where to look first and what actually matters.

Microsoft has steadily expanded what pages can do, as outlined in its guidance on using web parts on SharePoint pages. That flexibility is a real strength, but it also removed the friction that once forced people to think carefully about what belonged on a page.

The shift from classic to modern SharePoint changed this dynamic completely. In the classic experience, customization often required master pages, script injection, or brittle workarounds. Modern pages replaced that with safer, faster, and more accessible building blocks, a transition Microsoft describes when comparing classic and modern web part experiences. The intent was good: standardize layouts, reduce risk, and make page creation easier. But simplicity also removed restraint.

Because you can add almost anything, people do. I regularly see pages with multiple web parts showing the same content in different formats. News appears as a feed, again as highlighted content, and again as quick links. Search boxes sit next to links that already lead to filtered views. Content is repeated because no one trusts users to click or navigate.

The result is not redundancy. It is noise.

This problem becomes more pronounced when custom SPFx web parts enter the mix. SPFx is incredibly powerful and absolutely has its place when extending SharePoint beyond what out-of-the-box web parts can do. Too often, though, custom web parts are built to recreate existing patterns simply because someone wanted a slightly different look or behavior.

Every custom web part carries long-term cost. Maintenance, testing, upgrades, and ownership never go away. When those custom parts are layered onto already crowded pages, clarity is usually the first casualty.

Every web part asks the user to make a decision: read this, click that, ignore something else. When too many decisions appear at once, users disengage. They scroll past everything or leave the page entirely. This is not a SharePoint problem. It is a human one.

The most effective SharePoint pages I have seen are intentionally restrained. They have one clear purpose and one primary action. Supporting content lives on subpages, where it can be organized and maintained without overwhelming the main experience.

Modern layouts and flexible sections made this more important, not less. Pages can now adapt to content far better than they could in the past. That flexibility should enable focus, not justify clutter.

A simple test helps. If removing a web part does not change the meaning of the page, it probably does not belong there.

This is where governance shows up quietly. Not as approval workflows or locked templates, but as shared design principles. What belongs on a page. What belongs in navigation. What belongs somewhere else entirely. Without that shared understanding, every page becomes a personal expression instead of a predictable experience, and users are forced to relearn how to read a page every time they visit a new site.

Clarity scales. Cleverness does not. Modern SharePoint web parts are not the enemy. Indiscriminate use is.


This post is part of my 25 days of SharePoint series, created to celebrate SharePoint’s 25th anniversary and lead up to the SharePoint at 25 digital event on March 2.

Each post reflects on what actually made SharePoint last 25 years, the wins, the mistakes, and the lessons learned from building, breaking, and rebuilding it in real organizations.

You can find all posts in this series here.

If there’s a topic you think I should cover next, a SharePoint mistake you keep seeing, or a question no one ever answers straight, leave a comment. This series is shaped by real experiences, not marketing slides.

Leave a comment