One Day Out 2017: "Redesigning the design process" by Josh Brewer

Okay, great. Hey, great. Alright, so we're going to jump straight back into it with Josh Brewer. He's the CEO and co-founder of Abstract, and he's got an amazing talk about redesigning the design process. So please welcome to the stage. Hello, everybody. The glorious props were unintentional. Snowboarding accident. Woohoo! My wife thinks I should cease and desist, but I tell her I've got eight months to recover for the next season. So we're going to go ahead and put this down over here. Alright, how are you guys doing? How are you doing this morning? Woo! Everybody feeling good? Yeah. Alright, I can't see up there, but it looks like there's some happy faces up there. Alright. Alright, we are here to talk a little bit about Abstract. The easiest way for me to begin this is a long time ago in a startup far, far away in a very foreign land called San Francisco. I started a small little incubator called Habitat. This was after I was a kid. I had spent a few years at Twitter helping lead and grow a lot of the design and product work there. And I was looking to do something new. I was looking to bring designers and developers together and give them space and time to focus on problems that were worth solving. I happened to have this wonderful gentleman who I had met several years prior. His name is Kevin Smith. And Kevin was an iOS engineer and all around kind of just very sharp-witted. Kind of just very sharp product guy. And I invited him to come and join me at Habitat. And so we were working on some stuff. And we ended up building this little app called Icons. And it was largely because I was super frustrated with the fact that designing an app icon for your iPhone, there was no easy way to preview multiple versions of it. Unless you opened Xcode and then did a build and dumped it onto your phone and on and on and on. And so I said, Kevin, there's got to be a better way to do this. Why? You know, it's like as a designer, we've got all these little things and we jump through so many hoops. Can't we do something about this? So we built this little app and basically recreated a home screen and allowed you to like sync the assets in there so you could do that. Knew it wasn't, you know, something that was going to probably change the world. But, you know, a couple thousand designers out there said, thank you very much. And that started Kevin and I thinking about like, okay, there's more here. There's more here. There's more problems. There's things that have yet to be solved in the design side of the world. And, you know, I was sitting there in Sketch and drawing out artboards at 1x, 2x, and 3x. And basically just wondering, and this is 2015, so I'm thinking, this is 2015. Why am I doing this? This is insane. We've been doing responsive design on the web for a while. But our drawing tools don't work that way. So often we jump into code and then we have the ability to have these things adapting and growing into their spaces. We're designing for more screens than we've ever designed for before. And I was just super frustrated. And he looked at me and he said, well, your tools suck, man. And I thought to myself, that's not very nice. I mean, I don't make fun of Xcode and I don't make fun of, you know, your tools. And he's like, no, no. Like, I've worked with great designers my whole career. And you guys spend all your time. Spend all of your time pouring out, you know, your thoughts, your creativity, the kind of problems that you're wrestling with. Aesthetic choices. You're inputting data. You're doing all of this work and you're putting it into this black box. And out the other side, all you get is a picture. What do you say to that? You're right. Okay, my tools suck. Right. No, our tools are actually pretty phenomenal. It's a constraint, though, that we have to deal with. And I had been having a conversation with another friend of mine. His name is Frank Camero. And Frank and I had this email that had been going on about how, you know, it was like one thing to have this kind of problem with our drawing tools. But we were seeing this proliferation of prototyping tools at the time. And it was like, man, I'm a huge advocate of prototyping. Built some prototyping stuff in the past. And yet here we are with like this problem. And it's growing. And it's growing. And we have more and more of this. We have more and more things to manage and more and more places to manage it in. And we were talking about there's got to be a way that we can start, like, making sense of this. How do we solve the deeper underlying problem? So we all kind of got together and spent a week just really looking at, like, what's the 10,000-foot view? What is going on? Why are we in this situation in the first place? And we started with this goal of we wanted to bring design and engineering closer together. I've been saying for a long time. I'm a big company who, you know, has spent enough time with me. I'll end up saying design and engineering are two sides of the same coin. They're absolutely connected and dependent on one another in building great products. And so how can we bring them together? And, of course, Kevin being a great engineer with good taste, which, hmm, nothing better than a good engineer with good taste. You know, and Frank and I on the design side but also having enough experience doing front-end work, we thought, okay, we've got to bring these two sides together. But the more we looked at it, the more we realized that, like, design itself and the design teams and all of the great folks that we knew out there, they weren't working well. They, they, we were jumping through hoops all day long. We started interviewing folks. We started talking to people. And every time we sat down with someone, we heard the same thing back. The majority of people's day was spent bouncing back and forth between different tools, talking in different communication channels. And then we would ask them, so when do you do the work? And they would often reply, well, sometimes at the end of the day I can carve out an hour or two. Or sometimes I block my calendar and I totally pretend like, you know, I can't come to meetings. Sometimes I turn off my Internet connection so nobody can bother me and I can actually get shit done. And we started seeing a theme here. We were like, okay, so there's all this work around the work that happens. And it's not true. It's actually hypercritical to the work that we're doing. It's largely around communication, collaboration, and building consensus around the work that we as designers are presenting. So we thought, okay, we've got to do something about this. We want to do something about this. There's clearly an unmet need here. And we've got to figure out how to make that, make that change for our industry. And so this great quote, which is, we can't solve problems by using the same kind of thinking we used when we were working in the industry. I thought this was fantastic because if you looked at where we sat two years ago almost, we were looking at file systems. We're just, you know, design uses these drawing tools. They output these binary files. And we've hacked together all kinds of ways of working. But it meant we needed to fundamentally change our approach. And the more we talked about it, the more we realized that our workarounds, our workarounds are not a workflow. As much as you like to think so, it's not a workflow. It's more like a work... And I don't know if any of you have ever experienced this before. This is like the nice version of this slide. The one I wanted to put up is more, just more terrible. And you wonder why we have problems communicating. What file am I supposed to look at? I'm working with somebody else. Whether it's another designer, an engineer, a stakeholder, client, doesn't matter. They're wondering, where do I go? What am I supposed to look at? And even myself at times. You know, you start riffing off someone else's work and you end up with a new Final-Final-JB with a date appended to it. Not going to lie. File naming conventions is like one of the greatest ninja moves that design has ever mastered. You know, you bake that into folder naming structures. And I'm telling you, it's like you have a database ready to go. No, you don't. Because actually, it turns out, dumb folders are dumb. They don't understand the contents. They don't know what's happening inside of them. They can't make sense of what's changing. They just know that there's stuff inside of them. And at the end of the day, we really came to the great conclusion that binary files are actually the culprit. They are the evil that we must face. And so we thought, okay, we've got to reevaluate this problem. The binary file is a huge problem. We're working on a basic file system that requires us to invent new ways of naming files all the time. We have to also then talk to every other person we're working with and make sure that they also follow this very same convention. And if they don't, then you have to manage that and it cascades on and on. Design is a team sport. There's no question that we've moved out of the era of kind of like a rock star design. Into the era of true teams being critical for the success of any product and any design endeavor. Maintaining and sharing knowledge across functional teams is critical. And it's central to how we're operating. It's like designing products is like a team sport these days. Nobody, well, unless you're like a solo designer that also knows how to code, that can also do the backend infrastructure, then maybe you're working all by yourself. But I'd say the vast majority of us, most of the time, are working with others. And so the cognitive overload of switching between all of the tools and all of the communication channels over and over and over while we're expected to ship faster and faster and faster. And I don't know about you guys, but whether it's clients or your boss or the CEO, which is actually really funny for me to be in that spot these days. We're expected to work faster than we ever have before. With more tools and more output that's all disconnected. So if collaboration is central, and yes, I use the C word. Collaboration is important. And it requires a level of transparency in our work that has not really existed until very recently. I look back about a decade ago and most designers, myself included, would hole away in a room for weeks on end just cranking away, designing out whole systems. And then we would come and we would present them. And there was this grand reveal. And one thing I've realized is fuck the grand reveal. Seriously, it is not worth it. You want people bought in from the very beginning. You want the folks that are either paying you or working directly with you to be a part of the process. We're working in an environment where we're designing for more context than I can imagine. Whether it's devices or it's physical, you know, watches or it's screens. Or it's now voice activated user experiences. It's not getting any simpler. Am I right? No? You guys are good. Okay. Repeatable work is another huge part of this. So we're moving into this component driven, very systems oriented era in design. And personally, I find it to be very, very exciting. It's an approach that's served me very well in my career. It's something that I've seen allow small teams to do very, very great and powerful things. It's something I've seen very large teams use to be able to build a consistency and a very clear identity across large systems. But that visibility is so critical because not only are you as a designer a part of a team, a part of a cross functional team. But you don't want to be duplicating other people's work. I don't know about you guys, but the number of times I've redrawn someone else's work, redrawn a button or redrawn an icon or redrawn this or that or the other, it's just maddening. And then you realize you end up with like 48 different versions of a thumbs up. Right? Or in the case of Twitter while we were there, I can't remember. I think we had identified there was like, this may be totally wrong, but it was like hundreds of different versions of the bird at one point. And I'm not sure. And the letter T, it was just like, it was maddening. And part of that process was going through and actually like building a consistent language that we used everywhere and replacing all of that madness. But it takes these kind of frameworks in order to do this. And so we're working in a systems-based approach. You guys probably are aware like style guides and pattern libraries are kind of like the topic du jour these days. For very good reason. Because it ensures a level of consistency. It creates a set of patterns that not only design, but it ensures consistency. not only design, but engineering can work from and build on. It allows for the maintenance and the kind of proposal of updates to these things to be a more consistent and clear manner versus before where I would just open your file and copy paste my stuff into it so that it was the right thing. And maybe or maybe not tell you that I did that. I don't know about you guys, but somebody else playing in my files was one of my least favorite things. So this is all going on and we're thinking that like, oh my God, what we have right now is drawing tools, prototyping tools, screenshots is the output of all of it. And we have more on our plates than we've ever had before. So we look to engineering and it turns out that having an engineering partner in Kevin was one of the best things that I could have asked for. It also didn't hurt that I'd spent a number of years in my career attempting to bring some of the practices from the engineering and development side of the world over to how I did my work as a designer. So the mid-2000s was using Subversion, which is a version control tool for managing files. And you essentially check them in and check them out. And it has a nice little cadence to it where you know who's touched what and you kind of have an idea of these snapshots in time. Engineering has had this for 30 or more years. VCS, Subversion, then in around 2008 or 2007, 8, Git came along and then GitHub. These tools are oriented towards collaboration from the start, especially distributed collaboration. For those of you who don't know, Git was actually built to be able to manage all of the contributors that were building the Linux system. And they all lived all over the world. So you're going to bring code from dozens of different engineers around the world together and make it all work. This version control system was born to be able to handle that. And I don't know about you guys, but we're watching, I think, more and more of the workforce transition into a remote and distributed world that we're going to live in. I think it's going to be more and more that way. So having systems as designers that allow us to participate in that is even more critical than it's ever been. So being able to do work independently, not stepping on other people's toes, not accidentally creating conflicted copies all over your folders. Having context. How about that one? I don't know about you guys, but it's really hard to glean context out of a screenshot. If you've been doing it long enough, you can maybe try and intuit some of the nuance of decisions somebody made. But if there's a way to capture some of the thoughts and decisions that were made and have that live alongside the content, the output, that would be phenomenal. Well, it turns out in Git and in these version control systems, they have this notion of committing and leaving a commit message. So you do a chunk of work, you commit that work. It's like a super save, if you will. And you've got to put a little message on there. And so being able to tell everyone else what you've done and what maybe they need to pay attention to is an amazing leap forward. On top of that, people being able to see where are we at? Where are we going? And where are we at? Design fundamentally is about helping people see the future. It's about painting the vision of where a company, a product, a feature is going. That's our job. That's one of the gifts that we have is this visual communication and ability to help people imagine a future that doesn't exist yet. But once you've gotten them there, then they want to know, okay, so how long until we get to the future? Where are we in the progress of getting to this awesome future you've just brought us into? And as designers, it's challenging. You could tell them to go through Dropbox or Google Drive and maybe they will be smart enough to figure out what's the most recent thing they should look at. Or you might use some other service. You might export a bunch of screenshots and put them in a PowerPoint presentation and leave that up for executives to take a look at. You could do all kinds of things. And one thing we hoops than any human should jump through in order to get something done as long as it allows them to reach their end goal. Engineers, on the other hand, will look at that and go, that's insane. I'm going to make some scripts that will actually do steps one through nine for me as long as I do X. And once I get to nine, if this is true, then this and this and this can happen. And I thought there's something pretty smart about that. Maybe, just maybe, all this willingness to adapt and use duct tape and twine and bubble gum and essentially, as I like to call it, MacGyver our way through our work isn't the best way that we could do things. And so we thought, okay, why would we reinvent the wheel? Why would we try and, you know, make a design way of working? Are there concepts? Are there fundamental pieces that we can take from this and bring into our workflow and give us kind of some of those superpowers that our engineering counterparts have? And so we looked at that. All of the pieces that were in there were like, oh, these map, they totally make sense. They've given engineering this ability to be transparent and open in their work. They have accountability baked in. They have consensus. They have, you know, they have a record, which it turns out having a record of the work you've done is really, really valuable if you want people to trust you. And I thought to myself, I think every designer I know out there really wants the people they're working for to trust them. That's at the end of the day, you hired me to do a job, trust me to do my job. But one of the things that I think is kind of missing in the way that we've been working for a very long time is we haven't been as transparent. We haven't been as open and bringing people into that process for multitude of reasons. But at the end of the day, as design is beginning to take more and more responsibility in helping shape the future of products and companies, stepping into leadership roles, that record, that system of record, that transparency is going to be one of the most critical aspects in getting the rest of the organization to believe in and buy into what design is helping them. Move toward. So we looked and looked around the company and said, okay, so sales teams have Salesforce and others. Marketers have Marketo. Engineers have GitHub. And design has, let's see. And I'm not joking. I left at least a dozen off of here. Design needs a home. Design needs its folks at Airbnb talking about design infrastructure and design ops as an actual function in the business. home. So I think design and getting a home is really important. Now, there have been a lot of attempts at this in the past. Subversion, as I mentioned before, is just a tool that I've seen a number of teams adopt, but it's not quite there. And there's some challenges because it's primarily a command line tool. Layer Vault took a really awesome charge at this back in the early teens. And unfortunately, they weren't able to overcome some of the challenges that they faced. One thing that was really challenging at the time was that the way they were trying to solve this was by literally uploading your Photoshop document every time you hit save, essentially creating a version of it. But there was no understanding of what changed. There was no insight into the files. Pixel Lapse was another company. It came along with a very similar premise and really wanted to... to solve this for design and ended up running into the same problems. We don't know what's changed. Yeah, sure, we can make revisions of files, but there's no understanding. There's no ability to read into it and understand and intuit what's changed. There's no ability to bring it all back together. It's all very manual. And so, you know, GitHub came along and a lot of designers that were familiar enough with code and had used GitHub started putting stuff into GitHub. Same problem. Don't understand what's happening inside of the file. Don't understand the work that you did over the last number of hours and why that's different from before and how to actually solve conflicts if you wanted to bring those things back together. And so, we set out to solve it. And we built Abstract to address this very, very deep need, which is how do we manage the files that we work with? How do we build consensus? How do we build transparency? How do we collaborate in a way that is not burdensome and actually gives us more power and more autonomy than we had in the way we've worked before? So, a few core premise that we knew we could kind of capitalize on. One, by only storing what's changed between any version of a file, our storage is massively smaller. We don't have to save the whole file. We only ever save out what changed. So, if you spent an hour working and changed 12 artboards, we don't have to save the whole file. We actually know enough to be able to save just the file. The set of data that changed. And so, there's storage costs that go down. There's an ability to understand exactly what changed between two versions. The workflow that we introduced. And I'm going to give you guys a little bit of a demo in a little bit, which I'm always nervous of doing live demos, but screw it. We're going to go for it today. But before we jump in there, kind of just a couple core concepts. The workflow of branching, committing, reviewing, and merging. And you'll see it in action in a moment. Branching is essentially something we do today. We duplicate files and folders all the time. Actually, let me see. Raise your hands. How many people on a daily basis, or how about a weekly basis, duplicate a file or folder in order to do like an alternate exploration? Or to work off of a new project? Holy, yes. All right, good. That's about what I thought. So, we're doing this. We're doing it all the time. And we had this kind of like light bulb moment. We were like, oh, my God, do you want to know why that's terrible? Because you can't put it back together unless you open two files and you start manually copy pasting into a new file. And at that point, you had one, two, at least, and then, you know, so one, two, three, four files. And now this new one that has all this merged work has no history. It has no undo stack, right? It has no way to go back and understand how it even arrived and became this thing. So, we're like, okay, branching means that we can essentially duplicate our files, do work. And have the ability to put it back together again. I thought to myself, okay, I would like that. That would be kind of amazing to be able to press a button and have the computer do the work to like magically put it all back together. Okay, check one. Two, committing. I mentioned this earlier. How great would it be to get screenshots with an annotation on the side where somebody explains why they did what they did? Or questions that they still have about the approach that they're taking. The ability for anyone to go back in time and see how an artboard has changed over several dozens sometimes of commits is one of the most like amazing things. And I thought, okay, so we've got transparency. We've got accountability going on. We've got this record that's happening. Okay, these are all good things. Reviewing. Okay, well, in any given, you know, workflow, you probably get somebody else to have their eyes on it. And in any company that I've worked at, the people who made the decisions to approve or reject something, usually somehow magically weren't a part of the discussion any further after they gave the thumb up or thumbs down. And over time in a large organization, you find yourself asking, why did we do this? And everyone in the room looks around and says, well, I don't, I don't know. Okay, so who approved this? Oh, Joe did. Well, Joe hasn't worked here for two years. What was the context in which this decision was made? Oh, we have no idea because actually nobody, nobody that worked here when Joe worked here is still here. So why are we doing this? Right? And you go round and round and round. And I don't know about you guys, but that requires time. That usually requires a bunch of other people in the room. And those kinds of things seem a little bit silly given that it's 2017 and we have all of these things at our disposal. So being able to, you know, have request someone to give you feedback and give you approval and record and capture who decided to say yes or no, and then allow that to be merged back together. And that kind of basic workflow has become, at least for us as we've built it and used it, one of the most transformational pieces of the experience of designing and using abstract to support that process. Review requests, which was what I just mentioned, gives you kind of the ability to present work in a, in a ordered way. We built and are building a couple features that are around presenting your work because it turns out that's a huge part of what we do. We do some work. We then have to present the work. We have to give context. We have to paint a picture or tell a story. And being able to do that in a seamless way that's still connected to the work is really, really valuable. And then last but not least is awareness and collaboration. So as I mentioned before, there's so many people involved in the design process at this point. It is a team sport. And in my role today at abstract as CEO, this is kind of the most critical piece for me, this awareness and this ability to know what's going on. And at any given moment is critical because I don't want our team to be sitting around waiting. And in the old way we worked, it quite often was like, okay, I did a bunch of work. I exported a bunch of screenshots. I dropped them into Slack. I mentioned you and said, hey, give me feedback. And then we tried to have a conversation about these screenshots in a linear messaging format with no ability to point to anything. And it just got messy. I don't know about you guys. That was our experience. So we thought, okay, what if we could present it in a way that you can point to specific things? You can annotate the very crisp pieces that have questions or are really working well or need to be removed entirely. But in a way to communicate and collaborate at very specific points. Having links and being able to share an art board or a file or a collection, which is our presentation format, with anyone. Have them see it on the web instantly. These are critical to being able to move quickly and keep people in the loop and aware of what's happening. Commenting with annotations is like a great leap forward. I still think that there's some great things that we've got planned. And I think the more we can move towards actually talking about the objects themselves, the better our communication is going to be. Building integrations. So we have a Slack integration in our product. And that was transformational in the way that we worked. It went from... Maybe a day of lag time in reviewing and feedback to minutes to hours. I'd get a notification in Slack. Because as CEO these days, I'm either in Slack or email or a spreadsheet. Which the designer in me just dies a little bit. But it's okay. Because it's the important work. And so the Slack integration gave me this awesome window into the second that Tim, who's our... Tim Van Dam is our phenomenal leader and design leader over at Abstract. He would push a commit and it would be pushed into Slack. And I'd see it and I'd click on the link and I'd go right to the web and I could see what happened. I'd leave him feedback and we'd close that loop like that. And so his ability to work and iterate and keep moving and not be blocked was decreased exponentially. And then we thought to ourselves, you know what? Slack is awesome and other integrations are awesome. But you know what we really need is we need this awareness for everyone in the company. And so we've built an activity stream that allows anyone in the company to be able to see what's actually happening. And transpiring in design at any given moment in time. So at this point, I'm going to jump out of this. And we're going to go... All right, you guys ready for this? I am really hoping... All right. Does not want to do that. All right. So here's our great little sample company. Very, very important title and business name. And in sample company, we've got a couple of projects. So an iOS app, a marketing website, and oh, an intercom integration. Okay. So you guys are going to have to bear with me for a minute because I'm going to basically be playing two different roles so that you can get an idea of how great this is for teams. All right. And I'm also having to use my mouse up on the screen. So please forgive me. So I got a job. Assigned to me. And I have to go and update our intercom integration with our new brand colors that we've just recently approved. But my teammate is already working on a bunch of copy tweaks. And so this is a project in abstract. And this is the master branch. The master is essentially the master files. These are the approved files that have gone through the process of having at least somebody's eyes on them. And we like to call this the source of truth. It's something that the more we talked with folks, the more they were begging for was where's the one place we can go and reliably look at the work. So when you jump into master, you see that there's a conversation. So this is the integration. It's going to be important. And here's the product brief that we're working off of. Here's the commits. So the project was created. And then we imported. I really can't see over there. Oh, we added a file. That's all we did here. Awesome. And so we'll go to the files tab. And now we have a full-blown preview of the sketch file without having to actually open it. Here are all the icons. Some of this is super blown out, so you'll have to forgive me for that. All of the artboards, everything in here, you can click on them. You can see a full preview. You have a history over here. But we're on Mac. and this is brand new, so there really isn't much. So we'll pop out of this, and we'll go in and check out the Copy Tweaks branch. So like I mentioned before, a branch is like a workspace that's just duplicated with this awesome piece of technology that allows it to be reconnected. So it's not duplicated. It's literally duplicated with the ability to bring it back together. So we'll look in here, and we find out, okay, this is great. Okay, there's been, ah, we changed some language in the Compose field, and nothing else has happened. So that means that I, with the job of going and changing the brand colors, I can create a new branch off of this branch, and that way I get the copy changes. Ooh, that's awesome. I can genuinely say I've never seen that happen before. I'm going to blame the HDMI for that one. It's going to be brand color updates. Woo! Actually, that's a special feature only triggered when you're doing presentations. So now I've got a new branch, and I'm clicking things I shouldn't be clicking. We're going to open it up in Sketch, and here's Sketch with this wonderful file. See our little plug-in down here? So here's the project we're in and the branch that we're on, and we're going to go, man, more challenging than I thought I was going to be doing this on the screen this way. We're going to jump in, and we're going to go into the symbols because we make heavy use of symbols, and we're going to change, we're actually going to change the header background color, and we're going to make that, oh, yeah, we're going to make it this blurple color because blurple's really awesome, and we're going to update the header background color. And so now all the places using those headings will have a new color. We're going to go in here, and we're going to update this one as well, and everywhere that uses the button background, we're going to update that. Oh, there we go. Okay. And we're going to pop back over here and see that, oh, there's one that I missed. I knew it was going to happen. We're going to update all of these guys in one pretty quick fell swoop, and these look different. These look terrible. So let's go in here and make sure that we update this as well. We're going to change that to like a nice, oh, what a nice gray. All right. And this one as well. You guys are super patient as I design live in front of you. And then I'm going to hit save. So it turns out you still have to save your files. But the cool part is when I hit save, what happened behind the scenes was we read the file, and since we knew what it looked like when you started it, and we know what it looks like when you hit save, we now have a record of the change set that's happened between those two points in time. I can now hit preview and commit, and I get this great preview form of all the changes that happened. So four artboards were changed, and four symbols were changed. So I'm going to say updated, and there's our party thing in the background. Two new brand. Blurple. Yeah. This, I don't know about you guys, but typing in front of people is a guarantee for me to totally spell things wrong. Was requested by the CEO. And we all know what that means. Winky face. All right. So now I've made a commit with all of these. And in this branch, you'll see that in the files tab, here's all of this branch's work. And so I tell my colleague who did the copy tweaks, hey, just a heads up, this is all ready to go. I updated the brand colors all over the place. So feel free to jump in and take a look. And he takes a look in here and says, okay, you know what, this looks really good. Let's go ahead and merge it. And so he says, let's merge this. The cool part is there were no conflicts. So we can just simply merge. It archives that old branch. And now the copy tweaks branch has the changes that were made in the copy and the brand color updates all in the same file. Now we could easily go in and request that the CEO come and take a look. He takes a look, says this looks great, hits merge. We merge it into master. And now on master, we have all of our updated copy, our updated brand colors, and everyone's aware of what happened, who did it, and how. And for us, this was a giant leap forward in the way that we work and the teams that we're seeing work. There's a couple other little things I will tell you quickly. As I mentioned, there's this great activity stream that I was doing. This is the first version. Previews and text and everything will be in there soon. But can you imagine jumping in and if you're working on a large team, being able to know what was actually happening? Oh my gosh, okay, so there's a commit. And I can click on that commit and I can go, oh, I'm not online. Shoot, sorry about that, you guys. We'll pretend. Well, it looks just like this. But on the web. It's magic. We also have the Slack integration that I was telling you about. So here it is right in Slack. And I can see these things. Small previews are coming very soon. I can click this button and it will take me right over to the web and jump right in. And it's been kind of fantastic. We've learned a ton. And I'm going to jump back over here. Get back into this. We have been in beta for about five months and have a bunch of teams using this. We've got a couple of thousand active. Using abstract to change the way they work day in and day out. I thought I would share a couple of things with you guys. It's been super humbling to see the kind of feedback that we've got. Folks are feeling like a professional. That was one of my favorite things that somebody said. I feel like a professional. I said, oh my God, then we're doing something right. The workflow. I got a clap from Obama. All right. That's not too shabby. This isn't a brand new idea. But it was something that we spent months and months agonizing over. Because the complexity behind the system is such that it's been prohibitive for most people to engage with it. And so by simplifying down the kind of technology and the superpowers that Git enables us. And building a few things on top of it that allowed us to do some very unique and custom things. We've fundamentally altered the way that some teams are working. We've got companies with hundreds of designers. We have small teams of two or three. Everybody in between. We have solo designers working by themselves. We have freelancers. And they're begging us to be able to invite their clients in. Which is in the works. And so my team, when they wake up in San Francisco, is going to hear something, I'm sure, about that. But it's exciting. Like being able to invite. You know, to be able to invite your client into the project. If you so choose. And participate in the process is something we're really excited about. It is. It's working. It's pretty darn stable for an alpha. In fact, most people keep telling us, why are you still an alpha? Please, please, like, get this out there. So the public beta is coming very soon. Early July. I will not commit to a date quite yet. But we'll be opening it up for everyone to come in and sign up. You can follow us along at Go Abstract on Twitter. You can sign up, if you haven't yet, at abstractapp.com. And I am so thankful to have gotten the chance to share this with you guys. Thank you very much. Amazing. I actually wrote down so many questions during that. I don't have a lot of time to ask questions. You kind of mentioned there's a lot of JavaScript libraries for everything. And developer tooling is crazy. I was literally backstage Googling weirdest NPM packages. And there are some weird things I found that I want to talk about. You should Google it yourself. But why do you think it took so long for design to catch up with that tooling? Is that because designers don't code? Sorry to bring that up. What is it that actually, there's been no focus on it for so long. So I actually think, and actually I'm pretty confident, that it's largely due to Sketch. Right. Wow. Honestly. If you go back to 2013, Sketch launched Sketch 3. And that was that beginning moment where the transition started happening. It was a different drawing tool. It had a different approach. They opened up a plug-in architecture. And that one decision, I'm convinced, is probably one of the most important things that's happened for our industry in quite some time. Wow. Because there's a lot of really smart designers and developers out there that do care about these things. And at Twitter we built systems where we could suck in real data to start populating our prototypes. Because we knew that putting our own made-up tweets doesn't work when you're trying to user test. They're like, it doesn't resonate. But if you put their own real content in a design that you're working on, suddenly they're completely able to give you real usable feedback. But there's no good way to do that until people start using it. Until people started building plug-ins. And Sketch opened their new file format. We did a ton of work before that. And so the file format is kind of like an added bonus at this point. But we had done the work to basically do that. I think this notion that the file itself is this big proprietary black box and it really isn't programmable. It really isn't versionable. And that's been this giant gating factor. Kevin, my technical co-founder, went in and did some really clever stuff and came and showed me the very first workable prototype. And when he hit that merge button and he merged, it was really like a circle. And in one branch it was green and on the other it had a drop shadow. And he merged them together and my jaw hit the table. And I was like, so we're starting a company, right? We're going to do this. We have to do this. We showed Tim Van Dam the demo. He pushed back from his chair and said, are you guys hiring? And I'm like, okay. So we're on to something. We had our work cut out for us, still have our work cut out for us. But I really like so much props to the Sketch team for, I think, making decisions that were not what I would say the big players would have ever considered doing and really opened a door and started this new landslide or, you know, landslide might be a bad word, but push towards tooling and infrastructure. And I also think the other piece of it, the other piece to it is the responsive design as a concept and the fact that, like, we have to do so much with so little these days, it's meant that we had to find new solutions. And I think we just hit a point where it was like what we were doing before will not continue to work. And so you get into any of those moments and suddenly certain things just start coming together. And so huge props to Kevin. It seems like it's moving really fast now. That's why I asked. Well, now it's just like it's crazy. It came out the other day with the design system that imports your whole React app into Sketch is just incredible. So it's a crazy time. It is a crazy time and it's one of the things we're excited about because we are going to be building an API. And we're really excited to see what starts happening when you can actually plug into design data. When you can have an API to the actual data in the files. What can people do? You can conceivably, you hit that merge to master button, and suddenly all of your assets get generated and exported to the Git repo where the developer is working. That sounds like a world I want to live in. Absolutely. That's where we're headed. Awesome. All right. Thank you very much. Thank you guys.