In the USA, it’s Thanksgiving Day. And although I try to write these posts weeks in advance, I thought I’d take this opportunity to give myself a break. That this break is on September 27th is immaterial.
Let’s start by getting right to the point: When someone is rejected from a job they’ve applied to, they deserve to know as soon as possible. If they ask for feedback, it behooves you go give it.
I’ve searched for a job often enough myself, and watched plenty of people do it for years at a time, and it is hard. It’s a hard, hard process and it takes all of your energy just to keep up your morale. And as hard as it is to be on the side of the table that’s trying to hire someone, it’s far harder to be the one who’s looking for a job. After all, your livelihood is at stake.
Coming at it from that perspective, I really don’t understand why companies simply stop talking to candidates rather than rejecting them, and why they refuse to offer feedback when requested. A little empathy is in order. And if not empathy, some appreciation for the possibility that one day you may be on the other side of the table. Wouldn’t you want to know that you were rejected? Wouldn’t you want to know what you did wrong or what skills you need to improve?
We got a copy of Baxter, Courage, and Caine’s Understanding Your Users at work recently. I was one of the reviewers for this book, which was a super-interesting thing to do. Besides getting listed in the Acknowledgments (yay!), I also got a mention as suggested further reading for web analytics. When you start getting recommended by other books is how you know you’ve arrived.
Stephanie Rosenbaum has been a pillar of the user experience community in Michigan and worldwide for the past thirty years. Although she originally founded her company, TecEd, in 1967 to focus on technical documentation for computer software, in the 1980s she concluded that she could do more good by actually making the software easier to use. At that point, she began to transform TecEd into one of the earliest companies to employ the emerging user experience (UX) discipline to use in industry.
For Rosenbaum, part of learning about UX was engagement with the community of researchers and practitioners. She has been a long time attendee of the Association for Computing Machinery (ACM) Special Interest Group on Computer-Human Interaction (SIGCHI)’s annual conference, CHI, and was a charter member of the first organization for user experience professionals, the Usability Professionals’ Association (UPA, now UXPA). She is also a prolific writer and educator.
In this interview, we discussed how she entered the computing field in the 1960s, the founding of TecEd, and its transformation.
Entering the Computing Field
How did you originally enter the computing field?
There I was, a 16 year old from the New York Metropolitan area with my nose in a book all the time, and I somehow learned about a National Science Foundation-sponsored summer course. Now, we’re talking about the late 50s… it was 1957 when the Russians orbited Sputnik. That got a lot of people really nervous and they said, “Oh my God, we’re lagging behind the Russians in science education. We have to do something!”
One of the somethings that they did in 1959 was to get IBM to donate time on the IBM 650, a mainframe computer that cost $1,000 an hour to use. The 650 was in their Watson labs at Columbia University, and they got a couple of Columbia professors to donate teaching time as well.
A bunch of 16 year olds from New York and New Jersey applied to this program, and we got to spend a summer going into Columbia every day and learning how to program. We actually wired boards a little bit, and we programmed in something called FORTRANSIT, which was the predecessor to FORTRAN. That was where I first discovered that most of the kids in this course with me were brilliant, really nice people, but horrible communicators. So that sort of laid the groundwork for what I did later!
The other reason that particular program got started was because anthropologist Margaret Mead was interested in whether somebody as young as a teenager could actually learn to run these enormous, complicated things called computers.
It’s actually pretty funny, when people are now taking their 18-month-old kids and putting them in front of an iPad. Nowadays, it’s, “Wait until 16? What’s the matter with you?” But at that time, it was unheard of that anyone without a graduate degree would be let near a computer, they were so expensive.
Were you in Michigan when you started TecEd?
I was actually in California. I was a grad student at UC (University of California) Berkeley. I started TecEd while I was getting my masters. The University of Michigan connection is a heavily personal connection in that I was an undergraduate at UM, and I met my late husband there; we were involved during our undergraduate years. We broke up and I moved to California, and then we got back together again. At that point, I had started TecEd in Berkeley and he had started an operations research consulting firm here in Ann Arbor. We decided that Vector Research had started in Ann Arbor, so it’ll stay in Ann Arbor, and TecEd can move. So I moved the headquarters to Ann Arbor.
That was pretty easy, because it was infinitesimal at that point—basically, it was just me and an occasional helper-out. Then since at that point Silicon Valley was just getting started, I moved our official California address down to Palo Alto, where we still are. But Ann Arbor has been TecEd’s headquarters since the 1970s.
It was a wonderfully wise decision, actually, because Silicon Valley is hot—it’s always been hot—but it’s also a revolving door if you’re an employer. You’re lucky if someone stays two years. Expenses are twice as high because it’s California. Especially in the usability field, Ann Arbor has turned out to be a real asset because I can say to our Silicon Valley clients, “Do you intend to sell your product or service only to Silicon Valley geeks? Or would you like to sell it to people in the heartland? If so, you should be researching with your target audiences outside of Silicon Valley,” and most of them get it. It’s been helpful, actually, to be able to say, “We can do studies with people from Detroit, and people from the suburbs, and so on.”
Also, Southeast Michigan is a wonderful environment for finding employees, and a better environment than it’s ever been. It was a little harder back when our profession was less well known, because there were fewer of us here in Michigan, but that’s getting better all the time.
How did you get started in the user experience field?
I started TecEd as a technical communication consultancy, largely because I was involved relatively early in the computer industry—mainframes—in the early 1960s. What I observed about computing at that time was that the people who were developing the computer systems and software and applications were brilliant people—they were also really, really nice people—but they were very bad communicators. They could only explain what they were doing to other people with the same backgrounds.
That was marginally okay in 1959 to 1963, when I first got into the computer field. Once computing started moving from mainframes into minicomputers, at the same time it was moving into industry. People were starting to use computers for things other than major engineering applications, where the only users were PhD engineers. So all of a sudden there was a growing community of people who needed to know what to do, and the only people who knew what to do were horrible at explaining it. So, having seen this from both sides, I said, “We need a service,” and the service is to be a translator from engineering-ese to human being-ese. We started writing help systems and user guides and instructional materials.
Interesting things happened. For example, we were writing a user guide for one of the first personal computer accounting systems for an Atari computer. We started writing how to execute the various commands, and as we documented them, we realized there was a huge inconsistency. Atari had two separate design and development teams. and the result was that half the commands in this product took effect the moment you finished typing the command and the other half required you to enter a carriage return. We started writing it down, and we said, “Wait a minute,” and we went back to our contact and we said, “It behaves like this.”
Atari said, “It doesn’t! It couldn’t possibly!” But we had documented exactly what the software did. And no one should have an instruction manual that says, “For these 20 commands enter a carriage return, and for these 20 commands, don’t bother.”
Various experiences like these led me to realize that no matter how good a job you did at explaining how something worked to its user community, that wasn’t good enough. It wasn’t anywhere near good enough. Because if what the user community had to experience was difficult to use and confusing—user-hostile—you could write the Encyclopedia Britannica and all you would have would be another not very usable aspect of the product.
If we thought the need for clear professional communication was desperate when I started TecEd in 1967, it was much more desperate by the mid 1980s. We realized we needed to take a step up the food chain and make sure that the products, systems, and eventually websites and apps were themselves usable. So we started going back to school. We went to SIGCHI and what was then the Human Factors Society—now it’s the Human Factors and Ergonomics Society—meetings, and took their courses, and we read the literature. And of course at that time, in the early to mid 80s, you could read all the literature. There wasn’t that much out there in user experience. Anyone interested and motivated could reasonably read a pretty large subset of what was published in English.
We started hiring people who had Cognitive Psychology backgrounds and Human-Computer Interaction backgrounds, in addition to our existing people who had mostly communication-related backgrounds of one sort or another.
One of the challenges for our field is how many different fields it has roots in. My roots are in technical and professional communication as well as some anthropology in college, which has been a huge help, and a master’s degree in the philosophy of language which also turned out to be a huge help—although who would have predicted it! But we didn’t know that we’d be designing user interfaces where the issue was how well the language in the interface was doing its job… Maybe if my graduate philosophy degree had been in Kant, it would not have been so useful, but philosophy of language has turned out to be very useful.
Anyway, what happened was from about the mid 80s through the early to mid 90s, we pretty much reinvented ourselves. By 1989, we were sufficiently pushing the envelope in usability that I was one of the authors of the first special issue of any professional journal on usability. That was in the IEEE (Institute of Electrical and Electronic Engineers) Transactions of the Professional Communication Society. I had an article on the differences between heuristic evaluation and user testing.
About that same time, or in the early 90s, Judy Ramey* started one of the first short courses that was taught anywhere about usability. For several years I guest-lectured there on participant selection and recruiting, which continues to be a hot button of ours. If you’re not doing your research on the people who are actually your target audience, you collect a whole lot of data with no idea if you can trust it.
Then, Judy Ramey and I, sometimes with a couple of other colleagues, started proposing courses at CHI. Between 1992 and 94, we taught a number of courses at CHI and I think at the Human Factors Society’s annual conference, basically on applying user data early in the design cycle—how to bring in user- centered design early in the process.
I presented at CHI just about every year. I was at both the CHI conference and the Human Factors conference the year Janice James** ran her birds of a feather session on usability—she was realizing, as a number of us in the field were, that CHI and what was then HFS were highly academic conferences. It wasn’t that practitioners couldn’t benefit from them, but you had to fill in a lot of gaps between somebody giving a paper on something from their PhD thesis and something that you could actually apply to make a product better. So in these birds of a feather sessions at CHI and HFS Janice said, “maybe we need an organization for practitioners,” and thus UPA was born. There was a lot of interest and they got it off the ground. I was one of the charter members of UPA in 1991 and attended the very first UPA conference, and I’ve been at every UPA conference but two.
* Professor and former chair of Human Centered Design & Engineering at the University of Washington.
** Principal founder of the Usability Professionals Association.
The UX Community in Southeast Michigan
How has the market for local talent changed over the years? Were you able to find usability people when you first changed the focus of TecEd?
Well, for the most part we didn’t hire usability people at first. We were mostly taking our existing people and training them. We did get one cognitive psychologist right out of grad school. At that point, in the late 80s/early 90s, there was only academic human factors and academic cognitive psychology, and also some University of Michigan School of Information stuff—so library science was the other place we got people. Even when SI was primarily a library science school, they were doing information architecture, which is a huge part of what you need to do to get better user experiences.
Marketing User Research and User Experience
Has it become easier to sell user research to companies over the last 20 years?
In some ways it’s less hard to sell because we don’t have to define every term from scratch. People have a better understanding now of what customer research is, what user research is, what user experience is. At least, people are more user-experience literate, and that’s a great help. So in that sense, things have eased. There are more places people can turn to learn about user research, to get support in it, and get help in it. That’s wonderful for the profession. However, it means we have to define our niche carefully, because we can’t compete with everybody.
Despite this, the challenges and obstacles have not really changed. When I was asked, something like 20 years ago, “Why don’t you get the projects you propose but don’t get? What are the major reasons? What are the competitors?” That’s not usually why we don’t get a project.
Usually why we don’t get a project is because first companies say, “Oh, that sounds like an awful lot of work; we can’t do it before the product launch.” That’s probably the biggest. I have a whole song and dance about how “It may be late for this release, but it’s early for the next release—do you really believe you’re never going to have another release?”
But despite all that, we still hear “That’s really expensive; that’s a lot of trouble; we’re not going to do that.”
Your major competitor is doing nothing?
The major competitor is doing nothing—not doing the research at all—and that has not changed. Then probably the next big competitor is, “Well, that seems like a really great idea, but we don’t have any budget for it. We’re going to get a programmer to test a few participants, or we’re going to get the tech writer to test a few participants.”
So another competitor is, “Yeah, it’s worth doing, but we can’t get funded to do a thorough job, so we’re just going to do something ourselves.” That’s a bit better, because if they do something themselves, that’s the first step up the ladder… They then realize how much work is involved and they may say, “I guess I didn’t really want to not do my day job for six weeks. I’m going to try harder to get funding next time.”
Competitor number three is, “We think we know enough; we don’t need to talk to our target audience. We’ve got a brilliant designer. We don’t need user data.” They don’t quite say that in as many words, though. None of those things has changed in 20 years.
TecEd continues to be an important part of the user experience community to this day. You can learn more about them at www.TecEd.com.