 My name is Ada Koonle, I'm running a race in Brooklyn, New York. So it's a pleasure. Oh, yeah, cool. So it's a pleasure to talk and see you today. Before I start, I know my name is difficult. So I got an outline like that. If you guys want to see with me, just add a Koonle Oduye. So stop that hard. See, yeah, nice. See, everyone got it. Cool. During my day job, I'm a product designer at NASDAQ. We work on web-based platforms for invested relationship professionals. Sounds pretty complex, which it is, but that's that. I'm also one of the co-organizers for the Gotham SAS Meetup. Yeah, I see. And also for SASConf. So before I get into my talk, I want to talk about what I'm not going to talk about, which is if designers should learn how to code. This has been a debate for the past two years. I was hearing a lot about it. But for me, I think that's a place for both coding and non-coding designers, especially within our team. We have a 30-person team where some people are focused on the visuals, which is pretty good, because they push the boundaries while they got designers like me that lives in within the boundaries and knows what it's capable of doing or not. What I also would be when I speak about is SAS basics. Hopefully, I'm assuming that everyone knows what are variables, make sense, and so forth. So hopefully, I hope you guys will learn is that how SAS could introduce designers to programming concepts, and also how it can make a better developer and designer. I know for me it's definitely helping out just learning the ways of the web and how it works. And also, it seems kind of odd, but I think learning how to code actually made it better for me to communicate my ideas and be able to collaborate with both designers, developers, and also stakeholders. So let me get into my story real quick. I started out as a traditional print designer. I had no coding experience at all. I think the only class I had was like a dream river, and I hated it. Actually, I think I failed it, but that was it. So I came in to have an internship, my first, after I left school. And I was doing basically promotional items and typical print stuff. So what had happened a couple months down line was I did a couple of mock-ups for a website. My boss was like, hey, do you want to code this site up? And I was like, not really, but I just, I got promoted from intern to actual full-time. And I was like, I guess I got to do it, right? So I did it, and I was like, OK, challenge accepted. So it was actually a OK experience. The good, it was actually functional. You click on links, it actually went to the right pages. And that's about it. Because if you actually look at it, I was very disorganized and redundant with my CSS. My CSS was very wet. Kind of like, what are you saying? Yesterday. Also, it took me a long time. It took me for the first project about six to eight weeks, which at the agency, it's a lot of time and money. It was kind of funny because for that project, the client refused to pay the whole amount. So we had to give a discount for that, which now I'm losing money and I'm taking too much time. So I was like, oh, man, I don't know if I'm up to this. But I was like, it was a great scene, my work coming to life, and it was like, it gave me a good feeling. And I was like, yeah. Yeah, I was doing exactly like that. So it was great for me to see my work coming to life, and I was like, I think I might want to do this for a long haul. So this is where my code addiction started. My code addiction, not code, but code addiction. So we went to the first stage of addiction was experimentation. I started after having at least four or five projects under my belt. It was, I knew the whole process of it. So it was coming to a point where I didn't really need to go to Google or CSS tricks or anything like that to actually figure out what I'm doing. I understand how to make layouts and all this other stuff. But the more I was doing it, the more I was like, I'm getting kind of bored. It was like the same thing over and over again. And I was like, is there a reason why it's boring right now? Like I said, there was a lot of redundancy. Since I was working by myself, I just did whatever I wanted to do. And when the developers actually looked at my code, they were like, what the hell are you doing? And I was like, I don't know. I'm just Googling and stuff and it's making it look good. So my coding buzz started to wear off. And I was like, I need something else. I was like, what's next? So I was like kind of thinking, I was talking to some of the developers. He's like, yeah, you should try JavaScript. I was like, OK. Because HTML CSS was conquered. And I was like, I guess this is the next jug of twice, right? But something happened. We didn't mix at all. I didn't understand. I was like, I was trying to figure it out, but I couldn't figure it out at all. It was kind of like oil and water, or Batman and Joker, or New York or Boston. I know a couple of people from Boston here, so yeah. So there was four main reasons why it didn't actually work. First was understanding the syntax. It was definitely a big learning curve for me, since I was more of a traditional designer. I had no CS background, no coding background. So it was kind of harder for me to understand. Second was definitely a different thinking process. Because if you think about it, you have to account for many situations. Whereas in the CSS, what I was doing before was pretty much upfront. The docs are very heavy. I'll look at the docs, and I'll fall asleep. And I was like, oh, god. And also I tried many educational platforms like Linda, Code Academy, all that stuff. And it didn't stick. It didn't stick, because most of the time they'll teach you the syntax, but not how to think about it. So when I tried to do my own projects, I was stuck. I didn't know where to start. So this made me very frustrated and sad. And I was like, I don't know what else I'm going to do. And it was really interesting, because once I started going to Meetups, just trying to get better and stuff like that, people was like, oh, yeah, you're having trouble with this, is that you should try SAS. I was like, what is this thing called SAS? I was like, and they were talking about it's basically CSS with superpowers. And I was like, whoa, I want some superpowers. I was like, I want to be part of that. So I started, and the most interesting thing about it was that SAS was kind of like a presentation language with basically scripting language capabilities. So with the SAS script, you could do many things that you could do the same thing within JavaScript and any other abjuring language. So the problems to solve, now my code is kind of dry now. I was like, OK, I'm kind of feeling this. I was able to break down my CSS folders, because I used to work with a big, large style that CSS folder where it was trying to find things. It was like a hot mess. I was finding and replacing different stuff, and then it will mess up other stuff. And it made my code more scalable. So this leads you to the next stage, which is basically regular use. I started using it regularly. I was like, any side project I had, I started using SAS. And I was like, yeah, I'm starting to like it. And it came to a point where I just couldn't go back to CSS. Even if I had to produce CSS, I would just go somewhere. I do use a SAS Meister where I could just do my SAS, compile, and then everything's there for me to just copy and paste in. And also, it was so good that it just kind of made me lazy, actually, because it has all these things that make your life easier, such as pattern frameworks like bourbon compass, which is great for vendor prefixes and all that stuff, which you probably don't need anymore. But we have these grid systems, which I used to Susie, and I love it, because it removes. You don't have to actually change classes within the markup to actually change the layout, which was pretty awesome for me. And if you want to check out more, take out Sashay for more sassy stuff. It's like a whole bunch of things out there. But with anything, with great power comes with great responsibilities. That's from Spider-Man, if you don't know. Uncle Ben, my favorite quote. But the thing I was doing there, I was kind of overusing it. Like, I was doing too much with it. I didn't know how to stop, because I was just so hooked. And I was like, I just got to keep on going. So this is the next stage, which is substance abuse, or a SaaS abuse, either way. So the first one was kind of funny, because for me, I thought you want your CSS to appear just like your markup, right? Is that a good idea, right? So you end up with the nesting inception. But this wasn't a good idea. And why it wasn't a good idea? Because your CSS is not componentized right now. And I didn't just go one, two, three, four, five, six level deeps. I went eight levels. Yeah. So basically what I was building, I was building pages instead of actual components. And it came to a point where I had, it was like for my actual personal website. So it was like 14 big pages that was there. So I was thinking about it, I was like, oh, damn. That's a learn, right? And I was like, oh, maybe I should have refactored it. But it was just so much work. And I was like, I don't have time for this. I was like, it was so much work. And I was like, you know what? This gives me another reason to actually build my website again. So that's why I did. The second overdose episode was, I call it the extend burgers. This is where your extends kind of look like this. I mean, you're selective is this extend after extend after extend after extend. Interesting enough, I thought extends is actually the faster way of doing it, but it's not. There's a great article from Shea from Belly talking about mixins versus extends and extends. I mean, mixins won by a mile because they were actually simple to use, faster to load. And then they were also creating the smallest file size. And also, it's also easier to debug with mixins than actual extends that I found. And also, I was actually using a lot of important, which is not a good thing, so don't fire me. The other thing was the overusing sass itself. I think sometimes when you're writing sass, do you forget that it's CSS and not JavaScript? So I don't know if you can see that. But when it starts looking like this, and especially for someone that doesn't know sass, you're going to look and it's like, wait, am I in the right file? Even to this day, I don't know what this does, but it does whatever I want to do, so whatever. So those are the three problems. So after I kind of figured out my overdoses, and I was like, all right, I know what to do now. Stage four, it was a full addiction now. It was a full addiction right now, because I was using so much that I couldn't go back. And every time I see a design, I was like, hmm, I wonder how to do that in sass, or how to make any way where it's just scalable and you don't have to write that much code. And I was like, I need to do it all the time. I was like, I was feeling for it. Yeah, I was like. So what happens if you just have sass in your head and your blood and it's like, I need something else? Sass, it brings me to the first benefit, which is basically how sass introduced program concepts to designers. Like I said before, I had trouble learning JavaScript, but once I started to get familiar with sass, it was just kind of easy, because it has the same concepts where it has variables. Mine is different syntax, but it's the same idea. We have arrays, which are lists in sass. We have objects, which is maps in sass. We have functions, and we have loops. So now I had a good understanding of how to make my work with JavaScript now. So I started experimenting with jQuery first, and then I started getting my feet wet with Azure JavaScript, which is more of like conditional and programming and all this other stuff. And with these two tools, it was very easy to actually design and implement your designs very quickly. At NASDAQ, that's where most of our team does our, most of our designers know how to code with HTML, CSS, and then JavaScript. And we do this thing called rapid prototyping. Rapid prototyping is basically an adjust when you design something in your application, you validate with team of designers, developers, and stakeholders. The process is iterative, you basically do three steps, you basically do three steps, which is prototype, refine, prototype, review, and refine. See with this is that sometimes your designs is not right at the first try. You have to keep on designing and designing and testing it out with your users to see if it works. It's like, if I borrow a pair of jeans, I probably want to try it on before I actually buy them, because if I commit to them and they don't fit, then that's a problem. So that was kind of like the story we were trying to solve. Benefit number three, like I said, it's definitely a great tool for today's designers. Most people believe that designers shouldn't be able to do USAS or JavaScript, but I think it's now more than ever that our job responsibility is it's so much that we need to actually design the actual product, close to the product as much as possible. And we should probably design and test our interactions and why it makes it easier, because now we have to test for different screen size, resolutions, browsers, now we have the eye watch and all those other stuff. So we have so many devices and situations we have to design for. We have to test for the user interaction, which is why most of our team uses JavaScript because it does click events and feedbacks, which you can't do just with CSS. It also comes with things called visual conditionals, which is basically a way to set up conditionals for when different designs activate. Like I said before, it makes the designers focus on interaction over visual design, especially when we work in sprints, you don't really have time to actually focus on how the type looks, how, what color to use, they should be something in place for that. The benefit improves communication and collaboration within your team. So in NASDAQ, we have 30 people in our product design team. We have about six, seven product owners and at least 40 developers. So it's, if we didn't know how to code or do any prototyping, it would be hard to actually communicate our ideas to us. So being that we have all these skills, the benefits to designers is that now we can set up design frameworks, like pattern library and style guide, which basically keeps the design consistent itself. So when you're actually designing, you don't have to actually spend your time thinking about it, you can just reference to the pattern library style guide and that will help you out. And also it benefits the developers too, because now you speak their language, you understand their constraints. It's less the developers. I know for me, I used to do mockups and then do annotation, which I hated. I was like, I don't want to type words, I just want to code and stuff like that. But this was a good thing just to deliver some actual prototypes to them. And it also gives them freedom to design too, because most developers won't admit, but they kind of like designing too. So you give them the tools, style guide, you give them a pattern library, sometimes they come back to you and they're like, yo, I got this, what are you thinking about this? I was like, oh, I thought you didn't say you liked the code. Now you know. And they will love you. They'll give you a big kiss like that. Benefits for the stakeholders. I think it's very important to have actual working prototype. And a prototype is different from a static mockup because a prototype actually includes both interaction and it tries to include real data too, which I think is important just for testing on the market, especially for usability testing, which what we do in NASDAQ. And also when you come to a meeting, it's a great presentation tool. So usually you send this out before the actual meeting and what they will do is they will play around with it and then they will have a set of questions when they come to the meeting, which makes the meeting more efficient rather than having a two, three hour meeting. They ask the right questions too. So it's not about how it looks or is that font too big or it needs more splash or whatever like that. It's more about is it answering the right question? It also gives the ability to see any pit holes in the ideas because I know when you're designing it, you're focused on one thing, but you gotta think about it. Whatever you design is a reflection of the whole product itself. So teamwork makes the dream work, it makes you happy. I think I started in NASDAQ and it's kind of funny because even it took me a while just to get used to actually showing unfinished work and that's one of the benefits of actual showing the prototype. It gives them the ability to actually test it out and it's interesting that most, if you include them in the process itself, people will get excited about what they're doing and basically you're all in the same team because I know in some companies where there's definitely beef between the designers, developers and the product owners and but you have to understand that if the product does well, everyone wins. So I'm actually gonna stop kind of short but the takeaways, hopefully you get, is that how SAS introduced programming language to concepts. I think now for me, I don't really consider myself a designer developer, I consider myself a prototyper, which is I think an interesting role. So now I'm more focusing on if what I'm designing makes sense. So I'm able to validate my designs of decisions. Also, it improves collaboration and communication within the team itself, which I think is very important. Working and as they actually told me how like, you have to be patient with everyone because sometimes you can't just do whatever you want, which is probably best. Some resources, definitely check out sasling.com, SAS way, those is great tutorials for basically events, beginners and anyone in between. SAS Mites is a great application where you can actually write your SAS and see how it compiles in TSS, which is a good thing to know about. We have SAS Bites, which is a great podcast where that's on YouTube. And also there's a lot of people in the community like Hampton, Chris Epstein, Claudina, Sam Richard, Scott Kellum, follow them on Twitter. Yeah, thanks for listening. Questions?