Yaron Schoen

What's a Design Engineer, Anyway?

2026-08-12T00:00:00Z

The other day I typed a small confession into Claude: I have no idea what to call my role anymore.

It started, as these things do, on LinkedIn. Suddenly every other person in my feed is a Design Engineer or looking for one. New job postings, new bios, new conference talks. And I realized that despite 25 years in this industry, I couldn't actually define the term. I had three competing theories and no way to pick between them.

Theory one: it's an engineer with good design and product taste. Someone who came up through code but can be trusted with the pixels and product decisions.

Theory two: it's a designer who uses AI to write code, but other than HTML/CSS can't really promise you if the more serious code is good enough. (This one felt suspiciously close to home.)

Theory three: it's the unicorn. A person who is genuinely both a designer and an engineer by training.

The first two made sense to me. Both are real, and both got a massive boost from AI tooling. But the third one bugged me. If a design engineer is a true unicorn, why are there suddenly so many of them? Unicorns don't have baby booms.

So I did what I do these days: I asked Claude to research the term, then went down the rabbit hole myself, checking its homework. Here's what I found, sources included.

The first obvious thing it came back with is that the term is old. I assume we all know this, but for most of its life, "design engineering" had nothing to do with screens. A design engineer sat at the intersection of industrial design and mechanical engineering, the person responsible for making sure a physical product actually works and can actually be made. The UK has had a professional body for them, the Institution of Engineering Designers, since 1945, and Imperial College London runs an entire school of Design Engineering that grants real engineering degrees. We borrowed the name from people who make actual machines.

When tech started to borrow the term, it couldn't stop renaming it. The design-and-code hybrid has gone by UX engineer, design technologist, creative technologist, and a handful of similar titles over the years. Heck, I've even hired some amazing UX engineers and creative technologists (Hi Donnie and Dave, to name a few…). Google has had a formal UX Engineering track for over a decade, and Vercel built an entire team around the role. Even the underlying tension is old news: Chris Coyier described the great divide between the design half and the JavaScript half of front-end work back in 2019, and Brad Frost later gave the design half a name, front of the front end. The role isn't new. The name just keeps winning different popularity contests.

And the purist definition, it turns out, is my theory three. In the strict sense, a design engineer is its own discipline, focused on the exact point where design decisions meet technical implementation. Not "kinda good at both"; a designer who can build their own solutions, end to end. That's essentially the case Jim Nielsen makes, and InVision (remember them?) published a whole Design Engineering Handbook about the discipline back in 2020. That population was always tiny, which is exactly why the title stayed niche for so long.

Which brings us back to the baby boom question. If the unicorns were always rare, where did this flood come from?

First, an honest aside: I couldn't find hard numbers on the flood itself. Job statistics for "design engineer" are dominated by the mechanical kind, so anyone showing you a tidy chart is probably measuring the wrong profession. What I can show you is the pile of anecdotes: Vercel, Linear, The Browser Company, and Anthropic have all been hiring design engineers, the title now has its own job board, and the essays about its rise keep coming. Something is clearly happening.

But it's not a baby boom. It's a title migration.

Here's what I think is actually happening… the bar for "can implement" collapsed. First slowly: component libraries like shadcn/ui, Radix, and Headless UI meant you no longer had to build every button and dropdown from scratch. Then all at once: tools like Cursor, v0, and Claude Code mean a designer can express ideas in working code without mastering every syntax detail. So the people from theory one and theory two can now credibly adopt the label that used to belong only to the theory three unicorns. Same herd, new name tags.

There's a piece by Anna Lefour, The Design Engineer Symptom, that takes this a step further. She reviewed a wave of design engineer job descriptions and found them wildly inconsistent, sometimes 70% design and 30% development, sometimes the reverse, sometimes something else entirely. Her argument is that this isn't just sloppy naming. It's organizations trying to scope roles in real time, while the old boundaries between research, design, engineering, and product management quietly become negotiable. The title is a symptom, not a definition. And her conclusion is the one that's stuck with me: "What matters now is the scope you're willing to own, and whether you can deliver tangible work within it."

I can't stop thinking about that last line.

Because by that logic, my own situation is less confusing than I thought. I'm a designer who ships working products by directing AI implementation (I wrote about that shift in Drawing With Words). An engineer may need to PR the code to ensure it's not breaking anything etc., but that happens even with other engineers, not only me. So I seem to land on theory two, but with a couple of decades of taste stacked on top. Arguably it's the configuration the market is rewarding right now, since taste is the scarce part and code generation is quickly becoming a commodity. "Design Engineer" is a defensible label for it. But so is "designer who ships".

And the people who'd quibble over whether I can hand-review every line of the code? I suspect they're arguing about the wrong thing.

So, did I figure out what to call my role? Sort of. Calling myself a design engineer just seems weird, I get imposter syndrome. Besides, the industry hasn't decided yet, and maybe it doesn't need to. Maybe titles were always just handles, something for recruiters and org charts to grab onto, and the real question was never "what are you called". It was "what can you own".

Or do we even need to change our titles at all? Do titles change just because the tools did? I dunno. If you think about it, PMs, product designers, and engineers all share the same tools now, yet everyone keeps their role's strengths and charters, even if the edges have gotten a bit blurry. When I partner with an engineer, we're both generating code, but I come at it from a designer's perspective, they come at it from an engineering perspective, and we meet in the middle. What if we just expect product designers to ship code, the same way we used to expect them to do the wireframes, or something…

Or maybe I'm overthinking it again.

Claude Code 101, for Designers

2026-08-10T00:00:00Z

I am very excited about AI tools. There, I said it. I'd even say that I haven't been this excited about tech in easily over a decade (maybe even two decades??). Since I started my career I have been designing products inside photo editing tools or derivatives of them, paintings of the real thing, always dependent on an engineer to build what I drew. Not anymore. At work I design straight in the repo, and at home I've built and shipped several tools myself. I wrote about that shift in Drawing With Words; the short version is that it's a golden age for product designers.

I also understand and agree that change can be hard. I'll admit I had a head start though, since my dad was a computer science professor at NYU who got into AI very early and used to blab about it to me almost daily. I also spent a chunk of my childhood using MS-DOS. I'm no coding expert, but none of this is exactly foreign to me either. That said, for plenty of designers it is foreign, and that's okay. That's actually the point of this series… helping product designers make the transition to designing with AI tools. Claude is my LLM of choice, so Claude is what I'll use, but most of what's here translates to other LLMs and AI tools just fine.

Which gives post one an obvious job: explain what Claude Code actually is, and while we're at it, decode the jargon that surrounds it. Agents, tokens, context windows, MCP: the words fly around every AI conversation at work, and they make the whole subject feel more technical than it is.

So here's the map. Every definition below is a couple of sentences, on purpose. Nothing to install, no homework. The deeper dives come later in the series; today we just learn the words.

Large language model

The engine under all of this. It's an AI trained on a staggering amount of text until it became very good at one trick, predicting what words should come next. Do that trick well enough and it starts to look like conversation, writing, thinking, code. ChatGPT, Gemini, and Claude are all LLMs wearing different products.

Claude

Claude is the AI made by Anthropic, the one you've probably already met as an app or a website: a chat box you type into, an answer typed back. In that form it's a conversation in a box: it can tell you things, but it can't really do things.

Claude Code

Claude Code is Claude, but with the inclination to code. The same brain, installed on your computer, where it can create files, edit them, run them, and look at the results. Chat Claude can describe a prototype and perhaps build an artifact. Claude Code builds entire apps and more. Despite the name, code is just one of its talents. It will happily rename five hundred files, resize a folder of images, or draft your case study.

It lives in the terminal

Claude Code runs inside the terminal (a full tour of which is the next post), and it always works from inside a folder: whatever folder you start it in becomes its workspace.

But the terminal can live inside an app

If the raw terminal isn't your thing, it doesn't have to be a standalone window. Code editors like VS Code come with a terminal built in, and apps like Rigadigdig or even Denote dress the whole experience up in friendlier clothing (full disclosure: those two tools are mine). Same engine, different outfit.

It's single-player

Figma trained us to expect every tool to be a shared canvas with a pile of avatars in the corner. Claude Code is the opposite: it's just the two of you, on your machine. Nobody else sees the session, nobody's cursor floats by. It's less collaborative whiteboard, more private collaborator.

Git and GitHub are how it becomes multiplayer

Git is version history for a project folder. It's a point in time you save that you can always roll back to, like Figma's version history but for everything in the folder. GitHub is the website where those histories live so a whole team can share one project. You don't have to learn either one to start, Claude performs the ceremony for you. I used to use GitHub Desktop but now I just tell Claude to do it. I'll have a more in-depth post on Git and GitHub soon.

Models are the brains, and they come in different sizes

Under the hood, "Claude" is a family of models with poetry names (Haiku, Sonnet, Opus). Bigger models think deeper and move slower; smaller ones are quick and cheap. Tho if you use a smaller model on a complex task, it may become more expensive because it's working longer and harder to perform what a larger model can do quickly. Claude Code picks a sensible default, and you can ignore this whole paragraph until the day you can't.

Context is its short-term memory

Everything in your current conversation, what you asked, what it read, what it wrote, sits in Claude's working memory. That's the "context", and you'll hear it called the "context window" because it's finite, like desk space. Tokens are the units it's measured in: little chunks of words, a syllable or two each. When the context fills up, Claude tidies it by summarizing the older stuff, which is why a very long conversation can get a little foggy about how it started. This is where the AI starts to make mistakes and hallucinate because it doesn't remember everything you talked about.

A session is one continuous workstream

Start Claude, do some work with it, then quit: that's a session. When you start a new one, it begins with a clean context. Quitting and starting fresh is a good habit to have. I constantly start new sessions so that the context is fresh and we don't get into a very long conversation where Claude will start forgetting what we talked about. I check to see the context window by typing /context. If the project is very large, I may ask Claude to produce a PLAN.md file which I will ask it to read in the beginning of each new session so that it remembers what we were doing in the previous session and picks things up from where we left them.

Approvals and modes

Out of the box, Claude asks permission before it touches anything, every edit gets a yes from you first. You can tune this. Auto mode approves everything automatically so you're not clicking yes forty times an hour. One of the more annoying things is leaving the computer for a bit and coming back to see it didn't do much cause it was stuck on an approval request. Plan mode is the opposite of auto: Claude researches, pitches you a plan, and nothing happens until you sign off. Me, I'm always in auto mode and I really dislike plan mode. If I want to plan with Claude I just tell it that I want to discuss something and it shouldn't code yet. We discuss for a bit, then I ask it to create an md file with the plan.

CLAUDE.md is the standing brief

A plain text note that lives in your project folder; Claude reads it at the start of every session. Since sessions begin blank, this is the onboarding doc: your rules, your taste, the stuff you're tired of repeating. Mine includes a strict ban on em dashes. Long story.

Commands and skills are saved instructions

A command is a prompt you've saved and fire with a slash. A skill is bigger: a recipe that teaches Claude how you do a particular job, which it pulls out whenever that job comes up. I have a skill that teaches Claude how to upload things to my server. Super useful for things you do repetitively and want Claude to repeat it in the same way.

Agents are Claudes you delegate to

You can send a copy of Claude off to handle a task (research this, rename those, fix that) while you keep working, and it reports back when it's done. So there is a team in here after all; it's just all Claudes. The added benefit: each Claude has its own context window, which saves context from the main Claude you are chatting with.

MCP is the plug standard

Short for Model Context Protocol, it's how Claude connects to other tools: Figma, your calendar, a database. It's USB, basically: one connector, endless devices. When someone says "there's an MCP for that," they mean "there's a plug for that."

That's the map. In the next post we walk into the terminal, and in the one after that we install Claude Code and make it build something. The map is nice. The territory is more fun.

Drawing With Words

2026-08-03T00:00:00Z

Last weekend I went digging through the basement for an extension cord (I have a few boxes where cables go to die) and found an external hard drive from somewhere around 2009. I plugged it in, fully expecting nothing. But it mounted! I dug around the old thing and there it was… folder after folder of old client work, all of it in Photoshop files.

I opened one. Hundreds of layers. Hundreds. Layer groups inside layer groups, a layer named "Layer 47 copy 3", another named "final_final_v2_USE_THIS". Drop shadows galore. Inner glows. Gradient overlays on everything. God, we loved our gradients.

The second that file opened, the muscle memory came flooding back. Cmd+clicking a layer to find it. Zooming to 1600% to nudge a one-pixel border. Marching ants crawling around a selection. And then, sitting there in front of that ancient PSD, I realized something… it's been a minute since the last time I opened a canvas to actually design something.

These days, when I design, I mostly write. I describe in words what I want, instead of using the mouse and a canvas UI. I tell the tools what I want, and the tools draw it for me. Then I look at the result, react, and direct. Less drawing on a canvas, more editing intention and context.

My entire career happened on a canvas. Photoshop, Fireworks (raise a glass), Sketch, Figma. Different eras, different logos, but honestly? They're all pretty much the same thing. A rectangle where you push smaller rectangles around until they feel right. For 25+ years, "designing" and "moving rectangles" were basically the same activity.

The challenging thing to admit, but I think we all knew deep down, is that we've basically built our entire discipline (and some, even their identity) on tools that are derivatives of a photo editing tool. Photoshop. My first job was at a web design agency circa 1999, and we knew back then we were hacking a photo editing tool to design sick websites. In a way, it was a conscious act of rebellion even. We just never imagined that it would continue for decades after.

Sketch and Figma adapted things for screens and design systems, but the bloodline is the same. They're all tools for making pictures. If you think of it, we never actually had a real product design tool. We had drawing tools that we kept bending into the job, decade after decade, and we got so good at bending them that we forgot they were never really built for us.

Which finally explains something that bugged me for years without being able to name it. The real design never lived on the canvas. It lived in our heads. Every product designer carries an invisible model of the thing they're building: the product objects, the entities, the attributes, the tasks and the relationships between them. A user has projects, a project has collaborators, a collaborator has permissions, and that's why this screen exists. We were building ontologies, on instinct, in our heads, without ever calling them that. But no tool ever really expressed those concepts, so no deliverable could either. The canvas only understood how things look.

So product design became a discipline focused on how things look. Not because we believed that's what it was, but because that's all our tools could produce. "We shape our tools and thereafter our tools shape us"… as they say.

AI tools are a different beast entirely, though. They're inherently ontological; they think in objects, the way we always did on instinct. You don't draw the thing anymore, you describe it. Visual production is still our responsibility, but it barely costs us anything now. Nobody cuts type with X-Acto knives and waxes galleys onto paste-up boards either, and nobody misses the wax. That frees us up for the actual job… designing the product, not just its looks. Its objects, their relationships, the flows and states that carry a person through a task. For the first time in my career, a tool can hold the model that used to live only in our heads. It's really a golden age for product designers.

We do lose something though. The canvas was never just an output device, it was where the thinking happened. Nudging something ten pixels left and going "hm, no" is thinking. Some of my best ideas were happy accidents: a layer accidentally hidden, a color dropped on the wrong shape. You can't stumble like that in a spec. Specs don't have accidents. Specs have typos.

But I think we're getting closer to the truth with these new tools. Because the canvas was always a bit of a lie. A mockup was a painting of a product, not the product. It couldn't hold the ontology underneath, the objects and their relationships, and it couldn't connect to a database; every screen was a still life of fake data. We spent decades handing developers beautiful paintings and hoping the building would come out looking like the painting. Sometimes it even did. But now we're designing for LLMs, which are probabilistic by nature, and a static mock made in a deterministic tool can't keep up. The drift between the picture and the product only widens, and it's our engineering partners who get left to bridge it.

Spec-driven design skips the painting and works the actual material. The thing on my screen isn't a picture of the product. It is the product, reacting, scrolling, breaking, getting fixed. That's not a small shift in tooling. That's a shift in what the job is.

The best analogy I've got: it's like going from playing the violin to conducting. A conductor doesn't play a note all evening, and nobody accuses them of not being a musician. Or call it a creative director walking the room during a crit. A manager giving notes to a talented team. Pick whichever you like; the instrument is the same: intent, taste, and the ability to say precisely what you want. Which sounds great, until you remember that every conductor worth anything spent years playing an instrument first. Every good creative director once pushed the pixels themselves.

So what happens to the product designer who never plays the instrument? If the next generation goes straight to describing, without ever feeling a layout resist them, without the ten thousand tiny "hm, no" moments, where does their taste come from?

Maybe this is just what every generation of product designers says when the tools change. I'm sure the drafting table crowd said the same thing about Photoshop, and I turned out fine. (Debatable.)

Maybe the canvas isn't dying. Maybe it's just becoming the sketchbook: private, optional, a place to think rather than the place where the work lives.

I dunno.

But I moved the hard drive from the basement to my home office where it belongs.

In Defense of Homogeneous Design

2016-03-16T00:00:00Z

The whole homogeneity of design debate is cropping up again. That's cool. We're all special flowers in our own way. But I'd like to share a few thoughts on product design as I see it.

First off, I'm a very visual person. I love creating unique and distinct visual experiences and have enjoyed doing so throughout my career.

But…

In digital product design, industry-wide established paradigms are a good thing. I assume most of us already know this, but it's worth repeating. Users develop expectations based on patterns they see everywhere: pull to refresh, swipe to dismiss, navigation structures, even underlined links. These aren't just stylistic choices; they're part of a shared design language that users instinctively understand. This benefits everyone. We're collectively teaching users how to interact with digital products. In a way, we're all in this together. Yay!

Sure, this might mean your app resembles another app. But that's okay. Jackets all look similar too, but I still know where my pockets are.

It's funny: I don't hear anyone complaining about the homogeneity of, say, a book's table of contents or an ATM interface. No one complains because they work and have worked for a long time. Why reinvent them? On the other hand, every TV manufacturer seems to think they need to be unique, resulting in completely random remote control and interface designs. Needless to say, nobody enjoys relearning how to use their TV. Amirite?

Digital product design isn't about abstract visual expression. It's a conversation framework between humans and computers. The components and interactions we design are part of a global language. Just like you wouldn't want to have a conversation that constantly shifts between different languages, you wouldn't want unnecessary fragmentation in the way you interact with digital products.

Building digital products requires letting go of ego. Sure, designing a slick, visually distinct homepage is important, but that's not my primary goal. My first goal is to ensure that people understand and enjoy using the product. Making it visually different from the competition is important for branding, but not at the expense of usability. A bad user experience is often far more damaging to a brand than looking similar to other products. Remember Ello? Exactly.

I see a lot of complaints about Dribbble. Look, I get it, it has its issues. But blaming it for design homogeneity completely misses the point. For example, the widespread use of blue in product design isn't Dribbble's fault; it's a result of practical design considerations. As product designers, we have to think about accessibility, clear primary action colors, link visibility, error states, confirmation states, and more. There's a reason so many digital products use blue; it's the same reason black dominates fashion. It just works. If you don't believe me, try building a robust product style guide using bright yellow as the primary action color. I dare you.

Now, I'm not saying we should all just use Bootstrap and call it a day. God, no. Character is incredibly important in product design, but it doesn't only come from visuals. In fact, much of a product's identity comes from microinteractions, copy, and nuance. Maybe a sign-up screen shouldn't be visually adventurous, but that doesn't mean it can't have personality through playful CTA copy, engaging animations, or thoughtful error states.

Knowing when to break from established patterns is part of the art of product design. It's a secret weapon that should be used sparingly and intentionally. Use it too often, and people lose trust because the product feels confusing or gimmicky. Never use it, and people lose trust because the experience feels generic or neglected. Striking the right balance takes time and experience.

It's easy to blame product designers for not seeking "better answers" (i.e., new design approaches or fresh perspectives), but that argument feels naïve. If I know certain patterns work and make users happy, why risk their experience? Do you really want your bank's app to feel like a new experience, or do you just want to quickly check your balance and transfer money?

80% of the time, the wow factor in a product comes from getting users to their goal as quickly and smoothly as possible. Sure, inject character into the remaining 20% and make them smile along the way. But don't let your unique design choices become an obstacle. (I'm throwing out numbers here; this isn't backed by science, but you get the point.)

Of course, I'm not saying never experiment. Nothing in life, or product design, is black and white. But if you do experiment, do it gradually and responsibly. Make sure it serves your users, not just the Designer News Bros™. You might come up with an innovative interaction that improves existing paradigms: a new metaphor here, a new layout there. But these things don't happen overnight. Unlike graphic design or content-driven web design, product design isn't just about infinite aesthetic possibilities.

So, for now, swallow your pride and embrace a little homogeneity, for the sake of your users and your business. We talk a lot about empathy as designers. Maybe this is where it's needed most: by exercising restraint.

Everything you need to know about online disruption models

2013-10-30T00:00:00Z

Cloud-based revenue streams and how a subway ride changed my life.

Yesterday while updating my mobile dating profile through social proof context, I found out that the broader vision of my company's dramatic pitch deck all fell into place. It was glorious.

Let me explain. As online gifting services compete with social funding platforms, mechanisms emerge throughout the industry that generate investor interest. This helped me finally accept the fact that it was in fact a B2C play after all, and that completely changed my perspective for the better. No longer was I inclined to browse flat designs on mobile web anymore! I even avoided responsive retina ready 24 second user generated ads. What a change!

Because of that, my company's music streaming service became a platform (not an ecosystem) that thrived on millions of monthly active personalization databases. In the first 6 months alone it generated enough capital through simple SaaS logistic supply chains that made Q4 look even more promising.

After realizing that simple fact, my work-life balance started to change. I started living in the moment. We replaced all our screen time in exchange for a fulfilling self-destructing photo session with our kids. What a relief. This trickled down throughout my company and I started seeing a real change in employee retention.

While I was focused on my company's hardware play, I found out that the longevity of a voice controlled enterprise platform was hard to disrupt. Founders throughout the industry have tried simplifying gamification to its purist form, so why should I even try? Especially after raising my first series A. I learned that nothing, not even traction, can help us go public.

This is where my outlook on perspective unique click-rates started to really change. No longer was I obsessed with ex-facebook 3d printing ventures. Cloud based modular devices were the norm now. Attribution services started to emerge from the ad hoc analytics rubble that the social marketing tools left behind. This was big.

The next day I decided to seize the moment and go after the high-end indie gaming industry. We unveiled our personalized tablet out of private beta and it completely democratized the way we got instant help from professionals. Think Uber meets haircuts but for Dribbble users.

It was a relative success, but not enough for our syndicate investors. Failure was something that we never spoke of at our company. Besides, the truth is that entrepreneurship isn't all fun and games. It's hard work. Late nights, ramen, and analyzing enterprise publishing platforms that aim to crowdfund financial in-line streaming data. Add in to the loop seed-stage firms and you've got yourself a value-added venture with an all-star team.

While acquisitions are on the rise, you may look back on the time you spent cranking away on embedable desktop licensing structures that engage with your fans. Clever yet simple products that connect wirelessly to your API. But you have to always remember never to use borders on iOS7 buttons. Doing so only increases the burn rate of your face.

Capital has never been so widely distributed among co-founders working to disrupt how doctors engage with the sharing economy. To the point that revenue is an on-demand cliché. Cloud services cannot be expected to survive in this competitive landscape, and that is why we pivoted.

It's a totally new landscape, and I finally realized that. I love this industry, and I can only thank that one subway ride that changed my life.

Bitter Sweet Symphony

2013-08-19T00:00:00Z

Yesterday, I stumbled across an old UNKLE remix of Bitter Sweet Symphony, which, of course, reminded me of the original version by The Verve. I'm not ashamed to admit that Bitter Sweet Symphony is probably one of my favorite songs. I was around 18 or 19 when it came out, and at the time, my friends and I were in London. I remember hearing it everywhere. And when I say everywhere, I mean everywhere. I once walked down a random little street and heard it blasting from a tiny coffee shop. The entire street was filled with those soaring violins. I was young, in London, feeling rebellious, and that song just amplified everything I was feeling. Listening to it the other day made me smile, instantly transporting me back to what feels like a completely different life, a completely different time.

After a few very loud listening sessions (and successfully driving my wife and daughter crazy), I remembered that Bitter Sweet Symphony's iconic melody wasn't actually written by The Verve. Its signature hook was based on the Andrew Oldham Orchestra's instrumental version of a Rolling Stones song called The Last Time, which itself was based on a song by The Staple Singers called This May Be the Last Time, which was inspired by an even older gospel song. Musical inception.

Unfortunately, even though The Verve had legally licensed the Andrew Oldham Orchestra's violin hook, they ran into legal trouble because the vocal melody closely resembled the Rolling Stones' version. Since they had only secured rights to the violin sample, but not the vocal melody, they got sued by the Rolling Stones' lawyers. In the end, Bitter Sweet Symphony wasn't credited to Richard Ashcroft but to Jagger and Richards.

Now, I'm no lawyer, but in my opinion, Bitter Sweet Symphony is better than all the previous versions combined. Honestly, I don't care if The Verve were inspired by, or even outright ripped off, the original. I love that damn song. It represents a time in my life that I cherish, and no amount of legal battles or accusations of plagiarism will ever change that. The Verve took something incredible, tweaked it, and made it their own. They created a classic.

So where does that leave us? I love a song that was "ripped off" from another song that was ripped off from another song. Is that morally okay? Should I love the original version instead? Does it matter that they licensed one part of the melody but not another? Or… maybe none of that matters. Maybe taking an existing creation and reworking it, even if only slightly, is completely fine. Maybe that's just the nature of art. The nature of creation itself.

Or maybe I'm just overthinking it.

It's just a song.

…Or is it?

The Wall

2011-12-06T00:00:00Z

The year was 2004. I was 25, and after several years "in the internet business," I decided it was time to go backpacking in Thailand. I was getting tired of my routine: working as a designer for years while all my friends were off traveling the world. It pissed me off. I was young, dammit! I should have been hopping from one exotic place to another, soaking up every minute of my youth, not stuck in an office.

Unable to take too much time off, I managed to squeeze in a little over a month, packed my bags, and flew to Thailand.

Landing in Bangkok was exhilarating. It was my first time in Southeast Asia, and it was unlike anything I had ever experienced. If you haven't been to Bangkok, it's massive. Just the drive from the airport to the city felt like an adventure: the highways packed with cars, the thick smog in the air, the endless skyline of towering buildings. It reminded me of The Fifth Element, but with a gritty, Blade Runner edge. It was chaotic, overwhelming, and completely thrilling.

A good friend of mine was also backpacking through Thailand at the time, and as luck would have it, he was in Bangkok the day I arrived. Before we had left home, we made a loose plan: the minute I landed, I'd head straight to our pre-arranged meeting spot. He had a flight that evening, so we only had a few hours to grab a beer and catch up. This was 2004; we were backpacking through Southeast Asia. The idea of carrying a cellphone with us was laughable.

But then Bangkok completely swept me away. Instead of heading to meet my friend, I impulsively hopped into a tuk-tuk and went straight to a local flea market, eager to take it all in. I didn't even care that I was lugging my entire backpack around. The intoxicating mix of sizzling mystery-meat skewers from street vendors, bars spilling happy travelers onto the streets, stalls selling cheap Asian statues, beggars asking for change. It all just felt right. Oddly enough, I felt at home. I fully embraced the moment.

After a couple of beers and some friendly conversations with locals, it suddenly hit me. My friend! Shit! I had completely forgotten. He was going to kill me. I shoved the last bite of my critter-on-a-stick into my mouth, downed my beer, and sprinted toward the nearest tuk-tuk, praying he'd still be there. Bangkok's notorious traffic wasn't on my side, and even with a kamikaze tuk-tuk driver, it took me nearly 40 minutes to reach our meeting spot. I braced myself, expecting to find an old friend furious enough to knock me back into reality.

After finally arriving, I tipped the driver way too much and ran inside. Our meeting point was a well-known backpacker hostel: a chaotic compound that had everything: a chill restaurant (well, calling it a restaurant was generous; it was more like a place to grab food), dorm rooms, a scuba gear rental, luggage storage, and more. It was packed, and as I searched the crowd, I had a sinking feeling that I had missed him.

After half an hour of wandering through the hostel, I gave up. Sweaty, exhausted, and deflated, I sat down to cool off with a beer. The heat was brutal, and there was no AC.

Turned out, sitting down was the best decision I could have made. The people at the next table were super friendly, and we started chatting. I told them my story and described my friend: a tall, bald guy with a smallish head and dark skin. They hadn't seen him, but one of them pointed toward a wall behind the bar.

"The wall?" I asked.

They nodded.

I got up and walked over, noticing as I got closer that it was plastered with handwritten notes. Each note had a name at the top, followed by a message. Suddenly, it clicked: this was an old-school communication hub, a place for travelers to leave messages for friends in an era before smartphones. My heart started racing. What if my friend left me a note? I scanned the wall, feeling like a kid on a treasure hunt.

And there it was, bottom left corner, nearly at the edge. My name, scrawled in big letters. I pulled the tack out and unfolded the paper.

It was short and sweet:

"YARON, you bastard, where you at? Ah, no worries! I'm sure you're out there enjoying yourself. The only thing I can say is that Thailand is AMAZING! Have fun. See ya at home. P.S. Go cliff jumping in Ko Phi Phi, it's pretty amazing."

That was it. A simple note. Today, this message would have landed in my inbox instantly. But this was different: I had to find it. I had to be lucky enough to stumble upon it. My friend had left it with no certainty that it would ever reach me, like a message in a bottle, hoping it would make it to shore. It wasn't a text notification buzzing in my pocket. There was no convenience, no instant gratification. And because of that, it felt almost romantic (in a totally manly way, of course). It was a feeling I hadn't had in years, since before cell phones were in every pocket and the internet was in every home.

In that moment, I felt more alive than I had in a long time.

I went on to have countless adventures throughout Thailand. Yes, I did go cliff jumping in Ko Phi Phi, just like my friend suggested, and I broke two ribs and cracked a vertebra. But no worries, my pain tolerance is high, and I didn't even realize I was injured. I kept traveling. True story.

One day, we'll grab a beer, and I'll tell you all about the crazy things that happened on that trip. But for some reason, the moment that made it all real, the moment that has stuck with me the most, was standing in that hostel in Bangkok, reading a note on the wall.

The Virtual Designer

2011-03-21T00:00:00Z

Our favorite Monday night TV show, by far, is Antiques Roadshow. Adva (my wife) and I never miss an episode. Each week, specialists from leading auction houses and independent dealers from across the country offer free appraisals of antiques and collectibles. Since Adva is about to graduate with a degree in Art History and I am a designer, we both love seeing the fascinating art and design pieces people bring to the show: everything from family heirlooms to garage sale finds, from 17th-century piano stools to a laugh machine from the '60s.

While watching the show a few weeks ago, I had a thought: how amazing would it be if, 150 years from now, my great-great-grandson brought one of my designs in for appraisal? But after a moment of reflection, I realized that could never really happen. I can count on one hand the number of site designs that have lasted more than a decade without a redesign, one that usually erases all traces of the original. A 150-year-old web design? That seems impossible.

It made me a little sad to think that my designs aren't built to last beyond a decade at best, that they are, by nature, temporary. This should have been obvious to me throughout my career (and maybe it was, subconsciously), but I had never truly confronted it. Compared to the incredible posters, furniture, and other tangible designs featured on the show, the reality became crystal clear. How did I miss this?

After shedding a few virtual tears and ranting on Twitter, another question came to mind: what does this mean for us as web designers?

Then I read Mandy Brown's article, which really resonated with me. She advocates for preserving web content, for shielding it from digital decay, not just through technological solutions but through sheer will. Technically speaking, I believe preserving content is achievable. Text, images, and videos can be converted into different formats or even physical objects (printed on paper, stored on film) if necessary. But as a designer, what interests me most is not just the content, but the design itself.

Web design (or more broadly, screen and interface design) is uniquely dependent on the technology it's built upon. And technology evolves so quickly that maintaining seamless backward compatibility for, say, 150 years, feels nearly impossible. Flash, once ubiquitous, is now dead. Who's to say what will remain in 200 years? When the technology disappears, the designs built on it vanish into the same digital void from which they emerged.

Unlike other forms of design, web design cannot easily be transferred to a physical medium. It relies on interaction (hovers, notifications, dropdowns, animations), all of which cease to function once removed from their technological context. A painting or a chair can be displayed in a museum, but a website without its underlying technology is just a collection of disconnected assets.

So, can we all agree that appraising websites will never happen? And if so, are we okay with that? Do we accept that what we create exists solely in a virtual world, destined to disappear? If preservation is impossible without a new solution, what does that mean for us as designers?

I'm starting to believe this is one of the biggest distinctions between web design and other design fields, particularly print, to which it is often compared. In some ways, web design has more in common with cake design, stage design, or window displays: things that are meant to be experienced in the moment and then fade away. Cakes are eaten, sets are dismantled after the show, window displays change with the seasons. Their beauty lies in their temporariness.

Is that why we've never had a universally agreed-upon masterpiece of web design? Will we ever? And if we do, how would it be preserved and referenced? Could this be why so many designers are caught up in fleeting trends? Should we be thinking about internet museums? If web design were more permanent, would designers focus less on trends and more on creating something timeless? And can web design even be timeless?

I don't have the answers, only more questions. But I'm increasingly convinced that the temporary nature of our work is one of the defining characteristics of web design. Sure, technical aspects like screen sizes and interactivity set us apart from other fields, but maybe it's time to dig a little deeper.