(Dev)eloping Empathy

The further I progress in my learning of UX design and UX research the more I have come to understand the need to develop empathy. We are constantly called to have empathy for our users and consider what their experience will be when using our products, which is as it should be. But when Colin Eyre spoke on Integrating Design Research into the Development Lifecycle at the UX Brisbane Meetup this week he posed a question that has really stuck with me: What is the user experience we’re creating for our teams?

Although my perspective is that of a student who is not yet working in industry, and perhaps because I’m coming to this from a totally different background (I was an ESL/primary school teacher before moving into design) I’ve been picking up on subtle digs and side comments about the working relationships between designers and developers. It’s been in published online classes from reputable sources and mentioned in articles I’ve read. It seemed that the stereotype of a designer changing things on a whim and developers being unwilling to implement changes is pretty ingrained. Could this stereotype have simply arisen due to a breakdown in communication? With cross functional communication being a buzzword that constantly comes up in role descriptions I felt this was any area I wanted to develop. But how?

Luckily studying UX had already provided the answer. Develop empathy. Often for early career UX designers it can be easy to confuse sympathy with empathy. Sarah Gibbons of Nielsen Norman Group states that “empathy enables us to understand not only our users’ immediate frustrations, but also their hopes, fears, abilities, limitations, reasoning, and goals” and goes on to give an example that the best way to develop this empathy is to recreate a user’s experience ourselves(2019). In comparison sympathy is simply our own reaction (usually pity) to another person’s experience. In sympathy there’s still that feeling of separateness and a lack of true understanding of what the user is going through.

I’ve developed plenty of sympathy for developers over the years. Being married to one I’ve seen first hand the hours that can go into coding something that, to the user, appears to be a simple function. The amount of time that goes into refactoring and writing tests. I’ve seen the lack of understanding when people without a technical background ask about “just building a small app” and can’t understand the costs involved. And whilst I could sympathise with all of that, I couldn’t really empathise.

To get a broader understanding of everything that goes into the production of a digital product I took a class this semester in Creative Coding taught by Jared Donovan at QUT. The subject was excellent, it stretched me as a designer and helped me to develop skills in JavaScript by creating sketches in p5.js. But what was most invaluable for me was the development of empathy.

Whilst I tried to fully design each sketch before starting to code, inevitably I would come up against changes that needed to be made either for stylistic or functional purposes. Very quickly I realised how many lines of code I needed to make even the simplest of changes. I experienced frustration as I had to read through documentation to understand the changes I was going to make and as I realised that changes I made in one area of my code would go on to affect other areas. I learnt the amount of research that has to go into developing something from scratch and the depth of expertise needed to understand if something was technically feasible, and if it was, the amount of effort and time that would be required to implement it.

I also quickly realised that there were gaps in my vocabulary to describe what I was trying to create. I would know that something was technically possible, I had seen something similar done elsewhere and would be able to describe it using language common to design. But I had no starting point of terms to search for the outcome I wanted, to find the resources that would teach me how to implement what I was trying to achieve from a technical standpoint. This taught me the value in creating a shared language and taking the time to at least learn the terms used by developers so that we can communicate more effectively.

Just as all of the coding was new to me I realised that all of the design aspects were new to my peers who were coming to the subject from a computer science background. I took for granted my ability to choose colours for my designs, make decisions around typography and layout in my documentation and to use ideation exercises to come up with ideas for my sketches and to then iterate on my designs until I had something I was happy to present. But for many (not all) of the computer science majors Creative Coding was their first introduction to design. It’s easy to forget when you are so immersed in a subject area that the skills that you use everyday, the understandings with which you make sense of the world and your work, are not universal. In this sense I believe that the need to develop empathy between designers and developers goes both ways and that both sides need to develop a deeper understanding of what is involved with our respective work loads.

The chance to develop that two way empathy ties in well with Colin Eyre’s presentation at UX Brisbane. When looking at the user experience we create for our teams he presented a number of exercises, tools and canvases that we can use to bring our teams into our research process/findings such as the knowledge share canvas, insight cards and scales of prioritisation. By presenting our research findings in a manner that is engaging and quickly digestible we can help other team members we’re collaborating with to see that there was reasoning behind our design decisions. We can increase the implementation of designs and give a shared sense of ownership in the overall product design by presenting this rationale. We wouldn’t expect our users to read through dense, dry documentation in order to use an experience we’ve designed, so why would we expect our team members to read through something like that in order to implement it?

Whilst I can’t see myself becoming a highly efficient developer anytime soon, I’m grateful for the empathy I’ve been able to develop by learning to code. I’ll probably keep experimenting with creative coding as a form of artistic expression and to try and break the stereotypes of what it is to be a developer or a designer but also as a means to continue developing a shared language to improve my skills in cross functional communication.