Learning Python: A UX Designer Perspective

Why?

The desire to learn Python stemmed from several motivators. As an interaction design graduate, I'm used to understanding the why behind UX decisions, but I have little understanding of how difficult it can be for developers to implement or change what might seem like a minor tweak to me. I wanted to experience that gap firsthand. And with a Raspberry Pi Zero 2 W and a Pimoroni e-ink display sitting in a drawer doing nothing, I was curious whether it's actually possible to learn a programming language using Claude AI as a guide rather than following a traditional course.

Tools & Programs

Getting Started

Before I even had a chance to try out a line of code, it became apparent this was going to be a task of much frustration, and that I needed to get comfortable seeing error codes. A lot of them.

Attempting to SSH into the device was the first hurdle, and honestly, that alone was almost enough to make me give up. What should have been a simple case of entering the username and password I created while setting up the Raspberry Pi Imager turned into hours of this:

But through much trial and error, I finally gained access to the device and could start displaying some basic elements on the screen. I began with the simplest things I could think of - rendering text and loading an image onto the e-ink display. Nothing fancy, just proof that I could actually make the hardware do something.

Branding Process

To begin the branding process, I considered what the core brand values would be. I established these early on and they served as a compass for each of the following stages. I found that they minimised time to make a good decision consistent with the rest of the project. This was especially useful when populating the text within the app, as I felt as though I knew the ‘voice’ of the app from the values.

Even at this stage, small wins felt significant. Getting a sentence to appear on a physical screen using code I'd written (with plenty of help from Claude) made the whole process feel tangible in a way that tutorials on a laptop screen never quite do.

Building a Dashboard

By this point I knew the knowledge needed to design something and the knowledge needed to build it are worlds apart. But I also started noticing some comforting similarities. In Figma, I create components and styles for consistency and ease of editing, and coding has its own version of that same thinking. For instance, defining colour values as variables at the top of a script felt a lot like setting up a colour style in Figma, or writing a reusable function to format text reminded me of building a component I could drop in anywhere. To try and understand more complex functions, I decided to create a weather dashboard. While my instincts as a UX designer is to always sketch and wireframe a project to iron out usability and structural problems, I chose to jump straight into building the dashboard - mainly because I didn’t want to get hung up on making it look a certain way opposed to figuring out what I’m doing and why.

My first iteration was just a basic black and white static dashboard with hardcoded placeholder data, which already introduced me to a lot of new concepts. I was starting to understand how layout works at its most fundamental level, figuring out a grid system based on the display's pixel dimensions rather than dragging guides around in Figma. I also began to see how Python's def function is essentially a way of creating reusable elements - not unlike building a component that you can drop in wherever you need it.

Now that I was beginning to understand some basic visual setup, it was time to develop the dashboard further and make it functional by pulling live weather data using the Open-Meteo API. I also wanted to add a colour output to correspond with the data, so you could tell at a glance which values were high or low. This was a big eye opener for me, as a designer, making visual changes like these is often just a case of adding an instance to a component, or adding variables in the prototyping stage. But in this instance, making the dashboard functional was enough to bulk the script from 86 lines of code to 228.

I was starting to notice how choice of hardware can impact design as well. Due to the nature of e-ink displays having minimal colour capabilities, adjusting colour contrast isn’t as easy as increasing transparency or simply making a colour lighter. To make the text legible against the card backgrounds, I had to get creative and use dithering - a technique that simulates lighter tones by scattering tiny dots of black and white. It's a solution I wouldn't have considered as a designer, but one that made complete sense once I understood the technical limitation I was working within.

Conclusion

My biggest challenge throughout this was probably terminology. While a lot of the principles shared similarities to UX design - formatting elements based off a grid system and setting a type scale - the wording and methods used to do so were far from intuitive for me.

So, is Claude AI capable of teaching a coding language? Based on this project alone, it's hard to give a definitive answer. I wouldn't be able to independently write a script from scratch, and there are still gaps in my understanding of why certain things are done the way they are. But I don't think that's a failure of the tool, it's more a reflection of how early I am in the process. Learning any skill takes consistent practice, and this was really just the starting point.

Witnessing first hand what design restraints can be determined based off hardware will definitely shape how I think about problems in the future. The use of dithering isn’t something I would have thought of utilising previously, but despite it being one of the only options available, I feel it actually creates more visual depth.