While on my Peru trip earlier this year, I read a great book called Product Design for the Web: Principles of Designing and Releasing Products for the Web.

As one of two interaction designers who joined Etsy in 2010, Randy Hunt, now creative director, has written the book on best practices of product development for successful modern-day Internet companies. I highly recommend it.

I sat down with Randy recently to learn more about his perspective on product design. But before I jump into that conversation, here’s a brief look at some of the big ideas from the book:

TAKEAWAYS FROM PRODUCT DESIGN FOR THE WEB BY RANDY HUNT

Note: these are not direct quotes but pretty close paraphrases

I started a Substack! New issues go out every Saturday

Great products are understandable (set expectations and live up to them) and meaningful (help people solve problems or accomplish goals) and, hopefully, delightful

(set expectations and live up to them) and (help people solve problems or accomplish goals) and, hopefully, It can be helpful to reimagine your product spec as a press release defining what the update is, who it is for and why it matters

the update is, it is for and it matters Watch and observe people because what they say they do is often very different from their actual behavior

Design flows, not screens — when users complete a task (like signing up), make sure there are pathways for them to continue down (discover new products, find friends, etc)

— when users complete a task (like signing up), make sure there are pathways for them to continue down (discover new products, find friends, etc) Reward users with success from the earliest possible interaction. Reward what you want repeated.

with success from the earliest possible interaction. Reward what you want repeated. Prioritize the effective over the clever. Use naming schemes that are descriptive vs metaphoric

over the clever. Use naming schemes that are descriptive vs metaphoric There are no silver bullets . It is the cumulative effect of lots of little improvements that create successful products.

. It is the cumulative effect of lots of little improvements that create successful products. Share your ideas early and often – your designs don’t need to be saved for a big reveal

– your designs don’t need to be saved for a big reveal Don’t forget about the “invisible features” like speed, security, reliability and support

like speed, security, reliability and support Designers should prototype using tools (platform, code) that most closely matches up with what goes into production

A framework such as Problem-Strengths-Weaknesses-Tenets can help the product team discuss and get aligned on projects

can help the product team discuss and get aligned on projects Big teams don’t work . The optimal team size is about 4-7 people.

. The optimal team size is about 4-7 people. Don’t forget to prepare the communication for new features (product marketing, support, etc)

for new features (product marketing, support, etc) Be clear about your designs’ desired outcomes and measure the results after launch to see how you did

and measure the results after launch to see how you did Small repetitive cycles of design-test-release-evaluate drives greater team and customer satisfaction and help us learn and improve faster

of design-test-release-evaluate drives greater team and customer satisfaction and help us learn and improve faster The product is always a work in progress — never get too attached to any particular element because it may (and probably will) change

— never get too attached to any particular element because it may (and probably will) change Change makes people uncomfortable. A designer’s job is to help people experience change as comfortably as possible

A CONVERSATION WITH RANDY HUNT

The book goes into way more detail and nuance than just that list posted above, but right away you have a sense of Randy’s approach. After I finished the book, I wanted some clarification on some of his ideas so I got in touch with Randy and he graciously sat down with me at Etsy HQ in Brooklyn, NY. Here are some of the highlights from that conversation:

Does Etsy use a lot of personas? Do you feel there’s a range of folks and how do you think about different user types?

It’s not like we sit at the executive level and talk about any particular personas. We’re not oriented that way at that high level. That’s not to say they don’t come into play on a project level sometimes, or with a team or an initiative. We do think about them.

A common one, not only for Etsy but anything that is a two-sided marketplace, is that we have two sets of customers, buyers and sellers, there’s overlap there, but they’re two very different sets of circumstances. We’d start things there.

Then within them there’s ones based on degree of engagement or awareness. On the shopping side it’s basically someone who has never heard of Etsy before versus someone who’s made a purchase.

You slice them in different cultural environments. Brand new to Etsy in France brings some different expectations with it than brand new to Etsy in North America.

You talk about validating hypotheses with users in the book. How do you do that Etsy? Is there a lot of launching a new feature to a small set of users?

Yep, it feels like like a fairly dominant way because one of things we got good at early on and we have a lot of infrastructure and expertise around it. Let’s put this idea in front of people and see how it works. It’s certainly not the only way. There’s also a lot of different reasons why it makes sense.

There’s that part, which is sort of learn, experiment, and test, collect data and validate hypotheses. But we also see percentage release as a methodology where we don’t just turn things on. It allows for the safe, secure, stable releasing of things.

We look at performance issues or communication issues. Okay, great, let’s tackle those things over the next handful of days. It might be something that has to simultaneously release to both a buyer and a seller. It might take some transaction for this. So let’s get a cohort of people and opt them to this.

You talked about how Amazon’s product team writes the press release (“Today, Amazon releases X product that helps Y people do Z thing”) before they really start going after the product. Is that something that you guys do? How closely do you model after that?

Across Etsy, the process varies a bit, as it always does with a complex organism. There are different versions of that. The purest form, “I’ve literally written the press release”, is a small percentage of the time. One of the advantages of it is that at the beginning, it requires you to think of the end, the benefit to a person. It really sets up a people-centric idea. Also it gets you in the headspace of “What is exciting or promotable about this idea?”

The other thing it does is express intent. What I intend to see happen, what I intend to change about people’s experience, how I intend to talk about it, what time I intend to release it. Then these things start to align, people’s desire plus your ability to execute it.

It’s like how writing a business plan is not that useful for your startup except in that it forces you to answer all these questions

Totally. It is the act of the creating that puts you in the right mindset.

You describe a framework that you use at Etsy focusing around Problems-Strengths-Weaknesses-Tenets. I get identifying problems: “X% of people fall out of the shopping cart without buying.” But how do you know what the strengths or the tenets?

Let’s say it’s the checkout problem you were describing. We take this process too iteratively. We might post it on a project management system or go to a meeting with it. We might say, “I actually don’t think that problem is what we want to address right now.” and have a discussion about that.

A strength might be “We have examples in three other projects of boosting conversion rate simply by rearranging elements on the page.” or it is circumstantial like, “The designer from such and such team has some extra time over the next free weeks”

Yeah so it’s like, why are we doing this? Why are we going to be successful?

Yeah. Another strength might be … what’s one that came up the other day? “We already have established patterns for doing this responsive header on marketing pages like this. So we already have something we can use.”

And the tenets are like, “We’re only going to use use that asset we already built.”

Tenets are like constraints

You got it. Maybe it is “We aren’t going to introduce any new UI elements” or we’ll acknowledge that it is going to have a performance impact but we aren’t going to address it now. It’s helpful to have something outside of the thing you are making that you can look at and agree on. And so here that something is basically a couple bulleted lists and everyone can see it.

So when the engineer says “the performance is going to be crazy” the designer can say “That’s right, I said going in I wasn’t going to worry about it.” It’s still an opportunity for conversation. You can say we’re not going to release it until we make performance better. That’s still fair.

In the book you talk about a situation at Etsy where you built a feature called Circles* where you add people into “your circle” and users got pretty confused. But sometimes you have to invent a word – like “tweet” for Twitter or “recipe” for IFTTT. How do you know when to push a new concept versus following the existing paradigm?

Great question. I think it’s an appropriate consideration when it’s a core, fundamental part of the product. I think creating networks of people is such a basic part of the Internet that it seems silly to create a branded terminology unless your explicit intent is to somehow enter that space and fundamentally change it.

Like it might make sense to have a different name for your network and your friends if you are trying to unseat Facebook and be the people network.

So I think the choice of “recipe” for IFTTT is a little odd… because I somehow expect even more cooking metaphors? But it works! They’ve got this unique name for their unique offering.

One last question: What do you feel you have learned in the process of writing your book?

With product design I would say there is so much nuance in there. I think to write a book about it you have to have a point of view. You don’t need the most comprehensive thing, like a “How do you make Internet?” wiki would just go on forever.

I have a point of view that I prefer more than others, but it’s not absolutist. It’s not buttoned up like “this is the truth.” You have to have some general principles that you check yourself against. We have a preference towards faster and sooner.

–

Randy’s book, Product Design for the Web, is available on Amazon.