..' }

No Section...

VIII.2 March 2001
Page: 33
Digital Citation

Industry briefs: Cadence


Authors:
Scott Joaquim

back to top  Philosophy of Design

Cadence provides electronic design automation (EDA) software tools used mostly by Electrical Engineers (EEs) to develop chip circuitry for such products as microprocessors, wireless phones, and many other complex electronic devices. The Cadence Usability Engineering Team consists of eight full-time staff and a manager; the group is part of the Research and Development Organization. The Usability team works on product development across several divisions and numerous projects; we work at various levels ranging from heuristic evaluations to full user interface design. Until recently, we generally worked on projects to improve parts of existing applications developed several years ago or obtained in company acquisitions. Since Usability Engineers (UEs) are not typically versed in EDA, we must work closely with EEs to understand user needs. Our customers have loudly applauded the results of our contributions, and we now enjoy strong backing from the R&D Vice President, as well as many development teams.

back to top  Design Process

Usability is not currently part of a formal software development process here at Cadence. Within the Usability team, we strive to follow the typical Usability/System Engineering process of functional requirements definition, identification and clarification of user tasks, and iterative UI design development. Of course, we try to test our concepts with users wherever and whenever we can. However, project scope, stage of the product development cycle, schedule, and user availability greatly impact the process we use. Our goal is to be involved as early as possible in product development; however, our process allows for flexibility so that we can make a contribution (although potentially limited) at any time. Minimally, we have performed heuristic evaluations late in the development cycle to rectify obvious errors in the user interface. At the other end of the spectrum, we have been continuously involved from the beginning of product requirements definition and have followed through with customer feedback and iterative improvements after product delivery.

back to top  Design Project Example

Two years ago, the Cadence Usability Engineering team was given an uncommon assignment: design from scratch the user interface (UI) of a new forms-based software application combining the functionality from two existing applications. There were a couple of catches, however. The entire design—main application window, menu structure, dialogs, and interactive features—had to be completed in half the time that it previously took for a significantly smaller project, and customer accessibility, as is typical in the EDA industry, would be sporadic. With only three UEs available to work on the project, we needed to find an approach that would quickly yield a huge set of UI designs that were nevertheless rooted in an understanding of our users.

Our solution was to assemble a cross-functional team consisting of four product engineers (PEs), one technical writer, and ourselves. The PEs and the technical writer served as our "internal experts," people who, either through extensive customer contact, or through previous experience as electronic designers themselves, were knowledgeable about user goals and requirements. In addition, they performed much of the actual UI design work with us.

The team's first task was to identify the high-level functions and derive the menu structure, which would later provide the context from which to think about other aspects of the UI. The first several meetings resembled conventional focus groups, as the UEs facilitated an analysis of the functionality to be included in the new product. Using index cards covering the walls of our lab, the menu commands of the two existing products were systematically examined, consolidated, or eliminated. This process alone reduced the total number of commands from 458 to 117. Ignoring the existing product menu headings, we then stepped through typical user task flows, identified commands required for each task, and grouped similar commands. After a few sessions, command groupings with readily identifiable headings emerged to become the basis for the new menu structure. A subsequent usability test confirmed that users could easily find most commands in the menu structure; adjustments were made accordingly where they could not.

Next we embarked on the most extensive phase of the project—defining the detailed product requirements and designing the numerous forms corresponding to the menu commands. To divide the labor, each member was assigned forms for which they were primarily responsible. In non-meeting time, members were required to systematically gather user and requirements data (using a set of questions developed by the UEs) from whatever sources were available and to draw up first drafts of their forms based on the data. In team meetings, the functional requirements were reviewed, and each UI design draft was reproduced in Visual Basic and displayed on a large screen in our lab using an LCD projector. As design issues and alternatives were discussed, a UE prototyped them on the fly in Visual Basic. The rapid, high-fidelity visualization of design ideas enabled the team to compare and evaluate the designs quickly and effectively, revamping each design as needed until a general consensus was reached. Where opportunities arose, we validated our assumptions and reviewed our designs with real users, either through testing or customer interviews.

Figure.

Reviewing each form and its associated functionality, one by one, did turn out to be time-consuming: The team convened about six hours a day, three to five days per week, for over a year. Some people outside the team were concerned that our approach was an inefficient use of eight people's time and that we were "designing by committee," predisposing ourselves to end up with a motley collection of designs with unnecessary compromises and inconsistent styles. They also wondered how eight people trapped in a dimly lit room everyday for hours could manage not to kill each other.

Yet we believe that this unusual approach (for Cadence) enabled us to accomplish exactly what we aimed to do: produce a usable, quality set of user interface designs for a complex product within an aggressive schedule. This process provided the PE's with a useful, structured approach to the review of functional requirements, and the UEs with ready access to reliable information about user needs. We believe the resulting process actually took less time overall than each discipline working independently. Far from producing a motley collection of forms, working together so closely for so long led us to develop a common UI style that lent itself to product consistency. And when we wanted to kill each other, we simply stepped out for some ice cream.

Two years later, as the product, Integration Ensemble (Fig. 1), is being released to customers, early feedback about the overall organization of the UI (including the menu structure and forms) has been positive. With our success on this project, we anticipate similar opportunities to participate in major design efforts early in the product development cycle in the future. Meanwhile, the other members of our cross-functional team have become not only staunch usability advocates, but people capable of making valuable contributions to future UI design efforts—a welcome adjunct to the Usability Engineering team.

back to top  Author

Scott Joaquim
Senior Member of Technical Staff
Usability Engineering
Cadence Design Systems, Inc.
Tel: 408-944-7456
joaquim@cadence.com

back to top  Figures

F1Figure 1. The user interface designed by the Cadence Usability Engineering team.

UF1Figure. tempcap

UF2Figure. Scott Joaquim

back to top  Sidebar

Job Titles of Usability Professionals at Cadence:
Member of Technical Staff, Member of Consulting Staff, etc. Beyond the corporate job titles, the members of the Usability team are referred to as Usability Engineers and/or Human Factors Engineers.

Job Qualifications:
Advanced degree in cognitive psychology, human factors engineering, or human computer interaction and at least five years experience in user interface design in a software product development environment is highly desirable. Additionally, qualified individuals have strong organizational skills, the ability to multi-task in a fast-paced software development environment, and the ability to work effectively within a team environment in a technically challenging software development product set.

back to top  Sidebar: Practitioner's Workbench

Favorite Publications:

  1. Alan Cooper. About Face: The Essentials of User Interface Design.
  2. Jakob Nielsen. Usability Engineering

Tools Used for Designing UI's:
Predominantly Visual Basic; also Toolbook

Favorite Quote:
"You know you have achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away."--Antoine de Saint-Exupery

back to top 

©2000 ACM  1072-5220/01/0300  $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 © 2001 ACM, Inc.

Post Comment


No Comments Found