With every CHI, and with every issue of <interactions>, our profession is maturing and reaching a better understanding of what it means to be a successful practitioner. The days of the rebel artiste are mostly gone. Yes I still have to put up with one when it comes to tuning my classic car's Weber carburetor, but temperamental craftsmen tend to be short-lived in corporations and large consultancies.
Design talent has to be tempered with business savvy, customer-facing communication skills, as well as the political skills to get your designs through the development life cycle with some degree of fidelity. In other words, who cares if a design is brilliant and scores a 100 percent for unassisted task completion if it cannot be implemented or sold?
A number of colleagues and I wrote a paper for CHI 2006 (available online at the ACM Digital Library), with the idea that "design was the easy part." Ultimately, we went with a less controversial title: "When Design is Not the Problem: Better Usability Through Nondesign Means." The paper resonated with a number of participants who were tired of hearing the "we must make executives listen to designers" mantra. We emphasized the skills that were required to get the design work through the corporate ecosystem, often engaging nondesign-related tools and collaborators.
An understanding and empathy for other stakeholders in the software development process is not really a new trend. Richard Anderson picked up on this thread in his blog, http://riander.blogspot.com, and in the course of his own design-management investigations. In an April 2006 posting, he listed a number of obstacles to good design, which were mostly not design talent-related. Even Don Norman's 1993 BayCHI talk was titled, "Where HCI Design Fails: The Hard Problems Are Social and Political, Not Technical."
With that in mind, there are behavioral traits, methods, and unique skills that distinguish a good commercial designer from a capricious artiste. I am assuming that good conceptual-design skills are a given and will not cover those.
- As outlined in Dustin Beltramo's piece, "Back to School," in <interactions>, volume XII.5, a designer's ability to learn the domain is key to project success. The design of consumer applications like e-mail clients, social-networking sites, and word processors presents unique challenges. But the learning curve can often be steeper when it comes to taxation, material-handling, supply-chain, or general-ledger software. The Internet makes the research stage easier, but a team member contributing designs can't earn credibility without knowledge of domain-specific acronyms, tasks, and behaviors. We often get sent to observe travel reservation agents, corporate procurement specialists, or even manufacturing plant supervisors. It is an opportunity to get out of a dark usability lab, and the resulting designs show the newly gained understanding of the domain's users and real-world tasks.
- Whether a designer is in a centralized or localized design organization, he or she will often be most successful when engaged locally and close to the means of production (engineering). By temporarily or permanently co-locating with the development team, a designer is better able to understand the historical and current design challenges. Working close to engineering also helps to remove the old "nice design, but it cannot be implemented" excuse.
- Deliverables' format and quality are critical to the success of any design effort. Architectural school was boot camp for me on how to present my ideas clearly and with a high degree of refinement. Yet I continue to see publications, sketches, usability reports, and other presentations that are delivered in a format that a developer cannot read (proprietary program flowcharts) or that create the wrong first impressionnot to mention credibility issueswhen prepared in too much of a hurry with incorrect data or use cases. One example of catering the design deliverables to the target audience is attaching a video clip to a particular bug in the software defect database. Using the right communications medium will generate results faster and increase design fidelity.
- "Guidelines are (mostly) evil" is a controversial statement, and I am not able to present laboratory animals that can attest to this fact. For some reason designers love to write guidelines. They are useful as a communication vehicle between designers and widget implementers, but I have not found them effective with the general application developer or customer audience. Developers often find them too detailed to parse or too overbearing for their business problem. Guidelines tend to apply to exceptions and exemptions, particularly in U.S.-based firms. What does work is embedding the guidelines or designer patterns in the tool that a person uses to code. This could be Oracle JDeveloper, MSFT's Expression Suite, or some part of Eclipse, but the idea is to include code-based design patterns. This way, a master/detail, a wizard flow, or some other construct that does not need to be reinvented becomes the path of least resistance.
- Question every excuse. How many times have you been told that something cannot be done for legal, technical, organizational, or political reasons? In most cases the real reason is time and effort, even if teams want to do the right thing for the user.
- The quality of the data gathered and the design itself matter a great deal, but an even more critical piece of the puzzle is the designer's ability to network and sell the solution. Preselling the design to the local team before showing it to the executives, or in some cases doing it the other way around, can lead to greater success rates. Engaging other stakeholders from marketing, publications, or strategy further increases the odds. We are often geographically dispersed, but face time solves many design problems.
- Enterprise software suffers considerable loss of fidelity once it is deployed, customized, or upgraded. The interaction designer who keeps track of the evolutions tends to have more data for creating better versions of the software. He or she can see how the customer or the consultant extended and customized the delivered package, leading to an even better understanding of the users' wants and needs.
- Cloak design speaks in business and technical terms. There is a natural tendency for designers to air dirty laundry and discuss minute details of the design process. Citing design rationale is often useful, but the software crowd is seldom interested in the process details and will turn hostile if the demo does not arrive within the first 10 minutes of your presentation. Any information about design decisions made for the benefit of business, or ease of implementation, should be highlighted along with the visuals.
If CBS were to stage a reality show featuring designers "Survivor"-style, viewers would find that most practitioners could create visually appealing designs. They would probably even test well in the lab. But the introduction of any real corporate, enterprise, or large academic ecosystem would cause half of them to get voted off in the first installment. Once they got deployed to the end users, initial designs would emerge completely unrecognizable. A successful designer forms public and private alliances with marketing, technology, legal, and strategy, all in the interest of getting their designs faithfully implemented. A deeper understanding and empathy for others in the software development life cycle, coupled with some sales skills, will often guarantee survival of the initial designs. Conversely, a desire to drive the entire process and unwillingness to compromise and evolve will ensure it stays on the internal website or in a museum.
About the Author
Luke Kowalski is the corporate UI architect at Oracle. His role bridges the user interface design groups at Oracle. He works as an evangelist for effective UI technology on legal aspects of user interfaces, accessibility, UX marketing, and business partnerships. Before Oracle, he held director roles at startups, and served as a designer in Netscape's UE group. He speaks, writes, contributes to standards efforts, and his most recent degree is from Columbia University.
©2007 ACM 1072-5220/07/1100 $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.