In this podcast episode, the host interviews Sasha Tănase, a Web3 designer, about the intersection of Web3 and design, specifically focusing on taste in design. Sasha introduces themselves as a web three designer, design researcher, and UX designer with experience working with organizations such as ConsenSys, Aletio, and Self Key. They currently work with Threshold Network.
Follow Dee on Twitter (@dthinksweb3)
Follow Sasha on Twitter (@sasha_tanase)
Send in a voice message
The conversation delves into the challenges designers and researchers face in web3. Sasha emphasizes the importance of education and lobbying for research within organizations that may not initially recognize its value. They also discuss the need for design to be integrated earlier in the development process rather than being an afterthought once smart contracts are already in place. Sasha and the host highlight the difficulties of designing for Web3, where different protocols often require different design approaches, and patterns are not easily transferable.
The discussion then shifts to the concept of taste in design. The host describes taste as the ability to distinguish quality based on industry standards, drawing parallels with food, fashion, and technology. They mention Apple as an example of good design in the technology industry. In the context of Web3, the lack of an established design culture poses challenges in teaching teams about taste. The host and Sasha both express the need for designers to be recognized for their expertise and role in improving products beyond aesthetics.
Sasha shares their experiences of initially educating their colleagues about the value of research and design. They discuss the ongoing effort to keep their team engaged and informed about the importance of the user experience and establish trust so that developers feel comfortable seeking their input. The conversation concludes with reflections on the evolving nature of Web3 design and the ongoing challenges of advocating for good design practices within the field.
Transcript
Dee 0:00
Welcome, welcome. Welcome to an episode of desired out where we talked about web three and Design.
Today, I was awesome designer named Joshua. And I'll probably butcher your last name like I usually do. They are a designer at wrestled with just trying to bridge the gap between a Bitcoin and Aetherium. And we're today we're going to talk about weathering design, and particularly taste. Sasha, do you want to introduce yourself real quick?
Sasha 0:37
Yeah, hi. So I'm Sasha naszej. I know it's very hard to pronounce me.
I'm a web three designer. It's, I like to call myself a design researcher,
UX designer. I've been working in UX since 2012.
But in web three, I joined in 2018, I joined consensus.
I worked with Alessio there, which was
an Aetherium data analytics platform, and mostly my target audience. Were developers, and we were holding them back then, like defy power users and developer power users.
Yeah, and around these, we were also building a lot of tools that were targeting web three developers can't even remember now that I was calling them DAP developers, which is very correct. And when I had a talk at East Berlin in 2018, I remember I asked the people in the audience. So are there any DAP developers here? And nobody
was very funny. Because I believe I was using the bad lingo. So yeah.
Yeah, so long story short, I work with consensus. And then
I lead UX design at sales key, which was self sovereign identity wallet. And now I've been working for two years now with treshold network, who is been formerly known as keep network and new cipher network. We are the first company, not company networks, the
only theory? Yeah. Yeah. How's it feel to be one of the two researchers in web three?
Dee 3:03
Just kidding. I mean, I mean, that we don't have a culture of research and web three
at the moment. And I guess I'm just curious about like, how you've approached research as a designer and a researcher. I am also a researcher and a designer. I'm curious about that experience. So how do I do approach the dynamic search? So first of all, it's very important for me to find
Sasha 3:35
an organization to work that understands the research needs.
And let's say even though they I consider that everyone
needs research, but some of them do not know the thing you need to research, I do a lot of education. And in some of the organizations that I worked with, I had to do a lot of lobbying research, which I didn't find.
I don't know, let's say annoying, because I'm trying to consider that everyone is innocent. And some people who may not have ever been confronted with research and thinking might not know what that is and why it's important. So I'm trying to build a lot of education around it and try to lobby and make people understand that super important and I'm not doing this only inside of the companies that I work with. I'm doing this also outside of the companies by doing a lot of talks at all of the web three conferences. I'm there trying to fight the good fight.
Understand that
This is important. And last year at DEF connect, I remember when I was
doing a talk and explaining that
design in web three shouldn't be, after the solidity contract, like the smart contract has been already written.
In parallel developed. And I remember, there was a Japanese
developer and Dr. Mike talk, he came to me and he said, Wow, I didn't know there could be another week,
getting it wrong for so long.
Dee 5:46
It's really hard to change anything after that smart contract. Like, you can't change the user experience after that development work has been done. And you're kind of basically fighting against the tide at that point. So that happened earlier in the process, design and definitely needs to have an early because
oftentimes went through what I've experienced is that I'm being approached, you know, about a UX problem. But then I have, like, you know, a bible of constraints, because of the, how it was developed. And it's like, well, I can't make this user experience better. Because, you know, you know, it would be too much, you know, costs to like, change the way that it works mechanically. So yeah.
Sasha 6:31
There, like the user flows are most of the times dictated by the smart contract interaction. And if you're giving the designer the task to do the experience, after the smart contract has been written,
this designer will be only able to
patch the experience on the landing.
And I'll bring some
things around the statics maybe try to make the experience better with copywriting. What you can't really do a lot. So the core, like the experience at its core, it's already done, when the smart contract has been
completely written, and not only completely redone, but it's been written, audited, everything.
Exploits referred vulnerabilities addressed. And then you're like Cloud? Like, yeah, I can do an amazing experience. Thank you bet. You could do a bunch of totems and model, but that's about it, you can't change the actual UX.
I mean, in websley,
tooltips. And models are like in every UX designers, kids, and until we are going to be
Should be a bit challenged when we're talking about difference. The hardest part of web three, is that you're dealing with different levels of competency, depending on the person's like individual
Dee 9:24
interest. And so like, even myself, like I've been web three for about two years. And but I'm not a liquidity provider, and I'm not a trader. And so although I understand the the, you know, the methodologies abstractly, like when I'm going through liquidity, providing flow, I might not understand the implications of every of the actions that I'm doing. How, you know, basically based on the task, and so, in my early days at sushi, that's what I learned is like, yeah, I was interviewing a bunch of defi natives, but depending on the person, they might have a different level understanding of it.
Sasha 10:00
what they're doing in the UI. And so it's hard to design for that, like how you design for all those different levels of competency because, like in a traditional sense, our tools are very, like a mix of b2b and b2c. And in a b2b environment, you know, you can pretty much bank on your your users knowing a minimum amount of knowledge, most of the time in a b2c environment, you pretty much think that you're using those nothing. And so we're like a definitely a blend of those two things. And it's definitely a hard challenge. Although I am not a fan of tooltips, I think, I think if you need a tool to maybe the UX can be reconsidered a little bit. But that's just me.
I'm in favor of just having the information just there. So hidden, you know, well, I know what you're seeing, but sometimes I need to fix in order to make sure that I have some
from school, I think it's somehow our duty to make sure we understand them and then
create the environment and the context in situated they will start
becoming
more comfortable and open up and the great colleagues that know I have
time for sure.
Dee 50:13
Thank you so much for finishing this episode designed out to learn more about us. Follow us on Twitter and our website designer dash doubt dot XYZ till next time
Sasha 10:57
white space. To add it to we're talking about the different kinds of users and the fact that some of them have some knowledge and some other are maybe less knowledgeable. The somehow funny and ironic part of web three is that the moment a user or a designer, has learned about one protocol, whatever they learned, they cannot apply for the apply on the next protocol. Because it's designed, it's so different protocol, that you can't really make a lot of patterns. So whenever swan is coming with some sort of, I don't know, term, and they start using it. My next move is that, oh, we have something very similar to that. And let's adopt the term, there are some people who already been educated and wrong. So let's just make sure we're using the same lingo. Because it's like, so many so many things. So yeah, it's, I think it's so hard not only for the designers,
Dee 12:24
and developers have a need or the want to reinvent the wheel and you as a user, user experience, professional have to be like when people aren't using our tool in isolation, they're using it in conjunction with other tools. And so if we adopt different languages in different patterns, that's gonna make it ultimately harder for them to use our product. And so even my work at duality I've been, I study like not only Cosmos chain I study Ethereum, I study AWS, you know, like, optimism just to make sure that like across different chains, that the experience is like recognizable, at least. Because they're going to be using like they're not just it didn't just show up here, they came from somewhere. So moving into that, I want to talk about taste, meaning and let's define it for a second, I believe taste is like basically similar to like, tasting food, like knowing what is quality and what is not quality based on like, based on the industry, industry, I guess, how do I base good design? I think I base it on the the titans of industry. Like I think Apple is a someone that we look to a lot in terms of good design, I think in in, you know, in clothing contracts, we looked at designer brands, in terms of signaling for good for good, like fashion design, or similarly to food we look at like, you know, refined or like, revered chefs in terms of like food. And so when it comes to web three, because in the beginning, there was like little to no, like it was all devs just patching this stuff together. Like what there wasn't like a design culture or still isn't really. It's still developing. And so we run into this issue of having to basically teach our teams taste and what that means. I guess it's you like, what do you how do you define taste? I know it's a hard thing to describe.
Sasha 14:30
So to be honest, I feel like taste is basically basically the tip of the iceberg or like find the light. I feel like we have might have a bigger issue just I think we're three has the issue of acknowledging different professions and Understanding that before something looks good, it needs to work. Yeah. And I think that's, that's like a really, really hard problem that I think every web three designer must have encountered.
Dee 15:19
Yeah, I definitely encounter, um, how do I say this diplomatically, I encounter people simplifying or under, under estimating my role. And for and developers, assuming that UX is just UI. And so they're what they're looking for is like, coin base or uni slop, or like, that's how they define their taste, you know, based on like, the higher end of web three, and like, make it look like that. And I'm like, Yeah, I can make that. But that doesn't mean that this is gonna be like a work in terms of like, user flow and understanding. And, yeah, that's what I run into a lot, just like not understanding my role, and like, not allowing me to, like use my level of expertise to improve the product.
Sasha 16:22
Yeah, I think to be honest, I think I'm a very privileged person in my team. And with the organization that I work with, because I came to this organization, after they have realized they actually need to have someone to think very well, that's news, and they need to talk to their users. So I stepped in on an amazing background. And then amazing, put together a context. However, I as well had to work a lot to make my colleagues understand why research is great. Because yeah, of course, the first time is like the novelty effect, and everyone jumps in, and they're super excited, and everything is great. And then they hear the opinions of the users, and they're like, Oh, my God, I never thought of it. I thought it was amazing. If I didn't think that it could be so difficult for the user, then in time, they start to lose interest. And I believe this is a very, like keeping the flame alive. One of the things that I feel like I have encountered, the other was to make sure that my colleagues know what I'm doing there, not only two or three of them, but the development team knows what's my role, what's my job, what I do, and then make them comfortable whenever they have an issue, to talk to me like Hey, be encountering this problem with let's say staking, and I believe you might be, might have a great idea or to help me with this one. And it took me two years. And I feel it was like constant work. But I'm very happy that now everyone from the development team, the solidity developers, the front end developers, everyone knows that if they have something that they believe, might implicate the user and the flow, they know to come to me and tag me in our Discord threads and whatever to his was two years
Dee 19:07
to build that trust. And I think another thing that is not talked about enough, InDesign is like how you have to become a salesman and like, pitch and continue to get buy in from your team. It's unfortunate that it has to be that way. But it really, especially in web three, where it's a developer centric environment, you have to do a lot of that selling. How do you deal with a team that wants to do spaghetti against the wall, ADHD Type, Product building? A lot of rebuttals that I hear often is like, Oh, we don't need research, we just need to keep pushing our features until we find product market fit. Or we don't, you know, we can just like run small, we can do Lean startup and just run small experiments and then see what's working, what's not working. We don't have money for research, you know, I mean, that's usually the typical order. battles I hear,
Sasha 20:02
I mean, um, so sometimes you need to be a cowboy. I am like picking my battles. If if someone is like telling me that it's not important, like research is not important at all for them, then I will just leave that group. It's definitely not for me. So, I mean, if you're trying to educate them, and they're still telling that, then it's not you, it's them. On the other hand, like, sometimes, like, when your state saying, Let's be like lean startup and just test, often and small, I think that is great, they are already a good place that they understanding they need to test. And I believe it's better, if you have the opportunity to test smaller features or features, just, instead of waking up to the entire end to end is much, much better to have small steps of iteration. But I think sometimes you, you need to choose your battles. So let's see, for a small feature, if there is not enough time, I would sometimes just work with it, maybe to some unmoderated testing, or internal QA testing, and it's still, okay, it's not the best, but it's better than nothing. Then, of course, run the tests afterwards. But then sometimes they're like, We really need to just push it out the door. And then we can come back. And if it's not like an MVP, then there's no problem. Because you only have some features that you always need to measure when people are are saying, we will see what works and what doesn't. Okay, but then how are you going to see what works and what doesn't, we need to have a way a means of measuring. You cannot know what's bad, what is performing, what doesn't, you cannot compare, you need to have a starting data. compare against it. So I'm I'm okay with or expense are measuring. Maybe you're basing basing their level of understanding for some things only on analytics, but they need analytics. And it's only like,
Dee 23:04
exactly, I
Sasha 23:06
think it's okay. And then they're like just waking up their stump and push putting it against the wind. It's not really
Dee 23:16
I think I hear a lot of like lean startup, but they don't fully commit to the lean startup. Like it's like, it's like what you said, like, if you're gonna run small experiments, you need a certain amount of time to gather baseline, have you defined that baseline before that experiment? Okay, what is our baseline, okay, and then in like planning, okay, after this feature, release, what data was gonna go back and look at it, you know, like you're having a plan, versus just saying we're running small experiments. And then like, instead of getting high off with a product release, and like not doing retros or not like, like, not reflecting on what was done. And then just moving on to the next thing, you can easily become a feature factory in kind of lead to like an cohesive product experience doing that 100%.
Sasha 23:59
And then I think you're, what you're doing is that you're only gaining design that at some point, if you're not addressing that, that the users will start fixating you, because you're ignoring them. And then they later return ignore you as well. I remember, I was running research, and there was been a participant who told me, Well, their documentation looks like bollocks, and it's bad. And if they don't care about me and putting together a good documentation, why would they even just care about them? It's just like disrespectful. So I'm gonna use this. And I think it's so important for people and for products. appears to hear that this isn't like their language. If you don't care, it's just like you're turning a cultural,
Dee 25:10
your ego building people can feel that eventually and then they'll they'll start to become disengaged, what's your, what's your brand? Because you're just engaged with them. It's like, it's like you, if people don't realize, like product building is not like a performance, it's a conversation, like, you know, like, you're not having that conversation, then like, why should they care about you? You know, not invested, you're not invested, you know.
Sasha 25:41
And then I wanted to touch up on something that you've mentioned earlier, like, products in product teams that are not doing market fit research, or just the type of products that someone woke up in the morning and said, Oh, I think this would be a great thing. And then they never tested it. And somehow, like, the need, find the product. It, it's, it's just like a one hit wonder type of I don't know, singer, it will work for some time. But then it's just like, it's happened to overlap with the need. But if you're not coming back, or like riding that wave and saying, Okay, we found this need or this need. And we weren't there, let's see, how might we improve the product? And how might we add to this, so we get responsive users, then it will slowly die. If you're not doing that, it's clean. You're you're not evolving.
Dee 26:57
I'm bringing back to my original hypothesis, original point about taste. And now we're moving more into UX and tasting UX can be kind of intertwined, because basically, we as designers, we we've been doing this for years, right? And so we have, we're, we're not only coming to these organizations, with zero knowledge, we have an idea we've, we've observed how to step back, we've observed user behavior in different contexts over time, which then builds our tastes and builds our instinct for what is good, and what is bad UX, in addition to like, our education outside of our roles. And so our challenge, when coming to these web three organizations, like these developers, these stakeholders, they don't have that experience. They don't have the experience of watching someone use products, various products over time and understanding like, you know, common pitfalls, common things, like how do we, as designers, like basically share that knowledge? You know,
Sasha 28:05
what I've been doing with my team, was that we would have monthly sort of talks. So every month, I were to present them something. And it was, again, educational for everyone, not only for the developers from for everyone from the team, and I would present them at the UX heuristics. And why this is why those are important and how I get to see that something works and something doesn't, because it's not that we find a magician to do. Magic mirror, and I'm saying it's not working. Everything is based on iterations and knowledge that was gathered. So there were patterns put together. So it's easier for someone to understand that it's not something that I have come up with. It's more like it's a science behind this, and I think it's easier to this is what I was doing. I was doing some sort of design talks. And I would be educating my colleagues, and not only on, let's say, UX patterns in UX methodologies, but also I would be picking up a product or product and doing some sort of dismantling mantling of the product and helping them understand why this works and why this doesn't work with all of the better Is all of the heuristics support, even with my like, I would test it as the user and tell them just what was my experience how this made me feel. I'm always trying to bring up emotions. So people understand better how the design is itself, our how the mechanics of the product makes the user feel. And in webserie, I think most of the users feel afraid.
feeling afraid, the fear of loss, it's so big. And it's not only in web three, it's also in banking, and any financial system, and it's super, super strong, and it's everywhere. And then you feel stupid, because everything is so complex. And there are people like, I don't know, who will come to product that is extremely complex. They've never read anything about it. They don't know anything about it. And then they will feel completely stupid in front of that thing. And
Dee 31:27
important to your team. I think another actually listening to you talk. Another thing that is the downside of accessing research or not doing research is that you start to miss that emotional piece. Because you're not testing with users or just looking at numbers on the screen, you're just relying on data analytics. So you're not getting that qualitative feedback of watching and seeing and feeling someone use your product. And so your users start to become more and more abstract each day that you don't do that kind of work. Yeah, it's hard to maintain that empathy. We're only relying on data analytics in terms of feedback. Yeah.
Sasha 32:17
That's true. That's true. They're they become deposits, they become deals, they become transactions. And it's very easy to forget the behind the deposit and the transaction, there's a basin, there is someone who has feelings. And I believe this is why it's super, super helpful to feed your colleagues, anecdotes, and verbatim quote unquote, things that the user space or just if they have time, and this is like the ideal scenario for the team to join the interviews. And I'm
Dee 33:01
try that. It depends on the person. Some people are like, more keen to it than others. For sure.
Sasha 33:09
It's hard. So I did that at some point. Some of them like at first, of course, we need to is super novel. Some of them were trying to make time participate. However, I see probably, I can't actually put the blame on them. I think they have a lot of warning coming with one one hour of an interview, their hours of code time and depth time. i It's extra extra load on there. So it's like, yeah, I can't blame them. I wish they could be there. But sometimes there's no possible and
Dee 34:02
social media approach when it comes to advertising research. Meaning like, how can I make this like, just as engaging or interesting as like a social media post on Twitter, like, and like, slowly feeding that to my team and some kind of was has helped.
Sasha 34:20
You know what I'm doing? Like, I call it the interview. So they're, they're not able to, to join. But after each interview, I give them like a debrief as takeaway, and I'm trying to add as much quotes from that user, and is, remember, I have a colleague who has done a good job cool. I'm waiting next week for you. I feel like I'm watching the series or something
Dee 35:02
like no engagement whatsoever. So sure, I kind of want to build a research bot where like, where like you basically put in your research into like little Twitter type and post, and it just feeds it into your discord like randomly. I wonder if that would work. Like to remember, we learned this and like, so people can still engage with it and remember it because I felt like we forget research a lot, too.
Sasha 35:32
I feel like every time whenever I'm encountering a problem that we already had, or it's similar to something we already had, and like, I remember there was one time with a user, and then I just telling them the entire story. So yeah, that Bob, I want to automate it
Dee 35:55
a little bit. I don't feel like the only because especially especially in web three, where like, we're often the only designer, we have very few teams, it's like, we can often be viewed as like that little birds chirping. You know. And I'm like, I want to put that weight on something else. That's not a person.
Sasha 36:17
I think there might be that could be that bird as their user. But what I feel is that whenever I have the opportunity to try to involve my colleagues, experience design, let's say, it's amazing, because the moment they have been part of the process, more prone not only to accept it, but maybe be understand what was the thinking behind it? And why is it important, and then they have a different way of seeing this. And I learned like this, from the start of this year, we started having everything, even issues and everything on GitHub, and what I've done, I have experimented with it. And I was very curious. So whenever I was putting together a feature or something like whatever task, it wasn't just like change the copy here. They've evolved more process. I was trying to start every feature or every issue, like the context, the behavior, noted. The problem, and then the solution and why I thought about it really is everything, everything the entire process explained. And at first I thought, oh my god, I'm just like, probably wasting time. Because it takes more to write everything instead of just for me things. screenshots and Pigma file. And I realized, because my colleagues told me, they were like, This is great, understand why are they why why you're doing this. And it's also helpful. And it's also helpful for me when I'm implementing it, because I understand the international. So yeah. This might be a good way, if you are not, I don't know pressure by time. Yeah,
Dee 38:46
I'm using like video explaining to like bubbles are loons or whatever. Because I feel like a video, like a two minute video is like easier to engage with than, like, you know, a block of text depending on your team. So, like, I've broken that down into text format, and I've gotten like mixed results. And so I found, you know, I guess my original point is like, you have to experiment a lot and like learn your team and like learn their learning style and like how they prefer to learn. And that's like a part of like, you know, raising tastes early, you know, raising UX maturity. And so I actually to close this out, I kind of want us to, like, give some tips for the designers that are listening. How do you deal with bad taste? I guess my bullet points are, I think one like when you're first joining an organization really learn I would do one on ones I would like learn who they are as people learn, like how what their experiences because once you know put your user researcher hat on, and like kind of ingest like, Okay, I know Bob is you know his background and how he prefers to engage with stuff. Because once you have that information, it will make it easier and easier to communicate. And I think to like really understanding, like you said, picking your battles understanding, like, what is worth, like died on that hill for and what's not a part of what makes me make that determination is like impact, like impact meaning, are we changing huge, like task flows? Are we changing like pivotal points of the user experience, like, if that's so that he is I might, you know, die on that hill more than like a small, like iteration or a small thing that like, users probably want to hear about. And, you know, sometimes you don't want it to feel like it's you against them, you want to feel like you're building with them. And so if you're challenging every little piece of that design, you can easily become like, you know, the Debbie downer, and things like that. And I heard hardly, is like, like, it's like, what we're saying is selling the research, selling the findings, selling the users. And like, you know, ingestible content, whether that be a video, whether it be what you're describing, which is like, you know, explaining the problem, the solution, the context, you know, just always providing context and providing content that is approachable. Because I think the one thing that I learned early in my career is like, I was like, a long form writer, because that was just how I got my thoughts out. And like, nobody wants to read my like, essay of findings, you know, and I had to learn how to, like, repackage my stuff in order for people to understand. And I yeah, like, it's gonna take time, like you said, it takes two, it took you two years to, like, get to that point. I mean, I think a year isn't is a year, at least, because people have to trust you. It takes a while to build that trust, you know.
Sasha 41:56
That's true. So in to add to that, it's super important, not only steal the findings, but make them part of it, and nobody's reading, so I make sure they are, I'm presenting the findings in the report, need to be there. cuz otherwise, I know, they're not going to do it. And, you know, we're there to make sure that even if they're not on the call, and they're not going to read the report, you might have like a one pager of takeaways, super easy, bam, bam, bam, this, this, that because this and that. And it's super, super helpful. And I would also say that if you want to get buy in, in your team, as a designer, you need to iterate on your process and make sure that your colleagues are part of it. And you're improving your collaboration with them. So yeah, that's I think it's
Dee 43:01
super super. And also just dying, when, like you said, sometimes it's just not a great fit. Like if you if you tried all the things that we described, if you if it feels like you're, you're continually fighting your team, to consider UX and to consider users. And you know, you're not really, like you've done all you can do, and you've like, you know, put your empathetic hat on, and you're still not seeing it any empathy or any consideration for your role. You know, maybe that's time to like, move on, because I will say, like, staying in a low maturity, organization that refuses to grow up, will hurt your career in the long run. And you you'll stagnate your own growth by continuing like fight, you know?
Sasha 43:49
Yeah. And it will curfew because I think it's a designer. At least I find a lot of joy in doing my work, and it makes me happy. And it's such a big chunk of my life. I just spend a lot of time with my work and doing my work. And if I'm going to spend a lot of time with the toxic work and the toxic, toxic environment, then something that in the end, instead of giving me joy, it will give me stress, anxiety and fulfillment, a sense of unfulfillment. It's just like in a relationship, you need to break out, break up and find some other partner because it's this like, the way you're choosing your life partner, is almost the same with the way you're choosing your work partner. You're having all of that time and it's, in my opinion, it's a sign of self.
Dee 44:56
Yeah, exactly. I think I wish I had a better developer analogies for the situations that we find ourselves in web three is like, it's like if I, if I told a developer that you can only make this app, you know, with HTML, no JavaScript, you know, it's like, that's the thing, other situation that they often put us in of, like, designing in a very narrow, like, way that it like, starts to become something else, you know, you recognize yourself, you know, like, Is this even designed anymore? Like, I don't even know what's happening?
Sasha 45:36
What's my job and my big, so?
Dee 45:41
I don't enjoy doing that, at all. Um, and I think, um, yeah, I think that constant conversation with design is needed. And, um, I don't, I can go on a whole rant about this, maybe it's another episode, but like, looking at how to knowing how to look at references, and like, look at competitive analysis, and like, basically understanding your product in a sea of other products. And that context is also important. On top of the things we talked about, like recent user research, you know, understanding heuristics, like things like that, because I'm building a product right now, where like, it's a new product, it doesn't exist. And so I've had to piece together references to understand like how this is going to live in the current landscape. And I think, like, you know, pitching it to your developer developer team of like, you know, how you look at other code to like, understand how to do something like, we need to look at other you know, designs, and that process lead to like better taste, or better user experience, maturity over time, as well. Yeah, I think that's, I think we've exhausted this topic. Anything else you want to say, before we close out or like things for the audience to think about?
Sasha 47:05
I think, um, for any designer who wants to join web three? I think they should. I would like to tell them that. It's not that hard as it seems. But they will need to become very comfortable in asking questions, a lot of questions. They might feel stupid is not their fault. That's okay. They will need to learn a lot, be comfortable with learning a lot. And then they will need to be comfortable with unlearning limited patterns. And I really hope more designers will join with three because it's like a, an effervescent space. And we
Dee 48:00
call it Yeah, I think, um, it's definitely an interesting and challenging environment. And I think, being ready for that, and understanding that and also, like, you know, our community designers out, like, if you are a new designer, like me, and you're running into stuff, and you don't understand stuff, like there's a community here, who's you know, who's experienced who can help you through this process, you can get it by us. And honestly, that's the whole goal of this podcast is that, you know, designers entering web three, don't feel alone, because I definitely felt that way. When I first got into this space, and I'd love to say someone else ahead of making the same mistakes that I did.
Sasha 48:48
Yeah, very good racing, and racing. And I would also like to add, for anyone 3d designer or designer who is aspiring to join web three, is that even though we have complained in this episode, the developers are not our enemies. And they're basically islands of knowledge. And we need to learn how to harness that knowledge. Because amazing solutions may spark from those brains, though, I think we need to learn how to collaborate better with them. And because we are more empathic
Can you teach design taste? <> Sasha Tănase