Chatting with Tim Van Damme, Head of Design at Abstract
We are Central, a design team that creates new digital products and improves existing ones. Every month, we organize Umami Talks: live interviews with professionals from the product design world. So far, we’ve interviewed start-up founders, product managers, developers and designers. Our goal is to get product design aficionados together to exchange ideas.
This article is a slightly shortened version of the chat we had with Tim. If you’d like to watch the whole interview, there’s a video of it at the bottom of this page.
Tim has had a pretty impressive career path. He left Belgium 6 years ago to join the design team at Gowalla in Austin. He then went on to Instagram and Dropbox in San Francisco. Now, he’s Head of Design at Abstract: a new app that will hopefully change the way web professionals collaborate.
It’s a pleasure to have you Tim. Could you tell us a bit about yourself? What are you doing these days?
These days I’m a product designer, a community manager, a product managing person... The life of a designer in a small start-up is that you have to do whatever needs to be done. The first thing we do when we come into the office is to open Intercom, look at all the new support requests that have come in and start replying, trying to help people, trying to figure out if they’re experiencing a bug or a human error. That’s most of our mornings. Besides that, we’re also actively building the product: fixing things, adding new features, trying to get the word out. We’ll do our public launch later this year so we’re preparing blog posts and interviews with some of our testers.
In one line, what is Abstract?
Abstract is a tool that allows the proper versioning of design files.
For those who may not know, what is versioning or version control?
Version control is typically based on Git. Instead of just duplicating files and everyone working separately, you create your own workspace from this ‘source of truth,’ this master set of files, and you apply changes to it. Once the changes have been approved, you bring the changes back into the master files. The cool thing is that there can be an infinite amount of people working in an infinite amount of workspaces. Because you only track the changes, it’s usually pretty easy to merge the modified files with the master files.
In Abstract, you use development terms like branch, commit and merge. Can you explain some of these terms?
A branch is a workspace. It’s a virtual duplication of the main folder where you can do whatever you want. You make your changes and when you’re done, you can delete that branch or merge it back into the master files. Or you can create yet another branch off of it. So, a branch is where you work.
The way you work is by creating commits. You create a commit whenever you feel like you’ve done something you can say something about. A commit is a snapshot of the work you’re doing. If you wanted to update button styles on a screen, you’d go into Abstract if you’re a designer, or Git if you’re an engineer, and write ‘I’ve updated all the button styles on this screen.’ From that moment on, you can go back to that point and open the files at the state they were in when you made the commit. So the idea is that you do multiple commits on a branch until you’re ready to reach out to your team for feedback. They’ll give you feedback, you’ll make changes (which means more commits), and at some point you’ll get approval to merge your work with the master files. Approval might come from your manager, from a coworker, or, if you’re working alone, it might come from you. When you merge, you take all the things that have changed and apply them to the master files.
What are the benefits of all this?
You create this very rich history of why screens look the way they do. Right now, you’d need to go to the original designers of the work and ask them why this screen looks the way it does. Design lives inside the minds of people. Maybe that designer already left the company. That’s why history-building is so important. It allows you to go back in time and see how a certain icon came to be. With Abstract, you can see all the commits that happened, you can read the comments, and the feedback that was given on the work.
Was it a conscious choice to keep the terminology developers use?
Originally the team was split in half as to whether we should keep the Git terminology or do something new. For a long time, I myself was gravitating towards doing something new. People don’t know what commits and branches are. But then Kevin, our CTO, brought up the fact that in the coming years designers and developers will work together more and more. So both parties need to be speaking the same language.
But we did simplify a bunch of things. Instead of manually pushing and pulling, we automatically push commits to the server. That means that when someone else makes a commit, it automatically gets pulled down so you’re always looking at the most recent version of the design work.
Now you’re in an Alpha version. What’s the feedback been like so far?
It’s been very positive. Obviously we can’t win them all. Some teams are in the middle of a big project and they don’t want to be distracted by adopting a new tool. Other people don’t immediately get the Git workflow. We’re working on doing a better job of explaining how that works.
We’ve also heard from freelancers who have given their clients the ability to look at their work while it’s in progress and give their feedback on it. But the biggest positive results we’ve seen are for big product teams with multiple people working on the same files. They can now collaborate in a structured way without walking on each other’s toes or having duplicates of files. They just go into the app and they instantly see what everyone is working on, which is fun because it’s new. It shouldn’t be new because engineers have been doing this for over a decade. But for designers, it’s completely new.
Why did it take so long to create a collaborative tool specifically for designers?
It took a while for all the technologies we needed to line up. We use libgit, which is the same thing that GitHub uses, to do the Git part of it. The Sketch file format just got a lot simpler (but it was already pretty easy to parse and translate into something versionable).
Abstract is a web app running in Electron (an open source framework maintained by the people at GitHub who used it to build their code editor called Atom). So it’s all web views, running inside this native wrapper that gives you access to the file system. What that means is that we didn’t have to look for 6 really talented Mac engineers, which is pretty much impossible to find. Instead, we’re using a technology that has been tested and tried over the past decade. Someone with a basic understanding of front-end code can jump in and do meaningful work in there. That allowed us to speed up the entire process. But it still took us a year to get to where we are now.
So it’s been a year now. How did it all start?
Before it officially started, Kevin (our CTO) did a bunch of work on Sketch plug-ins. By doing that, he got a really good understanding of how Sketch works. So one day, he looked at the Sketch file format and noticed that it was pretty much code. Being an engineer, he was like ‘Well, I have a Sketch file which is code, and then I have Git. What if we merged them?’ So he built this really rough proof of concept. It was a native Mac app combined with 2 or 3 other apps.
I still remember, he had an orange button on an artboard and he created 2 branches. On one branch he made the button green, and on the other branch he gave the button a drop-shadow. And he said ‘Now I’m gonna merge them!’ and I was like ‘That’s not gonna work.’ But he merged them. It was the new color with the shadow and it was still a Sketch file he could open.
That blew my mind and I quit my job at Dropbox the next day.
From there, we knew it was technically possible to do versioning for design files. It took us a year or a year and a half to figure out the right flow to do this. No one had ever done it at this level before. I think LayerVault had done versioning with Photoshop files which basically means that every time you’d save, they’d upload the entire version to their servers. And then there were a couple of other similar services. But this is brand new, which makes it hard to build because there isn’t a lot of inspiration out there.
On the UI side, we built 3 prototypes. We do a lot of talking with users and different types of teams so we can build something that a lot of different teams can use. But even with all that data, our first prototype was still really rough. We learned from that, we didn’t throw it away. We just put it aside and built a second version which was slightly better. We kept testing with people and it still didn’t feel like it was something we could ship and expect a lot of adoption. It was only when we built the third prototype that we had this feeling it had the potential to be shipped. That’s the version we’ve been working on for the past 9 months now. And it’s the version we’re going to ship publicly later this year.
Do you know when you’ll publicly release Abstract?
No, I could make something up but it would probably be wrong. We’re in private Alpha right now, still gathering a lot of feedback and working on performance, adding some big and small features. The next step is probably going to be a public Beta where people can sign up. But it’s still going to have a little Beta sign meaning ‘Use at your own risk.’ You won’t lose any work but bugs may happen. And then hopefully sometime this year we’ll do a public launch and then we’ll start charging. Maybe we’ll charge already in Beta, I don’t know. We’ll see.
In your career, it seems you’re always at the right place at the right time. Could you share your story?
I’ve always been a big fan of American design. Six years ago, the most consistent design work was coming from the U.S. I’m not saying the best design work came from there but it was consistent. And there were big design teams with many well-known names. I dreamt of working in the U.S. for a bit. So I reached out to Gowalla. We did a 2-week tryout, just contract-based. I redesigned their website while I was at their office in Austin and they gave me a job offer. At that point I was like ‘Alright, I need to get a visa, and I need to get married so my girlfriend can move with me.’ And I think from that point on, that ball has not stopped rolling.
I joined Gowalla a year later, full-time. I spent 12 months there and basically the company ran out of money. There was a big fight between Foursquare and Gowalla. In the end, years later, Foursquare won. But Gowalla ran out of money so they were looking for companies to acquire them. Facebook came along and they had job offers for about 6 out of 36 people. Not me. I think it was because I was very vocal about not liking Facebook. And I was also very inexperienced back then. Problem was, my wife was 8 months pregnant. In the U.S., if you don’t have health insurance, which you get from the company you work for (otherwise you pay $1000 a month for it), giving birth can be anywhere from $25,000 to $75,000. So I needed a job. What I did at that point was: I looked at my phone and tried to figure out which apps I enjoyed using and where I thought there was an opportunity to help with design.
Instagram wasn’t looking for a designer because they were growing so fast they didn’t have the time to put together a job description. I just picked them. The founder was following me on Twitter and I sent him a DM saying ‘Hey, I’m in Austin. I’m Belgian and I have a work visa. Do you need a designer? I’m a big fan of the product.’ And they were like ‘Yeah!’ So I spoke on the phone with the founder, I spoke on the phone with the co-founder and then maybe the Head of Engineering and they sent me a PDF which I e-signed and I started working for them. That was a couple of days after our first daughter was born.
Later, I flew over to San Francisco to actually meet the team and I went on a weekend with some ex-Gowalla people. At the end of the weekend, we were driving back to San Francisco and I was like ‘I don’t like San Francisco. I wanna move back to Austin and back to Belgium at some point.’ Then I got a phone call from the Instagram founder saying ‘Can you come in tomorrow at 8am?’ And I thought ‘This is San Francisco, no one comes into the office at 8 in the morning.’ I thought they were going to fire me. So I get there super early and the entire team was there. I was like ‘Cool, they’re not gonna fire me.’ He called everyone around. We were a team of about 12 or 13 people. He was like ‘Alright, we’ve had tremendous growth in the past few months, it’s all been great... We’re being acquired by Facebook for a billion dollars.’ That was a crazy day.
The acquisition was made official 6 months later. I was still working for Instagram but legally I was employed by Facebook for 9 months. It was a dream job. The pay was phenomenal, I had a ton of stock in the company and our team got support from Facebook. They would come in saying ‘We can help you with performance and this and that’ and we would help them with photo-related issues. It was great. But the design team was still growing and I wasn’t confident that I could help it grow. I didn’t have the experience to do that. So I made the tough decision to leave Instagram.
I started working for Dropbox, a company which I knew had a very talented design team: a large set of designers whom I could learn from. If you’re working in a small team it’s hard to learn new things. At a bigger company, you have the luxury to take some time to learn. You work with people who know more than you do. Just by working with them, you pick up a ton of stuff. Looking back at it, I would make the same decision in an instant. I spent 2 and a half years learning about building products at scale, hiring people, and just working with others. And then Kevin gave me a demo and I was like:
‘Fuck it, here we go again.’
With all that experience, what advice would you give to people working in product design?
When I left Instagram, when I made that tough call, I saw a bunch of people stay for the money. I understand because it was a lot of money. But they didn’t grow for a couple of years, which in the end made it hard for some of them to find new jobs outside that company.
In this industry, whether you’re an engineer, a designer or a manager, you need to be learning every single day.
New technologies are coming out every day, new work flows are coming out every day. If you don’t educate yourself, you won’t be able to find a job in a few years.
There’s one more question we usually ask our speakers: Why do you do what you do?
I enjoy creating products. I enjoy creating things that I know people will use, whether it’s for entertainment or for productivity. Things that will hopefully make people’s lives nicer. But not in some bullshit way. I’ve worked on social products. I don’t think I would do that again because you basically design something to grab people’s attention and then you sell that attention. I don’t like that. But I like building products like Dropbox. Someone stores photos on this and they can go back through years of history and then maybe stumble upon a photo they had forgotten about. For them, that’s worth paying for, which makes me feel good. It makes me happy to be a part of that.
I like playing with new tools, I like following up on new technologies, I like interacting with the people in that space. There are a lot of really smart people, way smarter than I will ever be, and they’re just fun to work with. There are some assholes too, obviously. But the whole community is very open. There’s always someone available to help, which I guess is my hook to this type of work. But in the end, I want to feed my family. I’m pretty good at drawing rectangles and circles, so I guess that’s how I’ll feed them.
