UX+IA workshop: Toronto, June 2008

In the better-late-than-never category, let me tell you about something I did last summer. In June, we took a family vacation to Toronto: while there, I did a TorCHI talk, and helped lead a "hands-on" workshop about information architecture. It is that workshop that I never got around to mentioning here.

The original TorCHI call for participation gives a good overview of what we set out to do. Paul McInerney, my co-collaborator who talked me into doing this and did at least as much work as I did, if not more, came up with this recap of the topics we actually covered:

• Site sections: When to use, types, navigation design within and between site sections. Case study: Large IT vendors, specifically ibm.com.
• Role based IA: Defining suitable roles, designing the top level categories and navigation based on the roles, if and when to use a role-based approach. Case study: City government sites, including Toronto and others that have contrasting approaches.
• Wireframes: Challenges and best practices using wireframes, such as fidelity, ownership, expectations, tools, Agile methods. Case study: Examples provided by participants.
• Putting it all together: A holistic discussion of web site issues, including those covered in the prior sessions. Case study: Transit authority web site.

We divided the day up into 1.5 hour sessions, with breaks and a nice, long lunch. So it made for an intense but very rewarding day.

Some of the key aspects of this workshop (that I think made it better than whatever might be considered the "usual"):

• Making it activity-based, not lecture-based. Learning is more fun when you are doing it, not just listening to it. I have to admit that I started out too lecture-y at the beginning of the workshop day, but by the end, the participants were "leading by doing" and I was just sitting back and advising more.
• Tackling some of the thornier issues in information architecture, like task-based and role-based organizational schemes. I know, "role-based IA does not work" is the surface-level response, but we wanted to dig deeper to really understand why it does not work - and perhaps, even, discover some situations when it does.
• Adjusting the topics based on what the attendees wanted to talk about. "Wireframes" was not something I had in mind initially, but each participant submitted a list of "burning issues," we voted and wireframes came up to the top. (Note: Chapter 10 of Communicating Design was required reading for this topic.)
• We had experienced people attend, and capped it at about 10. I love teaching the basics to newcomers, but this was about "doing advanced IA" with peers in a close-knit setting. I am sure the participants learned more from each other than they learned from me.
• Using common, local scenarios to "make it real." We were in Toronto, so we gravitated towards Toronto-area local government and transit authority examples.
• Preparing each section in detail, with "learning goals," "preparation materials" (aka "homework to do before the workshop") and "exercises." It was a lot of work to prepare, and it took some commitment from the participants. We did not always stick to the master plan, but it was good to map out the day in gory detail so that we could decide as a group when the flow of the day was pushing us in a better direction.
• A "putting it all together" session at the end of the day. We debated whether this would work, or whether we should just have a 4th deep topic. This was my favorite part: I did see people incorporating the sub-site, task and role IA issues from earlier in the day into the holistic user experience session at the end.

I really enjoyed it, and the feedback I got from the participants indicated they liked it too. It was worth their time and money, it seems. What prompted me to write this summary is that Paul/TorCHI are going to try it again. Check out the UX Irregulars post for some initial information.

If you are an IA in the Toronto area, I definitely encourage you to sign up to get more information about the 2009 version. While I am glad I did it last year, I am more glad to give someone else a chance to lead it this year (too darn busy). I think we showed that the basic idea of "a hands-on workshop for experienced practitioners to tackle deep problems" is sound. Now someone else can work on perfecting it.