For a long time, I thought the hardest part of working with SharePoint was the technology.

Users would not follow the process. They ignored documentation. They skipped training. They used folders “wrong,” named files inconsistently, and worked around the systems we carefully designed for them. It was easy to conclude that the problem was user behavior.

That belief felt justified, especially when we had done everything we thought we were supposed to do.

But eventually, I realized I was fighting the wrong battle.

As technology professionals, we live in the deep end of the pool. We spend our days in the 301s. We forget how much context we carry around in our heads. At the same time, new users arrive in SharePoint every single day. New hires. New roles. Mergers. Reorganizations. What feels obvious to us is brand new to someone else.

The 101s matter just as much as the 301s. Forgetting that is where empathy breaks down, and where most adoption efforts start to fail.

The turning point for me came when I stopped asking why users would not follow the system and started asking what the system was asking them to do that did not make sense. Too many decisions. Too many rules. Too much assumed knowledge. Friction was not a failure. It was a signal.

I didn’t call it Organizational Change Management back then. I just knew that fighting users wasn’t working. Later, I learned there was a name for it.

What actually helped was slowing down and understanding who I was building for. Not job titles. Not org charts. Real people. What they were trying to get done, what got in their way, and what success looked like to them.

That’s where user stories and personas quietly changed everything for me. Once I started framing SharePoint decisions around “who is this for” and “what problem are they solving,” the platform stopped feeling like the enemy. Resistance dropped. Training landed better. Adoption stopped being a mystery.

Years later, I found language for what I had already experienced through Microsoft’s guidance on adoption and change management and the Maturity Model for Microsoft 365. Not as a checklist, but as a reality check. The same solution does not fail everywhere. It fails when readiness is assumed instead of understood. Microsoft also maintains a broader adoption resource hub that reinforces many of these ideas in practice.

This shift aligns closely with Microsoft’s own guidance on driving adoption and change, which emphasizes understanding user behavior before optimizing tools. We often skip that step and jump straight to enforcement.

This realization tied directly back to something I wrote earlier in this series in Day 2, The biggest lie we told users about SharePoint. We told users SharePoint was easy, then acted surprised when reality did not match the promise. When trust breaks at the beginning, everything that follows becomes harder.

Once I reframed the problem, patterns started to emerge. Metadata models that only worked for power users. Pages overloaded with options. Permission structures that required users to understand governance just to do their jobs. None of these failures were about resistance. They were about design.

I explored that more concretely in Day 5, SharePoint metadata only works if people use it. Microsoft’s own documentation on information architecture in modern SharePoint reinforces the same idea. If users are not using your metadata, the answer is not more training. It is better structure and better defaults.

The same lesson shows up in permissions. Locking things down harder does not create clarity. It creates work. I wrote about that in Day 7, SharePoint permissions are not governance, and Microsoft echoes this in its guidance on modern sharing and permission models. Permissions are meant to support collaboration, not punish mistakes.

Pages were another wake-up call. I used to believe that if users did not engage, the answer was to add more content or more options. Over time, I learned the opposite. Simplifying pages and reducing decisions worked far better than explaining them. That lesson shows up clearly in Day 10, Fewer SharePoint web parts, clearer pages.

What changed after I stopped fighting users was not a loss of standards. It was a change in focus. Fewer rules. Better defaults. Clearer structure. Less explaining. More listening. Adoption improved without adding more process.

SharePoint did not suddenly become easier. It became more humane.

SharePoint is flexible enough to reflect whatever mindset we bring to it. If we design for ideal behavior, it will punish real behavior. If we design with empathy, it will quietly support people without asking them to think about the tool at all.

That shift also forced me to confront my own bias. Expertise can be blinding. The things that feel basic are often the most important. Systems that only work for experts are broken systems.

I did not stop caring about quality. I stopped blaming people.

Fighting users was easy. Designing for them was harder. And it finally worked.

---

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.