Palantir.net's Guide to Digital Governance: Private Websites, Intranets and Portals

Most organizations these days have some form of private area for only staff, group members, constituents, partners, vendors, etc. These sites are sometimes guarded behind a firewall and a user authentication system, sometimes just user authentication, and sometimes simply hidden by obscurity. Most often, though, you can identify one of these types of sites because it requires a login and password and is not generally accessible by the public.

Most of the previous questions, regarding content, organization and design are relevant to internal Web properties as well, but here are a few questions you may want to ask yourself specifically with regard to private websites, intranets, and internal-facing portals:

• Who owns each one? If they are shared responsibilities, what are the parts and who owns each part?
• How are accounts distributed and access granted?
• Who determines access and account creation?
• What is the process for account creation?
• What is the criteria for gaining access via an account?
• Do user accounts have different roles with different permissions?
• Who are the content editors and creators within the site?
• How is the site edited and maintained?
• Are there any workflows or approval processes for content?
• What distinguishes content that is appropriate for external channels from content that is only appropriate for internal channels?
• Who will be responsible for determining what is appropriate? And how will they enforce those rules?

Public vs Private

Another important consideration for private websites and intranets, especially if you are planning to build one or redevelop your public website, is whether or not an intranet (or a private website) should be a part of your public website. In other words, should the same system for administering and maintaining your public website be the same system as your intranet or private website?

On the surface, the simple answer may appear to be, “Of course! Wouldn’t that be the most simple and streamlined approach?” Once you dig into the requirements of what you need for your private site, and compare that with the purpose of your public site, you may determine otherwise.

Why?

The most common purpose for a public website is to communicate information about your organization to a range of audiences, many of whom are not currently part of your organization. In fact, the primary purpose of your public website, specifically, may be to attract those who are not part of your organization in order to convince them to become part of it.

In short, your public website’s primary purpose is likely to be a marketing tool for expanding your message and growing your constituency (membership, clientele, user-base, however you think of them). There is not typically a lot of functional interaction that happens between user and website at this stage, aside from asking visitors to contact you, sign-up up for something, attend an event, purchase a product, or some other interaction that is typically managed by a relatively basic form.

In other words, the necessary functionality for a public, marketing website tends to be fairly light in terms of the weight of its programming logic and requirements.

Intranets and private websites tend to be a different animal. Being private, by definition, means they need to support accounts for users. Having a lot of users logging into a system presents a number of challenges and requirements that can become quite complex. A heavier set of tools are often required, adding more software to the system.

Given that users and authentication credentials are involved, often integrations with user databases or user management systems may be involved, and almost certainly, a higher level of security and encryption becomes necessary.

Usually, when you have a private site or intranet, the needs of users become more transactional than consumption marketing information. Once a user is a member, they no longer need to be sold on the organization; they need to “do” things through the website – use tools, access account information, transmit or receive private data, etc. All of these things require deeper levels of programming, security, and the infrastructure to support it – a lot more heft and complexity than what you need for your marketing website, which probably benefits most from being nimble and quick to deliver relevant content.

Perhaps most important, though, is the organization of information – and this is where many projects that aim to combine a public website with a private intranet get bogged down. Since the two sites address the needs of largely different audiences, the menuing and navigation in sites that aim to serve both public and private needs are often in conflict with themselves. 

Rarely do you want to show navigation, menuing, or content to the public which is meant only for private users. However, how do you then present the private content and way-finding to authenticated users without breaking a design that, in theory, looks appropriate for only the public content and navigation?

As you get into the details of accommodating both public and private needs on a website, what you often find is that you make odd compromises to things you ordinarily wouldn’t (like usability of the site), in order to make the two work together. In truth, given that the audiences for the two sites may have very different needs, and the websites need to serve very different purposes, it is often wise to separate the two, even if that means support of two separate systems. In the end, it is better to serve the needs of the users, such that they can be successful using your websites.