Teaching Information Architecture to the Design Student

I teach an Information Architecture class for undergraduate design students at ”I knew that I was not going to turn a junior-year graphic design student into an information architect with only six credits of course work.“Pratt Institute. Teaching IA to students of design is not unlike working with practitioners of design. A good designer will usually have an instinctual understanding of IA, but without deliberate attention given to IA, it sometimes gets ignored. In order to talk about IA, it needs to be made relevant to the designer. IA issues should not be addressed by suggesting visual solutions but instead, the designer should be shown where the design is weak because of poor Information Architecture.

Prior to teaching, I was a student at Pratt Institute. At the start of my senior year, the ‹img› tag was brand new, Netscape Navigator was just unleashed upon the world, and a professor of mine handed me a copy of Edward Tufte’s “Envisioning Information.” It would take years for me to begin to understand how the first two events would affect my life, but Tufte’s book immediately began to shape me as a designer.

My senior year was spent doing nothing but information design —maps, diagrams, interactive information kiosks. At the time few faculty members understood my desire to work on these projects, but many years later I was asked to draft a related course. The school needed to prepare students for the large number of ‘Information Architecture’ jobs that had started to flow into career services.

The class
Approaching the class realistically, I knew that I was not going to turn a junior-year graphic design student into an information architect with only six credits of course work. I also doubted that there would be 12 students every year that wanted to digest the library science and human cognition knowledge in order to become an IA. Instead I decided that what the design student needed was a design course that stressed usability, human factors, and clarity, instead of the typical branding and interpretation problems they usually encounter in their other design classes. This class would be very similar to the work I did in my senior year.

Such a class would give these students a good foundation if they ever chose to pursue IA or collaborated with an information architect in the workplace.

Studio classes at Pratt all have a similar structure, and usually meet once a week for a three-hour session. An assignment is given, and in the subsequent weeks, sketches and final projects are reviewed. The class critiques are designed to help the students learn from each other and resolve their design solutions. Class discussions are encouraged. My class follows the same structure. The difference being that the projects assigned and the critiques given put the usability of the students’ solutions above than the visual aesthetics or composition.

The class is also broken into two semesters. The first half of the year consists of short projects designed to teach specific information design concepts, and the second half deals with one or two large-scale projects where students have the chance to wrestle with multiple problems. So far I have taught two classes, both of which were the first half of the course, the Information Architecture I class.

Going from theory to practice
I always approach teaching IA to the designers in a very abstract way instead of giving specific rules and solutions. I want the students to understand why and how things work so their creativity can be guided by knowledge rather than having their designs be burdened by arbitrary rules. Because of this approach I have found that communicating academic IA topics, like labeling systems, wayfinding, and interface heuristics is much more successful if I present them during a class critique, rather than during a pre-scripted lecture. The students are more likely to pay attention because of the very clear relevance to the work they are doing, and a tangible problem helps them understand the abstract concepts.

In one of my first classes after assigning a project about organizing photos, I gave a lecture on classification systems. It was less successful than I had hoped because it was structured and pre-scripted to some extent, and I found that the lecture I had planned did not address a fair number of issues that I saw in my students’ work. In subsequent projects I wove this type of information into critiques, and the class was more receptive.

Classifying and grouping is such a basic skill; I thought that this assignment would be finished in a week or two, and we would move on to something more interesting. This assignment ended up dragging on for five weeks, and the students got bored and frustrated. The problem was that there was no end purpose for organizing the photos-no context. The assignment became an abstract exercise with very little relevance. The students could have come up with a perfectly reasoned organization scheme, but without knowledge of how the photos would be used, there was no way to evaluate their work.

In short, design students (and designers) will more often produce wonderfully functional pieces of design if they understand the human interaction problems they are being asked to solve.

Realizing my errors, the next assignments I gave worked much better. I gave very clear problems that needed to be solved. I gave restrictions and requirements that focused the students’ attention on the problems that I wanted them to think about. I removed formalized lectures from my lesson plans.

The follow-up assignment involved doing on-air graphics for an Olympic sport. I brought in screen shots and video clips of what NBC had done for the 2002 Winter Games. I personally thought NBC had done a poor job, and pre-discussion of the NBC examples allowed the class to get past the aesthetics and focus on the functionality of the design.

The students were asked to pick a sport and watch it on TV (the Olympics were on for another two weeks after I gave the assignment). During the broadcast they were to write down what information they wanted to know about the game, if the on air graphics (or the announcer) were supplying them with the information they needed, and how well that information was presented.

Armed with a user’s perspective and a clear objective, the solutions the students came up with were quite good. In addition, we did all of the class critiques with the designs displayed on a television, and the class began to understand how to edit their designs so they would read on low-resolution mediums. This skill also helped them in later print-based assignments.

Other projects that I assigned included: designing a kiosk for ordering commuter train tickets, making parking and trash collection street signs, and visual directions for making a food item. During class sessions I would ask students to use the designs made by their classmates. This form of user testing was easy and beneficial.

What about websites?
I have purposely avoided directly giving assignments that deal with websites. It is not because I think they are poor design problems. The issue is, websites have too many problems that need to be thought about and solved, a task that can be overwhelming. I also believe that many of the design issues that websites present can be taught using non-website projects.

Websites also bring with them the quagmire of technology. I want to teach a user-centered approach to design, and if my students also need to learn a new way of working (i.e., HTML, CSS, etc.) at the same time, I would spend a bulk of the class not teaching design. It is my opinion that the design issues I am teaching will help the student after they graduate, while any web technology I teach them will be incomplete (because it not the focus of the class) and several years out-of-date by the time they enter the workplace.

A solution might be assigning traditional IA deliverables like wireframes and flowcharts. I am concerned about having the students create these planning tools without seeing them as a finished product. This means there is no way for the student to evaluate, and learn from, their work in a more realistic context. It could be like going through the motions of organizing photographs.

I also have mixed feelings about having students do static Photoshop mock-ups of websites. This exercise places too much focus on the aesthetics, and doesn’t give them any experience in designing interaction. Photoshop mock-ups also don’t allow students to solve the design issues of designing for sites where most of the content resides in databases, and the content is created after the design is completed.

These are some of the issues I plan on teaching during the Information Architecture II class where assignments will allow the students to wrestle with interaction and fluid data problems. The trick will be to not have the students overburdened with unfamiliar technology. Not every student will have taken an HTML course, and I would prefer not to make it a requirement.

Despite the challenge, a website will most likely be a project in the second semester. I would be neglectful as an educator if I let students walk out of my class and into an interview for an IA position without a well-architected site in their portfolio.

See You in September…
I am looking forward to teaching again; former students have overwhelming said that my class was worthwhile and invaluable because it gave them a completely new way to think about design. Teaching students is not unlike working with professional designers, both require a fair amount of respect, effort, and patience. But, once a designer understands IA issues, their designs become successful on another level, and only good things can result from that.

James A. Spahr works as a designer and programmer for Designframe Incorporated. His design work has been showcased in Graphis Books and in ID Magazine. He teaches undergraduate Information Architecture and Graphic Design at Pratt Institute.