After holding many design and design-management jobs, I was taken aback at a recent interview when asked if I had more examples of design work in my portfolio. Never mind that I thought I had examples thereit wasn't enough. Yet I identify as an interaction designer, and I thought I had been doing design during the past decade. In truth, my portfolio is stronger than that of many of my more junior colleagues.
My experience of 10 years on staff at software companies as diverse as Excite, Adobe, and Autodesk is that few interface-design positions entail doing much actual design work. Nevertheless, hiring managers go through the motions during the interview, as if it's terribly important for the role you'll be playing. Just wishful thinking, or a bigger problem about who we are versus who we wish we were?
"...A good team player, able to juggle multiple priorities."A job ad for an established "startup"
Strong's NSF report on the state of the industry in 1995  asserted that many HCI practitioners experience identity conflicts within the first few years of entering an applied position. "In general, they must reorient their views of how they work, what questions they ask, and what about their work is valued." I find this to be as true today as it was a dozen years ago, despite some evolution in software companies. There may be more jobs now, but are they the jobs we've been trained for? Are they even what we're being interviewed for? Why the disparity?
I suggest three reasons: 1. lack of good project management in software companies; 2. a desire for "usability" as a goal without an understanding of how to execute on this, from both practitioners and executives; and 3. a lack of education and confidence in young practitioners as relates to design activities.
This is a common line in an interaction-design job posting. It means you need "good project-management skills," usually good people-management skills, and, more sinisterly, that "you'll be completely swamped." This doesn't mean you'll be doing a lot of design; in fact, it may mean just the opposite: You're willing to squelch your own design impulses and abilities in favor of achieving timely group consensus in an efficient move toward that resource-constrained ship date. If you get too creative and pushy about your ideas, you probably won't be seen as a team player.
A UI-design colleague of mine at Adobe (now a product manager) used to say that we spent more time scheduling meetings and getting various stakeholders to talk than we did designing or writing specsand we did that part after-hours when we were pretty tired.
Berkun identifies a good project manager (or program manager) as someone with the "ability to make things happen". It's no surprise that playing this role often falls to the designer or the usability team memberif we couldn't make things happen, by creating consensus while stitching together vague business requirements into a development plan for concrete features, our design specification would have no value at all. It's a role many of us have had to adopt in order to do what we believe we were hired to do, which is make change in an existing product. But it's a side effect of being in matrix-managed software teams that don't have anyone else playing this role, a larger problem in the software industry as a whole.
Our second problem is the balance of evaluation versus design in our roles. The majority of the professionals I have seen on staff in industry are fairly junior, often imprisoned in usability testing labs rather than performing creative activities, or located in other positions of influence. Strong reported that "design of software interface" came in 22nd out of a list of 50 items practiced by surveyed HCI practitioners . The top item on the list was "giving presentations." If this has changed in the past decade, I'd guess it has changed in favor of "project management activities," which is admittedly an improvement over "doodling ideas I wish I could show someone."
"We do not create anything of substance; we are critics."Don Norman 
Marginalization in the testing lab is not improved by a lack of facility with market-research methods and language; many students from HCI programs don't emerge well trained in experimental design, statistics, methods for consumer research, content analysis, or ethnography. These gaps in their research skills limit them when it comes to opportunities in other influential business roles, including promotions beyond the usability function.
Educating HCI students in market-research methods and concerns, in addition to our own particular methods, will help them to communicate their value to organizations in language that business leaders can understand a bit better. Siegel and Dray  suggest we reframe UCD methods in ways that show UCD's links to larger business concernsdue diligence, product planning, quality, reduced risk, efficiency, and innovationand to marketing and business goals like customer satisfaction and retention, and, ultimately, profitability where possible.
However, the risk of developing broader research and strategy expertise is that practitioners can move even further away from design activities. Before we know it, we can be snapped up by the modern marketing organization that asks for increased rigor, a stronger focus on customer metrics of all kinds. At CHI 2002, the 20th anniversary of the conference, Stu Card and Don Norman criticized the CHI community for being focused on evaluation  (and today one might optimistically say customer research), but we are not doing creative work: "Design is where the action is," Card said.
The hard part of the designer's job should be the act of producing good design. But before we get to the hard part, we need to be allowed to do it. This means not doing other things, such as usability studies, market research, and project management. Research work is more immediately evaluable and therefore valuable to most managers, even when not delivered using business vocabulary. For those trained as generalists in HCI, it's easy to fall into the lab trap because we're criticized for doing design and not for our research efforts.
Design is unacknowledged as a dirty word or at best poorly understood in the serious engineering practice of developing software. Design is disruptive, in that the results often suggest costly work for already overcommitted development organizations. Design work is hard to evaluate, particularly at the artifact stage; Bill Buxton has claimed it takes design talent to recognize good design direction . Yet everyone has opinions about design and is eager to share them!
The design process itself can be seen as "unstructured" or undisciplined, and the same is often thought of the folks who practice it. Artifacts that appear sketchy, informal, speculative, mutable, and unfinished may look self-indulgent and indecisive. We as a community haven't helped the case for the inherent messiness of design by being focused on a rigorous engineering approach with a goal of producing artifacts for user testing, communication to other stakeholders, and inclusion in specifications rather than as part of a more creative cycle of prototype production and critique [2, 6].
"I live for the day one of my ideas goes in the product."A UI designer at a consumer-electronics company
As a result of these professional stresses, the portfolio of most HCI designers will usually consist of a lot of functional specs, usability-testing data, but very few breakthrough design ideas and artifactsand they'd be the first to admit that. If they're lucky, one of their ideas made it into the product and they feel inordinately proud of getting it past the consensus process and the development schedule. If that idea was just an extra radio button option on a dialog, this will be depressing to admit in an interview contextespecially when it felt like a real coup at the time.
The better we become at expressing and capturing ideas in prototypes of different types, the more we can communicate our value as designers.
We can't just talk about the importance of good design. If we don't create good design, user experience and product innovation won't be coming from us, but from someone on the engineering team. And we'll be lucky to be asked to evaluate it.
To submit a research article, please email Carolyn Gale at email@example.com
3. Shneiderman, Ben, S. Card, D. Norman, M. Tremaine, and W. M. Waldrop (2002) "CHI@20: Fighting our way from marginality to power." In Proceedings of CHI 2002 Minneapolis, Minn., April 2002, 688--691.
Ghostweather Research & Design, LLC
About the Author
Lynn Cherny is a former design manager and contributing UX professional from software companies such as Excite, TiVo, Adobe, and Autodesk. Now working as principal of Ghostweather Research and Design, she's recovering from doing too much project management and reacquainting herself with the tools of prototyping.
©2007 ACM 1072-5220/07/0900 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2007 ACM, Inc.