Posted On: 2019-06-24
User Experience Design is a fascinating topic to me: the idea that the user's experience of a product is more important than the actual functionality of the product seems (to me) to be self-evident, but a lot of energy and thought has gone into explaining why, so I assume it must not be as clear to some people. Additionally, much of the discussion has been focused on end-users, but not as much has been said about how its principles apply to the design of non-user-facing systems (though I am aware of at least one excellent blog about considering an API user's experience.) This seems unusual to me, as I typically try to consider the experience of end users, fellow developers, QA, and even my future self whenever I work on a project. In light of this, I thought I should write my thoughts about User Experience, as it seems my perspective on it might differ from others'.
As I understand it, User Experience is about the internal world of a user as they interact with a product or service. This includes everything from affective states (is it enjoyable to use) to the mental model they use to represent their understanding (ie. pushing a button will cause a certain change.) Regardless of reality, the actual experience a user has will determine their relationship with the product. If it is difficult to use, the relationship may be strained. If they have an inaccurate mental model of what it is doing, they may experience anxiety or cognitive dissonance when they discover what really happened. (As an example, imagine a user donating "1.00" dollars to a charity, but when the server goes to process it, it strips out all punctuation and processes a donation of "100" dollars.) Regardless of the reality of what the product is actually doing, a user's experience will determine what, if any, value they get from using it.
What's perhaps most interesting to me is that User Experience is just as important for software as it is for conversation. As a very relevant example: as I type this blog post, I am making an effort to express the information clearly, but I am also considering how you, the reader, will perceive it as you read it. I could put a bullet point before each individual word
The study of Rhetoric is in many ways the study of the User Experience of communication. While in many cases it's described as a way to persuade or influence others, many of the principles can be just as easily used to alter the listener's experience to overcome communication obstacles inherent to the content. For example, whenever I give criticism, I try to both lead and end with something positive. This is because the user experience of receiving criticism is (usually) unpleasant, but I want the experience to be positive and uplifting. My goal is not to influence the person, rather it is to make sure the listener is experiencing the same helpful tone that I am trying to communicate.
When you consider that all communication has a User Experience component, I hope it becomes clear why it seems so natural for me to think of the user experience everywhere in development. Everything from the names on the database columns to the amount of time it takes the application to first load communicates something to someone. When another developer first sees my code, it is unfamiliar (possibly strange) - if I want them to understand it and use it, then my best bet is to make sure that first impression is a good one: name things clearly, include comments, use comfortable amounts of whitespace, and otherwise generally make it "maintainable."
To return to the idea of a User Experience mattering for the end user: the end user is often the customer of the product (ideally paying customer, but important either way.) As such, communicating effectively with whatever you have (product, promotional materials, website, etc) is extremely important, and it is often the full-time focus of entire teams (marketing/sales/etc.) In light of that, it seems understandable that this is where popular focus on User Experience first emerged. Considering its pivotal role in all forms of communication, however, I have been somewhat surprised that I seldom hear about it outside of end-user-facing work. Perhaps this post can be (one of) the first to test those waters?