We have all been at organizations which use SharePoint as their internal document management and storage standard. For those who manage it well, it can be an extremely valuable platform which not only delivers relevant content as needed, but also provides dynamic data which aids in critical business functions and processes. On the flip side, we have also seen SharePoint solutions which are completely overridden with abandoned sites, broken links/pages, and outdated and un-useful content that is completely frustrating to the end-users who were aimed to be helped in the first place!

It does not have to be that way. By asking the right questions up-front and considering all potential use cases, you too can create a long-term strategy for continued usage.

BRAINSTORM AND PLAN

Primary Purpose: Think about the end game you want to achieve and consider all paths leading there

When building or designing any SharePoint site or solution, there are certain questions you should ask yourself and your ultimate sponsor up-front. While some of these questions may look/feel similar, there is enough distinction between them to help draw out crucial details that will make your site useful in both the short- and long-term. Examples include:

• What do you envision the site to have once it is made available to users? What are the pressing needs, and what are the nice-to-haves?
• What are its various use-cases? How do you envision end-users interacting with the site?
• Who will your audience be? Standard worker bees? C-suite executives? Will they be looking at/provided the same content or do they need to have information separated?
• What kind of content do you want to serve? Is it primarily static (non-changing) or dynamic (ever evolving)? How would updates/data be managed within the site?
• What levels of access should the end-users have?

The insightful questions above should be the lead for any productive brainstorming session. Grab a marker and head to a whiteboard! Make sure to document all answers and re-confirm with your stakeholders as you go through the list. Brainstorming sessions allow for the organic growth of any design/concept, drawing on the unique perspectives of all involved. Well thought-out preliminary questions like those above can help this process go smoothly and be very effective.

Once everything is on your whiteboard or screen, it is time to plan. Think about the following:

• Prioritization of items (what is most critical)
• The means of how you could deliver on content asks (through straight data, via pictures, videos, etc.)
• How people should and would be accessing/utilizing your site and the information on it

Strategize with your colleagues and stakeholders. Lay out the most important pieces and establish base timelines around the next steps of putting your plan into action. It is time to get to work.

BUILD A WIREFRAME

Primary Purpose: Get a build confirmation before you begin building

Measure twice, cut once. This analogy is also applicable in the next step of the process which consists of building out a sketch or wireframe based upon your brainstorming activity. It starts with a blank canvas. This could be a PowerPoint document, Word document, or just a few sheets of blank paper. Begin sketching out your site. Think about its usefulness. Instead of spending endless hours in the back-end of the tool tinkering away at a design that your stakeholders might not even like, simply put pen to paper, or a marker to a whiteboard.

Stakeholders love to share their opinions and have their ideas implemented. By creating a wireframe mock-up, in whatever manner you deem appropriate, you will have a better idea of what needs to be produced on the eventual site in order to achieve stakeholder approval – even before you have begun building on the back-end! Any requested changes can easily be incorporated into the design, and most importantly, by laying out the navigation/design and your eventual content, you can begin to formulate exactly how the content will come together in the back-end to achieve your end display results (which we will cover in the next section).

Personally, I recommend making these wireframes look as close to the final product as you can (which is why I work in PowerPoint, which I feel gives me the greatest manipulability). This allows your sponsors to really get a good feel of your vision and see the value it brings. Of course, you must have sufficient knowledge of how different app and web parts work within SharePoint, in addition to your client’s SharePoint environment’s ins and out as each environment differs in accessibility and resources available. Research as many available internal sites as you can; note who owns/manages those pages so that you can ask the proper questions down the road if you wish to incorporate any of their ideas within your own site. Ultimately, a realistic wireframe paves the path towards design approval and the confidence of knowing that your content is already set up for success, even before you have begun your official build.

DEVELOP THE CONTENT

Primary Purpose: To deliver what your end-users want

The reason a SharePoint site is built is to deliver the right content, via the best medium, to your end-users. There are many tools available within SharePoint’s app, web parts, and even other native functionality to display all kinds of content, and once your wireframe and design have been drafted and approved, it is time to consider how you want your end-users to interact with said content via these various layouts and tools.

Your content will either be static (non-changing) or dynamic (changing). For static content, utilizing text fields, images, and even video is perfectly acceptable as this information will not change often. Keep in mind, however, the importance of consistent fonts, text size, and colors across all your sites and sub-pages when developing static content.

For dynamic content, it is important to consider how your audience will interact with it. For instance, if you plan to display data elements such as large data sets, would you prefer your users to just click into an Excel document and open it on their own PCs or would you rather utilize a list feature in SharePoint to allow individuals to have direct access to the data and allow them to view/edit data right on the page as needed. While a list feature may take a little more time and effort to set up properly, the benefits to the end-user could be significantly higher! Additionally, would you want your site to be full of folders to click through to get to documents an end-user might want, or would it make more sense to have varying views of documents (sitting in repositories on the back-end) to help your users find what they want, quicker. It will completely depend on the use-case you flushed out during your brainstorming sessions. For shared calendars, instead of having a PowerPoint or Excel document with individual items, why not utilize SharePoint’s built-in calendar functionality which can also tie directly into your Outlook or Team’s desktop application.

All content should be designed and developed with the end-user and their use cases in mind. Do not expect your build to be a one and done deal. As your users’ needs evolve, so will your content, which is why it’s equally important to consider your sites longevity and on-going maintenance needs.

CONSIDER ITS LONGEVITY

Primary Purpose: To ensure the long-term viability of your site

Throughout your SharePoint build, the documentation you create is extremely important; focused on the knowledge gained of not only building the site but also how to work with the content being displayed. It is essential, as you will most likely not own the site forever. By doing the hard work up-front, you will save a lot of time and effort for future developers down the road. Take note of specifics, such as who owns the various content elements within your site, how often specific items require updating, how the content gets to your site, and ultimately who ensures that content remains up to date and accurate.

Accesses to your site is also an important thing to consider for future maintenance. Who should be granted read, or read/write, or even read/write/delete privileges? By documenting these roles at a high-level and explaining who should be granted what through various examples will help all future owners.

Building an effective, user-friendly, SharePoint site is not easy. And to ensure it will continue to remain relevant is difficult to achieve. Make sure your stakeholders are aware of the site’s progress, its short and long-term plans, and how it should be maintained. The more information that is shared, the more the site will remain an important business resource for all who use it.