 Our team is a growing team, a bit over 60 people now, and there are six of us who make up the design and communications team. We all work really closely with our devs and have weekly meetings to facilitate remote collaboration on CK apps and protocols. And we use design to align teammates from various technical backgrounds, creating this common understanding internally allows us to communicate the value of our open source protocols and apps to the ecosystem so that you, our community, can dream up and build your own CK products. When I started working with PSE, Designing Public Goods, it took me some time to wrap my head around the idea of not designing for profit. Because almost all of my previous design experience involved aligning UX strategy with business goals. It was a big mental shift to move from designing to increase sales or signups, to designing to attract participants who can use what we have built to build their own thing. On my team, designers, developers, writers, product owners, we're all using design as a tool to make the unfamiliar familiar. In this presentation, I'll start by addressing the value of designing for privacy, share some design challenges, highlight a few CK apps, discuss the ways design can be used to facilitate conversation and touch on mental models. The PSE, we're building privacy and anonymity infrastructure using zero knowledge proofs so that you can choose how much of your identity you want to expose when going about interacting with others on the Ethereum blockchain. But simply, a zero knowledge or ZK proof is a method by which one party can prove to another party that something is true without revealing anything besides the fact that it is true. We call our zero knowledge protocols and apps public goods because they're open source and free for anyone to build with or use. I believe that we need to design for privacy so that we can evolve beyond our current challenges, understand our material more deeply, involve more people as collaborative, co-creative participants, and in turn fortify privacy solutions with greater anonymity sets. So yes, privacy resources are difficult to option to. True, user experience for these apps has a lot of room for improvement. Sure, the material is abstract and complex. And to some of us, zero knowledge feels like incomprehensible witchcraft. But design can help people from any technical background make sense of the things that they don't understand. The only way to create better, more usable interfaces is by exploring and iterating our work. We're only at the very beginning. There are many design cycles in our future, which to me is super exciting. The design process is a hands-on way for anyone to learn. On my team, contributors from all kinds of backgrounds are finding alignment by cycling through phases of discovery, problem definition, prototyping and testing, together. When the abstract can become something physical, concepts can sink in and inspire the next cycle. The more that we understand the protocols that we're working with, the easier time we will have communicating their value. More and more people are understanding how our information is collected and how our data is used to influence our thoughts and actions, but they're apathetic. Imagine if by default, we had privacy and anonymity online. If people could make an informed decision to opt out, they wouldn't be saying, well, they have all my data anyway, what can I do? Instead of creating extractive applications that use users, we can choose to design participatory environments where people consent to how much personal information they reveal about themselves. And although there may not be a high demand for zero-knowledge public goods or products yet, I believe the more that we design, the more people will come to understand the magic of ZK and want to use it. We're still in really early stages of research and in design. The experiences we create will become more usable, more accessible, the more cycles that we go through. And the more people that we can talk to about their experiences. And this part's really cool to me. The better the experiences are, the more participants there will be, which will result in larger sets of anonymous participants and increased privacy for everyone. If this material still feels conceptual and you're wondering what an experience with zero-knowledge would be like, here's a relevant example. Say you want to anonymously share feedback about this event with the event organizers. But in order to do so, you have to prove that you attended the event. An app built with ZK could allow you to prove that you did in fact attend the event without revealing who you are, giving you the opportunity to truly share feedback anonymously. Can you think of other instances where you might want to prove that something is true without revealing additional personal information? A few other ones I've also heard are speaking out against systems of power and engaging in conversation and discourse. So a lot of our protocols have the potential to structure or manage anonymous or private environments for these purposes. There are plenty of challenges that arise when designing ZK apps. We like to use how might we questions to help us explore problem spaces without immediately jumping to solutions. So I'd like to share some of those with you. Some of our challenges reframed us how might we statements. How might we balance approachability and transparency? An ever present challenge that we're facing is deciding how much information to share in our apps and other resources. We want to be transparent and help curious individuals learn more about ZK products while they're using them, but we also want to avoid overwhelm and cognitive overload. Here's some screenshots from our ZK-OPRU private wallet. This is a browser extension. My teammate, Beyonder, came up with these designs and I included them because I think they're a really nice example of progressive disclosure where users land on the primary screen that's on the left and they just see the tokens in their wallet. When they want to get more information about a specific token, they can click the Chevron to open up the secondary window where you see more information about the transactions and also like the full functions of that app. How might we give users the freedom to choose how much they reveal about themselves? Because ZK-Apps give us anonymous identities, it's up to us to preserve or break the level of anonymity that we start with. When we're anonymous, our identity is unknown, but our actions are public. Trails of actions we have taken can be clues to our real identities. ZK-Apps can expose you to the idea of controlling how much you reveal or when you reveal it. In one of our applications, Unirep Social, this user, in the screenshot, the user is about to post to the feed of an anonymous social app. You can see that they have 30 rep and you can see that before they post, five points are required to post and they can choose from three different personas and they can also choose on a sliding scale how much of their rep they want to display. So my teammate Chiali created this sliding scale model for giving people that opportunity to decide how much to reveal about the reputation they have and that's a cool way to show people making a decision about how they want to appear in this group. How might we craft environments for anonymous users to build trust with one another? A lot of people ask me why I would ever design apps where people can be anonymous online because they feel that anonymous environments are often hostile. And I would argue that anonymity can also create places where everyone has an equal voice and they're not limited by potential judgments that they might experience if their identity was revealed. However, an interesting way to create trust is by creating groups where everyone has to prove that they belong and if they qualify to join a group they can trust that everyone else who qualified also had to go through the same qualification process. This project that we've worked on, InterEP is a good example of bridging reputation from centralized applications to your on-chain identity to be able to prove that you qualify for a certain group with other people. So in this example, the person qualifies to be a Twitter Gold member because they have a certain number of followers and they can join. How might we represent identity in communities of anonymous individuals? If anonymous environments are not all going to necessarily have profile pics and user bios what will the identities look like? It's fun to think of the different ways things could be represented. Will handles always be the same? Will they change? If they change, how often could handles instead be tied to reputation? My teammate Tsukino created Skitter. This is a social app where people have the option to decide how they want to be displayed by username, by their ENS address or saying that they're a member of a group. You can see at the top of this screenshot a Taz member posted. That's someone who signed up for our temporary anonymous zone downstairs. You guys should all check it out. Then they were able to take their identity from that app and use it in Skitter. And say like, yeah, I'm a non, but I'm also associated with this group. And another clever thing I think Tsukino came up with was saying a Twitter user with 500 plus followers said X, Y, Z. But what gets us to the point of creating designs that address these help my way statements? I believe it's environments that foster collaboration and discovery and processes that facilitate conversation. As much as design is about creating objects or interfaces that people can interact with, it's also about creating containers where people from different technical backgrounds can explore ideas and find alignment. We create containers for conversation by frequently hosting workshops in digital whiteboards. It's in these workshops that people from different technical backgrounds can develop common language and create bridges between their domains of understanding. Here's an example from like one of our FIGJAM files. I am obsessed with the digital whiteboards. I feel like it's so cool to allow people to support their words with, you know, markers, sticky notes, shapes, cursor gestures, or chat bubbles. It's way more comfy spending time with unknowns when everyone can visualize a discussion. And I've noticed that when a group of people are all looking at the same thing on, you know, their different screens and wherever they are in the world, it's easier to identify misunderstandings. With the visual aids in this created environment, there's less room to miss what someone said or to not understand what they mean. We've been hosting a bunch of workshops, and so I wanted to share with you some principles that have helped us lead successful ones. We're opening our workshops to teammates from various backgrounds, different technical backgrounds, and experience levels. We offer people multiple ways to contribute because you need to think about different personality types, different technical circumstances. Not every workshop should just be people verbally exchanging ideas with each other. There needs to be time set aside for writing or drawing as well. We also make sure we always have a dedicated notes taker, and before we synthesize results at the end of the workshop, we preserve what we had, like the workshop results, because you don't want to have one or two people synthesize and be left with the bias of their synthesis. For workshops that involve a lot of people and have a tight time limit, I highly suggest collaborating with someone else as a co-host and time box yourselves and have a dress rehearsal. I encourage anyone to explore using digital whiteboards in this way and watch how it gets people thinking and talking through challenges. For us, we've learned a lot about some of our protocols like ZKOPRU, SEMIFOR, and UNI-RUP through these digital whiteboard sessions. No matter how lo-fi, visuals help us move from abstraction to something concrete. Translating a protocol into an approachable user interface takes time. It takes time because our initial means to understanding what a protocol can do usually starts with documentation. This kind of writing reflects an implementation model necessary for development because it reflects the technology back to the reader. When we begin designing, we can create other kinds of models to better understand protocols that instead reflect familiarity back to us. Represented models reflect the designer's vision because they know some stuff about the protocol and mental models reflect the user's understanding. They know nothing about the protocol most likely. I really like this chart for visualizing the difference. It's adapted from the book About Face. There's five shapes on this scale. Can you identify any of the shapes? I heard circle. While we might... Some of us might be able to identify the potato. Most of us are going to identify the circle. It's a representation of how users' mental models take recognizable shapes. However, the closer we get to the other side of that scale, the model that reflects technology, it's a less recognizable form, or at least one that we are probably not going to agree on what is called. A really interesting aspect of this is that developers on my team encounter a similar journey when they create programmable cryptography. They start with mathematical proofs, which they abstract into simple and familiar code. So both developers and designers on our team are on this similar journey, transforming abstraction into something familiar and usable. Let me give you an example of how this plays out. Back to some screenshots of VINI Rep Social. I could describe this with an implementation model and say that VINI Rep Social was built with 2CK protocols, VINI Rep and Semaphore. And when you register, and a tester will give you three epoch keys and a set number of reputation points, every epoch to interact with other users. Positive reputation points are used to post and comment. You can give positive reputation points to content that you like and give negative reputation points to content that you don't like. At the end of every epoch, a user state transition occurs where the positive and negative reputation points are recalculated and your epoch keys are swapped for three new ones. That might have made sense to some of you, but for me, when I first heard this, it made literally no sense at all. The language is niche and uncommon. But I do understand it now, but it's only because we created mental models to understand it. We could have trained ourselves to learn the system vocabulary, but instead we came up with a new way to describe the app. By asking ourselves questions like, what does this remind me of? What do I know that is similar to this? If we want to create usable ZK products, we cannot ask people to just get used to a machine's language. We have to put time into deepening our understanding so that we can create approachable applications that mirror the familiar. So let's try this again. What if I said Unirep Social is a place to build communities based on ideas rather than identities? If you sign up for the app, you get three personas and 30 rep to interact with other users. Rep is like points or currency. It's needed to post in common. It's also used to boost the content that you like and squash the content that you don't like. Every cycle, about one week, you receive three new personas and your rep total is calculated based on what you have used and what you received from other members. You must have a positive amount of rep to interact with the system. I think that that was probably more accessible, but the thing to point out is that it's not a user's mental model. We're still not at that stage. It's a design team's represented model. This just goes back to iterating the point of we need to keep cycling through and iterating on the work, putting the work in front of people and getting feedback. This is true for any of the designs in the space. Although I could only share a few of our challenges, there are many, but that means there's lots of opportunity for design. With more people designing CK Public Goods, we believe that we can empower more builders and product teams, reduce friction when onboarding to privacy apps, help developers create protocol resources that are informed by user research, educate users by providing transparent information that evolves with them as they learn, and reduce the stigma and normalize online privacy and anonymity. If we want to see privacy normalized and made accessible to everyone, we must continue to collaboratively design. People from all kinds of technical backgrounds design by approaching challenges with curiosity, getting comfortable spending time with the unknown, aligning strategy to audience objectives, testing potential solutions, and iterating their work. I want to thank my team members who helped me collaboratively with this presentation. We worked really similarly to the way we work on other things. The QR code goes to our PSE Discord, where you can find all of us. My handle is in the top left, and we started designing for Public Goods Channel. If this content resonates with you, please join our channel and start a conversation. If you want to get involved this week, like I mentioned earlier, the Temporary Anonymous Zone Community Hub is downstairs on the first floor. On Thursday from 10 to 6, there's the Adoption Day UX Unconference, where we'll do some ZK design lightning talks and then have discussion groups later in the day. We also want to start some learning groups for people who are designing in this space, and we'll keep you updated in our Designing Public Goods Channel on the PSE Discord. Thank you so much.