By Dana Martinelli, Information Architect, sunKING Interactive
One term that's emerging with more popularity in the digital community is the term, "Information Architect." Depending on who uses it, the term can take on different meanings. With this in mind, I'd like to offer up a peek inside the life of an information architect (that would be me) to help define the term. In short, information architecture is the pursuit of defining, maintaining and expressing visual interactive structures within a complex system.
Information architecture (IA) is a discipline that leverages many forms of analysis in order to visually and contextually explain specific interaction metaphors to a varied group of professionals within a wide range of skill sets. The product from an IA is a series of well-defined actionable documents, which contain rules and reasoning for a proposed system that can be understood by three core teams; stakeholders, visual designers and developers. Essential core goals of the IA are: to refine and express process, define elegance and mitigate risk. These are lofty goals and each goal can take several teams of very well-coordinated individuals in order to work successfully. Information architecture is a discipline that must understand the goals of these teams in order to build processes, which can empower the teams to work together, harmoniously, and in turn, build an elegant interactive system. It is a correct assumption to think of an IA as someone who can think like a business analyst, a designer and a developer, and anticipate the needs of each.
IA In Practice
Ultimately, the study of information architecture is to study and document needs and how they can be satisfied by a system’s purpose. These needs are at the center of where inspiration is and where all decisions are made for the IA. For an interactive system to succeed, an IA must build metrics, traceability, and reasoning on why something is integrated into a system and how it relates directly to the user. In practice, and for optimal results, it is best to segment levels of analysis in order to not overwhelm the client or the process.
I have outlined a much-diluted overview of my IA workflow process and how it relates to the complete production cycle from client discovery to functional specification documents. I personally work within three development methodologies that contain user-centric exercises, which I call fidelities. There is a sketch stage, a prototype stage and specification stage.
In the sketch stage, I like to gather as much knowledge about a target system and its users in order to better understand convention. This is usually done by creating a glossary which relates directly to the unique language of the industry and/or system. Next, personas or user profiles that capture the audience of the system are built. Sample user tasks are then sketched to better understand what the system is intended to do for the user. Once these core elements are satisfied, a mental model is built. The book by Indi Young, Aligning Design Strategy With Human Behavior from Rosenfield Media (http://rosenfeldmedia.com/books) has some fantastic examples of what mental models are and when to use them. In short, a mental model is an exercise which helps define potential user tasks as it relates to the goals of stakeholders and the developers. Most importantly, the exercise helps engage the developers early on in the discovery process.
Engaging the development team at this stage helps provide much-needed feedback on any IT limitations the system or the user interface may have. It also can limit development surprises when the functional specification document is handed off at the end of fidelity three. It is best practice to distill the mental model into a well-defined high-level business requirement document, which is usually maintained within a spreadsheet with each requirement numerically tracked. Also in Fidelity Level 1 is the mind map.
There is a great, free open source tool for this called FreeMind (http://freemind.sourceforge.net/wiki/index.php/Main_Page). Mind mapping can dramatically condense the complexity of the mental model into unified visual structures, which are very easy to navigate and can be essential in finding interrelationships.
In Fideilty Level 2, there is an exercise I like to call “the speedboard.” This exercise defines global structure, first phase site map hierarchy, technology constraints, and content management regions. This exercise visually segments each page into content parts within each proposed page and helps identify how a content management system (CMS) may react within the site. Parallel to this effort, designers are usually busy creating a style guide and visual language enforced by established branding. Once a global site structure and content map is built from the speedboard exercise, a more complex and detailed visual prototype is developed which dives deeper into the structure and begins to define actual user experience metaphors.
At this point, the client is fully engaged and multiple rounds of meetings occur which relate to validation and sign-off. Sign-off is essential at this point since it is what drives the merger of the style guide and the prototype. It is important to be sure the client understands that the prototype is not the final design. As the prototype matures and final designs get added, the functional specification round begins.
In Fideilty Level 3, the IA, the project manager, and developers work together closely to scrub each page and target page regions which will need detailed clarification for both quality assurance and development lifecycles. It is best practice to define each page region and design patterns with traceability back to the high level business requirement document. The goal here is to capture all functionality and compose language which is digestible by a developer. There is an excellent tool called Axure (www.axure.com), which is used to satisfy many of these efforts. Axure, if utilized to its fullest, can simulate working interfaces, capture functional specs and provide documentation for quality assurance and usability testing.
This overview only scratches the surface, but in the end, should shed some light on Information Architecture as a career path, as well as help employers to better understand the IA process and how they can best incorporate it into their next project. If implemented correctly, the IA process can help reduce risk and increase turnaround dramatically. n
Dana Martinelli is an Information Architect with sunKING Interactive and a freelance consultant. He can be reached at martinelli@gmail.com