Transcript
I'm gonna be giving a talk about something quite different from what Scott and Marty were just talking about. Again, this is not a tutorial on Figma or 101 or really anything like that. It's more about our agency, Tundra, and my attempts, along with some of the designers' attempts, to introduce Figma as a tool that we can use at our agency. I'll be going through that with a Notorious B.I.G.-themed talk, and every slide, similar to these guys, is kind of just a Biggie Smalls track that I'm going to make up some stuff to talk about.
As you've already seen, I'm Adam Brock. I'm a senior front-end developer, officially at Tundra. I change my title all the time on Slack, so at the moment, I'm editor in chief. This is me today. We don't take him too seriously. I checked a record; I've mentioned before he's the technical director of the company. His client-facing role is junior front-end developer at the moment, so we really don't take it too seriously. I think that just makes it easier for us to be more adaptive to work without the disciplines and actually take on parts of the job that may not be in the official job description. That's kind of the way we roll there.
I work at Tundra; we're a leading digital agency in Collingwood. If you saw my last talk, I was talking a lot about the Nike account. That's my team's biggest account. I personally spend a lot of time there, and a lot of the designers who are in the crowd from Tundra would spend their time there as well. Obviously, I co-run the Design Ops meetup with John, and yeah, we're the most dangerous meetup in Melbourne.
Kick in the Door is a great track, but also this is a question that I received quite a lot at the last meetup. When we had the informal catch-up, I was getting people from varying companies—big companies, big agencies, product companies—and it was effectively a version of this question: things aren't that great in my workplace, but I don't even know where to start to change them. I think this seems to be a really common problem, and I want to try and hopefully address that a little bit. I don't have all the answers; this is based on the last two months, I guess. All these things I'm going to be talking about are from my perspective related to Figma specifically.
The everyday struggles—the design workflow is broken in most places, almost every place, actually. It's broken in one way or another. As Scott and Marty said, even with their workflow, which I really, really like, there are probably one or two spots. It's not perfect, and it probably will never be perfect, but there are degrees of that, and a lot of companies are more perfect than others, while some are just on the other extreme too. We do have this everyday struggle as designers and as developers, and the both combined, where it's obvious that it's broken, but it's not obvious how we get past those things that are broken. As these guys kind of said before, they learned to live with those things, like the 20-folder deep versioning, manual versioning of folders and things like that. There seems to be more of a tendency to get comfortable with these problems rather than putting things in place to try and sort of leap over them, and I think that's a bit of a problem.
I'm just gonna talk about this for a second. Things don't change—again, pretty cool track—but it's really relevant to right now. We are in a spot where things have changed. As a designer, as a developer, everything's just completely changed. If you look at the future of these trends, they're not fads; they're trends that have been happening for a while and will continue to happen. A few of these are pretty obvious to me. The first one is quite a big one: collaboration. If you look at the tooling that is coming out, they're building in collaboration into these tools. This is something that is being more widely used and more widely requested for projects and for designers. Everything from other tools like Google Docs is obviously a very collaborative environment. Slack is very collaborative. Figma clearly is very collaborative. There is a trend where things are getting more collaborative rather than this siloed workflow that a lot of people are used to.
Decentralization is another important one. Like these guys, they don't work next to the developers. They have to be able to work in a decentralized way, whether a developer can be in Canada or in another country and still be able to have a really good workflow. Decentralization, I think, is another really important one.
Iteration—we have to be able to make iterations quickly that don't go through this crazy process of generating those flats, generating the 40 pages, getting that to 95%, and then presenting it to the client as a finished product. Then being so shocked when they don't like some of it. You think you've perfected this design, but you're actually back to, you know, I had this joke: has a design gone, "Yo," and that like 90% don't like? Cool, I say you're halfway there because you know it's gonna go back. It's not done based on client feedback or in general feedback; it just doesn't really work that way.
The fundamental way of how we need to work and how our work is changing. It's already been changing, and it will continue to change. This is not something that's just a little blip. We kind of like this idea of collaborating and being able to make fast iterations. This is something that will only increase with time, so I think acknowledging that is quite important.
With that being said, "Somebody's Gotta Die." In our case, again, we're big fans of Sketch. We have been using it for a couple of years full-time. We got off Photoshop quite a while ago, and ironically, the switch from Photoshop to Sketch was fairly similar to what I'm going to be talking about tonight. You can basically take that and apply it to how we did it back then. Alex, wherever he went, he's probably going home. A sticker this mean oppa now, but he was actually pivotal in the switch from Photoshop to Sketch as well. I vividly remember a walk back from like All Press or something, and you're like, "Man, like, you know, Sketch is always—I can't wait until we can use it." It's like, "What are you waiting for? You're the most senior designer or whatever. Do not speak bad things about that man. You do the outside, not in front of me."
Anyway, just like you know, these designers who are very senior or very knowledgeable still feel like they're being held back or they don't feel like they're the ones who can make that decision. I just think that's sad because it's holding back very smart people who have really good ideas or want to change things.
Going Back to Cali, we looked into a tool that could resolve a lot of these problems that I think everyone's familiar with. I'm not going to go down the laundry list of all the problems that we have with something like Sketch or that kind of workflow, but Figma immediately just jumped out to me. I'll expand a little bit on what those guys talked about, but as I said before, it's effectively a Google Docs version of a design tool. It's based on this collaborative nature that's built into it. It's not like a plugin you have to install; they've built it from the ground up that way. For me, the most important feature of it is that it is built using web technologies. This is not a native Mac OS platform like Sketch. You can't install that on Windows or Linux or whatever. The fact that they've built this from the ground up in the web using web technologies like WebGL seems like not many people acknowledge that as being such a huge deal. They are two to three years ahead of any other design tool just on that fact alone. It's such a big deal, and I'll be touching on a couple of reasons why in a second, but from a development perspective, it's just such a cool starting point for them over any other tool. The sky is really the limit.
If I just kind of delve deep a little bit on my initial impressions and my gradual learnings of Figma and thoughts on it, as we mentioned at the top of the show, Chan said our mission is kind of to reduce the distance between design and development to zero, and I truly believe this tool will be pivotal in helping us do that. There are a couple of things of note. Figma 3.0 was just released, I think, two weeks ago, as these guys touched on. It offers a whole new range of features. I'd encourage you to check out the release notes from Figma. They did a really good blog post covering off all those things, but there are a couple of things that really stood out to me.
Mark, wherever you are over there, Mark—from Tundra—he showed me a demo last Thursday, I think it was, so last Friday. I was about to go to a meeting, actually. He showed me at his desk. He had a couple of days booked in to play around with these new Figma features, and as soon as I saw it, I was like, "Oh my God, this is a graphical representation of my codebase." The style tools they have for typography, colors, and layout—all these variables in my mind are racing. This is a one-to-one representation of what a codebase would kind of look like in this as a design system or a codebase of components. That was just a really immediate shock to me.
I think the other underrated thing, which is half out, is Figma again being a web-based tool. It's so cool because you can integrate with it via web technology. You can actually have an API set up where, at the moment, they've done half the puzzle. As of now, you can, from a development environment, access a design file or a project in Figma and read the contents of that file in a JSON format or in a web-friendly format. For a developer, being able to access all of the information from that design file and have it translated into a language that's native to their codebase is just really incredible. The Figma team themselves have already shown a proof of concept of this where they have actually written something where you can read from your project file, and this application they've built will transfer that into actual React components—like production code—which is quite incredible. I know Sketch can do this using, you know, react-sketchapp and all that sort of stuff, but this is really at the native layer of Figma, and that's half the puzzle.
Again, this is very, very new stuff to Figma as well, but if you realize the implications of that and the power of that looking forward, it's quite incredible. As of right now, again, you can look it up. There's a whole bunch of use cases that people have already started building. You can generate a style guide on the fly, you know, automatically based on your Figma files and all that kind of stuff. But the really exciting part is the write API. Sometime in the next six months, they've said that they're actually going to be releasing a write API. At the moment, we can read from design files, but they're going to be closing that loop by allowing us, as developers or anyone who's writing code, to actually do it the other way. I'll be able to take my codebase and push stuff from that codebase back into my Figma file. This is quite literally closing the loop between my design environment and my development environment.
I personally believe that the current version, which they've done a proof of concept of having the design get converted into React components, is not a great way, but that shouldn't be the end goal. The highest fidelity version of the product should always be the source of truth, which is the development environment, the production environment. Being able to read from that development environment and convert that back into Figma, or convert it from your website into Figma, and then make updates in Figma and have those changes in Figma pushed back up to the development environment—almost effectively using it as a graphical representation of your design system—is a very, very powerful idea. I truly believe we're going to be getting somewhere close to that, and again, this won't happen overnight. This might take 12 to 24 months, but the development community loves this kind of stuff, and I will personally be working on trying to get this working as well. I think it's just really the direction where everything's heading.
Even I guess the existing implementation of this, which is probably one of the closest versions with the react-sketchapp. I know Mark, who gave a talk here a few months ago, they've integrated into their build pipeline. When they do a build, it basically pushes the production code into a Sketch file. It effectively generates a Sketch library or a Sketch file. They call it a Sketch; it works in Sketch, but it's actually rendering production code into Sketch. You can edit all those components directly in Sketch, but they're being generated from code, so it's a one-to-one with your production environment. Unfortunately, it only goes one way; we need to close that loop.
With all that technical stuff aside, this is more about the process of getting this stuff changed. Ready to die—you have to be ready to die for this stuff if you truly believe in something. Let's say you're still on Photoshop, and this is a real use case. Someone—I won't name in the crowd, who I'm kind of looking at directly—he's at a very big agency. He only joined there a few months ago. They just switched from Photoshop to Sketch like, you know, eight weeks ago or something like that. It's an extremely big company, and if you know that Sketch is probably a better alternative to Photoshop, it may or may not be an easy sell. But if you really believe that that is the better alternative and you're ready to die for that idea, I think that's a really good place to start. You have to be willing to kind of stand up for what you think is good.
I have a little quote here: "To sell your soul is the easiest thing in the world. That's what everybody does every hour of his life. If I ask you to keep your soul, would you understand why that's much harder?" I really like this quote. It's from a book called The Fountainhead, and it's from the main character, Howard Roark. He has a very extreme level of integrity because he knows that on a long enough timeline, you're gonna regret it if you just sell out every time and you don't stand up for what you think is the right thing to do.
My approach here is one part of it is to get some help, so you don't have to do this on your own. The notorious thugs, I guess the point of this is there's other smart people in your company or your agency who think similarly to you. They might not be obvious, but you can find them. Talk to them. You want to find a few smart Mavericks who are willing to kind of put themselves out there a little bit and help you with this cause of implementing change. That's kind of one of the things I did recently at Tundra. Shout out to Kaylee, Mark, and Elliot as well. They've been really, really supportive of helping me try out Figma as a design tool. I'm not a designer at work anymore; I used to be a designer. I'm not on the design tools anymore, but these guys are, so I really value their opinion of Figma as a design tool, and I wanted to work with them as a developer to see how that integrates into my workflow as well. It's really a bit of a back-and-forth.
To get this to work, you really have to build in a 20% expected failure rate from the start. Failure is not in a bad sense at all. Again, I think there's a level of fear: if I do this, am I going to lose my job? Am I going to get in trouble? I think you need to build that in from the start because switching to any new tool is gonna have some bumps, whether it's from the software itself or the onboarding process. You may not be as fast with it up front; that's okay. I think building in that failure right from the start and letting people know that it's safe to try these things and they're not going to get in trouble for it, and in fact, they're gonna get in trouble for not trying new things, really is the message to send. I think that's really critical.
I can't emphasize this enough: just talk with your team. Again, I think a lot of people just internalize this stuff and just have self-talk where it's like, "Oh man, I wish I could use this thing. When will someone change it?" They're just talking about getting really worked up. Just talk to your team about it and see if they've been thinking about the same things. There's a good chance that they probably have. Not just the designers or the discipline-specific person. My team at work, as you may or may not know from previous talks, Tundra's split up into two teams. We're the same company, but we have two sets of clients and all that sort of thing. My team, the Brown family, are named after our Lord and Savior, Andy Brown, in the audience. It's really the key place to talk about this stuff. They're not all designers, but every day I will be posting something about Figma. I've been doing this for like two months, and I'm sure everyone's sick of it by now, but at least they're aware of it and they're thinking about it. We've had really good discussions about it.
I think it's just about educating people as often as possible and really just keeping that communication every single day. When I'm in the kitchen making breakfast at work, I'll grab the designers. We'll just have a ten-minute chat, and that was just really critical, I think. One of the things recently, as a sort of solid example, was the Design Ops Handbook released by InVision and the Design Better Co. sort of side of that. When we sent that around in the morning, I think all the designers jumped on it. We had such good discussions the next morning. Everyone was so amped up about design ops and about this kind of way of thinking, and they wanted to jump on board and see how we can change these things.
This is a quote from Elliot Minson, who's in the front row. Elliot, wave. This was what I would call when I talked about critical mass before. Elliot is a senior digital designer at Tundra, and when I talked about getting that critical mass, having someone like Elliot give this kind of endorsement to me was really—I truly felt like it was a bit of a tipping point. I think he's someone who, obviously, I respect his opinion, and him sending me a message like this—I literally just linked him to another really good article from Deliveroo that talked about their experience with Figma more recently. I highly recommend reading that article too. But I got this message: "I'm sold. I migrated my portfolio design to it last night. It's so good. #F***Sketch." How inappropriate, Elliot. But anyway, if you ignore the bottom, it's actually a really, really good sign of kind of two months of persistence of trying to get these conversations and things happening at work.
I'm talking about management or senior people in the team. Of course, this seems to be a very easy excuse to make: "Oh, you know, my boss won't let me." But it's really self-defeating. Again, you're all internalizing this. You probably haven't even talked to them about it if you're being honest with yourself. My approach to this would be very similar to the first thought I gave here about sort of effecting change or bringing in things that you believe into a team. This doesn't have a hundred percent success rate, but for me, it's proven to be the most effective way of conveying value. You really want to make whatever you're doing, whatever you're proposing, make it ten times better—not ten percent, ten times better. A 10x improvement of anything, any metric, is very, very hard to argue with or ignore completely. You might get some pushback; that's great. You're having a conversation about it. But if you can put that work in yourself and you've shown that you've gone above and beyond in your own time or at work or researched at home and actually demonstrated it to someone and showed that it is ten times better in whatever metric you're measuring, I think that's going to give you a really, really good shot at at least getting that built-in failure rate from your design managers or your higher-ups as well. I really recommend that approach.
Suicidal thoughts—again, I think this has come out of my own discussions with designers from lots of different companies that I've talked to. There's a really common theme again: that self-defeating attitude, that feeling like nothing is ever gonna change or you're waiting for something to happen or you're waiting for someone else to make that change. I just never really understand that. No one else is going to do it. If you got that envelope I was handing around before, I've kind of described this in more detail, so you can have a read of that later. No one is going to save you, so as soon as you realize that and you realize it's actually up to you, that's probably a good frame of mind to have. For anyone who's stopping these things from happening, all these discussions from happening, the sad truth is that's not actually that sad; it's probably for the best for the person. From my experience, the best people will quit. They won't put up with it for too long; they'll quit, and they'll find somewhere else that will offer this. I know people in this room who have literally quit their job in the last six months because their company was still on Photoshop or just something that they couldn't see changing in the near future.
The best will quit, and even worse is the rest will stay, and they'll be dead inside. The ones who just—really, really on the other extreme of this—and they don't feel like they have any power to change anything, they'll be the ones that stay there, and they'll be learning to live with those subpar processes or subpar tools. They'll just be dead inside, and they won't actually say anything. Their work is going to suffer; their creative souls are going to suffer; their integrity goes out the window. The real-life implications of not being able to have these discussions or not being able to try new things actually have bigger impacts than just, you know, this little tool is something someone wants to try, but we're not gonna let them sort of thing.
I alluded to this before. This is back to getting in touch with the Figma marketing person, Sarah. I added a little PS when I emailed her, and I was sort of asking if there was any way they could send out some merch or whatever. I said, "By the way, we've got this community, and I want to give them the best possible chance of being able to try Figma or at least see what it's like working with their team in Figma, you know, in a more unrestricted way." They never do free trials or special deals or affiliate codes or anything like that, but they actually went above and beyond. I can't thank them enough for how supportive they've been overall. They went above and beyond, and they've actually worked out a way where we all get one month of free premium from Figma. That's not just us; that's the entire meetup group. They're giving away, yeah, like five hundred and fifty-plus free premium trials, which I'll send out tomorrow morning. I hope that allows you guys to go back to your agency or go back to your studio and share this with your teammates and actually either get the full Figma experience and try it and see how it affects your workflow. Obviously, something to work for everyone, but I think having the best possible chance at seeing how it could work is a good idea.
That's about it. I had lots more to say, but it's a lightning talk. I wasn't even gonna give the talk; I came up with the title on Sunday morning and thought that it warranted a talk. I did want to talk about this kind of stuff, but I will be following the Figma API stuff very, very closely and updating everyone with what I personally find and where this stuff's going. We're just going to keep following this until it actually happens, basically. Thank you.