Sharepoint 2010 : Planning Your Information Architecture - Site Architecture

1/10/2014 3:05:51 AM

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.

[2] Personas are fictional characters created to represent the different user of your solution. A user persona represents the goals and behavior of a real group of users. You use the persona to imagine the site design from that user’s perspective, which helps you create a meaningful site architecture.

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 ( 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.

Figure 1. Example site architecture

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.

  •  Sharepoint 2010 : Using InfoPath 2010 to Create Electronic Forms (part 2) - Publish the Form to a SharePoint Library
  •  Sharepoint 2010 : Using InfoPath 2010 to Create Electronic Forms (part 1) - Creating an InfoPath Form
  •  Sharepoint 2010 : Designing Workflows with Visio 2010 (part 2) - Importing the Workflow into SharePoint Designer
  •  Sharepoint 2010 : Designing Workflows with Visio 2010 (part 1) - Designing a Visio Workflow
  •  Adobe Dreamweaver CS5 : Working with Multimedia and Online Tools - Sharing My Screen
  •  Adobe Dreamweaver CS5 : Working with Multimedia and Online Tools - Exploring CS Live Services
  •  Creating Custom Workflows with SharePoint Designer 2010 (part 3) - Testing Our Workflow
  •  Creating Custom Workflows with SharePoint Designer 2010 (part 2) - Workflow Actions, Creating a Simple Workflow
  •  Creating Custom Workflows with SharePoint Designer 2010 (part 1) - Introducing SharePoint Designer, Workflow Types
  •  Sharepoint 2013 : Visio Graphics Services (part 2) - Setting the Description of a Data Provider , Configuring Visio Performance Settings
    Top 10
    Review : Sigma 24mm f/1.4 DG HSM Art
    Review : Canon EF11-24mm f/4L USM
    Review : Creative Sound Blaster Roar 2
    Review : Philips Fidelio M2L
    Review : Alienware 17 - Dell's Alienware laptops
    Review Smartwatch : Wellograph
    Review : Xiaomi Redmi 2
    Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
    Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
    3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
    Popular Tags
    Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Exchange Server Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe Photoshop CorelDRAW X5 CorelDraw 10 windows Phone 7 windows Phone 8 Iphone
    Visit movie_stars's profile on Pinterest.