I am still thinking about what type of writing should come next. I don’t plan these — I’m not the kind of writer who keeps a backlog of topics in a Notion board. I was sitting at my desk and I saw a book lying next to me, bookmark still wedged at around the seventy-five percent mark, and something clicked.
The book is Design Is Storytelling by Ellen Lupton. I had never considered writing about a book before. I read plenty, but I never felt like I’d earned the right to — I’d finish a book, nod along, and then go back to doing things exactly the way I did them before. Reading without applying is just entertainment with better branding. But this one was different. I didn’t finish it, and it had already changed how I work.
Let me start with the cover.
People always say you should look at a book before you read it. Study the cover, the typography, the layout. With this one, I didn’t need anyone to tell me that — the cover did the work on its own. There are too many symbols on it, and by every rule I know, that should feel like clutter. But it doesn’t. Everything sits where it should. And that alone made me pause. There is something behind this — some principle that separates clutter from composition, noise from design. That gap between “a lot of things thrown together” and “a lot of things placed together” is not an accident. Someone thought about it.
That’s the thread the whole book pulls on: simplification. Not dumbing things down, but clearing the way so the important thing can breathe. And the more I read, the more I realised how badly I had been getting this wrong — not in design, but in my actual job.
Here is the thing nobody tells you when you’re starting out as a developer or a data scientist: implementation is the easy part. I don’t mean easy in the sense that it requires no skill. I mean easy in the sense that it’s the part we’re most comfortable with. You get a problem, you open your editor, you start building. There’s momentum in that. There’s the dopamine of watching something take shape on screen. And because the building feels productive, you assume you’re doing the important work.
I was exactly this person. Someone would hand me a task and I would jump straight into the code. Get the MVP ready. Ship it. And it would work — in the narrow sense that it would do the thing it was supposed to do. But “works” and “works well” are not the same thing. “Works” gets you a ticket closed in Jira. “Works well” gets you something a person actually wants to use.
For the longest time, my work’s main highlight was speed. I could build fast. But so can a lot of people. With AI writing code now, I’m not even one in a million. I could have gone on like this — shipping functional things, collecting my annual raise, never asking whether the thing I built was the right thing to build, or whether I built it in a way that respected the person on the other end of it.
Reading Lupton broke something in that loop.
The book talks about storyboards, scenario planning, emotional journeys — tools that sound like they belong in a design agency, not in a data scientist’s workflow. But the underlying idea is brutally simple: before you build anything, understand the person who will use it. Not in the abstract, product-manager way where you write a user story on a sticky note. Understand how they think, what they say, what they do, and what they feel. Plot it out. Sit with it.
I was working on a loan eligibility form. And to me, it was just a form. Fields, validation, a submit button. The kind of thing you could build in an afternoon without really thinking about it. But I tried something from the book — I mapped out four quadrants of the user. What does this person think when they open this page? What do they say to themselves? What are they actually doing, physically? And what do they feel?
The user is a loan seeker. Probably anxious. Probably not doing this for fun. Probably scanning the page trying to figure out if they even qualify before they invest the emotional energy of filling it out. The moment I put myself in that seat, everything about the form looked wrong. The same font that looked fine in my code editor looked completely out of place on a page meant for someone in a vulnerable position. This was not a developer tool. This was a financial decision wrapped in a web page, and it needed to feel like someone had thought about the person on the other side of the screen.
The insights came running after that. Not because I suddenly became a better engineer, but because I had finally asked a question I’d been skipping: who is this for, and what are they going through when they encounter it?
This is what I mean when I say the book changed how I think before I even finished it. It didn’t teach me a new programming language or a new framework. It taught me that implementation — the part I’d spent years getting faster at — is not even the main work. The main work happens before you write a single line of code. It happens when you stop and think about the human being at the end of the pipeline.
And here’s the part that extends beyond design, beyond data science, beyond any single discipline. We treat our current tools and methods as settled because enough people have approved of them. Python is a good language for data science — yes. But is it the best it could ever be, permanently, just because a large enough group of people happen to use it right now? Consensus is not the same as truth. It’s a snapshot. The moment someone arrives with better reasoning and a clearer logic, that same crowd will shift. It has always worked this way.
But before you can improve anything — a form, a language, a workflow, a career — the first step is to acknowledge that it can be improved. That’s harder than it sounds. It means looking at the thing you built, the thing that works, the thing you’re proud of, and saying: this is not done. Not because it’s broken. Because nothing ever is.
The bookmark is still at seventy-five percent. I’ll finish the book eventually. But I think Lupton would appreciate that I stopped reading and started doing — that the book worked on me before I worked through it.