MI UPA:: Past Meetings - Interview with Jason Withrow

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: You said something earlier about the terminology issue that concerns me. You think people might be deliberately avoiding using more common terms so they can market themselves in a unique way to their customers?

Jason: Exactly. I mean, it’s tough. We have a lot of brilliant people in the field and unfortunately with the brilliance comes sometimes the belief that “my way is the way to go” and so you end up with people saying “Well, I call it this” or “I’m going to coin this term for what I do” and a client might say “Wow, I haven’t seen this one before, that sounds compelling, we should go with you, that sounds like a great idea. This guy’s talking about this cool new word and that sounds like what we need.” So they sell it to the client, they get the contract, they write a book or what have you, and we end up with a whole new term for something but when you analyze what they’re doing, it’s something that’s been done before. It’s something that has been around in, say, HCI, for many years, but HCI didn’t market it that way or didn’t get the word out through newspaper articles or books or what have you. So now someone is coining a term for the same old thing.

One of the challenges as a field that we face is that even though we’re forming professional organizations, we’re not looking broadly enough at whom will we serve with that professional organization. UPA has a nice, broad focus but yet there are people that UPA doesn’t bring in and those people might go to AIFIA, the Asilomar Institute for Information Architecture. That name says it all, it’s for information architecture. Or you have CHI, and that’s for the HCI people. And it’s tough because, until we have some sort of a structure or some sort of organization that can “umbrella” and get everyone inside it, it’s hard to establish dialogue, it’s hard to see the big picture. Because we have these little silos of knowledge and silos of “we’re going to call ourselves this in this group and you can call yourselves that in that group” and there’s a lot of similarity, but because we’re separate we’re just not seeing it, we’re not able to jointly benefit from the common ground.

Tim: You know, the more I think about this as we talk, the more I wonder if some of these people who do come up with new terms for what they do, and then they get a customer involved and maybe write a book—it’s kind of a double-edged sword. I don’t mean to disparage what they do, because if they get people to pay attention to user experience issues and improve products, then humanity wins. But yet if they’re doing it with terms uniquely coined for their situation, it doesn’t necessarily help somebody else make inroads with different customers. But then again, I guess if you know what you’re talking about you can just translate for your audience on the spot.

Jason: Yes. And you’re right, it’s sort of like the perspective that, if you’re selling user experience no matter what you are calling it, that rising tide lifts all boats, everyone benefits from that. But you’re right, the language is a barrier and we as practitioners and as consultants have to be very flexible with our language if we’re going to sell a project, to see what the client’s terminology is, what book they’ve got or they’ve read or what they’ve heard from their business colleagues. I’ll give you an example. You call “user testing” “usability testing”. Ok, I’ve got to use that terminology because if I don’t then you’ll wonder what I’m talking about. They are one and the same, but you’re using a different term.
One of the classes I teach is called Professional Practices, where I’m getting my students ready to get employed as Web developers, information architects, programmers, graphic designers. And I tell them when they’re writing their resumes “Look at that job posting. Take what they have listed there, translate it back into things that you’ve done, it’s one and the same. You’ve done what they’re asking for, but you’ve called it something different.”

Tim: I like that point, Jason. Here’s an example of what we’re talking about to further what you just said. My own specific background makes me rail against that “user testing” phrase because in my methodology I’m not testing users, they’re helping me test a product, a product experience or interface or something. I don’t want them to think they’re being recruited for something where they themselves will be tested and judged as passing or failing a test.

Jason: That is true.

Tim: But when you and I talk about it, using either phrase, we both know what it means ‘cause we’re testing something with a user and they’re involved, so it all kind of comes on whatever angle you approach it as. Do you think maybe some of the larger companies in the world, as our profession seeps in, maybe they will help us define things in a more broad way that’s universally accepted simply because they’re so huge? And if they adapt some of our processes, whatever they call them may become by default the terms we should all use?

Jason: I’m hoping that’s the case, that something moves the field towards a common language and it could be a large company. It could be someone stepping forward to take the reins. It’s interesting, we have very well-known people like Jakob Nielsen at Nielsen Norman Group, we have Lou Rosenfeld and Peter Morville, but none of them are really stepping up and trying to unify and really put it out there as leaders in the field “Let’s establish something in common.”

Tim: Sounds like a job for the boards of all our professional organizations at the national and international levels to get together and have some kind of summit! [Laughs].

Jason: You’re right! And like I said earlier, it’s something where everyone has to perceive value from it, and if you can’t get that perception of value and buy-in that this is going to help everyone, it won’t ever happen. I see the value, but they may not; as you said, it’s a matter of perspective.

Tim: Now, you just talked about what you teach your students. I’d like to take some time to ask what you’d advise student members of my UPA chapter to do based on your own experiences. What is your background and education for the work you do today and would you recommend it for others, or do you have some general advice for people, speaking as an educator as well as practitioner?

Jason: Well, my background is a dual background. I have a master’s in psychology and in information science, so I’ve got this combination of understanding human beings, which is the psychology aspect, and the other side of it is understanding information. So that’s how I did it. But to be honest, people are not going to want to get two master’s degrees, that’s a lot. So what do you do?
For my students, I recommend that if they can do it, they should go on and get at least a bachelor’s degree. And that’s what I recommend. And then…it’s a challenge—there are some education options like Carnegie Mellon has a bachelor’s in HCI and there are some others out there, various master’s programs, and it’s a long road. I think at a minimum you need to have a bachelor’s degree. But what BA do you get, what bachelor’s do you go after. Do you get a psychology undergrad? Do you get an information one if that’s available to you? One of the nice things about the field, because we are relatively young, you can still find a position if you have experience and can impress the employer with the quality of your deliverables and get your foot in the door that way. In another ten years, we might see that changing, that it’s going to be education, education, education. But right now you’ll see people asking “do you have the skills?” It would be nice to have the specific bachelor’s degree but people can still get their way into a company if they show the caliber of their work.

Students always ask me if they should go on from our two-year program to a bachelor’s or a master’s and I recommend the bachelor’s as something you should definitely do, and a master’s would make you even more employable. One of the things I stress in my classes is a lot of practical, real world examples: doing an expert review, conducting a user test or usability test [Tim laughs] whichever terminology you want to use, doing a cognitive walk-through or pluralistic walk-through. Actually doing it so you can say to someone I know exactly what you need me to do and I’ve done it and here’s a written analysis of a website or here’s a storyboarded interface for something I’ve created based on these specs. That’s the sort of stuff that builds a student’s portfolio and I think gives them a really big edge over someone who might have more education but doesn’t have a portfolio, they really haven’t proven that they can do what the employer expects them to do.

Tim: I like hearing you say that, Jason. In the master’s program at Miami University, we had to go out and find clients on campus for our projects. Instead of a professor saying “Ok, everybody do X and hand it in” and everybody’s doing the same thing, they helped us find genuine needs on campus for our work, either in the campus IT department or other departments within the university so our projects served real needs. We had to deal with clients just like in the working world, we weren’t just sitting in our apartments writing an assignment.

Jason: Right. That sounds very much like the School of Information at the University of Michigan. Finding a client, usually through the university system, and working with them on solving their problems.

Tim: Yeah, if you’re not solving problems, it’s really hard to justify the work, isn’t it?

Jason: It’s very, very difficult.

Tim: I have a question based on the slides you kindly let us put up on the website. I was showing them to my technical communications teammates at my job, and one question they wanted me to ask you was what is the difference in content and purpose between storyboards and wireframes as you have them in your slides? Both of them seem to contain similar stuff.

Jason: Yes, and in fact you could consider the storyboard to be a series of wireframes. They mostly differ in how I use them. A wireframe on its own is usually done as part of the interface development process. If I’m going to start mapping out more than just a single screen, more than just a single home page or sub-page (using the Web model) —I’m thinking of a registration process across multiple pages or a checkout process or anything that really involves a task—then the storyboard is where I’m going. And that’s essentially a series of wireframes that go through step by step so the developer knows very clearly what needs to be put on the page, where it’s positioned, what terminology to use, everything down to those details. The only aspect that might be different is I might end up providing some information about functionality, some information about what’s going to have to happen interaction-wise and functionality-wise in a storyboard, because it is a series of screens, that I wouldn’t put into a wireframe because a wireframe tends to be a static “this is the home page” or this is a given sub-page. But there is a lot of similarity there between the deliverables; essentially, it’s a matter of what you’re doing with it and what your goal is in creating that deliverable. So if it’s a task, I move towards using the storyboards, and if it’s just a simple “develop a homepage” then a static wireframe on its own does the job.

Tim: Alright. Last question. What are you doing these days in your research or your teaching that you’d like to share with the world?

Jason: I’ve written a couple of articles for Boxes and Arrows, it’s an online information architecture journal. They do a lot of great work with a pretty broad focus across information design, HCI, and the other various sub-disciplines. I wrote a piece recently on site diagramming for them. I didn’t get into the labeling issue in this article, as in saying there’s a bunch of names for this kind of diagram and mentioning 10 synonyms or whatever—I held off and decided not to lambaste or to lament the state of labeling. Ultimately these things are diagrams of a website; the common denominator is that it’s a site diagram. And that article got a nice reception; people had some great insights, lots of comments that I try to get back to post responses to on the website.
Another thing I’m writing for them and that should be published one of these days is my process for creating a series of three user experience classes. So if you had this trilogy, this opportunity to make three classes from scratch, and at the very end have students skilled and knowledgeable about user experience, which will be across these various disciplines, how do you do it? So that was a fun piece to write, I think it will be a good piece to read, I think it’ll probably be published in October is my guess, but I’m not real sure. So I’ve been looking at those issues and writing about things that are pertinent to my teaching.

Tim: I did just read your new article and really liked it.

Jason: Oh, thanks.

Tim: I really appreciated that you used “diagram” to cover all bases. It really says what it is without getting into trademark terminology fights about what you’re using for a particular purpose.

Jason: And it just goes into my whole reason why I developed that approach to diagramming. I was looking for something that clearly stated what was going on, approaching it as exactly what it was, so even with my labeling of the deliverable I didn’t use language that was unnecessary or unclear. I was trying to use something that on its own described itself; a self-describing label. That’s my goal in my professional work, to make things as intuitive and transparent as possible. I guess that’s really all of our goals.

Tim: I think so, and that’s a perfect place to end our interview. Thanks for talking to us today and for speaking at our July meeting.