A Comprehensive Guide to SharePoint Site Design

In this post: The steps · Automating repeatable setup with Site Scripts · On step 7 (permissions) specifically · Common mistakes worth avoiding · When would you actually use this? · Helpful references

The steps

Define the purpose first. Project management, company-wide comms, or external collaboration each want a different structure — decide before building, not after.
Plan the structure — sitemap, metadata scheme, navigation hierarchy — before creating anything in the admin center.
Pick the site type: Team Site for collaboration, Communication Site for information-sharing one-to-many, and a Hub Site if you need several related sites sharing navigation and branding.
Create it in the SharePoint admin center, choosing the template and setting name/language/privacy.
Customize the design — theme, logo, header, navigation, and Site Scripts if you’re automating repeatable setup steps.
Add content and web parts — News, Quick Links, Document Library, Calendar, Embed — whatever the purpose from step 1 actually needs.
Set permissions deliberately, not by accepting every default.
Test before launch with actual users, not just yourself.
Monitor and adjust after launch — usage rarely matches the plan exactly.

Automating repeatable setup with Site Scripts

If you’re creating the same kind of site repeatedly — one per project, one per department — step 5 (customize) and step 6 (add content) get tedious fast doing it by hand each time. A Site Script defines those steps as JSON and attaches to a Site Design, so creating a new site can apply the whole thing in one action instead of manually recreating lists and settings every time:

{
    "$schema": "schema.json",
    "actions": [
        {
            "verb": "createSPList",
            "listName": "Project Documents",
            "templateType": 101,
            "subactions": [
                { "verb": "setDescription", "description": "Central document library for this project" }
            ]
        },
        {
            "verb": "applyTheme",
            "themeName": "Custom Company Theme"
        }
    ],
    "bindata": {},
    "version": 1
}

Register it with Add-PnPSiteScript and Add-PnPSiteDesign, and it shows up as an option when creating new sites — consistent setup without a manual checklist.

On step 7 (permissions) specifically

Assign access through SharePoint groups, not individual users — it’s the difference between updating one group membership later and hunting down permissions across every library and list. Only break permission inheritance where a folder or library genuinely needs different access than the rest of the site; every break is one more thing to remember during an audit. See SharePoint Permissions: A Comprehensive Guide for the full picture on this.

Common mistakes worth avoiding

Deep folder nesting instead of metadata. A “Client > Year > Project > Phase” folder tree feels organized at first, but it doesn’t scale — views and metadata filters do the same job without the fragile deep links and eventual path-length issues.
Copying an existing site’s structure without asking whether it actually fits. The last team’s site layout solved their problem, not necessarily yours — reusing it wholesale usually just means inheriting whatever they got wrong too.
Skipping step 8 (testing with real users). A site that makes sense to the person who built it often doesn’t make sense to someone seeing it cold — navigation that seems obvious in hindsight is the single most common thing that gets restructured after launch.
Treating the site as finished at launch. Usage patterns after real people start working in it rarely match the plan exactly — step 9 (monitor and adjust) isn’t optional cleanup, it’s when you find out whether step 1-2 actually predicted how the site gets used.

Assign access through SharePoint groups, not individual users — it’s the difference between updating one group membership later and hunting down permissions across every library.

When would you actually use this?

You’re setting up a new team’s workspace and don’t want to just clone whatever the last team did — working through purpose and structure first avoids inheriting someone else’s mess.
Multiple related sites need consistent branding and navigation — that’s the Hub Site decision point in step 3, not something to bolt on later.
You’re rolling out a company intranet and need a Communication Site, not a Team Site — picking the wrong one early means a rebuild later.
External partners or subcontractors need access to specific project info — that’s an extranet with guest access, not a Team Site with loosened permissions.

Helpful references

Real SharePoint site design examples from Microsoft: SharePoint Look Book.

For a more advanced starting point: the PnP SharePoint Starter Kit on GitHub.

That should cover the basics. Comment if you want to go deeper on any part.