Although the focus of my career has remained largely consistent, my job title has changed and evolved. This (I believe) is largely to reflect the needs of the host business. Often the business will place value on one particular nuance of my role. For example a 'usability engineer' will be expected to write reports based on user feedback of a given prototype. This might be necessary because historically, the user interface is produced and executed by your developers yet they don't have the time to evaluated their output. The term 'engineer' also reflects that the business has an engineering bias.
Similarly, a 'creative director' might work amongst a number of design focused roles such as interaction designers or visual designer. This perhaps reflects a businesses design focus. Its more likely to be a customer facing brand and the user interface could be developed via an off-shore team. Hence the need to document the intent of the business and user as accurately as possible.
More recently, I have had an increasing exposure to the job title 'information architect'. I suspect some of you will have heard about this role. Some of you may feel that you are doing that role as part of your current job title and others maybe conducting elements of this role without realising.
The information architect role is nothing new. Indeed this practice has been around for hundreds, if not thousands of years. Perhaps the classic example project being Melvil Dewey's 'Dewey Decimal' system which was conceived in 1873 in order to organise vast libraries of books. The system was widely adopted throughout the world and is used to the present day. I have no doubt that you will have encountered the Dewey system at some point in your studies.
Once you appreciate the Dewey system you will know that books are organised by theme and you will also know that themes are normally arranged in collections on specific shelves. This means that when you are looking for books on African Arts, you are likely to see other books which are also related to the same topic. This increases the chance of what we call serendipitous discovery. In other words, the chances of finding an answer from an unexpected source is greatly increased because of the way the books are organised.
The obvious value in having an information architect in your company is to provide a system like this which organises the information your staff or users utilise on a daily basis. This system should be intuitive and understandable so that anyone can quickly complete their goals - reducing time, effort and therefore increasing profits. The system should also extensible so that it adapts to the growth of the business. Therefore, an information architect will require a good understanding of the business goals in order to establish a flexible and long lasting solution.
In the O'Reilly book on 'Information Architecture', Peter Morville and Louise Rosenfold outline seven reasons why 'why information architecture matters' to organisations:
- The cost of finding information
- The cost of not finding information
- The value of education
- The cost of construction
- The cost of maintenance
- The cost of training
- The value of a brand
However, in recent years I feel that the term information architect has been overused and perhaps watered down. Why do I believe this?
Firstly, I often hear of organisations with more than one information architect. Indeed sometimes I hear of organisations with teams of information architects. Imagine if you will, a team of five information architects working on the Dewey system. How do you know that each of those architects will place African Art books in the same group. Indeed, how do would you know that every information architect will name that label 'African Art'. One might label it 'World Arts', 'South African Arts' or 'African Arts & Crafts'? In short, it is the definition of the system which is key and having more than one person working on a system although not entirely impossible, progress will be painfully slow. It is because of this I do not believe any company with more than one information architect is actually providing the true service or impact of an information architect.
My second reason, is around the question of which organisations require the skill of an information architect.
Think about organisations who deal with large numbers of disparate items. Amazon sells numerous types of products, each classified under very different themes or groups. If the items did not appear under the expected labels, the user would not find the product and the retailer would forego a sale.
Google's search engine uses algorithms which classify and label search terms. If the themes were not recognised the search results would be entirely irrelevant to the user. They would not click the link and Google would not generate revenue.
Utility companies (such as Gas and Electric suppliers) with thousands upon thousands of customers will need databases to record their customers. The marketing department may wish to use this information to promotes a new tariff to customers who have been on a specific tariff for for more than two years (i.e. loyal customers).
Its the way this database is structured and accessed which will allow its internal staff to communicate with this audience in an efficient manor.
So there you have three examples of organisations who do require the skills of an information architect. They all manage large amount of disparate data with one or more key users (internal and/or external). They require an understandable system in order to make sense of it.
But here's my concern. Many of the companies using information architects do not have demanding set of deep and disparate data. More so, many of the companies I see using information architects are actually using them as interaction designers.
Graphic design is NOT information architecture
Software development is NOT information architecture
Usability engineering is NOT information architecture
A quote from 'Information Architecture' by Peter Morville and Louise Rosenfold
Some organisations are using information architects to solve high level concepts via the user interface - in other words by producing wireframes for a website and stumbling across the labelling and taxonomies as they proceed. Designing page by page and then going back to edit each page as they learn more about the complexities of the system.
There are numerous problems with this approach. Firstly you only see the parts of the architecture which are visible to the use in any given state (The 'iceberg' issue). Secondly, you won't be able to build themes or access all dependancies. Thirdly, it is an inefficient way of working.
To further the quote above, I strongly believe that interaction design is NOT information architecture. Information architecture has an entirely different focus to interaction design plus you won't necessarily need a dedicated information architect in order to conduct the work. You may already have someone ideally placed in your organisation who can conduct this role with ease. What really matters is that they know the business and the given audience inside out.
So if 'IA's don't really need to produce wireframes, how do information architects conduct their work? In order to establish understandable labels, themes and hierarchies a true information architect will use user research methodologies such as card sorting or website analytics to establish behavioural insight of the intended audience. They will ultimately produce heat maps and matrixes of data perhaps using spreadsheet applications such as excel or numbers. An information architect will rarely touch a wire-framing or prototyping tool, unless they are attempting to present and promote high level concepts (i.e. via Venn diagrams etc).
For organisations who deal with disparate data, information architecture can be key to your growth and success and whether your business employs an information architect or not, its worth reviewing your methodologies or your job specs to establish: (A) could my business be more profitable with more structured data system and (B) what skills/insight do I have or need to create an appropriate solution.