Episode 283: Devconnect 2025 with Nuno Loureiro ๐Ÿ”— **Source:** [Episode 283: Devconnect 2025 with Nuno Loureiro](https://www.youtube.com/watch?v=XDwn9Syk62U) > [!note]+ Document Notes > tags: [ethereum, design, open-source, sustainability, ux, devconnect] > author: Sustain OSS > source: Sustain OSS Podcast > reference: https://www.youtube.com/watch?v=XDwn9Syk62U > date created: 2024-12-19 10:30 > > # ๐Ÿท๏ธ Title: Episode 283: Devconnect 2025 with Nuno Loureiro > <!-- deep-read:sections start --> ## ๐Ÿงฐ Action Inbox - [H1] Open source design systems for community collaboration โ€” exploring collaborative design frameworks #design - [H2] Address UX as primary blocker for open source mass adoption โ€” improve usability barriers #sustainability - [H3] Build trust through design in decentralized systems โ€” reliability and consistency patterns #ethereum ## ๐Ÿงญ Table of Contents - [๐Ÿ“ Summary](#-summary) - [๐Ÿ“– Main Content](#-main-content) - [๐Ÿ—’๏ธ Notes](#๏ธ-notes) - [๐Ÿ“š References](#-references) - [๐Ÿ—ฃ๏ธ Paraphrase](#๏ธ-paraphrase) - [๐Ÿ“ฐ Newsletter](#-newsletter) - [โœ… Action Items](#-action-items) - [๐Ÿงช Hypotheses](#-hypotheses) - [๐Ÿ“Š Methodology](#-methodology) - [โ“ Questions](#-questions) - [๐Ÿ”ฎ Future Research](#-future-research) - [๐Ÿ’ก Implications](#-implications) - [๐Ÿง  Learning Styles Assessment](#-learning-styles-assessment) - [๐Ÿ“Š Accessibility Assessment](#-accessibility-assessment) - [๐ŸŒ DEIB Assessment](#-deib-assessment) - [โœ… Logical Validity](#-logical-validity) - [๐Ÿ›ก๏ธ DARVO Analysis](#-darvo-analysis) - [๐ŸŽฏ Conclusion](#-conclusion) ### ๐Ÿ”— References - [Sustain OSS Podcast](https://podcast.sustainoss.org/) - [Penpot](https://penpot.app) ## ๐Ÿ“ Summary - Sustain OSS podcast interviews Nuno Loureiro, lead designer at Ethereum Foundation, at DevConnect in Buenos Aires - Covers design challenges in open source, particularly around community collaboration and mass adoption barriers - Discussion centers on UX as the primary blocker for open source adoption and the unique challenges of designing for decentralized systems - Key stakeholders include designers, open source maintainers, and the Ethereum community - Bottom line: Design and UX improvements are critical for open source sustainability and mass adoption ## ๐Ÿ“– Main Content Nuno Loureiro serves as lead designer for the Ethereum Foundation, primarily focused on ethereum.org as a learning platform. His role has expanded from website design to broader communication and design system challenges across multiple Foundation projects. The conversation explores fundamental tensions in open source design work. Unlike traditional software development contributions through pull requests, design collaboration proves significantly more complex. Loureiro identifies this as a systemic issue affecting open source sustainability. A central theme emerges around trust and reliability in user experience. Ethereum founder Vitalik Buterin's emphasis on consistent performance (avoiding scenarios where the same action takes 10 seconds, then 2 minutes, then 10 minutes) reflects broader UX priorities. The Foundation has adopted three core mantras: scale L1 (core protocol), scale L2s (satellite networks), and improve UX. The decentralized nature of Ethereum creates unique design challenges. The Foundation doesn't control the protocol roadmap or user-facing applications, instead coordinating with community teams who build actual user interfaces. This distributed approach complicates traditional design feedback loops and user research. ## ๐Ÿ—’๏ธ Notes #### โฑ๏ธ [00:00](https://youtu.be/XDwn9Syk62U?t=0) โ€” [H1] Introduction and Context - Key idea: Sustain podcast recording at DevConnect Buenos Aires with Ethereum Foundation - Evidence: "We've been invited by the Ethereum Foundation to have some interesting conversations about sustaining open source" #### โฑ๏ธ [02:30](https://youtu.be/XDwn9Syk62U?t=150) โ€” [H2] Nuno's Role at Ethereum Foundation - Key idea: Lead designer focusing on ethereum.org learning platform and broader Foundation design needs - Evidence: "I joined the foundation three plus years ago to focus on ethereum.org... a portal or a website where you can learn everything about Ethereum" #### โฑ๏ธ [04:45](https://youtu.be/XDwn9Syk62U?t=285) โ€” [H3] Design System Collaboration Challenges - Key idea: Open sourcing design systems for community collaboration proves difficult - Evidence: "I wanted to on board so I open source as much as I could the process of creating the design system itself" #### โฑ๏ธ [06:20](https://youtu.be/XDwn9Syk62U?t=380) โ€” [H2] ZK Proofs Portal Design Challenge - Key idea: Building competitive comparison interfaces for zero-knowledge proof providers - Evidence: "building a need proofs a portal for ZK proofs where different providers of the technology needs to be under the same platform" #### โฑ๏ธ [07:15](https://youtu.be/XDwn9Syk62U?t=435) โ€” [H1] Design as Primary Open Source Adoption Blocker - Key idea: Poor UX prevents mass adoption despite functional software - Evidence: "From my perspective, it's the biggest blocker for mass adoption of the open source software" #### โฑ๏ธ [08:30](https://youtu.be/XDwn9Syk62U?t=510) โ€” [H3] Designer Collaboration Difficulties - Key idea: Designers struggle more than developers with open source collaboration - Evidence: "we designers do it even worse than developers we are the worst collaborators" #### โฑ๏ธ [10:45](https://youtu.be/XDwn9Syk62U?t=645) โ€” [H2] Design Education and Hierarchy Issues - Key idea: Traditional design education emphasizes hierarchy over collaboration - Evidence: "You learn that you have someone above you that tells you what to do or a client tells you what to do" #### โฑ๏ธ [12:20](https://youtu.be/XDwn9Syk62U?t=740) โ€” [H2] Vulnerability in Open Source Design - Key idea: Attachment to work makes designers reluctant to accept criticism - Evidence: "sometimes I think that it's hard for both coders and designers to really be vulnerable and open up those conversations for criticism" #### โฑ๏ธ [14:10](https://youtu.be/XDwn9Syk62U?t=850) โ€” [H1] Reliability and Trust in UX - Key idea: Vitalik emphasizes consistent performance as core UX principle - Evidence: "if a user tries to do something on a platform and the first time it takes 10 seconds, the second time it takes 2 minutes and the third time it takes 10 minutes" #### โฑ๏ธ [15:45](https://youtu.be/XDwn9Syk62U?t=945) โ€” [H2] Ethereum Foundation's Three Mantras - Key idea: Scale L1, scale L2s, and improve UX as organizational priorities - Evidence: "scale L1, the core protocol... scale the L2s which is the satellite networks... and then third it's improve UX" #### โฑ๏ธ [17:30](https://youtu.be/XDwn9Syk62U?t=1050) โ€” [H3] Web3 Ownership Paradigm - Key idea: Web3 represents shift from read/write to read/write/own model - Evidence: "Web One was just read. Web two was read and write... web three is own. How do you own your own stuff online" #### โฑ๏ธ [19:15](https://youtu.be/XDwn9Syk62U?t=1155) โ€” [H2] Decentralized Design Decisions - Key idea: Foundation coordinates rather than controls design narratives - Evidence: "we don't own the project. Those conversations are not within the foundation are within the community" #### โฑ๏ธ [21:00](https://youtu.be/XDwn9Syk62U?t=1260) โ€” [H3] Feedback Through Third Parties - Key idea: User feedback comes through community projects and wallet teams - Evidence: "We rely on a lot of different third parties, a lot of the community projects that has his own design teams" #### โฑ๏ธ [22:45](https://youtu.be/XDwn9Syk62U?t=1365) โ€” [H2] Penpot Recommendation - Key idea: Spotlighting Penpot as promising open source design tool - Evidence: "Penpots... I've been using and I think it's a really good one. Really, really good for design, changing the landscape" ## ๐Ÿ“š References - [Sustain OSS Podcast](https://podcast.sustainoss.org/) - [Ethereum Foundation](https://ethereum.org/) - [Penpot](https://penpot.app) - [DevConnect Conference](https://devconnect.org/) ## ๐Ÿ—ฃ๏ธ Paraphrase - Design collaboration in open source faces unique barriers compared to code contributions, with designers struggling more than developers to work in community-driven environments - User experience quality serves as the primary obstacle preventing mass adoption of open source software, despite technical functionality being adequate - Decentralized governance models create complex design coordination challenges, requiring new approaches to user research and feedback collection across distributed teams ## ๐Ÿ“ฐ Newsletter Exciting insights from DevConnect on designing for open source sustainability! Nuno Loureiro from the Ethereum Foundation shares how UX barriers prevent open source adoption and why designers face unique collaboration challenges. Key takeaways: Traditional design education emphasizes hierarchy over collaboration, making community-driven projects difficult. However, focusing on reliability and trust through consistent user experiences can drive adoption. The Ethereum Foundation's three-pillar approach (scale core, scale networks, improve UX) shows how major projects prioritize design. Their decentralized model offers lessons for coordinating design across distributed teams. Check out Penpot for open source design tooling that's changing the landscape! Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## โœ… Action Items #### DevRel - Developer experience: Research design system patterns for community contribution workflows - Education: Create workshops on collaborative design practices for open source projects - Developer marketing: Document case studies of successful design/developer collaboration #### Community - Contributors: Develop onboarding materials specifically for designers entering open source - Maintainers: Create governance templates for design decision-making in decentralized projects - Sponsors: Fund design system initiatives that support multiple projects #### WordPress - Design: Conduct UX audits focused on reliability and consistency across core experiences - Community: Establish design mentorship programs connecting agency designers with open source projects - Training: Develop learning paths for designers contributing to open source ## ๐Ÿงช Hypotheses - Design systems optimized for community collaboration increase designer participation in open source projects - Consistent performance metrics (response times, reliability) correlate with user trust and adoption - Decentralized design coordination models can maintain quality while enabling distributed contribution - Traditional design education creates barriers to open source collaboration that require targeted intervention ### ๐Ÿ“Š Methodology - Survey designers about barriers to open source contribution and test targeted onboarding interventions - Measure user trust metrics against performance consistency across different open source tools - Compare design quality outcomes between centralized and decentralized governance models - Analyze correlation between design system openness and community contribution rates ### โ“ Questions - How can design systems be structured to enable meaningful community contribution while maintaining coherence? - What specific performance consistency metrics most strongly predict user adoption in open source tools? - How do decentralized organizations balance design vision with community input? ### ๐Ÿ”ฎ Future Research - Development of collaborative design frameworks specifically for open source contexts - Investigation of trust-building mechanisms in decentralized user experiences - Exploration of designer onboarding patterns that overcome traditional hierarchy expectations ### ๐Ÿ’ก Implications - Practice: Design teams need new collaboration models for community-driven development - Policy: Open source governance should explicitly address design decision-making processes - Education: Design curricula should include collaborative and community-driven project methodologies - Funding: Grants should specifically support design system initiatives that enable community contribution ### ๐Ÿง  Learning Styles Assessment Reading level estimate: 12th grade #### ๐Ÿ‘€ Visual learners - Present: Conceptual discussion of design systems and user interfaces - Improve: Diagrams showing decentralized design coordination, UX flow examples #### ๐Ÿ”Š Aural learners - Present: Podcast format with conversational explanation of concepts - Improve: Audio examples of user interaction patterns, sound design considerations #### ๐Ÿ—ฃ๏ธ Verbal learners - Present: Clear definitions of Web3, L1/L2 concepts, design system terminology - Improve: Analogies comparing traditional vs. decentralized design processes #### ๐Ÿงฉ Kinesthetic learners - Present: Discussion of hands-on design system creation process - Improve: Step-by-step guides for contributing to open source design projects #### ๐Ÿง  Logical learners - Present: Three-pillar organizational framework, cause-effect relationship between UX and adoption - Improve: Decision trees for design governance, metrics dashboards for trust/reliability #### ๐Ÿง‘โ€๐Ÿคโ€๐Ÿง‘ Social learners - Present: Community collaboration challenges and solutions discussion - Improve: Forums for designer collaboration, peer review processes for design contributions #### ๐Ÿง˜โ€โ™€๏ธ Solitary learners - Present: Individual reflection on design collaboration challenges - Improve: Self-assessment tools for design contribution readiness, personal portfolio development guides #### ๐ŸŒฟ Naturalistic learners - Present: Ecosystem thinking about design in decentralized networks - Improve: Biological analogies for distributed design systems, sustainability connections ### ๐Ÿ“Š Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive content organization - Improve: Alt text for design system examples, ARIA labels for interactive design elements #### Keyboard navigation - Present: Standard podcast interface navigation - Improve: Keyboard shortcuts for timestamp navigation, accessible design tool recommendations #### Contrast and readability - Present: Standard podcast player interface - Improve: High-contrast design system examples, readability guidelines for design contributions #### Text resizing and reflow - Present: Responsive podcast interface - Improve: Scalable design system documentation, flexible layout examples #### Media and captions - Present: Full transcript provided for audio content - Improve: Audio descriptions for design process examples, downloadable transcript with timestamps #### Forms and interactions - Present: Basic podcast controls - Improve: Accessible design contribution workflows, inclusive feedback mechanisms ### ๐ŸŒ DEIB Assessment #### Cultural breadth - Present: International conference setting (Buenos Aires), global Ethereum community perspective - Improve: Examples from diverse cultural contexts, multi-regional design pattern considerations #### Inclusive language - Present: Technical terms explained in accessible language - Improve: Avoid jargon like "junky," provide glossaries for blockchain terminology #### Neurodiversity support - Present: Clear section breaks, consistent interview structure - Improve: Visual summaries of key concepts, multiple format options for design guidelines #### Representation - Present: Designer perspective in traditionally developer-focused space - Improve: Include diverse designer voices, showcase varied cultural approaches to design collaboration #### Psychological safety - Present: Acknowledgment of vulnerability in design criticism - Improve: Guidelines for constructive design feedback, community codes of conduct ### โœ… Logical Validity #### Strong reasoning - Deductive strength: Solid reasoning from UX barriers to adoption challenges - Inductive strength: Good generalization from Ethereum Foundation experience to broader open source challenges - Causal reasoning: Clear connection between design collaboration difficulties and adoption barriers - Analogical strength: Effective email adoption analogy for Web3 mindset shifts #### Fallacies - Hasty generalization: "Designers are the worst collaborators" - overly broad claim without sufficient evidence - False dilemma: Implies traditional hierarchy vs. collaboration as binary choice rather than spectrum #### Tone of voice - Overall tone: Conversational and reflective, with appropriate self-criticism and humility about challenges ### ๐Ÿ›ก๏ธ DARVO Analysis - Deny: No concerning denial patterns observed - Attack: No attacks on accusers present - Reverse victim/offender: No reversal patterns identified - Emotional cues and rhetoric: Healthy self-reflection and acknowledgment of community challenges ## ๐ŸŽฏ Conclusion This conversation highlights design as a critical but underaddressed aspect of open source sustainability. The Ethereum Foundation's experience demonstrates that even well-funded projects struggle with design collaboration and community engagement. The key insight is that UX barriers, not technical limitations, prevent mass adoption of open source tools. Practical next steps --- ## Full Transcript [00:09] Hello and welcome to Sustain, the<br>[00:13] podcast where we talk about sustaining<br>[00:15] open-source software for the longhaul.<br>[00:19] Hi, I'm Errol Fox and with me is<br>[00:22] >> Victory Brown and we're at Dev Connect<br>[00:25] Conference in Buenos Aerys, Argentina.<br>[00:28] We've been invited by the Ethereum<br>[00:30] Foundation to have some interesting<br>[00:32] conversations about sustaining open<br>[00:34] source. Today we have with us Nuno who<br>[00:38] is the lead designer for the Ethereum<br>[00:41] Foundation. Nuno, can you tell us a<br>[00:43] little bit more about what being the<br>[00:45] lead designer in the Ethereum Foundation<br>[00:48] contains entails? Tell us about your<br>[00:50] day-to-day.<br>[00:52] >> Hello. Thank you so much for having me.<br>[00:54] It's a pleasure to be here and to talk<br>[00:55] about the future of open software, open<br>[00:58] source. So I joined the foundation three<br>[01:02] plus years ago to focus on ethereum.org.<br>[01:05] So my background is a lot of digital<br>[01:07] design. I've done a lot of apps and<br>[01:09] whatever comes to your screen. I used to<br>[01:12] do a lot of that and somehow I cross<br>[01:14] paths with the foundation. I have focus<br>[01:16] on the learning platform that is<br>[01:18] ethereum.org. So it's a portal or a<br>[01:21] website where you can learn everything<br>[01:23] about Ethereum. So from the early<br>[01:27] journey where you pick your wallet to<br>[01:28] help you understand what Ethereum is to<br>[01:31] hardcore dev docs where you learn more<br>[01:33] in depth like the tech stack, what it's<br>[01:35] built, how it's built and all that<br>[01:37] stuff. So that was the beginning of my<br>[01:40] journey within the foundation. Then<br>[01:42] things got to grow. I am help a lot of<br>[01:45] more stuff related to design to<br>[01:47] communication building other websites on<br>[01:50] the side for other teams. So we<br>[01:52] bootstrap a lot of other projects all<br>[01:54] based on web. Now we're picking another<br>[01:56] mediums like video a little bit which<br>[01:58] has been fun. It's recent but uh if you<br>[02:01] follow the Ethereum foundation account<br>[02:02] and Ethereum account you'll see a lot of<br>[02:04] more of that but yeah so my role will be<br>[02:07] kind of helping whenever I can whenever<br>[02:09] there's a design challenge to be to be<br>[02:11] faced or<br>[02:13] >> to that statement of design challenges<br>[02:15] in the Ethereum Foundation. What would<br>[02:16] you say are your biggest challenges<br>[02:20] working as the lead designer in the<br>[02:21] Ethereum Foundation? I had a few I had<br>[02:23] one I think this was the one that got us<br>[02:26] close together with open source was I've<br>[02:29] done few design systems back in the day<br>[02:32] and when I joined the aesthetics of<br>[02:35] website was working but we wanted to on<br>[02:38] board designers and I've never done this<br>[02:40] before so I kind of learn by navigating<br>[02:44] sure like I don't know how in English<br>[02:45] the best expression but it's close to<br>[02:47] this and I wanted to on board so I open<br>[02:51] source as much as I could the process of<br>[02:54] creating the design system itself. So we<br>[02:56] had a community of 40,000<br>[02:59] users. A small portion of that were<br>[03:01] designers. We're tackling to them<br>[03:03] mostly. We had contributions for content<br>[03:06] for translations for code. Obviously<br>[03:09] it's the most fun like you open a PR can<br>[03:11] fix a PR was really easy. But for design<br>[03:13] that never happened. And to be fair, I<br>[03:16] never found a good example like this<br>[03:18] because it's not easy to open in a<br>[03:21] design system and have being<br>[03:22] collaborative to other designers. So<br>[03:24] that was probably my challenge that I<br>[03:27] had within the foundation. The other<br>[03:28] ones was more proper product challenges.<br>[03:32] The other one was building a need proofs<br>[03:34] a portal for ZK proofs where different<br>[03:37] providers of the technology needs to be<br>[03:39] under the same platform and competes<br>[03:41] compete quote unquote on this in the<br>[03:43] sense that they we want to be who's the<br>[03:45] fastest who's the best proving in order<br>[03:47] to push the narrative of the ZK. So how<br>[03:50] to present that to the user is a huge<br>[03:52] design challenge.<br>[03:54] >> Well, it sounds like the design team and<br>[03:57] you are busy at the Ethereum Foundation.<br>[04:00] And it sounds like there's plenty to<br>[04:02] improve and make really good for users.<br>[04:05] I guess this is more of a broad question<br>[04:07] around how do you think good design,<br>[04:10] good usability, good design systems<br>[04:12] plays into the idea of making open<br>[04:15] source sustainable.<br>[04:17] >> From my perspective, it's the biggest<br>[04:19] blocker for mass adoption of the open<br>[04:22] source software. I don't have any other<br>[04:25] explanation to this because if you open<br>[04:27] or open other because I know<br>[04:29] there's others tools but close to me it<br>[04:32] feels still kind of junky and it's<br>[04:34] mostly on the user experience because<br>[04:36] the software is there mostly it does<br>[04:39] what it supposed to be. So my clean take<br>[04:42] is design should be the forefront of the<br>[04:45] open source because that's the main<br>[04:47] blocker for the mass adoption of free<br>[04:49] open source tools. Thank you for that.<br>[04:51] You know, and that's really important<br>[04:53] because Errol and I are also designers<br>[04:55] and this is challenges that we face all<br>[04:57] the time. I wanted to ask about like<br>[05:00] what have you done differently because<br>[05:02] again design is one of the<br>[05:03] sustainability mechanisms of open<br>[05:05] source. What have you done to you know<br>[05:07] attract more designers to you know the<br>[05:10] project and also push design<br>[05:12] conversations and make sure that design<br>[05:14] is front and center of this entire<br>[05:16] process.<br>[05:16] >> Unfortunately not enough. I'm sure that<br>[05:19] not enough and that's something that I<br>[05:21] would love to do more when you design<br>[05:24] for more open source balancing<br>[05:27] life where you had a job full-time job<br>[05:30] and have that full-time job some<br>[05:32] compensates the other part of it and<br>[05:34] have time for that it's really hard and<br>[05:36] we designers do it even worse than<br>[05:38] developers we are the worst<br>[05:39] collaborators I have a huge criticism<br>[05:42] for myself included so it's all of us<br>[05:44] how to collaborate on this front how to<br>[05:46] join a project understand the project.<br>[05:48] There are something inherent to a design<br>[05:51] job that it's not 100% compatible of<br>[05:54] community and open collaboration. At<br>[05:57] least from the old design or from the<br>[05:59] one design that we are talked in<br>[06:00] colleges that we learn when you start a<br>[06:02] job, you go to agency or some other<br>[06:05] place. You learn that you have someone<br>[06:07] above you that tells you what to do or a<br>[06:09] client tells you what to do or some VC<br>[06:11] if you're in a startup or something like<br>[06:13] that. And the other way around is gives<br>[06:15] you freedom to start the other way<br>[06:16] around. Start from the beginning. It's<br>[06:19] harder for us designers to get the<br>[06:20] mindset of collaboration. I don't know<br>[06:22] why. I'm not here to explain. I don't<br>[06:24] know why, but it's really hard.<br>[06:27] >> I've thought about this long and hard<br>[06:28] for the seven or eight years I've been<br>[06:30] doing design in open source. And yeah,<br>[06:34] designers really struggle in a different<br>[06:37] way, I think, to coders and developers,<br>[06:40] but we also have this sense of love and<br>[06:44] care for what we do. And I think in open<br>[06:46] source there's a lot of attachment to<br>[06:50] what you build because it's usually<br>[06:53] something you've built in your spare<br>[06:55] time or it's been a really critical<br>[06:57] problem that you've wanted to solve. And<br>[07:00] yeah, sometimes I think that it's hard<br>[07:02] for both coders and designers to really<br>[07:05] be vulnerable and open up those<br>[07:07] conversations for criticism, right? But<br>[07:11] then maybe the thing that we're trying<br>[07:13] to get at here is for the sustainability<br>[07:15] of open source to grow, we have to be<br>[07:18] open in all ways that we collaborate,<br>[07:22] design, code, and be a little bit more<br>[07:25] vulnerable in how we do that. But yeah,<br>[07:29] really interesting challenges and it's<br>[07:31] also somewhat like victory. I don't know<br>[07:34] if you feel this way, but it gives me<br>[07:35] like a sense of confidence that even<br>[07:38] foundations like the Ethereum Foundation<br>[07:40] are having similar problems to smaller<br>[07:41] open source projects. It's actually kind<br>[07:44] of like, oh, we're all having similar<br>[07:46] problems that we're trying to solve. But<br>[07:49] I do have another question actually,<br>[07:50] Nuno, I'm really excited to ask this<br>[07:52] question. So, I was at a talk from the<br>[07:56] funding the commons this morning. It's a<br>[07:59] satellite event at the Devconnect<br>[08:01] conference and Vitilik the founder I<br>[08:04] believe of Ethereum was talking about UX<br>[08:08] in his panel with Robert the co-founder<br>[08:10] of tour and he asked what do we think is<br>[08:15] really important about usability and UX<br>[08:18] and for the Ethereum Foundation he<br>[08:20] talked about how he thought that<br>[08:22] reliability<br>[08:24] for users is really important from the<br>[08:28] sense of if a user tries to do something<br>[08:30] on a platform and the first time it<br>[08:33] takes 10 seconds, the second time it<br>[08:35] takes 2 minutes and the third time it<br>[08:37] takes 10 minutes, then there's<br>[08:38] inconsistent reliability. I'm really<br>[08:40] curious to know whether these are<br>[08:42] conversations that you're having as the<br>[08:44] design leader of the Ethereum<br>[08:46] Foundation. What you think about that<br>[08:47] since it came from Bitter Lick himself.<br>[08:50] Yeah, to be fair, he started at least a<br>[08:53] few years ago, at least two years ago to<br>[08:54] start to add UX on her talks. I saw his<br>[08:58] talk two years ago and has a bunch of<br>[09:01] bullet points for the future. The last<br>[09:02] one was improve UX and that started the<br>[09:05] conversation even within the foundation<br>[09:06] now with the new co- leadership. We kind<br>[09:09] of adopted the three mantras which is<br>[09:11] scale L1, the core protocol, the core<br>[09:14] technology needs to scale. It's being<br>[09:16] done. scale the L2s which is the<br>[09:18] satellite networks that help having<br>[09:21] different experiences within the<br>[09:22] network. I'm speaking simpler for other<br>[09:25] listeners known to understand and then<br>[09:27] third it's improve UX simply as simple<br>[09:29] as that we are still trying to<br>[09:31] understand what does it mean on the<br>[09:33] context of such a complex technology so<br>[09:36] we have a lot of different ways of<br>[09:39] seeing it because UX is not just pushing<br>[09:42] the button the flow or the experience<br>[09:44] exactly touching the interface it's how<br>[09:47] to experience that like you said it's<br>[09:49] mostly about trust how can we build<br>[09:51] trust through UX X or true design that's<br>[09:55] struggles because in the end we are<br>[09:57] talking about the network that has so<br>[10:00] much value in it and if you want to<br>[10:03] change the mindset of traditional<br>[10:04] banking and replace the financial system<br>[10:06] with blockchain based financial system<br>[10:10] it's a completely different mindset for<br>[10:12] the users for everyone else I compare a<br>[10:14] lot with the bubble like you send an<br>[10:17] email now it's completely normal 20<br>[10:19] years ago no one would send an email you<br>[10:21] get confirmation by a letter like it<br>[10:23] wasn't the thing and wouldn't believe<br>[10:25] that okay I don't know what this is this<br>[10:27] is not official something on my screen I<br>[10:29] need to print it I need to could store<br>[10:30] this printed like there's a lot of<br>[10:32] things that we are kind of certain<br>[10:34] that's why you call it web 3 when you<br>[10:36] see web 3 it's not web 3 in the sense<br>[10:39] the AI came into the place and mix a<br>[10:40] little bit what we are doing because AI<br>[10:42] is super nested it's blowing everyone<br>[10:44] mind and it's changing the narrative of<br>[10:46] everything digital but aside of AI web 3<br>[10:50] was example that thing web One was just<br>[10:53] read. Web two was read and write. We<br>[10:55] were about to post blogging, social<br>[10:57] media and web three is own. How do you<br>[11:01] own your own stuff online and through<br>[11:04] blockchain technology? That's why we are<br>[11:06] building the whole ecosystem. This is<br>[11:08] why how has the user perceived that it's<br>[11:11] a completely different mindset. So we<br>[11:13] have different dimensions of UX that<br>[11:15] needs to be tackled.<br>[11:17] This is such an important topic. It's a<br>[11:22] different way of viewing how design is<br>[11:24] done in technology as well as open<br>[11:26] source that it's about concepts that<br>[11:30] make us very human. And of course, open<br>[11:34] source is not going to be able to be<br>[11:36] sustained and used and continued to use<br>[11:38] and continue to grow if people don't<br>[11:40] trust it. and trust can be something<br>[11:43] that is designed for as you say which is<br>[11:46] really important. It's really critical<br>[11:48] to hear. So I'm really curious in our<br>[11:51] last few minutes can you like walk us<br>[11:54] through the way that design is done on<br>[11:58] like a feature or something new within<br>[12:00] the Ethereum Foundation? Like how do the<br>[12:02] decisions get made? How do you have<br>[12:04] these big topic discussions about things<br>[12:06] like trust internally? And what can<br>[12:08] other projects learn from you?<br>[12:11] Curiously, we don't own the project.<br>[12:13] Those conversations are not within the<br>[12:15] foundation are within the community. So<br>[12:17] the protocol itself grows. It's<br>[12:18] decentralized protocol. The foundation<br>[12:20] doesn't own doesn't control the road<br>[12:22] map. Doesn't own the narratives around<br>[12:24] it. So to be clear, those narratives are<br>[12:27] built for everyone that's building<br>[12:28] within the space. Either you're a<br>[12:30] wallet, you're an app, or just building<br>[12:33] an L2, whatever you're building touches<br>[12:35] the network, you're building<br>[12:36] experiences. So we don't control the<br>[12:38] narrative. We don't even write a<br>[12:40] narrative at all. So to be clear, we<br>[12:42] within the foundation, we try to<br>[12:44] coordinate or to steer some of it. But<br>[12:47] the conversation goes outside and design<br>[12:48] has been mostly worked outside the<br>[12:51] foundation. To be fair, we are talking<br>[12:53] how to improve that. But it's not the<br>[12:55] role of the foundation per se to make<br>[12:58] that narrative so strong that we'll<br>[13:01] somehow offiscate the other ideas. It's<br>[13:03] a community-based approach for<br>[13:05] everything, the upgrades, everything<br>[13:07] within Ethereum. It's community based.<br>[13:08] It's decentralized. So it makes it<br>[13:10] really hard even harder to have these<br>[13:13] conversations.<br>[13:14] >> All right. Sorry to take you back, but I<br>[13:16] wanted to ask about the feedback loop<br>[13:18] like designing. One of the things that<br>[13:20] we know in the OSS space is we don't<br>[13:23] often talk to users. It's very rare that<br>[13:26] we do that. How does the Ethereum<br>[13:28] Foundation get feedback? When we talk<br>[13:30] about user experience, what does that<br>[13:31] relationship look like? How do you<br>[13:33] collect all of this feedback? How does<br>[13:35] that look? What does that look like?<br>[13:36] >> It's exactly that. We rely on a lot of<br>[13:38] different third parties, a lot of the<br>[13:40] community projects that has his own<br>[13:42] design teams. They will perform most of<br>[13:44] the user experience and we talk with<br>[13:46] them a lot. We kind of like talk with<br>[13:48] each other to learn from each other. So<br>[13:51] mostly those teams, we know the pain<br>[13:53] points, we know what are the problems.<br>[13:56] Probably we need to do a better job to<br>[13:57] map them and probably we will work on<br>[13:59] that very soon. If you follow that might<br>[14:02] be we are working on something like that<br>[14:04] within like the foundation. How can we<br>[14:06] help? But in the end the user facing the<br>[14:08] end point of touching the technology<br>[14:10] itself it's by the apps and that's not<br>[14:13] the role of the foundation to control or<br>[14:14] even to build anything of it. So those<br>[14:16] are the wallets know the websites<br>[14:19] whatever you use that touches the chain.<br>[14:21] So that's hard but at the same time on<br>[14:24] the other spectrum the technology is<br>[14:26] being built by engineers and researchers<br>[14:28] and cryptographers that build those<br>[14:30] tools. So it's hard them to meet in the<br>[14:33] middle. It's really hard to understand,<br>[14:35] but it's two different forces trying to<br>[14:38] improve something with different<br>[14:39] agendas.<br>[14:41] >> Amazing. So, Nuno, have you got a<br>[14:44] project that you would like to spotlight<br>[14:46] for us today?<br>[14:47] >> Yeah, for sure. Penpots. It's the<br>[14:49] project that I've been following. I've<br>[14:50] been using and I think it's a really<br>[14:52] good one. Really, really good for<br>[14:53] design, changing the landscape.<br>[14:56] >> And you can find Penpot over at<br>[14:57] penpot.app.<br>[14:59] It's really sad we actually don't have<br>[15:01] more time to dig into some of these. You<br>[15:03] know, as a designer myself, I want to<br>[15:04] hear even more. But we are going to have<br>[15:06] to wrap up. Maybe we'll invite you back<br>[15:08] on for a longer episode and the other<br>[15:10] folks that we've spoken to as well. But<br>[15:13] finally, where can people find you on<br>[15:15] the internet, Nuno, if they want to find<br>[15:17] out more about what you're up to or what<br>[15:18] the design team in Ethereum Foundation<br>[15:21] are up to?<br>[15:23] >> You can follow me on different places.<br>[15:25] I'll add the link. It's hard to<br>[15:27] pronounce. the first time I'm<br>[15:28] pronouncing in English to be fair. So,<br>[15:31] we'll add the links.<br>[15:32] >> No worries. So, folks, you can find<br>[15:34] Nuno's social media or other links in<br>[15:37] the show notes. Please check out the<br>[15:40] show notes for those. And other than<br>[15:43] that, just thank you so much for<br>[15:44] spending time with us for this podcast<br>[15:47] recording, Nuno.<br>[15:48] >> Thank you. Thank you for having me.<br>[15:49] >> Thank you.<br>[15:51] I want to say a big thank you to Dev<br>[15:54] Connect, the conference, and the<br>[15:55] Ethereum Foundation for having us here<br>[15:58] at the conference to record these<br>[16:00] podcasts and connecting us up with some<br>[16:02] really amazing guests while we were here<br>[16:05] so that we could record these for for<br>[16:06] the Sustain audience. Also, don't forget<br>[16:10] that you can email us at podcasts<br>[16:12] sustainoss.org<br>[16:14] if you have any feedback. You can reach<br>[16:16] out to Richard who looks after the<br>[16:18] podcast normally. Email richards<br>[16:21] sustainoss.org.<br>[16:24] Please consider rating us on Apple<br>[16:26] Podcast, Spotify, or wherever else<br>[16:29] you've been listening to this podcast.<br>[16:31] Please follow us on social media, which<br>[16:33] includes Masterdon and LinkedIn. If you<br>[16:35] just search for Sustain OSS, you should<br>[16:37] find us. We also maintain a forum, a<br>[16:40] discourse forum. If you want to head on<br>[16:42] over to the forum and have discussions<br>[16:44] with other sustainers, open-source<br>[16:46] software folks, you can head over to<br>[16:49] discourse.sustainoss.org<br>[16:52] and you can find more episodes, in fact<br>[16:55] over 250 episodes and the show notes at<br>[16:59] podcast.sustainoss.org.<br>[17:02] And finally, if you want more podcast<br>[17:05] episodes, if you want more conversations<br>[17:07] about how we sustain open-source<br>[17:09] software, please consider donating to<br>[17:12] the podcast so that we can keep doing<br>[17:14] what we're doing. You can do so over on<br>[17:17] our open collective which is found at<br>[17:20] opencollective.com/sustainoss.<br>[17:24] Thank you so much for listening and see<br>[17:26] you again soon, I hope. Listeners <!-- deep-read:sections end --> ## ๐Ÿ“บ Video ![](https://www.youtube.com/watch?v=XDwn9Syk62U) --- # ๐Ÿ“ Full Notes (Deep-Read Analysis) # ๐Ÿท๏ธ Title: Episode 283: Devconnect 2025 with Nuno Loureiro ## ๐Ÿงฐ Action Inbox - [H1] Open source design systems for community collaboration โ€” exploring collaborative design frameworks #design - [H2] Address UX as primary blocker for open source mass adoption โ€” improve usability barriers #sustainability - [H3] Build trust through design in decentralized systems โ€” reliability and consistency patterns #ethereum ## ๐Ÿงญ Table of Contents - [๐Ÿ“ Summary](#-summary) - [๐Ÿ“– Main Content](#-main-content) - [๐Ÿ—’๏ธ Notes](#๏ธ-notes) - [๐Ÿ“š References](#-references) - [๐Ÿ—ฃ๏ธ Paraphrase](#๏ธ-paraphrase) - [๐Ÿ“ฐ Newsletter](#-newsletter) - [โœ… Action Items](#-action-items) - [๐Ÿงช Hypotheses](#-hypotheses) - [๐Ÿ“Š Methodology](#-methodology) - [โ“ Questions](#-questions) - [๐Ÿ”ฎ Future Research](#-future-research) - [๐Ÿ’ก Implications](#-implications) - [๐Ÿง  Learning Styles Assessment](#-learning-styles-assessment) - [๐Ÿ“Š Accessibility Assessment](#-accessibility-assessment) - [๐ŸŒ DEIB Assessment](#-deib-assessment) - [โœ… Logical Validity](#-logical-validity) - [๐Ÿ›ก๏ธ DARVO Analysis](#-darvo-analysis) - [๐ŸŽฏ Conclusion](#-conclusion) ### ๐Ÿ”— References - [Sustain OSS Podcast](https://podcast.sustainoss.org/) - [Penpot](https://penpot.app) ## ๐Ÿ“ Summary - Sustain OSS podcast interviews Nuno Loureiro, lead designer at Ethereum Foundation, at DevConnect in Buenos Aires - Covers design challenges in open source, particularly around community collaboration and mass adoption barriers - Discussion centers on UX as the primary blocker for open source adoption and the unique challenges of designing for decentralized systems - Key stakeholders include designers, open source maintainers, and the Ethereum community - Bottom line: Design and UX improvements are critical for open source sustainability and mass adoption ## ๐Ÿ“– Main Content Nuno Loureiro serves as lead designer for the Ethereum Foundation, primarily focused on ethereum.org as a learning platform. His role has expanded from website design to broader communication and design system challenges across multiple Foundation projects. The conversation explores fundamental tensions in open source design work. Unlike traditional software development contributions through pull requests, design collaboration proves significantly more complex. Loureiro identifies this as a systemic issue affecting open source sustainability. A central theme emerges around trust and reliability in user experience. Ethereum founder Vitalik Buterin's emphasis on consistent performance (avoiding scenarios where the same action takes 10 seconds, then 2 minutes, then 10 minutes) reflects broader UX priorities. The Foundation has adopted three core mantras: scale L1 (core protocol), scale L2s (satellite networks), and improve UX. The decentralized nature of Ethereum creates unique design challenges. The Foundation doesn't control the protocol roadmap or user-facing applications, instead coordinating with community teams who build actual user interfaces. This distributed approach complicates traditional design feedback loops and user research. ## ๐Ÿ—’๏ธ Notes #### โฑ๏ธ [00:00](https://youtu.be/XDwn9Syk62U?t=0) โ€” [H1] Introduction and Context - Key idea: Sustain podcast recording at DevConnect Buenos Aires with Ethereum Foundation - Evidence: "We've been invited by the Ethereum Foundation to have some interesting conversations about sustaining open source" #### โฑ๏ธ [02:30](https://youtu.be/XDwn9Syk62U?t=150) โ€” [H2] Nuno's Role at Ethereum Foundation - Key idea: Lead designer focusing on ethereum.org learning platform and broader Foundation design needs - Evidence: "I joined the foundation three plus years ago to focus on ethereum.org... a portal or a website where you can learn everything about Ethereum" #### โฑ๏ธ [04:45](https://youtu.be/XDwn9Syk62U?t=285) โ€” [H3] Design System Collaboration Challenges - Key idea: Open sourcing design systems for community collaboration proves difficult - Evidence: "I wanted to on board so I open source as much as I could the process of creating the design system itself" #### โฑ๏ธ [06:20](https://youtu.be/XDwn9Syk62U?t=380) โ€” [H2] ZK Proofs Portal Design Challenge - Key idea: Building competitive comparison interfaces for zero-knowledge proof providers - Evidence: "building a need proofs a portal for ZK proofs where different providers of the technology needs to be under the same platform" #### โฑ๏ธ [07:15](https://youtu.be/XDwn9Syk62U?t=435) โ€” [H1] Design as Primary Open Source Adoption Blocker - Key idea: Poor UX prevents mass adoption despite functional software - Evidence: "From my perspective, it's the biggest blocker for mass adoption of the open source software" #### โฑ๏ธ [08:30](https://youtu.be/XDwn9Syk62U?t=510) โ€” [H3] Designer Collaboration Difficulties - Key idea: Designers struggle more than developers with open source collaboration - Evidence: "we designers do it even worse than developers we are the worst collaborators" #### โฑ๏ธ [10:45](https://youtu.be/XDwn9Syk62U?t=645) โ€” [H2] Design Education and Hierarchy Issues - Key idea: Traditional design education emphasizes hierarchy over collaboration - Evidence: "You learn that you have someone above you that tells you what to do or a client tells you what to do" #### โฑ๏ธ [12:20](https://youtu.be/XDwn9Syk62U?t=740) โ€” [H2] Vulnerability in Open Source Design - Key idea: Attachment to work makes designers reluctant to accept criticism - Evidence: "sometimes I think that it's hard for both coders and designers to really be vulnerable and open up those conversations for criticism" #### โฑ๏ธ [14:10](https://youtu.be/XDwn9Syk62U?t=850) โ€” [H1] Reliability and Trust in UX - Key idea: Vitalik emphasizes consistent performance as core UX principle - Evidence: "if a user tries to do something on a platform and the first time it takes 10 seconds, the second time it takes 2 minutes and the third time it takes 10 minutes" #### โฑ๏ธ [15:45](https://youtu.be/XDwn9Syk62U?t=945) โ€” [H2] Ethereum Foundation's Three Mantras - Key idea: Scale L1, scale L2s, and improve UX as organizational priorities - Evidence: "scale L1, the core protocol... scale the L2s which is the satellite networks... and then third it's improve UX" #### โฑ๏ธ [17:30](https://youtu.be/XDwn9Syk62U?t=1050) โ€” [H3] Web3 Ownership Paradigm - Key idea: Web3 represents shift from read/write to read/write/own model - Evidence: "Web One was just read. Web two was read and write... web three is own. How do you own your own stuff online" #### โฑ๏ธ [19:15](https://youtu.be/XDwn9Syk62U?t=1155) โ€” [H2] Decentralized Design Decisions - Key idea: Foundation coordinates rather than controls design narratives - Evidence: "we don't own the project. Those conversations are not within the foundation are within the community" #### โฑ๏ธ [21:00](https://youtu.be/XDwn9Syk62U?t=1260) โ€” [H3] Feedback Through Third Parties - Key idea: User feedback comes through community projects and wallet teams - Evidence: "We rely on a lot of different third parties, a lot of the community projects that has his own design teams" #### โฑ๏ธ [22:45](https://youtu.be/XDwn9Syk62U?t=1365) โ€” [H2] Penpot Recommendation - Key idea: Spotlighting Penpot as promising open source design tool - Evidence: "Penpots... I've been using and I think it's a really good one. Really, really good for design, changing the landscape" ## ๐Ÿ“š References - [Sustain OSS Podcast](https://podcast.sustainoss.org/) - [Ethereum Foundation](https://ethereum.org/) - [Penpot](https://penpot.app) - [DevConnect Conference](https://devconnect.org/) ## ๐Ÿ—ฃ๏ธ Paraphrase - Design collaboration in open source faces unique barriers compared to code contributions, with designers struggling more than developers to work in community-driven environments - User experience quality serves as the primary obstacle preventing mass adoption of open source software, despite technical functionality being adequate - Decentralized governance models create complex design coordination challenges, requiring new approaches to user research and feedback collection across distributed teams ## ๐Ÿ“ฐ Newsletter Exciting insights from DevConnect on designing for open source sustainability! Nuno Loureiro from the Ethereum Foundation shares how UX barriers prevent open source adoption and why designers face unique collaboration challenges. Key takeaways: Traditional design education emphasizes hierarchy over collaboration, making community-driven projects difficult. However, focusing on reliability and trust through consistent user experiences can drive adoption. The Ethereum Foundation's three-pillar approach (scale core, scale networks, improve UX) shows how major projects prioritize design. Their decentralized model offers lessons for coordinating design across distributed teams. Check out Penpot for open source design tooling that's changing the landscape! Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## โœ… Action Items #### DevRel - Developer experience: Research design system patterns for community contribution workflows - Education: Create workshops on collaborative design practices for open source projects - Developer marketing: Document case studies of successful design/developer collaboration #### Community - Contributors: Develop onboarding materials specifically for designers entering open source - Maintainers: Create governance templates for design decision-making in decentralized projects - Sponsors: Fund design system initiatives that support multiple projects #### WordPress - Design: Conduct UX audits focused on reliability and consistency across core experiences - Community: Establish design mentorship programs connecting agency designers with open source projects - Training: Develop learning paths for designers contributing to open source ## ๐Ÿงช Hypotheses - Design systems optimized for community collaboration increase designer participation in open source projects - Consistent performance metrics (response times, reliability) correlate with user trust and adoption - Decentralized design coordination models can maintain quality while enabling distributed contribution - Traditional design education creates barriers to open source collaboration that require targeted intervention ### ๐Ÿ“Š Methodology - Survey designers about barriers to open source contribution and test targeted onboarding interventions - Measure user trust metrics against performance consistency across different open source tools - Compare design quality outcomes between centralized and decentralized governance models - Analyze correlation between design system openness and community contribution rates ### โ“ Questions - How can design systems be structured to enable meaningful community contribution while maintaining coherence? - What specific performance consistency metrics most strongly predict user adoption in open source tools? - How do decentralized organizations balance design vision with community input? ### ๐Ÿ”ฎ Future Research - Development of collaborative design frameworks specifically for open source contexts - Investigation of trust-building mechanisms in decentralized user experiences - Exploration of designer onboarding patterns that overcome traditional hierarchy expectations ### ๐Ÿ’ก Implications - Practice: Design teams need new collaboration models for community-driven development - Policy: Open source governance should explicitly address design decision-making processes - Education: Design curricula should include collaborative and community-driven project methodologies - Funding: Grants should specifically support design system initiatives that enable community contribution ### ๐Ÿง  Learning Styles Assessment Reading level estimate: 12th grade #### ๐Ÿ‘€ Visual learners - Present: Conceptual discussion of design systems and user interfaces - Improve: Diagrams showing decentralized design coordination, UX flow examples #### ๐Ÿ”Š Aural learners - Present: Podcast format with conversational explanation of concepts - Improve: Audio examples of user interaction patterns, sound design considerations #### ๐Ÿ—ฃ๏ธ Verbal learners - Present: Clear definitions of Web3, L1/L2 concepts, design system terminology - Improve: Analogies comparing traditional vs. decentralized design processes #### ๐Ÿงฉ Kinesthetic learners - Present: Discussion of hands-on design system creation process - Improve: Step-by-step guides for contributing to open source design projects #### ๐Ÿง  Logical learners - Present: Three-pillar organizational framework, cause-effect relationship between UX and adoption - Improve: Decision trees for design governance, metrics dashboards for trust/reliability #### ๐Ÿง‘โ€๐Ÿคโ€๐Ÿง‘ Social learners - Present: Community collaboration challenges and solutions discussion - Improve: Forums for designer collaboration, peer review processes for design contributions #### ๐Ÿง˜โ€โ™€๏ธ Solitary learners - Present: Individual reflection on design collaboration challenges - Improve: Self-assessment tools for design contribution readiness, personal portfolio development guides #### ๐ŸŒฟ Naturalistic learners - Present: Ecosystem thinking about design in decentralized networks - Improve: Biological analogies for distributed design systems, sustainability connections ### ๐Ÿ“Š Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive content organization - Improve: Alt text for design system examples, ARIA labels for interactive design elements #### Keyboard navigation - Present: Standard podcast interface navigation - Improve: Keyboard shortcuts for timestamp navigation, accessible design tool recommendations #### Contrast and readability - Present: Standard podcast player interface - Improve: High-contrast design system examples, readability guidelines for design contributions #### Text resizing and reflow - Present: Responsive podcast interface - Improve: Scalable design system documentation, flexible layout examples #### Media and captions - Present: Full transcript provided for audio content - Improve: Audio descriptions for design process examples, downloadable transcript with timestamps #### Forms and interactions - Present: Basic podcast controls - Improve: Accessible design contribution workflows, inclusive feedback mechanisms ### ๐ŸŒ DEIB Assessment #### Cultural breadth - Present: International conference setting (Buenos Aires), global Ethereum community perspective - Improve: Examples from diverse cultural contexts, multi-regional design pattern considerations #### Inclusive language - Present: Technical terms explained in accessible language - Improve: Avoid jargon like "junky," provide glossaries for blockchain terminology #### Neurodiversity support - Present: Clear section breaks, consistent interview structure - Improve: Visual summaries of key concepts, multiple format options for design guidelines #### Representation - Present: Designer perspective in traditionally developer-focused space - Improve: Include diverse designer voices, showcase varied cultural approaches to design collaboration #### Psychological safety - Present: Acknowledgment of vulnerability in design criticism - Improve: Guidelines for constructive design feedback, community codes of conduct ### โœ… Logical Validity #### Strong reasoning - Deductive strength: Solid reasoning from UX barriers to adoption challenges - Inductive strength: Good generalization from Ethereum Foundation experience to broader open source challenges - Causal reasoning: Clear connection between design collaboration difficulties and adoption barriers - Analogical strength: Effective email adoption analogy for Web3 mindset shifts #### Fallacies - Hasty generalization: "Designers are the worst collaborators" - overly broad claim without sufficient evidence - False dilemma: Implies traditional hierarchy vs. collaboration as binary choice rather than spectrum #### Tone of voice - Overall tone: Conversational and reflective, with appropriate self-criticism and humility about challenges ### ๐Ÿ›ก๏ธ DARVO Analysis - Deny: No concerning denial patterns observed - Attack: No attacks on accusers present - Reverse victim/offender: No reversal patterns identified - Emotional cues and rhetoric: Healthy self-reflection and acknowledgment of community challenges ## ๐ŸŽฏ Conclusion This conversation highlights design as a critical but underaddressed aspect of open source sustainability. The Ethereum Foundation's experience demonstrates that even well-funded projects struggle with design collaboration and community engagement. The key insight is that UX barriers, not technical limitations, prevent mass adoption of open source tools. Practical next steps --- # ๐Ÿ“„ Full Transcript *Auto-generated from YouTube captions ยท timestamps roughly every 30 seconds ยท [watch on YouTube](https://www.youtube.com/watch?v=XDwn9Syk62U)* **[00:00]** [music] Hello and welcome to Sustain, the podcast where we talk about sustaining open-source software for the longhaul. Hi, I'm Errol Fox and with me is >> Victory Brown and we're at Dev Connect Conference in Buenos Aerys, Argentina. We've been invited by the Ethereum Foundation to have some interesting **[00:32]** conversations about sustaining open source. Today we have with us Nuno who is the lead designer for the Ethereum Foundation. Nuno, can you tell us a little bit more about what being the lead designer in the Ethereum Foundation contains entails? Tell us about your day-to-day. >> Hello. Thank you so much for having me. It's a pleasure to be here and to talk about the future of open software, open source. So I joined the foundation three **[01:02]** plus years ago to focus on ethereum.org. So my background is a lot of digital design. I've done a lot of apps and whatever comes to your screen. I used to do a lot of that and somehow I cross paths with the foundation. I have focus on the learning platform that is ethereum.org. So it's a portal or a website where you can learn everything about Ethereum. So from the early journey where you pick your wallet to help you understand what Ethereum is to hardcore dev docs where you learn more **[01:33]** in depth like the tech stack, what it's built, how it's built and all that stuff. So that was the beginning of my journey within the foundation. Then things got to grow. I am help a lot of more stuff related to design to communication building other websites on the side for other teams. So we bootstrap a lot of other projects all based on web. Now we're picking another mediums like video a little bit which has been fun. It's recent but uh if you follow the Ethereum foundation account and Ethereum account you'll see a lot of **[02:04]** more of that but yeah so my role will be kind of helping whenever I can whenever there's a design challenge to be to be faced or >> to that statement of design challenges in the Ethereum Foundation. What would you say are your biggest challenges working as the lead designer in the Ethereum Foundation? I had a few I had one I think this was the one that got us close together with open source was I've done few design systems back in the day and when I joined the aesthetics of **[02:35]** website was working but we wanted to on board designers and I've never done this before so I kind of learn by navigating sure like I don't know how in English the best expression but it's close to this and I wanted to on board so I open source as much as I could the process of creating the design system itself. So we had a community of 40,000 users. A small portion of that were designers. We're tackling to them mostly. We had contributions for content **[03:06]** for translations for code. Obviously it's the most fun like you open a PR can fix a PR was really easy. But for design that never happened. And to be fair, I never found a good example like this because it's not easy to open in a design system and have being collaborative to other designers. So that was probably my challenge that I had within the foundation. The other ones was more proper product challenges. The other one was building a need proofs a portal for ZK proofs where different **[03:37]** providers of the technology needs to be under the same platform and competes compete quote unquote on this in the sense that they we want to be who's the fastest who's the best proving in order to push the narrative of the ZK. So how to present that to the user is a huge design challenge. >> Well, it sounds like the design team and you are busy at the Ethereum Foundation. And it sounds like there's plenty to improve and make really good for users. I guess this is more of a broad question around how do you think good design, **[04:10]** good usability, good design systems plays into the idea of making open source sustainable. >> From my perspective, it's the biggest blocker for mass adoption of the open source software. I don't have any other explanation to this because if you open or open other because I know there's others tools but close to me it feels still kind of junky and it's mostly on the user experience because the software is there mostly it does what it supposed to be. So my clean take **[04:42]** is design should be the forefront of the open source because that's the main blocker for the mass adoption of free open source tools. Thank you for that. You know, and that's really important because Errol and I are also designers and this is challenges that we face all the time. I wanted to ask about like what have you done differently because again design is one of the sustainability mechanisms of open source. What have you done to you know attract more designers to you know the project and also push design conversations and make sure that design **[05:14]** is front and center of this entire process. >> Unfortunately not enough. I'm sure that not enough and that's something that I would love to do more when you design for more open source balancing life where you had a job full-time job and have that full-time job some compensates the other part of it and have time for that it's really hard and we designers do it even worse than developers we are the worst collaborators I have a huge criticism for myself included so it's all of us **[05:44]** how to collaborate on this front how to join a project understand the project. There are something inherent to a design job that it's not 100% compatible of community and open collaboration. At least from the old design or from the one design that we are talked in colleges that we learn when you start a job, you go to agency or some other place. You learn that you have someone above you that tells you what to do or a client tells you what to do or some VC if you're in a startup or something like that. And the other way around is gives **[06:15]** you freedom to start the other way around. Start from the beginning. It's harder for us designers to get the mindset of collaboration. I don't know why. I'm not here to explain. I don't know why, but it's really hard. >> I've thought about this long and hard for the seven or eight years I've been doing design in open source. And yeah, designers really struggle in a different way, I think, to coders and developers, but we also have this sense of love and care for what we do. And I think in open **[06:46]** source there's a lot of attachment to what you build because it's usually something you've built in your spare time or it's been a really critical problem that you've wanted to solve. And yeah, sometimes I think that it's hard for both coders and designers to really be vulnerable and open up those conversations for criticism, right? But then maybe the thing that we're trying to get at here is for the sustainability of open source to grow, we have to be **[07:18]** open in all ways that we collaborate, design, code, and be a little bit more vulnerable in how we do that. But yeah, really interesting challenges and it's also somewhat like victory. I don't know if you feel this way, but it gives me like a sense of confidence that even foundations like the Ethereum Foundation are having similar problems to smaller open source projects. It's actually kind of like, oh, we're all having similar problems that we're trying to solve. But **[07:49]** I do have another question actually, Nuno, I'm really excited to ask this question. So, I was at a talk from the funding the commons this morning. It's a satellite event at the Devconnect conference and Vitilik the founder I believe of Ethereum was talking about UX in his panel with Robert the co-founder of tour and he asked what do we think is really important about usability and UX and for the Ethereum Foundation he **[08:20]** talked about how he thought that reliability for users is really important from the sense of if a user tries to do something on a platform and the first time it takes 10 seconds, the second time it takes 2 minutes and the third time it takes 10 minutes, then there's inconsistent reliability. I'm really curious to know whether these are conversations that you're having as the design leader of the Ethereum Foundation. What you think about that since it came from Bitter Lick himself. Yeah, to be fair, he started at least a **[08:53]** few years ago, at least two years ago to start to add UX on her talks. I saw his talk two years ago and has a bunch of bullet points for the future. The last one was improve UX and that started the conversation even within the foundation now with the new co- leadership. We kind of adopted the three mantras which is scale L1, the core protocol, the core technology needs to scale. It's being done. scale the L2s which is the satellite networks that help having different experiences within the network. I'm speaking simpler for other **[09:25]** listeners known to understand and then third it's improve UX simply as simple as that we are still trying to understand what does it mean on the context of such a complex technology so we have a lot of different ways of seeing it because UX is not just pushing the button the flow or the experience exactly touching the interface it's how to experience that like you said it's mostly about trust how can we build trust through UX X or true design that's **[09:55]** struggles because in the end we are talking about the network that has so much value in it and if you want to change the mindset of traditional banking and replace the financial system with blockchain based financial system it's a completely different mindset for the users for everyone else I compare a lot with the bubble like you send an email now it's completely normal 20 years ago no one would send an email you get confirmation by a letter like it wasn't the thing and wouldn't believe that okay I don't know what this is this **[10:27]** is not official something on my screen I need to print it I need to could store this printed like there's a lot of things that we are kind of certain that's why you call it web 3 when you see web 3 it's not web 3 in the sense the AI came into the place and mix a little bit what we are doing because AI is super nested it's blowing everyone mind and it's changing the narrative of everything digital but aside of AI web 3 was example that thing web One was just read. Web two was read and write. We were about to post blogging, social **[10:57]** media and web three is own. How do you own your own stuff online and through blockchain technology? That's why we are building the whole ecosystem. This is why how has the user perceived that it's a completely different mindset. So we have different dimensions of UX that needs to be tackled. This is such an important topic. It's a different way of viewing how design is done in technology as well as open source that it's about concepts that **[11:30]** make us very human. And of course, open source is not going to be able to be sustained and used and continued to use and continue to grow if people don't trust it. and trust can be something that is designed for as you say which is really important. It's really critical to hear. So I'm really curious in our last few minutes can you like walk us through the way that design is done on like a feature or something new within **[12:00]** the Ethereum Foundation? Like how do the decisions get made? How do you have these big topic discussions about things like trust internally? And what can other projects learn from you? Curiously, we don't own the project. Those conversations are not within the foundation are within the community. So the protocol itself grows. It's decentralized protocol. The foundation doesn't own doesn't control the road map. Doesn't own the narratives around it. So to be clear, those narratives are built for everyone that's building within the space. Either you're a wallet, you're an app, or just building **[12:33]** an L2, whatever you're building touches the network, you're building experiences. So we don't control the narrative. We don't even write a narrative at all. So to be clear, we within the foundation, we try to coordinate or to steer some of it. But the conversation goes outside and design has been mostly worked outside the foundation. To be fair, we are talking how to improve that. But it's not the role of the foundation per se to make that narrative so strong that we'll somehow offiscate the other ideas. It's **[13:03]** a community-based approach for everything, the upgrades, everything within Ethereum. It's community based. It's decentralized. So it makes it really hard even harder to have these conversations. >> All right. Sorry to take you back, but I wanted to ask about the feedback loop like designing. One of the things that we know in the OSS space is we don't often talk to users. It's very rare that we do that. How does the Ethereum Foundation get feedback? When we talk about user experience, what does that relationship look like? How do you collect all of this feedback? How does **[13:35]** that look? What does that look like? >> It's exactly that. We rely on a lot of different third parties, a lot of the community projects that has his own design teams. They will perform most of the user experience and we talk with them a lot. We kind of like talk with each other to learn from each other. So mostly those teams, we know the pain points, we know what are the problems. Probably we need to do a better job to map them and probably we will work on that very soon. If you follow that might be we are working on something like that within like the foundation. How can we **[14:06]** help? But in the end the user facing the end point of touching the technology itself it's by the apps and that's not the role of the foundation to control or even to build anything of it. So those are the wallets know the websites whatever you use that touches the chain. So that's hard but at the same time on the other spectrum the technology is being built by engineers and researchers and cryptographers that build those tools. So it's hard them to meet in the middle. It's really hard to understand, but it's two different forces trying to **[14:38]** improve something with different agendas. >> Amazing. So, Nuno, have you got a project that you would like to spotlight for us today? >> Yeah, for sure. Penpots. It's the project that I've been following. I've been using and I think it's a really good one. Really, really good for design, changing the landscape. >> And you can find Penpot over at penpot.app. It's really sad we actually don't have more time to dig into some of these. You know, as a designer myself, I want to hear even more. But we are going to have to wrap up. Maybe we'll invite you back **[15:08]** on for a longer episode and the other folks that we've spoken to as well. But finally, where can people find you on the internet, Nuno, if they want to find out more about what you're up to or what the design team in Ethereum Foundation are up to? >> You can follow me on different places. I'll add the link. It's hard to pronounce. the first time I'm pronouncing in English to be fair. So, we'll add the links. >> No worries. So, folks, you can find Nuno's social media or other links in the show notes. Please check out the **[15:40]** show notes for those. And other than that, just thank you so much for spending time with us for this podcast recording, Nuno. >> Thank you. Thank you for having me. >> Thank you. I want to say a big thank you to Dev Connect, the conference, and the Ethereum Foundation for having us here at the conference to record these podcasts and connecting us up with some really amazing guests while we were here so that we could record these for for the Sustain audience. Also, don't forget that you can email us at podcasts **[16:12]** sustainoss.org if you have any feedback. You can reach out to Richard who looks after the podcast normally. Email richards sustainoss.org. Please consider rating us on Apple Podcast, Spotify, or wherever else you've been listening to this podcast. Please follow us on social media, which includes Masterdon and LinkedIn. If you just search for Sustain OSS, you should find us. We also maintain a forum, a discourse forum. If you want to head on over to the forum and have discussions **[16:44]** with other sustainers, open-source software folks, you can head over to discourse.sustainoss.org and you can find more episodes, in fact over 250 episodes and the show notes at podcast.sustainoss.org. And finally, if you want more podcast episodes, if you want more conversations about how we sustain open-source software, please consider donating to the podcast so that we can keep doing **[17:14]** what we're doing. You can do so over on our open collective which is found at opencollective.com/sustainoss. [music] Thank you so much for listening and see you again soon, I hope. Listeners [music]