In a portal or content management system,
an effective site architecture helps users navigate to content without
having to search. Your site architecture also allows users to see
documents and other components of the solution in context, which helps
them assess whether a document or component is relevant for what they
are trying to accomplish. Our experience indicates that users use a
combination of hierarchical navigation and search when both are
available. It is impossible to predict who will be a “browser” and who
will be a “searcher” in practice. The challenge is that while
creating an optimal site architecture for navigation and content
organization is vitally important, you probably won’t get it right
until you get real users using the solution with real data. As you
learn more about how users interact with your solution when you observe
their behavior and gather feedback after deployment, you should evolve
your site architecture to make your solution even more effective.
As you conduct interviews and workshops to develop
an understanding of user objectives for the solution and how they use
information to guide their work, think about how that information fits
within the overall conceptual organization of the company. Think about
how content can be separated into major groups, based on key business
processes, major projects, key business roles, or organizational
functions. Within each major classification, you may need to break each
concept into subunits, depending on both the type of content, who will
“own” the content, and how you believe people will use the content.
One technique you might use to plan your site
architecture is to gather together three to five representative
stakeholders to brainstorm key content areas. Write down the major
content categories that users will expect to find on your site. If you don’t have access to actual site users, you may have to imagine
what users will find on your site. If this is the case, consider
creating user “personas”
and approaching your site architecture design from the perspective of
each persona. Use your stakeholder team and interview results to
document major content areas on sticky notes and then group the sticky
notes into related groups. These related groups will form the starting
point for your site’s main navigation. As you iterate through the site
architecture process, you will want to take out duplicate items,
combine similar items, and look for opportunities to create primary and
secondary or subgroupings where appropriate.
One mistake made by novice information architects is
organizing their site architecture based on the organization of their
company. The company organization chart should not
be the starting point for your site architecture. That doesn’t mean you
should ignore how your company is organized; it just means that you
should use the organization chart to inform your site architecture, not to guide
it. That said, there are some organizational units that are also
functional units—for example, human resources and legal. It is
perfectly fine to represent HR and legal in your site architecture
because while these may, in fact, be represented on the organization
chart as “departments,” they are also each a function within a typical
organization. The mistake designers often make is putting a business
function like corporate communications “under” HR in the site
architecture because the corporate communications department happens to
report to the head of HR in their company (or when they put HR and
legal under finance because these two business units report to the
CFO). This structure might make sense temporarily, but if there is a
reorganization and communications moves to another business group, the
site architecture will no longer make sense. In addition, new employees
who are not familiar with the company’s organization structure will be
far less likely to understand the site navigation if functions are
aligned by organizational “ownership.”
A well-designed site architecture can contribute to
organizational goals and objectives. It should allow people to quickly
find the information they need to do their jobs, effectively improving
operational efficiency. It should also help people place the context of
their work in the overall context of the organization, enabling them to
gain an understanding of what is available on the solution as a whole,
even if they primarily focus on their own particular space. It is
important to provide meaningful labels to the elements of your site
architecture. It is even more important to test your chosen labels with
representative users to make sure that your nomenclature makes sense.
Labels should be succinct—not more than three words each. Terms should
be straightforward, consistent, and convey the desired tone for your
solution. Try not to make up words for your navigation—use terms that
users will understand. There is no single “right” way to organize the
content in your site. However, there are some approaches that are
frequently used in well-regarded solutions:
Many public facing Internet sites and
internally facing intranet sites group general information about the
organization in a section called About Us or About [Company Name]. You
can put information such as the mission and vision, directions, company
history, and organization charts in this section. Because this is such
a familiar concept, users will generally know what to expect in this
category.
Functional groupings can be
based on “what we do,” “who we serve” (both customer groups and
industries), and what employees need to do
their jobs. Different organizations will have different terms for these
groupings. For example: Our Customers, Our Clients, My Life and Career,
My Role.
Activity groupings are based on
primary activities. This structure may work for a departmental in
addition to an enterprise-level solution. For example, the following
types of activities might form a basis of your site architecture:
Project work. Activities that are designed to produce a specific result during a finite period of time.
Support work. Ongoing services that maintain an existing process (such as application maintenance and support).
Enabling work.
Initiatives such as career planning, a project management office, or
portfolio tracking that help your organization deliver project or
support activities.
Customer work. Activities related to engaging with partners, suppliers, and customers.
Team work. Activities related to administering a team such as managing vacation and travel schedules and conducting regular team meetings.
Leadership work.
Information and activities for management personnel only such as
performance management, budgeting, and sharing other confidential
information.
Duplicate
groupings if content “belongs” in more than one collection. One of the
biggest benefits of organizing information online is that the same
content can be grouped logically in more than one location even if it
“lives” physically in only one place. For example, you may organize
your sites based on industry groups, but there may be a subgroup that
could be classified in more than one industry. For example, imagine an
information architecture for an executive search firm. The site that
supports the CIO practice could appear under the “CxO” group and the
Information Technology group, which would help users navigate to the
practice page no matter where they are looking for it. However, be
careful about overusing this capability and creating lots of “weak”
categories because this will confuse your users who will wonder why the
same topic appears in so many places.
In some organizations, the solution design team will
define the major organizational groupings for the site architecture but
leave the detailed architecture
to content planning teams at the division or group level. This practice
works effectively if experienced information architects are available
to support the divisional teams and if some common architecture
principles are defined at the enterprise level to ensure consistency in
user experience across the solution and to ensure that the optimal
SharePoint features are leveraged in the architecture design. As stated
earlier, the key to success in a delegated model is to ensure that you
empower all users with design permissions with information architecture
skills and best practices. This means that you will need to define a
training program to ensure that users get the knowledge they need to
effectively define their information architecture. In addition to
training, you should also consider providing expert coaching to new
site designers until they feel proficient.
Before you implement your site architecture, it is
important to review it with several stakeholders. While you may be
tempted to immediately implement your proposed architecture in
SharePoint, this is not a good idea. You should go through at least one
round of “paper” site architecture documentation. There are several
techniques that information architects use to document a site
architecture, and several information architects we know like to use
mind maps and a mind mapping tool such as MindManager (http://www.mindjet.com)
to document a proposed site architecture. Others use Microsoft Office
Visio or PowerPoint. The goal of your site architecture diagram is to
show the relationship of the various elements of your proposed site
navigational structure in a picture that allows you to review your
proposal with your key stakeholders. The technique you use isn’t nearly
as important as the conversation that you need to have, so choose a
diagramming technique that best facilitates your conversation. Figure 1
shows a simple site architecture diagram created with Microsoft Office
Visio. This example shows some diagramming techniques that you might
use to help facilitate your architecture conversation.
Your site architecture diagram should include the following:
Hierarchical diagram showing each level (“node”) and how the nodes are connected. Note that the example in Figure 1
suggests that you try to limit your nodes to no more than three levels
deep. This is not a hard and fast rule, just a guideline. Don’t use
this rule to eliminate useful “landing” pages for major sections in
your site. Category or landing pages help provide context when users
land on subpages or subsites from search results.
Labels for each subsite or page and, if possible, a general description of the content on the page.
Plan for navigation (using tabs and/or other navigational links).
As you consider whether a particular topic, process,
or function needs a separate “node” (page or site) in the site
architecture, it is also helpful to consider several factors in overall
site administration:
Content ownership.
If a particular business group is the primary owner of all of the
content to be published on the page or site, creating a separate site
(“node”) for that business group probably makes sense.
Security.
If a significant group of content is highly sensitive, creating a
separate node in the architecture allows you to more easily control the
security settings for that content.
Database administration. If you think that you might want to backup, restore, or otherwise manage content in a single group, having a unique portal node for that content will make these processes easier to manage.
Navigation.
Try to minimize the levels of nesting in your information architecture.
It’s a good practice to keep the number of levels in the hierarchy to
no more than three so that users do not have to continuously “click
through” to get to critical content. If you don’t need to create a node
in the architecture for any of the other reasons outlined here or your
content group does not need a “landing page,” don’t create it.
Effective site architecture design is not a simple
or quick process, even for small organizations or simple sites. If you
invest the time to learn about your users’ information needs, the
result will be a site that is easy to learn and use.
