Transcript
My talk is called building a startup, and I added in brackets "in a pandemic" just based on the last couple of weeks. As chance would have it, for the last decade, I worked in digital agencies as a designer and a developer. I started out as a designer-developer and then doubled down on development once I realized I was actually spending more time in code and in the browser designing things. That's kind of what led to that change.
For the last three months, I've been building a startup called Figmatic full-time, and I'm just going to talk about that for a little bit. We build premium Figma plugins that are designed to replace people in your design team. You can check out the website later; I'm not going to go too far into it.
First things to note from the first few months are the cool things: having no managers, no meetings, and no agile. Magically removing these things has made work fun and productive once again. That's been really neat. Before I kickstart a little bit, I'm just going to rewind 12 months really briefly. Twelve months ago, I discovered life after the red pill. As John mentioned, I was co-running the Design Ops Meetup for the first year, and then I decided to leave and focus on other things. There was certainly a void left after I walked away, which opened me up to probably a four to six-week period of shutting myself off from everybody, being very introspective, and thinking about what I wanted to do next.
This question I come back to very often over the last six or seven years is from a book called Zero to One. The question is: what important truth do very few people agree with you on? I have a few answers for this, but the one I want to touch on at the moment is that I believe we've been living through design and development workflow stagnation for roughly the last 20 years. I'm just going to give a little bit of context around my thinking on this, hopefully not going too deep with it, but I think you'll see where I'm coming from at least. By definition, most of you should disagree with me on this important truth that I believe.
It wouldn't be a talk unless I quoted something from The Fountainhead: "The hardest thing to explain is the glaringly evident, which everybody has decided not to see." This is kind of the way my mind works when I'm talking about this topic because it seems like everyone has blinders on, and no one really wants to think about the hard questions or look at where we're at compared to where we've come from.
To start off from 20 years ago, this is a quote taken from an article I posted from John Allsopp, the founder of Web Directions, called "The Dao of Web Design." It was posted almost exactly 20 years ago this week. He said, "It's time to move on to embrace the web as its own medium. It's time to throw out the rituals of the printed page and to engage the medium of the web in its own nature." He wrote this 20 years ago, and if you told me it was written last week, I would still think that it's a new article. That signifies that we haven't really gotten past that sort of print idea just yet.
Ten years later, almost ten years ago exactly, the famous responsive web design article came out. He wrote, "This is our way forward. Rather than tailoring disconnected designs to each and every increasing number of web devices, we can treat them as facets of the same experience." That was ten years ago. We had twenty years then, ten years, but today, ten years later, we still use the term responsive web design instead of it just becoming absorbed into the term web design. To me, this seems as if we talk about it as if it were both new and optional, none of which are true. Somewhat hypocritically, we also at the exact same time use these other terms for arbitrary fixed sizes that aren't responsive, like desktop, tablet, and mobile. If you've looked in a design file in the last year, you've probably seen layers and frames named with these terms.
Again, to extend on that, the language we use around design and development is very telling. We've got words like handoff designs, slicing up designs, inspecting designs, bridging the gap between design and development, and pixel perfect. These are all kind of tells that something is a little bit off. To keep going down the rabbit hole a little bit, you've got terms like Design Thinking, which in and of itself is fine, but these terms distract us from the need to actually think about design at all. The speed of new articles and tweets we see each day also fools us into believing the propaganda that things are just moving quickly; we can't keep up with all the radical progress. It's hard to even keep up to date, and things are just progressing at this rapid rate that we can barely stay on top of.
Not having a go at this specific trend, but just things like new UI trends like neomorphism give the illusion that there is a new future on the horizon simply by covering our dated present with a fresh coat of paint. The reality, as Mark was sort of touching on, is that many people think a design system just means a tidy sketch file, which is by definition always outdated, containing pictures that emulate parts of a website. The reality is that our designs are made with tools that have no relationship at all to the medium that they're actually being used in by real people.
This, to me, is perhaps the most telling fact of the complete breakdown of our design and development workflow: every design portfolio I looked at when I was at my last agency never included the links to the websites that they actually designed. That means something has really gone wrong. If nobody wants to show the URL of the thing that they actually designed, then something has really gone wrong along the way. To me, that's a sort of a tell that we've really messed up.
If you've attended this meetup before, you'll know that the tagline and mission of it is that we believe the distance between design and development should be zero. I'll probably get into that a little bit, but I think Mark kind of already alluded to this in his talk. To be clear, I'm excluding Mark from any of this criticism; he's one of the few people actually thinking about this and trying to get us to a new future that looks radically different from today.
To be more concise and more related to the business I'm starting, I believe that anything that exists inside of a screen design tool is always more valuable outside of it. You could take the next step and say production code and data is actually the source of truth for your designs. Never in history will a user of your website be looking inside of your Sketch file or your Figma document. There's just no relationship between the customer.
This is really what design ops was meant to be. The term kind of got hijacked. If you read about what design ops is, there's a lot of propaganda out there about how it's more about management and overseeing design and development teams, making sure that the information flow and the handoff processes are all going according to plan. In our future, in the design ops future that Chan and I defined, this role that people say design ops is actually irrelevant. It's actually removed completely when the distance between design and development is zero. There is no longer anything to manage, so that role is non-existent. It's actually the opposite of what we defined it to be.
I'm just going to briefly touch on the tipping point for me personally. A few months after I finished co-running design ops at work, I was working on a design system for the better part of a year for a very big e-commerce platform. I had done the entire thing in code. I had built everything in code, all the low-level stuff right up to the full views and states and everything that Mark outlined. I held on; I pushed back against this for four months. People were trying to hijack the ideas and all that sort of stuff. I got to about a month before the project ended, and for some reason, we had to send the client static JPEGs or images. I said that's ridiculous; we've got this live link here where they can look at it on anything and see the real thing. No, we just had to do it.
Long story short, one afternoon, I spent four hours screenshotting every view in every state of every page in Chrome and put it into an InVision link to share with the client. We went in there the next week to meet with them to present these designs, and they said, "All right, these are looking really good, but we would love to get the Sketch files so we can hand it over to our developers in the Philippines and get them to build it." I said, "No, you don't understand; these are JPEGs, but I actually took them from the HTML that I already built." He said, "Yeah, we just need the Sketch files." I was like, "Oh my god," and it turned into a mess.
Long story short, none of the HTML was used, and we had to actually use the—I had thankfully already set up the HTML to Sketch extension, so I rendered all the components out to Sketch files and just sent them that. That's kind of what we did. This was really the tipping point for me where I realized I had lost the Design Ops war even in my own workplace.
You can probably tell by now that I believe it's time to really start getting back to the future. The question I asked myself was again from the book Zero to One: how can you achieve your ten-year plan in the next six months? I like these questions because they force you to reframe it in a completely different way than you would usually want to answer it. What do I want to be doing? I want to be building design automation tools full-time and be profitable doing it. The answer to that question was the way for me to do it was I really needed to put some skin in the game, quit my job, and start my own company. This was the only answer I could come up with in order to at least have a shot at getting to where I wanted to be.
The reality looks like going from an early developer's salary back down to zero. We did a few things to counterbalance this after I decided to do this. I gave four months' notice because I wanted to have a really smooth transition between me and my replacement and leave the agency in a better place than I found it. I also wanted to build up a bit more savings, so I saved up for those four months. I moved to a less expensive apartment, sold my car because I realized I wouldn't be leaving the house for the foreseeable future. You guys who have been quarantined for the last two weeks, I've been self-quarantined for the last three months of my own choice. I also sold a lot of my childhood Nintendo 64 and Super Nintendo games and my Nikes, just cutting down expenses everywhere else.
I've never started a company before, but I do know that having any plan is probably better than having no plan at all. Here's a rough outline of what I kind of planned out. The five things I thought I was going to do were: number one, do not compete; charge from day one; ship fast and often; talk to customers; and do things that don't scale. This advice is probably common, but I decided to actually follow it.
Going from zero to one really just means that I'm not going to be doing things like building the tenth Figma plugin or the fifth spell-checking Figma plugin. I want to build things that currently don't exist that would be valuable to exist in the future. I've built five Figma plugins so far. One is what I built to learn how to build Figma plugins at least at a base level. This one literally exports production-ready favicon packages for progressive web apps and websites from Figma. The next one handles image compression. There's no image compression in Figma, which is strange, so this compresses JPEGs, PNGs, and SVGs directly from Figma. I actually just got PDF compression working today, so I'll be shipping that shortly.
Bannerify was a Figma plugin I built to animate and export production-ready banners from Figma to HTML. It supports all the ad networks, vanilla HTML, and it will export 100 of them in like five seconds. Pixelay is one where you can overlay your Figma designs on top of your real development build, so you can actually get a sense of how they line up. Then we've got Crypto, which is a new one I've just built as well. This is almost a strategic Figma plugin in some sense because I've been talking to a lot of people who aren't on the Figma train yet, and the feature they're requesting is they need to have password protection on their designs. Figma sort of does this, but not the way they want; they just want a password-protected thing, so I built that and am releasing it soon.
As I said, charging from day one means plans to make cream cash rules everything around me, validating real value quickly by charging for products. It's common advice to say release everything for free; just give it away for free, build up recognition, and you can charge later. I decided to do the opposite and charge from day one. There is a trial period, but once you've exceeded that, you do have to buy a license. I found this is actually a really good way of figuring out how valuable something actually is.
The other thing I really wanted to do was not fall into the trap of just building things for months on end, hiding away in the corner, not showing anybody, and not knowing if anyone actually wants the thing I think is going to solve a problem. I just get it out there while I'm still embarrassed with the product. I've been building very quickly, and the way I've been able to do that is by using components. I use that on a Figma plugin level when I design my components, and at my website level, it's all component-based. I ship probably at least a couple of times a day either to my website or to the Figma plugins I've got up online.
The weird thing is I actually don't use Figma for designing my websites or Figma plugins at all. I've never designed anything in Figma. I design everything in code. Everything that I've designed for my website and my Figma plugins is all in code, with components. It's extremely quick. I've actually redesigned the website like three times, and it took me a couple of hours every time to completely redesign it because it's fundamentally built to be very adaptable. That's a pro tip: if you take anything away from this talk, it's that designing with code works. Not only does it work, but it's actually faster than drawing pictures of websites inside tools, and you get the benefit of having real content, which is a big one.
Talking to customers has been great because I get super good feedback, and they actually help me develop new ideas. I can build relationships with them, check in, and get some ideas of what's broken at their company. It also helps convert customers into paying customers really effectively.
Then I did things that don't scale. I've got five things in here. Things that don't scale: number one would be extreme customer service. If someone messages me on chat or email, I'll reply to them within a minute. They'll usually have a feature request or a question, and my reply to their feature request will be that the feature request has been deployed. I'll get feedback like, "Whoa, your team is so amazing!" I'll sort of go back and forth on the answer of either telling them it's just me in my kitchen or making them think we have some sort of massive enterprise running.
Things that don't scale: number two, manually cold emailing over a hundred agencies and offering to pay them to talk with me. Obviously, this doesn't scale over time, but upfront, it's a good way to talk to people who might want your product. I've met and talked to a bunch of them, and none of them have wanted me to pay them.
Number three would be just manually posting, linking, and commenting everywhere possible online to blitzscale these initial product launches and get a little bit of a growth curve starting at the beginning. The other thing that probably doesn't scale is that I've been averaging about one to two new Figma plugins per month, developing them over time. That'll probably slow down because I'm going to be working on more complex products over time. The last one would be working 10 to 12 hours a day every day on this business. That may or may not scale; we'll see how the mental breakdown situation goes later, but for now, it's going well.
If you're thinking this all sounds incredible, I would probably just say that building a startup might not be the right choice for everybody. There are certainly easier ways to make money, and those are fairly obvious. Consulting would be one. I've turned down a bunch of consulting offers. You can very easily, as a developer, make over a thousand dollars a day consulting. I've been turning those down because the time cost is too high for me to be away from working on the business. Just consider that if you are thinking about starting a company; there are probably other ways to do it if you only want to make money.
To put that in perspective, my current income is roughly less than five percent of what it was back when I was getting a salary. That'll obviously grow over time, but that's why I needed that to self-fund and have that cushion to start with in order to last.
To make this somewhat relevant to the title, I thought I should probably answer the question of whether there are any advantages to building a startup during a pandemic and impending recession that will obviously be happening in the next quarter. I came up with a few. One would be there's definitely less competition. Fewer people will be inclined to start new companies, and old companies will not survive. Overall, there is actually less competition.
In the case of COVID-19, there will be more remote workers, which means an uptick in Figma usage, considering the options for collaborative design tools are very slim, and Figma is by far the best one. That may or may not lead to more use of my products. I would say that in these times, less waste and stove companies should be tolerated. People will be wanting to find ways to save time, save money, and improve efficiencies inside the workplace, and that's kind of what my Figma plugins are all about.
A more personal one would be that it's just an outlet for me to focus. It's been great to not get too distracted by all the news and all that sort of stuff over the last few weeks. I just keep the routine going and keep the blinders on with working on my projects or my products.
To sum up, if you're thinking, "Well, you're talking about all these futuristic things, but at the moment, you're not doing anything too crazy," the reason for that is I have a list of things that I want to automate specifically in digital agencies. I have a list of those things—about ten of them—so I'm about halfway there. I want to automate all those things first, get those done, which is good because they don't take as long. Hopefully, I can get some revenue to keep the business going, and then that'll free up my time to focus on the new tools that we need today that I hope will exist in the future, either from me or from others.
That's it. I hope that's been somewhat interesting. As I said, it was kind of a pivoted lightning talk update, and I tried to add a few more points in there. If you want to learn more, you can just jump on my website, which is figmatic.com, and there are details about some of the things I'm doing on there. Thank you.