"With a few notable exceptions, most advice on "learning code" for designers emphasises front-end and web frameworks. That makes sense if your focus is UI. But if you are interested in shaping interaction and functionality in complex, data-intensive products - which probably includes LLM-powered interactions - Python is the natural choice. It gives you a concise, readable, powerful language in which to describe data and logic. You need this for communication even if an LLM writes all your code."
"Practice it on the tool you are building (AKA UX Dogfooding). Watch users perform it on the tool you are building. Note the differences. There should be no functionality in the system that you haven't both used yourself and observed with end-users. This is the only way for you to build intuition for the meaning, value, and relationships in the data you are working with."
"Rather than designing a page that you "fill" with content, create building blocks from the data and assemble them according to its logical structure. This is not word-play - it's really a Copernican shift - the data is the interface."
"Let the actions that you can perform live in/on the data representation as much as possible. This is similar to Edward Tufte 's "data-ink maximisation principle" but expanded to include application scaffolding as well as data display. Ideally, if there is no data, the page is (almost) completely empty, which leads to the next suggestion... Design the empty state. Why is it empty? Is it a starting state (e.g. the blank page of a design tool), an error mode, a transitional state, or a desired outcome (e.g. an empty list of issues/errors)."
Python supports concise, readable, powerful descriptions of data and logic, making it suitable for interaction and functionality in complex, data-intensive products. UX dogfooding means practicing on the tool being built and observing users performing their jobs, ensuring every system capability has been used and validated with end-users. Interfaces should be assembled from data-derived building blocks according to logical structure, treating data as the interface. Actions should be available directly in or on the data representation, reducing surrounding chrome. Empty states should be defined by cause and purpose, including whether the component should exist and what guidance should be shown. Realistic data should be used to avoid misleading design assumptions.
Read at Medium
Unable to calculate read time
Collection
[
|
...
]