#165 – The creative process in a remote & async environment: Deep work, Loom, pair design, & presentations | Ben Grynol & Alan McLean

How does the creative process happen in a remote-first and async work environment? Design and creativity move from in-person, collaborative whiteboards and sticky notes to the use of Loom and other documentation tools in an asynchronous environment. While at times it’s tricky to work asynchronously, it also provides a lot of creative freedom. Alan McLean, who leads design here at Levels, shared his thoughts on the pros and cons of async design work, how to maintain communication in a remote environment, and why critique is essential.

09:46 – More exploration time

To get in a state of flow with creative work, sometimes you need to step back from traditional design work. Async gives you more time to explore.

Sometimes getting in a state of flow with design and creative work actually means you’re not doing any from the outside lens, traditional design work. It doesn’t all happen in Figma. Sometimes it’s me riding my bike, sitting alone, not being interrupted. Or walking my kids to school or something like that. When you have meetings, interspersing those kinds of moments all the time, it gets really hard to just think offline about a problem that you’re exploring. So, you ask any design team what they need more of and they usually say they want more exploration time. So I think that’s one thing about being async and being remote that you can do a lot more effectively.

11:46 – The importance of subconscious design work

There’s a lot of subconscious work that goes into design, and async offers time to think. But it’s also more challenging to connect with your coworkers and get needed feedback remotely.

There’s actually a lot of subconscious design thinking and work that happens. There’s been times where I felt completely stuck and didn’t get anything done in a day then I woke up at one in the morning, went to my computer and cranked out a whole section. A big redesign of the explore section and I felt like it was pretty good. But if I’d been struggling to throughout the day to chip away at it, I don’t think it would’ve been nearly as effective. That said, I think in the design process, probably where you do need a conversation, is sometimes going through the details. The really small micro details around design or look and feel. In those moments, not having a bit of an echo back and forth with somebody can be really hard. I think it’s kind of a matter of figuring out when to bring someone in and when not to in a synchronous way. It can be also really hard to stay in a productive fashion if you get a hundred Figma comments.

14:09 – Help people give good feedback

If your clients aren’t design-minded, it can be hard for them to give good feedback on a half-finished design. Learn how to communicate with them at the right time and in the right way.

Sometimes in progress design work, it’s just chaos brain. It can actually kind of freak people out because you’re showing stuff that isn’t completely at odds with what you might ship or… It’s like creative process sometimes is just go really broad, right? I think one thing I’ve learned over the year is that you have to be probably disciplined in what you share too. Because you’ve got an audience that doesn’t always understand how to consume it. That’s just all about helping people give good feedback, but also finding a way to communicate at the right time and in the right way.

18:14 – Async evens the playing field

In a synchronous environment certain voices tend to stand out. Async work levels the playing field so everyone has a voice.

In a sync environment oftentimes there’s very dominant voices and there’s the voices that are usually very opinionated or they’re very assertive in their point of view. And sometimes that can drown out, oftentimes I look for the people that are the quietest in the room because they’re the most thoughtful. Sometimes those voices get diminished in person. Whereas when you’re in an async environment or you’re doing a lot of it remote, it can become, especially when it’s async, it levels the playing field. I found that to be really helpful.

24:19 – The value of Loom

Loom offers an interesting avenue for communication, because it gives control to both the speaker and the listener.

What’s interesting, too, about that is that no one can interrupt you. When you’re doing presentation, someone can like, “Hey hold up, I want to think about that a little bit more”. The next slide might explain why it is what it is, but when it’s a Loom, they can record, they can… I think there’s actually this subtle thing about power that happens in presentations where if you’re just a viewer and you’re listening to someone talk, and you have really no control over what they’re saying, say in a live sync meeting. I think it can subtly mess with your feeling of control over what’s going to happen or the design. But when you give the viewer the opportunity to turn you up three x, or pause it, or go back and forth and add comments, it somehow empowers a viewer to give better feedback.

28:25 – You need interaction

Whether you’re async or not, you shouldn’t design in a silo. Feedback and interaction with your work is vital.

I think there’s something about knowing when to flex that muscle. I think actually there’s a subtle thing here is that sometimes you hate what you’re working on, you think it looks awful, and you might need just a little bit of validation. And you know, like the saying “share early and often”. Well if you’re not liking the way it’s working, the least less you like it, the least likely you are to share it. Having a way that kind of flex both is really important. So you continue to maintain momentum and have some positive reinforcement and honest critique on what you’re doing.

36:40 – Document and discuss

It’s important to have justification or clarification on why decisions were made, so document everything regularly.

What I’d like to do is of monthly or maybe every two months, document why things are the way they are. Cause there’s so much rationale and design discussion that happens. It doesn’t always manifest in a Figma file or a deck. And talking about zones, how do zones work? There’s like how do they structurally work, but then why do we represent them the way that we do? Or why do the graphs look like this in this context and different in another? There’s a bunch of considerations that happen there, and we probably need to document those design components in a more rigorous way. So when you jump in, because oftentimes this is of standard immune response for any designer, they join a team, they see all these components, the design system and they’re like, “What is going on here”? I don’t think I’ve ever heard a designer say when they joined a new company, “Boy the design system is so great”. So the typical thing is I inherited this terrible design system and there’s not much I can do because it’s so bad. That’s really important to have justification or clarification on why decisions were made and then you can all work together to better solve it, rather than feeling like it’s an immovable block.

41:21 – Critique is essential

It’s hard to come to a good place, especially in product design, without having other people’s feedback. Your concepts need critique in order to become better.

Having critiques on the concepts you’re coming up with, it’s essential. You’re not going to be able to design just by yourself and come up with something that’s any good without having some feedback from people. There’s no rockstar designer. Well there probably is, but it’s awfully hard to come to a good place, especially in product design without having other people’s feedback. I think it’s a little bit different than graphic design. You’re going to go make a poster, you’re almost like applying your aesthetic to it. But if you’re a designer and you’re building UI, you need feedback back on the usability and how it works. I think design critiques, at least at Levels, until recently were just one on one. But I think you need of crowdsourced opinions that do a good job.

47:34 – Async isn’t for everyone

Some companies aren’t built for asynchronous work. From the ground up, your tools have to represent an async, remote culture.

It might not be possible for all companies to transition to that. Apple doesn’t even use Figma, they use Sketch because they don’t want their designs leaking. So we’re kind of in the perfect sweet spot, where we valued it from the very beginning. So All the structural stuff we created facilitates that. So if you’re in a company that’s struggling to go remote async, it might require some larger reevaluations of how you think about work overall, not just for a design or product team. From the ground up, your tools have to represent an async, remote culture, I think. Some places you can’t even record video, right? Because you don’t want to materialize a point of view that could potentially be on a legal problem or something. So if you’re in a situation like that, your prospects are becoming remote and async are probably pretty low.

Alan McLean (00:06):

Having critiques on the concepts you’re coming up with, it’s essential. You’re not going to be able to design just by yourself and come up with something that’s any good without having some feedback from people. There’s no rockstar designer. Well, there probably is. But if you’re a designer and you’re building UI, you need to be [inaudible 00:00:27] on the usability and how it works. I think design critiques, at least at Levels, until recently, were just one on one. But I think you need crowdsourced opinions. Maybe what that means is actually a minimum viable design team to have good feedback.

Ben Grynol (00:51):

I’m Ben Grynol, part of the early startup team here at Levels. We’re building tech that helps people to understand their metabolic health, and this is your front row seat to everything we do. This is a whole new level.

(01:05):

When you work in a creative environment, the world of design, it can be really hard to put boundaries around. What are the constraints, how does it work? Well, our mental model of design when we think about it is designing a tangible product, maybe something you can pick up, you can hold in your hand. When it comes to digital products, the way you work is maybe a little bit different. You can’t necessarily hold that thing, it exists on a screen. But when you think about the traditional process for design is typically thought as being in person, very collaborative, whiteboard, post-it notes, you name it. All of these things everywhere. Well, when teams are remote, very much like Levels, and for us we operate asynchronously. The creative process has to change, it has to evolve. So what does this mean from a tooling standpoint? What are some of the platforms that we use and the way that we document things internally? How do we collaborate? How do we do things so that we can focus on the deep work without distracting each other?

(02:12):

Alan McLean, who leads design. Also, side note, one of the Canadians on the team. He and I sat down and we talked about design. All about this process, the way that it really has evolved. Prior to Levels, he spent time at Fitbit, at Strava, at the New York Times, and, most recently, Google. The design process that he had used throughout his career very much had to change and evolve as he came into Levels. And the more that he has worked in this asynchronous and remote environment, he’s found a lot of things that have worked really well for him. So, as the team scaled, we now have three different members of the design team, and a lot of these principles are holding true. There’s a lot of benefit to being able to work very deeply on design. Think about it when you need to think, work when you need to work. But there’s also a way of finding that space to collaborate as necessary so that you can get that sync time, if you need it, to transform ideas. Anyway, no need to wait. Here’s the conversation with Alan.

(03:14):

The idea of this is to talk through creative process in an async and remote environment. So, without a doubt, and we’ve talked about this before, there’s a time and a place for in person design. Full stop. Depends on what you’re doing. The extreme example is it’s really hard to clay model a car through a Zoom call. That just doesn’t work super well. But then other products, like a digital product, there’s a case where you could say, “Well, maybe you can collaborate asynchronous and remotely.” As an async and remote company, and you’ve done so many different facets of design in every corner of the world, but, they’re two different worlds. So I thought it would be useful to talk through the differences of how does async and remote differ for the design process? And we can riff on some of these ideas of where one is beneficial and where you can get away with the other. And then sometimes it is more efficient to be doing some components of it asynchronous and remotely. That’s some framing for what we can jam on.

Alan McLean (04:18):

Yeah. Oh. I mean, it’s a really interesting topic. Especially lately, because we brought two new designers on, so I’ve been thinking about this a lot more in terms of collaboration styles and getting feedback. My general takeaway is that async is probably basically what you said at the outset. Async is only good if you know when to use it and when not to. I do get questions in hiring conversations around, how do you do design without being able to quickly get feedback from people or do a workshop or something like that. Just through the course of COVID, largely discovered that a lot of design can just happen, can happen async or solo. And then there’s some parts of it that just absolutely can’t. You need to be able to have sync chats and go back and forth. A lot of design is super organic and it doesn’t really work to have all these comments and back and forths and Looms. Sometimes you just need to get on a phone call or a screen share and just walk through it.

Ben Grynol (05:30):

One of the interesting things is, if we think of design as being iterative. Iterations within iterations within iterations. It’s like these micro conversations of exchanging information. That is one way of moving an idea forward, and two people go back and forth and play a bit of tennis. Then let’s say this is a real time chat. Doesn’t matter whether it’s remote or in person, but that is helping to go, “Oh, this thing, this idea that we started with is now here.” Then you can go do the work against it and come back and do the next cycle. So, that’s one thing. What happens in a synchronous or an in person environment, on occasion, and this is where the deep work, this is the dichotomy between both worlds. It gets really hard to be in an in-person and synchronous environment in a design world, in any world, but in a design world where you go to do the deep work and then Billy’s tapping you on the shoulder again. You lose your train of thought.

(06:36):

It’s like it’s harder to get in that state of flow. I know that’s one thing that, when you did your think week, gosh, it seems like it was two years ago. But you did your think week relatively recently, however many months ago. And you came out and you’re like, “That is the deepest design work I’ve been able to do in a while.” Because you allowed yourself to go to that place. So it’s like there’s merit in all of it. I think that the takeaway is finding when and where to use the different levers. That’s always the hardest thing.

Alan McLean (07:07):

Yeah. Yeah. That was definitely the longest uninterrupted design work I’ve ever done. But there was also some chats during that, periodically, to help pull the ideas along. I think sometimes when you’re alone you can do things that wouldn’t normally make sense or someone would immediately tell you isn’t going to work, but you can keep going. The flip side of that is you can also get lost, and it can be hard to come back to the problem you need to solve. But, on the other hand, I mean I’m so torn on that, because it’s both helpful and can also hinder your design because you can get lost and go on these crazy tangents. But you also need to have the ability to have a bit of a reset and come back to the problem. I think in some ways it requires some discipline to do it well.

Ben Grynol (08:00):

Yeah, designing in a silo. It’s hard because designing in a silo, you can get to this really deep exploration. Really, really deep. But then sometimes it’s hard when you are in that silo, if you aren’t having the conversations to bring you back to reality is your head gets so deep in the sand that you’re like, “What part of the world am I in right now”? But it’s really good from a creative standpoint, it’s so engaging and stimulating because you just sort keep going and constraints melt away. There aren’t any constraints because everything is an exploration. So it is that balance of doing both. And I know that what you touched on was, this comes up in general is around being remote and async as a company. How do you actually do work? But it’s different with design where I think in general we’ve got a mental model of, design works like this.

(08:56):

People have a general sense of the way the cycle works, the cycle works to do the work. And because we have such a different model, A, it’s very hard to communicate what exactly it is. It is this, it’s just sort of, it happens, right? So maybe let’s go into that because what’s a good way of framing it from what you’ve learned, how we go about actually doing that work. And now that there are more team members, how do we bring them into the fold so that everyone is maintaining our cultural values and the way that you can get great work done but still leaning into design needs iteration and collaboration to make it happen?

Alan McLean (09:39):

And it does, but maybe I’ll just add one thing there. That one of the hardest things to do, just sometimes getting in a state of flow with design and creative work actually means you’re not doing any from the outside lens, traditional design work. It doesn’t all happen in Figma. Sometimes it’s me riding my bike, sitting alone, not being interrupted. Or walking my kids to school or something like that. When you have meetings, interspersing those kinds of moments all the time, it gets really hard to just think offline about a problem that you’re exploring. So, you ask any design team what they need more of and they usually say they want more exploration time. So I think that’s one thing about being async and being remote that you can do a lot more effectively. Now I forgot the question.

Ben Grynol (10:37):

Just talking about maybe the process. How do we go about doing the work? Especially now that we’ve got three people on the design team that are working towards this. The bike ride’s an interesting thing. You can’t make calendar event, going for bike ride to think about glucose game. You can but then you’re going to get on your bike, like anything, and it’s just stale mate with your mind. You can’t force that. But what you can do is carve out enough chunks, like these four hour blocks where you’re doing some things, it might be message, it might have been some hand sketches on in your notebook could be anything then you’re like, “I’m going to go for a bike ride right now”. That just something inspires the thought because of what you had for lunch, a song you heard on the radio and then all of a sudden you saw some message and you’re like, “Yeah, I’m going for a ride now”. Then all of a sudden that’s the unlock. But it’s freeing up that deep work for your brain to actually explore, the conditions are what you said, where it can’t be meeting, break, meeting, break, meeting, break. That will never get anyone anywhere very quickly at all.

Alan McLean (11:45):

I think there’s actually a lot of subconscious design thinking and work that happens. There’s been times where I felt completely stuck and didn’t get anything done in a day then I woke up at one in the morning, went to my computer and cranked out a whole section. A big redesign of the explore section and I felt like it was pretty good. But if I’d been struggling to throughout the day to chip away at it, I don’t think it would’ve been nearly as effective. That said, I think in the design process, probably where you do need a conversation, is sometimes going through the details. The really small micro details around design or look and feel. In those moments, not having a bit of an echo back and forth with somebody can be really hard. I think it’s kind of a matter of figuring out when to bring someone in and when not to in a synchronous way. It can be also really hard to stay in a productive fashion if you get a hundred Figma comments. That could just be a conversation, right?

Ben Grynol (12:58):

Yeah. Is the key is having you hear it in, it can be in design business, it can be in anything but. People when they’re trying to do meaningful problem solving, maybe that’s a good way of framing it, when you’re trying to do problem solving is having a thinking partner. It can be a design partner. But the thinking partner that somebody that you lean on consistently for reference. Like “Hey, I want to gut check this thing. Hey I’ve been thinking about this. What’s your feedback on it”? And that can be very asynchronous too. You put this idea over, I’ve been thinking more about doing this thing, can you think about it for a while? And sometimes those are sync conversations, sometimes they’re async. But having that resource that you can lean on when you need to is so helpful to get unstuck.

Alan McLean (13:50):

Yeah, yeah, yeah. Actually it’s kind an interesting thing I’ve learned over my time at Levels is that… You might recall I used to do those long Looms of general concepts and ideas and everything. I do that for in progress work too. And sometimes in progress design work, it’s just chaos brain. It can actually kind of freak people out because you’re showing stuff that isn’t completely at odds with what you might ship or… It’s like creative process sometimes is just go really broad, right? I think one thing I’ve learned over the year is that you have to be probably disciplined in what you share too. Because you’ve got an audience that doesn’t always understand how to consume it. That’s just all about helping people give good feedback, but also finding a way to communicate at the right time and in the right way.

Ben Grynol (14:47):

That’s the biggest thing with designers, always keeping things so low res that the second they start to feel polished and people are like, “Oh is this the finished concept”? And you’re like, “No, no. Chaos brain, chaos brain”. Sometimes making things worse from a resolution perspective. Well I know I could record a Loom and show some of the Figma files, but that might feel too polished. So I’m just going to hold a picture of my napkin and then people will definitely know that this is not finished. That’s always the thing of when… It’s great to show work, but knowing how to frame it to certain audiences. Because if you show a bunch of chaos brain, I like that little statement, is chaos brain to a design crowd. They’re like, Oh that’s just Alan showing some concepts. It’s chaos brain. But you show it to somebody that might not have a design lens and they’re starting to give feedback on the things that you’re like, “Oh that’s not even… That red button isn’t even going to be there. That’s nothing”.

Alan McLean (15:50):

Don’t worry about it. So yeah, I used to do a lot of that too. I mean I guess it really depends on your audience. Oftentimes I find though that with an audience that doesn’t have a lot of design background, that if you show just wire frames, if it’s just a spectrum of wire frames, the high fidelity, it’s hard to actually give feedback that is more actionable or that is really constructive. Because when people see wire frames often that times they’ll just be like, “Yeah, it’s great”. You don’t actually walk away with a lot of value sometimes. So I try to do the medium fidelity thing, but sometimes that doesn’t work out. People get freaked out.

Ben Grynol (16:42):

So the first is rewinding in your experience of everything up until Covid, right? Everything up until remote world, new world, everything was in person as far as your design experience. So why don’t we talk through synchronous in person and then we’ll go async remote and just talk through some of the differences. So in person synchronous environments, what is your frame of references in the way that typically works?

Alan McLean (17:14):

Yeah, I…

Ben Grynol (17:17):

Maybe what makes a healthy design process from your experience and your perspective?

Alan McLean (17:22):

Yeah, I mean usually it’s a lot of things like workshops and printing out your designs and putting them on the board. People can do dot voting and add comments. Sometimes it’s more of a pair design model that I used at Fitbit. Where you’ve got a product designer and a visual designer going back and forth and one driving and one is giving feedback, almost like pair coding. There’s a variety of different flavors of, and sometimes it’s of course just heads down kind of work. Although that’s a lot harder. I think when Covid first happened, well let me just before I get into Covid, I think there’s some real benefits to being able to do those sorts of things and get a bunch of different eyes on it at the same time. The coordinated workshop, I’ve run tons of workshops in the past.

(18:12):

I think what I have seen though is that in a sync environment oftentimes there’s very dominant voices and there’s the voices that are usually very opinionated or they’re very assertive in their point of view. And sometimes that can drown out, oftentimes I look for the people that are the quietest in the room because they’re the most thoughtful. Sometimes those voices get diminished in person. Whereas when you’re in an async environment or you’re doing a lot of it remote, it can become, especially when it’s async, it levels the playing field. I found that to be really helpful. But anyway, continuing on with sync time. It’s usually you running these workshops, you’re putting post-its on the wall. It is actually fun too because you’re breaking, you’re getting lunch together. That’s great. So of talking about the work at lunchtime or whatever, but it’s also super inefficient.

(19:08):

I remember taking these post-its, putting them on the ground, taking photos of them, transcribing them, taking photos of the ones that had the most votes or dot votes. And that is painful. Going and getting these printed on phone boards. I mean it’s nice to be tactile but it’s also pretty slow and inefficient. When Covid happened, and we transitioned to these workshops, I was at Google at the time, running workshops remotely. You needed a lot less time. And also you were documenting the feedback in a Google slide, and so there’d be spaces for everybody. There’d be instructions that were super clear. You never really needed to repeat the instructions because they were right in front of you on a screen. A slide deck that you could look at. And then it started to actually get really, actually much more productive. It was hard to coordinate across time zones. So that’s the async problem. But actually found workshops to be really efficient and really high value, remotely.

Ben Grynol (20:11):

Yeah because when you’re doing that work, the work of getting things printed and putting them on, you have some treasure, you have this thing that is here is the artifact of my work. And so it’s busy and it feels productive. But if you actually break it down, there’s the opportunity cost of being able to now do the actual work. You’ve gleaned all the insights. Putting some polish on them so they’re on the foam core board is probably diminishing returns as far as the investment, as long as you’ve got good documentation, good organization. As far as it’s not just a bunch of paper everywhere, where it’s so hard to categorize and bucket the insights and say “Cool, here are the core themes that we’re building against. We’re going to go design against these”. If it’s just chaos, it’s chaos. But having it on the foam core board as long as it’s organized doesn’t actually make it any better.

(21:05):

And so then you miss out on the time of, which is the nice thing about being remote and async is that like, hey you’ve got this now you can go and design against it. So bringing it to remote and async… I know we haven’t had to do as much of this because it’s been relatively small as far as the way we’ve grown, and there are more team members now. But when you first started and it was the team of one and then you’d have collaboration partners with David and with Eng. How have you had to adapt some of those things into this different way of working? Probably the most different, being remote was table stakes, but async was not. Remote being everyone experienced it with Covid, async is not table stakes. That’s like a newer concept for many of us.

Alan McLean (21:54):

Yeah. So again, the question is exactly, how did it evolve? That’s what you’re looking for?

Ben Grynol (22:03):

Just sort how did it differ? So you got used to this way of working in the design world and then bring it to remote and async, how did you have to adapt some of these things as far as, we talk about behavior change all the time from a consumer perspective, but sort change some of the way that you work your own processes and your behavior. To achieve the goal that you like the goals that you wanted to achieve. But it’s a way different way of working.

Alan McLean (22:32):

Yeah, it is. I mean actually I think it really improved my presentation skills. Because I think sometimes when you go back and forth with someone remotely just on a phone call, you can boot them up really quickly. You can give context, and when you just do a presentation and you’re walking through a design and you record a Loom, some of that can get lost .because the screen’s kind of changing and again, chaos. It can feel a little bit like chaos. Whereas, what I found that I needed to do was do a lot more of these structured presentations. That actually helped clarify my thinking too. You only really know it if you’re able to communicate it clearly, oftentimes I’d be building these presentations for a Loom and I’d completely changed my idea of what it was going to be or how it should work. Because I could see it all in context. I was creating a narrative around the experience. In the past I wouldn’t have done that. I would’ve just like someone would’ve stared over my shoulder or remotely in Figma, and their little cursor would go around and they’d have comments or whatever, right? It’s a much more deliberate presentation now that I think yeah, really helps the design. Yeah.

Ben Grynol (23:53):

Man, it’s hilarious. You painted a picture, which is so true. There’s the, we’ll call it the in person Loom that’s very typical in a creative field. It is somebody, one or more people stand over your shoulders behind you and they look at your screen while you talk about the screen and it’s hilarious because that is actually what people do. So you take a tool like Loom and you’re like, oh this is way more effective for the async stuff. But [inaudible 00:24:19]

Alan McLean (24:19):

What’s interesting, too, about that is that no one can interrupt you. When you’re doing presentation, someone can like, “Hey hold up, I want to think about that a little bit more”. The next slide might explain why it is what it is, but when it’s a Loom, they can record, they can… I think there’s actually this subtle thing about power that happens in presentations where if you’re just a viewer and you’re listening to someone talk, and you have really no control over what they’re saying, say in a live sync meeting. I think it can subtly mess with your feeling of control over what’s going to happen or the design. But when you give the viewer the opportunity to turn you up three x, or pause it, or go back and forth and add comments, it somehow empowers a viewer to give better feedback, I think.

Ben Grynol (25:10):

Yeah, you realize how inefficient the in person stuff. Assume you’re doing a Loom, it’s a very fast thing that you wanted, “Hey I’m thinking about this concept” and it was like five minutes. Took you five minutes to record this and just go through these things. And you’re sort of like throwing it over the fence for anyone to give feedback to.

(25:32):

That typically, not just from a distraction standpoint, booking it with the 15 minutes before and 15 minutes, well assume not before. Because those things usually happen from a tap on the shoulder where you’re caught off guard, somebody throws you out of your chair and you’re like what is happening? But those end up being these 25 minute or half hour conversations because people interject, they want to ask you more about that and that’s entirely fine. But you were interrupted from something that could have taken five minutes, and so you get so far out of that deep work mode that you were in, that the work, I don’t want to say suffers, but the work might not evolve to the point that it could have if you weren’t interrupted. And that’s the nice thing about doing the Loom, going back into this world and you don’t have to spend more than the five minutes or 10 that you would’ve taken to record it in the first place.

Alan McLean (26:26):

Yeah, yeah, totally. Yeah, I’m a big Loom fan. Yeah, it’s definitely improved the quality of my work. But I think also it’s worth calling out that, because even on the design team now we’re talking about, you say you’re just playing with a color palette or topographic treatments or something. It can be quite costly to do little tweaks and little spacing changes and stuff in a Loom, that’s not always deep thought or deep thinking, so much as it is kind of instinctual. Sometimes for that you really need to just drop a screen, get some feedback, you don’t need to record a whole Loom because you’re kind of waiting for that ping pong effect or you’re going back and forth, back and forth.

Ben Grynol (27:17):

It sounds like the low latency design flow if you want to call it that.

Alan McLean (27:20):

Yeah, yeah. You can’t stay in a flow, you got to record a Loom for every little tweak you’re going to do, right?

Ben Grynol (27:26):

Yeah. The low latency back and forth with messages. Because then it feels less formal. It’s just like hey this and then that. And maybe there’s a time and a place there, where you are able to do something synchronous and screen share with someone else and walk them through a thought process and they can give that the ping pong back and forth to evolve the conversation. To transform it to a different place. Because you’re saying, “I don’t know, something feels off with the padding here, what are you thinking”? And then that way somebody can give that insight, like “I think we need a little more radius on that”. Those little things help especially people… Everyone on our design team is senior, so tons of experience, and will have a lens, but it allows you to all evolve things to where you want them to be and have that true thought leader, true design partner to make things better.

Alan McLean (28:24):

Yeah, yeah totally. Yeah, I think there’s something about knowing when to flex that muscle. I think actually there’s a subtle thing here is that sometimes you hate what you’re working on, you think it looks awful, and you might need just a little bit of validation. And you know, like the saying “share early and often”. Well if you’re not liking the way it’s working, the least less you like it, the least likely you are to share it. Having a way that kind of flex both is really important. So you continue to maintain momentum and have some positive reinforcement and honest critique on what you’re doing.

Ben Grynol (29:11):

Those table stakes. That people in a creative field disliking their homework and being overly critical of table stakes that happens.

Alan McLean (29:19):

Yeah, I hate everything I’ve ever made.

Ben Grynol (29:22):

There you go. It’s always constant evolution. Before coming on board, was there anything that you were nervous about having heard some of the things around, “Hey we work in this way”. Was there any feelings that you thought, “I wonder how this is going to work out. I wonder how am I going to do my work”? Did anything cross your mind that you initially had a lens on and have since changed or still feel certain ways about?

Alan McLean (29:52):

Honestly, I was coming from a super sync place, so coming to Levels I had actually no concerns. It looked like a huge free up of my time and it has been. So in that regard I didn’t have any concerns. I definitely hear some concerns when interviewing candidates who were thinking about joining Levels or interviewing for a role. And they wonder just how it could possibly be successful, which is actually an interesting point… Because me coming in, I was like, “No way I’m doing this anymore”. But maybe part of it is once you can get in the right async rhythm, I think it can work really well.

Ben Grynol (30:36):

Well what’s been different as far as the tools? So some of the tools that you would’ve picked up, one being Loom. If you went from highly synchronous meetings to Loom, are there any other tools that you’ve embedded into the design stack that you weren’t using before and have been very beneficial?

Alan McLean (30:59):

Well, yes, other tools, but not so much as it relates to async or remote. I mean I do use Observable a lot cause I get some data and I need to visualize it to generate a primitive to drop into a design. I suppose you could use that async too. You can have people collaborate on it and work on it rather than some local Python notebook or something. So that’s great. But that’s usually just me, well no I could share it with the team. I’ve shared it with folks like Josh and other folks like that before. So.

Ben Grynol (31:33):

Nice. What’s been the experience with documentation, in the sense that design for the most part doesn’t fall. I mean I shouldn’t frame it this way. Some organizations have a deep documentation culture, some functions typically have deeper documentation. Let’s go to the extreme. Legal is all about documentation. That is the goal of legal is to make sure things are well documented.

(32:02):

In the eng world there’s always the mental model that like “We could be documenting more”. Not necessarily at Levels, we work very hard to make sure we are documenting. But a lot of organizations you’ll hear, “Oh talk to Jimmy, Jimmy has the tribal knowledge” and that’s not a good thing. So there’s a time and a place for that. But design is one of these functions that it’s really easy to get away from saying, “Yeah, we don’t really need documentation because we throw things out as quickly as we make them”. But what’s been your experience as far as having this documentation culture and knowing like… If everything looks like a nail, you’re going to take the hammer to it, right?

Alan McLean (32:50):

Yeah.

Ben Grynol (32:50):

No matter what. But some things need different treatments. So how have you taken this documentation approach and catered it so that it still worked with design and you’re not just sitting writing very long form memos day after day. Knowing when to do that, when not to do that?

Alan McLean (33:07):

Yeah, I think oftentimes it comes bound to the audience. You and I have talked about this lightly in the past. I definitely don’t nearly subscribe to the documentation culture nearly as much as Levels typically would because a lot of my work is visual. So oftentimes rather than a Notion doc, which for a variety of reasons is kind of a problem for us, because the aspect ratio is wrong and everything, a lot of our stuff manifests as a Google slide doc or something or a Loom.

(33:41):

Maybe the one change is I often record that content in a Loom or Slides or whatever and reference back to it in Notion. That’s how I work typically. I think this is kind of just an evolution of the team too. The process wasn’t structured in the past. It’d be me and David or me and Scott or anyone on the team going back and forth. But now we’re getting to a place where we have a brief, we have some sizing on how long it’s going to take, what are the design problems. Some brainstorming and then transitioning to actually making it, which I think is really welcome. Before that was great, it was fun, but also it’s not really scalable process, and you need to document along the way to scale it. So I think having in that respect, I think you’re kind of right at the moment where process and documentation’s probably going to change design.

Ben Grynol (34:40):

The part that’s beneficial across the entire company is the idea of having things that are well documented and thorough. Documentation being whatever form fits the function, if that makes sense. So for design you found leaning into the decks and the Looms and everything has been great, but it’s not as easy as we scale the team to say “Hey, well we did those things but then they just got lost into the abyss because they were in some thread”. So still having that warehouse or architect in a centralized database in Notion where assumed design team was at 20 people, however long from now. And someone comes in and said, “Oh I’d like to try this thing, you can go, well three years ago or two years ago, the deck. Here’s like we did kind of try that thing, maybe we should revisit it. But here was the experience so far with doing this thing”.

(35:46):

And so that’s the time and the place to say keeping track of things. We always refer to it as documentation but it’s more of the matter of keeping track of it in some way that is referecable in the future has huge upside. Then the other side of it is when a new team member Victor just joined, he can go through three, five, he can go through some end number of decks slash Looms that you’re like, “Hey check out these things and that’ll get you up to speed on the last eight months”. It takes him so much less time to onboard and then he feels invested and aware of the work that’s been done to get from here to here. Because when someone joins they only see the point in time. They don’t know the historical work that’s been done to that point.

Alan McLean (36:30):

It is actually something I’ve been thinking about and I wanted to do this before Victor joined but I was on break and didn’t get a chance. What I’d like to do is of monthly or maybe every two months, document why things are the way they are. Cause there’s so much rationale and design discussion that happens. It doesn’t always manifest in a Figma file or a deck. And talking about zones, how do zones work? There’s like how do they structurally work, but then why do we represent them the way that we do? Or why do the graphs look like this in this context and different in another? There’s a bunch of considerations that happen there, and we probably need to document those design components in a more rigorous way. So when you jump in, because oftentimes this is of standard immune response for any designer, they join a team, they see all these components, the design system and they’re like, “What is going on here”? I don’t think I’ve ever heard a designer say when they joined a new company, “Boy the design system is so great”. So the typical thing is I inherited this terrible design system and there’s not much I can do because it’s so bad. That’s really important to have justification or clarification on why decisions were made and then you can all work together to better solve it. Rather than feeling like it’s an immovable block, right?

Ben Grynol (38:02):

Yeah man that’s such an interesting thing. So doing that isolated to, we’ll say the function of product design eng. Like, yeah, that makes sense. There’s some history, there’s some thought that goes into why these decisions are made. But take that forward, how many support tickets come in that ask, “Hey, I want to understand what does a zone score mean? Why this done this way? Help me understand”. That happens frequently where people will ask specific questions about product and then there will be responses that the support team has. But new team members join. It’s a lot harder to get ramped up on why these decisions are made. So documenting things in that way, huge upside across the team for anyone that would be close to needing the lens on the reason why we have certain things that are designed the way they are. Built, the way they are in product.

Alan McLean (39:09):

Yeah, I think it’s something that could be distributed in all over the place internally. A user, our new designer shouldn’t necessarily have to ideally use the product to understand functionally, use it for two or three weeks to understand how it works. You know, should be able to download that pretty quickly. So yeah, definitely a top of mind asset to create, and could be kind of a fun just rolling artifact of explanation on the product.

Ben Grynol (39:39):

The history and timeline.

Alan McLean (39:40):

Yeah.

Ben Grynol (39:42):

Given this idea of creative process in async and remote environment, what’s been the most challenging thing? There’s been a lot of benefit where you can get into deep work. What’s been the most challenging part of working in this way?

Alan McLean (40:04):

I think probably the most challenging is kind of that one to one bouncing feedback back and forth. You do need that. So not having that it can be challenging. Maybe there’s also just some practical stuff. Sometimes it’s not quiet. When my kids were home during Covid it was really hard to carve out quiet time to record a Loom. But maybe that’s just because Covid was hard generally for people with families. Largely, it’s been a big unlock for me. I think crits are really important part of the design process with me.

Ben Grynol (40:50):

But I got to cut you off. Critiques, crits, critique, People will not know crits. So design critiques.

Alan McLean (40:56):

Yeah, design critiques, yeah. Yeah, so design critiques. I think maybe this is a Levels specific challenge, because there was up until recently just me. But critiques, design critiques where people look at the work and have an eye design eye and sometimes engineering and product people too, but having critiques on the concepts you’re coming up with, it’s essential. You’re not going to be able to design just by yourself and come up with something that’s any good without having some feedback from people. There’s no rockstar designer. Well there probably is, but it’s awfully hard to come to a good place, especially in product design without having other people’s feedback. I think it’s a little bit different than graphic design. You’re going to go make a poster, you’re almost like applying your aesthetic to it. But if you’re a designer and you’re building UI, you need feedback back on the usability and how it works. I think design critiques, at least at Levels, until recently were just one on one. But I think you need of crowdsourced opinions that do a good job. Even just today we had some back and forth with Victor and Brett on some design system changes and I don’t know, it was very exciting. I was really thrilled by it.

(42:23):

So I think maybe what that means is actually sort of this a minimum viable design team, to have good feedback. And you can try to instill that into a company and we’ve tried, so when you get a design lens on it becomes just a bit more potent and valuable.

Ben Grynol (42:39):

That’s pretty interesting, the minimum viable design team because yeah. Team of one person, then you don’t get that feedback. Let’s break it out actually, feedback from people who have an objective lens when it comes to design is completely different than feedback that is a little bit more subjective. “I’m not sure what I don’t like about this, but I don’t like this”. I mean it’s still feedback, and there is value in it, but it’s a lot different than somebody that has the design lens can go… We talked about padding and the radius on a button and all of these things where starting to talk in design language, an of one doesn’t exist. That doesn’t work. An of two, maybe there’s not that… What the numbers, we don’t really know, but minimum viable being… Three is really interesting because then you get that extra perspective and it’s not just sort of two people trying to massage an idea. What that is, who knows? But it’s pretty neat to hear how you’ve had that experience early on so far and how it’s evolved with Victor coming on board where it’s like, “Wow, it feels like this different dynamic in a good way to make things better”.

Alan McLean (43:50):

Yeah, I’m already really optimistic that the visual design and the interaction design, the overall experience is going to sort dramatically evolve. There’s something kind of nice about having people focused on, we’re Swiss army knives, but having people responsible for a domain. Overall user experience, actually kind of think of it like a triangle actually, at least for Levels that, because we’re in health and wellness. Typically you would look at it as a spectrum. You’ve got one side, you’ve got a visual designer, a UI designer, and the other side you have a UX designer. And they’re thinking about the overall relationship with the product and interaction design, visual design. They’re thinking about how it feels and what it looks like. But for us, we’re trying to shape behavior and so it’s this probably more of, instead of a spectrum, it’s kind of like three pointed. You got someone dealing with the emotion, [inaudible 00:44:49] relationship, the joy. Someone thinking about the overall architecture. And then someone thinking about the look and feel. And it’s not that they’re stuck and just in those corners, but having a domain, really like a strength. If push came to shove and the house is burning down or whatever the metaphor is, you go to that place. I think that’s really helpful.

Ben Grynol (45:10):

Yeah, the frame is, that Brett does interact. I mean everyone’s doing everything in, contributing to all aspects of it, but Brett’s wheelhouse is interaction, your wheelhouse is the architecture.

Alan McLean (45:25):

I say Brett is probably more like the joy and the emotional relationship. I’m probably the architecture, and Victor’s the visual. We all [inaudible 00:45:34] those places, but, yeah.

Ben Grynol (45:36):

And everyone compliments each other because, for people that don’t live in the design world, it’s capital D design. The cliche is always the graphic designer that we joke around. So you’re a graphic designer… I mean, sort of, I can do it, but not really. There’s so many aspects to it. So understanding, they’re very distinct skill sets and distinct roles. To be world class really, really good at each of them is its own challenge. So we’ve the best, we’ve got an incredible team of people that are thinking about these aspects of what we’re trying to do every day, which is very important. It’s a very cool team to see all of this unfold the way that it does. So yeah. One thing to dig into, so interesting to hear your perspective around advice that you might have for other designers or other teams that are struggling a bit with the process of, maybe not async, but remote because so many teams are remote now.

(46:39):

That is a thing where tech companies, large and small startups all over have said, “Hey, we’re now remote, or we have some remote component” and we get these questions all the time about how do you work from a business or an op standpoint. But what would be some advice that you have or some takeaways for people that are thinking about how to do this better or maybe struggling with it, where they’re like, “We’ve been doing this for over two years now and we just cannot figure it out”. It could be tooling, it could be process, it could be mindset, way of thinking, but what are some little things that have worked well for you? I know blocking off deep chunks of time has been hugely beneficial, which is a whole different conversation around company norms and the way that teams work.

Alan McLean (47:28):

I mean this will sound a little pessimistic, but I think some, it’s in their DNA to be super sync. And so it might not be possible for all companies to transition to that. Apple doesn’t even use Figma, they use Sketch because they don’t want their designs leaking. So we’re kind of in the perfect sweet spot, where we valued it from the very beginning. So All the structural stuff we created facilitates that. So if you’re in a company that’s struggling to go remote async, it might require some larger reevaluations of how you think about work overall, not just for a design or product team. From the ground up, your tools have to represent an async, remote culture, I think. Some places you can’t even record video, right? Because you don’t want to materialize a point of view that could potentially be on a legal problem or something. So if you’re in a situation like that, your prospects are becoming remote and async are probably pretty low.

Ben Grynol (48:31):

That becomes very, very difficult, because a ton of the value that from what you’ve communicated and that you found has been in this idea of being able to record Looms, being able to share things openly. There are some principles that have to be in place. A foundation has to be in place to enable it, but if people are having challenges around it, they have to unpack it in the right way to find. Maybe part of it is colluding in some fashion between a small group. Let’s say a design team is five people, and there aren’t constraints in place that make the entire organization say, “We have bureaucracy and we cannot do this thing”. But people who work in certain functions can do their sync stuff, and you’re not going to change that, but you can say, “Hey, team of five of us, let’s collude to just say we’re not going to… On Tuesdays, we do not message back and forth. We do our deep work”. So it’s like these seem to be little sort hacks or systems. Massaging the levers where you can to get the benefit so that you can free up the space to go on the bike ride to be able to think about the thing that you wanted to do.

Alan McLean (49:52):

I mean, one thing we’ve been talking about potentially for this back and forth, is maybe there’s days you do it, like you said, or maybe it only exists on your desktop computer, not on your phone. The phone is this gateway to be working all the time or not have private space to think about things. Maybe we make, don’t want to be bureaucratic, but establish some norms that ensure that you’ve got a clean separation. Especially, I don’t know personally, I feel like a lot of my most creative work comes out in the times when I’m not at work. Finding a way to separate it I think is pretty important. It’s almost like indirectly improving your productivity.