Transcript
Thank you very much. I sort of threw this together; if I get stuck, I might have to fall back to my second rap plans, but we'll see how the mood takes me. I'll be giving a talk called "Insanely Inevitable." As you can see, my name's Adam Brock, and as you probably already know by now, I'm a senior front-end developer at Tundra. I used to be a designer; I still am at heart.
This image I really like—This is Steve Jobs giving a "you know what" to IBM. This kind of resonates throughout the talk, and you'll kind of see when I'm giving a "you know what" along the way. I'm primarily going to be talking about agencies because that's where I've been born and bred, and I still work in an agency. I've heard enough stories from my friends who don't work at agencies and those who do work in agencies to know that there'll be enough overlap for the two. But anything I talk about will mostly just be specific to agencies, and I'm kind of going to address the typical agency model that still is very much rooted in this Mad Men 1950s idea. It's very much still stuck in there. We don't dress as cool anymore, and we don't like to smoke and drink whiskey in the morning, but we do sometimes, actually.
This is going to be touching on that kind of tradition as well. Before I can talk about anything, I have to talk about avocado and agile. These two things rightly may have no overlap whatsoever in your head, but in fact, they do have a bit of overlap, and they're also at the same time the exact opposite of each other in other ways. Effectively, from what I can see anyway, the biggest widespread innovation in Australia in the last decade has basically been smashed avocado. The biggest widespread innovation in agencies has been stealing agile from product in a very ill-conceived manner. I actually really like avocados—smashed avocado ahead of today; it's really good. On the other hand, I do not care for agile at all or what it's become, especially in agency land. Agency agile has become obscene, but anyway, I digress before I've even started.
Effectively, what I'm getting at is we were promised flying cars, and instead, we've got 140 characters. There seems to be this inverse innovation that's happening certainly in agencies and perhaps even in other companies as well. I really just want to address that up front before I can get to the second part of my talk, which is going to address some of these things. Just as a couple of examples, these are examples that I've seen myself from other companies when I talk about inverted innovation.
In a quite large company, they're talking about design systems and all this cool stuff. Meanwhile, the designers still need to tether their own phones in order to upload work to InVision. On one hand, you've got this very seemingly progressive innovative idea, but at the same time, this is kind of the tip of the iceberg. It's a very opposite end of the spectrum as far as this kind of approach goes. At the same time, another company I heard talking a lot about innovating with AR, VR, and chatbots and voice—sidenote: I think if your marketing team is talking about things that are innovative, they are almost definitely not innovative, like those examples above.
At the same time, the file hosting service that the company has approved internally has a size limit of 10 megabytes, which is identical to the size limit that email attachments have. The file hosting services originally came out of the need to exceed the email limit, but these guys are still stuck with 10 megabytes. I think again there's some inverse innovation happening. They're focusing on AR and VR when they can't send a PDF file bigger than 10 megabytes.
There are a few reasons for this; this is not an exhaustive list, but these are just some top-level points that I'll go through. Everyone is too focused on busy work. This is a trend you'll just see basically everywhere you look—people running very fast in the exact same place, in no direction, and mistaking it for work or doing unimportant things very efficiently, which doesn't actually make them any more important. Decisions are often made by committee or groupthink. There's usually a lot of really good ideas from people at companies, and they present them to the higher-ups or the group, and then they basically get watered down. They become the average opinion of the average person and end up being average at best.
There's an assumption that the hard problems will just automatically get solved. This is something we're used to, so we don't actually spend a lot of time thinking about the hard problems, just assuming they'll get solved. There's a fear of being wrong or having risk aversion. This is very common; people try to spread the blame and don't want to be responsible for anything going wrong or right. There's a trend of short-sighted vanity metrics over the long term, focusing on things that day-to-day might seem very important but really have no effect in the long term.
Incompetence overrides reason. People who are very reasonable actually doing the work will often get overridden by incompetent people above them who have no idea about what they're actually facing or what decisions are right. These last two are quite pivotal. Process seems to trump substance, falling back to the process and not focusing on producing anything of value. This last one kind of encapsulates the whole thing: there's really just no definite optimistic view of the future. It's very much a possibly undefined optimistic version of the future where things are probably going to get better, but we don't know how or why they're going to get better.
I really like this quote that sums it up: "In the most dysfunctional organization, signaling that work is being done becomes a better strategy for career advancement than actually doing work." If this is your company, then you should quit, which I completely agree with. Effectively, everyone ends up copying each other, and that's why we're in the state that we're in now. Everybody is sort of doing the same thing, smoking on the same tooling, using the same processes, and they're doing it because they're looking at other agencies and doing it that way. There's just this real incremental back-and-forth between companies or reading a blog and incrementally improving things. Maybe it's not even improving anything, but everyone's just copying each other. There's not really much original thought going on at these companies.
This kind of sums up my mindset as a default most of the time. This is a quote from "Atlas Shrugged" by Ayn Rand: "The hardest thing to explain is the glaringly evident which everybody has decided not to see." This is basically how I feel most of the time, and certainly with this next slide. As I mentioned earlier, I think the distance between design and development should actually be zero. This is not a popular view in agencies, certainly, and perhaps in other companies as well. When you start talking about this stuff at face value, really no one is spending the time to understand why this is important. You basically just get not ridiculed, but it's just like you don't really seem to be a value. They can't see behind the short term that they're already dealing with; they can't see the longer-term picture of these things.
This talk is kind of called "Insanely Inevitable" because there's a certain direction that is absolutely inevitable. We're going to get there, but at the same time, you have to deal with your own kind of illusion of insanity to get there and hang on for the ride. Basically, I think things are taking way too long to happen. This kind of change should not be something that takes five years, ten years, or a very long period of time. I think if you have a definite optimistic view of the future and what it should be, the goal should actually be to get there as quickly as possible.
This happens every time. I would have been happy with them off, but that's again cool. I think we really need to be focusing on what will have value in the future, and this is opposite to the trend that we currently see, which is trying to retrofit today's ever-changing problems into these traditions of the past. As I said before, the Mad Men model is like the very beginning, but we haven't really stopped doing that. We try to cling on to all existing ways of doing things, and instead of inventing new ways to solve new problems, we just kind of mash them into ways we've already been doing stuff, and it barely works.
Woody Allen kind of sums it up much better: "Tradition is the illusion of permanence." Things are constantly changing; we can't just cling on to tradition constantly and just expect that to remain true for our lives. It's absolutely not the case. To really make this concrete, these examples I'm about to give are things that I personally saw in the last month. This is 2018; this is not 2008, which is a decade ago. All these examples could easily have been from a decade ago, but they weren't. This is what I'm kind of seeing in the agency landscape, working with clients as well.
Static web designs were created in InDesign. This was the handover format that was provided. Feedback was printed off by the stakeholder, written on in pen, scanned back in, and then put into a PDF file for us to review and action. Photoshop files had to be exported to JPEGs by the design team and put into a PowerPoint presentation to present to the client. The reason for this was that this particular very large agency is too cheap to pay for something like InVision, so they decided that spending three hours of a designer's time to do this is much more efficient than an annual plan on InVision or whatever would solve that problem.
I saw clients signing off on a very large website design that had no content at all. It was just designing delusion effectively. App development handover was handed over with this print magazine-style JPEG file with inputs all over the place. As Mark said rightly before, this was very much at the nth degree of an unconstrained design. It was just inputs literally put in different positions. How does the tabindex even work on this matrix of inputs? It was outrageous. I had to defend it a few times against this idea of unique pages. I was more than happy to do that, but just the pushback I was getting on just this idea of even using components is nuts.
No design thought was given to screens below 27 inches. This was almost like just constant mobile markups with totally different content. You just see one screen, one JPEG, and another JPEG is the desktop version, and the mobile version has two completely different sets of content, or the content is in a totally different order—just different images, different inputs. It's just nuts, and these are responsive designs, or they claim to be responsive designs. Finally, the app designs I got just weren't even using the design system UI. As Mark said again before, they were literally doing stuff like changing the font weights and just designing completely new inputs. It's out of control.
Traditional design tools and workflows have basically run out of track. There's nowhere else we can go with these current workflows and tooling. We need to jump the curve and actually think about approaching this in totally different ways. This isn't just my opinion; it's kind of reassuring to know that other people in the community have a similar view. This is John Gold from Airbnb, very prolific with this way of thinking. He says, "Looking at the current crop of design tools after taking a glimpse of the future is frustrating. There's a total lack of contextual and industrial awareness in our software." I'd highly recommend that article he wrote a couple of years ago, which is worth the read to give a bit of context to that quote.
Finally, another quote from a Facebook designer really sums it up: "Even the most advanced design tools are based on workflows for drawing mere pictures of interfaces." Again, it just sums it up really nicely. I'm just going to touch on this for one slide, but having a design system is just the first step; it's not actually the end game. I've seen a trend where there's this view that once we get a design system or have a design system, all of our problems will be over forever. Again, this is groupthink, this kind of design system trend that we're seeing. It's not necessarily a bad trend, but the reasons for doing it I've seen are a little bit ill-conceived. It's really not the goal; it's almost just the starting point.
This is like the foundation to be able to do anything more than that. We should not be focusing on this as an end game at all. Just some points to ask about your own design systems, I guess: Are the developers actually writing less styles or writing less code? Are people actually using it effectively? Is it documented or always up to date for both parties? Is there ongoing maintenance to it? Is it used across all of your products? Are there workflows to add new components? As a designer, you want to be able to make changes to it. What's the process for doing that? Can UX or design teams prototype or design with the code itself? Most importantly, is the codebase the source of truth for the designers?
I've seen so many design systems that are delivered as a PDF file. That is not a design system; that is a print document with some font weights and colors on it. It's real weird. But I don't believe that we're at the end of history. I think you can either take two approaches: one, you either think what we're doing right now is the best we're ever going to get, and we're basically doomed to a future with these drawing tools; or two, you know this is not the end. It's pretty clear to me that that's not the case. If this is as good as it gets, then it's even worse because the design tools and handover tools that we're seeing are not even actually improving anything.
These handover tools I've noticed are actually removing communication because the tools are leaned on as a crutch to substitute communication. If it's all in some handover tool, designers feel like they can throw it over the fence and not provide any additional context or communication with the developer team. I've seen this constantly, so it's actually not even solving the problem; it's just kind of masking it a little bit.
It's time to get back to the future. I think that design with code is kind of like luggage with wheels. Luggage did not have wheels until after we put a man on the moon. That's a little bit of a weird scenario, but that's kind of like where we are now. We're talking about all these very forward-thinking things—design systems, all this cool stuff, the terms I mentioned before, the buzzwords. We're doing all this cool stuff, but we haven't actually figured out the fundamental problems that these systems still have.
I think like luggage with wheels, design with code is just going to be enhanced over time, and you're not going to be able to imagine going back to luggage without wheels once you've actually seen the way that the future can look. The reason why I said I don't believe we're at the end of history is partly due to the influx of tooling that already exists, is about to drop in beta, or is going to be released next year in 2019. This is not an exhaustive list, but it might be worth taking a photo of this if you want to research them in your own time. They all take a similar approach, which is they all somehow integrate with code one way or the other, typically treating code as a source of truth.
To give you an idea of what these look like, sort of similar to the Framer X example before, I'm just going to show you real quickly three of the demos from these companies. As I said, they are all using code as a source of truth for design, so that's what they share in common. The first one is Alva. This is an open-source tool, so you can actually download this and play with it right now if you want to. You can see on the left these are all components—code components—that are being imported into this application, and you can actually drag them onto your tooling and design layouts and pages with them.
This is kind of the rudimentary version of the idea of using your components or design system in an application to actually make it usable in a way that designers are quite familiar with. Another one I'm actually going to steal a screen cap from a Medium article that was using Seat's library for this, and this is another very exciting app called Interplay. I think this is probably the one I'm most excited about; I've been following them for a little bit. This is actually using that design system you just saw Mark presenting with, and this tool on the left is the application. The design tool and components from the library are being brought in there, and layouts are being applied. You can see on the right there's a real-time representation of that code being rendered. I think that's just really cool. You get to see it in the context with real code and actually see how it's going to work.
This third one actually just dropped on Kickstarter last week; they were trying to raise some capital or some funding, and this has a few cool features too. It's got the interactive states; it's kind of a given. You can style the different versions of a button, for example, or a different component. It's really nice that they're bringing that to the forefront rather than just a flat file. We've got exporting code, so being able to take what you've done in this design tool and somehow reuse it back into the codebase is a very interesting idea. I don't know how well they're going to execute it, but I'm quite interested to see how they approach it.
The design system for this tool is based around the idea that you do have a design system, and that's being used as a very central part of this tool. This one has seemed inevitable to me for a long time: this idea of design linting. We have this in code; if you write something that's not quite right in code, you can get flagged to let you know—it's a little bit of a warning. Using this in a design tool is very interesting; it kind of nudges those constraints a little bit more. I guess you could even apply this to things like accessibility. If a designer tries to use a certain color that may not have the right color contrast for your accessibility level, this is a really nice feature. I think to be able to provide feedback about where you're deviating from the design system is a very nice thing to have.
That's a bit of a catch-all of those tools. I think they're all worth looking into. I think we're going to be seeing a lot more of that kind of style, and these are very, very young at the moment, but it's quite clear that that's one of the ways that we're going to be able to use code in a more familiar way. The other half of it is more about a different direction. I like this line from "The Matrix": "Never send a human to do a machine's job." This becomes more clear when I found out a couple of months ago that half of the code at Google isn't written by humans. That's a very interesting thought to consider when you think about how many engineers they have there and the level that their software is at.
I think that this is something I've given some thought to; it's probably a whole other talk. I think that machine learning, AI, and automation are very underestimated in the design space. There's not really a whole bunch of chatter around it. There are a few things you can kind of find online of people exploring these technologies to assist with design, but in general, I think that these are very, very underestimated for the future of design. I'm not talking about the next decade; I'm talking about the next few years, and we're really not doing ourselves any favors to avoid this either.
This is a tweet from Jon Gold from Airbnb from a few years ago, actually, but I literally saw these two layouts last week as new designs. This is a very relevant tweet even today. It kind of boils down to that; we are actually very repetitive with the way we design things. If this is kind of our standard of design, a computer could very, very easily design this from scratch or certainly build it for sure.
How does any of this apply to us at Tundra, which is the agency I work for? Well, being in this mindset constantly, I'm always trying to explore real problems that we face in the agency. These are all very nice things to solve, but they're probably not the most pressing issues for the projects that we work on as an agency. We do a lot of short turnaround work—very quick stuff that we need to turn around very quickly without design and development teams at a very reliable standard and be able to do that very efficiently.
I've approached this in a couple of different ways. I've said this before, but there is really no glory in building banner ads. They're extremely short-lived code; they're fixed dimensions and have sort of fixed positioning. They are really driven by images, have many different size placements, and the feedback loop on these is an absolute nightmare. You basically take the amount of placements that you have, multiply that by the number of changes that a client or internal will give you, and you get the number of total changes you have to roll out in a design tool, and then the developer has to do that. It's very, very hard to sync design changes with dev, and it's a real nightmare.
I wanted to solve this. I had lunch with my design team and said I should just be able to click a button to generate code from banner designs in Figma. That's the endgame. I just kind of worked backwards from there and figured out how to do it. I'll just run you through it really quick. First up, I decided we should use Figma to do this because Figma exposes the design data via API, so I can access this in a friendly format to my development environment.
The first step was connecting to it to see what I get back. I could basically get all of the frames or placements of these banners, and then I could get a list of every element that was in those banners too. That's a pretty awesome help—the dimensions. The second step was automating exporting assets. It's a real pain to go through, even in a handover tool, and manually save assets out that you have to then save into your folders, decide what to name them, or rename them. It's a real pain.
I automated the slicing process by using the Figma image API, so that works quite well. Then I extracted all the CSS data that I needed to effectively replace myself from putting this data into the build. I can get the width and height of these elements, the X and Y positioning, all the restraints, the naming, all that sort of stuff. Then I decided to turn my node scripts that I kind of got working generating some code into an electronic tool. This is just to make it more accessible to the team, but I also really just wanted that button that I could push.
This is the first version of it. I showed this two months ago just after I'd finished getting this working. This is in a Figma file with banners. I'm copying the Figma file ID, pasting it into this tool that I made called Figmatic, and my API keys are already in there. I literally click this button; this connects to the API, gets all the data, downloads all the images, saves them into a local folder for me, and there's some transformations going on behind the scenes that automatically generate all the code that is required. I get a fully functioning banner straight from the design without having to actually write anything.
This was a really good first step. Then I had to try it sort of at scale, I guess. A week or so later, I just tried running this on a completely different campaign. I didn't touch any of the code; I just wanted to see how robust it would be to hold up to this. It's a really simple way that I approached it; you just loop through all the frames, move through the elements in those frames, and position them. But I wanted to see how far I could get with that.
This is about a five-minute video; this is a screen cap of my first production run. This is building 14 banners for Australia Post. This is for an international shipping campaign. There are some tins of honey on there that kind of look like cans of shoe polish, but anyway, there are two creatives; they're two different targets, but each of them has seven different banners. This is basically what we have to build. If I was usually getting this as a developer, I'd probably want to jump out the window, but in this case, I'm going to run it through my tool and see how it performs.
It's exactly the same process. I'm taking my Figma ID, and I'm going to be dropping that straight into the application and clicking that wonderful button. This is going through the same process; it's downloading all the images, generating the code based on that data. This is actually a much more advanced version of that first one. This has actually got some proper build tooling in it, very similar to the way we were doing it before, but all the gaps have been filled in by Figma basically.
I'm just going to run you through a couple of files that it generated for me. These are all the images they downloaded at retina 2x scale, so they're all in there straight from the Figma file. I didn't have to manually slice them out and export them. Another file here, I'm just going to be showing you the same thing. I've got more images right now, sort of exercising one. I realize how small this is, but this code is all being generated automatically. I'm not writing any of it. All those elements are automatically getting the positioning data that we need to position all these elements properly.
This is all the HTML that injects all those images, applies the class names that are going to get targeted by the CSS automatically. I've got some HTML comments in there, so you can quite easily understand how those relationships work. Back to the CSS, but all the dimensions are in there, all of the animation delays by the folder in there. The animation delays or order is actually dictated by the order of the layers, so as a designer, you can say what is the priority for this ordering.
I'll touch a little bit more on the animation later because it's always the first question I get: how do you do the animations? Effectively, it's using some smart defaults, so even if you don't want to spend any time on animation, you get some decent animation of the box. This is the preview page it automatically generates when I run my build tool, so you can see a list of all the banners. I've got links to all of them. This makes for a very nice internal and external sharing link to the clients. We can just upload this, and we upload it if we make any changes.
You can see in here it's built my banners, and I can go to any of the placements. It's got all the animations in there, so that's the entire campaign build basically. It's pretty cool. If you think about how much time this would take alone to just save out the images, we'd probably still be on banner 1 right now just actually slicing that and creating folders for them. It's a huge time-saver.
There are a few more features as well. I can't remember what I'm going to be showing you, but oh cool. I think I'm going to be showing you some global CSS. If I want to be able to easily roll out changes to all of these banners at the same time, I can quite easily do that in my global settings file. If all of these need to have borders—which a lot of the time they have—their borders in a certain color, I can apply a property that just automatically applies a border to every single banner immediately.
That's quite a nice thing to have, to be able to turn on and off. I think I'm demoing the size of the border. I don't know why it's always one pixel, but it definitely gets rolled out across all the banners, which is pretty neat. Also, since this demo, I've set up a way to have global styles as well. If you have a certain element that you want to apply a particular style of animation to or a particular way of handling it, you do get global classes that you can use. There's a globals file you can just write your own custom CSS in; it won't get overridden when you rerun the tool.
Each banner itself also now has a custom CSS file where you can write overrides effectively, and those overrides will not be overridden when you rerun the tool to get new assets or new data. That's the most powerful thing: you can just keep running this tool all day. If the design team just made two hours' worth of changes, as a developer, I can just rerun that tool that you saw originally, and all those updates—the positioning, the sizing, the assets—they all just get re-rendered into my codebase. That just keeps re-rendering it and ignores anything extra that I've added.
Again, that loop is now zero; there is no distance between these two things. This is the exact opposite approach of what I was saying we should be doing before. We're just treating the codebase as a source of truth. In some ways, it is; there is a structure to this project that exists, and all we're really doing is filling in the gaps. But at the same time, the design tool is the source of truth for the visual styling of it, so the designers can actually make a lot of changes in there where they're most comfortable doing it, and it does make sense for a banner campaign.
This is the last step I want to show, which I'm still thrilled about. You can run a zip script, which effectively takes all my compiled banners, and what it's doing right now is it's running a headless browser in the background, and it's taking screenshots of each banner. It's using the banner HTML as a source of truth, and instead of having a designer go through and save out static backups, right now it's literally spinning out browsers, screenshotting the end frames, saving them as a backup file, and at the end, it'll just zip all of them up.
There's a double-click ready, so you can just upload them straight into DoubleClick. You know, anybody can do that; it's not developer-specific. You'll see in a second these are all my zip files it's just created, so they're good to go to drag and drop. If I unpack one of these things, you'll see all the compiled code. I don't know if I actually opened it, but it's all compiled; it's all minified, all optimized, and that backup image is rendered automatically.
This is a rendered version of what you see in the browser, so it's an actual one-to-one fallback that is always up to date. You don't have to get the designs to re-save these out, and the images here have all been optimized. It does a really good job of optimizing for some tools in the build script that do that. I don't know if you can see that sizing, but it's 25 kilobytes for that whole folder of images, which is super good considering a lot of banners often have very strict file size limits.
That's basically it for that demo. As I said, without all that sort of walkthrough, I was giving this as a talk to my developer team as well as the design team, so that's why I was kind of walking through all their steps, which hopefully you got some benefit out of. If we just decided to run this tool, accept all the smart defaults, we literally get production-ready zips of any size banner campaign. If it's like a couple of dozen, we can get a production-ready build folder in 60 seconds to go straight to DoubleClick, which is nuts.
Four more of these have been done since that build; this was over a month ago, so we've done four more successfully. Basically, that's saved us five extra days at least of developers' time, and that we've got paid in dividends from this tool, which is so good. This kind of just reinforces that repeatable tasks should actually get faster and cheaper over time. I've noticed the opposite trend, where things like websites—like we should be really good at websites now—but they tend to get much more expensive over time rather than having efficiencies along the way and being able to reuse those.
The reason for this is very intentional. I really like this quote from Ricardo Semler in the 1994 book "Maverick." He wrote a revised intro in like 1999, and this quote was in it: "We've all learned how to go on a Sunday night to email and work from home. Very few of us have learned how to go to the movies on a Monday afternoon." This is literally my goal for the team. I want to be going to the movies during the week all the time. If we can just put this banner generator on and go to the movies in the afternoon, that's pretty neat. I hope to see you all there if you follow the same trend.
This is basically the app your agency needs, but not the one it deserves. However, I am going to be releasing this as an application, so I've got a landing page up there right now. It's some sort of candy-themed page at the moment. I built it in like two hours just in HTML; I didn't obviously use any design tools to do it. But anyway, you can go there right now, and it actually now supports animations and timelines specified directly in Figma. I'm leveraging the prototyping tools from Figma, so you know where you can click on a frame, drag an arrow to another frame. In my code, that now interprets it as a link between banners, so I can have multi-step banners or timelines in banners using the native functionality of Figma.
I can specify the delay in that native text box and get the information back from the API when the animation is a weird one. I thought a little bit about this and haven't really thought about it much since, but the temporary workaround is to use some sort of pipe symbol naming convention for your layers. You can call the layers whatever you want—CTA button, whatever you want to call it—pipe symbol animation name that we have built into our banner generator. We have a library of predefined animations: pipe symbol animation name, pipe symbol speed, pipe symbol delay, pipe symbol ease. If you want those extra options, you can do that, and that will inform my code to use some specific animation styles.
You can go there right now; it's a figmatic.com. You can't download it yet because I would like to make it a little bit nicer. I do subscribe to Reid Hoffman's theory from LinkedIn that if you're not embarrassed by your first product, you've probably shipped it too late. But I'm not quite embarrassed yet, so I need to make it a little bit worse before I ship it.
There's just one more thing before we wrap up, and that's that it now also builds some EDMs. I haven't even shown my team this yet; I literally finished this yesterday at home. I was like crying in the corner, wondering why I had to build EDMs the way that I always do. If you saw my first-ever talk, it was literally called "Building EDMs Seventy Times Faster with Reverse Science Fiction and Kanye West." I kind of took you through the timeline of when I first started at Tundra. EDMs were taking 20 hours to build, and by the time I built a custom tool, you can watch the video that I built. We got them down to ten minutes, so we could build ten-minute EDM production EDMs in ten minutes. But it's still too long, so I decided to apply this technique.
Yeah, I'll be unveiling it for the first time right now. This is a five-minute screen cap of it in action. This is me using it yesterday for the first time successfully. This is an EDM—typical Nike EDM that we work on. It's just in Figma; it's pretty stock standard, which is great because we do a heck of a lot of them. I'm just in my terminal, so I've written some scripts just using Node, the same thing I was writing to make that banner magic happen.
Keep an eye on these image folders and the pages folder; they're about to be populated in a second. This is doing the same thing. There's no fancy UI, but it's hitting the Figma API, identifying all the components in that EDM, mapping them back to my codebase, and also exporting all the images as well. You can see here it's downloaded all the images for me straight from Figma. I didn't have to go in there and slice them all up, and you can see here this code has not been written by me. This was just generated a second ago straight from the Figma file.
All the data is being pulled straight from Figma, so that's pretty neat. Obviously, it's responsive because that's just the way we build our emails. You can see it's handling this whole component. It knows that it should be splitting into two if there's two in a row to split into two. You could send this; this is good to go. But I wanted to know how it would solve the problem that we inevitably face, like with the banners—the feedback process again—very, very, very difficult.
I'm going to make three changes to this EDM in Figma, and I'm going to show you what happens. For some reason, I might get some feedback that this is actually not being sent to this particular store. I'm just going to change it to a different store, so I'm going to change it to Nike Melbourne Central instead of Newmarket. We've also decided we don't like this gray background, so instead, I'm going to go rogue and make it much worse by changing it to the color of this product up here—make it an orange background.
This is a little bit of flashback humor, actually. This is the first lines of the verse that I was just rapping before on stage. This is a Tribe Called Quest, "The Low End Theory." I've decided I want the conversion rate of this email to be through the roof, so I'm just going to drop those five dog lines in there. Rest in peace, Phife Dawg.
What happens is I'm just going to literally rerun the script with my browser open. It's already in dev mode, so it's watching out the changes, and because this is going to rewrite that HTML for me once it regenerates that file, you should see immediately those changes appear. It's just taking that data, rewriting the file, and now I have my text that I just changed. I've got my new background color, which looks terrible, and the winner of the email, which is the intro that's going to sell out of this new product.
Yes, I think that's it. I'm just doing a comparison, so as you can see, it's a one-for-one copy of the email. Good lord, I just keep happening. Okay, that's good. Yes, this is it; it's all working. This is the very first version of it. It's not going to be this kind of primitive as we go forward. I'll be integrating it into my UI and making some sort of interface to handle whichever task you want to do—banners, emails, campaign pages—are probably next on my hit list, short-lived ones.
That means we can focus our time on important problems and work on our design systems and whatnot instead of worrying about how to build banners and EDMs and other solved problems like that. As I said, in 2015, this was a 20-hour task. Quite literally, I still don't know why it took that long. In 2017, a tool let us do it in ten minutes, and as of today, we can build them in five seconds using this tool. It's quite a nice little jump and sort of time metric change as well.
I can only show you the door; you're the one who has to walk through it. Everything I've shown you tonight is available to you. I'm not like some person with special access to these tools; you can use Figma for free. This API is available if you want to use it tomorrow. All those tools, they're all available, so you just have to try it and actually do it.
What I recommend is signing up for those new apps, checking them out, getting on the beta lists, getting the invites, you know, the adopter. Try it out, see how it goes, do some research, and share those new links with your team. You want to educate people so they're aware that these things are happening rather than dropping it on them 12 months from now, and you sound like a maniac like I do all the time. Work with your cool developers to build stuff—not the ones who don't care about design, but the ones who really get this stuff.
I'd also try and understand some of the code as well. Just try and learn a little bit, as I guess my kind of touched on before. Certain aspects of it are very helpful to learn and experiment together with your developer. If you're a designer, get your developers and just experiment together and think of things that you can do and work on them together. You can obviously do them; anything is basically possible.
I just want to leave you with this one last quote, also from "Atlas Shrugged": "Do not let your fire go out, spark by irreplaceable spark in the hopeless swamps of the not-quite, the not-yet, and then not at all. Do not let the hero in your soul perish in lonely frustration. For the life you deserve and have never been able to reach, the world you desire can be won. It exists; it is real; it is possible; it's yours." Thank you.