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
Let’s draw upon two other real-world examples. My first example concerns the many LinkedIn groups relating to user experience, with their plethora of discussions on topics such as “What is the best prototyping tool?” “What are your favorite wireframing tools?” and “Take a look at this brilliant new mobile UX design tool.” Despite the repetitive nature of these posts, they typically prompt a frenzy of advocacy for particular tools—ranging from paper and pen to coding in HTML/JavaScript and from Adobe Photoshop to Axure. Inevitably, someone eventually posts a comment like “I think Visio is more of a wireframing tool than a prototyping tool” or “Axure is not a design tool because it can’t do leading and kerning.” Therein lies the problem! What exactly are wireframing, prototyping, and design tools? How do these tools differ? Is it even necessary to make any distinctions between these classifications of 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?”
