About Tim Van Damme
People often think of design as 'making things look nice,' but in reality, some of the most brilliant parts of great design go largely unnoticed. A well designed product should be intuitive and easy to use. It should not only look good but feel good too. This can be accomplished through well thought out icons, satisfying animations and workflows that are entirely natural. It's these subtle touches that are the hallmark of a mature designer. The actual 'look' of something is far less important than the way the design helps the user accomplish a goal or task. Tim Van Damme is a master at crafting well thought out, intuitive design. He's designed some of the easiest to use and most recognizable UI's for companies like Gowalla, Instagram and now Dropbox.
Tim hopped on his Soapbox to explain his design philosophy, the way the design team works at Dropbox and what he looks for in members of his team.
Two Key Elements to Great Design
After some explanation of the meaning behind his popular internet moniker, Max Voltar (think videogames), Tim got right into the key elements behind all of his design decisions: content and people.
Content - What all design revolves around. Content comes first. People shouldn't even noticed your design, they should notice the content.
People - Know your audience and design for them.
To help make sure he's designing for people, Tim does what he calls the "mom and dad test," He tries to imagine if his parents would understand his design. Could they use the product? Would they be able to navigate around the app without issue? Would they understand each icon? He also emphasized the need to design with both data and gut instinct. For Tim, it's always advisable to design with the numbers in mind, but when something is entirely new, that data is not available. That's when experience comes in, and designers have to make some judgement calls based on their gut feelings. People don't always know what they need, and they only think they know what they want.
Building Great Teams
We were really interested to learn about how Dropbox organizes their teams and tackle product design. They currently employ around 40 product designers and divide them into smaller teams that work on projects. Twice a week, they meet with other teams solving similar problems to exchange ideas. Each team seems to have a lot of autonomy and are free to find new ways to tackle problems.
When hiring new designers, the team at Dropbox are really concerned with not just the skills they bring to the table, but the kind of person they are. Tim brought out questions they often ask of new candidates - Are they a good person? Can they give and receive good feedback? Are they trustworthy? The reason for this is that they realize that the working relationship is just like every other relationship in life, you need to find trustworthy people that you can communicate well with.
Communication seems to be at the heart of everything they do as a design team. When presented with a big challenge, each design team goes off and tries to find solutions to the problem. They go through several explorations and have many discussions. More often than not, they usually settle on the original proposed solution, but Tim says this "messy" process is essential. It gets people talking to each other.
In addition to great communication skills, Dropbox also looks for people with passion. Tim shared with us how initially, they rarely hired people straight out of school, opting instead to go for people who had experience shipping product. What they found, however, was that people who worked on side projects or school projects often had all the same skills and even more passion. It takes passion and dedication to see a project to completion, especially if you aren't being paid for it. Passionate people are often more open to feedback because they want to learn and improve. Tim said that they'd rather hire someone who is less talented but has a passion for learning, than someone with incredible skills and a bad attitude.
Designing with Purpose
While Tim is known for his innovative designs, icons and patterns, it was refreshing to hear that his goals are to come to the best answer, not necessarily just introduce something new for the sake doing it. For Tim, you can either build a system or reuse a system. If you’re designing a new product, you should reuse as much as possible. If you really need something new, you should take pains to document it thoroughly, explaining your decisions and it uses.
He gave the example of a new feature which blurs the background and displays nine icons similar to a pattern on iOS when you're on phone call. It's a familiar pattern based on a device people use every day. There's no need to reinvent the wheel every time. He also reaffirmed his focus on solving user problems, saving the visual polish for last.
Making things pretty is the easiest part of design. What’s hard is laying things out in a way that makes sense, in a flow that is easy to go through. You can actually ship it at that point.
Our chat with Tim ended with questions from the audience. We want to thank Tim for coming down and sharing his insights with ZURB and the ZURB Soapbox audience!
Transcript
Ryan: All right folks, we're gonna get going here now. Just, first of all I wanna thank everyone for coming out for another edition of ZURB Soapbox, it's great to see you all here. And let's please give a warm welcome to our guest, Tim Van Damme from Dropbox. Tim, thank you so much for being a part of this and . . .
Tim: Thanks for having me.
Ryan: Enduring some of my questions today. But first of all, I gotta ask, cause we talked about this earlier before we get into all the design stuff. Where does your Twitter handle come from? Cause I made the mistake earlier and I called him Max because of it.
Tim: Which is the best. It happens about once a month. It's an old gaming nickname back in the days where you wanted something that sounds cool and tough, especially when you're playing Counter-Strike. So I was a big fan. I'm still a big fan of a band called "The Mars Volta". I've started playing with that.
Ryan: Right.
Tim: And, that's where we ended up here. And the user name is always available. The domain names are all available, kinda stuck with it. When people started calling me Max, I'm like well, there's no way back right now.
Ryan: It's just stuck in my head, you know. Yeah, it's just like mine, Ryan, it's you know, no one has that. It's just not a common name.
Tim: "Ryan Riddle," that's a really good villain name, by the way.
Ryan: I get that a lot actually. But, I wanna start out, before we start getting into talking about Dropbox. I wanna start by getting into your design philosophy and what your approach to design is. What is your general design philosophy and how do you approach design and how do you see your approach influencing the look and feel of the product?
Tim: Okay. Hold on. To me, the most important . . . There're two key things to every design project you're doing, no matter the type of project or the size, whether it's a new product or just a new feature. One, content, that's the most important thing. The things you design, the chrome you design around the content should not get in the way that . . . It should always support the content and, ideally, you don't want people to notice all the work you put into designing it. And then the second key aspect is people. You've to make sure that you know the target audience of whatever you're working on. It's easy for a designer or a team of designers to build something that you wanna use and you have all the context about the specific product so you want to design it in a certain way. It ends up being power-usery. But you should always focus on . . . do the Mom test or the Dad test, whatever. My Dad is an equally good example of that. If they see this, what's their reaction going to be? I try to design that way, so. I had a good discussion with someone on a podcast recently, where it was like, do you design with numbers, the data you get from product research? Or do you design it from your gut? And it's sitting somewhere in between, right? You are, as a trained designer, you have instincts and you know how to solve certain problems. But you should always test that against the numbers. You don't want one or the other win that battle. It needs to be a good . . . It needs to be a healthy fight in between.
Ryan: Right, because data only gets you a part of the way there and instinct can get you the rest of the way there.
Tim: Yes.
Ryan: And vice-versa.
Tim: Yeah, yeah. And if you're working on something new, you can't get perfect data on it. And also people not always know what they need. They know what they want and they'll opinionated about it. But there's a big difference there. If you read "Creativity, Inc" by Ed Catmul, at some point he mentions this constant struggle between all the different teams they have. You have the Writing Department, and they want to make sure the script is just perfect. You have the people focusing on the way hair looks and they want that to be perfect, and everyone wants their team to be the most important team of the project. And again, in the end that's not . . . You don't want one team or one part of the project to win. You want to have . . . Everyone is helping keeping that ball up in the air. And because of the constant struggle between the writers and the people who do the hair and the people who do other things, that's what creates a healthy, balanced product in the end. That's what creates a great movie in the end.
Ryan: And how do you take that into, and I might be just jumping a little ahead here, into a design team dynamic? How does, how does that function? Cause we were talking about, earlier before this, before we started, about how Dropbox is organized. So, could you tell us a little bit of how they are actually organized in terms of, in terms of teams and how does that work to where there is that healthy competition but it's not this over-powering need to be one over the other.
Tim: Okay. So the way the teams are structured is, I think we have about 40 product designers right now. We have groups of two to four designers working on . . . They, they sit with the product teams, they sit, developers with the PMs, with the product people, all that. So those teams are then grouped together in small areas of, not expertise but, the products they work on, they solve similar types of problems. So, day to day, you work with the same one to three other designers and you get fast feedback from them. You just tap them on the shoulder, you don't need meetings for that. But then twice a week we sync up with some other teams that solve similar problems, but those people don't spend eight hours a day looking at the problem that you're trying to solve. And then we have a communication team, we have the Dropbox product team itself, which is a large group, spans a lot of different platforms, so that's a whole org. We have our group of illustrators and they work slightly different. Every team works differently and it's always changing and it's very important for everyone involved to be flexible and to be respectful towards each other. Which brings us to how you do that with a team is by communicating a lot, by trusting the people you work with and by being trustworthy yourself. Through that you can have the healthy discussions you need. They can get heated, that's cool, as long as at the end of the day you respect the people you work with. It's also something we look out for when we're hiring new designers. We will look at the portfolio and the project they've done before and all that, but in the end the most important aspect is are they a good human being? Are they capable of receiving feedback and giving good feedback? Which is a skill of its own, besides being a talented designer.
Ryan: And you brought up something up that was really interesting there about being trustworthy and having trust. You can certainly hire someone who is not a jerk and does all those things in terms of giving good feedback, receiving, and being able to receive feedback. But within those teams, how do you continue to build trust? Because you can begin, there is some trust there but then over Time that has to be built and really to the point where you guys can have those heated debates and still walk away respecting each other.
Tim: Yeah, it takes Time. There are a lot of things that you can force in life, but building up a good relationship is not one of them. You work together for a while and then you get sick of each other, then it gets better. It's like the relationship you have with your wife or husband or whatever.
Ryan: It really is like a secondary family, right? There's the mini-battles and then there's the huge battles and then there's the alliances and all that. I do want to go back to speaking a little bit more about the team structuring, and you talked about teams that solve similar problems. Can you give us an example in terms of how that works, in terms of what it is, maybe say what you are working on and what's coming up for Dropbox and how does that dynamic feedback work?
Tim: When we were working on, so I'm in the Mailbox team. I've been there for about a year now, and we were working on something small which was like the sidebar, the source-list, of all the, we call them zones, but your different inboxes, your lists and all that. And we ran into the issue where people had a lot of lists, and we weren't sure how to solve it in a lightweight way. We had this system of like you can heart the list and then it will show up and then you can click more so you can see everything else. And technically, that was a perfectly good solution to that problem. But realistically, people are not going to go through the hassle of liking everything, or whatever. We never really settled on what we wanted as an icon for it. So we worked on another team and they had a similar issue. They also had a source list which could overflow, but you didn't necessarily want to see everything. So they told us what the feedback they got, of how they implemented it. We ended up going with a slightly different solution, so that it's like a smart thing and it overflows at the bottom. But it was inspired by the feedback they gave us. And that was valuable feedback because it came from a real life situation, while we didn't have any real life data on it yet. So, yeah.
Ryan: And you also mentioned something there, because it is . . . Data in itself and storing data and all that can be a complex thing. And obviously, Dropbox could be a complex application, but it doesn't feel like it, right? So, how did you guys make sure that something that can be overwhelmingly bloated, give it that simplicity that a user wants out of that application? Or as I've heard it referred to a read it referred to as zero-complexity. How do you make that seemingly work?
Tim: We stumbled upon this process by accident, I think. So, a lot of people are always joking, we're the Starbucks of designers it's just [inaudible 00:12:14] all that. We actually do work hard, every single one of us. We start this process where a bunch of designers go off in a different direction trying to solve the same problem, and then we get back together and we compare notes like, "What'd you have? What'd you have?" And then, we split off again and we keep doing that a bunch of Times and through that we go through a bunch of really complex explorations. And then all of a sudden, it goes up in complexity and then it just starts falling down. And in the end, most of the Time, we come up with something that we're like why did we spend all this Time exploring this, because what we have right now is just so straight forward. It just makes sense. And it's a messy process and we get into a lot discussion and heated arguments about it like, "Mine is better than this because of this," and like, "No," whatever. But we always seem to find the core elements of it and solve it in a really simple way, at least I hope.
Ryan: And in terms of that, can you take us through that process? Can you give us an example of something that has gone through that process, to make it seem as simple as possible?
Tim: This will be another Mailbox example. What was it? I had a perfect one. Oh, the sheet that comes up when you defer an email. So you can swipe an email and have it come back later. So we have a range of options like make it come back in a couple of hours, tonight, tomorrow, this week and all that. So we had a bunch of complex things that are like how can we . . . Can we do custom snoozes, it's what we call them, how can we get more options in there, and all that? And in the end what we settled for is the design is pretty much based on the screen you see when you're in a phone call on your iPhone. So it's just the same one, we blurred the background, [inaudible 00:14:29] with icons in there. People know what to do with it because they are familiar with that screen. And from a design standpoint it's not the most exciting thing because it is based on a real life example, but for us it makes so much sense. Because when people first saw that screen it wasn't something new. It was built on existing patterns, on the device that they use every single day. And at that point we're like, "Yes, this is the way we need to do it." Instead of going completely custom and giving them millions of options like, "No, let's keep the nine options we have and lay them out in a way that you can interact with it pure on muscle memory, almost."
Ryan: Right, and that's playing on the users' familiarity and users' actual need as opposed to putting in some sort of arbitrary new design that they would have to relearn, which could potentially prevent them from wanting to use the application in the first place.
Tim: Yup.
Ryan: Right? And there's something I read that you'd once said about being a project designer at Dropbox. This is a good segue way to that. You'd said, "It's more about having good taste and recognizing what looks good. At Dropbox we all have different areas of expertise through which we complement each other." And we've touched a little bit on it, but what are those areas of expertise, and how does that play into that simple look and feel of the application?
Tim: We have people that are really, really good at prototyping, but they might not be the best visual designers. We have great visual designers who might not be good with laying out a flow. And we don't see that as weaknesses. We don't expect people to know everything. Instead, very open about it and like, "Hey, I need to prototype something, can you help me out with this?" or "Can you give me some pointers?" or whatever. Or someone else comes up and like, "Oh, I need an icon for this, can you help me with it? Because you've done a bunch of other icons, you know the style. I trust you with this, and I trust that you will do a good job doing that for me." But these people work in different parts of the company. So the cool thing is, you ask them to help you with something, but at the same Time it's a good excuse to catch up on, "Hey, what have you been doing?" "What have you been doing?" So, we're running around all the Time doing our work, helping out others, which gives you a good feeling of satisfaction, as well, if you can help with another project. And it's just a good impromptu meeting to catch up, it's all about building that trust. That is one of the ways you do that.
Ryan: And do you find that, because you talk about having someone strong in prototyping, do you find that helps elevate someone who may be strong in prototyping but not in visual design, having them learn a little bit more about visual design and learn other things so that they can also do that on their own?
Tim: Yeah.
Ryan: Cool.
Tim: That is actually the main reason I joined Dropbox. Because there were a lot of people there who were really good at things that I wasn't good at. And I knew some of them personally and I knew that it would be a great opportunity to learn. To do good work and learn in the process. Just like school, then you get paid to do it.
Ryan: You get to learn from the best of the best. Speaking of product designer at Dropbox, I'm kind of curious to know, because product design is the new term, and we've used it at ZURB, for many years but it is becoming more and more a prevalent term. How does Dropbox define a product designer? What goes into being a Dropbox product designer?
Tim: Someone with experience shipping things. So we like to hire people . . . For the longest Time we didn't hire people straight out of school just because the team wasn't big enough to mentor an inexperienced designer. Then we realized that because we like to hire people who have shipped at least one thing before, because your experience grows a lot when you do that because you see how hard it is to come up with a product, to find a product, prototype it, build it, ship it, maintain it. We realized that people in school go through similar things with hobby projects. So if we interview someone, that's definitely something we look out for. And as soon as we see one or two hobby projects in their portfolio, we know that that person is probably going to be a better hire than someone who doesn't have that. Because they went through all the problems of figuring all these things out that they didn't have to. School didn't ask them, no one was paying them to do it. It was just, they saw a problem and they were passionate enough to solve it for themselves, and hopefully also for other people.
Ryan: Right. And in terms of that, I know other than being a good person, right, which is a really important part of hiring, are there any other . . . Just ship it, be a good person, are there any skills that you guys also look for? Because we hear about like the unicorn that can code, can do this, can do everything. For you is that important, that they can do all the things, or that they be specialized in one thing, or have at least a mixture of that? How does that qualify for you guys?
Tim: We used to try to define this and we came up with this bucket system. We don't use this, it's not perfect, but the idea was you have four buckets for example, and if you're good at four things, you fill those four buckets. If you're extremely good in one or two things, those count for two buckets each and then that's the bar. But that felt, it wasn't perfect and it just didn't feel right to define a person with a system like that. The thinking behind it is still the same, but we try to be more human about it. And again, they need to be passionate about what they do. Because passionate people will be open to learning, they will be open to feedback, they wanna learn how to give good feedback, all that.
Ryan: Right, I think that's a very important part of any hiring, is that aspect to want to learn. If you don't have that, if they think they don't have anything to be taught, then it becomes a wall. I think that can probably almost be more detrimental, right, than just not being a good person.
Tim: Yeah, you wanna hire flexible people. We've also hired some amazingly talented designers that were like that. They thought they knew everything, they thought they were the shit. And we were like, "Well, no", "Well, you might be all that", but that is not something . . . We'd rather hire someone who's a little less talented, but has more potential to grow in the long term. For us, that's the most important thing.
Ryan: Right, I think someone's arrived. "You have reached your destination." Before I throw it over to audience questions here in just a bit, I wanna go a little bit back in Time. Just a tad. Especially to your Time at Instagram, before you joined Dropbox, and you were working on redesigning the camera flow, and you did a video feature from scratch. I wanted to go in . . . Because we have an excellent blog post from Alina about resist the redesign. What is the difference in thinking when you approach redesigning something versus creating a new feature from scratch? What's the thought process there and how do you approach it, how do you tackle that?
Tim: They are slightly similar, in a way. As in, you wanna either build the system or you wanna reuse the system. If you are redesigning something or designing something from scratch, you want that product to scale, you want the people that touch the project after you're gone to just be able to pick it up and then run with it. It's the same as writing clean code, basically. Needs to be a collection of building blocks that then later can be reused. If you are designing a new feature for an existing project, you should try and create as little new blocks as possible. Reuse whatever you have. And if you really, really need something that is not anywhere available, you should be able to almost document it like, "Here's the reason why I'm designing this custom thing and here's how you should use it in the future." And all that, and give the context for that new thing. Because that is a very expensive thing, both for design and for engineering to implement and to maintain. If that new block ends up being reused over and over again, that's a great investment. If that is the only instance of that thing for the rest of the lifeTime of that product, that's expensive. So . . .
Ryan: And in terms of that, because you talk about . . . It's almost like the Mailbox example too as well, using patterns to make it easier for the user in the end. But when you do roll out a new feature like that, that you have documented, how do you actually roll that out to users and get them into the habit of using that new feature the way it was intended? Or that new whatever it is, how you roll that out and ensure that they're able to understand it?
Tim: Depends on the scope of the thing. If its a small thing, we might just roll it out and not really communicate it. If it's something that changes the way a lot of people use the app, we'll try to throw in some education at that point. We call it "Just in Time" education, the thing will pop up when we hope the user needs it. If it's even bigger than that we'll do blog posts and videos and all that. But we try to be helpful but not annoying . . .
Ryan: Right.
Tim: As we roll things out. And also we will roll things out and people will use it in a completely different way than we expected, because we were wrong and we did a bad thing. And we'll take that responsibility and we'll try to fix it in a non-invasive way, in a way that we don't have to relearn things again.
Ryan: Right.
Tim: Designing is not an easy process, and hopefully will never be. It's what makes it so enjoyable.
Speaker: You're right, and it's a learning process, right? It goes back to wanting to be willing to learn . . .
Tim: Yes.
Ryan: And understand. One thing, I have a couple more questions before I throw it out to the audience, because I found some . . . While doing a lot of research on your background, I also found another quote that really stuck out to me and I wanted you to elaborate on it. You'd said, "As a designer, it's your job to pick the best font for the job, not to follow trends." I love that quote, I really love that quote.
Tim: It's an old one.
Ryan: Yeah, I really do a lot of digging.
Tim: I hope that's the farthest you went back because this might get awkward.
Speaker: Well, I went back to your Counter-Strike days. But, what are, in your opinions, the dangers in following design trends? And how do designers just avoid jumping on the next hotness of the bandwagon?
Tim: Yeah, I think it goes back to start with the content of what you're building, whether it's . . . If it's a chat interface, the messages are the most important thing. If it's Email, Emails are the most important thing. If you start with that and spread out from the main content and . . . Everything new you design is to support whatever the main part of the app is. It's easier to avoid design trends. If you start with designing all the chrome and all the buttons, you might tend to lean on existing trends and the things that you see on Dribbble every day. Making things pretty is actually the easiest part of design. You can do it in the end. What's most important is make sure that everything is laid out in a functional way that makes sense in a flow that is easy to go through, all that. Once you have that, you could actually ship it at that point. But then, of course, the really passionate designers go in and put in the extra work to make sure that everything looks good.
Ryan: Right, right. And I think you've made a good point there about it needing to have that function for the user in solving that problem. But although, admittedly, as users we like pretty things. So, you still need the pretty part, right? But, I do enjoy that. So, what I want to do now is I want to throw it out over . . . Thank you so much for answering all my questions and getting into the nitty gritty of how Dropbox design team works. I want to throw it out to all of you to ask any additional questions you might have, and all that good stuff. So, who wants to go first? Yes?
Man 1: You've worked on some really good products in your career, and I really miss Koala.
Tim: I do too.
Man 1: What's your favorite team or product?
Tim: Product or team? Cause those are . . . I've worked on some really shitty things with a lot of awesome people. And I've cranked out some really cool products with a bunch of people I never wanna work with again. It's all different. One of things I'm most proud of was when we did video at Instagram. I think, from the day we were instructed to build video till the day we shipped it to Apple, that was four weeks, which is something I've never seen anywhere else. That whole project, everyone was aligned with the problem we were trying to solve. We all knew what the constraints were, we knew what the Time frame was. We knew the things we wanted to change in the app, because it meant adding at least one button to one of the most important flows in the app. So we all knew how serious it was, and how difficult it was gonna be. And the team just rallied behind it. And, again, four weeks to build a completely new feature like that, I'm still surprised that we were able to pull it off. But to this day, they've re-skinned the flow for iOS 7 and all that, but the main flow is still there. So again, design, the pixels are not the most important thing. We put the buttons in the right place, we made sure that the flow was solid, and that will last years and years. So yeah, it's probably what I'm most proud of, most fortunate to have been part of.
Ryan: Yup. And then Alina.
Man 2: Thanks again for taking the Time. So you said you guys have roughly 40 product designers on the team? With two to three person groups? Aligned with PM and engineering [inaudible 00:31:21] How do you keep everybody aligned? How do you make sure everybody . . . I think that's it.
Tim: We're doing a pretty bad job of that right now. The company has quadrupled in size ever since I joined a little over a year and a half ago. So we, every couple of months, the way we are used to doing things just starts breaking, and we need to try something new, and something new, and something new. And at this point that is one of the things that is breaking. We have a, we call it Picasso, it's a way to upload whatever you are working on, a screenshot to an overall feed of all the designers. And that's a good way of seeing what everyone else is working on. But it's not just that we have 40 people in a team, it's also the offices right now. I think we have six different floors, they're not all full floors, but they are different floors in two different buildings. That makes it even harder to just naturally walk up to someone and look on their screen and see what they're working on. So, we're trying to fix it. We'll see how it goes.
Ryan: Oh, Alina first and then we'll continue, sir.
Alina: So you mentioned that and, definitely agree with that, there are different kinds of designers. If you had to pick one, would you recommend someone focus on their strength and continue learning more about that subject area or that they try to learn other skills and become a more rounded designer?
Tim: Depends on the size of the company. If you have a start-up, hiring designers is extremely expensive, and you want someone who is good overall. If the company grows and grows, you have the luxury of hiring more specialized people. Because you have multiple people, and they're all good at different things. And as we said, if they're good at communicating, they can walk up to each other and ask for help, or learn from each other at that point. Right now, I'd love to hire people who are really good at one or two things and are also willing to learn new skills, but that's in my specific current situation.
Ryan: Yes, sir?
Man 3: Just building off the gentleman's question, in any large organization, there's a lot of great problems to solve. With the context of shipping, what's your thoughts on how do you prioritize which design problems or which problem in general? [Inaudible 00:34:05]
Tim: I call this a North Star. A North Star is probably one of the founders of your company and they have a vision. They have all the context of the company. They know what needs to happen financially. They know what needs to happen to get more users, all of that. And they need to take responsibility of like, "This is what we wanna do." From there you have the specific teams and every team leader, project person, whatever you want to call it, needs to be a smaller North Star for that team. And it is a trust system all the way down and you need to . . . I wanna trust the people I work for to give me a good direction of what to work on. And I want them to trust me to do a good job executing on it. And, of course everyone's free to give feedback, as long as you're polite about it. If you have opinions about the direction the company is going in and they're valid, they're founded on good reasons, you should be heard. And you should be able to slightly change or tweak that. As a designer or as an individual contributor in a company, you don't have all the context, at least not in a big company. So, it's important to trust the people. It's important to trust your North Stars.
Man 3: Thanks.
Ryan: Yes.
Man 4: Slightly unrelated. Have you had a chance to look at the Apple Watch? And if you did, any thoughts on it?
Tim: I played with one for a day, couple weeks ago, to test out an app we were building. It's a beautifully engineered device. But I'm worried that the software is a bit too slow and the battery-life is borderline, not enough to get you through a day. But I'm excited that they sold a ton of them and that there will be a second generation. So it will get better. It's like the first iPhone, pretty much. Even if you look at the design, the way the glass is floating above the screen. And these days iPhones, I don't know, they give it some technical name, it's flushed together in a way. So I'm excited for the Watch to be more like the newer iPhones, get more battery capacity, be faster, not rely on an iPhone to feed them everything. So, personally I'm not going to buy the first gen, but I am excited about the future of it.
Man 5: What app?
Tim: I can't say.
Ryan: That was a good follow up question. He was listening. He could do my job. Another question here, and then we'll go to the back.
Man 6: How are you communicating with developers? Do you have a documentation tool or whatever you call it? How you get your idea from your end into their hands?
Tim: Most of the projects I'm working on . . . I know this is different for other people, but I'm actually sitting with the developers. Especially with Mailbox, we did a bunch of design tweaks for Yosemite, and the people with most context about what is possible and what is not possible on Yosemite are the developers. They were sitting next to me or behind me and as I was designing, they would give me feedback on how feasible it was to build certain things. So that's how we communicate, just, we sit together, we talk all day, and because we do that all the Time we both share a lot of the context of what's being designed and what needs to be built. It also helps a lot with deadlines, and makes sure you don't miss them. Other teams, they have the long dogs, they have their red line files that shows developers how to implement certain assets. I am fortunate enough to work with developers that will have the latest sketch beta, open a file, pull out the things they need, and take it from there. And they'll ask questions when they need it, which is not very often.
Ryan: And yes, sir in the back.
Man 7: So I totally agree with you about [inaudible 00:38:51]. I was curious, though, what was the first problem that you solved with the passion you have for this?
Tim: It's a good one. I don't really remember, but I'm sure that I spent nights and nights doing something I wasn't sure they wanted me to do. And I remember being anxious about it, "What if they don't like it?" "Will they fire me because I was doing this?" Which was really stupid because I was working for free at that point in the middle of the night. But still . . . The great thing about passion is how unhealthy it is in the end. I don't have a specific example but I'm sure I've had a few of those.
Ryan: We've a question here and then we'll go to the back.
Woman 1: How do you prioritize features versus design, tweaks, like changing the color of the buttons or something like that versus building a code within a feature.
Tim: The new feature is probably always going to be the most important thing. Again, if you are close to the developers you can nudge them, like "Hey, can you quickly change that color while we are building this thing?" And as long as you don't distract anyone or distract people from the goal of shipping the new feature, I think that's perfectly cool. Yeah, being flexible about it and knowing the people you work with closely is very important.
Ryan: Cool. And in the back.
Woman 2: [inaudible 00:40:35]
Tim: I work in Sketch most of the time.
Woman 2: Is it versus Photoshop in [inaudible 00:40:48]?
Tim: Yeah, used to be Photoshop for a long Time. And then I think as soon as Sketch 3 came out, at that point I was just starting work on a new project, so it was easy for me to start this new project in a new app. Otherwise, it would have been more tricky. But then, four weeks I think, over half of the design team had switched over to Sketch. People were recreating existing designs in Sketch so we could reuse those building blocks, all that. Now the entire design team is using Sketch, unless they're illustrators. Then they're in Illustrator and they're never going to use anything else. Besides Sketch, Framer is my go to prototyping tool right now, because it's very close to the HTML and CSS that I used to write. It's easy to pickup, and even more importantly, it's easy to share with other people. I can send someone a link and they can open the prototype on whatever device they need to open it on. I know Quartz is really advanced as well. That's Quartz Composer, by Apple, now very much supported by Facebook. You can't just give someone a build of a prototype on their device. It's like, "Here's my phone, please can you play with it?" all that. Besides that, not sure, I think that's where I spend most of my days in. yeah.
Ryan: Cool, we have Time for one more question. Yes, sir.
Man 8: What's your take on [inaudible 00:42:33]?
Tim: We actually have multiple services and multiple products. We have Dropbox which is obviously the biggest one. We also have Mailbox, we have Carousel, there are some new projects on the way. They just released a beta of Notes. So, in a way, that is a multi-service product. Even if you're a big company doing one service, there will always be plenty of work to do, because there're so many different parts to it.
Woman 3: [inaudible 00:43:34] you mentioned earlier that there are situations where you want to document something new. Do you use something to document, something general?
Tim: We use Notes, or the new Dropbox product.
Woman 3: Something internal, or . . .
Tim: It's internal right now because it's being built. There are some external teams who have access to it and I think they are going to launch it soonish. It allows you to write in the same document with multiple people together. It's easy to share things, it's easy to link to other documents. So we have a whole system in it. We've been using it for months and we have thousands and thousands of docs in there already.
Ryan: Cool, and one last question from Shane in the back.
Shane: Hi, my question is what do you poll for your inspiration? What sites do you go to [inaudible 00:44:32]?
Tim: I still visit Dribbble once a week. Half of it is to find talent, find people I wanna work with, and the other half is to see how people solve problems. I don't really pay attention to the visual style or the gradings or whatever they put in their buttons. It is interesting to see someone working on a slightly similar project or they solved a certain problem in a way that you hadn't thought of. And that's extremely inspiring. And besides that, using other products, non-related products might spark inspiration to solve something. I will never go look for a specific bit of, "How can I design this?" It's more like, "I have this problem. These are the unknowns. How do I solve it?"
Ryan: Cool. Well, thank you so much Tim, or Max as I like to call you, for joining us today for ZURB soapbox. We have another Soapbox event on May 8 with Randy Hunt of Etsy. So, be on the lookout for that. Thank you everyone for attending. Appreciate it.
Tim: Good, that was fun.
