Interview with Robert R. Johnson
Usability Education in the Copper Country: Teaching Usable Software Design at Michigan Tech
Timothy Keirnan spent part of his recent vacation to the Keweenaw Peninsula of upper Michigan talking with Professor Robert R. Johnson, Chair of the Humanities Department at Michigan Technological University. In this interview, Dr. Johnson talks about a National Science Foundation project to teach user-centered design to software engineering undergraduates.
Interviewer: Timothy Keirnan
Guest: Robert R. Johnson
Tim: Bob, for starters tell me the history of this project. How did it come together? What was the goal?
Bob: Well, the history of the project was that I got to know a new professor in Computer Science – actually, in Software Engineering--named Charles “Chuck” Wallace. We played tennis together, actually, and there’s always conversation before and after the games. Anyway, one day he was talking to me about some of the problems with students he was having in his software engineering class where they actually create software products. And he started to explain that a lot of the students didn’t seem to make things that had any worth beyond their own interest; in other words, that didn’t have any use. So they thought they were making cool stuff but nobody could use it or even cared to use it. This is juniors and seniors we’re talking about.
So Chuck was talking about that and I talked with him about some of my background in usability and also a book I’d written called User-centered Technology. He got a copy of the book and he read it and he said “this stuff makes a lot of sense and I’d like to implement this in my classes.” So we talked about that some and then an opportunity came up with the National Science Foundation for an education-related computer science grant. We applied for it in a collaborative effort comprised of me, Chuck, and Ann Brady, who is a professor in the Department of Humanities at Michigan Tech. Between the three of us we started doing this project, which is to develop cases based upon actual situations of software development. Our goal is not just to give students a clean, nice case that they can then make something from; rather, it’s to give them a case that has all the complexities of contingency and time and deadlines and budget, and also—most importantly—the problems of users, usability , usefulness and what it means to design products that can fit within and deal with all these complexities.
Now, through the grant we’re developing cases that are used in Chuck’s junior and senior-level courses that will hopefully teach students more about stakeholders, users, usability, and all of that.
Tim: That sounds interesting. How did you get it started, then? Is it part of a class he’s already been teaching and he folds this into his curriculum?
Bob: Yes. In the software engineering concentration, a student can more or less major in computer science and there are two capstone courses for software design. These are mostly juniors and seniors we’re talking about. In the first course, they learn the principles of software design and some various techniques for designing software. In the second course, they actually design and make something, usually for a client.
Tim: So when you say “cases”, does that mean there are projects that the students have to do that involve a product that will have usefulness for others?
Bob: Actually, the way we are doing this is that it involves the students all the way through. We’re collecting information through ethnographic kinds of case study methods: interview, observation, survey, and some usability testing in the second course. That’s where the students are actually making something for a client.
For instance, one of the projects is making software that would control the mechanism of a boom—or winch—on a ship. A mechanical engineering faculty member had a company that wanted something developed and these students are working with some mechanical engineers and with some computer science students to develop software that will actually work this pretty complex mechanism.
What we are doing is studying and collecting a lot of narrative and a lot of stories and a lot of data about that particular project. Then we take that and we distillate into stories not unlike the Harvard business case model, which is where real-world scenarios are presented to students to solve problems or to learn about business practices. It’s similar to that, but we’re using these actual projects so that the students in the second semester course are actually cognizant of what we are doing and helping us to build these cases. Then, these cases that are developed will be used in the first semester class to teach the principles of usability and software design.
Tim: Okay. How far along has this gotten as far as getting ready to teach the first-semester students?
Bob: To this point we’ve developed two cases over the last year: one with forestry that had to do with aspects of learning about soil, teaching middle school and high school students about soil science through the Forestry Department and US Forestry Service. And then there is this one with the crane.
Tim: So what was the software for the Forestry Service doing as opposed to operating a crane?
Bob: It was a web-based, instructional learning tool that would probably be used in high school or middle school to teach about water flow geology and different aspects of soil science as it relates to forestry.
So those two cases that we’ve developed, or are developing, are given to the first-semester students. We have taken the project stories and broken them into weekly modules where they get certain aspects of a project as it might occur in a workplace. So, for instance, things can be going along quite fine in weeks three and four and then in week five something happens-
Bob: - something breaks down or somebody leaves the team or the company comes in and cuts your funding, or whatever the case may be. And the students need to adjust and deal with that. And in the end they will have learned about these principles so that in the second semester they can actually go out there and work with another client doing something probably totally different depending upon what comes along.
Tim: This sounds interesting. How do you and Chuck find clients for this kind of thing? How do you go about doing that?
Bob: It’s just like in technical communication courses: we do a lot of client work and have, you know, hooks out in the water and we see if people are interested. Sometimes it can be another faculty member in another department or somebody at an institution, but it can also be a company that might want to have something done and the students could assist in it. And then the nice thing about it is that, particularly when we work with companies, we can get some sort of financial backing, probably, and maybe we can buy better equipment or things that enable the students to learn a little bit more and do more things.
Usually, it’s that we just make contacts with people, so we are always looking for them.
Tim: That’s great! Is there a deadline in effect for the boom operating software so at some point the company will have software that does what they are hoping?
Bob: Yes, I hope so. And see, one of the things, too, of course, is that this project was really through Mechanical Engineering and whether that project actually goes to completion or goes forward any further would be up to them and the company. But I think even if these things are failures, the students learn a lot, so it is a valuable experience.
Tim: So if the software that is developed by the end of the course is not ready for shrink- wrapping and selling or delivery to that one client, that is okay, this is a learning process.
Bob: Yes. And that’s another thing in courses and in the Academy: you can’t do that kind of stuff on a commercial basis with all the obligations that entails. There’s a tension we sometimes have with these projects particularly with these companies. We make it clear to them that these are students. They’re learning the stuff, they also are in many cases taking four or five other classes, and this is only one—although maybe a very important one in their education, no doubt—and we can’t promise, as you might in a company setting where you have to get that product out the door. We would hope in cases where that’s expected that it can happen, but, you know, sometimes it just doesn’t.
Tim: The companies understand that they are not contracting with an actual software development house…
Bob: And they’re getting a deal. They’re not paying somebody two or three hundred dollars an hour to do this stuff. They realize that, and also I think in some ways it is a good way for them to engage with the students, show what their company does and then maybe they would get some job applicants out of it, so that is a side benefit for them.
Tim: It sounds to me like this is a really good way to train future software developers in terms of it not just being about QA testing to see if the application will work without crashing, or that the outputs are “correct”. That is a certain type of quality that is very much needed, but there is another type of quality that relates to purpose and to usability and usefulness of the application itself. Just because it runs without crashing or the outputs are not mistaken – that’s a real victory in one sense – but that’s only part of the total product. You really want it to do the things people need to do, in the way they need to be done, and in a way that is usable for them.
Bob: Right, and it is really interesting to see. These are team projects, usually, and not only teams of software engineers but—as in this one case with the crane and then of forestry—we have foresters and mechanical engineers, too. Then we bring in technical communication and usability techniques as well, which help Chuck to develop raw materials of documentation so that not only is there user documentation in the traditional sense, but there are things like proposals and progress reports and final reports and usability reports, things of that nature. So they learn not only that they need to keep track of things in written form, but they also need to reported to someone.
Tim: As when they leave the university and have a boss!
Bob: Right. And so we are trying to bring all of that in there, and this is one of the interesting things about the project from the technical communication background—we actually feel as though we are making some impact. One of my concerns for many years, one that I have written about, is that we borrow from other disciplines such as business or computer science or psychology, and we take it and we use it and we think we have found an answer and we get very comfortable with that. And that’s fine. I mean, we have learned a lot, and we’ve made progress in technical communication with that. But then how do we move back in the other direction? I think we have a lot to offer these other disciplines. What can they learn from us, and how can we contribute to that? Ideally I have seen it happen in some cases: such things as maybe getting in early to projects with usability help, and as the students experience how we help they realize the synergy there. I hope in the best of all worlds that they get hired in some company and, when problems are happening with a product, they recognize them as communication problems and they say “Hey, we need a technical communicator here to help us with this.”
Tim: I like the idea of this class the way you are approaching it because, when I was in grad school with you at Miami University, I took a C++ course and it was really interesting to see how the developers were being taught. They learned about requirements definitions for their software projects and they had a model for requirement specifications. As I recall, perhaps somewhat fuzzily now, they didn’t really talk about researching tasks of intended users—it was more like “What does the client want.” In the real world, just because the client wants you to do something like controlling the crane on that ship, the client probably isn’t the person who is there on the ship operating the crane. The client is not the person who must use that software to be productive for the company. So your course with Chuck might give your programming students the realization that there is more than one audience here whom they really need to talk to, besides the person who hires them. I guess the person high up defines strategy like “we need to control that crane on our ships” but the tactics of the job are only known by the people closer to the actual work. Can’t leave them out if you want a quality product.
Bob: Yes, we also hope that these kinds of complexities of multiple audiences and the like come out. Another aspect of this project that has been really great is that we have had three graduate students from our program-- the Rhetoric & Technical Communication program—involved, and they have been instrumental. They’ve had a lot of energy. The grant has been wonderful because it subsidizes them and they don’t have to teach as much in their assistantships, so they can be more involved in this project. They are learning things that they can take with their Ph.D.s and go to some job where they are doing what we are doing to educate students in better product design. It has been a really rich experience. We hope that it bears some fruit down the road, far beyond the duration of the grant.
One of the things I was going to say about the requirements analysis stuff is that Chuck has written a section of an article we are working on, and as I recall, the heading for that section was “Beyond Requirements”. He really sees that the students are always taught about the requirements specs but they don’t necessarily—like you where saying—relate it to the end user.
Tim: Yes, interaction design of the product as opposed to “the output will be a PDF form” or something…
Bob: It’s the old function versus usability issue. They can make a functional product, but who cares if nobody uses it?
Tim: Yep. You just touched upon something I was going to ask for my next question. Are you and Chuck and the grad students going to publish some kind of paper about this so that I might point people to it when it comes out?
Bob: That is another interesting thing about this because it is so interdisciplinary. We have several articles in the works. One thing that has already been accepted—and we have to finish writing a draft by December--is an article that will appear in the Journal of the Society for Technical Communication. There’s a series on the future of technical communication and our article will be in the second issue dealing with that topic.
Tim: Great. When will that appear?
Bob: Sometime in 2006. And currently we are also writing an article we hope to publish in a software engineering journal. So we are trying to publish in both areas. We have another year on this grant and maybe it will get extended by a year – you never know what NSF might do – but even if we don’t get more grants we will be publishing in some more technical communication journals. Also, Chuck has a website for the project: http://www.cs.mtu.edu/~wallace/research/speaksoft/index.html. We’ll post some articles there, too.
Tim: Is there anything else you would like to say about the project before we end the interview?
Bob: Next summer, we will host a small workshop/conference as part of the NSF grant, and if anyone were interested they would be welcome to contact me or Charles Wallace about it. The workshop will basically be to have people come here from software development, human-computer interaction, and technical communication, to see how these kinds of things are working. I think that there is a lot of future in that; I feel good that this can happen. At the same time, I don’t kid myself that we are going to radically change the world here. People like Donald Norman and others have been dealing with usability for thirty or forty years and yet you can still go push a button on something and it makes no sense, like the recorder you were having trouble with just now…
Tim: (laughs) Yes, like the controls on this music player/voice recorder I’m using to back up my PowerBook recording! What a mess.
Bob: But I do think we’re having some sort of impact. I also believe that one of the best contributions (and my own interest in this) is that we can bring more theoretical understanding of how usable design works. Through the research, we are developing theories, and we can also go back to the ancient Greeks, and look at other disciplines and understand how—from rhetoric or cognitive psychology or graphic design—all of these things work together. So that’s the kind of stuff that I would like to see happen.
Tim: I think it’s great and I’m also thinking about this in terms of American economic competitiveness. I would rather have industrial designers and product engineers work with these other disciplines while in college so that they understand the interdisciplinary nature of making great products. After graduating, when they are on a project, they might think to involve more people than just a few folks drinking caffeinated beverages and throwing products over the wall to Marketing—but sometimes in a race to no place as far as usefulness and usability goes for the customer.
Bob: There was a software engineer at, I think, Microsoft who once told me something like “People think that you go in a room with a bunch of designers and developers and put on a pot of coffee and sit there and develop stuff but that’s not the way it works.” So I hope that’s the kind of change that we can we can make.
Tim: Me, too. Thanks for talking to UPA-MI about this project.