Happy Thanksgiving 2015!

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.

Give Feedback to Job Seekers

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?

How You Know You’ve Arrived

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.

2015-08-21 08.21.44

Interview with Stephanie Rosenbaum

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.

Founding TecEd

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.

Transforming TecEd

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.

Rethinking the History Project

For much of this year, I’ve been working on a project to document a history of the user experience field in Michigan. It’s a subject that’s quite interesting to me, but because it’s not my day job, it’s also something that is perpetually on the back burner.

I’ve interviewed some really interesting people so far, and I’ve started to feel bad about burying the information I’ve gotten from them for months already, and potentially for years to come. Does keeping this information to myself for however many years it takes to feel “done”—to have interviewed enough people and written something satisfactory—fulfill the goal of the project?

Well, no. The goal is to make the information available. I still want to write something that stitches all this information together, but in the meantime, I’m going to start trying to whip these interviews into shape and making them available here.

If all goes well, watch this spot for more!

History Continues

My work on the history of user experience in Southeast Michigan is continuing slowly and steadily. The biggest obstacle, unsurprisingly, is that paid work always takes precedence over the history project. Not that I necessarily want to get paid for the history project. It would be super scary to actually be obligated to complete it. I have to admit, though, it would also be exhilarating to have this work be my primary job.

I’m hard pressed to identify what is most time-consuming about this work, but my best take on it, in ascending order of time-consuming-ness, is:

  • Interviewing people
  • Booking interviews with people
  • Transcribing interviews and otherwise digesting what I’ve learned
  • Assembling a narrative from all this information I’m gathering

I do think, however, that the narrative will get easier at some point. I’ve already found that to a certain extent, some of my interview subjects have shed light on episodes that I otherwise have a handle on.

I still have to push further into talking to people about the post-2005 time period. I’ve addressed it a bit, and the oddest part of trying to write about it is that I start to enter the story after 2005. I’m not sure how, exactly, to handle it. I’m also pondering the issue of whether to expand my scope beyond the rather arbitrary boundary of Southeast Michigan and just encompass Michigan and part of Ohio. I know far fewer people outside of Southeast Michigan, but places like Lansing and Grand Rapids have had an impact on events in my home region. Also: How much do I talk about non-UX things like the local Society for Technical Communications and human factors work (such as in the auto industry).

It’s hard to say how I could ever truly be done with this project. Well, obviously – history has a way of continuing to happen. Even so, it’s hard to see where I’m going to call it “finished” if I’m working at this rate. I have no plan to abandon the project yet, but even if I do at some point, I suppose a half-finished history is more helpful than no history at all.

My Magazine Article Is In!

I appeared in the October issue of Net. I guess it came out a while ago, but it took time for the physical copies to cross the Atlantic. Last week, I finally got my hands on a copy of the magazine. It was pretty cool to run into the bookstore and pick up something that I wrote.

2015-10-10 09.44.14

How to Get Your UX Conference Proposal Accepted

If you are interested in developing your skills and raising your profile in the UX community, you may have thought about giving talks at conferences. If you’ve already tried submitting proposals to conferences, you’re probably feeling pretty discouraged at this point. Well, I have a foolproof guide to getting your proposal accepted:

Be someone that conferences will invite to speak.

It turns out that filling out a conference proposal is, in fact, a fool’s game. UX conferences get hundreds of proposals. The only guaranteed way to speak at conferences is to be one of the handful of UX celebrities that gets invited to speak at every conference.

Unfortunately, this option is not open to most people. Fortunately, there is a second foolproof way to get your talk accepted:

Be incredibly lucky.

The foremost thing to understand about the conference review process is that it all comes down to the opinions of the reviewers. These opinions are incredibly subjective and idiosyncratic. Some conferences actually share the reviewers’ feedback with you (which is a great thing for them to do). Every time, I’ve found that reviewers will give opposite and mutually exclusive feedback. I’ve had the same proposal described as:

  • Too detailed and not detailed enough
  • Such common knowledge that no one would want to hear this talk and an important emergent topic that everyone would want to hear
  • Too basic and too advanced

So, while I appreciate getting the feedback, I don’t even know what to do with it. As it turns out, getting a talk accepted is just like playing a slot machine. You pull the lever and hope you get three cherries.

Experience Architecture at Michigan State University

Some of the team at Michigan State University’s Experience Architecture program wrote an article for User Experience Magazine and they do a great job of describing what’s so exciting about their program.

I agree completely with a program rooted in the humanities, for the reasons they described. Human values are necessarily the heart of what we do in user experience, and something that, while I don’t believe the University of Michigan School of Information was against, it wasn’t really something that entered the conversation.

It’s interesting to see programs that are created when it’s taken as given that there is a user experience field, and it is a field where people find jobs. When my own school, UMSI, reorganized to incorporate Human-Computer Interaction, it was the early days of usability in industry, and I don’t think there was as clear of a career path.

However, I do have reservations about efforts to push more people into the user experience field. Michigan is not a hot market for user experience (or any job, really). I worry that we’re giving young people the skills they need to evacuate the state, or to engage in a frustrating job search.

But much more importantly, seeing an undergraduate program in UX spring up (and this is in addition to UMSI starting its own undergraduate program) makes me wonder about the future of our field. Does it hasten the day when there are no distinct “user experience” job titles, and instead the skills are taken as a given in a variety of different jobs?

Visual Analytics

The following is a letter I sent in to User Experience Magazine after a recent article on Visual Analytics. Sadly, I don’t think they publish letters to the editor anymore.

I am writing to offer feedback on Bartosz Mozyrko’s recent article, “Visual Analytics: Uncovering the Why in Your Data.”  I am pleased to see the magazine covering data analysis topics.  As the author of Practical Web Analytics for User Experience, I also have a great interest in the subject. I’d like to offer a few comments and concerns.

Mozyrko argues that visualizing web analytics data answers the question of “why” users do what they do, in a way that either plain numbers and/or page-to-page path data do not. I must disagree: Neither kind of data actually reveal the “why” of user behavior. Rather, things like heatmaps and session recordings are just representations of plain, why-less data.

Mozyrko starts by describing how traditional web analytics tools like Google Analytics are insufficient for the task of answering “why,” which is accurate. However, he then argues that visualizations help people digest large amounts of data. While true, understanding large amounts of data still doesn’t solve the problem of “why,” as Mozyrko suggests.

Later, he states that visual analytics focus on what happens within pages, whereas traditional web analytics tools focus on how people move between pages. This statement is an oversimplification. Robust tools like Google Analytics and Adobe Analytics capture a rich amount of data on in-page and between-page behavior. In fact, having these two kinds of data together in one tool offers amazing opportunities for analysis, such as the ability to segment data about in-page behavior based on something the user did elsewhere during their session.

The rest of the article discusses types of visualizations. However, click tracking heatmaps, session replays, and form analyses still do not tell you why users did what they did. Mozyrko never answers the question of how to understand the “why.” He writes “armed with your visual analytics, you now have a complete picture of how users engage with your website or mobile application.” However, the picture is not complete—a complete picture would contain the answer to “why” and Mozyrko does not discuss how to answer that question.

A complete picture of user behavior comes from triangulating different kinds of data. Web analytics data work best when combined with data from things like surveys, usability testing, interviews, field studies, and so on. Interaction with users and putting together quantitative and qualitative data sources are the ways that we get closer to answers the “why” question.

Lastly, Mozyrko has a link in his article to a case study on his company’s website. He is the CEO of a company that makes the kind of tools he discusses in this article. While it makes sense that he would be highly knowledgeable about data visualization tools, this connection along with the inaccuracies of this article make it seem more like a piece of advertising than an article that seriously engages with the question of how to better understand user behavior.

I remain committed to maintaining the highest possible ethical standards for UXPA, and felt obligated to share my concern.  Thank you for your attention, and for your efforts managing this vital publication.

Michael Beasley