In Part 1 of SharePoint for Public-facing Websites we discussed the importance of a high-level methodology for planning the implementation. In this post (part 2) we will expand these concepts.
Audiences
Your website is built for them – not you. Your website is for your audiences. Your org likely has many audiences: anonymous public, or logged in members, volunteers, donors – everyone that supports your organization. Your website may be for students, teachers, educators, the press, government officials, affiliates, and other orgs. Again, your website is for them – not you.
It’s for them to learn about you. It’s for them to communicate with you. It’s for them to communicate with each other – about you. It’s for them to learn, contribute, teach, and share. Your website must serve many masters, but the master it should serve first and foremost is them.
Clearly define your core audiences. Just because your website is public-facing does not mean the entire world is your audience. Your defined target audiences will dictate your content, functionality, presentation, marketing, and structure.
Remember they will use the website only if it is convenient for them. They will use your website only if they can find what they want, when they want. They will use your website only if it works for them on whatever device they happen to be using when they find it.
Your users do not care about your technology. They don’t care about your AMS, CRM, CMS, Financial Package, servers, widgets, or ACME parts.
Your users do care about you. They care about your content. They care about the Page, the file, the audio, and the video. They care about what you say, and they might care even more about what the other users say on your website. They either want Content, Commerce, or Community.
Content
What content do you have today? What format is it? Do you have HTML pages, PDF files, videos, and podcasts? Is it all in one location, or is it spread out all over the place? Is it in a CMS already?
It is never too early to perform a content audit. A content audit should actually be an ongoing effort of your org. You should have a handle on your content and the way it is managed. The sad reality is most orgs don’t. The content audit can seem overwhelming, but it really is a simple task which just happens to be time consuming.
Content is king, has been king, and will continue to be king for the foreseeable future. If your website has irrelevant or just bad content, your website will not be successful.
In most cases, your top-level website content is actually marketing copy. Put your salesperson hat on when you write your content. On your website, your content is one of your products. Your audiences are your customers. Think about how to sell your product to your customers.
Train your staff how to write better content for your website. Have a genuine interest in providing the best possible content for your audience(s).
Design
Design is more than just pretty pictures. Design is the entire user experience (UX) and user interface (UI). In fact, the pretty pictures should be the last part of your design stage. You should first define the structure and usability, and then make it pretty.
Contextual Planning
Plan the entire design in the context of SharePoint. SharePoint provides a lot of capability right off the shelf. While SharePoint can be molded programmatically to be anything you need, that doesn’t mean it should be.
Remember to start with configuration and resist customization. Leverage the power provided out of the box as much as possible.
Your planning team needs to be aware of SharePoint capabilities. They need to see it in action and be able to use it. They need a sandbox so they can try ideas during the design stage. Remember, SharePoint provides a lot of configurability through in-browser configuration. Use it.
Wireframes
Wireframes are the best way to plan the logical layout of individual Page templates. The technology you use to develop a wireframe can be pencil and paper or software. Wireframes should be done before any artwork or creative design. The wireframe should be kept simple, but should serve these very important purposes:
- ? Suggest the overall structure of the website.
- Suggest the relationship among Pages.
- ? Suggest the relationship among areas on a single Page.
- ? Suggest the necessary templates that will be used throughout the website.
- ? Suggest the global and secondary navigation.
Wireframes can be used for initial usability testing, link prediction testing, and most importantly, for communicating website and Page structure.