So as I'm currently sitting on my flight home from ETH Bogotá, I figured it would be fun to write something. Flesh out some thoughts that crossed my mind this past week.

No giga-brain insights, but rather some guiding principles for designing in web3. Hopefully someone out there will enjoy it.

Time to hit that publish button.

Designing products in web3 means designing products that haven't been done before. We're collectively trying things out, exploring patterns, and finding out what sticks. To keep the momentum up during these explorative stages of the space, learning how to draft and iterate on ideas faster will be key.

For most people, the design process is split into two phases: drafting and editing. In the drafting phase, the goal is generally to get out of your way to get something onto the screen (or whatever medium you prefer). However that looks for you, this phase is crucial to seizing your most important ideas and preserving them for future rearrangement.

When you can draft quickly—you can start editing sooner. When you can start editing sooner, you can share more designs with people. And the more designs you can share, the more feedback you can receive, the better your ideas (and final products) will become.

And the best part? Designing quickly is, i.e., a compounding skill. Faster iteration cycles means more opportunities to learn, improve, and ship.

As web3 intersects finance, distributed infrastructure, and socio-technical systems in ways we haven’t seen before, teams should seek to build a team of overlapping multidisciplinary members.

In my experience, I've been able to run the furthest, the fastest, and had the most fun, when collaborating with people in complementary roles. Where we each took the time and effort to speak each other's language and build a shared sense of what we're working towards.

So should designers code? Write copy? Understand the sales pipeline? Interview users? Read the data? Yes.

It's just that it's not practical to try to be the one person who does all of these things day-to-day in any meaningful capacity. But if you can be the bridge between these teams, and not feel alienated by their different lingoes, you’ll gain a lot.

It's easy to add more features: slap a button here, throw in a disclaimer there, and pin an explainer tooltip on everything. It's not so easy to take those things away.

Educating people about new features or changes is tough. And it's even harder to dismiss a loudly-requested feature for reasons that users might not easily understand.

Designing quality UI is knowing when to add features. Knowing when something works well and when to take things away, especially if a feature is no longer in service of a broader vision.

This past week I’ve seen too many can-do-it-all products showcased; DeFi products with more features than the G Suite, NFT projects with twelve different utility verticals, and alternative layer ones claiming to be better at pretty much everything. I.e. products trying to do everything—but end up doing nothing.

One thing I’ve learned from participating in, and sometimes winning, hackathons is to always scope down your products. Start by identifying one tiny problem, friction, or annoyance you’ve thought about, and begin with solving just that super smooth.

Quality software is fast. Data is cached. The first paint feels instant. Interactions respond in milliseconds. Simplicity and narrowing things down to the core is everything.

Designers who became experts at mobile screen design in 2008 and 2009 are likely at the top of their game today. They are designing solutions for a massive number of people, and their skills are easily transferrable between industries, companies, and products.

Today, we can observe similar opportunities in web3. And as the space expands, the foundational tools we have access to will flourish. From new standards, to protocols, to frontend libraries—we continue to invent new and exciting primitives that unlock the ability to solve new kinds of problems.

Those who make it a habit to examine the latest trends, details, and product decisions will more likely be able to push the limits of their own products further.

Prioritize attending conferences, hackathons, and talks within your interest. Wherever you are in life right now, occasionally throwing yourself into 48h sprints with like-minded frens, new tools, and red bulls is an efficient method for staying up-to-date.

Thank you and stay blessed. Let me know what you think and feel free follow me on Twitter.

So as I'm currently sitting on my flight home from ETH Bogotá, I figured it would be fun to write something. Flesh out some thoughts that crossed my mind this past week.

No giga-brain insights, but rather some guiding principles for designing in web3. Hopefully someone out there will enjoy it.

Time to hit that publish button.

Designing products in web3 means designing products that haven't been done before. We're collectively trying things out, exploring patterns, and finding out what sticks. To keep the momentum up during these explorative stages of the space, learning how to draft and iterate on ideas faster will be key.

For most people, the design process is split into two phases: drafting and editing. In the drafting phase, the goal is generally to get out of your way to get something onto the screen (or whatever medium you prefer). However that looks for you, this phase is crucial to seizing your most important ideas and preserving them for future rearrangement.

When you can draft quickly—you can start editing sooner. When you can start editing sooner, you can share more designs with people. And the more designs you can share, the more feedback you can receive, the better your ideas (and final products) will become.

And the best part? Designing quickly is, i.e., a compounding skill. Faster iteration cycles means more opportunities to learn, improve, and ship.

As web3 intersects finance, distributed infrastructure, and socio-technical systems in ways we haven’t seen before, teams should seek to build a team of overlapping multidisciplinary members.

In my experience, I've been able to run the furthest, the fastest, and had the most fun, when collaborating with people in complementary roles. Where we each took the time and effort to speak each other's language and build a shared sense of what we're working towards.

So should designers code? Write copy? Understand the sales pipeline? Interview users? Read the data? Yes.

It's just that it's not practical to try to be the one person who does all of these things day-to-day in any meaningful capacity. But if you can be the bridge between these teams, and not feel alienated by their different lingoes, you’ll gain a lot.

It's easy to add more features: slap a button here, throw in a disclaimer there, and pin an explainer tooltip on everything. It's not so easy to take those things away.

Educating people about new features or changes is tough. And it's even harder to dismiss a loudly-requested feature for reasons that users might not easily understand.

Designing quality UI is knowing when to add features. Knowing when something works well and when to take things away, especially if a feature is no longer in service of a broader vision.

This past week I’ve seen too many can-do-it-all products showcased; DeFi products with more features than the G Suite, NFT projects with twelve different utility verticals, and alternative layer ones claiming to be better at pretty much everything. I.e. products trying to do everything—but end up doing nothing.

One thing I’ve learned from participating in, and sometimes winning, hackathons is to always scope down your products. Start by identifying one tiny problem, friction, or annoyance you’ve thought about, and begin with solving just that super smooth.

Quality software is fast. Data is cached. The first paint feels instant. Interactions respond in milliseconds. Simplicity and narrowing things down to the core is everything.

Designers who became experts at mobile screen design in 2008 and 2009 are likely at the top of their game today. They are designing solutions for a massive number of people, and their skills are easily transferrable between industries, companies, and products.

Today, we can observe similar opportunities in web3. And as the space expands, the foundational tools we have access to will flourish. From new standards, to protocols, to frontend libraries—we continue to invent new and exciting primitives that unlock the ability to solve new kinds of problems.

Those who make it a habit to examine the latest trends, details, and product decisions will more likely be able to push the limits of their own products further.

Prioritize attending conferences, hackathons, and talks within your interest. Wherever you are in life right now, occasionally throwing yourself into 48h sprints with like-minded frens, new tools, and red bulls is an efficient method for staying up-to-date.

Thank you and stay blessed. Let me know what you think and feel free follow me on Twitter.