I was in a meeting with a client discussing the approach to Information Architecture – how to develop scenarios and use cases for a target audience and then transform those details into a usable web site. At one point in the discussion, the client said “Maybe I am missing something but I don’t get it – I don’t see the value”. I could not contain my surprise – I exclaimed “Really?? You don’t??” I was taken aback.
After all, information is the most fundamental asset of the organization. All of user experience is information. Applications that present information in an intuitive manner have well-designed information structures behind the scenes. That is why they are useful and intuitive.
We continued to discuss this and the problem became clearer to me. When developing an application – whatever the application, a web site, document management system, intranet, ecommerce application, etc. – a business analyst goes about having conversations and discussing problems with users. From these discussions come a set of requirements and use cases. From the requirements, a set of additional artifacts and documentation are developed which is then handed off to the technical development team.
At some point, the “information architecture” or “IA”– the design of how the system works – is developed. Some of the “IA” is inherent in the software – there is core functionality that the vendor designed that cannot be changed. The rest is configurable and dictated by requirements and specific needs of the business. This is typically based on input from the business analyst. However, sometimes an Information Architect – a different kind of specialist – is needed. The big question is - what are the boundaries of each role and when is more than one role required?
A Data Architect, a Taxonomist and an Information Architect Walk into a Bar…
This sounds like the beginning of a good joke and I would love to hear a punch line if you can come up with one. Meanwhile, we'll just stick to the facts. Each of these roles is slightly different:
They each have a perspective on making information more usable and valuable. They each have a role in making information more findable. And they each leverage the approaches and principles of the other. There is no developing of a taxonomy without considering the user. One cannot consider IA without data architecture constructs. Data architects need to understand the purpose of the application which is to solve a business problem which means understanding the user perspective.
What we have found in our work is that components are sometimes considered in a vacuum. For example, we have seen taxonomies developed “as a standard” or “to be the source of truth” without reference to the user or application. Ideally, the Information Architect connects the dots, using techniques to capture and translate user needs into the design elements that consider the larger enterprise information ecosystem while meeting the immediate needs of the business.
One valuable approach is to describe the “day in the life” of a user and then deconstruct that scenario into component tasks. At each step of a task, needed information is identified and then structured so it can be accessed by the user as they go about their work.
Take a look at "Improving the Digital Experience: 6 Steps to Create a High-Fidelity Journey Map" for an in depth look at the use of user journeys.
One way to explain the concept of information architecture by looking at a physical analogy – building a house. In the case of a large corporate environment, however, the house analogy may not be sufficient. An enterprise is more like a small city or a large planned usage development. It becomes even more important to develop the master plan and then carve out a smaller development phase to build. The master plan provides the longer term blueprints that allow for controlled and orderly development. Not the wild west of unplanned development.
The physical metaphor makes sense in many ways. An information architect needs to look at the correct level of detail and the correct scale and scope of development. In the physical world, a master planner might take on one level of design, a chief architect another level. Specialists in particular areas (like electrical systems or heating ventilating and air conditioning) would add levels of detail and design expertise for subsystems. This comes back to the original question of when to use a specialist and when to subsume the design responsibility into another role. This is less of a question of role and more a question of skill, approach and experience, as well as project scope and ultimate business purpose of the solution.
There are many data architects with knowledge of taxonomy development and information architects that understand database architecture, etc. In each area, particular techniques are required in order to validate the outcome. Developing highly usable, integrated information environments requires a focus on methods which iteratively validate design decisions. Regardless of project size, information systems need designers that attend to all aspects of data and information, from a larger semantic architecture perspective. Even smaller projects can benefit from standard reference architectures that guide rapid/agile development.
Experience is the best indicator of knowledge and skill – make sure that your design resource can demonstrate specific projects that are similar to your own and leverage that experience and knowledge. What is different today is the technology has greater capabilities and flexibility. Your organization should not have insurmountable problems with information management.
Problems with information management are problems of content organization and content relationships and can be managed and addressed through application of well tested and proven methodologies.
Design the IA intentionally and then design the supporting processes and governance that leverage information as the fundamental enterprise asset that it is. All value is based on information. The organization does not exist or function without information. The enterprise IS information.
Ready to start organizing your enterprise content, customer data, product information, and/or organizational knowledge? We're here to help. Give us a shout!