Soft Skills for Information Architecture
In: Columns > IAnything Goes
Published on September 24, 2003
While much of one’s success or failure depends on the skills specific to information architecture—like diagramming, documenting, organizing—an even greater indicator is soft skills: dealing with conflict, negotiating, and communicating. These soft skills are important in any profession or job role, but are of high importance in information architecture, which requires applying them in sometimes unconventional ways.
For people looking to transition from their present role to take on information architecture duties, or for those who currently have these duties and would like to continue to grow and improve, an excellent approach to the softer side of IA is to build on a solid foundation of IA principles, techniques, and skills. Applying the soft skills correctly will help you organizationally and politically while you are actually applying the skills specific to information architecture.
Know how to win arguments, but know when to give in
As an information architect, you will occasionally need to put your foot down. A large part of the IA role is convincing others that your recommendations are sound and should be followed, or persuading others that IA is important and you should be allowed to perform your duties. Information architects need to convince and persuade on a daily basis, and knowing how to do this is a key success factor.
It is just as important, however, to know when to give in. Too often, valuable energy is wasted trying to implement a recommended design or add additional IA tasks. Not only does this cause frustration and waste time, but it can undermine what needs to be a solid, honest relationship with clients, developers and teammates. There will be times when, like it or not, you will not get your way. To paraphrase from the old axiom:
Grant me the strength to improve the features that I can
Accept the features that I cannot
And give me the wisdom to know the difference
If ever there was a guiding mantra for information architecture, this is it.
Learn to make do with what you have
In case you hadn’t already noticed, life is not fair, and neither is information architecture. It would be great if several months were available for usability testing, or if the Purchasing department would approve that new version of the software that all your IA friends say you really need to have, or if the project team would let you do some wireframes before they jump straight from project plan to development.
Unfortunately, it seems like IAs have to deal with things like this more often than other roles (though others surely would disagree). Success as an IA involves creativity and resourcefulness. Not only is it knowing when to give in, as explained above, but it’s learning to make the best of the situation and work within the constraints that you are given.
On a practical level, that means not getting too attached to a specific process, or format, or piece of software. Your next client or employer may function totally differently and utilize different methods or products to get the work done. It might be easier or quicker initially if you could work the way you’re used to, but good information architects adapt and learn new approaches. And who knows—it might actually be a little bit better than the way you were doing it before!
Keep everyone happy
Information architects often act as the middlemen, interfacing with everyone from middle or upper management to marketing to development to IT. Each group requires something from IA, and IA requires something from each group. The key to a successful working relationship is to keep everyone happy, which means:
Not treating other groups as adversaries. When the relationship with another group or individual turns from being friendly and complementary to confrontational, it does neither side any good. Everyone should be working towards a similar high-level goal, and the individual responsibilities shouldn’t overshadow that. Understand their role and respect their focus in that area, just as you would like them to do in return.
Not confusing client-centered for user-centered. Keeping people happy doesn’t mean following direct orders, nor does it mean going out of the way to please them if it displeases you. Again, focus on their individual or group goals and objectives, and help them work towards that. Sometimes a little tough love may be needed but, ultimately, respect will be earned by helping them while at the same time acting responsibly and knowing your boundaries.
Realizing that there are other things outside of IA that affect someone’s happiness. Information architects are sometimes analysts, therapists, designers, or negotiators who can get involved in areas where they may or may not necessarily belong. By using these skills creatively, a better working relationship can be established. For example, a developer may be unusually combative when presented with a new proposed feature that was identified during user research. This resistance may not have anything to do with the backend work needed to implement it, but because the business owner denied the developer’s request for additional software that would make it easier to develop said feature. Presenting the developer’s case to the business owner and understanding his/her reasons for denying the request could help, especially since information architects are often uniquely suited to understand both the technology and business context involved. It could help clear the air and get everyone focused on a proper solution that would allow the feature to be implemented.
Keeping everyone happy not only makes it easier to focus on the specific information architecture tasks, but it obviously builds the foundation for a better long-term working relationship, continually reminds everyone of the importance of information architecture, helps ensure job security or client work, and reduces stress.
Document, document, document
Information architecture is what it is because of its deliverables. Site maps, content inventories, wireframes, scenarios, conceptual models—a large part of what we do is defined by how we document ideas and information.
In addition to creating documents that are presented to clients or team members, documenting everything else that goes on in an information architect’s work life can be beneficial as well. Having a record of why certain decisions were made, how issues were resolved, when certain events happened, and who was involved can be invaluable when prior actions are questioned later on in the process. Similar issues may come up again, on the same or different projects, and being able to reference prior similarities is always useful. Research may be able to be reused in other situations or referenced for future work, and having it documented, rather than relying on memories of a discussion, saves considerable time and energy.
Documenting can be as simple as following up a phone conversation with a written summary of your understanding of the discussion and decisions that were reached, or as formal as a full document that is passed on and signed off at various stages. However it is implemented, having a written record of actions, decisions, recommendations, and the reasons behind them can make the life of an information architect much easier and allow for better, more effective uses of time.
Embrace the librarian within you
Since the current practice of information architecture was largely influenced by library science, this should come as no surprise. Embracing the librarian within you, however, is not so much about using librarian skills in job duties as it is about developing a system for storing and retrieving useful information.
There are countless online resources for information architecture and related disciplines. Thousands of articles, research papers, interviews, case studies and similar materials exist, and information architects need to access this information on a regular basis. Developing a system for finding the good resources—like, ahem, this column—and being able to find them when they are needed at a later date is extremely helpful. It may be possible to rely on memory or search engines, but those tools may be unreliable at a later date.
Some information architects rely on huge categorizations of bookmarks, others on wikis or blogs, and others on downloaded copies of useful resources. Again, the method is irrelevant, but the need to embrace the librarian within you, and develop a strategy to find and use relevant information, has never been more apparent as the amount of information available grows at an exponential rate.
Let other people do the work for you
As the information architecture community expands and more individuals get involved with the discipline in some capacity, it becomes clear that this growing number of colleagues can be of great value. A design question or political hurdle that comes up may have been faced by another information architect in another company, and information about their experience is certainly valuable to obtain. Opinions on a new technology or method can be solicited from those who have first-hand knowledge, saving considerable time and energy needed if the research were to be started again from scratch. Though you may have embraced the librarian within you, certain articles, research summaries, or case studies may have fallen through the cracks, and other information architects may help where searching has failed.
There is also the additional benefit of being able to add often-needed clout to a recommendation by referencing successes (or failures) from other companies or projects. The combination of publicly available information and personal anecdotes and experiences may be useful in the decision-making process.
The softer side of IA
This admittedly incomplete look at the soft skills helpful to information architects can hopefully shed light on “those other things” that people entering the field or looking to advance need to know. While much attention is paid to skills specific to information architecture, and deservedly so, these soft skills can make the difference between a competent professional and a truly effective and successful practitioner.
Jeff Lash is a User Experience Designer in the Health Sciences division of Elsevier. He is a co-founder and Advisory Board member of the Asilomar Institute for Information Architecture (AIfIA) and has also written articles and tutorials for Boxes and Arrows and WebWord. His personal website is jefflash.com.