Developer Experience (DX)

Summarized using AI

Bringing UX to Your Code

Joe Mastey • May 14, 2015 • Atlanta, GA

The video titled 'Bringing UX to Your Code' features Joe Mastey discussing the application of user experience (UX) principles to code design. Mastey, who has background in backend development and UI, emphasizes the importance of extending user-centered design principles to the code we write.

Key points discussed in the video include:

- User-Centered Design Overview: Mastey highlights that user-centered design has been around for nearly thirty years, shaping how we build interfaces but often neglecting code usability.

- Personal Journey: His transition from backend developer to UI developer illustrates the challenge of merging technical skills with design principles.

- Understanding Usability: Drawing from Don Norman's 'The Design of Everyday Things', Mastey shares insights on usability through examples like confusing door handles, stressing that usability issues often lie in design rather than user error.

- Gulf of Execution and Evaluation: He elaborates on the gulf of execution and evaluation, explaining how names of methods in coding (like 'delete' vs. 'destroy') can cause confusion for new developers.

- Natural Mappings: The need for intuitive design in coding is explained through practical examples, such as how the layout of stove controls can enhance usability, paralleling this with code naming conventions.

- Designing for Errors: Mastey emphasizes the necessity of anticipating developer errors and providing clear error messages for better debugging experience.

- Emotional Connection with Code: He discusses cultivating a positive emotional response from developers through readable and enjoyable code, citing Ruby as an example.
- Concluding Principles: The talk concludes with the principles of avoiding jargon and making code understandable, reinforcing that good design transcends user interfaces to encompass all code.

The overarching takeaway from Mastey’s talk is that applying UX principles to code can significantly enhance developer experience, akin to improving user experience in interfaces, ultimately leading to better quality software.

Bringing UX to Your Code
Joe Mastey • May 14, 2015 • Atlanta, GA

By, Joe Mastey
User Centered Design as a process is almost thirty years old now. The philosophy has permeated our products and the way we build our interfaces. But this philosophy is rarely extended to the code we write. We'll take a look at some principles of UX and Interface Design and relate them back to our code. By comparing code that gets it right to code that gets it desperately wrong, we'll learn some principles that we can use to write better, more usable code.

RailsConf 2015

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!
Explore all talks recorded at RailsConf 2015
+122