Ask UXmatters is here to answer your questions about user experience matters. If you want to read our experts’ responses to your questions in an upcoming edition of Ask UXmatters, please send your questions to: [email protected].
Champion Advertisement
Continue Reading…
Using Verbs As Nouns in User Interfaces
Q: My company is developing software that, among other things, manages large amounts of member information. This is enterprise-level software, so we assume there will be some training involved. (Although, it’s been my task for the past year to get the company out of the mindset that we should rely on training rather than usability.) To better manage interactions with such large datasets, we’ve incorporated the concept of views, in the same way that Microsoft Outlook and SQL Builder use them. However, my initial usability testing has found that the concept of views is escaping most people, and I think it often boils down to the term itself. Even if I show users what the software does—and they pretty much always like it when they see it—they still often cannot get over the initial hurdle of the naming convention. When we say Click here to view your views, we see eyes glazing over and drool forming at the corners of the mouths of even the most competent users. I have two questions for the Ask UXmatters experts:
What are your experience and wisdom on the use of verbs as nouns in naming software functionality?
Do you have any other brilliant names for views?—from a UXmatters reader
The following experts have contributed answers to this question:
David Malouf—Professor of Interaction Design at Savannah College of Art & Design; Founder and former Vice President, Interaction Design Association (IxDA)
Pabini Gabriel-Petit—Publisher and Editor in Chief, UXmatters; Principal User Experience Architect at Spirit Softworks; Founder and Emeritus Member of Board of Directors, Interaction Design Association (IxDA)
Leo Frishberg—Principal Architect, User Experience at Tektronix Inc.
David Kozatch—Principal at DIG
Whitney Quesenbery—Principal Consultant at Whitney Interactive Design; Past-President, Usability Professionals’ Association (UPA); Fellow, Society for Technical Communications (STC); and UXmatters columnist
Paul Sherman—Principal at Sherman Group User Experience; Vice President of Usability Professionals’ Association; UXmatters Columnist
View—A Noun or a Verb?
“Regarding your specific questions, applying language in an unambiguous way is crucial, no matter what the part of speech,” answers Leo. “View is both a noun and a verb, but as you’ve discovered, it doesn’t work well to put the two together in a directive.”
David Malouf says, “I don’t think I can answer your question about verbs as nouns. Why? Because it all depends on the market space. I have 10 years of experience designing enterprise software and hardware, and the one constant is that there is no constant. The rule in enterprise systems is that vocabularies should be contextual. This is a long way of saying that you’ve got to do your research.
“I do have to say that if I saw a link that said Click here to view your views, I would have a similar response.
Click here?
View your views?”
Whitney asks, “Is it the label Views that is confusing people or the actual implementation? I can easily see how eyes might glaze over on being told to View your views, but when users see what’s behind that door, does it make sense to them? Before you can get anywhere with this problem, you need to figure out if it’s the terminology, the learning curve for the software, or if the entire approach is wrong for the types of tasks and information people will be working with.”
“It’s difficult to answer your question without seeing the user interface in question, because the use of terminology in user interfaces is contextual,” replies Pabini. “What is the here you’re asking users to click? What are the views? The source of users’ confusion may lie there rather than just in the terminology you’re using in the user interface. That said, though the verb view predates the noun, view has been in use as a noun for over 400 years, and both forms of the word are common in user interfaces.
“In Windows, Mac OS, and more recently Java, a View menu has been a standard feature for many years. The purpose of a View menu is to contain commands that alter a user’s view of data in the active window. Commands on the View menu let users change the presentation of the data, without altering the data itself. The View menu commonly contains commands that comprise both nouns and verbs. For example, in Mac OS X, the Finder’s View menu includes the following commands:
In combination with the menu title View, the following four commands comprise clauses, in which View is the verb. All of these clauses have the same implied object—the data in the active window.
as Icons
as List
as Columns
as Cover Flow
A separator bar sets off the first group of commands, in which View is a verb, from the second group of commands, in which View is a noun.
Clean Up—Read this command as Clean Up Icon View.
Arrange By—Read this command as Arrange Icon View By….
The rest of the commands on the View menu show or hide certain features of the user interface, which is another common use of the View menu.
“So, as you can see, the use of the term view is quite varied, and users are accustomed to seeing view used in all of these different ways.”
Alternatives to the Word View
“We often encounter multiple views in user interfaces as means of inspecting different aspects of a dataset or different results,” says Leo. “Sometimes users prefer to think about the window element itself—as in pane—to help keep themselves oriented. In other circumstances, based on the specific design approach, users may frame the discussion in terms of results. In yet other designs, the actual widgets inside the pane are the thing users want to use—for example, that table or that diagram.”
“If your user interface requires the use of some kind of descriptor to delineate each different type of view, simply name each of them based on what users see—for example, a list, a table, or a tag cloud,” offers David Kozatch. “Without seeing your user interface, it’s tough to know exactly what your directive should be, but I would guess that See Your Views or View Results might work.”
David Malouf offers this opinion: “I would say that the term views is way too generic for anything in the enterprise. What users call them is already embedded in their standard business processes, and they just want that word.”
Pabini disagrees about the term views being too generic, “Enterprise software usually displays large bodies of data, so letting users choose different views of that data is essential, and that’s exactly the purpose for which guidelines say we should use the term views. Of course, what we should call each individual view is another matter, and on that point, I agree with Dave. We should use the terms users are already using for them.”
David Malouf makes an excellent point: “If the enterprise software you are creating is used across a broad segment of contexts, you have to give your customers the ability to create their own vocabularies. The unfortunate reality of the enterprise is that, if you don’t allow for customization, you will likely fail.”
Views: A Successful Example
“As for views, one of the most intuitive interfaces is Apple’s iTunes,” says David Kozatch. “At the top right of the screen is the word View beneath three icon buttons. These buttons provide visual cues to prepare users for what each represents—a text-based list, a list of cover art visuals, and their unique cover flow feature. There is no need to name each of these views. A user can simply choose each view and decide whether it is useful or fun. Unless you are inventing a new way of viewing data—for example, cover flow, a term which Apple doesn’t require you know in order to choose that view—why name the feature at all? The interaction should be self-explanatory.”
Choosing Terminology for User Interfaces
David Kozatch reframes the reader’s question, saying, “With all due respect to the reader, I think you should be asking your question from a different context. The use of verbs as nouns is less of an issue than what I would call expectation versus experience. User interfaces use lots of words that can function as both nouns and verbs, but users don’t really care about this grammatical distinction. The question is How can you use naming to meet user expectations?
“Being descriptive and action oriented is a good place to start. If you want users to perform an action, you should use words that let them infer that action—for example, edit, view, print, send, or buy now. One of the most common mistakes in user interface design is designers’ forgetting to include an important action word when introducing an important function. Here’s a recent example: We tested a user interface in which users could rename and add columns in a grid and save different views. The button label for this action was simply Columns. Users often remained unaware of this feature until we added the key action word Edit. Another common mistake designers make is to use branding in lieu of simple descriptors—forcing users to learn the meaning of each new word.”
Leo suggests, “I think the fundamental problem here is your attempt to impose a vocabulary in the first place. A different starting place might be to visit several of your target users, show them Outlook, SQL Builder, or other applications with which they are familiar and which have the kinds of artifacts you are trying to emulate—views in this case—and listen to what they call these elements. As part of your inquiry, you might have users do whatever tasks require them to interact with, create, or manage these elements and hear the language they use when discussing them. This is a very simple method of eliciting the language your population is already using to describe these things.”
“My experience in this area has led me to conclude that, like a rock band’s being unable to predict which song will be their hit, it’s very hard to predict what word will resonate with a user population,” says Paul. “Noun versus verb is the least of your worries. If you want the best way to generate an understandable, effective term, you should—you guessed it—practice user-centered design on the problem.
“Go round up a half dozen users—or people who fit the target user profile—describe or show each of them the functionality—minus the word views, of course—and ask them for their name for it. If they can’t give you just one, settle for two. Then round up four to six more people, describe or show each of them the functionality, and have them choose the most appropriate term from the six to twelve words the first group of users generated. If you get consensus on one word, you’re golden. If users seem to be split between two or three words, you could either choose one word from that set or rerun the second experiment, using the reduced set of words and another four to six people. To answer your second question, no I don’t.”
Pabini offers this advice: “In choosing what terms to use in your user interface, you need to consider two things:
context—What terms do your users use for actions and objects when describing their own work?
standards—What term usage is standard practice either for an operating system or in a product domain?
“There are several ways to make sure your terminology is appropriate to the domain for which you’re designing a user interface. Do a competitive analysis to determine what terms your competitors use in their user interfaces. Follow any terminology guidelines your organization has already established. If your organization doesn’t have a lexicon of terms, you should create one. To ensure your users will understand the terms you choose for your user interfaces, employ user-centered design methods to find out what terms your users typically use in describing their work. One excellent way of doing this is to do an open card sort. For information about doing card sorts, read these excellent articles:
David Malouf also recommends a user-centered design approach: “Do your contextual inquiry or goal-directed design. The vocabulary is there. A short-cut method is to do an open card sort, where you ask several users to sort through the content catalog and give you the answer.”
“When determining what terms to use in a user interface, it’s important not to reinvent the wheel,” continues Pabini. “Use the terms that are appropriate to the platform for which you’re designing. Many terminology guidelines have now been in use for decades and were established through extensive usability testing. Follow them, and you’ll be using the terms most users expect and will understand. Here are some guidelines you should follow:
Whitney agrees with our reader: “Relying on training for something so basic as how to get to the information the software holds is a really bad idea. But you might use this to your advantage. Try running a few usability test sessions in which you include some introductory training material that describes the views concept and how it is used in your software, before asking participants to complete some meaningful tasks. Then, you can ask participants to help you come up with a better label—one that makes sense in the context of your software instead of naming a generalized concept. After all, if you can figure out how to explain views effectively, you can then put that knowledge to work in the software itself.”
UX Roles in Organizations
Q: We are looking to update our UX team to align with advanced needs, and I am having trouble finding an organizational view of UX roles. I am not sure where UX architects, art directors, information designers, visual designers, user researchers, usability testers, creative managers, interactive designers, and other UX roles fit into the big picture. Do you have any examples of organizational layouts?—from a UXmatters reader
The following experts have answered this question:
Steve Baty—Principal Consultant at Meld Consulting; UXmatters columnist
Pabini Gabriel-Petit—Publisher and Editor in Chief, UXmatters; Principal User Experience Architect at Spirit Softworks; Founder and Emeritus Member of Board of Directors, Interaction Design Association (IxDA)
Leo Frishberg—Principal Architect, User Experience at Tektronix Inc.
Paul Sherman—Principal at Sherman Group User Experience; Vice President of Usability Professionals’ Association; UXmatters Columnist
Daniel Szuc—Principal Usability Consultant at Apogee Usability Asia; Founding Member and President of the UPA China Hong Kong Branch
Russell Wilson—Vice President of Product Design at NetQos
The Role of UX
Russell answers, “In my company, the UX department is called Product Design. Product Design is a peer department to Software Engineering and Product Management and, as VP of Product Design, I report directly to the EVP of Products. By avoiding being underneath Engineering or Product Management, UX becomes more strategic, but there can also be some challenges with cross-departmental processes.”
Pabini agrees, “It’s essential for UX to be on an equal footing with Engineering and Product Management within an organization. I discussed the necessity for balance between Product Management, UX, and Engineering at length in my UXmatters article ‘Sharing Ownership of UX.’
“If there is no VP of UX within an organization, the unavoidable consequence is that UX is subordinate to some other function within the organization—usually Product Management or Engineering. This can make it more difficult for UX to successfully represent the interests of users when conflicts arise on product teams. When an organization’s leaders are discussing strategic issues, if UX doesn’t have a seat at the table, the concerns of both Product Management and Engineering can overshadow those of UX. In my article, I described some of the cross-departmental challenges to which Russ alluded and how to overcome them.”
Steve suggests, “I would start by recognizing two general rules of successful UX design:
Get in contact with your users as closely and frequently as you can.
Good people are more important than good structure—which is not to say that structure does not make a difference.
“To address your question, then, I’d be looking to position your staff such that they can make and maintain direct contact with your users. Set up channels of communication and interaction with your user base and remove as many layers of intermediaries as possible.”
“As usual, the answer to this question depends on the organization, the type of work it does, and its relationship to its customers and users,” adds Leo. “In our industrial tools manufacturing company, for example, the role of a UX Architect (UXA) is on par with the Software Architect and Hardware Architect. While we don’t have a reporting structure that puts the UXA above the interaction designers, visual designers, industrial designers, and information designers, the UXA works at a more strategic level with the business managers, marketing directors, and others. The designers work more closely with the software engineers on the implementation of a project.
“In addition to the UXA’s greater visibility at the management level, there is a difference in focus, over time, for any given engagement, as reflected in Figure 1. Figure 2 illustrates the emphasis of each role over the course of implementation.”
Figure 1—Focus over time Figure 2—Emphasis of each role throughout implementation
Leo continues, “In a decentralized organization such as ours, there is a role for central resources, in addition to the resources that are assigned to each business unit. In the central organization, you would find a more agency-style organizational structure, with a director overseeing creative resources shopped out on a project basis.”
“For a detailed analysis of the various business models a UX organization can adopt, read Jim Nieters and Garett Dworman’s UXmatters article ‘Comparing UXD Business Models,’” Pabini suggests.
Building Your Team
Paul has put together UX teams at several mid- to large-sized companies. He says, “Generally speaking, I’ve found that a service-oriented team structure works best. By service-oriented, I mean, first decide what services you are providing your organization, then build around that. For example, at my last big organization—I’m independent now—my team’s mandate was to provide a considerable amount of ideation-phase user research to the product management organization, as well as concept prototyping. Our bread-and-butter work, however, was feature-level interaction design, usability assessment, and visual design. These needs drove us toward this organizational layout:
1 Full-Time Equivalent (FTE) User Researcher
3–4 FTE Interaction Designers or Information Architects
1 FTE Usability Analyst
1 Visual Designer
“Over this group was a single manager and a director who interfaced with the Product Management and Engineering Directors to set strategic direction. This group successfully moved from waterfall to iterative to an agile, or scrum, development process over the course of three years, which taught me that the basic structure seemed to be valid no matter the development process.
“The standard caveats apply, of course. Your mileage may vary, and much of the success of a UX team hinges on having a high-level champion—or ideally more than one—in the business.”
Pabini says, “In my recent UXmatters article ‘Specialists Versus Generalists: A False Dichotomy?’ I described my ideal, small, and nimble UX team, which would comprise a mix of specialists and T-shaped individuals and encompass the following functions: interaction design, information architecture, visual design, user assistance, user research, and front-end development.”
To help you understand how you should structure your UX team, Daniel poses the following questions:
“What roles do you have on the UX team currently, and what do they do? (Assess)
Where is the UX team positioned now, and where do you want the team to be positioned in the future? Are you effectively placed at the moment? (UX Strategy)
How are the UX roles understood by your organizational buyers? (Acceptance)
How is the UX team delivering on work requests now? (Delivery)
How are product teams structured, and how do you want to provide UX service to projects? (Delivery)
Based on the mix you are looking for, how will this impact your current and future hires? (Hires)
How will the UX team contribute to a UX toolkit and strategy to help sell UX into the organization? (Knowledge)
How is each UX team member going to help sell UX into the organization? What is the minimum amount they should know to help grow UX? (Sales)
“In terms of team structure, I suggest it’s optimal to have a smaller team—for example, a team of four people with a mix of design, information architecture, and user research skills, a UX lead, and a developer—with all roles working very closely together toward delivering against a UX promise for a product.”
Russell describes his team: “Within my department, I divide my team into four units: interaction design, visual design, user interface (UI) engineering, and usability. Workflow, interaction design, prototyping, and information architecture fall under interaction design. Graphic design is, of course, visual design. Information design involves both the interaction design and visual design teams. UI engineering is a new initiative. We are building out some of the designs instead of just delivering specifications and prototypes. And usability is responsible for testing, walkthroughs, and proactively suggesting improvements. What is critical is that all of the teams work very closely together and support each other.”
“To the second part of the equation, what your staff are capable of doing is more relevant than their individual job titles or formal roles,” says Steve. “Start by looking—from a project perspective—at what you need to successfully deliver a project within your organization. Look at your current staff and see whether you have any skills gaps, and whether those can best be addressed through training or recruitment. You will also want to ensure you have adequate overlap in core skills. Don’t rely on individuals for any critical project skills. Plan for illness, holidays, and over-commitment. The,n I’d structure the team around the individuals and the channels you’ve set up. Work through a variety of options and see what will deliver best for you.”
Daniel’s Suggested Reading List for UX Roles in Organizations
Colfelt, Anthony. “Building the UX Dreamteam.”Boxes and Arrows, November 27, 2007. Retrieved April 29, 2009.
Rather than “Click here to view your views” (I, too, felt what I would describe as a very mild “douche chill” when I read that), why not just list each available “view” and let the user select the view they want to start with?
“Click here to view your views” (there it was again… what an odd sensation…right near the prostate…) leads me to believe that when I click that link I’m going to be presented with a list of available views, or possibly land on a default view and have the option to bounce between others. It just seems like an unnecessary step. Allowing users to select from a list of data types / view names right at that point would get them to what they need more quickly and without making them pause to interpret that link. Even if your “views” are literally different views out windows in your luxurious hotel, I think you’d be doing your users a favor at that point by just letting them select from a list of links that describe something distinct about each view (even if it is as basic as “east view” or “pool view”).
Is there a reason this wouldn’t work in your situation?
Eliminate the Click here text. The control itself should provide the click affordance, making the click text redundant. (Imagine if all command button text were prefaced with Click here to.)
Try words like perspective, mode, or other dedicated nouns, as a substitute for view. View is overloaded both syntactically and by convention (OS View menu). So you can have X perspective, Y perspective, etc. as a list of choices.”
Provide a thumbnail preview of the view in question—for example, using a “butcon,” or toolbar button. This should make it a no-brainer.
Place the perspective/view controls near other global controls—for example, in the main toolbar. See MS Word 2007 for examples.
[I only scanned the article above. You may find repetition in my reply. It’s actually convergent evolution :]
Dr. Janet M. Six helps companies design easier-to-use products within their financial, time, and technical constraints. For her research in information visualization, Janet was awarded the University of Texas at Dallas Jonsson School of Engineering Computer Science Dissertation of the Year Award. She was also awarded the prestigious IEEE Dallas Section 2003 Outstanding Young Engineer Award. Her work has appeared in the Journal of Graph Algorithms and Applications and the Kluwer International Series in Engineering and Computer Science. The proceedings of conferences on Graph Drawing, Information Visualization, and Algorithm Engineering and Experiments have also included the results of her research. Read More
