Deep Dive
Shownotes Transcript
One cause of ambiguity is different understandings of the same decision or different understandings that each person has over where we're going, what we're doing, what the plan is. So when you write it down, you give people the opportunity to say, oh, no, that's not what I got from that meeting. I don't think that's what we agreed on. So you can clarify.
Hello, everybody, and welcome to the next episode of Honest UX Talks. I'm Anfisa on the court here, and I'm talking to Ioana today. No surprises, no guests, but a regular episode.
And today we're going to talk about designing in ambiguity. I think that's a topic that we have carried out from the previous episode. It was a bit of a natural point that was brought up in the middle of discussion, and we realized that we didn't cover this topic. And most of us very often, I would say, work in the ambiguous project. Sometimes it's ambiguous team goals. Sometimes it's ambiguous values. It's just a lot of ambiguity that we have to tackle. And we decided just to talk about it and how we usually go about it.
how we solve problems in the beginning and stuff like that. And before jumping right into the episode, I also want to quickly catch up with you, Ioana, and ask you how have you been in the last two weeks? Hi, hi, welcome everyone. Hi, Anfisa. Last two weeks. Ooh, let me just rewind. I have no idea what I've been doing in the last two weeks. Probably just a lot of work. I'm very immersed in my work at Miro right now. Of course, beginning of years always come with these bigger challenges, like what do we want to do this year?
planning vision, the future of the design narrative for your part of the product and so on. And since I'm working in the AI space, this comes with a lot of ambiguity. So we'll have plenty to unpack on that topic.
It's been very intensive and exciting. I'm spending a lot of time building and refining my talk for South by Southwest. It's essentially an extension of the talk that I've been giving in the past, but it's much better. I'm adding so many new cool stuff and this exercise is expanding my understanding of the AI industry, the AI space. I'm moving more into technical stuff, interesting references and so on. And it's essentially growing into something that I'm
more than ever very proud of. When I built this first version of my talk last year, I had a lot of doubts around it. Is this valuable? Is this interesting? Is this common sense? Does everybody just know these ideas? And then when I delivered this talk in New York, I was thinking that my KPI or what does success look like for me was just have everybody in the audience find at least one interesting idea in my talk.
And now I feel like I have a lot of interesting ideas. I mean, for me, they're interesting. So hopefully they will be interesting for other people. So yeah, I'm very focused on that as well. And I guess not much, not much. I'm also baking some interesting future potential things that I might be doing with my life. Yeah.
But we'll see about that. Yeah, very early to start disclosing some of those. So as always, a bit of a workaholic. But yeah, doing good. How about you? How are your past two weeks? Now you intrigued us all with your handcliff on, oh, some changes, some changes, what's going to be in? I don't know also.
Okay, so my weeks were quite intense, I'm gonna say, because I have finally launched that job hunting community group, which was a big stress, honestly, and also excitement. I was looking forward to this for so long. I was like building the excitement to open the community to everyone. I was just looking forward to February 1st, and then it happened, and I started realizing a lot of mistakes I did.
Kind of. I have to acknowledge that. So I've been wrapping my head around it for the last two weeks, pretty much day and night. I didn't sleep well last two weeks. I was thinking about things, running things, pushing things, seeing how it goes. The idea behind launching the new product after almost like three or four years after I've launched the previous product, which is Courses, it's just new rock and roll, especially when you have a baby now. So it's something that you can dedicate all the time to this one project. So it was pretty stressful because I had to work a lot of times at the night.
Well, I actually have to report that I started working pretty much like almost a full-time job, almost 40 hours per week. So I'm feeling proud of myself because I can still take care of the day the whole day and still work pretty much the whole working week. So with the community right now, we're figuring out the path because I realized that my key mistake was that I did this community for free. So after one week of doing it, I found myself spending
prepping too soon, especially with the baby. I couldn't do anything else but just like replying to messages, helping others, reviewing portfolios. I reviewed more than a hundred portfolios over five weeks or five days or something. And just given a lot of webinars. I had like four events every day during the week, plus a lot of mentoring calls. And it was just like overwhelming altogether. I do love all the things that I did, but I just realized that I suddenly stopped doing sport, eating well, I stopped spending enough time with the baby.
It's just my mistake. It's not a mistake for anyone. I realize that people are in a bad place. So when somebody gets an opportunity, they're using it. But for me, I knew that it's not sustainable. So I have to change something and I'm still figuring out the way to do this. I'm talking to community right now to figure out the best way to move forward, considering either to close the community behind the paywall. So making sure people commit. And I only work with the people who actually have a chance on finding job in this very turbulent market right now. Or alternatively, I'm looking for different ways.
Also considering opening the courses in a more dynamic way. We'll see, we'll see. I don't want to spoil right now, but it's a pretty stressful, you know, rocking journey as for me, just because I realized I did a mistake. I'm doing the damage control right now and I still want to help as many people as possible, but in a sustainable way for myself. So that's where we are at the moment.
But the good thing is that I'm going to travel for three weeks, first time with the baby. So that's also an exciting thing to do. I'm sure it's going to be very new rocking traveling with the baby for so long. You have no idea how it will go. We will be in the plane for five hours. I don't know how the eight months baby will behave in such a long flight. A lot of things to think about, a lot of things to pack, a lot of things to make sure nothing goes wrong and stuff like that. Exciting times.
Anyways, I don't want to spend too much time talking about us. Let's dive into this tricky, tricky topic, let's say so.
Okay, so working in ambiguity, how do we as designers do our best job and actually arrive to a solution that helps someone? And the first question I want to start from, it's very helpful for our listeners when we talk about our specific cases. I can think of one project, but I also wonder if you, Ioana, can think of the maybe recent project, of course, without any details because you're on the NDA, where you had to work in the ambiguity. What was at least the scenario in which you worked at?
What was the team dynamic? What were the ways of how you wanted to go about it? So I'd love to hear a little bit of the cases and then we can start unpacking how we went about solving those cases. Yeah, I actually had a lot of experience working on Ambiguity. It's really interesting that my first design job was in a very big company, ING Bank, and it was a pretty mature company. The banking industry was an established space.
It was interesting that you wouldn't expect so much ambiguity to go on in these kinds of spaces, but the ambiguity came from the novelty of the design role. So when I became a designer in ING, in the Romanian headquarter, essentially the role had been introduced for one year or six months or something, and the senior people all left. And so I was the only designer for the entire bank, and I was junior, just transitioning. And so the ambiguity was, let's say, a personal kind of ambiguity, which is...
a very particular kind of chaos that has to do with your own inexperience or just not having been through these tough contexts and complex systems that you need to navigate and so on. But then there's also the external ambiguity that for me personally came with startups and scale-ups. And the bigger the company, the clearer the processes, the more mature ways of working and processes
product problems, the problem space was already better understood. And it makes all the sense, right? So when you're building a startup, or even when you're scaling, you're doing things for the first time. And that's what's causing ambiguity. On the other hand, I feel that every time I was in the setup of ambiguous stuff, there was an accelerated learning going on. And I think the point of the design job is to uncover, put the spotlight on the ambiguous parts and make them clear.
So it always felt like a very exciting challenge. Yeah, I don't know, maybe I can pick a random ambiguous context and dive deeper into it. But let's see what my brain chooses for today's topic.
I think the one where I felt most lost was when I joined UiPath. So I joined them as my second big full-time job. I joined the marketing team, but then I got offered a role in the product team. And I said, of course, I would much rather work on the product than on the website. And I was very excited and I moved into product team. And then there was just chaos because this team was also pretty new.
At that time, UiPath was Series C, hyper growth, kind of going from 100 people to 800 people in a couple of months, opening offices all over the world. So it was very intense and very rapid and not the rhythm I was used to in my previous role at ING Bank. So...
Not only that, but design was not present. So before me in that team, there was one designer. He was there for a pretty short period of time, I think a couple of months. So there was no design maturity. There was no design seat at the table. There was nothing around that. So I joined this team and...
The product was very technical, so I had to understand a lot of ambiguity around the problem space and the product itself, which I failed, I think, even by the end of my role. I feel like I didn't get that product completely. I just couldn't get it because I was so far away from the persona of that product, which was a developer mostly. Maybe I could have done something different. I guess there are many things I could have done different, but I failed. So...
I didn't get the product, like deeply. I just want to make this quick point. Sometimes as a designer, you don't need to get the technical parts because they might bias your thinking. You might find things complicated, easy to understand for other people. So if you don't get it, you can still be a good designer because if you don't get it, then how will the users get it? And so you super simplify things. You communicate them in the
easy way that kind of doesn't assume that everybody has that technical complex understanding anyhow so there was the ambiguity around how that product worked and there was also a lot of team dynamics ambiguity right so there were I think nine product managers or eight product managers and I was the only designer and the software engineering team was of course much bigger there
There were already a lot of tensions and a lot of pressure to make this product evolve. The product needed to support the company growth in a way, right? So the entire company was growing, the other products were growing, and this was sort of a control panel of the other products. So it had to be able to accommodate that growth. So there was no time to waste, right?
We needed to introduce very new complex mental models, new complex paradigms like folder structures and integrations with Microsoft and all sorts of things that were user directories. And it was a pretty difficult space to operate with. And so there were these two levels of stress that I've been put through. One was understanding the problem space, the product, the users, and then understanding team dynamics, which were also very ambiguous.
I think how I tried to tackle it at that moment was to introduce a process very early on. So I thought that at least we could build some clarity around how we work. But it turned out that that was very hard to reinforce and practice. So it looked very nice and everybody was excited. Oh, we have a design process with these check-ins and these milestones. And now we're showcasing design and everybody can critique.
And we were using Zeppelin and everybody left comments and they were all part of the feedback gathering and how we are evolving solutions. On one hand, things were interesting. On the other hand, there was always the mess that I just couldn't control.
Things really derailed most of the time. I think for my entire experience on that team, eventually I went on maternity leave and then I switched teams and the company had grown for two years when I was out and it was almost completely different company when I rejoined in terms of clarity and the lack of ambiguity and
And yeah, overall, just even the design maturity had been accelerated because the design team grew, we brought in design leadership. So essentially, there was more of a partnership between the triad, right? Product engineering design, as opposed to a company that when I joined was mostly product engineering and design was always the afterthought or just something that needed to establish some authority and trust.
Yeah, I think I can dive deeper into any of those things, but I'm going to stop now and ask you if you've had a similar experience or if you want to ask me any follow-up question or just tell me your story of ambiguous environments.
Yeah, first off, I also wanted to say that I wonder if my scale-up story will be also different when I return to the office because you were away for two years, I will be away for only one year. I'm just very curious if something has changed, if things have been a little bit more clarified or not. Something very exciting to look forward for.
Long story short, actually, my story was extremely similar to yours. I think we both work in very technical environments, targeting developer personas, a very technical guy, usually. Sorry for specifying the gender, but it's typically a guy, and that's unfortunate. When I joined the company, it was also my biggest story of ambiguity, because I was constantly faced with projects when I had no idea how to go about them.
I was there a little under two years and pretty much all the time I've been there, I had no idea what I'm doing there. I had no idea why I ended up here because I'm so far away from the lifestyle of understanding the problem, understanding their work, understanding their mindset and thinking that I constantly felt these insecurities and like, am I doing the right thing? Who am I designing for? How do I know that I'm doing the right thing? Luckily, I have the husband who's a developer, so it's
It absolutely helped me. Spoiler alert, one of the ways for me to solve working on this was to take a lot of courses on the backend, on understanding the tables and the relationships and APIs and how those works and stuff like that. I literally took a lot of courses and like you'll have an amazing team in the company.
All of them were trying to make a great job, trying to educate me. Honestly, like I had a lot of masterclasses from PMs, BAs, even designers. At some point, I realized, oh, I'm not so bad anymore. But still, working for this technical persona was just so different from what I'm used to. And on the one side, it's great because obviously that's a challenge. That's a growth. You're learning something new.
new. And obviously, if you're working in a tech environment, it's very helpful because moving forward, you'll understand this context so much better. But at the same time, it was a constant imposter syndrome for almost two years. A quick example here would be that, you know, as a designer, you're so incentivized and always asked to design beautiful, sleek, innovative, simple solutions. That's all we put in our titles, right? Always. But the reality is that when I started working for the tech persona,
They didn't want anything simple and slick. They want those complex tables. They want everything at the same time into their face. They wanted complex solutions. I was like, oh my God, what am I doing here? How do I design the complex solution? And I don't understand all the data they want in front of them, right? I had to switch also my thinking on how they typically want it. And again, I'm not saying that I should have started designing ugly interfaces. That was not the goal. The goal was to give them what they need, but
At the same time, make it so that every new user also understands how to use it. So the challenge was pretty interesting. And the part of the ambiguity that fits into that scenario or context was that every time we had a new project, I remember myself thinking that I have no idea what they're trying to build.
I have no idea. We sit in the planning and I'm listening to all those pitching projects, PMR, pitching, doing their presentation, explaining your objectives. And I'm sitting there and I'm realizing I don't understand half of the things they're saying. The words they're saying, I don't get them. The abbreviations they're saying, I'm not getting them. Seriously, I just remember that they're telling me to build something. It's a corporate environment. There's like a planning for, let's say, 500 people. And
I'm sitting on that presentation. I cannot unmute myself and ask the very stupid question in front of 500 people, right? What is the thing, guys? I'm a designer for this project. So that's the situation I find myself in for a while. And we're doing those presentations. We also have to estimate the amount of work
we have to do. So my estimation was pretty much always the guessing game. I had no idea how I'm going to go about this. And my biggest mistake was that at that point, I had this new design manager in my team that I didn't feel like we had a very good relationship with him. Every time this guy would just ask me like, do you know what to do? And I just didn't feel comfortable sharing that I have no idea what I'm doing. The part of the ambiguity was that I just felt myself
I am in a place where I don't know what I'm doing. I don't have trustworthy relationship with my design manager and I have no idea what I will arrive to. And so, yes, in many ways, starting from the teamwork dynamic to how organization works, right? How the planning went. How do we derive the answers from the team to even the context to, you know, designing for the technique
persona. A lot of those parts were contributing to my feeling of being lost, of being absolutely covered by imposter syndrome. I'm not sure what I'm doing here. And I think that's part of the reason why moving forward when I switched to the next role, when I started working in hospitality context, that's why I was so eager to work in the context that I understand so much better, so I can feel easier, right? Working in hospitality space, we all travel. Like Ioana said, you don't want to say I'm
I'm designing for myself. Definitely not. That's not a part of your job. But at least when you hear the objective, you understand the aspiration, what you're trying to create. So the goal is usually understandable or at least clear. You might not know the details. You still have to figure out and discover them. But at least you know the goal. That's the biggest shift and the reason why I actually wanted to switch to the place or environment or whatever context that I understand so much better.
We have talked a lot about such an interesting topic, which is called the teamwork. I think that's the key to arrive to the clear result when we work with ambiguous projects. So now I know that you're working in a very ambiguous space at Miro, and I really wonder, given this context that you said, that you feel like you failed in many, many cases, and now you're again in an ambiguous environment and trying to go about it, I bet, in a more mature way. Can you tell us a little bit more on how do you handle relationships? How do you manage the teamwork?
I think the ambiguity aspect is something that it's very tricky to permanently solve. With every role change that I've had in my career, I've stumbled into new kinds of ambiguity, which in a way they were similar to things I've experienced. Team dynamics, right? It's like again and again, the same story of parallel conversations, silos work, lack of transparency between teams, miscommunications, and so on.
I feel that in a way it's specific, if that makes sense. So I'm running into the same problems again and again. But in many ways, they're very particular and different to each company and environment and problem space and product and so on. So some things that I feel typically work or are more of a general ways to tackle this ambiguity that I'm using in the present time.
is essentially to try to always converge every single conversation to a North Star, to like, how does this align with the other things we said we're going to do, and then turn it into very actionable points. And now with the help of AI, you can have AI companion in Zoom to give you the summary, which is not very reliable yet, but yeah, probably we'll get there.
But the essence is that what causes the biggest ambiguity in teams is not having a source of truth for what's being agreed, not documenting your work, not documenting conversations. So in my second role at UiPath, where I was very happy and...
And in my current role, I'm admiral where things are going well. I think what changed was that I became very religious about documenting stuff, even using Slack for that, right? So after we had any kind of meeting, even the seemingly unimportant meetings, I would write a short summary that I would share with everyone just to make sure that we have the same understanding. So I think one cause of ambiguity is different understandings of the same decision or different understandings.
that each person has over where we're going, what we're doing, what the plan is. So when you write it down, you give people the opportunity to say, oh, no, that's not what I got from that meeting. I don't think that's what we agreed. And so you can clarify, right? And you can do it during the meeting, each conversation as well, like,
okay, takeaways, action items, what do we want to do next, what was decided and so on. And then many times when I think we have immense clarity, it turns out that when we start trying to draw conclusions, it's like, oh, wait, is this what you were saying? Because I was thinking about something different actually. And so have those conversations, clarifying conversations where you sit down and put into some structure what has been discussed.
I think that helps so much. It's sort of a basic hygiene kind of thing. But many people simply don't have the time to do that, right? So you have a meeting and then you have to deliver the Figma prototype or whatever. You have to jump in another meeting. So you don't have the time to write a summary. Here's what we discussed each time, especially if you have back-to-back meetings or a lot of work to do in general. And with my triad, we have a Google Doc.
and we document everything in that Google Doc. I mean, you don't have to over-engineer it. You don't have to put it on, I don't know, some sort of a very complicated JIRA board or whatever, or product board, or use tools or Notion or whatever. You can simply have some
something as basic as a Google Doc, or you can even use Slack, but that's harder to understand the journey of what was decided. And so I think what the cure for ambiguity is clarity. And to build clarity, you need this kind of transparent documentation of everything that's going on. And it also helps you very much when you're trying to build your portfolio or when you're trying to transform everything into a case study that you want to share maybe within the design team in your company.
Or whenever you're trying to run a self-reflection exercise, right? Let me just go through these notes of how this project or feature went on and then learn what went wrong and then learn what I could have done better, understand the points where things went in the
wrong direction and so you have much more clarity both on an individual level which translates into just better self-awareness and when you build the self-awareness you can also translate it into better tangible actions that continuously improve the process of collaboration in the triad and beyond the triad right because this documenting of what goes on helps you be a better teammate in the design team as well or just a better professional in general right even a better freelancer i
I think as a content creator, you can also document stuff. So you build that clarity of continuously reflecting on what goes on. So I think that's something that helped with ambiguity. But then other things were just not putting a lot of pressure on myself. Like I think designers tend to feel that maybe product managers have that feeling even more than the designers.
But I think there's that feeling that I'm doing something wrong. We miscommunicated again. This person has a completely different understanding than I thought they had. And I explained something completely different. And here's what they got. I must be doing something wrong. And then understand that you're essentially in a team where things go wrong as a, let's say, team disease, not necessarily a personal failing. And so working continuously in a collaboration effort is
to understand how to navigate ambiguity. And I think the last point I want to make around building clarity, the cure for ambiguity is clarity. My last point on this is that the hardest part is
uncovering these unknown unknowns, right? So sometimes you don't even know what's ambiguous. That's the idea of ambiguities. Many things are not known. And I think what really helps is to understand what are the questions we need to answer? What are the things that we don't know? How would these translate into, I don't know, research questions or just maybe questions to leadership? Hey, we feel that there's not enough clarity on, I don't know what OKR or whatever thing we need to achieve. And so just continuously asking, what is it that we don't know that's causing this?
confusion or tension or misalignment and so on? Are we missing information? Is it the cause of ambiguity? Is it just ambiguity itself? And how do you disambiguate it? So yeah, I don't know if those are very tangible pieces of advice, but I think at least the documenting part is something that you can start doing now. What has been your experience?
Yeah, these are very cool points. I love to see your transformation journey from understanding the mistakes you did and realizing how important is documentation. I remember even when we started recording this podcast, you were saying that you're so bad with documentation, you hate it, and now you're telling this is the cure.
So it's beautiful to hear this story. In my opinion, there is a very similar answer to how I'm trying to tackle this today. Long story short, I did realize also at the same company when I was working in a very highly technical environment that workshops is my key answer to
to go about it. And I'm still a very big advocate for the workshops and I'm still trying to do them every time, even when I feel like people know what they're doing, everything is clear. Let's just jump into it. I'm still trying to squeeze in the workshop, just making sure it doesn't hurt and never over align everyone and just making sure we know what we're doing.
The problem with ambiguity in my past experience was that there was never straightforward answers. There was never like a clarity on the direction. So let's say one PM who put together this objective deck, put together one meaning in that deck and everybody understood it in one way. And then the problem with lack of clarity and, you know, ambiguity is that everybody understands it in very different ways, right?
I love this infographic about workshops when everybody had in there had different shapes, right? Somebody had circles, somebody has rectangular, somebody has triangle. And then everybody's designing or working on whatever they're thinking of. Until you do this workshop, everybody's thinking on different things. So it's super, hyper important to ensure the alignment. And for one, like Ioana said, documenting everything is a very good way of aligning everyone and making sure everybody understands what we are doing.
To me, why a realized workshop is very important is because when you navigate this conversation, when you make sure you're asking all the right stakeholders, you're essentially making sure they're committing to those things. And you want to put them onto some structure. You want to put them onto some paper just to make sure you can always backtrack.
track to it and remind that that's the goals we all have agreed on, right? These are the key priorities we have decided on. Even when there is no straightforward answer, let's document those no straightforward answers. Let's document what we are working on. Let's document what we all are thinking about, right? What are the directions? It's almost like the whiteboarding challenge that we do today when we are applying for jobs, right? And somebody gives you a very general prompt and you have no idea how to go about it. You want to start somewhere. You want to document your initial thoughts. And that's
where I feel like the power of workshops really plays a very important role. And I think it goes in line very well with what you said, right? It's about a documenting, making sure everybody has the same things in mind, or if not, let's write them all down and then find the common themes and agree on something right there in the workshop.
Obviously, there are workshops for different stages of the project. And right in the beginning, it's about understanding the key goals and the key action points. And then later on, it's more about going through the insights prior to adding the right things and stuff like that. But in the beginning, for me, it's a lot about just making sure we all know what we're working on. And even if the
things is absolutely unclear. Like, Ioana also pointed out that sometimes you don't even know what you're solving, right, until you start doing the discovery. You don't know what you don't know. And then I think at least those questions that we don't know, at least the directions needs to be written down somewhere. And there has to be action points based on this. So every time we finish the workshop, it's so important that you arrive to some, not to say conclusions, but at least A, everything is recommended. B, you know the next steps that needs to be taken in order to address those questions that we all have.
That's, again, like the power of the workshops, in my opinion. But the second thing I also realized from my experience that I also want to share with everyone is that I feel like it's super important to identify the key stakeholders in this journey. Because the tricky part, especially if you work in the enterprise context, where there's so many people, so many sometimes senior people with very strong opinions, you always have to make sure everybody aligns with it, right? Everybody's having the same picture.
So there are two things. First is you need to identify the key stakeholders because those are the people who will essentially be presenting it. Those are the people who will be backing your thoughts, your designs, who will be presenting it. So you need to understand the key stakeholders.
Who are your key partners who make the final decisions? Without it, you're kind of potentially spreading things by listening to way too many people taking their opinion as it is a must, as this is important. And sometimes you end up with the situation that is even more blurry and even more confusing. And you have no idea how to go about it because maybe there are contradictory opinions, opinions that have very different directions and ways to solve them. It was very helpful when I realized that I need to see who is the main backbone
person who puts the bet on, who will be paying with their own money for this bet if we fail, right? So we need to identify who pays, who puts the bet on. And I really like this tactic for prioritization. I think I found it in the storytelling card decks. I think it's called $100 bill or something like this, where while we are prioritizing and trying to understand what we're building, everybody needs to say, I would give my hundred bucks on this bet. And so if we put a real money onto it,
we actually make the stakes real. And this way, especially by targeting the key stakeholder, you help yourself by defining the direction that aligns with the main quote-unquote stakeholder. Almost like you do it in design sprints, right? When there is different contributors, different opinions, everybody's sharing their thoughts, directions, points.
And then at some point, there has to be the final decider that says we are going with that direction, right? So that's one of the goals, in my opinion, right now, to identify those key stakeholders who's going to pay for that, essentially. And another point I also wanted to mention is that when it comes to working with ambiguous projects, I can remember that
At some point, I felt like it's similar to learning a new language, especially now when I remember that it was like a very highly technical environment when I didn't understand what am I designing for whom, those terms I didn't know about. It's almost like learning a new language. In the beginning, it feels so overwhelming. You don't understand half of the things, if not more. Even like when you're reading the English text or whatever language you're learning, Spanish text, you read the text and you understand 20-30% of it.
You first cannot make sense of it. You're just feeling frustrated and feeling like you didn't get anything, you leave. At some point, if you persevere, you start making more sense. You start connecting the dots, you arrive to 50% of understanding. Moving forward, if you continue persevering, you arrive to 80%. And then finally, you arrive to the confidence, right? So you build this journey. You're going from understanding nothing to
to some clarity, to reading the text and understanding 100% of it or at least 90% of it, you're finally arriving to the confidence on clarity in what you're doing. So to me, in a way similar to learning a new language, and if you keep this mindset, you'll know that you still arrive to the result. And I shared this story somewhere in a previous podcast episodes. Today, I'm speaking English. 10 years ago, I was sitting in the room and nobody understood what I was saying.
So it takes time, but it's this journey that you go through. If you persevere, if you try to align everyone, if you try to get to the point, you will get there. It's just going to take a little bit of a struggling, I would say. And the key thing, as we are establishing today, I think on this conversation is the alignment, because even if you arrive to the solution and if you're confident in that,
It doesn't mean that everybody else went through the same transformation journey. It doesn't mean that everybody else aligns with the solution. So there's still a lot of work you have to do with making sure everybody sharing the same direction at least. And that's the tricky point always, which I still feel like workshops typically help you with.
Some quick follow-up ideas to what you were saying. You made a lot of interesting points, and I have a lot of emerging ideas from those points. I love the language metaphor. I think the thing I can most closely relate it with is my recent experience. I think I talked about it briefly on the podcast. I took my first snowboarding lesson, and I realized that the experience and the joy and just like being a complete...
failure and something, but holding that hope that someday I will not be a failure if I keep failing just showed me that I haven't learned something new for many years in this very traditional way of learning, like learning a new language or learning a new skill. But I can deeply trace it into the professional experiences I've had where I've been in this beginner mentality even, I don't know, eight years, 10 years into the design role, even when joining Miro, right? I felt like I'm in a completely new space.
apprentice kind of mindset, which is counterintuitive because you feel that as you progress in your career, that should not be there. The ambiguity that you experience when you have clarity and you come in and you tell people you prescribe recipes and you tell them what to do and you show them your process. And in many ways you do that, but in many other ways you're still operating with a lot of unknown and
ambiguity. So going back to your point about workshops, this is a very, let's say, tactical kind of piece of advice or a thing that is very specific to the Miro world, but I feel that I can share it with everyone and I think it's very helpful. Every time we have a conversation in the team, in the triad or with the data science team or even with my researcher when we have a one-on-one conversation, we open a Miro board and then as we discuss, we jot down ideas, we fill it with stickies, the
radical departures from what we're discussing, things that aren't simply documenting the points that are being made. So essentially I think at Miro, every meeting is a workshop. And of course it's because this is what Miro does, right? It's in the DNA of the company. But I think that this is a, let's say recipe,
or a system that could be easily extrapolated to any company and any team, right? So simply have this whiteboard, have this canvas where you put down whatever comes to your mind as you have a conversation. And many people take personal notes, which are on there. I don't know, like I took a lot of notes now on my agenda. But if we're working on a team, we can make it in a space that's
accessible to everyone, visible, transparent, and so on. And in a way engaging, right? And if I jot something down, then I'm going to help you understand what's going on in my mind. And you can then build on top of that and so on. It's like this continuous growth loop. And then on the key stakeholders, another point from my experience is right now I'm trying to build a vision for the AI experience at Miro's.
You can imagine a lot of ambiguity, not just the ambiguity of being in a new role, but also the ambiguity of crafting a vision. What does it even mean? How do you build a design narrative for what's going to go on in five years with this product? And then there's also the important layer of ambiguity that comes with the AI space where nobody knows if GPT will still be around. I mean, GPT will probably still be around, but I don't know. A lot of things will change.
in the landscape and so I can't predict them and nobody can and so how do you design for this kind of unexpected landscape and moving parts and so I'm starting to talk with the internal key stakeholders just to your point and what's very interesting is that
In many ways, they all have different perspectives and different views and different quirks, and there's a lot of differences, but there are so many common themes. I see that once you start talking to people, you're going to notice those themes that are converging, like
The points everyone is making are grounded in some commonalities that you can then treat as, here's where we all seem to be in agreement. And it's an important starting point in lowering the ambiguity, right? So we don't know many things. These are all the things that it seems we don't know or that are contradictory. But we also do know these things. So everybody knows that we want this kind of AI experience or that success looks like this. And so you can start from that and then work on the parts that aren't clear and then
I really loved your point about a $100 exercise. I've been doing it in workshops, and I always thought it's maybe kind of silly, but it's very important at the same time.
I just said that the cure to ambiguity is clarity, but maybe the cure to ambiguity is priority, like just starting somewhere. And I think that this idea of a priority means that if everything is important and if we can do everything, we can do anything, right? So AI is full of potential. We could do whatever. What do we do? The point is to decide what we do first.
And so having priorities, and this can be extrapolated to your work as a designer as well. I think ambiguity stems from this feeling that you don't know where to start from, you don't know what part you're in the process, you don't know what to discuss next, you don't know what to focus on, so you don't have that clarity of having some vision.
It's like the metaphor of driving a car, right? You can only see so far, but you're going to get somewhere, right? You can go for 500 kilometers, but you always see immediate next parts of your journey. So I think that's what helps with ambiguity is figuring out what should I do next and then near. Anyways, one last point I wanted to cover in this conversation. How are we doing with the mental health when we're working in an ambiguous project? What's your point of view, Ioana? How do we stay sane in this environment? Ioana Krivokuća
Mental health. I'm not very good at that, but I'm very passionate about it. So I think a lot about how to balance things and how to set in boundaries. I don't know how to set in boundaries, but I feel that they're important. So I think that in these very ambiguous environments for me personally, what's
seemed to always take a toll is that I'm perpetually disappointing people because of the ambiguity, right? So there's that feeling that I'm not delivering on what's expected of me because nobody understands what's expected of me. So I can always be wrong or not do the things that I'm supposed to do because nobody knows what are the things that I'm supposed to do. So I think that what really helped is to continuously ask people questions
What do you think I should be working on? What do you expect of me? And then, of course, have your own opinion and do whatever you feel is right. But just understanding what are the people's expectations from the design team, from the design work, from what you're delivering. And I think this is like deambiguating your own role and deambiguating the expectations of other people from you helps with your mental health. And also, I feel just sending in time to discuss.
disconnect from the noise. I think that these kinds of environments, startups, scale-ups, companies where things are rapidly moving and there's a lot of pressure, it's just continuous noise, like perpetual conversations that can go on into the night, Slack channel messages that
midnight and so on. So I think what you need to do is setting very clear personal boundaries. And some people are naturally good at that, but others struggle because they want to be there. There's also that fear of missing out, right? So sometimes if an important conversation happens in the weekend, you still want to be there because it's an important conversation. You don't want to miss out, but you should miss out. I mean,
set those boundaries because otherwise you're perpetuating the ambiguity, right? So if there's no structure and there is no system that everybody is respecting and you're not reinforcing it, then you're allowing, you're inviting ambiguity if these conversations continue to happen all over the place, outside working hours, outside the structures that we agree we're putting in place and so on. So just...
reinforce it, respect it for yourself for the sake of your mental health. But it's also going to help everyone if we say, you know what, this is a conversation that should happen in the planning meeting. Let's just have it in the planning meeting, not now and stuff like that and get some rest.
These are such great points. Honestly, I made myself even points for myself. Like, how do I think about it? I really love the point about North Star. That's something we always forget about, right? What is our North Star? We all have to agree on that. And like designing for that North Star, forget about all the constraints. We all have them, right? We have all the timelines. We have all the problems. We have no idea how technology will work. What's the perfect world?
And how do we pave our way towards that? And if you think about that, you know, you shoot the stars and you arrive at some point, right? If you don't shoot the stars, you arrive somewhere very low. But if you shoot the stars, at least you reach towards that. So super important. And I really like how you framed the deambiguating your own role. That's a beautiful point. I haven't thought about it. And that's something I should try doing next time.
And also, I found that it's very useful to, you know, disconnect from the noise. And that's something I can totally relate to right now. Because now as I'm being nine months on the maternity leave, I have been disconnected from the noise. And it's very refreshing because I'm listening to the podcast.
I have a lot of space because I can, you know, go for the walks with my baby every morning and listen to the podcast in the fresh air. Right now it's winter. So this whole context of me being disconnected from Slack noise messages, constant something going on, but me being in my call space in the morning with the podcast in my head and listening to some different perspectives on how people solve problems.
That is so refreshing and that gives you this opportunity of thinking outside the box, of not being enclosed in your own bubble, in everybody's own little worlds and like trying to just go through all this mess. And like you said, adding more ambiguity into your own life.
This is my key takeaway from being on maternity leave, that while you're away, you give yourself this wide space, empty space that we all creative need sometimes. Because if you're constantly being in the hamster wheel, we are not able to come up with a new radical and interesting solution. We're constantly, you know, delivering the expected thing.
I don't know if I articulated it well enough, but I just guarantee you, if you give yourself that empty space, it will be filled in with so many thoughts, new perspective that you didn't think about. But my point on, again, going back to the question, I feel like we go astray, but it's useful going astray type of conversation. But back to this original question of how do we stay sane, what did help me a lot, reflecting back on my past experience, was actually building good relationship with
my design team because essentially you're not the only one if you have design team everybody's probably going through the same mess everybody's going through the same ambiguous situations lack of clarity lots of opinions how do you tackle how do you go how do you navigate what are we building and stuff like that so having design things or some sort of rituals with my design team sharing almost wenting about those arriving to some interesting thoughts and you
insights in those experiences did help me a lot overcoming those. And then I did mention that I have design manager who I didn't have good relationship with, but at the same time, in my past role, we also had two design manager. One was directly in my tribe,
Then another one was from the outside of Tribe, and he was the guy who was basically just helping me to overcome the blockers as a designer. Not specifically in the team, but just as a designer, helping me to grow. And that's the reason I had a really good relationship with Wes. And that guy didn't know what I'm working on. He didn't understand the context of my projects, but he would hear my struggles, and he would, again, be this wide space, empty space, outside perspective that
who'd help me navigate through it and sort of set me up for success. So having somebody who's cheering for you, having some sort of design manager or a mentor, something we keep bringing up here over and over again, somebody who's not necessarily in the trenches with you on the same project, but somebody from the outside world who could help you with your mindset was something that
really relieved me many times and helped me stay focused, not on just building yet another feature that I have no idea about, but seriously focusing on that North Star and understanding what are we trying to build here for the best.
So I think that we have this conversation, which was unsurprisingly full of interesting insights. And I really hope that it helped our listeners. Hopefully somebody who struggles right now is ambiguity to take away a couple of points and now applying them to their work or context. And if that was useful, we would really, really appreciate if you could rate us on the podcast platform of your choice, be it a Spotify or Apple podcast or even Google podcast.
whatever platform you're listening to, we would really appreciate your rating. It helps the podcast to be noticed by more people. And so, yes, we will really appreciate your help. At the same time, if you have any more questions or anything you think we need to talk about or any topics we need to bring up next time, please find the anonymous show notes link. It's the form where you can fill in your topic, your question, or something you think we should talk about.
With that being said, thank you so much, everybody who has listened to us today. We are hoping you're having a great day or night, and we are looking forward to see you in the next episodes. Thank you so much. And I hope this was actionable enough. Yes. Goodbye, everyone. Bye. Bye-bye. Bye.