Information Architecture Jennifer A. Fell email@example.com September 13, 2006
Agenda • Introduction • Me • My team • About my roles • Strategist • Architect • My information architecture philosophy • Technology and tools: A nod
About me • Information Strategist and Architect for a portfolio of products at IBM • 16+ years of information and software development expertise • Training • B.A. in English; minor in computer science • Practiced in user-centered design and testing • Conversant in human factors • Roles • Information developer • Course developer • Course instructor • Information development team lead • UI designer • Member of technical staff • Manager • VP of Engineering
My team • Reports to a central User Technology team • Matrixed into portfolio development team • Approximately 20 products • 3 brands • Information development team • 3 managers • 3 editors, including 1 terminologist • ~30 writers • Scope: All text that is provided with the product • UI labels, messages, embedded introductions and assistance • Introductory tutorials and viewlets • Help • Conceptual, task, and reference information
About you • What is your role on the team? • Do you have a strategist on your team? • Do you have an information architect on your team? • What does your information architect do?
Information strategy: The business of what we deliver • Ensure that we are spending money on the things that have the biggest impact to the business and our customers today and tomorrow. • Ensure that we are competitive in the marketplace.
Information strategy: Where are we now? • Strategy considers questions such as • What are the strengths of our information? • What are the weaknesses of our information? • What are our opportunities? • What are our threats? • What are other information development teams doing • Within the broad profession? • At my company? • The users evaluate the strengths and weaknesses of our information
Information strategy:What are others doing? • What is the business strategy? • What is the product strategy? • What is the sales strategy? • What is the corporate information strategy? • What is the software group information strategy? • What is the competition doing?
Information strategy: Where are we going? • Strategy answers questions such as • What kind of information do we deploy on the Web today? Tomorrow? • Should we provide cross-product solution information? What are the key solutions we should address? • What is the roadmap for getting there from here?
Information strategist in action • Collaborate across the product planning and leadership team • Product management • Marketing • Information development • User experience • Collaborate with other portfolio and product teams • Evaluate and helps bring forward strategic initiatives from within information development, including product initiatives • Evaluate new projects • What do customers need? • What do we have that can be leveraged? • What will it cost? (work items and estimates)
The result: Priorities backed by the business • Support flexible product packaging strategy and solution bundling by providing information that can more easily be reused • Decrease time-to-value by providing better installation and introductory information • Decrease support costs by providing more troubleshooting information, especially on the Web where customers can find it via Google
Questions • Who determines information strategy on your team? • Could you articulate your team’s information strategy if asked? • Could your extended team?
Information architecture is… • The implementation of the strategy
An information architect… • Understands the users, products, technology, competition, and business, working with UE, human factors, marketing, development, service, support: • Researches & understands user requirements • Assists in user and task modeling, using those models to define information model • Assists in developing personas • Assists in developing scenarios • Assists in designing the UI task flow, and therefore the information flow • Finds the patterns inherent in data, making the complex clear • Validate designs with intended users • Owns and drives the information-related aspects of all of these
An information architect… (cont) • Defines the overall solution for how information is delivered (vs. authored, developed, or managed), based on user’s goals and user’s context: • Information model & organization of content • Navigation & linking & retrieval • Location & storage (Web, CD, installed) • Information architecture ensures that information is retrievable, presents a cohesive mental model, and is consistent, especially across products • Fulfills a formal role, defined as part of the corporate IRUP process • In short: An information architect makes sure the pieces connect to provide the greatest value to all customers.
The IA role does not include… • Information development team lead role • Ownership/responsibility for the documentation plan • Ownership/responsibility for executing the ID plan • ID project manager role • Project management, tracking, scheduling, etc. • ID infrastructure lead role • Ownership/responsibility for the technical details of the implementation, including designing solutions and creating processes for file storage and version control, information builds, information testing, etc. • The same person might fill all of these roles on some teams, but as a role, IA is not about these things. I don’t fill these other roles on my team right now.
Day-to-day • I lead or participate in development of • Scenario development • User role and persona descriptions • Task analysis and modeling • I am a mandatory reviewer for • Information plans • Content plans • Navigation and tables of contents • Templates (such as DITA specializations) • I help seek and analyze user feedback • Customer feedback plans and summaries • Customer advisory board presentations and results • Customer conference presentations and results
Information architecture’s impact on the business • Customers consistently request: • Better retrievability • Solution-oriented information • A seamless information experience across products • Good information architecture can fulfill those requests and: • Reduce total cost of ownership • Reduce customer support calls • Reduce number of non-defect customer support issues (NDOPs) • Increase customer satisfaction • All information developers can work toward these goals in their information deliverables and contribute to the overall information architecture.
My approach • Strategy is the foundation • Move information close to the user • Progressively disclose information • Architect for flexibility • People buy products; they don’t use them • Topic-based information • Component-based architecture • Dynamic delivery
Build off the foundation Tools Technology Architecture Strategy
Move information close to the user • Everything the user sees is a user interface, including APIs • Work with UI and user experience teams to make the interface as easy-to-use as possible • Embed as much information as practical directly in the UI itself • Getting Started or Welcome pages • UI labels • Message text complete with user action for recovery
Progressively disclose information • Progressively disclose more information at user’s request • Hover help or tool tips • Contextual help • Complete conceptual, task, reference information • Seamless connections and transitions • The user should never have to hunt for the next clue • This is not a scavenger hunt
Architect for flexibility • My team contributes to 20 products, under 3 brands • Products historically renamed once each year • Some capabilities are provided in 6 products • Customers want solutions, not products, so solution bundles are becoming more common…and need to be flexible to market needs
People don’t use products • People use solutions, capabilities, features, technical components • Example • Goal: federating information • Capability: federation • Technical component: federated server • Product: IBM WebSphere Federation Server • Product name reserved for things that exist because we package as products: installation, release notes, what’s new • Capabilities, technical components referred to in most other product information • Cornerstone of re-use on my team: Information can be reused wherever we provide federation capability
Topic-based information • One thought or idea • The most finely grained portion of content that merits or requires individual treatment • Questions to consider when chunking • Can the information be segmented into multiple chunks that users might want to access separately? • What is the smallest section of content that needs to be individually indexed? • Will this content need to be re-purposed across multiple documents or as part of multiple documents?
Why topics? • Flexibility in presentation • Structure • Organization • Categorization • Necessary redundancy • Reuse • Across products • Across divisions • Outside the company • Single sourcing for reuse decreases maintenance time—maybe • Minimalist—enables us to provide just the information users need, just when they need it
Component-based architecture • An information component is • A group of related topics that “travel” together • The largest group of topics that won't ever be split apart as a result of remarketing, repackaging, technological componentization, user tasks, or usage scenarios. • The topics in a component also won't be split apart for our own work management purposes; all topics in a component are owned by the same information developer • Power is in the ability to assemble them in new and interesting ways as needs change
Product’s PDF Suite Book 1 Segment Segment Segment Component Component Component Component Component Component Component Component Component Component Modeling components and deliverables • Components packaged into information center plug-ins • Components packaged into PDF books • Plug-in and book definitions can cross segment ownership • Product information set is a collection of plug-ins and PDF books Book 2
Product’s Information Center Plug-in 1 Plug-in 3 Plug-in 4 Plug-in 2 Segment Segment Segment Component Component Component Component Component Component Component Component Component Component Modeling components and deliverables (cont’d)
Dynamic delivery • Information adapts • Products and capabilities installed • Platforms used • User level • Information components hide and become visible as needed • Runtime instead of development-time reuse • Plug-and-play components • Not “starter doc”
DITA and Eclipse • DITA enforces topic-based information • DITA support components • At least 1 DITA map per component • Maplists combine maps in a component • Maplists combine maps across components • Eclipse provides flexible delivery • Dynamic integrated navigation across all installed components • Future: Filtering components • And that’s how I got here tonight
Resources: Information architecture and design • Don’t Make Me Think, Steve KrugA short, excellent book that contains human factors, usability, and information architecture and design information. Well worth the short read. • Web Navigation, Jennifer FlemingNavigation is a critical part of the information architecture of products, Web sites, and online information systems. This book covers principles that apply to all of these. • Information Architecture for the World Wide Web, Lou Rosenfeld and Peter MorvilleSays Web, but principles apply generally. Excellent book. • Developing Quality Technical Information, 2nd ed., Gretchen Hargis, et al. w3.svl.ibm.com/usertech/ecouncil/dqti/DQTI.PDF IBM’s very own. The basis for our Edit For Quality process. Sleep with it under your pillow.
Resources: Information architecture and design • Asilomar Institute for Information Architecturewww.aifia.orgProfessional organization for information architects. • Society for Technical Communicationwww.stc.orgProfessional organization for technical communicators. SIGs for usability and information design are particularly pertinent.
Resources: Human factors • Human Factors for Technical Communicators, Marlana CoeAn excellent introduction to human factors that is specific to information use. • Human Factors and Ergonomics Societyhfes.orgProfessional society dedicated to promote the discovery and exchange of knowledge concerning the characteristics of human beings that are applicable to the design of systems and devices of all kinds. • ACM’s SIGCHIwww.acm.org/sigchiA special interest group (SIG) of the Association for Computing Machinery (ACM) focused on computer-human interaction (CHI)—those working on the design, evaluation, implementation, and study of interactive computing systems for human use.
Resources: User-centered process and usability • The Inmates are Running the Asylum, Alan CooperThe ultimate cranky developer takes on the software-development process and the lack of user-centered approach. Justifies design before coding. • Usability Engineering, Jakob NielsenEarly process book; basis for most later approaches. • The Usability Engineering Lifecycle, Deborah J. MayhewGood end-to-end process coverage. • Software for Use, Larry Constantine and Lucy LockwoodA very detailed, model-oriented, engineering approach to user-centered design.
Resources: UI design • The Design of Everyday Things, Don Norman.This could be considered a human factors or usability book. A seminal work. • About Face, 2nd ed., Alan CooperUpdate of an early classic. Adds significant Goal-Directed Design™ (Cooper’s process) information. • Designing Visual Interfaces, Kevin MulletVisual communication in UI design. • Designing Effective Wizards, Daina Pupons WickhamWizards are an important information deliverable in the UI! • uidesign.net www.uidesign.netWebzine/information site with timely UI design opinion and resources. • User Interface Engineeringwww.uie.comJared Spool’s primarily Web-oriented usability and design site. Interesting research results.