Peter Boersma has recently been elected on the IAI Board of Directors. He is well known in the IA and UX Scene and though he is very busy, he was so kind to answer the following questions.
Interview auf Deutsch
1. Peter, you are Senior Interaction Designer at the Dutch full-service internet agency Info.nl. You have been working in the user experience (UX) field since 1995, you speak at UX conferences and are hosting the infamous Amsterdam UX Cocktail Hours. When you look back, what were the most valuable lessons you have learned practicing UXD and IA?
I have two important lessons:
Lesson 1: School does not prepare you for client work. At my university I followed 60 classes and only 2 helped me function in a team and only 1 of those involved reading client requirements. In the real world of projects for clients, I have to use skills that I never learned in school. Workshop moderating skills are the most important ones, and I wish those would be taught in school. As a designer you have to be able to ask the right questions about requirements, ask what design direction would be right, present designs, defend decisions, criticize other solutions, negotiate compromises, summarize discussions, distribute tasks, and much, much more.
Lesson 2: Everyone benefits from a review. I used the review process as an example of a process pattern in my presentation at EuroIA 2007 partly because I think reviews, of any kind, are very important. There are many steps that go with a full-blown review: prepare the review, invite reviewers, distribute the deliverable, perform the project review, technical review, team review or client review, distribute review-notes and re-distribute the deliverable. But the most important aspect is that the maker of a deliverable hears what someone else sees in his or her work, what is missing or unclear and hopefully what could be done about it. And the second most important aspect is that someone else (but hopefully more) in the team knows what you have done and what the status is. I have learned that both aspects are crucial to deliver good work consistently.
2. UX as I understand it, is related to the field of ergonomics (which emerged as a discipline in the 19th century). I think Information Architecture on the other hand leans more toward the form follows function principle Louis Sullivan was talking about. How would you describe the relation between UX and IA?
My definition of ergonomics is that a designer creates or adapts an artefact (based on knowledge about humans) so that a human user doesn't have to adapt him/herself. This can be applied to anything from heavy machinery to information workspaces. When I combined computer science with ergonomics into information ergonomics, I studied the human body and the human mind, as well as how computer technology can help people and organizations become better users and suppliers of information. Information Architects, especially those who design information structures for end users, can become better IAs when they empathize with their users and know about their possibilities and limitations. When they consider all aspects that deal with usage of the information they structure, they consider humans and their needs, wants, quirks and oddities.
User Experience practitioners define situations where end users can have experiences. At the highest level of design, the designer needs to know all kinds of things about the users: what are their goals and expectations and why, what have they done elsewhere with the brand, who do they talk to and what words do they use,etcetera . How users use the information that a company supplies is just part of the problem but it is a good idea to have someone with an ergonomics background on the user experience team to focus on those aspects.
3. Eric Reiss and you framed the T-Model of Information Architecture in 2004, which later became the Shoulder Model. Could you explain a little bit what that model is all about and what is the status quo right now?
In 2004, Eric had just become part of the leadership team of the Information Architecture Institute (then still called Aifia) and when we had dinner after a Cocktail Hour he wanted to know what I thought the organization should do for its members. In the process I started sketching my ideas of what IA was all about and how I thought it related to other fields. That sketch, on the back of a beermat, later became the T-model for User Experience.
The model basically describes how each field under the UX umbrella has its own specialities, its "deep" subjects that no-one else knows much about. In IA for example, those are search, metadata and controlled vocabularies (which is why our field owes so much to librarians). In addition to those deep subjects, each field has subjects that can also be found in one or more other fields. Again, for IA, those could be content, navigation and labeling (which we share with people like copywriters, marketing communication experts, and interaction designers). And, as I later realized, there's a third layer that deals with management of the practitioners, for example subjects like Return On Investment, IA processes, and the impact of IAs on an organization.
Every now and then I refer to the model in online discussions, as do others. And I have presented it as a poster at Euro IA in Brussels. But that's about it; I think it is finished :-)
4. In your experience, what are the most approved IA deliverables and methods? Could you please sketch a typical basic IA workflow?
"most approved"? As in: approved by clients? In that case: the final design! :-)
But I assume you mean the best-known deliverables, or those considered by designers as standard IA deliverables, and in that case I am afraid it is the sitemap. I say afraid because a sitemap it often produced too early in the process and in a way that determines what types of pages will be created and what the exact main navigation will be. I would much rather wait until all functionality is designed (probably by people with interaction design as their specialty) and all user flows are designed. Then designers can determine whatfunctionality fits best together on what types of pages, and how these can best be connected with types of navigation.
What I'd love to see IAs deliver in a project are: user experience requirements, content requirements, a high-level content inventory, a functionality inventory (all compiled through research and analysis workshops), the IA elements of the system's concept including content and navigation principles (created with the UX team), a new content inventory, wireframes, the navigation design and rules for user flows, and finally a sitemap (all presented to and reviewed with the client). Oh, and IAs should help with the preparations and execution of a usability test on a paper prototype and/or an early semi-functional prototype.
5. Do you find it hard to sell IA services to clients that are more focused on their business objectives than on end user needs? What is a good argument for integrating Information Architecture in the overall website-building process?
In initial meetings with client representatives I always tell them that I will defend the rights of the user, that my mind always goes to the users. It is okay for them to have their business in mind; that is their job and I will ask them all about it. But I will always translate it to what users need from the company. They always seem receptive to that idea, as long as they don't have to do it themselves :-)
As for integrating IA in the rest of the design process: I sometimes say that the definition of IA is to help people find what they need, get there, and get away from there; what happens in between is the domain of interaction designers. And of course the whole idea of a user experience is that all elements work together, from the business model, via communication design, visual design, interaction design, copywriting, IA, software design, training, packaging, branding, and the list goes on!
There are very, very few projects where an IA can do all of the work; we have to work together with other user experience practitioners!