@nimesh.mohanakrishnan

I first got into programming in 10th grade. I wrote a little HTML and CSS and managed to draw a box on a webpage. Just a box. But I'd only just learned how the web worked, so it honestly felt like a magic trick. I could imagine something, write a few lines of code, and there it was. And I got to decide how it looked and how it behaved.

That feeling is what took me to computer science. There, I learned what I'd now call the science of making things: databases, microcontrollers, how to build something end to end. For my database class, I built a full-stack blog in Django. Whenever I wasn't sure how something should work, I'd just look at how other blogs did it and build that. I knew how to make things. It never really occurred to me to ask whether they should work that way.

As it turns out, someone else asked that question for me. In 2021, I was interning as a developer at Brane Enterprises, working on a no-code platform. I was building a feature that let users add an intent, and my instinct was a modal: click a button, fill in a few details, done. Then the designers came back with a question. Was a modal even the right interaction here?

I wasn't annoyed. I was curious. Why would they pick one approach over another? So I started asking questions of my own, and learned that the information was dense enough to need its own page. The point wasn't just to let people enter it. It was to help them understand it.

Honestly, I don't remember the rest of the details. It was 2021, and apparently my brain decided those were optional. What stuck with me was the realization that there was a whole layer of thinking between an idea and its implementation, and I hadn't learned to see it yet.

So I went looking for that layer. I started with the Google UX Design Certificate course, which taught me the process: research, define, ideate, card sorting, all of it. Not long after, I joined RozieAI as a design intern, and that's where real work started teaching me the things a process can't.

My first job there was redesigning screens for Experience Studio, a no-code tool businesses used to build their own conversation workflows. About a year in, I got my own project: Conversation Insights, an analytics platform for Air Canada's contact centre managers.

That project is where I learned that decoration is not UX. I kept spotting chances to polish the interface, but my users were a small group of power users. They didn't need delight. They needed the right information. The biggest improvements actually came from taking things away: a trend chart people kept skipping, a filter bar that had grown as big as the data it was filtering. And the biggest gap came from a question I never thought to ask. I'd researched how managers investigated an issue, but not how they decided an issue was worth investigating in the first place.

That missed question stayed with me. I'd learned design on the job, one screen at a time, and part of me wondered whether I'd learned it the right way. Was I asking the right questions? Would I even know if I wasn't? I wanted a real foundation, especially in research, which I'd never formally practiced. That's what brought me to HCDE at the University of Washington.

I started finding answers sooner than I expected. In my usability testing class, we ran a study for an industry partner. One of our tasks asked participants to find “architectural recommendations you care about.” The first two participants struggled. So we changed it to “find specific architectural recommendations,” and the next three completed it.

One phrase changed the result. That's when it clicked for me: a question isn't just how you find an answer. It decides which answers you can find at all.

Looking back, I don't think my path into design was ever a change of direction. It was me slowly learning to ask better questions about the things I was building. From “How do I make this?” to “Why should this work this way?” to “What problem are we actually solving?” and now, “What exists around the problem? What should exist? What should be subtracted?”

And yes, I still work in code. I don't write much of it by hand these days, but I use it to close the gap between design and implementation, that same layer I couldn't see back at Brane. The box is still there. I just ask why it should exist before I draw it.

Lately, building with AI has given me the same feeling I had with that box. I can picture something, describe it, and watch it come together, sometimes in a single day. It's honestly magical.

But here's the thing. That magic used to feel like mine, and now it's everyone's. Anyone with the right tools can pick up a new skill, build something impressive, or put together a polished artifact in an afternoon. So I've been sitting with a slightly uncomfortable question: if making things isn't the hard part anymore, what do I actually bring?

A few months ago, I built a game entirely with AI tools. It's called kar-no-key: one person makes a room, shares a short code, and everyone races each other one lyric at a time. No accounts, nothing to sign up for. Front end, back end, all of it, in a matter of days.

Then I realized something. Nobody was going to click “Leave game.” People just close the tab. But the game didn't know that, so it still thought they were in the room. The next time they opened it, it told them they were already in a game. And if the person who left was the host, their friends were stuck in a room with nobody running it.

My first idea was a popup: “Leave the game?” Turns out that can't exist. When you close a tab, the browser just shuts the page down. The site doesn't get to ask you anything. So we went with a heartbeat instead. As long as your tab is open, it quietly lets the game know you're still there. Close the tab, and the heartbeat stops.

Then I asked the question the AI hadn't: what about someone who's still there, just not clicking? Someone waiting for their friends, or thinking about the next lyric? They shouldn't get kicked out for being quiet. And they don't, because the heartbeat comes from the open tab, not from clicks. If the host leaves, the room doesn't disappear either. Someone else just takes over.

That's what made it make sense for me. The building is getting easier. The questions are still mine. And when I look at the questions I keep asking, they tend to come back to two ideas that have started shaping how I design, and honestly, how I live.

I'll be honest, these ideas are still taking shape. They feel less like rules and more like a compass.

Right now, that compass is pointing me toward AI agents, agent tools, and developer tools, at the scale of products used by millions of people. So far, I've mostly designed for small groups of power users. But as agents take on more of our work, that question from kar-no-key gets a lot bigger: what happens to the person in the room? That's the question I want to work on, at scale, while staying close enough to the technology to build what I'm imagining.

Do I have the destination figured out? Not yet. But I've made peace with that. Like a good interface, the next layer tends to show up when it's relevant. For now, I've got a direction, two ideas I believe in, and plenty of questions I still want to ask.