Published: May 28, 2007
A UX architect, or lead UX designer, is the member of a product team who is primarily responsible for ensuring all aspects of a digital product that users experience directly—including its form, behavior, and content—are learnable, usable, useful, and aesthetically pleasing. Thus, a UX architect has an important role to play from a product’s conception to its launch. But creating truly great products requires an entire product team to place the needs of users foremost when making product decisions—or even better, a user-centered corporate culture. If you find yourself in a less enlightened company or on a product team that just does’t get how creating great user experiences contributes to a company’s success, you should take every opportunity to evangelize the value of UX to people in your company—from the executive management team to your peers in other disciplines on product teams. If you need help making the case for UX, have a look at my article on UXmatters, “Why UX Should Matter to Software Companies.”
The Multidisciplinary Nature of Product Teams
So, who owns UX? An entire product team must consciously share responsibility for UX—or ownership of UX—because the members of a multidisciplinary product team impact the success of a product’s user experience in different ways. Read more
Published: May 28, 2007
Last year, I had the pleasure of contributing to Jonathan Arnowitz and Michael Arent’s special issue of Interactions magazine that focused on prototyping. Based on our conversations and the other contributions to that issue, I looked forward to seeing their forthcoming book on the topic.
I’m a great believer in prototyping as a means of rapid application development and am always looking for ways to improve my craft. Imagine my delight at the prospect of cruising through 600 pages devoted to the subject!
Effective Prototyping is an ambitious undertaking that in some ways redefined the meaning of prototyping for me. No reader is likely to absorb this tome from cover to cover—certainly not in one sitting and maybe never. The authors have tried to include as much information as possible on the topic, resulting in an extensive reference that paradoxically leaves me unsatisfied. Read more
Published: May 21, 2007
Many Web application designers strive to reduce the amount of instructional text that appears in the user interfaces they create. A likely part of their motivation is the perception that, if explaining how to use something requires too much instruction, it probably isn’t that easy to use and, therefore, has room for improvement in its design. Another motivating factor might be the tendency for people not to read any on-screen instructions, just like they tend not to read product manuals.
This type of thinking also applies to Web forms. When possible, designers strive to utilize a minimal amount of text to explain how users should fill in the different input fields in a form. In cases where forms absolutely require additional explanations or examples, a bit of clear text adjacent to an input field tends to do the trick, as shown in Figure 1. Read more
Published: May 21, 2007
There is an adage in software development that says there are only three types of documentation that have ultimate value:
- user assistance
- test cases
This adage does not mean that other documents such as functional requirements, documentation plans, wireframes, personas, and such do not have value. It merely means that you do not want to be a year, a thousand pages, or a million dollars into a project and not have any code, user assistance, or test cases.
Most iterative design frameworks such as the Rational Unified Process (RUP) or agile software development embrace the principle of getting to demonstrable, testable code as soon as possible. Typically, they achieve this by separating the product requirements into functional chunks, then systematically developing each of those chunks through sequenced project phases that are sometimes called iterations. The early iterations usually comprise architecturally significant or technologically risky functionality. Read more
Published: May 7, 2007
Making the case for user-centered design (UCD) is a topic of recurring discussion for UX professionals. Much of the discussion has centered on strictly objective approaches such as cost-benefit or return-on-investment (ROI) analysis. However, recent commentary suggests proving ROI is not always enough. For example, Dray, Karat, Rosenberg, Siegel, and Wixon have raised concerns about significant weaknesses of the ROI argument, including their concern it ties UCD to tactical, not strategic initiatives. 
How can UX professionals address these weaknesses and make their case for UCD convincing? Promising sources of help are the fields of rhetoric and argumentation, specifically the range of persuasive appeals, the consideration of audience, and the structure of informal reasoning. There has been some discussion of rhetoric and UCD. For instance, Carter and Yeats explored the rhetorical function of a video showing highlights from usability testing.  However, until recently, there was little in depth discussion about using rhetoric and argumentation to make the case for UCD. A Special Interest Group session at CHI 2006 tackled this subject, resulting in a lively and useful discussion.  Additionally, during management panels at CHI 2006, executives at major corporations such as Intuit and Reed Elsevier stressed the need for UX professionals to articulate arguments and be persuasive in a range of situations on projects and in organizations. One even flatly said that the ROI argument “doesn’t work.”  Read more