Content Strategy

Content strategy refers to the planning, development, and management of content. In other words, content strategy plans for the creation, publication, and governance of useful, usable content.

The purpose of content strategy has been described as achieving business goals by maximizing the impact of content.

Necessarily, the content strategist must work to define not only which content will be published, but why we are publishing it in the first place. Otherwise, content strategy is not strategy at all: it is just a glorified production line for content nobody really needs or wants.

Content strategists strive to achieve content that is readable and understandable, but also findable, actionable and shareable in all of its various forms. Content strategy development is necessarily preceded by a detailed audit and analysis of existing content.

A content strategy defines:

• key themes and messages;
• recommended topics;
• content purpose (i.e., how content will bridge the space between audience needs and business requirements);
• content gap analysis;
• metadata and taxonomy frameworks and related content attributes;
• search engine optimization (SEO);
• implications of strategic recommendations on content creation, publication, and governance. 

Content strategy may include:

Editorial strategy 

Editorial strategy defines the guidelines by which all online content is governed: values, voice, tone, legal and regulatory concerns, user-generated content, and so on. This practice also defines an organization’s online editorial calendar, including content life cycles.

Web writing

Web writing is the practice of writing useful, usable content specifically intended for online publication. This is a whole lot more than smart copywriting. An effective web writer must understand the basics of user experience design, be able to translate information architecture documentation, write effective metadata, and manage an ever-changing content inventory.

Metadata and taxonomy strategy

Metadata and taxonomy strategy identifies the type and structure of metadata, also known as “data about data” (or content) and taxonomy. Smart, well-structured metadata helps publishers to identify, organize, use, and reuse content in ways that are meaningful to key audiences.

Search engine optimization

Search engine optimization is the process of editing and organizing the content on a page or across a web site (including metadata) to increase its potential relevance to specific search engine keywords.

Content management strategy

Content management strategy defines the technologies needed to capture, store, deliver, and preserve an organization’s content. Publishing infrastructures, content life cycles and workflows are key considerations of this strategy.

Content channel distribution strategy

Content channel distribution strategy defines how and where content will be made available to users.

The content life cycle is a repeatable system that governs the management of content. The processes within a given content lifecycle are system-agnostic. The processes are established as part of a content strategy, and implemented during the content life cycle.

Aspects of a content life cycle 

The content life cycle covers four macro stages: the strategic analysis, the content collection, management of the content, and publishing, which includes publication and post-publication activities. 

The content lifecycle is in effect whether the content is controlled within a content management system or not, whether it gets translated or not, whether it gets deleted at the end of its life or revised and re-used.

The analysis quadrant comprises the content strategy. The other three quadrants are more tactical in nature, focusing on the implementation of the content strategy.

Analysis 

In the analysis phase, the content life cycle is concerned with the strategic aspects of content. A content strategist (or business analyst or information architect or writer) examines the need for various types of content within the context of both the business and of the content consumers, and for multiple outputs on multiple platforms.

The analysis has a bearing on how the content strategy is implemented in the other quadrants of the content life cycle. On a new project with new content, this is the beginning of the process. Much of the time, the process will start somewhere else in the cycle; a lot depends on a multitude of factors involved in changing content from a current state to its future state.

Collection 

Content collection includes the garnering of content for use within the framework set out in the analysis phase. Collection may be through content development - creating content or editing the content of others, content ingestion - syndication of content from other sources, or incorporation of localized content, or a hybrid of content integration and converge - such as integrating product descriptions from an outside organization with prices from a costing system, or the convergence of editorial and user-generated content from social media for simultaneous display.

Publish 

The publishing quadrant deals with the aspects of content that happen when the content is delivered to its output platform and ensuing transformations, manipulations, or uses of the content. Publishing the content is only a point in the first life cycle iteration; there are post-publishing considerations such as re-use and retention policies that require attention.

Management 

The management quadrant is concerned with the efficient and effective use of content. In organizations using technology to automate the management of content, the management aspect assumes use of a content management system (CMS) of some sort. In organizations with smaller amounts of content, with little need for workflow control, and virtually no single-sourcing requirements, manual management is possible.

However, in large enterprises, there is too much content, and there are too many variations of content output, to manage the content without some sort of system to automate whatever functions can be automated. The content configuration potential is enormous, and builds on the information gathered during the analysis and collection phases.

The solutions will be highly situational, and revolve around the inputs and outputs, the required content variables, the complexity of the publishing pipeline, and the technologies in play. The most basic questions are around adoption of standards and technologies, and determining components, content granularity, and how far up or down the publishing pipeline to implement specific techniques.

At its core, content strategy is a way of thinking that has direct impact on the way we do business. And the way we do business must include a clear focus on how we create, deliver, and govern our content. Because more than ever before, content has become one of the most valuable business assets.

Information Governance

Information is the lifeblood of any modern-day business. Companies succeed or falter based on the reliability, availability and security of their data. A company's capacity to handle information depends upon a variety of factors, including engaged executives and a company culture that supports collective ownership of information.

However, strategically created enterprise-wide frameworks that define how information is controlled, accessed and used are the most critical elements in a successful information management program. This framework is information governance.

Information governance is the set of policies, procedures, processes, roles, metrics, and controls implemented to manage information on all media in such a way that it supports an organization's immediate and future regulatory, legal, risk, and operational requirements. It treats information as a valuable business asset and ensures the effective and efficient use of information in enabling an organization to achieve its goals. Information governance is a holistic approach to managing corporate information.

Organizations with good information governance know the who, what, when, where, why and how of their information:

• What is this information?  
• Who has access to this information? 
• When was this information created or processed? 
• Where is the information stored? 
• What information is being retained? 
• How long it is retained? 
• How is this information being protected? 
• How policies, standards, and regulations are enforced?

The goal of a holistic approach to information governance is to make information assets available to those who need it, while streamlining management, reducing storage costs and ensuring compliance. This, in turn, allows the company to reduce the legal risks associated with un-managed or inconsistently managed information and be more agile in response to a changing marketplace.

When a company fails to manage their information properly, it puts itself in jeopardy of violating compliance rules, damaging its brand equity, and paying hefty fines.

To implement or strengthen an information governance consider the following:

• Define procedures, processes, and controls with users feedback. When they participate in the creating processes and procedures, they will agree with them.
• Be clear at the outset about roles, responsibilities and accountability across the organization. Establish a central governance body with decision-making authority and cross-functional and geographic representation. Committees should plan to meet regularly and be sufficiently small and empowered to make decisions swiftly.
• Top-down support is critical to the success of any information governance strategy. Senior management should be briefed regularly on projects and progress related to information governance.
• Establish a formal and ongoing training to make employees aware of new policies and procedures and the reasoning behind them. Develop training sessions and annual governance refreshers to ensure that the entire organization is in-line with the information governance framework.
• Enforce standards with flexibility. While some policies and procedures should be universal, certain business units and regions may need some leeway when it comes to process particularities. They should be free to determine the best course of action within the overall governance boundaries.

The future of information governance depends on continually evaluating policies and adapting them as business priorities and market conditions evolve. Just as an effective corporate governance strategy can yield competitive advantages, effective information governance can turn information into a more consistent generator of business value.

Information Architecture Methods

There are few methods that are used in information architecture. Some of common methods are: site maps, annotated page layouts, content matrices, page templates, personas, prototypes, storyboards, wireframes.

Site maps

Site maps are perhaps the most widely known and understood deliverable from the process of defining an information architecture. A site map is a high level diagram showing the hierarchy of a system. Site maps reflect the information structure, but are not necessarily indicative of the navigation structure.

Annotated page layouts

Page layouts define page level navigation, content types and functional elements. Annotations are used to provide guidance for the visual designers and developers who will use the page layouts to build the site. Page layouts are alternatively known as wireframes, blue prints or screen details.

Content matrix

A content matrix lists each page in the system and identifies the content that will appear on that page.

Page templates

Page templates may be required when defining large-scale websites and intranets. Page templates define the layout of common page elements, such as global navigation, content and local navigation. Page templates are commonly used when developing content management systems.

Persona

Persona is a fictional character with all the characteristics of the user. Personas are created after the field research process, which typically consists of members of the primary stakeholder (user) group being observed on their behavior, and additionally answering questionnaires or participating in interviews, or a mixture of both.

Prototypes

Prototypes are models of the system. Prototypes can be as simple as paper-based sketches, or as complex as fully interactive systems. Research shows that paper-based prototypes are just as effective for identifying issues as fully interactive systems. Prototypes are often developed to bring the information architecture to life. Thus enabling users and other members of the project team to comment on the architecture before the system is built.

Storyboards

Storyboards are another technique for bringing the information architecture to life without building it. Storyboards are sketches showing how a user would interact with a system to complete a common task. Storyboards enable other members of the project team to understand the proposed information architecture before the system is built.

Wireframes

Wireframes are rough illustrations of page content and structure, which may also indicate how users will interact with the website. These diagrams get handed off to a visual designer, who will establish page layout and visual design.

Wireframes are useful for communicating early design ideas and inform the designer and the client of exactly what information, links, content, promotional space, and navigation will be on every page of the site. Wireframes may illustrate design priorities in cases where various types of information appear to be competing.

Analysis Tools Used in User-Centered Design

There are few tools that are used in user centered design. They are persona, scenarios, and essential use cases.

Persona

During the UCD process, a persona of the user's need may be created. It is a fictional character with all the characteristics of the user. Personas are created after the field research process, which typically consists of members of the primary stakeholder (user) group being observed on their behaviour, and additionaly answering questionnaires or participating in interviews, or a mixture of both.

After results are gathered from the field research, they are used to create personas of the primary stakeholder group. Often, there may be several personas concerning the same group of individuals, since it is almost impossible to apply all the characteristics of the stakeholder group onto one character. The character depicts the a "typical" stakeholder, not an "average" individual in the primary stakeholder group, and is referred to throughout the entire design process.

There are also what's called a secondary persona, where the character is not a member of the primary stakeholder group and is not the main target of the design, but their needs should be met and problems solved if possible. They exist to help account for further possible problems and difficulties that may occur even though the primary stakeholder group is satisfied with their solution.

There is also an anti-persona, which is the character which the design process is not made for. Personas usually include a name and picture, demographics, roles and responsibilities, goals and tasks, motivations and needs, environment and context, and a quote that can represent the character's personality.

Personas are useful in the sense that they create a common shared understanding of the user group for which the design process is built around. Also, they help to prioritize the design considerations by providing a context of what the user needs and what functions are simply nice to add and have. They can also provide a human face and existence to a diversified and scattered user group, and can also create some empathy and add emotions when referring to the users.

However, since personas are a generalized perception of the primary stakeholder group from collected data, the characteristics may be too broad and typical, or too much of an "average joe". Sometimes, personas can have stereotypical properties also. Overall, personas are a useful tool that can be used since designers in the design process can have an actual person to make design measure around other than referring to a set of data or a wide range of individuals.

Scenario

A scenario created in the UCD process is a fictional story about the "daily life of" or a sequence of events with the primary stakeholder group as the main character. Typically, a persona that was created earlier is used as the main character of this story. The story should be specific of the events happening that relate to the problems of the primary stakeholder group, and normally the main research questions the design process is built upon.

These may turn out to be a simple story about the daily life of an individual, but small details from the events should imply details about the users, and may include emotional or physical characteristics. There can be the "best case scenario", where everything works out best for the main character, the "worst case scenario", where the main character experiences everything going wrong around him or her, and an "average case scenario", which is the typical life of the individual, where nothing really special or really depressing occurs, and the day just moves on.

Scenarios create a social context to which the personas exist in, and also create an actual physical world, instead of imagining a character with internal characteristics from gathered data an nothing else; there is more action involved in the persona's existence. A scenario is also more easily understood by people, since it is in the form of a story, and is easier to follow.

Use case

In short, a use case describes the interaction between an individual and the rest of the world. Each use case describes an event that may occur for a short period of time in real life, but may consist of intricate details and interactions between the actor and the world.

It is represented as a series of simple steps for the character to achieve his or her goal, in the form of a cause-and effect scheme. A use case should:

• Describe what the system shall do for the actor to achieve a particular goal. 
• Include no implementation-specific language. 
• Be at the appropriate level of detail. 
• Not include detail regarding user interfaces and screens. This is done in user-interface design, which references the use case and its business rules.

Use cases are useful because they help identify useful levels of design work. They allow the designers to see the actual low level processes that are involved for a certain problem, which makes the problem easier to handle, since certain minor steps and details the user makes are exposed. They also convey useful and important tasks where the designer can see which one are of higher importance than others.

Tomorrow: tools of information architecture.

User-Centered Design

User-centered design (UCD) is a design philosophy and a process in which the needs, wants, and limitations of end users of a product are given attention at each stage of the design process. 

User-centered design can be characterized as a multi-stage problem solving process that not only requires designers to analyze and foresee how users are likely to use a product, but also to test the validity of their assumptions with regards to user behaviour in real world tests with actual users. 

Such testing is necessary as it is often very difficult for the designers of a product to understand intuitively what a user of their design experiences, and what each user's learning curve may look like. The main difference from other product design philosophies is that user-centered design tries to optimize the product around how users can, want, or need to use the product, rather than forcing the users to change their behavior to accommodate the product. 

For example, the user-centered design process can help software designers to fulfill the goal of a product engineered for their users. User requirements are considered right from the beginning and included into the whole product cycle. These requirements are noted and refined through investigative methods including: ethnographic study, contextual inquiry, prototype testing, usability testing and other methods. 

Generative methods may also be used including: card sorting, affinity diagraming and participatory design sessions. In addition, user requirements can be understood by careful analysis of usable products similar to the product being designed. 

UCD answers questions about users and their tasks and goals, then uses the findings to make decisions about development and design. UCD of a web site, for instance, seeks to answer the following questions:

• Who are the users of the document? 
• What are the users’ tasks and goals? 
• What are the users’ experience levels with the document, and documents like it? 
• What functions do the users need from the document? 
• What information might the users need, and in what form do they need it? 
• How do users think the document should work? 

As examples of UCD viewpoints, the essential elements of UCD of a web site are considerations of visibility, accessibility, legibility and language. 

Visibility 

Visibility helps the user construct a mental model of the document. Models help the user predict the effect(s) of their actions while using the document. Important elements (such as those that aid navigation) should be emphatic. Users should be able to tell from a glance what they can and cannot do with the document. 

Accessibility 

Users should be able to find information quickly and easily throughout the document, regardless of its length. Users should be offered various ways to find information (such as navigational elements, search functions, table of contents, clearly labeled sections, page numbers, color coding, etc). Navigational elements should be consistent with the genre of the document. 

"Chunking" is a useful strategy that involves breaking information into small pieces that can be organized into some type meaningful order or hierarchy. The ability to skim the document allows users to find their piece of information by scanning rather than reading. Bold and italic words are often used. 

Legibility 

Text should be easy to read: Through analysis of the rhetorical situation, the designer should be able to determine a useful font style. Ornamental fonts and text in all capital letters are hard to read, but italics and bolding can be helpful when used correctly. Large or small body text is also hard to read. (Screen size of 10-12 pixel sans serif and 12-16 pixel serif is recommended.) High figure-ground contrast between text and background increases legibility. Dark text against a light background is most legible. 

Language 

Depending on the rhetorical situation, certain types of language are needed. Short sentences are helpful, as well as short, well-written texts used in explanations and similar bulk-text situations. Unless the situation calls for it, do not use jargon or technical terms. Many writers will choose to use active voice, verbs (instead of noun strings or nominals), and simple sentence structure. 

A user-centered design is focused around the rhetorical situation. The rhetorical situation shapes the design of an information medium. There are three elements to consider in a rhetorical situation: audience, purpose, and context. 

Audience 

The audience is the people who will be using the document. The designer must consider their age, geographical location, ethnicity, gender, education, etc. 

Purpose 

The purpose is what the document is targeting to or what problem is the document trying to address. 

Context 

The context is the circumstances surrounding the situation. The context often answers the question: What situation has prompted the need for this document? Context also includes any social or cultural issues that may surround the situation. 

User-centered design involves simplifying the structure of tasks, making things visible, getting the mapping right, exploiting the powers of constraint, and designing for error.

Tomorrow, I will talk about analysis tools used in user-centered design.

Information Architecture and Usability

The distinction between information architecture and usability may seem like semantics, but there are significant differences between the two disciplines.

Though they are often discussed interchangeably, and practitioners are often well-versed in both, information architecture and usability differ in their scope and areas of focus.

The difference between information architecture and usability is important to understand because information architecture is more than just understanding what users want and need. A usability-only approach to information architecture is only one piece of the puzzle.

Information architecture problems often account for a large percentage of usability problems, but there are many other things unrelated to information architecture that have an impact on usability.

Usability encompasses two related concepts:

• Usability is an attribute of the quality of a system: "we need to create a usable intranet". 
• Usability is a process or set of techniques used during a design and development project: "we need to include usability activities in this project". 

In both cases usability is a broader concept, whereas information architecture is far more specific.

Usability is a detailed subject, taking into account things like font size, colors, visual proximity, usage context, search, error messages, navigation, form design, and labeling. Of these, only a few are true information architecture issues. Navigation, labeling, site architecture and search results all have an impact on the usability of a site, but they are not the only things that affect usability.

An effective information architecture is one of a number of attributes of a usable system. Other factors involving the usability of a system include:

• visual design 
• interaction design 
• functionality 
• content writing 

The process for creating an effective information architecture is a sub-set of the usability activities involved in a project. Although weighted to the beginning of the project, usability activities should continue throughout a project and evaluate issues beyond simply the information architecture.

In terms of great usability information architecture, it is the information architecture that makes it easy for users to find desired information or functionality. On a website, the information architecture can also add important context to the current page (for example when a user begins their visit deep within the website, having come directly from a search engine).

A "bricks and mortar" architect must balance the demands of aesthetics, structural integrity, heating, lighting, water supply and drainage when creating building blueprints. Similarly, an information architect must create navigation schemes for web sites, content management systems, etc. that are at once concise, descriptive, mutually-exclusive, and intuitive. Both types of architects seek to create spaces for humans that are safe, predictable, enjoyable, and inspiring.

Usable navigation systems should: 

• Be easy to learn. 
• Be consistent throughout the web site, CMS, etc. 
• Provide feedback, such as the use of breadcrumbs to indicate how to navigate back to where the user started. 
• Use the minimum number of clicks to arrive at the next destination. 
• Use clear and intuitive labels, based on the user’s perspective and terminology. 
• Support user tasks. 
• Have each link distinct from other links. 
• Group navigation into logical units. 
• Avoid making the user scroll to get to important navigation or submit buttons. 
• Not disable the browser’s back button. 

Steps to develop an intuitive information architecture: 

1. Find out what the mission or purpose of the website is: why will people come to your site?

2. Determine the immediate and long-range goals of the site: are they different?

3. Pinpoint the intended audiences and conduct a requirements analysis for each group.

4. Collect site content and develop a content inventory.

5. Determine the website’s organizational structure, which can include:

• hierarchical
• narrow and deep 
• broad and shallow 
• sequential  
• tag-based 

6. Create an outline of the site, which can include:

• Content Inventory: a hierarchical view of the site content, typically in a spreadsheet format, which briefly describes the content that should appear on each page and indicates where pages belong in terms of global and local navigation. 
• Site Maps: visual diagrams that reflect site navigation and main content areas. They are usually constructed to look like flowcharts and show how users will navigate from one section to another. Other formats may also indicate the relationships between pages on the site. 

7. Create a visual blueprint of the site, which can include:

• Wireframes: rough illustrations of page content and structure, which may also indicate how users will interact with the website. These diagrams get handed off to a visual designer, who will establish page layout and visual design. Wireframes are useful for communicating early design ideas and inform the designer and the client of exactly what information, links, content, promotional space, and navigation will be on every page of the site. Wireframes may illustrate design priorities in cases where various types of information appear to be competing. 

8. Define the navigation systems:

• Global navigation: Global navigation is the primary means of navigation through a website. Global navigation links appear on every page of the site, typically as a menu located at the top or side of each web page. 
• Local navigation: Local links may appear as text links within the content of a page or as a submenu for a section of the website. Local navigation generally appears in the left-hand margin of a web page and sometimes is placed below the global navigation. 
• Utility links: Utility links appear in the header or footer of every page. These may include infrequently used links such as: Contact Us, About Us, Customer Support, Customer Feedback, Privacy Policy, Terms of Use, Site Map, Press Room, etc. Search boxes often appear in the header of the site as well, so the Search feature is available on every page of the site. 

9. Conduct user research. Once you have a draft navigation structure, conduct appropriate usability research to collect feedback from the target audience. Methods may include: card sorting, cognitive walkthroughs, contextual task analyses, and usability testing.

Information Architecture Styles

There are two main approaches to defining an information architecture. They are:

Top-down information architecture

This involves developing a broad understanding of the business strategies and user needs, before defining the high level structure of site, and finally the detailed relationships between content.

Bottom-up information architecture 

This involves understanding the detailed relationships between content, creating walkthroughs (or storyboards) to show how the system could support specific user requirements and then considering the higher level structure that will be required to support these requirements.

Both of these techniques are important in a project. A project that ignores top-down approach may result in well-organized, findable content that does not meet the needs of users or the business. A project that ignores bottom-up approach may result in a site that allows people to find information but does not allow them the opportunity to explore related content. Take a structured approach to creating an effective information architecture.

The following steps define a process for creating an effective information architecture:

1. Understand the business/contextual requirements and the proposed content for the system. Read all existing documentation, interview stakeholders and conduct a content inventory.
2. Conduct cards sorting exercises with a number of representative users.
3. Evaluate the output of the card sorting exercises. Look for trends in grouping and labeling.
4. Develop a draft information architecture (i.e. information groupings and hierarchy).
5. Evaluate the draft information architecture using the card-based classification evaluation technique.
6. Don’t expect to get the information architecture right first time. Capturing the right terminology and hierarchy may take several iterations.
7. Document the information architecture in a site map. This is not the final site map, the site map will only be finalized after page layouts have been defined.
8. Define a number of common user tasks, such as finding out about how to request holiday leave. On paper sketch page layouts to define how the user will step through the site. This technique is known as storyboarding.
9. Walk other members of the project team through the storyboards and leave them in shared workspaces for comments.
10. If possible within the constraints of the project, it is good to conduct task-based usability tests on paper prototypes as it provides valuable feedback without going to the expense of creating higher quality designs. Create detailed page layouts to support key user tasks. Page layouts should be annotated with guidance for visual designers and developers.

Developing an information architecture in this way enables you to design and build a system confident that it will be successful. It simply isn’t good enough for organizations to build functionality or write content, put it on their computer systems and expect people to be able to find it.

Developing an effective information architecture is an essential step in the development of all computer systems. Effective information architectures enable people to quickly, easily and intuitively find content. This avoids frustration and increases the chance that the user will return to the system the next time they require similar information.

Remember: people can only appreciate what they can actually find.

Information Architecture

Information architecture is defined by the Information Architecture Institute as the art and science of organizing and labeling web sites, intranets, online communities, and software to support findability and usability.

Information architecture is the term used to describe the structure of a system, i.e the way information is grouped, the navigation methods and terminology used within the system. An effective information architecture enables people to step logically through a system confident they are getting closer to the information they require. Information architecture is most commonly associated with websites and intranets, content management systems, but it can be used in the context of any information structures or computer systems.

Information architecture involves the categorization of information into a coherent structure, preferably one that the intended audience can understand quickly, if not inherently, and then easily retrieve the information for which they are searching. The organization structure is usually hierarchical.

Organizing functionality and content into a structure that people are able to navigate intuitively doesn’t happen by chance. Organizations must recognize the importance of information architecture or else they run the risk of creating great content and functionality that no one can ever find. Most people only notice information architecture when it is poor and stops them from finding the information they require.

An effective information architecture comes from understanding business objectives and constraints, the content, and the requirements of the people that will use the site.

Information architecture is often described using the following diagram:

Business/Context 

Understanding an organization's business objectives, politics, culture, technology, resources and constraints is essential before considering development of the information architecture. Techniques for understanding context include:

• reading existing documentation;
• mission statements, organization charts, previous research and vision documents are a quick way of building up an understanding of the context in which the system must work;
• stakeholder interviews;
• speaking to stakeholders provides valuable insight into business context and can unearth previously unknown objectives and issues. 

Content

The most effective method for understanding the quantity and quality of content (i.e. functionality and information) proposed for a system is to conduct a content inventory. Content inventories identify all of the proposed content for a system, where the content currently resides, who owns it and any existing relationships between content. Content inventories are also commonly used to aid the process of migrating content between the old and new systems.

Users 

An effective information architecture must reflect the way people think about the subject matter. Techniques for getting users involved in the creation of an information architecture include card sorting and card-based classification evaluation.

Card sorting involves representative users sorting a series of cards, each labelled with a piece of content or functionality, into groups that make sense to them. Card sorting generates ideas for how information could be grouped and labelled.

Card-based classification evaluation is a technique for testing an information architecture before it has been implemented. The technique involves writing each level of an information architecture on a large card, and developing a set of information-seeking tasks for people to perform using the architecture.

More about information architecture next time...

Engineering Change Process

Let's look at the engineering change process and how Engineering Change Order (ECO) is used in this process.

The stages of the engineering change process are:

1. Issue identification & scoping:

Someone identifies a problem or issue and determines that it may require a change. The scope of the issue and its possible impact are estimated.

2. ECR creation:

An engineering change request (ECR) is created to examine the necessity and feasibility of the change, to identify parts, components and documentation that might be affected, to estimate costs and to list the resources required to implement the change.

3. ECR review:

The ECR is circulated for review and discussion among key stakeholders and is modified as needed.

4. ECO creation:

Once the ECR is approved, an engineering change order (ECO) is generated, which lists the items, assemblies and documentation being changed and includes any updated drawings, CAD files, standard operating procedures (SOPs) or manufacturing work instructions (MWIs) required to make a decision about the change.

5. ECO review: The ECO is then circulated to a change review board made up of all stakeholders (including external partners when appropriate) who need to approve the change.

6. ECN circulation:

Once the ECO has been approved, an engineering change notification/notice (ECN) is sent to affected individuals to let them know that the ECO has been approved and the change should now be implemented.

7. Change implementation:

Those responsible for implementation use the information in the ECO and ECN to make the requested change. While an engineering change order is used for changes that are executed by engineering, other types of change orders may be used by other departments. These include the:

• Manufacturing change order (MCO) — A change order describing modifications to the manufacturing process or equipment.

• Document change order (DCO) — A change order detailing modifications to documents, specifications or SOPs.

ECO benefits

While you may groan at the prospect of pulling together another set of documentation, an ECO is a critical part of keeping product development on track and making sure product information is accurate. A good ECO contains the full description, analysis, cost and impact of a change, and a good ECO process ensures that all stakeholders have bought in to the change. Having an organized method of handling product changes reduces potential design, manufacturing and inventory errors, minimizes development delays and makes it easy to get input from different departments, key suppliers and contract manufacturers.

Following good ECO practices also makes it easy to document a full history of what changes have been made to a product and when they occurred. In industries with regulatory requirements, like the medical device industry, having a full history of every change to a product is mandatory. Depending on the industry, change orders and even the change process itself may be audited by a regulatory body. Keeping a record of product changes will also help you debug any problems that occur after your product launches. The task of identifying and fixing the root cause of any problem is easier when you have a complete product change history.

Without a clear ECO process in place, making a change to a product can set off a chain of costly, time-consuming and avoidable events. Take a part switch that happens late in the development process. Engineering may tell manufacturing to be aware of the new part, but if that information is never conveyed to the purchasing department, the old part will be ordered. When the components arrive, manufacturing will not be able to assemble the product, and its launch will be delayed until the new part is obtained (most likely with some rush charges incurred along the way).

Engineering change orders make it possible to accurately identify, address and implement product changes while keeping all key stakeholders in the loop and maintaining a historical record of your product. Without them, miscommunications occur that lead to delays, incorrect purchase orders and improper product builds.

Companies need to be able to adapt quickly in today’s constantly changing environment, and often that means making changes to their products. Engineers make modifications during development and production with the intent of adding functionality, improving manufacturing performance or addressing the availability of a particular part.

To make sure proposed changes are appropriately reviewed, a solid process is critical, especially if members of your product team are scattered across multiple locations (for instance, design engineers in Boston, the manufacturing team in St. Louis and component manufacturers all over the world). At the heart of a solid change process is the engineering change order.

Engineering Change Orders: Paper-Based vs. Electronic Documentation Systems

	Managing Paper ECO	Managing Electronic ECO
Cycle Time	·         ECO is generally reviewed one person at a time. ·         If multiple copies are distributed, edits must be consolidated and reviewed again. ·         Paper ECO can be misplaced ECO review can be a long process (weeks).	·         ECO can be reviewed by many people  at  once. ·         All edits are made to a single version, so no consolidation is needed. ·         ECO is always available online.ECO review is significantly shorter process (days).
Signature Process	·         Early approvers won’t be aware of edits, necessitating additional rounds of review. ·         Official approval disappears if the ECO file is lost. ·         Harder to maintain clean, complete history of changes.	·         All approvers sign off on the same set of documentation. ·         Electronic signature is 21 CFR part 11 compliant, a requirement for the medical device industry. ·         Automatic maintenance of clean history for audits.
Issue Resolution	·         Individuals need to be tracked down to resolve problems. ·         May need to wait for change control review board meeting to connect with other approvers.	·         People’s comments can be viewed, so hold-ups can be quickly resolved ·         Can easily see who hasn’t signed and request approval electronically.
Package Format	·         Large paper file of documents and drawings must be printed. ·         Tedious and labor-intensive to pull together information from many locations.	·         Electronic documentation is environmentally friendly. ·         Easy to create and access ECO when managed in the same system as underlying product information.

Document Control

The primary purpose of document control is to ensure that only current documents and not documents that have been superseded are used to perform work and that obsolete versions are removed. Document control also ensures that current documents are approved by the competent and responsible for the specific job persons and are distributed to the places where they are used. In regulated industries, this function is mandatory.

If a company is ISO 9001 compliant, it has document control it place. Document control is a part of ISO 9001 and GMP/GxP requirements.

There are four steps in the document control system:

1. Define the scope of the document control system (which documents must be controlled).

2. Develop a document authorization or approval system.

3. Ensure that only current versions of documents are used at the work places where they are used.

4. Out of date documents that need to be archived must be suitably identified.

Let's look at these steps more closely.

1. Identify which documents need to be controlled

The first task is to identify which documents need to be controlled.

The most important rule of document control is that only current documents must be used for work. You may find that other documents are less vital and it may not be worth the effort of controlling them.

You may even decide to have different levels of document control for different types of documents, e.g. formal approval and controlled distribution for procedures and work instructions, controlled distribution for your list of legal requirements, etc.

2. Define a document approval system

An approval/authorization system ensures that distributed documents are appropriate for persons receiving them. A responsible person must approve these documents. This approval can be in two different forms: on paper documents it will be a signature, on electronic documents it will be either electronic signature or they may only be published when they are approved. If there is no electronic signature, the approval usually can be verified through electronic workflow the document went through to get approved.

When a new document is created or a document is going through a change, Engineering Change Order (ECO) is used to document and approve the document creation or changes. It can also be called Engineering Change Notice (ECN) or Document Change Notice (DCN). ECO outlines the proposed change, lists the product or part(s) that would be affected and requests review and approval from the individuals who would be impacted or charged with implementing the change. ECOs are used to make modifications to components, assemblies, associated documentation and other types of product information.

The change process starts when someone identifies an issue that may need to be addressed with a change to the product. It ends when the agreed-upon change is implemented. ECOs are used in between to summarize the modifications, finalize the details, and obtain all necessary approvals.

3. Assure appropriate distribution

During this step, you need to make sure that everyone who needs the document gets a copy.

Distribution may be physical (paper documents) or electronic. When posting the document on intranet or other electronic systems, ensure that everybody who needs to have the new document knows about the posting (e.g. through an email or workflow notifications). When distribution is physical (paper documents), documents need to be stamped to identify that this is a controlled document and that a user of this document needs to verify that this is the most current version before starting work.

An inventory of controlled documents should be created with the exact location of each controlled document.

4. Remove old and obsolete documents

This is easy if you use an electronic documentation management system but is more complicated with paper documents.

You may request the receiver of new documents to send back obsolete ones. If for some reason you need to retain obsolete versions of documents, they need to be marked to avoid unintended use. Many organisations use a stamp: "obsolete document".

Next time: I am going to talk more about ECO and engineering change process.