We’re starting a new series of bonus episodes called Going Remote. We’ll have different Basecampers answer questions about how they do their work remotely. In this first episode, design lead Jonas Downey talks about how he and his team collaborate with each other, give feedback, and communicate with their developer colleagues. These episodes are adapted from an ongoing series of livestreamed Q&As, which you can find in their entirety on Basecamp’s YouTube channel.
- Video of Jonas’ Q&A | YouTube playlist of all Q&As - 00:33
- Jonas Downey on Twitter - 00:39
- Question #1: I’m planning on doing design thinking sessions for groups. How should I channel the team aspect in a virtual call with 20 to 30 people? - 4:25
- Question #2: What tools do you use to replace whiteboarding and Post-It sessions? - 6:33
- Reflector app - 7:31
- Question #3: It seems like most communication you do runs through Basecamp. How do you communicate the intricacies of designs to engineers, and what’s your workflow? - 8:51
- Basecamp co-founders Jason Fried and David Heinemeier Hansson’s live walkthrough of the company’s Basecamp account - 8:54
- Question #4: Do you use version control tools like Abstract? - 12:46
- Question #5: In the meeting-averse culture of Basecamp, how does design work get reviewed and approved? - 16:23
- Question #6: Do you use any design tools, or do you design in the browser? - 17:44
- Question #7: Is it required at Basecamp for a designer to know how to code? - 18:48
- Question #8: How many designers do you have at Basecamp? - 20:21
- Question #9: I’m interested in the dynamic between designers and product managers. Do you do project management yourself using tools like Jira or Trello? - 21:07
- Question #10: How do you balance between designer and manager roles? - 23:00
- Basecamp on Twitter - 25:35
Transcript
(00:00:00) Broken By Design by Clip Art plays.
Wailin: (00:00:02) Welcome to REWORK, a podcast by Basecamp about the better way to work and run your business. I’m Wailin Wong.
Shaun: (00:00:07) And I’m Shaun Hildner. Today we’re kicking off a series of bonus episodes called “Going Remote.” Different folks at Basecamp have been doing livestream Q&As about working remotely. We’re releasing edited versions of those Q&A sessions as podcast episodes.
Wailin: (00:00:23) Over the next few weeks you’ll hear about how we do customer support, technical operations, and even parenting as remote employees. If you want to watch the full videos, there’s a playlist of all the Going Remote sessions at YouTube.com/Basecamp.
(00:00:36) And now we’re going to kick things off with Jonas Downey who leads the design team at Basecamp.
(00:00:40) Broken By Design by Clip Art plays.
Jonas: (00:00:51) Cool. All right. So I’m going to start with a little bit of a chat about just the philosophy around designing remotely. First of all, I just want to acknowledge that nothing about right now is normal in any way. If you work for a company that wasn’t previously remote and now you’ve been forced to become remote. You really just cannot possibly expect people to have anywhere near the same degree of productivity that they had before.
(00:01:21) Because people are not only adjusting to a completely new, different way of working but they’re also doing so under extreme anxiety and with other unanticipated life changes. So, I just kind of want to acknowledge that up front that whatever I’m going to talk about today, about designing remotely will be based on learned experience having done this for about a decade.
(00:01:42) But even with that experience, this last few weeks has been nothing like those ten years. It’s messed up for everybody. So we have to cut everybody a lot of slack no matter what their comfort level is with remote work. So with that said, everything’s messed up and with things being messed up, there’s also maybe, we’ll see, maybe there’s a positive side to this in the end where being forced to work in a different way could be weirdly enlightening for the future when we’re able to return to some degree of normalcy and make decisions for ourselves again and leave the house.
(00:02:20) Maybe some people will discover that they liked aspects of working remotely, working at home and want to do more of that. So what I’m going to focus on questions for today is general practices concerning less unusual times and things, techniques and tricks that can help you be successful with your remote design work whether it’s for now during our anxious times or preferably in calmer times.
(00:02:43) So, our general approach usually, but even more so now, is to do things asynchronous as much as possible. So less demand for real time interaction with people. It’s especially important right now with people being at home with their kids or isolated in their apartment, whatever it is. Everybody’s needing to have buffer time to figure out their life and deal with their situations.
(00:03:10) So you can’t reliably expect people to be on a computer at 3:45 pm, necessarily. It’s too hard right now. One key thing is just try to reduce synchronous communication as much as possible and try to increase asynchronous.
(00:03:30) What I mean by that is if you can write something up instead of having it in a chat, if you have a place to do that, write it up. If you can track work in a system like Basecamp or Trello or whatever, do it there instead of needing to get somebody on the phone, or needing to have a video call with them, whatever. Really reduce the amount of time you’re needing people to be interacting in high fidelity.
(00:03:53) We’ve been doing that at Basecamp, traditionally we were doing more video calling and then within the last two weeks I’ve basically kind of shut that down for a while because it was like, everybody needs time. We might spin some things back up now that people are getting more used to what’s going on but we’ll see how that goes.
(00:04:07) So, let me start answering some questions.
(00:04:13) A bunch of people asked me questions prior to me starting this stream so I’m going to kind of go through those one by one. And when I’m done with those, if there are more I’ll keep going, otherwise, we’ll just call it off at that point.
(00:04:24) So the first question I got was from Hamza on Twitter. And he asked, “I’m planning on doing design thinking sessions for my company and I’m thinking of ways to create teams so that they can work on ideas together. I’m deliberating on how to channel the teamwork aspect in a virtual call with about 20 to 30 people.”
(00:04:45) And this is the thing, I think a lot of people are probably facing right now, where, if you used to work in an office or you used to work in group situations, you could congregate a lot of people together and work as a big group. When you’re person to person, that’s relatively easy to do because there’s a social construct. Everybody can see everyone. It’s friendly. You can raise your hand, you can have a snack, whatever.
(00:05:08) When you switch to remote tools, having that quantity of people on a video call is really awkward. Basically, there’s an inverse relationship to the number of people on a call and how good the call is. So if you scale up a video call to 20 or 30 people, it’s just not going to be very pleasant. Basically, what happens is nobody really talks. Everyone has to mute because there’s too many people. So people start talking, they talk over each other. And everybody has kids in the background and there’s noise. So everybody’s muted and one person talks at a time. And there’s usually awkward silences because nobody wants to unmute the call to talk. It’s just bad.
(00:05:49) So what I’ve found works better is if you have to have a high fidelity call with that number of people, make it mostly a presentation, not an interaction thing. So maybe you want to present an idea to a group, you can do that but don’t expect a lot of back and forth collaboration on it. And then if you do need to do back and forth collaboration, break that out into smaller calls.
(00:06:14) So my suggestion is, to the extent possible, always keep video calls to the fewest number of participants you can. If you need to have more calls, then just do that, because 20 to 30 people is just not fun. It’s kind of just painful.
(00:06:28) So then my question is from Jason Grant on Twitter. He asked, “What tools do you use to replace white boarding and Post-It sessions?”
(00:06:40) Now we don’t do a lot of Post-It stuff, in fact we don’t really do any Post-It stuff. There are tools for that. I’ve seen people use apps where you can share, you can make a Post-It board and then share it with other people. I can’t recommend them because I don’t use them, so I don’t have a lot of experience with that. However, white boarding is something we do a lot. In fact, I tend to get together with Jason Fried, our CEO in Chicago, usually once a week, we get together and raw stuff. For us it’s chalk boarding, it’s not white boarding because we have chalk boards. We get together and just draw things on the chalk board and we review what’s going on.
(00:07:18) And since this lockdown thing has happened, we can’t see each other. So we basically just haven’t done that. But there are ways to reproduce that experience remotely that work pretty well. And the way I like to do it is using an app called Reflector. It works with iOS and the Mac. This is a really good way, high fidelity way, to reproduce that white board experience. You’re not actually sitting around the same white board, but you can see what a person is sketching and comment on it and move things around. That would be my recommendation for replacing white boarding.
(00:07:52) Jason had also asked, “How do you balance interaction time with heads down time?”
(00:07:59) I think that kind of goes back to what I was talking about originally at the beginning which is just, basically reducing interaction time to the minimum necessary. And what that means varies depending on what your company is like. So if you feel like you need to talk with your team very frequently, maybe try to reduce the frequency by one step. So if usually you were talking to everybody every day, try to tamp that down to maybe twice a week or something, for now, in order to let everybody breathe and have some space.
(00:08:32) Then, get back together, save those meetings up and get back together and have a rich, longer session. Or maybe you do this white boarding stuff, or whatever. That would be my recommendation for now, is more heads down time and less interaction time for the moment.
(00:08:45) Cool, all right. So then I had a question from Aaron on Twitter and he asked, “I watched Jason’s demo yesterday.” Jason Fried and David Heinemeier Hansson did a demo of Basecamp yesterday. They live-streamed and walked through our account and showed people how to use it. So, “We watched Jason’s demo and it seems like most communications that we do as a company run through Basecamp as opposed to having calls or video chats. When you do it that way, how do you communicate the intricacies of your designs to engineers, and do you have a particular workflow you can elaborate on?”
(00:09:19) This is a really good question. I think we talk a lot about how we shape and scope projects. We don’t talk as much about how we actually execute the projects as designers and programmers when we’re in there. So once a project is shaped and it gets assigned to a team, how do we actually do that? As I’ve been saying, repeatedly, we obviously prefer asynchronous communication.
(00:09:43) I’m currently, I’ve been working with one of our programmers who lives in Copenhagen. So there’s a relatively substantial time difference there. You have no choice than to be more asynchronous then, because you just can’t count on somebody being around.
(00:09:55) Our general day-to-day life between designer and developer is mostly asynchronous write-ups and some real time chat. Very occasionally, like really occasionally, we will hop on a video call. But that tends to only happen either at the start of a project when we’re first kind of figuring things out and getting the lay of the land and deciding what to do. Or, sometimes in the middle of a project if we run into issues that are so difficult that we can’t work it out with text. Like, I’m stuck, we need to get on a call, something higher bandwidth to figure this out. We will then have a call. But generally we’re almost always text-based. 95% of the time.
(00:10:39) The way that works is we mostly are tracking our work in Basecamp and to-dos and to-dos all have comments. There might be a to-do that’s like, wire up this part of an interface for our programmer to do. So I’ll design the interface, take a screenshot of it, probably commit the UI code in a branch in GitHub, post that, and then I would comment in the to-do and say, hey Kasper, I’m ready for you to hook up this part of this interface. Here’s how it looks. Here’s a link to the code. Let’s talk about it if you get stuck.
(00:11:13) Then, typically we would either go back and forth in the comments if there were problems or we might hop into a ping or a chat to discuss it in higher fidelity. Sometimes it’s just friendlier to chat than it is to drop a comment in. So there’s not a rule to when you use one or the other, but I tend to, especially with Kasper, I try to do asynchronous a little more than I would with somebody who was at least in my time zone because I don’t know what his schedule is like. He’s six or seven hours ahead. So I don’t want to send him a chat and wake him up so I’d rather just make a comment and then when he’s available he’ll get to it.
(00:11:49) So that’s a little taste of what our day to day design is like working with a programmer.
(00:11:55) And the other part I left out of that was we also do a fair bit of stuff in GitHub. So we’ll commit code with each other. I’ll make a pull request that might be a spiked-out interface that doesn’t actually work. It’s just like a stub and then Kasper might take that and make the stub into a working thing. Or maybe I get part of it to work but he has to do the back end so I’ll give him the part that works. Sometimes the programmer will actually start if the designer’s not available yet. So he might spin up some tech with a skeletal interface and then I’ll take that in Rails and then build something on top of it.
(00:12:31) So that’s basically it. That’s a quick snapshot. Happy to take more questions on that if anybody has more questions.
(00:12:37) So the next question is do you use, this is from Brad and Alan on Twitter, they both asked about this same thing in different ways. “Do you use version control tools for designs, like Abstract, for example?”
(00:12:51) We don’t really and part of that is we’re perhaps a little fortunate in that most of our designers work kind of independently with programmers on separate teams. So we’re generally not on top of each other when it comes to design assets very much. Sometimes there’s some overlap. We might have a couple designers… we have a mobile team and a web team working on the same thing at the same time and we have to go back and forth more. But generally, everybody’s doing separate work so we don’t have to fight about versioning on a day to day basis.
(00:13:27) If you’re a team that heavily uses sketch files or something, that’s your main output, a lot of people need to be in the same sketch files all the time so it becomes more of a problem. For us, we don’t really work that way. We’re mostly code so the vast majority of our version control just lives in GitHub.
(00:13:48) We have a Designers team in our Basecamp 3 account where we keep a lot of shared assets that any of us might need. There’s logos, fonts, we have some color palette things. There’s icon libraries that we use for the apps, and various illustrations and things we might use. And we’ve also been working on a designer handbook for people at the company who need to do some light interface design. Writing down what we do, what our rules are, how we work, what our style is, how to write CSS, things like that. So we do have those basic structural things in place in case we need to share things. But in general we don’t need to do full version control.
(00:14:33) In addition to that, I would say if you’re a design manager, you’re leading a team, and you’re considering, maybe I need version controlling for all these assets or whatever. I would also encourage taking a step back from the problem and think about if there are ways that you can decouple dependencies between teams so that they don’t need to be on top of each other worrying about day to day version control of assets.
(00:15:00) Maybe you need to. It could be you’re at a scale where that’s just the way you work and you have a million files getting produced and there’s output coming all the time. If that’s the case, then sure, you’re going to need a thing.
(00:15:10) But I generally think it’s healthy to ask, is there something we could just not do to not need to have this complexity rather than adding software tooling and steps to peoples’ work process in order to manage these things. So part of that might be staggering projects so that people aren’t on top of each other as much. Or it might be reducing the team size, more teams with fewer people so that you don’t need as many versions. You’re not having to track communication across a large team, you can make a smaller team. Those are just a few ideas.
(00:15:41) But I think that’s always worth, if you’re in a situation where you’re like, man, I think I need to buy software to solve this problem. I always think it’s good to step back and be like, do I, though, really need to buy software? Would there be a way to not?
(00:15:55) We make do with six designers and no version control and we support somewhere around a dozen apps and 100,000 customers so it can be done. Not all companies will work like us, obviously, but it’s just an encouragement. If you feel like you’re struggling with this and it’s a problem and it’s reducing your productivity or something, give it a shot. Maybe try a different way of working.
(00:16:20) All right, I’m going to move on to the next one.
(00:16:21) The next question is from Joshua on Twitter and he asks, “In the meeting-averse culture of Basecamp, how does design work get reviewed, feedbacked, and approved?”
(00:16:34) Yeah, I just talked about we’re meeting-averse and asynchronous, but part of the way we avoid needing to be in contact with each other a lot is having thoughtfully shaped projects assigned to teams at the outset before we even start working. When you do that, you reduce a lot of the uncertainty around the project because everybody at the beginning has a pretty clear outline for what’s supposed to get built, how long it ought to take, and what’s within the boundaries, within the scope, and what’s not. What it might look like, what parts are going to get affected in the software.
(00:17:11) When you do that, that automatically reduces a huge amount of feedback and meetings you need to have, because you’re not having all these meetings just figuring things out. You might end up, if you don’t do that, you end up spending two or three weeks just constantly talking to each other, being like, wait, is this interface good? What about this interface? Did anybody do research on this? What do you think? So we just don’t have that at all. We don’t do it.
(00:17:33) Which means, then, at that point, the work you’re doing is more precise and the feedback is very specific.
(00:17:44) “Do you guys use any design tools,” this is Renato, “Do you guys use any design tool or do you still design in the browser?”
(00:17:52) We all use different things, I think. It depends on what you’re doing. So mostly, I think, our web team is primarily writing front-end code. They’re doing HTML, CSS, JavaScript, some Rails. But that’s not necessarily the only place you’re designing. We’re also probably working in Sketch or Figma or Illustrator to design assets or visual elements. We’re usually sketching in GoodNotes or whatever. Usually writing copy, which is not, you don’t really need a design tool for that, but Notepad is a kind of design tool, in a way, for us.
(00:18:26) So I think we’re just all over. We use whatever tool and scenario we need to get something done, and it varies depending on the project. Some projects don’t need any illustrations, they don’t need sketch work. Some projects need a lot of that. It just depends on what you’re doing. So we try to just be flexible and not get stuck into a corner on one thing or another.
(00:18:47) So, related. “Is it required for a designer at Basecamp to know how to code?”
(00:18:52) Yes, it is, I think. We’ve played around with that in different ways with different employees over the years. We generally want someone to come in with a basic amount of knowledge about HTML and CSS at a minimum. And the reason for that is we’re a tiny team, there’s only six of us total and we all are pretty independent and we need to be able to pretty much build our own interfaces. That’s just the way we like to work. It makes us a little more productive. It makes it easier for us to go back and forth with programmers. It’s just a little tricky for somebody who doesn’t have that skill set to walk in and be able to ship stuff. That’s just our traditional process.
(00:19:38) So that’s a higher bar than not knowing any implementation code. But it’s not so high that you couldn’t come in and learn stuff. When I joined, I didn’t know Rails, I’d never used it. Now I know it well enough I can spin up an app on my own, probably. Not great, like it won’t be a beautifully designed, functioning app, but I can make an app work in Rails relatively easily.
(00:20:02) Similar to with JavaScript, too. You might not know any JavaScript, you might know a little. That’s fine. You can learn that but the key is, I think the fundamental thing is really being able to spike-out a working web interface. It’s like the minimum requirement we would have to hire someone.
(00:20:21) Okay, here’s a question. Somebody said, “How many designers do we have at Basecamp?”
(00:20:24) So right now we have three designers who work on our core product team, which is basically the web and desktop. Our desktop stuff is also kind of web-based. We have two designers, one each, that work on our mobile apps. So we have one designer on iOS and one on Android. And then we have one designer who does our marketing work and that’s it. So there’s six of us total, three on the core product and then one on each one of those smaller teams. And that’s it for now.
(00:20:56) We’ve over the years gone up and down a little bit on that but we’ve stayed pretty consistently sized for quite a while.
(00:21:03) I have another question here, it says, “I’m interested in the dynamic between designers and product managers at Basecamp. Or maybe project managers. Do you do project management yourself, using tools like Jira or Trello?”
(00:21:20) Yeah, we don’t have dedicated project managers at the company. We have people who sort of fill that role, that’s also a thing that’s sort of project to project. Whoever is the lead person. Jason Fried, I would say, is the product owner where he kind of makes the final call. So if there’s a debate or there’s an interface that’s unclear or a project that’s been going that maybe isn’t going well. Ultimately, it falls to Jason to decide is this going to go in the product or not. So he’s kind of in that role.
(00:21:50) Beyond that, we’re all relatively independent in our ability to make decisions and run projects. So we don’t use any other tooling for project management other than Basecamp, since that’s what we do. Basecamp is our place for that. And the designer on the teams is typically the person who does more of the project management, but not always. Sometimes there’s a programmer who’s very adept at that. Or someone who’s on the team who’s a little bit more up on the to-dos kind of thing. So whoever’s the person who’s most excited about doing it or most comfortable with it tends to manage the project a little bit. Keep an eye on it, keep the to-dos cleaned up. Keep an eye on what the schedule is like. A lot of times on Mondays, we’ll kind of reassess where we’re at. Be like, hey, we’re doing a four-week project, we’re on week three now. Are we close? Are we way off? Did we underestimate the time we were going to need for this? Are we in the ballpark of being able to get it done? So we’re kind of constantly asking ourselves those questions throughout a project.
(00:22:55) Okay, I have another question. I’m going to do one more and then I think I’m going to end the chat for now. One person asked, “How do you balance between designer and manager roles?”
(00:23:03) I’m not sure I totally understand what you’re asking there. I think you’re asking, like, how do you do both design and project management together, I think? Part of it is that it’s a natural pairing for us where in order to get the design work done, you kind of have to have a picture in your head about where it fits within the larger context of the overall project. What other parts you need to do next, what parts aren’t done yet.
(00:23:31) The way I see it is it’s like, they’re all the same. I don’t even think of them as being separate parts. If I’m going to design something and I’m working with another person, I need to communicate everything I’m doing. I need to have everything sorted out for what needs to get done and then I just need to work through it day by day. So I kind of see the project management aspect of it as just the means to an end. It’s just the way to get design accomplished without a lot of confusion. That’s really it.
(00:24:04) And everybody has different styles. So some people are more detailed in their to-dos, they might make more to-dos, they might have many more dots on the hill than I would. It’s like, you get a lot of subjectivity around how to organized how closely to break things up, but that’s kind of the nice part about this system is it doesn’t need to be very heavy-handed. You can kind of adopt it the way that you feel comfortable.
(00:24:27) Okay, well I think… coming up on an hour here so I’m going to go ahead and cut this session. Thank you all for attending and sending cool questions, this is great. We’ll try to do more of these. I don’t know. If people have other topics they’d like to hear, or more of this. Whatever. If you have other questions hit me up and then maybe we’ll do another one in a couple of weeks. So, cool, you all. Thanks for attending. See you soon.
(00:24:49) Broken By Design by Clip Art plays.
Wailin: (00:24:58) REWORK is produced by Shaun Hildner and me, Wailin Wong. Music for the show is by Clip Art.
Shaun: (00:25:03) You can find Jonas Downey on Twitter at @JonasDowney, that’s D-O-W-N-E-Y. You can catch all of the full videos for these Q&As at YouTube.com/ Basecamp. We’ll probably be doing more of these live streams, so if you have questions for Jonas or anyone else here at Basecamp, drop us a line at hello@rework.fm and we’ll try to get it answered on a future Going Remote session.
(00:25:28) And if you want to catch future Q&A sessions live, the best way to find out about them is following Basecamp on Twitter. That’s @ Basecamp. Thanks for listening and see you next week.
(00:25:41) Broken By Design by Clip Art plays.