In January, Nathaniel Davis wrote an article on UXMatters titled “Call Yourself a Practitioner? Prove It.” In the article, he challenged us to improve the rigor of our information architecture practice. This website has a blog post about Davis’ practice, “Information Architecture Practice Framework.”
Last night at the Vancouver IA Meetup, we discussed the section “Practice is About Behavior” from the Call Yourself a Practitioner article. It was an interesting discussion: since I run the group and introduced the discussion, I thought the conversation would be more directed. I thought the conversation would lean towards “what I do and what I want to do and what I have a challenge doing as an information architect.”
First, let me state each of Davis’ practices, then I can tell you how our talk developed. Where applicable, I will review what I do, what I want to do, and what I have a challenge doing. (Note: You could also expand his article to user experience and interaction design. In this article, we’ll look at information architecture.)
Davis lists these items under the section “Insight 2: Practice Is About Behavior.”
Probe for new knowledge and opportunities.
This is probably the one behavior of practice that most reflects a mindset that encourages practitioners never to rest on their laurels. Your intention should be to explore something new.
When probing for new knowledge, most of the people in my group last night stated that they tended to look for new knowledge when they had a problem to solve. If they were in a project and had a situation, they would look for information about that specific situation. Davis talks about being on a project and finding a specific aspect to explore in the project. Problem solving is a great way to direct one’s inquiry.
However, I don’t think problem solving is the only way one can probe for new knowledge and opportunities. I find that my practice falls into four general areas: facilitation, user research and business analysis, information architecture, and content strategy. While I can problem solve in these areas, looking for new knowledge that I can apply to a project can also be helpful. This involves learning something new and thinking, “How can this be applied to make my work more effective?” One practitioner last night said that she used to learn a lot of new stuff, when she had time, and try to apply it in some way, but now she just does problem solving. It’s unfortunate that she lost this innovative zeal, though problem solving can provide its own type of innovation and reward.
Discover new insights through the measurement and research of known activity.
Practitioners seek insights into their own work as much as they take an interest in the revelations they can find in the work of others. Practitioners explore ways of analyzing the work theyâ€™ve done to learn as much as possible about their solutions as they persist over time.
Last night, the general feeling in my group was that, as a consultant, it was difficult to measure and research known activity. As a consultant, one works on a project, reaches a certain stopping point, then the involvement in the project comes to a screeching halt. Otherwise, there may be some work in the implementation phase, but not that much. I agree that in consulting, it can be difficult to get money for user testing and it’s really hard to see one’s design implemented. While we all want those great consulting projects, in my experience and from what I’ve heard from others, measurement and insights from those measurements aren’t top priority.
However, to grow as a practitioner, the point is to discover new insights through measurement as well as gain new insights through research of known activity. So, we need to come up with ways to measure our work. One person last night suggested that we take customer satisfaction as a measurement. Not the end user, but the client for whom we’re building the product. If that client is happy with our work, then we’ve done a good job. In researching known activity, this could include looking at examples of others’ work as well as reading the research of others in the ASIS&T Journal (paid with membership) and the Journal of IA (free). There is also the ASIS&T Bulletin, which has some interesting research for the practitioner.
Document your discoveries.
Even in the most volatile work environment, practitioners can find a moment to capture their experienceâ€”whether formally or informally. Your intent should be to make the documentation of your discoveries actionableâ€”whether you capture them during or after a project.
For documenting discoveries, we discussed how difficult it is to document discoveries. We rarely realize all the knowledge we have in our head so we forget to translate this into documentation. When we go back months later to look at our deliverables, we can’t remember the choices we made. It’s important to understand that our clients don’t have insight into what is in our brain and they see it as we would see it six months after the fact. They don’t know what’s going on unless we annotate, create functional specs, create user stories.
For professional development, it’s important to document our discoveries. For example, when I first started as an information architect, I did a lot of informational interviews. I was a keener! I kept all the notes from those interviews and just found them the other day and thought to myself, “Man! I’ve done a LOT of professional development. I’ve done a lot of work to become an IA.” Some days, when I don’t feel like I’m doing enough, I’m going to open those notes and see how hard I’ve worked.
Refine existing knowledge and gain consensus.
Whether you gain your insights through the proactive probing or vetting of existing methods or artifacts, you should constructively assess the necessary changes to an existing discipline and view their realization as improvements.
The discussion last night didn’t concentrate on this point very much, or, if it did, it was combined with Share Knowledge (below). In vetting existing methods and artifacts, we all have reviews of our deliverables and ideas with others. We present what we have, get feedback, and improve.
My concern in this feedback loop is that what we are recommending isn’t always based on best practice but is unduly influenced by time, budget, and lack of user research. I absolutely realize that projects are always constrained by time, budget, and lack of research. However, one needs to realize what the best practices are and how what is currently being done does or does not fit into those best practices. With current feedback loops, I fear that best practices are not discussed given the pressures of time, budget, and lack of research. When we discuss ideas, deliverables, and designs, it is important to talk about what is the best practice and how it is being applied to the current situation. I know this is something I can improve on in my work.
Practitioners share their discipline with those in their close professional circle, as well as with broader audiences.
Naturally, we would expect reading books, websites, going to networking events, watching webinars, and talking to practitioners to fall into this category. One suggestion for tracking shared knowledge was to find some websites you like, such as UX Matters or UX Mag or A List Apart, and follow the articles on those sites.
The fear I expressed in “Refine existing knowledge and gain consensus” can be best countered by sharing knowledge between practitioners. If you work in an office, these can be lunch-n-learns, emails to share articles, talking about best practices over beers after work. If you work alone, it can be asking questions and looking for answers, meeting for coffee with others. It can involve mentorship.
Validate best practices by putting them to the test.
Practitioners understand that the validation of their insights requires testing. This final stage of a practice methodology completes the cycle and gives it the recommended rigor of a sound scientific method.
We didn’t talk much about this one at the IA Meetup, but one can validate one’s ideas by talking about them with others, by using them on a project and seeing what reaction one gets, by doing user testing. It does give a way for practitioners to validate what’s going on in their heads: does anyone agree with me? does my opinion hold professional value?
One final sentiment from last night’s discussion is how difficult it can be to create the time for this practice. At times, I have more free time than others, but it would be useful if I could create a methodical way to capture insights from projects. It could help me recognize where I’m doing well, what I need to improve, ideas I need to discuss with other practitioners. One way to do this could be to simply write up a project description once the project is done. In the description, we can include what our role was, what the client wanted, who the stakeholders were, some challenges, some rewards, and some outcomes.
I’ve done something like this on the Portfolio pages on this site. It’s important to realize that not all work is rewarding or successful. But we can learn from it to continue to improve our practice and validate our best practices.