Defining a designer

While I’m in the midst of hiring for product design at Gecko, I’m having a lot of great conversations—both with candidates and with folks at Gecko. Without the breathlessness of LinkedIn clickbait, we’re all trying to understand the role of design in 2026, design at Gecko, and the candidates’ ability to fill that role. ¹ It’s making me think a lot about my definition of a designer and my expectations for myself and others.

Evolution of design scope

I have a broad definition of design. I know that. I have a broad set of skills. I have high expectations for others. I believe in the people on my team to do great things and grow.

When I define this with people at Gecko, it becomes clear that I’m changing others’ perception of what design can or should own. And this happens through our work more so than hiring discussions. Designers always seem to carry the burden of proof—or at least proving it to others.

Most of this ethos was born in my formative days at MAYA Design in the peak HCD/design thinking frenzy of the early 2010s. Design could do anything, so therefore designers could do anything.

But most designers couldn’t and shouldn’t do everything. Heck, a lot of designers couldn’t do anything particularly well. I found myself getting sick of portfolios from relatively inexperienced candidates coming out reputable master’s programs who had a good sense of strategic human-centered design impact, but not a great skill in anything that would help achieve that impact.

This is what I’ve waffled between for years now. Design can do it all. Designers can’t do it all. And then PMs increasingly took more and more of the scope that human-centered design made possible, so everyone was a designer in that sense. And bigger orgs dedicated full teams to doing user research, which took even more fun responsibilities away from the designers. Designers were left with Figma, the TikTok of the product world, where they lost hours (or years) fiddling with more and more complex software simulations.

Expectations

Because I’ve been a lot of different types of designer over the years (graphic, motion, game, UI, interaction, visual, UX, product, experience, heck, even dabbling in workspace design for a few projects), I know it is possible for individuals to have a lot of breadth and depth. But it is not common, nor is it easy to come by (though many people will acquire that skill set faster than I did, I never claimed to be a fast learner). I try to factor this into my evaluations and expectations, but it’s hard—I still believe “designer” carries a broad charter of things to own and be good at. The job description I wrote is long (and would have been longer and spicier if recruiters hadn’t helpfully edited it with me) because the job is hard and requires more now than ever.

Getting back to the recruiting and role definition conversations I’ve been having: I have an admitted aversion to the designers who come across as specialist designers. Design is already a specialist thing. The lot of us are nowhere near as broad as the average MBA-toting management consultant. But that means the variants like design systems designer or design engineer are essentially red flags for me, because those types tend to be less well-rounded and capable of the research, discovery, HCD, and product-y thinking that I believe a designer should inhabit. That’s a generalization, I know. But it’s also a title that tells me you have a desire to focus on those things at the expense of other things. Not wrong—you gotta do you and put food on the table—but not my definition of what designers should be.

And I don’t think the definition of a designer has really changed from those early days when pioneers came up with terms like “interaction designer”, but the common understanding and expectation has. Which is what I will continue to work to change in my small sphere of influence.

Footnotes

1. I hesitate to use the term “fill” in that sentence, because it is probably unfair to both designers and expectations (though I don’t think expectations have feelings). ↩