If you read the range of articles out there written on the subject of User Experience Design (UXD), you’ll find varied opinions about what it is in practice. Some say UXD is just about user studies and research to gather actual user data that will inform the design process. Some say the “UX” is about what users feel when they experience a product. Pretty much all of what experts write about “UX” is true, depending on what sort of product is being developed.
There are products with good user experience and products with bad ones. The bad ones are typically not that usable, and, frankly that’s what makes them bad. UXD refers to the processes that go into making a usable product. And, they are not all made equal. Not every option in the process is right for every product. The point is to get to know about The Users—whether hypothetical future users or concrete existing ones—and think about the needs of these users to achieve a design that is not only usable but superior, intuitive, easy, friendly, and functional, among the many other objectives that can exist for a product. These factors play a role in design decisions about how the product will behave and how the users interact with it, as well as how the interface is organized and what it looks like or what it’s made up of.
Some say the field of UXD is “New”. If you think about this, it’s sort of silly. People have been designing products since the Stone Age when the first tools were created. Over time, the tools are tested, flaws are found, and improvements are made. It’s in the nature of Man to improve upon a design. And, in the field of Software Design, both designers and developers are forever working toward making the products they work on usable. So what is new about this?
What’s new is that, as technology is evolving, the field of software and product design is taking the importance of this more seriously, and making space for it formally on the typical design team—hence the extensive search for UX Designers that is being conducted across the Western world today. And, the people charged with this are sometimes having trouble figuring out what they need.
Okay, here’s the skinny. There are many UI Designers and Developers out there that have had to work on projects with little or no information about who will use the product. They, or that is to say, we, rely on the knowledge of our trades, the standards within the metaphor or medium we are designing for, the many best practices that are written about, our experience designing and developing other interfaces, and a range of heuristic studies about user practices, as well as instinct and whether or not we find the product usable ourselves. But, there is more we can do to validate what we believe about what makes a product usable. And, this is where UXD processes can come in handy.
Figuring out what makes a product “usable” is in most cases not best left to the arbitrary decisions of one individual. And, whomever is charged with creating the designs and plans for what the product’s experience and interface will be like should be as informed as possible about the users’ needs. This is not new. User-Centered Design philosophies have been commonly used in Software Design for some time now.
So how does this all translate into practice? Each project I work on needs careful attention to decide what aspects of UXD are going to help make the design product great. As a UI/UX Designer, I consider myself a User Advocate. My job, aside from meeting the needs of a client and the project team, is to speak and act for The User so that I can create a product they will absolutely love to use. So, I want to have an idea of User Scenarios and Stories—who are the potential users, what are their habits and needs surrounding how they will use this product, and also importantly what will they not want this product to do and what would they find annoying, so I can exclude those behaviors from the product.
For new products with no existing user base to work with, fictitious User Personas can help fill the gap. And, there are a number of techniques from the UXD Process arsenal which can be employed to explore user needs when there are no user yet. I need to look at what the product is going to do and then look at how the users will want to accomplish that. And, for a product that is being designed for a particular group of people, User Studies can be really helpful because they can provide a snapshot of user practices to take into consideration. I might discover that there are real needs that no one on the product team has thought about yet, and this creates an opportunity to make the product more usable for the widest segment of users.
I also might want to validate my design choices with Usability Testing. Whether there is an existing user base or not, by the time I have a semblance of the interface for a product, I should also have enough an understanding of typical users to create some sort of prototype and run usability tests as a field study with individuals who fit those profiles. Running usability testing during the design process can make a significant contribution to the product in the revision phase by bringing in user data and basing decisions on more than just the opinions from the team. But, many clients see this as a non-essential expense. They trust their instincts and the instincts of the team (that’s why they hired us, after all), and plan to run tests later after the product is in the marketplace, then iterate on the design for their ever-evolving product.
So, again, what makes UXD “new”? Many of us have had to design for a lot of projects with informally gathered and scant impressions about who The User is, and, the field as a whole is understanding that formalizing the UXD processes creates a better focus on who The Users are.
Whether or not a project needs a single person dedicated to UX Design and a single person dedicated to UI Design varies depending upon the size and scope of the project. For large organizations that have very formal processes, this might be effective. For smaller or shorter projects, having a single person charged with UI/UX Design can be more efficient because ultimately this work is all for a single aim—a great interface design. And whomever is charged with this role needs to understand that, in addition to considering The User, the entire team plays a part in the UI/UX Design process—the stakeholders, the designers, the managers, the developers, and anyone else working on the product. Each individual has an expert focus that adds to the big picture of what it takes to make the product great. It’s the Designer’s job to synthesize all this expertise into a really elegant solution to the problems and challenges faced in making the product excellent.
So, what’s my answer if you ask me what UX Design is? It’s designing the experience the user will have with your product, but, tell me about your product so I can tell you what UXD will mean to you.
Spot the Vulnerability: Loops and Terminating Conditions In memory-unsafe languages like C, special care must be taken when copying untrusted data, particularly when copying it to another buffer. In this post, we\'ll spot and mitigate a past vulnerability in Linux\'s...