Elizabeth Boling teaches graduate students in Instructional Systems Technology at Indiana University.

Her area of expertise is visual design and the development/ production of instructional materials. From 1988-92 she worked at Apple Computer, managing several dozen graphic designers and animators in what was then the company’s User Education group; from 1983-88 she held a similar job at educational publisher Bibliogem, where she managed artists and programmers as well.

Ignition’s Amy Satran spent several years as an instructional designer in a different part of Apple’s User Education group, and secretly envied all the fun Boling’s group seemed to be having. They spoke about the topics covered here in August 1997.



Elizabeth: One of the things I’ve learned is that we can’t just teach a bunch of models. Models have their uses, but they tend to make people think that the development process is somehow linear -- until they’ve tried it.

A big part of our instructional approach is what we call “project-based learning.” We assign students to teams -- deliberately diverse teams -- and have them work through four actual projects from start to finish, doing all the work themselves along the way. They start with very small projects, where they have to produce maybe an hour’s worth of instruction. They experience the process as total chaos. And most of them find this really disturbing. Part of our job is to help them understand that some of the chaos is because they’re new, but some is because that’s just the way it is.

A very important thing we do is incorporate reflection into these projects. We have all the students go back and think about what happened and why -- this was realistic, that was a mistake. This is a critical part of their learning because these projects can be such a double-edged sword -- people can arrive just as easily at a misconception as they can at an insight. After they’ve gone through this reflection exercise on four projects, we hope they can start to see some patterns emerging.

The trick is to coach them at the moment of need, not to lecture them in advance. In that sense, the entire process is much more like managing people in a business setting than like teaching them in an academic setting.



AS: Here’s another balancing act question: How do you teach students to be creative and visionary, and at the same time to work successfully as part of a team?

EB: This is a tremendous challenge, and one of the biggest hurdles for every student in our program. It took me awhile to realize that part of the problem is language. “Designer” (in the sense we’re talking about here) does not mean “artist” -- though lots of people want to think it does. In our culture, “artist” translates into “self-expression” -- but the job of a designer is not to express him or herself, it’s to solve a problem. The interesting challenges of design are in the great-solutions aspect, the puzzle-solving aspect, the service aspect of helping the users of the product. A big part of teaching designers is helping them rethink their notion of what it means to be creative, and guiding them so they can identify their own sources of satisfaction in the design process.

I should say right now that it doesn’t always work. We get a few lone wolves who reject this way of thinking, resist team projects from day one, and then go out on their own to consult. In their heads they’ve got a model of how the instructional design process should work in a perfect world. They end up sneering at people who don’t use their methods, and fighting every step of the way, and the whole problem stems from the basic misconception that there’s only one right way to do what they do.

But with the students who are willing to stretch themselves, this is another coaching opportunity. About a quarter of our students already have professional experience in the working world. Interestingly, no matter where they come from, they don’t seem to have had a lot of successful team experiences. So we have to create an environment in which they can start to have these experiences and learn from them. Frankly, our success with this is limited by the habits of a lifetime -- educational systems both in the U.S. and elsewhere pay more attention to teamwork than they used to, but still not enough.

Here’s what happens: Our program is very competitive and selective, so our students are excellent, and they’re used to high achievement. The minute we put them in situations where their performance is linked to that of someone else, the disorientation and anxiety are extreme. Their own personal work strategies have always paid off well in the past, and naturally they’re very reluctant to give these up, or to try something new, but they have no choice. We’ve given them lots of autonomy, but in what they perceive as a very burdensome form, and they are really confused. A lot of them are terribly unhappy. It takes a long time for some of them to sort this out.

But this is inevitable. None of us are born knowing how to separate our feelings about teams from our feelings about people -- this has to be taught. Many people simply don’t like or trust their teammates. They are convinced that no one else is pulling their weight, takes the project seriously, has the skills or knowledge to do the job right.

Our job is to make it clear that design is a multifaceted, interdependent activity, and that teamwork is not optional, but it’s not necessarily painful either. The first step is to set up the expectation that your teammates are neither obstacles nor competitors, but collaborators. Your job is to help them by teaching them what you know, and learning in turn whatever they have to teach you. People need to learn how to talk to each other in teams -- it’s not the same way you talk to people when you’re all out for a pizza. You need to learn when and how to stall, to push, to facilitiate, to divert.


AS: How do you teach your students to build quality into what they do? How do you teach them to deal with the realities of time and money without compromising what’s important?

EB: First, we have to disabuse people of the idea that time + money = quality. “If we only had more time and more money, it would have been better.” Sorry, that’s not the way it works. We have to look instead at how to do the best possible job with whatever resources are available to create “quality sufficient unto the day.” It won’t be perfect, ever, so the trick is to learn how good is good enough.

On the teaching side, we deal with this “knowing what to do when” question constantly in the process of project-based learning and reflection. Here’s something that happens all the time: late in every project, people tend to be disappointed in the results of their work, which they blame on every imaginable thing -- the outdated software, the shortage of hardware, the tight schedule, their incompetent teammates, whatever. We debunk all this and go back to look at the quality of the decision-making from the beginning. We look at the whole chain of decisions and their consequences -- did you ignore this testing data? spend too much time on this minor component of the product? wait too long to start audio production? -- and help them see that this outcome was not the only one, and could have been better, all other things being equal.

Often, even when students understand that there can be more than one solution, they want to labor endlessly over the solution they’ve settled on. We have to remind them that this IS a solution, not a masterpiece, not a stand-in for the creative expression of their personalities. The solution needs to work for the audience, not for the students personally.

The difficulty here is that people -- not just students -- tend to assume that if perfection isn’t attainable, well then quality must not matter at all.


AS: Is this why there is so much bad interactive product design, and so much tolerance of it?

EB: Well, there’s badness that results from excess as well as badness that results from deficiency. In the world of educational products, people discovered very quickly that more glitz didn’t mean more learning. If products looked too slick, people assumed they were shallow, or that money was spent on the wrong things. But at the other end of the spectrum, instructional design has suffered for years from extreme visual deprivation, really ugly stuff. Simple visual solutions can be very effective, but creating “simple yet effective” anything is always harder than it looks, and very few people are good at it.

This goes all the way back to our educational system (again). When we look at a seven-year-old who can’t read, we panic. But when we look at a seven-year-old who has zero artistic sensibility, we not only don’t care, we don’t even recognize the problem. Without basic visual literacy, people have lost something that could have been a key component of their lifelong problem-solving arsenal. They can’t visualize things and it doesn’t even occur to them to try.

The received wisdom is that we design things for three reasons:

1.

It makes the material look more organized.

2.

It enhances the viewer’s enjoyment or engagement.

3.

It makes the work look more professional.

This is fine as far as it goes, but it isn’t enough. In a professional sense, in an interactive product design environment, we design because it’s a huge part of solving the problem we’re here to deal with in the first place. I’ve heard someone say, “It never occurred to me that the way it LOOKS would be information.”

Well, the way it looks IS information.



AS: What should this mean to, say, a manager in a big corporation who is trying to develop an interactive training product that needs to go up on the corporate intranet in six weeks?

EB: It means, think about balance. When all your plans are just verbal and analytical, and the visual manifestation doesn’t matter, whether you recognize it or not you have a visual literacy problem. And your project is going to be hindered by it.

Cross-disciplinary impoverishment is the real issue here. All expertise -- including that of your designers, visual thinkers, production people -- needs to be focused on the product from the very beginning. Everyone has to be invited to help solve the problem together, early, not just brought in at the supposedly “appropriate” moment.

In the corporate world this kind of cross-disciplinary teamwork is an incredible rarity, partly because not enough people have seen it work so they can understand the value of implementing it. In big organizations, people have a responsibility to make everything as “efficient” as they can, which usually means “codify this process and do it just the way we did it last time” and “don’t apply resources to a problem until they’re obviously needed.”

But if you’re doing something new, when is the need obvious? Usually after it’s too late.

Every corporation needs innovation and new solutions. Part of the cost of coming up with a new solution is that you work in this different way. People need to express what they’re doing both verbally and visually. Once people see a solution visualized, they realize that it’s not what they thought, or they can see ways to improve it, or they realize that they don’t like it. Making something visible is one of the best ways to control the outcome. You’ve externalized a representation that everyone can operate on. You can iron out the differences in what people might have been assuming.


AS: Think for a minute about the hardest design project you ever worked on. What made it so hard?

EB: Well. OK, two things: ignorance and inflexibility.

Ignorance is when the client or team doesn’t understand something incredibly basic, like the medium or the market they’re designing for, or the roles and responsibilities of the other people on the team.

Inflexibility is when people are too attached to one approach and aren’t able to alter it or try another one. Or they aren’t able to recognize the value of someone else’s expertise. Or they insist on the value of their own expertise but won’t share it in a useful way.


AS: You’ve taught a lot of students and managed a lot of employees. If you went back into the business world today to run an interactive design group, what kinds of people would you want to hire?

EB: I’m wary of people whose skills are too general, because often they’re not really useful anywhere. But if someone is deeply skilled in more than just one area, to me that indicates flexibility, receptiveness to expanding their view and their role. These people tend to be better problem-solvers and all-around resources than those who are devoted single-mindedly to one specialty. But some of the latter can be valuable too, in smaller numbers, for really focused tasks.

I’d want to work with people who have lots of strategies they can employ to solve problems. People who can make up a new method or learn a new tool if they need to. I’d also want realists. And people who aren’t easily discouraged. People who don’t see an obstacle as a reason to stop working. Everyone can learn these behaviors if they don’t come naturally, but they’re vital.

The best people I’ve ever had in my groups are the “natural educators.” Their tendency is to recognize knowledge and skill deficiencies in the team and react to them by sharing their expertise with peers, managers, and teammates. These people have all had the confidence that sharing what they know doesn’t somehow put them at a disadvantage. They’ve all had respect for other people and a good ability to size them up and present new information in ways that will be not only palatable but interesting, and convincing. They’ve all been willing to admit ignorance in the areas where they’re NOT experts, and get educated themselves. They’ve all recognized each other’s strengths and turned them into the kind of quality we were talking about earlier. These are the kinds of people I like to think I’m teaching now. Time will tell.




Elizabeth Boling:

E-mail:eboling@indiana.edu
Web work:http://www.indiana.edu/~iirg/index.html




© 1997-1999 Ignition, Inc. All rights reserved.