Top 5 tips to follow before building your SharePoint site

I’ve built, inherited, re-developed and managed a lot of SharePoint sites over the last ten years. When I inherit a SharePoint site, too often I find I end up with poorly managed, difficult to use, unfit for purpose and out of date sites that no one likes, or uses. Often this is because sites have not been given a clearly defined purpose upfront and the users of the site not engaged in the development process. Here are my top five tips to follow before you build you site to avoid falling into the 9th level of SharePoint hell.

1. Be clear on what you and the site’s intended users want it to achieve – SharePoint is a very versatile tool which allows you to use it simply as virtual document storage, up to creating an interactive sharing and engagement platform where multiple users can share and update information and documentation virtually. A lack of clarity on purpose can make development difficult at best, result in a site that's unfit for purpose at worst and can lead to users either misusing the site, or not adopting it at all.
2. Understand the needs and wants of your intended site users – Directly linked to tip 1, if you don’t understand users, how will you be able to develop a site that will positively encourage them to use it and make their working life easier. If you develop a site that makes things harder, then force them to use it, you’ll likely to get a lot of push back and spend a lot of time enforcing the use of it. With a bit of upfront engagement, user research and requirements gathering, it’s possible to create a site that meets management and end-users needs, or at least a working compromise of the two.
3. Be clear on the management principles and responsibilities you will use to keep the site up and running – As a site builder you might be focused mostly on getting your nice and shiny new site built, but one of the biggest downfalls to even the most beautifully designed site is not having clear principles on how the site will be run and managed, and by whom. Along with clearly defining the objectives of the site, it's useful to create a clear set of principles for its use, such as, only one editable version of a document existing on the site, defining naming conventions, etc. You should also define the user access levels and the responsibilities of each level, ensuring there is clear accountability, stewardship and ownership of the site. I usually present this information in a presentation with an activity plan, wire frame and mock up – see tip 4 for more details.
4. Create an activity plan, wire frame and mock up to share with stakeholders before building your site – After gathering all the requirements it helps to distil the requirements into a presentation which includes an activity plan for developing the site, a wire frame diagram showing how the different pages, libraries, lists and sites are organised and interlinked, and a mock-up of the core pages of the site, together with the core objectives, and proposed management principles of the site. This gives you a clear understanding of exactly what you need to build, when and how to connect the different assets into a working site. You can then walk this through with senior stakeholders, and a selection of users from different backgrounds to get engagement and buy in at all levels with the design and purpose before building the site.
5. Engage end users and key stakeholders in your testing – Even if you are creating a simple site its worth involving those same stakeholders and end users you engaged with in the planning, with the testing. As good as your plan and execution is, sometimes it’s not until a site is used in practice that you pick up on things which don’t work as you wanted, or extra functionality and tweaks which might be required. It also helps to reinforce with users that their views and opinions were incorporated into the build and demonstrates that the site works well….hopefully.
6. Bonus tip: What was perfect yesterday, might not be practical or fit for purpose tomorrow – The more complicated your site the more difficult it will be to manage and keep up to date, so try to minimise complexity upfront and if you’re still associated with the site after 3, 6 and 12 months do a brief audit of how the site is being used, canvas user experience - are there any areas not being used you can remove, or functionality which needs to be updated as requirements have changed, is there any new functionality users want. If you’re not going to be associated with the site once you’ve built it, encourage the site admins/owners to build those audit responsibilities into the handover. 

So those are my top tips to creating a successful SharePoint site which delivers what management needs and works in a way that doesn’t put off its users. If you’d like to know more about developing and managing SharePoint sites as a business power user feel free to contact me or leave a message in the comments. You can also find an example SharePoint development presentation which includes: site objectives, management principles, roles and responsibilities, delivery activity plan, wireframe and page mock ups based on change programme SharePoint sites I’ve previously built on my LinkedIn profile.