00:00:21.439
Thanks for coming! My talk is called 'Walking a Mile in Your Users' Shoes.'
00:00:28.789
The first thing I want to do is introduce myself real fast. My name is Jameson Hampton, but you can call me Jamie. I'm here from Buffalo, New York, which is the home of bad sports. I'm really pleased to be here. I love RailsConf; this is my third time attending, and it's my first time in Minneapolis.
00:00:42.239
I'm representing AgriList, the company I work for. While I jokingly refer to myself as a professional plant licker, I am actually a software engineer. I'll talk more about AgriList later, but for now, I'll just leave it at that. I'm also representing Greater Than Code, the podcast I co-host. If you haven't heard of it, it's great—though it's about tech, it emphasizes the people behind the tech, which we think is really important.
00:01:00.500
If you've heard of Greater Than Code, that's great! If not, I encourage you to check it out. We're having a Birds of a Feather discussion with some of the panelists from Greater Than Code today at 3:30, so consider attending if you're interested. You can also find me on Twitter at @JamieBash. I love Twitter, so feel free to live-tweet my talk. One thing I want to mention is that I use they/them pronouns, so please keep that in mind when discussing me publicly.
00:01:13.020
When I started preparing this talk, I reflected on the traits typically associated with programmers or those that contribute to being a good programmer. When I was in my introductory computer science course in college, my professor shared that good programmers tend to have two defining traits: the first is a fear of bugs and the second is being lazy. I found it amusing that he suggested laziness could be a good trait. However, upon contemplation, I realized that laziness can indeed make us effective programmers. We strive to write reusable code instead of repeatedly rewriting the same functions; we craft scripts to avoid tedious manual tasks. This tendency drives us to work efficiently, as we aim to minimize unnecessary work.
00:01:56.300
Despite the benefits of laziness, it’s important to acknowledge its flipside. Sometimes, as programmers, we forget that what we create isn’t necessarily as easy for others to use as it is for us. Not everyone can simply write a script in place of an arduous task. We often incorporate these solutions into our workflow, forgetting that these workarounds are not the 'real thing.' Thus, I propose a third essential trait for programmers: empathy. This talk centers around user empathy. But what does that truly mean? Empathy is defined as the ability to understand and share the feelings of others. While researching empathy, I learned there are broadly three types: social empathy, cognitive empathy, and empathetic concern.
00:02:41.100
Social empathy refers to sensing how others feel, though that won’t be the focus of today’s talk. Cognitive empathy, on the other hand, involves awareness and understanding someone else's perspective. This is where the phrase 'walking a mile in someone else’s shoes' comes from—truly understanding their viewpoint while communicating in a manner that is easily understandable to them. Lastly, empathetic concern encompasses acknowledging when something is wrong and having a desire to help resolve it.
00:03:11.500
While I deeply value discussions around feelings, today's focus will be more on real-world applications, particularly in the realm of technology and requirements gathering. I want to explore what it means to work in tech and perhaps more importantly, what differentiates a technologist from someone simply working in the tech industry. Code is code, and once you know how to code, you can contribute to various industries.
00:03:31.740
My background in software engineering allows me to serve as a technologist across different industries, including agriculture, which I will discuss today. In fact, the hard skills required are often similar across industries. The privilege to choose which industry to work in is significant because it enables one to find fulfilling roles that matter. However, some might ask, 'If code is code, why does industry matter? What's the difference?' My answer is simple: it’s about understanding the user base you are programming for.
00:05:10.840
Consider Stack Overflow as an example. They conduct an annual developer survey that provides in-depth data about their demographics. However, it’s essential to acknowledge that many of the statistics I will discuss highlight issues—some of which could easily be the topic of an entire talk. For instance, the user demographic is overwhelmingly male and primarily white. The age demographics reveal that a significant portion of users are between 25 to 34 years old, which contributes to shaping the Stack Overflow user experience.
00:06:27.130
Additionally, one data point I found intriguing pertains to parental education levels. This privilege of growing up in a middle-class environment often correlates with access to technology and education. Reflecting on these demographics leads us to an essential question: what do we notice when we examine these statistics? Many may resemble our experiences, yet, as a gender minority in technology—according to the statistics, I'm part of less than 1%—I don’t necessarily relate entirely to the overarching demographics. If our users reflect our backgrounds, we might think the technology we create will intuitively resonate with them. But what happens in case of disparities, like the industries I work within?
00:07:06.490
For instance, in agriculture—and as I’ve noted, my experience has distinguished the tech industry—I discovered compelling disparities. The data from the 2012 Department of Agriculture census indicated gender diversity issues but revealed progress in terms of female farmers. Additionally, the racial and ethnic diversity trends are evolving, albeit slowly compared to the tech industry. Furthermore, the age range among agricultural professionals tends to be broader, influencing how they interact with technology and internet access.
00:08:17.900
Encounters with unique circumstances during my work made me realize that not everyone can effortlessly adapt to digital tools. I realize I’ve referred to our users multiple times as 'users,' which is a critical consideration. A common tweet that resonates with me states, 'Don’t replace people with abstractions. They’re not users; they are individuals using your tools to do their jobs. The web isn’t made of content; it’s a collection of human ideas.' Basing our discussions on empathy significantly enhances our understanding of what those human ideas and needs actually are.
00:09:35.130
Let me share an example to illustrate this. A project I previously worked on, called MetaCap, was developed to aid in prosecuting sexual offenders in third-world countries. Commissioned by an NGO, Physicians for Human Rights, the app aimed to streamline the reporting of assaults, solving the problem of reporting under difficult conditions. This app would allow doctors to record examinations in a way that was admissible as evidence without subjecting survivors to repeated invasive procedures.
00:10:12.130
My experience working with MetaCap led me to encounter numerous challenges—chief among them being privacy concerns regarding sensitive medical data. We designed a system where medical examinations would be stored securely and tracked to maintain the chain of custody, ensuring that proper records were available. However, I soon discovered that the app would primarily be used in regions with limited reliable internet access. Thus, we had to develop it to work offline and sync data when users regained access to the internet.
00:11:07.960
The most striking realization came when I had the opportunity to visit the Democratic Republic of Congo, where the app would be launched. Spending time with NGO staff and doctors revealed numerous unanticipated challenges due to the lack of resources—such as reliable internet and even basic electricity. This immersion presented a pivotal moment for me, as it significantly altered my perspective on the app’s purpose. I began to understand that being a programmer in the first world obscured the simple fact that the realities faced by the end users were far more challenging than I could have imagined.
00:12:06.850
As we proceeded with the project, I encountered issues like a lack of experienced users who had never interacted with smartphones before, causing design navigations to be non-intuitive for them. Language barriers also posed significant challenges—while the app was translated into French, some of our translations were poorly worded, leading to confusion. The app's terminology was confounding; for instance, using 'record' incorrectly translated led some to wonder fraudulently about their purpose within the app. Moreover, with no available tech support in the field, the design had to be reliable and include easy-to-follow troubleshooting steps.
00:13:14.510
Given these challenges, we pursued non-standard solutions. Having access to the right hardware provided by the NGO facilitated the creation of well-optimized devices for our needs. This led to extensive market research on various printing devices suited for the conditions we were encountering. We considered factors like battery life and durability. Moreover, we had to develop the app with specific devices in mind since any small loss of our constraints could render our solutions inadequate.
00:14:57.000
The project became an exercise in developing solutions from scratch—an experience that was frustrating yet enlightening. Our understanding of the end users was cemented through our discussions and experiences, ultimately guiding the development of useful and straightforward features. This realization reminded me of the importance of empathy, a lesson validated with my shift to working at AgriList. Here, I contribute to an app that assists with the day-to-day operations of indoor farms and greenhouses, interfacing with farmers directly and understanding their daily needs.
00:16:42.290
At AgriList, we face similar challenges regarding language. With customers in various countries, ensuring the app is accessible in languages people can understand is crucial. We leverage i18n for internationalization, making the app available in English, Spanish, French, and Arabic—yet adjusting the layout appropriately can introduce unexpected problems, such as flipping the design for right-to-left support in Arabic, which can lead to confusing results if not adequately revised.
00:17:39.800
Another consideration revolves around user-friendliness; designing something intuitive requires thinking about where common elements are typically found, like the back button’s placement. Based on user feedback, we are currently refactoring our app to include big task calendar views, mimicking Google Calendar—requested by users who preferred such an integration. We learned that while we developed the desktop version of the app, our end users predominantly relied on mobile devices to access our functionalities.
00:18:53.170
When planning features, it’s essential to be in tune with users' requirements. One practical example of this is the introduction of 'plant sites,' enabling users to manage their inventory effectively while addressing main constraints. Our discussions facilitated a perspective that enabled us to implement features suited to farmers' needs, illustrating the value of talking with users to understand what truly impacts their day-to-day operations.
00:20:27.090
While I haven't worked specifically on accessibility-focused projects, I believe it is a significant subject worth discussing. Basic issues like color contrast can be problematic, especially for colorblind individuals, who form a large demographic. Sometimes simple solutions—like including asterisks next to required fields in a form—can make a tremendous difference, so it’s essential to prioritize their usability early in the design process.
00:21:04.780
Wrapping up, I reflect on what I've shared. Cultivating empathy towards your users is essential for creating applications that resonate with them, not just ourselves. Developers often struggle to predict user pain points before an application is developed, which is why requirements gathering is so crucial and, at times, challenging. It's important to understand whom you’re truly serving and ensure you engage with them personally, as understanding their environments and experiences is fundamental.
00:22:36.490
Don’t merely seek out highly technical solutions; simple and clever answers can also yield immense value. It is easy for developers to fall into the trap of pursuing complex solutions just for the sake of complexity instead of focusing on the user experience. Small adjustments—like taking the time to think through context—can significantly improve usability and customer satisfaction. Lastly, fostering empathy not only enhances applications but has a far-reaching impact on the wider community, resulting in a better understanding of the people around us.