My UX process begins first and foremost in attempting to understand what problem needs a solution. This is, perhaps, the largest “problem” in UX – understanding/defining the problem.
Understanding the Problem
All too often, I have had a client come to me expressing they need a website or an application built to allow them to do X task. The problem with this scenario is the client often has a very poor understanding of their needs or they are not very good at expressing their needs. The needs of the client are often the equivalent of their problems. Good design seeks to solve a problem. Sometimes this problem is simply a matter of automating a process so that what was once done on paper can now be done via computer quickly. Other times, the process might not improve with the implementation of technology. In many cases, the implementation of technology forces the user to enter data into a system, for example. This method is usually not quicker than entering the data with pen and paper (pen and paper is a pretty nifty invention we have had trouble eradicating over the past few decades). But the ability to enforce validation rules and ensure more rigid data entry is often worth the sacrifice for the end-user. As an example, I am working on a project right now where the problem is ensuring we have good data in the system. That is the problem we are trying to solve. This has resulted in creating a system for product entry and tracking. It is not as easy to use as the old method with Excel spreadsheets. But the problem was not to automate a process so the user has an easier time entering data. In this instance, the problem was the user entering sloppy data.
Locating the problem(s) needing to be solved is the first stage in my UX Process. This often involves ethnographic observation where I become immersed in the user’s world to understand their daily life and challenges. This is a technique I learned in my experience as a journalist years ago and I still use the same techniques in observation, interviewing and helping users effectively communicate their needs. This is termed as user research and there is a dearth of it today in the UX field. I know many designers who never speak to a user and I have left more than one position as a result of this strange phenomenon. I call it strange because UX stands for User Experience and I am astounded at how often the user is mystery as the design process is carried out.
Designing the Interface
Once the research is completed and the data has been trended, I begin brainstorming interface designs. This is largely an experimental process where I iterate through many designs and proposed solutions to the problems. Early in the process I being showing ideas to the clients and my colleagues. This, I find, brings about a certain synergy of ideas where we often are able to collaborate and achieve a better design as a result of our interaction. This is, perhaps, the longest part of the UX process for me. It is also the most rewarding and frustrating. I enjoy working through the problems and finding the solutions. But this process is a creative one that takes time. And every project I have ever worked on involves time constraints. Thus there is this constant tug of war on every project to build the best interface in the least amount of time.
Testing the Interface
Ideally, each and every project would allow me to test an A/B design with the client’s users. But, I won’t lie to you. User testing is time consuming and can be very expensive. The long-term benefits are clear to me. But convincing the client of the benefits of user testing is not always the easiest thing to do. Sometimes testing has to be done on the fly. Other times, there is not enough time to develop two types of designs for A/B testing. I have worked on projects where I only had a few users I could do a cognitive walk-through with and other projects where I had a number of users to test multiple designs with.
Testing your design is a must. And in every project, I strive to be as thorough as possible (and as thorough as the client will allow) in testing. Testing the design can be an iterative process in itself where you move through several design improvements and test multiple times. The key to the testing process is the 80/20 rule where we are trying to identify the 20 percent of the design problems that will cause the user 80 percent of their frustration.
Following Through
Once the interface and design are handed off, it is easy to think you are done as a designer. There is still a process of working with the developers and helping them understand the functionality. It would be nice if specification documents could clearly communicate everything. But unfortunately, that is an impossibility and you will have to communicate several time with the developers to ensure your design work is being implemented appropriately.