Designing for Developers When You’re Not One: Lessons from User Research

When you’re designing for an audience you deeply relate to — say, parents, students, or people who shop online — empathy tends to come naturally. You know what frustrates them because you’ve felt it too. But what happens when your users are people whose workflow you don’t fully understand, and who speak a language rife with terms you don’t know well, like «RPC calls», «impersonation», and «contract listeners»?

That was the situation I found myself in while doing user research for ethui.

I’m a product designer. My audience? Engineers. And not just any engineers — Web3 developers.

To better understand how developers test and debug smart contract interactions, I ran a series of interviews with 8 people (5 frontend developers and 3 smart contract/backend developers). The goal was to learn about the workflows they were dealing with and evaluate how to make the tool we’re building, ethui, improve those routines.

The tool is designed to offer a local-first, fast-feedback testing environment that connects directly with Anvil. It supports multiple wallets, multiple browser sessions, and eliminates the friction of repetitive confirmations. We wanted to see where we could fit our features naturally into developers’ workflows, especially when they’re testing contract interactions from the frontend.

This research pushed me outside my comfort zone in a big way. I had to ask questions that felt «dumb». I had to stop people mid-sentence to ask them what a tool did, and constantly fight the feeling that I was missing something important.

When I design for the general public, I’m often drawing from personal experience. But here, I had no frame of reference. I didn’t know what a tool like Anvil or Hardhat did before this. I didn’t realize how complicated it is to test frontend smart contract integrations manually. I certainly didn’t know that writing your own tests from scratch was the norm when developing smart contracts.

To navigate this, I tried to be as upfront as possible: if I didn’t understand something during an interview, I’d ask the developer to explain it on the spot, even if it sounded basic. I also took detailed notes and looked things up afterwards to fill in the gaps. Still, I couldn’t shake the feeling that I might be missing critical threads, so I invited a developer colleague to join one of the sessions and help validate whether I was asking the right questions and pushing the right topics forward.

There wasn’t one magical «aha» moment, but there was a key personal shift in perspective. I came into this research thinking the tool we were building would be most useful for smart contract developers — people writing contracts and debugging logic at the protocol level.

What I learned is that while those users might use it, the ones who benefit the most are frontend developers. These are the folks building the user interfaces that interact with contracts, and their workflow is full of repetitive testing, wallet switching, and fragile flows that break if contracts or chains change even slightly.

Even though this wasn’t a new insight to the team who built the tool, it was new to me. And that’s the value of doing your own research. You want not just to discover what users think, but to get clarity as a designer, so you can better advocate for them in future decisions.

One of the most eye-opening things I learned was how frontend devs test smart contract flows. They don’t usually get to run tests in environments they can control. They make transaction after transaction using real wallets (like Metamask), manually connect to testnets or staging chains, and reload flows over and over just to make sure things work.

This is painful. Especially when things like impersonation aren’t possible or when they need to simulate balances and contract states just to see how a UI behaves. That’s where our tool comes in and where I saw the potential it has to genuinely make their lives easier.

Another unexpected lesson? What I think of as “good design” often doesn’t match what developers actually want.

As a designer, I tend to lean toward whitespace, clarity, and minimal UI. But developers — especially those who spend all day in VS Code or terminals — are used to dense layouts, limited padding, dark themes, and a ton of information in one place. What looked «noisy» to me was «complete» to them. What felt too dark to me felt «easy on the eyes» to my users.

It took some effort to adjust, to let go of my biases and design for their preferences, not mine, was a big part of this process.

It was a humbling reminder that great design doesn’t mean universal aesthetics. It means meeting users where they are.

This research reminded me how humbling and powerful it is to build tools for people whose work you don’t fully understand. It forces you to slow down, ask more questions, and recognize the assumptions you bring into a project.

But it also reminded me why I love product design. We’re translators. We take technical complexity and turn it into clarity. We build bridges between tools and people.

And to do that well, we have to get close to the people on the other side, even if it means asking what might feel like «dumb» questions along the way.