00:00:11.840
Hi, my name is Joe Mastey, and this talk is titled 'Bringing UX to Your Code.'
00:00:18.880
As a day job, I help companies build awesome internal education programs to keep their employees happy and engaged. While this talk isn't directly related to that, I wanted to provide some context about my background.
00:00:30.480
I've been working with Rails for five years. About five years ago, I grew tired of consulting and decided to join a company where I felt somewhat overqualified for a backend job, even though my background is in backend development.
00:00:44.320
I applied for a UI job, even though I had no real history in UI design, and surprisingly, they gave me the role. I want to clarify that I am not coming from a designer's perspective; I am not a UX designer or developer. My expertise leans more towards the technical side.
00:00:57.120
Can I get a show of hands? How many people here identify as UI front-end developers? It's a small group. Now, who here considers themselves more of a backend person? That's a majority, and you are actually the target audience for this talk.
00:01:16.798
When I joined my company as a UI developer, I received a bunch of materials for learning, including some books. One of those books was by Don Norman, the founder of the user-centered design movement. He released a book in the mid-1980s titled 'The Design of Everyday Things.' Has anyone here read this book?
00:01:36.880
Surprisingly, a good number of you have. If you've read it, you know it teaches a lot about the usability of everyday objects, including doors. In fact, when I looked it up, it was authoritatively about doors.
00:02:09.119
The book illustrates that if you look at a door with identical handles on both sides, people need labels to show which side to push. I have always assumed that people who struggle with this are just not very clever, but the book made it clear that if you struggle, it's not necessarily your fault. This was an important lesson for me--it’s the design that fails, not the user.
00:02:31.680
There are many valuable usability lessons in the book. It altered the way I approach software development, particularly in the context of websites. For instance, when searching for difficult-to-use websites, I found that only about 20 percent of them are clickable, and you can't tell which 20 percent just by looking at them.
00:03:04.080
However, when it comes to code, we often neglect usability principles. This is especially true for backend developers, and I think I understand why this happens.
00:03:33.840
As engineers, we often overlook two things: first, anything invented a long time ago, and second, anything created by non-engineers. We tend to remake approaches from other fields, especially when it comes to design, which often seems foreign to many engineers.
00:04:16.239
In Don Norman's book, he discusses concepts such as the gulf of execution and the gulf of evaluation. The gulf of execution, in essence, describes how we translate our intentions into actions. For example, if I am new to Rails and want to remove a record from the database, I might not know the correct action to take and look through methods available to find the right one.
00:05:03.080
Often, we get clever and try to use methods based on our previous experiences, yet we can end up confused. In Rails, the method to delete an object is not as straightforward as you might think. For instance, using the delete method can lead to data inconsistency.
00:05:29.440
However, the correct method to use is 'destroy,' which does not align with the conventional naming we expect, leading to confusion for newcomers. This confusion happens because every person who learns the framework faces these problems, which could have been avoided with more coherent naming.
00:06:08.000
When it comes to the gulf of evaluation, it pertains to the feedback we receive after taking an action. For instance, in Ruby, every operation has an expected return type. It's essential to think about the feedback your code provides. When using methods like 'delete,' the feedback does not adequately warn you if you've caused any data corruption.
00:09:06.000
The level of feedback becomes more problematic in cases where your code isn’t executing correctly or if it's in a certain context that doesn't allow for clear return types. In many cases, users might not notice that there's no actual output, which complicates the debugging process.
00:09:54.000
Now, let's talk about natural mappings. A practical example would be a stovetop with four dials laid out in a row, which makes it intuitive to control. However, if that same layout were changed and labels were removed, it would confuse many users. This principle applies to code as well. For example, in Ruby, it is intuitive to use methods like 'sort' or 'first'. However, there are moments when naming conventions can lead to confusion; for example, using 'update' versus 'edit' can lead to misunderstandings in functionality.
00:11:17.040
Another principle to keep in mind is designing for errors. When I'm coding for eight hours, I often find that a significant portion of that time is spent fixing errors. Therefore, it is crucial to design code that anticipates mistakes and allows developers to recover without getting frustrated. I have a daughter, Lane, who is learning JavaScript, and I remember her struggling with an error message that said, 'undefined is not a function.' This vague message is unhelpful and doesn't guide users about the error's source.
00:13:39.360
Exploiting the power of constraints is another important principle. If there's a correct way to execute an action, make it easy to do. For example, MySQL has a flag that prevents the deletion of records without a proper condition in place. This is a great way to avoid accidents that could lead to significant issues, especially when one is coding under stress or fatigue.
00:14:53.840
We also need to consider the emotional response we have with the software we use. When there’s an emotional connection, it can greatly enhance our experience. Writing code that feels good to work with is essential. Ruby, for instance, has embraced this principle by making the language easy to read and enjoyable to write, contributing positively to the developer experience.
00:16:45.440
To conclude, I want to recollect on these two basic tenets: avoid jargon and help users understand quickly. For example, a confusing name like CSRF isn't widely understood, and using language like 'protect from forgery' is much more intuitive. Knowing your audience and ensuring they understand your code is key to good design. The goal is always to reduce cognitive load when working with any software.
00:19:03.840
In closing, the world already contains enough complexity so let's strive to make things easier. Good design principles aren't just for UI; they apply directly to the code we write. No matter what code we write, it should be written with the same usability principles in mind that we apply to our user interfaces. Thank you!
