Episode 26: Bridging Tech and Design with Yi Xin Ang
53:33 Share

Hi everyone, I'm Dalen, founder and design educator at Curious Core.

Welcome to our Working in UX Design podcast series where we interview a UX design leader in the industry on their experience in this emerging field. We've had UX professionals from Grab, AirAsia, Google and more join us previously and we're bringing you more exciting interviews this year. Stay tuned for this week's interview with our special guest who is working in UX design.

So good evening everyone, welcome to another session of Working in UX Design. Today we have a special guest Yi Xin with us this evening and she is going to be sharing more about her career journey becoming a senior product designer, most recently with Stripe.

So she has been in the UX and UI field for over 13 years, solving user problems, both on the government side as well as on the commercial side. So she's a very, very experienced person and we'll be hearing more from her. Additionally, she also has experience

in software engineering and front-end development. That has also helped her become a better designer and a more competent, I would say UX engineer. So some of her projects you might have experienced includes her working for GovTech and Open Government Products in Singapore, such as Parking.sg, Redeem.sg,

and the CDC voucher schemes, if you've been using the CDC to redeem vouchers, that's also part of her work.

So today we'll be covering more on her work in government, in commercial, her career journey from being a game artist to a product designer. And she's also affected by the recent tech layoffs. So that's something we'll talk about as well. But in any case, welcome to the show, Yixin. Thanks for having me, Daylon. Thanks for inviting me. This is my first time doing a podcast, so I'm super excited and live streamed.

Yeah, that's awesome. I'm really glad to have you here this evening. And we have with us a very, very international crowd, including people from Singapore and the rest of the world this time. So maybe we can start off since our theme tonight is about bridging tech and design.

Maybe you can start off by having you share with me a little bit more, like, why did you pick up coding? I think I have to start, like, way back. As a child, I've always been interested in making stuff. Then, like, the avenue for doing that is maybe playing Lego or, like, doing art itself. So my background was I studied art in school and then art animation. Then my first five years of my career was making games. And then I realized that, like...

I was inclined to the more utilitarian side of things. How can I bring everything together? How to make it interactive? How to make it intuitive versus like making it for entertainment sake, for storytelling, character development, things like that. So like I wanted to create stuff that like help

people do their work or accomplish their tasks without even them knowing. So like, I really enjoy those kind of interfaces that does it with a lot of like great feedback, but the user don't even realize that they completed their task. So like,

In order to do that, a lot of times when I design, you have research and mock-ups will always just remain in your design file if they don't get implemented by the engineers. And it's really a challenge to like, oh, I don't, if they say, the engineers say, no, it can't be done or like it's done this way because then they will start rambling on the technical stuff that I don't understand. Then it's hard to arrive at the point where, okay, can we find a

good outcome where we can still achieve what the user needs and yet it's implementable it's feasible so like because of this challenge trying to translate this vision into a build that people can use and enjoy using then like I started dabbling in code and then like from design to code itself it's a lot

it's very challenging because like, oh, and then people will tell you, oh, you start HTML, CSS, but those are not real code. And you get confused by JavaScript and you bounce here and you bounce there. Like it's really hard to follow. So the turning point I think was I decided to go for a three month bootcamp with general assembly. And then that's where like, I really appreciate the community like,

all around the learning curve. Everyone is around the same. So you can learn from them, learn with them. You have the same question and then you tackle it together. So that was the turning point. Then after that, that was about three years plus ago. And then after that, it became easier to do tutorials on my own, to just experiment different type of React or front-end, all the different libraries.

much easier after that. The one thing to help translate this vision and I often see like designers that I look up to, those that can create very detailed or like very with animation or very clear database, they tend to be able to code. So I wanted to be like them then that's why I started doing code.

Well, thank you for sharing and what a journey that has been being able to do so many of these things and also pursue your passion on the side. Out of curiosity, do you actually pay for the course yourself or did you get a company to sponsor you to learn code? It's part of the subsidy where the government will help subsidize, but I managed to convince GovTech to...

because I'm an employee and then they say government is not entitled to this subsidy. I'm still an employee then. And so like I managed to convince GovTech to pay the full sum, but then I end up like, like,

paying back in terms of a year bond. Yeah, I think we can definitely learn a few things on how do you convince your stakeholders to sponsor your course. If you would like to elaborate on that, like how do you persuade them that this is actually relevant to your job back then at GovTech where you were only a UX designer?

I think the environment itself was also very encouraging to people to like want to do cross-disciplinary stuff in order to gain empathy. And like, for example, product managers are also encouraged to go learn code. And then all of us are supposed to take like Harvard CS50 to get like amount of understanding of tech so that we are able to collaborate much better. So I think there is already the environment, the motivation,

motivation and then it's more of like in terms of time, how can I allocate like three months full time and go away, like leaving my project teams behind and do that. So that was more of a challenge, like really have to quickly do up. I had a couple of interns who helped me out. I hand over the project and then just check in regularly. Other than that, like the three months was super busy trying to learn new stuff.

That's really great. And I'm glad you learned CS50 from Harvard Business School, which is a free course. I definitely recommend it to everyone. I didn't manage to finish it myself, but super enlightening just going through a few lessons on that. Just if you are working with engineers, that is the course to learn because that really helps you to understand how they think. That's amazing that you did that. How does knowing code

help you become a better designer? My first few projects was pretty data heavy. So I was working on my first project in the government was working with data scientists. And then we were trying to like use EasyLink data, the tap in and the tap outs to see like where to run mini buses. So like the data part of stuff and then they start talking about bus routing, the algorithms. And then like, it's all very exciting. It felt like building SimCity. But then I couldn't really

design effectively if I don't understand how it works. The idea was to build a tool for our civil servants to be able to plan these routes or like where to put lifts or where to put your traffic light that helps the old people. All these tech terms became like black boxes. What is backend? What is API? What is latency? And then like, it's just really hard to be able to design effectively if I didn't know that. So we lie a lot.

on like keep clarifying. And like I said earlier, like there's always this gap and then what I design is not really effective and then don't get translated. So like you, a lot of wasted effort in that sense. So that's how it got me started. And then after that, I had more data platforms and then understanding how, how to make internal government share more data and then like permissions, authorization, things like that. Like,

became very heavy. So having that understanding of how tech works can help you design this kind of tech heavy products. That's one. The other one is when you start discussing, you are able to participate in more of the product, give input from the product perspective and as well as like, okay, I think the user won't understand all these tech terms. You become the bridge as well. Engineers, they are super smart. They want their code to work, but

Like when it comes to how exactly doing the UI, if you can't explain it to them, then they also can't do a good job. So like there's a bit of convincing. So if you use their language, you gain the empathy, use their language, it will be a much smoother journey.

The other thing I can think of is earlier on, if you are doing like research or discovery with your PM and the engineers are not involved and you go to your stakeholders and they ask you, oh, is this doable? Is this feasible? And then if you do not understand how it works, it's very hard to answer that question or like how to come up with ideas in a way that can satisfy to solve that problem. And yet the team is able to implement it.

I really like some of your points over there. And I think it started with a very, I would say a frustration, but then it ended up being like something that you really like and that you enjoy. And I think this is really interesting that you also have your side hustles and the fun coding projects that you did

Maybe you can talk a little bit about some of these like experiments that you did, like Color Husband, you know, Lost for Words or Redeem Admin in React. What made you kind of like want to do some of these projects?

So like for example the redeem admin in react I was working with the intern was helping me out in for building the admin and then the intern is also new in front end and so like they couldn't do the css they understand like how the data the api all those stuff they understood but then when it comes to like the actual like elements try and make it fall in a table this is the layout and then like it just didn't fall into place and then for me was

Can I try and learn React and then support them in that way so that at least we have something that is usable for the user? So like I did this, I can do the responsive stuff, the CSS stuff, and then they can do the functional side of things. And then we just try and find a way to like cobble this thing together. Yeah. And then LostForwards was something I did in GA. It was just a game. Like it was our first project because we just learned JavaScript, vanilla JavaScript. Yeah.

And yeah, it was quite fun building that. Then Color Husband is my latest experiment. I've always felt like color choosing is relying on some external palette and then you generate and then you don't really know what all the different selection means. And then there's a lot of numbers. I can't really choose. There's a lot of... Then after that, you guesstimate in Figma where to choose, not in relation to the rest of the shades. So I wanted something that can...

choose in relation to like step 100, 200. They are all like follow some sort of a curve or need more contrast, things like that. This is something you can just experiment. And once again, her website is rtlope.com. Actually, someone was just asking the audience, why do you call your website RTLope?

Initially, the idea was I like antelope because I think they're very elegant and then they can jump very high. And it's just an aspiration thing. I wanted my designs to be nice and elegant and works well and effective. Instead of calling it antelope, you call it artilope. Like an art background, like...

like for my art beginnings but I'm also not very sure I thought about like changing names as well like something more direct just like ayx.com I tried to buy easing.com couldn't find couldn't buy it someone bought it well you're you're settled with it I mean most people most portfolio websites I've seen is usually the name of the designer yeah but yours is quite unique and

and maybe even like a memorable right because it's not a very common name thanks for sharing the context and also some of your experiments that you have done when you were applying for a company like strike did these like these skills that these kind of experiments play a part in helping you secure a job in one of the top silicon valley companies in the world

I think the portfolio, being able to have control over my portfolio, how I want it, how I want the interactions to happen, the way I layout it, if I click this, part of the website comes out. If you rely on some external tools, sometimes you can't get it the way you want it if you don't have that understanding of code.

I think it played a part, but like, did I use any of those skills within the work itself at Stripe? No. At Stripe, everyone is very specialized. So like there are people who really specialize in making the Stripe website look very cool and like everything move and there's animation, like very specialized. They are in the core platform teams in the US. And then my role at Stripe was more of like specifically how can I make

disputes less frustrating, make refunds less frustrating. So most of my time, it's really spent on leveraging on the design system that already exists and come up with interfaces and user flow that makes sense to solve those problems. So it's not so much about how can I come up with my own React component and then work.

take the job of engineers, no, I can't do that. They are very strict about who can commit code as well. So I didn't get to do that. I was doing more prototyping design at AWS. I spent one year at AWS. They like the idea of me being able to come up with

code my own stuff, design system and react. But turns out the projects that were allocated to me at that point in time was a lot more early in the development phase. It was a lot of discovery, a lot of trying to understand the problem with the stakeholders.

So I end up doing more like research, more user interviews, more storyboarding, workshops. I didn't even really get to do like prototyping in that sense. They liked the idea. They liked that I can do this stuff, but like I didn't get to use it at work.

You know what they call you in the Valley, right? You're known as a unicorn. Not as a startup unicorn, but as like skilled labor kind of like unicorn, right? Someone who can code, someone who can design. That's very, very rare. So I think that's the idea over there. But talking about Amazon, talking about Stripe, I'm sure you heard about the layoffs in the general tech sector. And I also understand Stripe also did a reduction in hate count and you were affected by it. So

So just wanted to understand, you know, from your perspective, you know, how did it felt as someone who is personally affected by all this change in the industry at the moment? At first, it came as a shock, but like, go back, think about it. It's not that shocking because I was supposed to work on like APEC stuff, like work with APEC teams on APEC features. But when I joined, there was Vyok.

de-prioritization of APEC, I was assigned to US teams. So I could have taken that as a sign, but internally, like, during those, like, all hands meeting, there was no hints at all. Like, we were still talking about this big design, which companies, which

our revenue and things like that. So like there was no hint from that angle. And so like I got the news at 11 p.m. Singapore because they announced it US time early in the morning. I got to know about it because my co-worker, my friend, colleague messaged me, you disappeared from Slack.

what happened and and um and then i'm like not sure maybe it's some connection problem tomorrow i'll fix it no you really disappeared so like i went to check my email that's when i saw like oh your role it's being made redundant and this is and they immediately log us out of all the systems or the admin all those stuff i lost all my docs so like the first thing i worry about is like oh my god my figma file can i still get it

Hang on, did you mean they fired you through an email? Yes, there was no like... There's nobody talking to you and say, hey, you know, you've seen you've been made redundant. How does that feel? Like the fact that you didn't even receive any notification from another human being? It was a very remote role because I was working with a US team. So like everything was via all these asynchronous methods anyway, like channels, right?

So it's not surprising that it came via email. And before that, there were a few smaller companies who were already doing layoffs. A bit shocked, but not entirely. More like worried and sad. I just feel you are taking it so well because I recently read an article that the same happened at Google.

and people were making a huge farce over it because it's so dehumanizing, right? Getting fired over email instead of like actually telling you what is happening and even explaining why. Did the email explain why they are making the cut? No, no. It was like just sorry and then it was the CEO. It was the CEO letter that was public so you can like go see it as well. The founder's email. And then I got...

guess that like I was from Amazon before that and Amazon didn't feel like a very, maybe it's not the place to say this, but I didn't feel very valued as a star, as an employee. Like the environment was just like what people talk about in a lot of the emails and a lot of the articles. So I already maybe train up a bit of my expectation at AAPUS.

It almost seems like it's a Silicon Valley thing. But I certainly hope that things are a lot more, a lot better on our side. So let's elaborate on these layoffs because I know you're not the only one affected, right? So there were also friends, there were also colleagues that were affected. Do you have any...

tips or do you have any messages that you want to share? I know you recently rebounded back. You got yourself a new role very, very quickly. So do you have any tips for people who got laid off? How should they rebound? I haven't mentioned to the rest of the people on the call, but I'm going back to open government product in the part of GovTech. And that was where I worked for like six years before I joined AWS. I think I could go back because I really...

Of course, we should never ever burn any bridges. Even if you're already tender, never ever burn bridges. That's one. Those are like great friends. I kept in touch with them all the time. Even after I left, like catch up, like what's happening? Like what are the fun projects you guys are doing? I really miss that place. So it was never like I'm never ever going back. There's a saying in Chinese that says like,

"Hao Ma Bu Chi Hui Tou Cao" which means a good horse never go back to eat the grass that you left. And I thought about that for a very long time, like there's so much opportunities or like I could explore, like just try some startup or like, but I asked myself like the kind of environment and the kind of insights that I got from Big Tech, can I bring it back to OGP? I really enjoyed that place.

So I decided to go back because I still feel strongly about the project is very varied. You keep learning new things anyway. And I kind of need that like tried after AWS, after the layoff. So

It sounds like you really, really feel like you belong. And also for context, for our foreign friends over here who are listening in, OGP is part of the Prime Minister's office, am I correct? Yes. Yes, so it actually reports directly to the Prime Minister's office and SOCOT is also one of the departments

departments that create very game-changing type of projects within the government tech sector so apparently i hear i don't know whether this is true i hear only the best of the best from guv tech gets to join them it's a really really difficult place to enter and you you have and it's very very competitive internally so knowing that you have rebounded i'm very happy for you uh

But there are also other designers or even like people in the tech sector who are affected by these layoffs. I'm sure you were shocked, right? And as you were processing this, I wonder, do you have any strategies, any tips for them? If they're still kind of like

to walk out of this phase, right? Where they're affected by the tech layoffs. I think I was lucky in that sense. Like, I got my portfolio at a state where like, no matter, like, even if I never update my, haven't updated my AWS and Stripe latest work, I still have something to show, like my previous work. So like, try and get

get to a state where at the very least you have something to show something that's live that people can access without you like needing to share needing to panic and do something about it I still panic because I needed to like I think it's a normal designer thing oh no I need to update my case study and it's so much work and like update presentation so much work and so like trying to get to that state

It is very tough, but it is very worth doing because once you have that, you have a place online that people can just go and see. And once you start networking on LinkedIn, like people always say like go LinkedIn network and that's what I did. I like post about my layoff and then my email is inside the Stripe layoff list. So people start like

"Oh, if they need someone like a designer, they found my website." And then I started making a lot of new connections via that route.

So I met a lot of startups, met a lot of new people, even like they learn, that's how we met as well. Like, yeah. So like have that presence online to show that you are able to do your work on its own without you needing to like keep explaining. I really like that advice. And it is true. I reach out to you first on LinkedIn when I saw the strike layoff, I was like looking through the list and I was like, Oh, product designer, let me go and connect with Yixin and see what's going on. Cause we're always looking for instructors. So yeah,

What you have suggested is a good strategy because I think most people would choose to just be more introverted after the day off. They'll be very harsh about it. In fact, I have a friend who I used to work with and she was very harsh about it. I didn't even know she was laid off until like when I was talking to her and catching up with her. So she didn't actually share that she was affected by the tech layoff and all that. So you went the opposite direction. You shared about it.

And I think a lot of people could empathize with your situation as well. And as a result of you putting yourself out there, you actually got a lot more opportunities. So that is great. Someone in the audience asked, "OGP feels like a very difficult place to enter. Is it very competitive within OGP itself?"

I grew up with the team. I was the first design hire on that team. When I joined, it was still part of IDA. And then through a series of expansion and reorg and stuff like that, I was in OGP. When I left, it's about 50 people, six designers at that point in time. I feel like if I wanted to get into OGP, maybe...

a few years after that, I wouldn't be able to get in. I always feel like, oh my God, there are all these people who just applied. Their portfolio is much better than mine. Then it becomes like this motivation as well. The imposter syndrome is super strong. So over time, I think the team also

did better projects over time and then we start to attract better people and then you do feel the need to like keep upgrading your skills if not if not like why are you hired in the first place so I think that was also one of the reasons why I left I was like so scared that I wouldn't my skills wouldn't apply outside I was six years in government and then I just needed to test myself and

And you did, you made it to Amazon, one of the fang companies, one of the top tech companies in the world. And then subsequently Stripe, which is a unicorn in its own right and providing financial infrastructure for all transactions on the internet. Now that you've been on both sides of the pond, you've been working on the government side,

working on the commercial side um would you like to briefly explain what's the difference between working on with the government versus working for commercial businesses at ogp the teams are really lean uh maybe one of the project is one designer 1pm and then like three to four engineers maybe some of the teams are bigger now but like generally still under 10 so

it's very easy to say, let's get together, discuss something, prototype something, and the communication overhead is not super high. Like you are just, okay, today we change direction, today we try something else. So like a lot of autonomy and ownership, but we work with external, like other government agency and we get a varied spectrum on a like,

health, transport, different kinds of projects. In that sense, then you won't get so much structure, you won't get so much like, if you are trying to look for, oh, what's the best way of doing something? What is the right way of doing something? Is there tools and everything set up properly for you to do A/B testing, this, this, this, all the processes? It's not there. So it's very dependent on like you as a person who drive all this initiative.

And then at Stripe, it's a lot more compartmentalized. So like, okay, you're part of this build. And then you see the whole like UI, the dashboard Stripe, right? So if I do this part, then I want to change the navigation. Then I need to start talking to the people on the NAV team. I need to start talking about the different teams who are in charge of all this. And the teams, you don't even know who they are.

But I get a lot more support in terms of like, okay, I don't need to worry about my English. I have content writer to ask for help. And if I want like domain knowledge, legal compliance, I also need to like start connecting. So like a lot more people to talk to, but also means like,

Maybe you spend one whole month just trying to come up with statuses and it needs to get approved. There's a lot more approvals. And because financial services is also regulated, highly regulated. Yeah. So that was Stripe. And then AWS, I think it's also the part of the team that I'm at. I was doing consulting.

with helping our enterprise customer before they move to cloud, how can we prototype something to solve the problems that they have? So a lot of the culture of each of the team is dependent on the client that we are servicing. So like if they have poor data performance

poor data quality or like there's too many stakeholders, they don't know who is doing what, then we will have to do it, go with them, try and navigate all this bureaucracy. In itself, AWS just leave it to the team to try and solve all these problems. So you feel a lot like freelancer, but with a lot of like security concerns and constraints.

Thank you for sharing the structure and how you all work. And it's very, very interesting to know of this. Sounds like OGP needs more help. So when you're in and if people want to join, I think they should definitely reach out to you. It's interesting that you spoke about how they function. And I think it's also quite dependent on so-called the business unit and where the business is at, depending on which organization it is. So AWS Enterprise Solutions is more consulting oriented.

Stripe builds products, right? So you're working on a global product. So it's quite different as well. One difference I can identify is that definitely from the government side, you're working on a more local user base, local context. Whereas working with AWS or with Stripe, you'll be working on more like a global kind of like user base and different contexts itself. Do you see any other differences like...

If a designer wants to design for commercial versus designing for government, are there any other things that he or she should look out for?

I think the way to think about it is for government, it also depends on like, are you trying to make something for the citizen or is that tool for public servants? So then the tech savviness is actually different. At the government, there is also the need for non-tech solution. Like what if the person doesn't have a phone? What if the person doesn't have Wi-Fi, no data? Then you need to have four bags for paper like

when it comes to vouchers. And then you need to come up with how can I work with the local communities to streamline their non-tech processes. But if it's for tools, then it's a lot more like B2P type of application, like SaaS solution type of way of attacking something. Then for Stripe, it's

like for business owners as well as developers. So there is already a base level for tech savviness, but there is a lot more to explain in terms of financial understanding. So like in that sense, you have to really understand how it works from a business logic point of view. Yeah.

Same as AWS because we are building for enterprises. So the solution is like, I was working a lot on Australia projects and Australia, a lot of them are about resource, oil and gas, energy. And so very remote, what if there's no internet? There is still this kind of problems.

Then in terms of impact, it's also measured quite differently. So like impact or metrics or usage. So for example, for government staff, you want them to go through something as fast as possible so that it's not like our commercial or like consumer type of product like e-commerce or social media. You want them to stay on the platform as much as possible.

So how can we make streamline all this workflow so fast that they can just finish their thing and then not come back and reduce the overhead in terms of support or more self-service, clearer communication. Yeah, so it's different in that sense compared to B2C.

What I learned and hear from what you shared is at the end of the day,

As UX designers, we represent the voice of the customer. So it's still primarily the customer, the user that we should place our focus on. I'm wondering, I mean, you're working from APAC on a global product like Stripe or you're working from Singapore for Australia team. Were there any opportunities for you to learn more about your users? For example, did they fly you to the US or fly you to Australia just to kind of do immersions and stuff like that?

So for the Australia projects, we are like about three to four hours behind. So I couldn't, that point in time was still like COVID, a lot of COVID travel restrictions. But I get to talk with the, for example, people who work in mines.

So like schedule time, but it's very hard to imagine the type of environment they work in. And so I missed out a lot of like during the user research phase, I missed out a lot of like questions because I didn't know that they are on shift work and then they actually have to fly on small airplane and stay at the mining site for seven days and they miss their families and that kind of context. I didn't have it. I just see them in Zoom and then they are in their meeting room

Maybe they are wearing their like mining suit, like orange suit, but it's a supervisor. So they are talking about stuff and I couldn't ask question that is contextual to the things that I'm going to design. So like after that, then like after effect, oh, oh, actually after doing this, that I found more. After doing this part, I found more. Very hard.

not being able to be down there to observe versus like here I just go down to a coffee shop, we test our vouchers or like go and approach elderly and have them try out our vaccination, like sign up. Like it's very different in that sense. And Stripe, we had to like US time zone. So schedule calls with the US like business owners to talk about how can we improve this

It sounds like very, very different working style, but you still have to work with the constraints, COVID included in this as well. But you made the best use of the situation. And definitely your methods and your tools were a little bit more limited, especially if you're working with a foreign user base and customers. But I'm glad you were able to still do your job and deliver on the design. So let's talk a little bit about your...

career. You mentioned it's about art, right? And you started as a game artist. How did you end up in UX? When I was doing games, I mean tools during that time, this was like 8-9 years ago maybe, like tools during that time, I was still using Photoshop, a lot of, it takes longer to develop something. And I was super interested in the UI part of things and I would always volunteer myself to build a website. Like I was very interested in interactivity, but

Like I wasn't so sure about my skills to draw a cute character, to draw an environment, to tell a story. Like I wasn't very interested in those parts. I was more interested in the UI, the feedback, the interactivity of things.

And for games, it's a lot about engaging people, entertaining people. And I didn't feel like I'm fun enough to do those things. So I decided that maybe I should try out the more serious stuff, like the solving business problems or just try it out. And then I started...

that was during the time when banks also started to be more user-centered and then the more I see like oh they are trying to make banking easier for people so I was very inspired by those things and I thought like oh government was super hard to understand I must solve it

And the government websites were very clunky. During that time, I think they were also hiring their first designer, so they don't really know what they want. And I kind of like could do graphics. And so we found a match.

It's interesting you mentioned that because I studied game design as well back in Polytechnic and you are right to also share that it's a very different thing to optimize for, right? You're optimizing for people to stay in a game, to get addicted to it, to be engaged.

Whereas like some of the products you design, for example, the vouchers for the citizens of Singapore that the government has given away, you just want people to redeem the vouchers as quickly as possible. And it's not about making it fun. It's not about making it cute or anything like that. So yeah, it's nice that you brought up that distinction. And I think

Career is also a process where you discover what you like along the way, right? You won't get it right the first time around. Rarely anyone ever does. And it's like this journey where you just kind of like pivot and transform yourself. Super glad to hear that you were given the opportunity to kind of do that pivot on GovTech. I believe that was a... You were quite early in joining GovTech at that point in time, right? There wasn't even like the GDS...

team yet. Every team was very tiny and still trying to figure out how to do a government project not in three years. The thing about working with big enterprises or the thing about working with government sometimes it's that long timeline to see your product out there.

I think we have another question from the audience. After you finished your coding course, how did you continue to polish your coding skill as a product designer? Just now I mentioned I was working with intern and then like there was no one doing the UI, the front-end side of things. So I just try it out. Then always volunteering myself for static site, like those that don't need too much data. So you get used to like setting up a project for CSS, for...

at the very least I can do HTML and all those things like just keep practicing then I tell the engineer you just pick whatever is useful to you like I don't mind you delete the code it's okay and for me I also start to get used to the idea of like maybe I can design in code because if things I design just

stays in Figma. Of course, Figma and all these design software super useful, come up with different variation, very helpful. But like after some time, if people don't refer to it, it also become this like still and if they don't implement, it just stays there. So very wasted. So like how can I help bridge all those gaps? So a little bit of tiny opportunities to try things out and

And I think at OGP, we also have this thing called Hackathon. So during Hackathon, you can work on your own project or switch roles, try something out. So also take the opportunity to do more code. After AWS, when I was very involved in all the research, I was...

dying to work on design and building so when after the the Australia time zone stuff I'll practice my design and code stuff like not easy but I think have to force have to find pockets of time to do those things a lot to learn like even for design like so much to learn how do you run a workshop how do you do research how to like

the amount of things you need to learn is just crazy. I mean, that makes you kind of like a Swiss army knife designer. You can code, you can design, you can run workshops, you can convince stakeholders. Makes you more versatile, makes you more hireable as well. And talking about hireable, someone is very interested to join GovTech.

but only has a diploma. So even though they mentioned that they both hire for university degrees and diploma, is it true that they're only looking for university graduates? Or have you seen diploma graduates in GovTech as well?

I think so. So we have even hired like high school students for internship. It's a lot about the portfolio actually, like you can demonstrate your skill to work on something. Like it's really about the skills and the portfolio. I don't know, like Gartek is very big as well. So it really depends on which push, like a lot of the teams also manage their own hiring process. So you have to see which teams, but

try and enter with a good demonstration of your skills through portfolio. Like, even if you're a programmer, like, you have coding projects, use that as a way to enter, like,

product manager, how have you worked on stuff, how have you done your school project, how have you taken initiative, like demonstrate true doing, true showcasing your work. I don't think the paper part of things, they will check to make sure that you're not lying, background checks. But I think I do see like people from police getting, entering GovTech, so I'm not sure.

I think it may be just timing sometimes and it may also just be the person who look at your CV. Sometimes it's not the actual hiring manager. It might be HR who decided, hey, actually we got a lot of degree graduates. Let's filter out all the poly grads. It might be just because of that. So I think usually as hiring managers, we do look at the portfolio more than

the specific qualification, which is a follow on to another question, you know, like in this day and age, is it necessary to have a master's in computer science or master's in human computer interaction just to be better? My take on this is actually if you've got the time and money, actually just like, okay, take a break from work, find some project that interests you, try and learn new ways of doing things. I think that could be more helpful because

if you look at how causes are designed or causes are especially long causes that takes years maybe like if it's something very that relies on like years of years of knowledge passed down from our ancestors then it makes sense

But like for technology, it keeps changing. Like this week is AI, next week is Metaverse. Like nobody is going to come up with causes so fast that changes. Like tomorrow is blockchain. Like you just cannot be so fast. So like maybe once you hear all this new stuff and you just want to try out, just start a new project, try and find time and experiment with it. You might get more things out of like waiting for a call, spending huge amount of money. I'm not trying to diss causes, but like I feel like it's more efficient use of time and money.

I think definitely Yixing, what really appeared to me is that you're a builder at heart.

If you don't build things, you can't sit still. That has definitely come out very strongly in this particular interview. So a lot of companies are hiring backend teams in India or China. Do you think all designers should learn how to code just to be competitive? I think the answer is

it depends on the type of things you want to design and it depends on the environment you are in as well like is there a chance to do that like so if you are in a bigger company and it's very compartmentalized then probably like the other complementary skills to do is like research and writing or even running workshops like there's so much to learn illustration branding even people skills communication

leadership skills, there's just too much, way too much to learn. So it let your curiosity and your like, like gut

to guide you, then that's more sustainable. Because like, if you jump around here and there, it's also really hard to go in deeper. That's my sense. But I do understand that decision fatigue and that overwhelming like imposter syndrome idea. I don't know how to run a workshop. What's the difference between this design, this tool and that tool and this framework and that framework? There's just too much to learn.

I mean that's such a good piece of advice, especially considering like how fast tech moves and the fact that you know, like even in Singapore we're also very competitive like oh yeah no night now Ai is the new thing right like oh everyone should is trying to learn.

more about AI or trying to learn how to work with chat GPT is quite inevitable but I think you made a point it's about also managing that internal conversation within yourself on imposter syndrome and also feeling like hey you know what am I strong at what am I interested in and developing that as you go along so

Someone is asking a more technical question. So you work a lot with engineers and on the team that we're talking about the bridging between tech and design, do you have any tips or frameworks or processes for handing off your designs to developers?

So in order to, like there's many ways to translate a vision to a build. And like my go-to way, the designer learning how to code, that one is just one of the ways. There are many, many other ways. For example, how do you advocate, how do you explain your design decisions in a way that like people understand and annotate your files or like have good documentation. So I think some of the tricks,

that worked was doing walkthroughs with my engineers. This is how you use Figma and then help them set up because sometimes it's just like panel toggling or this is where you find this particular style or you can just copy the whole style and paste to them. This is 100, 200, 300, 400, just paste to them and they don't need to come into the file and look for it. Like those are already super helpful. And then other things like

like, okay, keep telling them it's okay if you think it doesn't work, please come back to me, we can discuss this, we can find a good way to reconcile it. If you really want some control, maybe you learn HTML, CSS, then you can go in and tweak the words, the copywriting, you don't need to wait for a pull request or like a Jira task. And those are really already like save a lot of time in communication.

Maybe let me just summarize the three things you said first. So you most recently said, hey, learn a little bit of coding, including CSS and HTML, which is not too hard to pick up. At the same time, being able to... True, like do a walkthrough of Figma. Yeah, do a walkthrough for them. Or like send them some of the like predefined styles so that they don't have to look for it. Yeah, I think the second one you were saying is about... Ask them to like have, like open up the channels to talk like,

Yes, so like communicating, right? Really, really great three tips. Any other tips for developer handoffs? I often hear like, hey, you know, when you do handoffs, you should have very detailed documentation. Is that your style or you like? My file is messy. I only do the parts where it needs explaining. I try to put together... I think the other thing that is helpful is like, if there is no time for meeting, recording a video...

and do a walkthrough of your prototype is super helpful as well. Like, "Oh, this is what happens when I click and then this is why I designed it this way." Like a five-minute video that they can go and just go through and then come back to me if you have any questions we can discuss further. Or send this video before a check-in.

And so they can just watch it and try and think of questions that they have before that meeting. Those are really good advice. And I think it depends on your style as a person as well. I know some designers are very detail-oriented and then they document everything. I think at the end of the day, it's about communication, right? You're working in a team, you're building a product together. Does the person understand what you're trying to communicate? And if they do, then of course, there's less...

mistakes that's less breakdown. It sounds like you ask your engineers to learn a bit more about Figma, but you also take the effort to learn a bit of their language. So it sounds like it kind of like bridges things a lot better. Do you have any tips working with engineers in general? Because, you know, some people might feel like they are a little bit different.

from designers because we look at things quite differently. I think just as there are many types of designers and designers with many different types of skills, there are many types of engineers with very different types of skills. So you can have an engineer who is super good at data, super good at backend, but can't do CSS for hell. And same with designers. There are those that are very good at thinking system or doing UI, but then don't talk to people. There is just a spectrum. Just everyone. So I feel like

teams when it comes to team a lot of time it's about trying to find that like what everyone is good at and try and leverage that as much as possible I also have instances where I work with engineers that initially I really cannot understand and like

They say cannot. No matter what designs I put, like, cannot. Like, why cannot? That, like, fucks out the motivation to learn code as well. But it's also trying to understand why cannot. I keep asking questions, like, try and break that ice, try and work with... Hey, can you help me sell an environment? I try to change something, like, ask them for help to help you change some of the things. Then they see you breaking their stuff, they are also super frustrated. So, like, they will come back.

Really, really good advice. But also what you mentioned is something so common, right? Like as a designer, you say, hey, you want to do this?

Generally, when I work with engineers, they are very, very efficient. They say, hey, if it's not broken, why go and fix it? So that's kind of their mentality. And then some of them wouldn't want to try extra things or do more work because that really doesn't serve them well as well. It takes time to build a relationship. And after that, things get easier over time once you have that trust established. Do you hang out with them regularly?

after work? I mean, does that help? I think I've managed to form a great relationship with my PMs and engineers because knowing a bit of what the other discipline and having that background helped engineering so they understand frustration centering a div is super difficult and it's

And if you can solve some of their problems, they are super happy with you. Like, they don't need to care about CSS anymore. Some of them love that. But some of them, I do meet engineers who care a lot about users. So they will go down to user testing with me. So they are a gem. You'll find all sorts of people, like different types of people. Then you just have to find ways to like, as a human being, how can you communicate better with these different types of people? It's got nothing to do with their like role or whatever. It's just,

more like communication style. Soft skills are just as important as hard skills. Don't just go and start learning about AI, but also work on your soft skills because your soft skills are the ones that are going to carry you forward, especially as you get into leadership positions as well.

Certainly, that's something very helpful. I wonder if you have any general words of advice for junior designers or people trying to get into this tech industry. I think one of the things that I would have told myself when I was doing this earlier on was that

there is a lot of these frameworks, a lot of these tools that you get overwhelmed by and you don't know why and then you're just like, I need to use it in my project or like, I need to show that I can use it. But it's understanding the why you're using it and go back to first principles that is quite important. Like,

for example, different types of like design sprints or design thinking or what's the difference between IDEO and like Stanford ones or like the five-day Google one, Google Ventures one, what's all the difference and how can I use it in my work? And if you go down to Google,

why is there a workshop in the first place? What are you trying to get out of a workshop? A workshop, you can have different types of activities and the activities can, in a way, collect information from your participants or like you want them to choose

to work on something or you want them to create and generate ideas and you want them to commit to an action plan like then you design around and then it doesn't matter what kind of tools you are using same thing for personas or like customer journey map or like i must use lean canvas i must use this canvas that canvas like really ask why you are using it is it i'm trying to communicate my findings in a way that like my stakeholders can understand then it might not

in a format of a persona. It can be something else or like yeah just laying them the information out in a digestible manner is already a good thing. So it's not about like how to the T you're gonna fit all these different tools. It's very overwhelming and never ending because everyone will just keep coming. It's a marketing thing like if they market it properly then you will be aware of it then people find this way more useful but

So there's a lot of all these things. How can you try and find what is useful out of them and then try and be sure of yourself in that sense? As they say, I mean, there's this thing they call the shiny object syndrome, right? Whatever is like, there's shiny, it's new, let's use it, you know? That's definitely something that a lot of people get distracted by, but

So little people, so few people actually go back to the fundamentals and ask the why, which I think this is really, really important as a designer, returning back to first principles and really challenging everyone to stay grounded, which I think is the value of doing evidence-based design in general.

So with that, super great advice. And I think the audience loved what you've been sharing here tonight, Yixin. Wish you all the best in your new role as you're starting your new role in March. And what is the best way for people to connect with you? Is it LinkedIn? Yeah, so I'm on LinkedIn. You can just look for me or you can just ping me via email. My email address is on my website. So yeah, I will try my best to...

to reply. I think in general, Isin left a final comment like she has to credit a workshopper book that she saw and it

It mentioned a four-step process whereby you collect, you choose, you create, and you commit to the process. So I'm sure there are a lot of different processes and a lot of different types of outputs, maybe something worth discussing as an event or as a sharing in future. But with

What you shared tonight, bridging technology and design. Thank you so much for sharing your perspective as well as bridging our understanding between building for government versus building for commercial applications and working for some of the top companies in Silicon Valley. Definitely wish you all the best in your career. If you like to check out more of E-SYNC's work, check out www.rtlope.com, which is A-R-T-Y-L-O-P-E.com.

With that, we shall end tonight's session. Thank you, Isin, for joining us. Thanks, Daylan. Thanks, everyone, for joining. I hope you enjoyed this episode. If you did, please let me know what you think. Get in touch with me over email at mail at curiouscore.com. I would love to hear from you

Do also check out our previous interviews and other free resources at curiouscore.com. And until next time, I'll see you on the next episode. Take care and keep leaning into change.