Collaborative Interaction Design and Specification
Published: January 21, 2013
In this article, I want to propose a new UX term: Collaborative Interaction Design and Specification, or CIDS. But first, it would be helpful to provide some background on how and why I came to invent this term, starting with a few words about communication and user experience.
Communication and User Experience
Those UX professionals who have a psychology background or have read seminal works on human communication such as Grinder and Bandler’s The Structure of Magic 2: A Book About Communication and Change know that interpersonal communication is key to virtually all endeavors that involve more than one person. But interpersonal communication is a difficult and complex business. Paradoxically, many seem oblivious to this fact, ploughing on regardless through an unending stream of miscommunications in both their personal and business lives. Or maybe it’s precisely because we unconsciously know just how difficult accurate communication is that we often seem reluctant or unable to address communication issues.
I can provide a potent example of this from my own recent experience as a Lead UX Consultant, working on a major project for a blue-chip multinational. The UX designers, business analysts, developers, and senior stakeholder had been going around in circles for several weeks regarding the information architecture for some secondary navigation. I eventually realized that the root cause of the problem was that different stakeholder groups had vastly different understandings of two key terms that we were frequently using in our discussions. What these terms were is not important here. Rather, my point is that a 10-minute conference call, during which we agreed on the definitions of these terms, unblocked the design process, with the result that we could agree on an initial information architecture for the secondary navigation in about half an hour!
This example makes it easy to see how poor communication can waste time—and therefore, money—and can lead to poor system-design outcomes. Unfortunately, I believe that the profession of user experience, in particular, suffers disproportionately from a range of miscommunication issues. Indeed, my UXmatters article “UX Defined” arose from my belief that, as UX professionals, we have been unable even to define and, therefore, communicate what exactly it is that we do!
Devising Clear Terminology
Motivated by the rationale that agreeing to key terminology is a prerequisite for good communication, in that article, I sought to make progress by clearly defining the term user experience. Even if we can’t all agree on the meanings of key terms, at least debating them in magazines such as UXmatters will help make us aware that the terms we use may well mean different things to different people—both UX professionals and people in the other disciplines of software development.
In keeping with this rationale, in this article, I’ll address what I believe is significant confusion around the following key UX terms: wireframing tools, prototyping tools, and design tools.
Wireframing, Prototyping, and Design Tools
My second example concerns a large-scale software-development project. As is common for such projects, it was running behind schedule and over budget. The client’s procurement team had become nervous about continuing the project’s funding and were demanding to know what they would actually be getting for their money. So the vendor’s senior-management team asked a couple of top Axure prototypers to model the system and, thus, help to reassure the client. The Axure guys did a great job, working around the clock, and three weeks later they delivered a high-fidelity prototype that was fully complaint with the client’s brand style guide, modeled several of the key routes through the system, and included some of the whizzier drag-and-drop interactions and animated carousels.
“That’s fantastic,” said the client’s IT Director. “I’m amazed by how much progress you’ve made. You’re clearly almost there. When can you hook the application into our central data base?” The vendor’s project manager explained that this was just a prototype, and there was still a long way to go. “Sure,” said the IT Director. “I know you have to add a lot of the detail, but the core development is nearly done.” After several more fruitless exchanges, the conversation ended uneasily with the IT Director saying, “What do you mean there is no working code in what we just saw? We don’t understand. It looked so good!”
After reflecting on these experiences and the apparent confusion around terms, my initial thought was to attempt to define the terms wireframing tools, prototyping tools, and design tools, as well as to categorize common UX tools under each of these terms to form a taxonomy. But I quickly rejected this idea for three reasons:
- However I might define these terms, there would inevitably be a high degree of overlap across them because the tools overlap so much in their purposes.
- Any definitions would, no doubt, be highly debatable, even controversial.
- Most important, I am convinced that distinct wireframing, prototyping, and design tools have no place in the future of user experience! Therefore, defining such a taxonomy would ultimately be a redundant exercise. Rather, I believe that what I have previously termed fourth-generation prototyping tools is the future of interface design tools.
Therefore, I’ve decided simply to attempt to clarify my definition of the term fourth-generation prototyping tool, which I introduced in my UXmatters article “(Why) Is UXD the Blocker in Your Agile UCD Environment?” and explained more fully in my UXmatters article “Are You Still Using Earlier-Generation Prototyping Tools?”
Collaborative Interaction Design and Specification Tools
The MUDS (Management, Usability testing, Design, and Specification) criteria that I used to evaluate interface design tools in the latter of these two articles has led me to call fourth-generation prototyping tools Collaborative Interaction Design and Specification, or CIDS tools—pronounced like kids. Present examples of CIDS tools include iRise, Axure, and Prototyper.
C = Collaborative
It is a given for me that good UX design typically embodies a true user-centered design (UCD) process. Since UCD is multidisciplinary and seeks both user and stakeholder feedback in an iterative manner, CIDS tools must be collaborative and
- allow multiple people to work simultaneously on the same design. This implies that CIDS tools must include features for data-integrity management and revision control.
- provide an integrated and structured way of gathering and collating user and stakeholder feedback
- include library features for documenting, managing, and sharing interface-design components, including design patterns, across a team of UX professionals
I = Interaction
In keeping with the critical role of UCD in UX design, CIDS tools must also be capable of modeling the key interactions that developers will implement in the final software, making it possible to conduct reasonably realistic usability tests and allowing stakeholders and focus groups to get a good sense of what the software will be like.
D = Design
CIDS tools must be capable of producing pixel-perfect screen layouts like those that designers typically produce using tools such as Adobe Photoshop and Fireworks.
S = Specification
CIDS tools must be capable of both internally storing and outputting all of the specifications that developers need to code a user interface. Possible outputs for specifications should include
- printouts—These specifications comprise both images and text and are similar to the design artifacts you can produce using tools like Visio and OmniGraffle.
- Web pages—Once you upload the pages to the cloud, people can view your specifications using any Web browser, so they need not have the CIDS tool you used to create them.
What Don’t CIDS Tools Need to Do?
Now that I’ve provided a definition of what CIDS tools must do, it’s equally important to define what they do not have to do. I’ll do this by posing and answering five key questions.
Must CIDS Tools Be Capable of Creating All of the Graphic Elements for a Visual Design?
No, this would be neither a realistic nor a necessary design goal for CIDS tools. However, a CIDS tool must allow designers to
- lay out pixel-perfect screens. Therefore, these tools must be able to import or link to graphic elements that originated in graphic design tools such as Adobe Illustrator, Photoshop, or Fireworks, as well as various specialized applications for icon design, text generation, and button design. There is no need to reinvent the functionality of these powerful tools. We just need to be able to use graphic elements that we’ve created with such tools in better, more comprehensive interface design tools.
- provide documentation for graphic elements
- store and manage graphic elements in a library
Must CIDS Tools Be Able to Produce Low-Fidelity, Grayscale Designs?
Yes, because producing such designs is often important in the UX design process.
Must CIDS Tools Be Capable of Fully Modeling All of an Application’s Interactions?
No. Again, this would be neither a realistic nor a necessary design goal for CIDS tools. In most cases, it would be possible to model such functionality only by producing a prototype using the target development environment. Thus, to completely accurately prototype most iPhone apps, you would need to produce a prototype using the Xcode IDE in the iOS SDK.
Instead, CIDS tools must be capable of modeling, or simulating, an application’s key functionality at a reasonably realistic level to enable usability testing and demonstrations to stakeholders and focus groups.
To get a sense of what I mean by this, consider the springboard in Android 4.0. Swiping between its pages produces a fancy, 3D transition effect that was implemented using Android code libraries. While this effect arguably adds to the user experience, a CIDS tool would need only to let a user swipe between pages and display a simple transition effect. However, the CIDS tool would also need to let a designer specify that developers should implement the 3D transition effect in the final software.
Of course, what a “reasonably realistic level” is will always be a matter of opinion. At present, we may have to live with the reality that no complex definition is 100% unambiguous. Also, while subtleties like transition effects might marginally influence satisfaction scores in usability tests and the results of focus group and stakeholder demonstrations, we would, in most cases, willingly accept this limitation in trade for the speed with which CIDS tools let us simulate key functionality and the massive benefits that this brings.
Do CIDS Tools Need to Produce Working Code?
No. While some CIDS tools attempt to do this, most produce disposable code. Though this may be contrary to what we might think we’d want, producing disposable code is typically the preferable strategy for both vendors and users of such tools. Because there are so many different development environments that developers might use to implement our designs, tools that produce working code must inevitably target just one or, at best, a very limited number of development environments. Thus, tools that target particular environments often lack sufficient flexibility.
Must CIDS Tools Be Able to Fully Simulate All Applications for All Platforms?
No. Some CIDS tools are platform specific, while other CIDS tools aim to be highly flexible, supporting design for a wide range of applications and platforms. For example, some might support Web, desktop, and mobile, while others might target just native apps for a particular mobile operating system.
As far as I am aware, there are no CIDS tools that support all types of applications and platforms, so a tool might qualify as a CIDS tool in one context, but not in another.
In recent years, the UX profession has benefited from a new generation of what I have termed CIDS tools. I hope this article helps you to avoid confusing these powerful, new tools with the limited tools of the past.
Grinder, John, and Richard Bandler. The Structure of Magic 2: A Book About Communication and Change. Palo Alto: Science and Behavior Books, 1976