Transcript

00:00:00 - Speaker 1: I think designing is just the process of picking the best option that you have gone through, but you need to go through that process. The more time that that process takes and the more expensive that process is, the less you experiment and you just fall back and you default to what we know. But that’s not where great ideas often come from.

00:00:24 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac, but this podcast isn’t about Muse the product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with my colleague Mark McGranaghan. Hey, Adam. And today we’re joined by Dan Lacivita of Play. Hey guys. And Dan, in addition to your duties as co-CEO of a startup, I understand you also have a particular management challenge this summer.

00:00:53 - Speaker 1: Yes, I have two boys, 9 and 7. They just got out of school. So we are thinking of outdoor physical labor activities for them over the summer. The last one was actually cleaning the garage floors, my son. was squeegeeing the water out and he’s like, Dad, this is really satisfying. I was like, yeah, you know, you have to do the other side of the garage too, and then it became immediately less satisfying for him. Yeah, so, we’re coming up with a lot of ideas for those activities.

00:01:21 - Speaker 2: For some reason, I’m reminded of a beloved 80s movie on male mentorship, which is the Karate Kid, and the famous doing chores as a way to learn to be a martial artist, so maybe there’s some angle like that.

00:01:34 - Speaker 1: Yeah, life lessons through chores. I don’t know if they’ll like that, but that’s the, you need to do this in order to play video games, so that’s the model we’re going with.

00:01:43 - Speaker 2: And tell us about the journey that brought you to play.

00:01:46 - Speaker 1: Yes, so 42 years old, father of two boys, prior to play starting play with my other three co-founders, June, Michael, and Eric.

We all worked together at an agency called Firstborn. It’s a design and technology agency. We’re headquartered in New York City.

I actually started there in 2004 as a flash developer, for anyone who remembers the good old Flash days. And when I left, I was CEO. June was our chief creative officer, Michael was our founder, Eric was one of our lead engineers.

And yeah, we were designing and building websites, mobile products, AR experiences for our clients.

We actually sold the business to Dentsu about 10 years ago now and through the process of creating all of those products for our clients, especially mobile products, we’re just always thinking about the tools that we were using, and this is when Sigma was very early days as an agency, we just moved over to Sketch and, you know, my partner June was just always talking about how we’re using the same input devices, you know, for our design tools, but we’re using our phone as a creation device in many other areas and so that kind of kernel of the idea led us to leave Firstborn and then start play.

00:03:02 - Speaker 2: And I feel this is quite a unique angle. I guess there are plenty of places where you use a phone to create content, typing out a quick email or something like that, but something like a design or especially an interactive prototype, you know, we think of that as something where you really got to be at a desk, mouse, keyboard, big screen, and doing that on the phone, which is really optimized to be a consumption device. It’s unusual. How is that borne out so far in your product to date?

00:03:29 - Speaker 1: I thought it was a crazy idea initially too, when June initially talked to me about it, and I was like, how are we gonna create a design tool on a phone with that real estate. And so the interesting and probably there’s many aspects of the entrepreneurial journey that are fun, but I think the early days of just watching the team.

Create different UI patterns.

We landed on sort of this, I think, unique slider UI that allows you to design on the phone while not having the interface getting in the way of what you’re actually designing. So I think that was a really interesting part of the process in the early days. And I think what’s been more exciting and maybe a little unanticipated is As we started to design a design tool for the phone on the phone, we realized, oh, we have this whole sort of sandbox of things that Apple has created, all of these native controls, native gestures that we can now tap into and then layer our GUI on top of, if you will, and give designers the ability to design with the real things, right? The real materials that engineers will ultimately use to make the product that they’re designing. So, it’s been A fun journey so far, you know, it’s unlike traditional design tools that require you to context switch and stimulate the mobile experience plays really the first tool to make contextual design for mobile possible, so there’s no proxies or simulations or syncing to mirror apps. You are sort of getting your hands into the clay immediately and beginning to craft inside of the final medium that the users will ultimately experience things on.

00:05:07 - Speaker 2: And that speaks to me for sure because I’ve written about creative process as being largely about the feedback loop, the iteration loop, how quickly can you try something and see the results of the value of, for example, what you see is what you get editing and word processors, direct manipulation.

I’ve written about this in developer tools where you very often have a long compile run. Cycle and the closer you can get to instantly make a change and see the results sort of the better, even though in many cases that’s not fully practical and so in some senses you’re designing it on the device and so there isn’t some switching, as you said, to some other location. It’s all kind of right there in the same context.

00:05:49 - Speaker 1: Yeah, it was one of the things that June had talked about early on, is like, you know, let’s say I’m designing something for a client to review, it’s, you know, mobile app screens or prototype for a mobile app. I have to get all those designs on my phone, like through a mirror app, right? Or just save JPEGs. This is even before mirror apps were, I mean, they’re still not really that great. It’s like, but then I want to look at that when I’m not at the office. Like, I want to look at that when I’m walking through the park, or maybe we’re designing for a certain persona and they’re going to use this app in a grocery store. Like, I should look at these designs when I’m in the grocery store and I’m in that environment, and then I’m going to see things that I want to change, but I can’t change them in that moment. I have to like write it down or take a voice memo, wait until I get back to the computer or back to the office the next day, then make those changes. And then if I want to see those changes back in that, you know, sort of environment, I have to go back to the grocery stores like, I just want to make that change right there in that moment. And then see how that feels, or maybe have a few different versions of that and then see how that feels.

And so, I think for him and as we talked about it, there’s this unique magical moment when you’re looking at something in your phone, like a design that you’ve created, and then you’re like, oh, I wonder what would it look like if this was changed, and then you could just change it just directly on your phone and it’s kind of a very cool and empowering moment.

00:07:07 - Speaker 3: That’s interesting to me because as an early phone user, I was surprised by the extent to which the mobility and ubiquity of the phone was an advantage. I think that’s kind of obvious in retrospect, but for someone who grew up with a desktop computer, you know, everything was there. You had a big screen, you had a keyboard, it seemed great. Just being able to access a thing all the time turned out to be amazing in ways that I didn’t anticipate. I hadn’t thought previously to apply it to design. Again, I’m back at the square of, oh, it’s design work, you gotta be at your desktop to do it, right? But not so much.

00:07:34 - Speaker 2: You mentioned needing to come up with new kinds of interactions because the phone doesn’t have a big command vocabulary or established precedent for, well, I think sort of creation activities in general, but certainly design work in the specific and in my brief experiments with the app like one that certainly catches your eye right away, maybe this is what you were referencing is you kind of see the prototype filling most of the screen, but you swipe to the right, which sort of spatially speaking drags in the left hand.

Side of layer list which will look very familiar to a sketch Photoshop type person and indeed those are often on the left, but here they’re just sort of off screen they’re sort of in the spatial metaphor of the mobile world they’re sort of hovering off to the side until you slide them in and then there’s another one on the right that you sort of pull in that actually. It gives you adding horizontal and vertical stacks, buttons, all that sort of thing, and then there’s sort of a properties panel that slides up from below that lets you edit stuff.

So that certainly speaks to us where, you know, working on the iPad trying to make a thinking tool we do end up having to like invent a lot of stuff from whole cloth, which is a pretty big hassle or a lot of work or takes a lot of time relative to working in the more known space, but it’s basically a lot more fun as a designer and engineer and product builder because you do have this open frontier that Now that all possibilities are open.

00:08:53 - Speaker 1: Yeah, I agree. I think it’s certainly fun in the creation process.

And then when you design those small magical moments, it’s fun for the user too.

And I think even tools that exist for creating something or have a purpose behind what I’m doing can also still have those moments of fun or you know, sort of interesting interactions that smile, right? That say, wow, that was actually a cool thing that I experienced and so. When we were designing the slider, Eric, you know, our lead engineer and my partner was like, oh, well, maybe we can just drag the slider vertically as well. So like I’m actually moving the knob on the slider horizontally, but if it’s in the way of something on the screen, I could just move that entire slider up and down. And it was just those little moments and as they compound, then the UI starts to come together and actually becomes something far more functional and usable and interesting to use for the user as well, I think.

00:09:51 - Speaker 2: So our topic today is designing with real materials, and longtime listeners of Meta Muse will know this is something we’ve we’ve touched on with past guests.

Andy from Not Boring Software has a great post called Honor the Material where he talks about basically furniture and how you can design using whatever the particular material is, whether it’s wood or molded plastic or steel that you can use.

That in a way that fits the material and then in the digital realm we’ve spoken with David from Webflow who talks about how Dreamweaver and other kind of past visual website builders maybe one reason they didn’t kind of quite ever seem to click is because they don’t respect the underlying materials of the web, that’s HTML, CSS, the box model, URLs, pages, links, etc. So, Dan, what does designing with real materials mean to you?

00:10:44 - Speaker 1: So, designing with real materials is something that I think early on for us, we realized was possible because we have access to, as I mentioned before, this sandbox that Apple has created. So even the most basic example of a button. I’m gonna design a button in FigMA or sketch, and the buttons are gonna have different properties, right, color properties, there’s probably text in there, maybe there’s an icon, probably has some padding, maybe a corner radius that has all these different properties.

And even when an engineer looks at that button in a FIMA file or a sketch file or XD file, there’s actually a significant amount of code that needs to be written just to get that button to look exactly the same. When I’m writing it in X code, when I see it inside of a design, and that’s just a button.

So then if you zoom out of that and think, well, OK, well then what do I need to do for a card or a stack of cards or an entire page or a multitude of pages that then have different states and interactions, it becomes a lot. And so, we realized that Why would I design a button and play when I could just use the native UI button, for example, that Apple creates, which is how an engineer is probably going to build the actual product. And this is the most basic example, right? So I could just add a native button to my page, and when I’m designing that button and play, I’m actually manipulating all of the properties that exist. In that UI button that an engineer is going to either include or choose to not include when they code it. So we’re doing a couple of things. One is where Giving, I think, more power to designers to, instead of writing a bunch of SWIFT UI code or UI code to, you know, create that button, we’re surfacing all those same properties, but in a way where they can design with them. And then when they communicate that, Perhaps with a developer handoff or collaboration feature, that engineer isn’t just looking at a vector-based rectangle on a page, they’re looking at the same real materials that they’re actually gonna build with. And if you further that, then you start to get into live maps or input text fields or UI collection view or, you know, how stacks are used. And so what we do is we say, well, what are all of the things that I’m gonna use to build a real application. Let’s surface those up as real materials for a designer to use when designing, instead of using replicas of those materials.

00:13:17 - Speaker 2: And I’ll argue it flows both ways.

There you’re talking about the engineer has to do this effort to kind of, you know, replicate what’s in the design mockup that comes out of the more general purpose designing vector editor tool, but it actually flows back the other way too, which is you see that.

There’s big libraries and components that are here’s your iOS system components, here’s your Android system components, those need to be updated every time a new version of the OS comes out where you’re essentially simulating all of those things inside the design tool and then you go back to the ultimate target.

Someone needs to build that button and then they need to kind of extract from your vector drawing what parameters are going to go into that button. So it seems like that could have the ability to short circuit a lot of that back and forth.

00:14:02 - Speaker 1: Yeah, exactly. And I think our general purpose design tools do a lot of things really well, but a lot of their strength lies in that what I would call generality, right? Like I can use a tool like FigMA or Sketch to design a website or an app or a wedding invitation or a poster or a business card or anything, which is incredible.

So I think in the context of designing products, they’re great for designing.

A blueprint for the house, but they don’t really get us closer to designing the actual house, cause they’re not using the real materials that are gonna be used designing that end product.

So, I think the closer designers can get to that point, not only does it make it better for engineers, but to your point, it educates the designer, and I think it empowers them to design with those real materials.

00:14:48 - Speaker 2: When we spoke earlier, you pointed out that the sketches and figmas of the world are general purpose vector editors, whereas what you’re building is a specific tool for mobile app design and as you said, there’s many benefits to being general purpose, but there’s also a lot of benefits to being purpose built for this specific task at hand.

And funny enough, one of our recent guests was a fellow by the name of Paolo who works at Sketch, and he actually made that exact point when I was kind of teeing up what sketches or talking about the history and I said, well, obviously it’s really focused around UI design, and he actually stopped me and said, well, That’s true that it found some good traction in that vertical, but actually it’s way more general purpose than that.

It’s a general purpose vector editor, and he talked about that they need to serve a huge number of use cases. Engineers use it to make flow chart diagrams, salespeople use it to make stuff for their slide decks, as well as yeah design many different kinds of design app icon design and graphic design and mobile apps and websites and desktop apps and so forth. So that’s interesting, which is it’s just not good or bad, it’s just a difference and if you want to do something very specific, then you’re making a thing that’s very suited to that specific task.

00:15:58 - Speaker 1: Yeah, I think one of the things we, when talking with our users, product designers, UX designers is, I don’t think people are really happy, generally speaking, with their UI design tool, whether it be FigMA or Sketch.

And those tools are very powerful, I think very early on in the design process, the design workflow, when I’m really just translating ideas in my head down on paper or on the screen.

Then there is a moment when I want to make the thing that I’m designing more real. It’s a higher fidelity of design, it’s a higher fidelity prototype.

I like the direction it’s going, and then that’s when we see a lot of people, they’re reaching for another tool. Could be origami, could be protoy, usually to do higher fidelity prototyping.

But I think what’s interesting there is, so if you think about, I’m spending all this time in a UI design tool. many, many, many weeks. And then I’m reaching for a secondary tool, spending time in there. The feedback loop between those two tools is very arduous as well, right? Because then if I want to make changes, I have to go back to my design tool and make changes, reimport to the prototyping tool. You don’t get tight feedback loops, which is the whole point of prototyping. I think there’s an inherent flaw there. But then at the end of all of that, what do you hand to your engineering team? Like a figMA file and some videos of a prototype. And it’s all reference points. It’s all just a blueprint. There’s nothing that they can truly use. They’re starting from scratch. And so we sort of look at it and we’re like, well, we should like spend time in your UI tool, in your design tool. I think is an incredible tool. Sketch, these are really powerful tools. But when you reach that point in your workflow when you want to make your design more real and reach a higher level of fidelity, That’s the moment where there’s a benefit in thinking about how to design it with real materials, right? And so, even your interactions, why not use a native modal instead of simulating what a modal is gonna look like? Why not use real haptics so you can feel what those haptics are gonna feel like. And then there’s a lot of, I think, if you get to that point where you’re doing higher fidelity prototyping, the input that you give a user, the higher the fidelity and the better that is. Most likely the better your feedback is going to be, again, when you’re at that higher fidelity prototyping moment.

00:18:22 - Speaker 2: Yeah, I feel like transitions and motion design are an area where mobile is in a whole new class, right? Desktop, typically you’re lucky if you get even like a button animating to a depressed position when you click it with the mouse for the most part, you click on something, the thing just happens. Whereas mobile introduced this whole world of very sophisticated high frame rate transitions that illustrate something spatial or maybe even be a little bit 3D or a fade or something like that.

Every design team I’ve ever worked with, and this includes Muse, you know, you do the static mockups and then you have some text that basically says, OK. This should probably transition by this kind of a thing with an ease in curve and probably take about half a second and then really it’s up to and on our team that’s Julia who loves this kind of work and in a way she ends up being kind of our transition and motion designer because she’s turning those static screens into the actual interaction. So yeah, allowing the designer to do more of that in their tool and thereby get again something that’s closer to the finished thing and let the programmers be more focused on logic, I think seems pretty logical.

00:19:30 - Speaker 1: And there’s some engineers that are really gifted at motion design and transitions and interactivity. It’s designers that have had an opportunity to work with those engineers. Usually get something great from that collaboration because the designer has the vision, and the engineer then takes it even a step further, but that’s not every engineer. And even sometimes designers, I think, don’t know exactly what that interaction’s gonna feel like until they make it and until they feel it. And I think that’s the other piece in the design process that we don’t talk about a lot is to what level of conviction do I have as a designer, that the thing I’ve designed looks right and feels right. Am I just relying on my experience or what I have seen to be true in other apps? Maybe for simple things, that’s fine, but how do we then get different interaction patterns? How do we surprise and delight users with new things? We need to try it. And I think the closer you can get a designer to trying new things and making them feel real in their hands, instead of just trying to explain it to an engineer, they have more conviction. They’re like, oh, not only have I designed it, but they can hand, you know, a phone to an engineer and be like, what do you think? Like, play with it. Like how does that feel? You think we can make it better? And I think that’s one of the things we’re trying to do with play is get designers to that point where they can have that conviction. Of what they’ve designed, not just from a visual standpoint, but from an interactive standpoint, feels and functions well, marrying those two things. I think the whole thing of interaction design, it’s visual design and interaction design together, those things should be married together and not be separate from one another, or be in a waterfall type of uh approach.

00:21:20 - Speaker 3: Yeah, another way to articulate that is that the better your tooling is for rapid and cheap experimentation, the more experiments are correct to do. So if it is in fact very expensive to implement a working prototype, the correct decision is often to actually waterfall it because it’d be too expensive to do it twice. But as it gets infinitely cheap and infinitely quick to implement a prototype, the correct decision becomes more and more just try it, which is great.

00:21:48 - Speaker 1: That’s a great point. It’s the cost of doing something wrong and spending too much time doing the wrong thing. If you can get to the wrong thing quicker, then you’re able to get to the right solution at some point quicker as well. June talks a lot about that. He’s like, I think designing is just the process of picking the best option that you have gone through, but you need to go through that process. The more time that that process takes, and the more expensive that process is, the less you experiment, and you just fall back and you default to what we know. But that’s not where great ideas, you know, often come from.

00:22:24 - Speaker 2: Yeah, enumerating the options and then choosing from among them based on your design constraints and tastes and things like that, I think that gets pretty close to at least part of the core of the design process. And one of my favorite Walt Disney quotes that he would always tell his designers, who only brought him one proposal, was he’d say, Well, it’s hard to choose between one. You know, your chance to exercise your taste is really when you can look at several things, ideally as many as possible, that kind of explore the space and then really see which one is inspired or solves the problem in a unique way or just feels right.

00:23:00 - Speaker 3: Yeah, Ricky has made similar statements about design in the context of programming languages. He said something like, if you’re looking at one option that’s not a design decision, right? It also reminds me of this book called The Principles of Product Development Flow, which I constantly go back to. And one of the insights from that book is that building something like software, something creative, is fundamentally about eliminating risk. If you eliminate all of the risk in a project, by definition, you win. And so one way to look at the creative process is how do you find and systematically eliminate risk. And again, if it becomes cheap and quick to do that, you more quickly and more certainly move towards winning.

00:23:37 - Speaker 1: That’s a great perspective.

00:23:39 - Speaker 2: Mark, what does designing with real materials mean for you?

00:23:44 - Speaker 3: Well, it’s interesting when you wrote that up in our notion doc, I had one thing in mind, but I think we’re actually talking about something else.

So I had in mind the idea of doing a design with an eye towards eventually building it using a quote unquote real material. So for example, designing a piece of furniture to eventually build the production version out of solid hardwood instead of particle board, for example.

But there’s also the notion of designing with real materials as doing the design of the chair with an actual hardwood prototype versus doing it with a particle board prototype, which might be cheaper, but it has less fidelity to the eventual production version. I think they’re both interesting, by the way, and you can imagine the same thing in software with taking the example of the button. If you’re eventually going to ship a native iOS button widget, you might want to do your design with a native iOS button implementation. There’s also separately, the choice of you can ship in your production version a native iOS button or like a transliterated HTML version that mostly looks the same, but actually the the covers isn’t exactly the same. I think those are both interesting discussions. But since the thing that Adam, you originally meant to talk about is more the Designing and prototyping with the actual thing that you’re eventually going to be shipping, in this case, the real iOS button. I would point out that I think that goes both ways, in the sense that you could choose to extend your prototyping technology to get closer and closer to production software. You could also pull in your production software and make it easier to iterate with, and people do mixes of both, of course.

00:25:12 - Speaker 2: Yeah, well, maybe another thing I had in mind was going back to Andy’s article on honoring the material.

There it’s less about in the process of figuring out what the end product is going to be. You’re making a chair, you’re doing a sketch, you’re maybe using some software to lay it out. It’s less about are you designing with the same material and more understanding the material that you want to make it for.

And so perhaps this is, well, I guess that’s in the word honor or respect, but I think it’s maybe authentic is another word that comes to mind a little bit, which is thinking in terms of I’m going to make, coming back to the web flow example, I’m making a web page, so it should use the qualities of the web in a particular way. I shouldn’t try to obscure that I’m making a web page and try to give someone a thing that feels like Photoshop because that’s wrong. I’m going to make a thing that feels like a static image that doesn’t feel like the web. And perhaps there’s a similar comparison to me made for mobile app design. If I’m doing that for a mobile app, I’m mocking up all of the elements in a vector editor, I’m just may not be fully really understanding and respecting what the material can do.

00:26:22 - Speaker 3: Yeah, I think that makes sense. So you might say designing with the real material in mind and honoring that. I do think there’s two subtle variations of this though. There’s one variation which is, OK, I think honoring the material is a good word for this.

This is where you deeply understand the traditional and ingrained use of the material. It’s almost like a moral argument of this is the way the web is, respect the web, this is the way it should be.

And then there’s also the Saying, OK, design is how it works. So you, as a part of that, you need to understand deeply the materials that you’re working with as part of the design and fully understand all the parameters and possibilities. And given that you’re gonna come up with certain approaches and designs. Now, typically, these circles are gonna almost perfectly overlap, but it’s not necessarily the case that they do. I think FIMA is a good example of Figma does embrace some elements of the traditional web. You can go to a URL and you can load the page, but the way the app is actually implemented is completely different. It’s like this wild C++ to WebGL, you know, graphics pipeline, because there they said, OK, here are the properties of the web. We read the fine print. You can do this thing where you transile C++ or JavaScript or whatever, and you can combine that with the traditional, you know, on the material sense of the web should have URLs you can go to, and we’ve produced this great result. So I think there are two interesting and different meanings of that.

00:27:32 - Speaker 1: It’s something we talk about internally as a team is how much time do you spend on different parts of the creative process. So, if I was Going to sculpt something out of clay.

Maybe I have an idea. And maybe I sketched that idea, so I’m doing a 2D sketch of this three dimensional object.

And I think that there’s value in that because I’m visualizing my initial idea, but if I spend too long sketching my sculpture, In 2D in an entirely different medium. I’m not getting to that real formation as early as I want to, versus somebody that gets their hands in the clay sooner rather than later is going to find new things that they wanted to sculpt.

It’s probably not going to look the same as that 2D sketch. And it’s, I think a question of where do I invest my time and how much of that time do I invest at different parts of the creative process.

And I think right now, our tooling. Does a really good job at that, get an idea from my head down to a sketch on a piece of paper or a vector in a browser.

It does it really well.

But then there’s that moment where I want to make it more real. And what’s interesting in hearing you guys talk about the real materials from your perspectives as well is There’s value in honoring those real materials, so the button, like we talked about. But then there’s also a moment where I think the working with real materials unlocks potential that you previously didn’t have.

So, how do I create an interactive map with pins that are connected to a carousel of cards in a vector editing tool? I can’t really do that.

Maybe somebody can create some crazy hacky thing, you know, prototype inigma sketch, but I can’t do that.

I certainly can’t do that in a native way. Or haptics, or a picker. Like how many times do we use a picker in an app, a little dial, right at the bottom of our screen. I can’t make that for real in a vector editing tool. But in a tool like ours, I just tap picker and then it appears on my page, and then I just get to use it, like the real thing. So there’s the moment where real materials unlock this. Potential that I previously didn’t have, not using those real materials, because I had to create ways around using those real materials.

00:30:07 - Speaker 2: Another real world metaphor that comes to mind. I’m reading a biography right now of a fellow named Ken Adam, who was a very talented production designer, so I think in film, this is the person whose job is to basically come up with the sets and a lot of the objects and things that are on screen that are not the actors, and probably his most famous work was Doctor Strangelove, which has these really dramatic war rooms and things like that.

But he’s a brilliant artist. He does these amazing sketches of these scenes, but he makes the point in the book it’s kind of this interview format. He makes the point that the sketches are not the finished thing. No one’s going to see them except some years later if someone happens to be interested and wants to read about it in a book. The sketches just get you to the end thing.

So he really liked to get to working with in this case, the carpenters as soon as possible, and for him, a lot of that was about not just the way the space will feel, but also the way the materials.

Will look so the way that the light will reflect off the metal and by the way this is film and this is film in the 1960s or whatever they’re trying to do things cheaply, you know, they’re doing a period piece. There’s supposed to be a big marble column or a big metal banister. You can’t actually do that with real marble or real metal, so you’ve got to use some various tricks of the trade to kind of do a faux version of that, but what’s that actually going to look and feel like in practice? So on one hand, yeah, he’s a huge fan of sketching and obviously from the muse perspective we like that early ideation. Don’t go and try to build a set before you’ve figured out what the concept is and what you’re trying to convey and what the feel it will evoke will be, but also you could spend too long on that ideation. It’s a safe place. You can make your beautiful pictures and in the end, once you get your hands on the clay, and the sculpture metaphor, get your hands on the whatever the painted wood you’re using for your set, then you start to discover the fine details that will really make or break the end result of your artistic endeavor.

00:32:01 - Speaker 3: I feel like a lot of things we’re talking about here are circling around our overall model of gradual enhancement and the creative process.

So we’ve talked about how the creative process fundamentally has this flow, just to simplify a little bit. Say you go from an idea to a sketch to a prototype to a finished product.

Now, it’s important to Progress along that appropriately. Otherwise you’ll make decisions and choices that are inappropriate for where you are. So obviously if you jump right to implementation and production without knowing what you’re actually doing, that’s a bad idea.

And conversely, if you stay around protyping forever without ever confronting the reality of the actual production material, that’s also a bad decision.

And there’s a theory about how you should do that whole progression that we can talk about if you want.

But kind of bringing it back to tools. I see a few issues that we typically have with tools to facilitate this process.

One is that there are sometimes outright gaps. So for example, we thought that there was a gap, at least in the digital realm with the thinking and sketching piece, which is where we introduced Muse to be a tool for that spot. There can also be a problem with the gaps or the extent of the gaps. So you might, for example, to use the example we’re talking about before with buttons, if there’s a huge gap to go from your protyping tool to your production tool, that introduces a bunch of costs. And by the way, you’re at least going to do one jump from the direction from prototyping to production, but you may well want to go back and forth many times, and that has implications which we can also talk about.

00:33:30 - Speaker 2: One thing I’d like to get your take on Dan, is how you think about the mediums or devices of the phone, tablet, and desktop. This is something we’ve spoken about and written about somewhat extensively and wanting to design fairly differently, for example, between tablet and desktop as we did with the news for Mac versus new for tablet, even though in some ways those are closer than, say, phone and desktop. How does your team think of those and particularly why you want to start with the phone?

00:33:59 - Speaker 1: Yeah, so starting with the phone. We decided to start with the phone, primarily because it was the medium that you were designing for.

So let’s use the same medium we’re designing for as the primary input device. And the other reason was, we realized that it was the most challenging medium to design for if you were going to create a design tool. So let’s start with the hardest, and then extrapolate out from their UI to other platforms.

So, we always believed that play would be a multi-platform product. One of the early pieces of feedback from users was, hey, can I have this on tablet? And we had always thought that we would create an iPad version to design iPad apps, right? Again, using the medium for its intention.

00:34:46 - Speaker 2: Yeah, that’s the thing that comes to mind immediately is that you want to make a phone app, you use the phone, you want to make a tablet app, you use a tablet, you want to make a desktop app, use a desktop.

00:34:54 - Speaker 1: Yeah, and that was in our first medium article, our launch article, we actually said that we’re going to release an iPad app to design iPod apps.

00:35:03 - Speaker 2: I’ll link that in the show notes for historical interest.

00:35:06 - Speaker 1: And then we got feedback from users saying, can I have this on an iPad? Like, I want to be able to design iOS apps, but I want to be able to do it on my tablet. It would be nice to have a little bit more real estate, so I can work for longer periods of time. And I think in our early testing, we realized this too, but there is a cognitive load when you’re doing certain design tasks that coupled with working on the device exclusively, gets to a moment where you fatigue sooner.

So we realized, OK, well, maybe we should accelerate our multi-platform vision quicker.

So we released the iPad app a few months ago, and what was interesting there is a lot of users were using it with their keyboard and mouse and Apple pencil. So the vast majority of people using peripherals, which wasn’t too surprising, but the percentage of them was surprising to us. And at the same time we had launched Play Web, so browser based. It’s really more of an admin tool and asset panel, so I can easily drag photos, images, SVGs, custom fonts, again, doing these things that are going to be way more challenging on the phone.

Let’s use each medium for what they may be best at. And I think as we’ve gotten feedback from users, there’s certainly A role for the desktop in the design process. I think the unique opportunity we have now is because we have a design tool on the phone and on a tablet. Well, what does that then look like on a desktop? Because now we don’t need to create a traditional desktop tool. We can create something that marries and complements the other platforms in a way that is more meaningful. And I think more innovative.

So that’s a space that we’re actively pursuing right now, that’s pretty exciting.

00:37:12 - Speaker 2: Use each platform for its strengths is absolutely singing our tunes, so I’m glad to hear you say that.

I also wonder too, I think your product caught my attention partially because there’s something really provocative about design on your phone, you know, it kind of has a little bit of this counterintuitive head explode emoji like what? No, like phones, you know, for consumption, you’re trying to picture the precision that you need for, you know, moving a thing, 3 pixels to the left or whatever that you associate with design tasks.

And so it’s sort of attention grabbing, but in the meantime you’re also just building a modern specialized just well made design tool, and I wonder, I guess I’m thinking of this because of your users and customers who are on a tablet with maybe a trackpad and a keyboard and a stylus, even if they’re designing for the phone, that indeed maybe they just like a lot of the things about the tool and the core concept of designing on the exact same device that’s sort of your target.

It is very interesting and provocative, but at the same time you can take some of the things that are just good about the tool and generalize them in this way.

00:38:18 - Speaker 1: Yeah, it creates an opportunity for people to harness the unique features or capabilities, I would say, of the product on iOS, but on a different medium.

And whereas the output would be the same, you’re designing a mobile product, how you do that on different mediums may be slightly tailored to that medium. And I think that’s been a really fun pursuit for the team, because how do I Carry enough of the UI from medium to medium, so it’s familiar, but adapt it in a way that also respects that medium, right? We have fundamentals of how we use right click context menus and things like this and hot keys for keyboard shortcuts. We would be silly not to incorporate those into a desktop product, right? So, how do we think about those things in conjunction with how a user would design on the phone and make it a cohesive experience across all mediums, but also unique enough where we’re taking advantage of Innate behaviors that have been ingrained in our activities and how we’re working for so long.

00:39:31 - Speaker 2: One thing I think we briefly mentioned earlier is developer handoff, code export, that sort of thing.

And as I think about the full creative process and going from kind of medium to medium for what’s appropriate for the stage, so you start with that could be a literal envelope sketch, you know, in my case, I would start in muse and I would gather user research and screen scouts to the current product and sketch some new ideas and what are the problems to solve. And once I roughly know what I’m doing, then maybe I go from there to the vector editor. And then maybe you go from there to, OK, now I really have a pretty concrete idea of the flow and the solution, but now we need to get in there with the real materials and design all the interactions and how does the spatial model work and feel and let me quickly do user tests and essentially iterate on it right on the spot where something doesn’t feel right and I can just grab the phone. Back and make a couple of changes in play. So there’s a nice progression there of increasing fidelity, but I know in that kind of little vignette in that little story that I’ve just told, it’s sort of all one person up until the point where they’re doing the prototyping and play and then Usually, not always, but usually at that point you’re not only changing between tools, but you’re actually changing between people, so there’s sort of a knowledge transfer, what was the intention here? What kind of role do you expect to play in that part of the process?

00:40:53 - Speaker 1: Yes, so it’s something we’ve thought about from the onset and I’m air quoting now, but developer handoff has been something that so many teams and companies have tried to solve. It’s a very challenging space for, I think all the reasons we all know to be true.

Engineers work in different ways, existing code basis for products that already exist, incorporating code that’s generated from a tool, maybe challenging to incorporate. Quite honestly, a lot of the code generated from tools is just garbage, and engineers don’t want to use it. So, we’ve thought about it in a way where we wanted to start with the basics and also talk to engineers about what would be valuable. And there’s a lot of opinions is one thing that we’re realizing, but We want to get to a place where it’s usable for both the designer and the engineer.

What I mean by that is, I don’t think all designers want to be educated as to how their designs are going to be written in code. I just don’t think all designers care about that, and that’s OK. The force feed that is not gonna be something that they’re gonna value in a tool. But maybe we could Give them the option to view what the code would look like for the thing that they’re designing in real time, and as they make changes to their design, maybe those properties are changing in the code. So they see that as I make changes in my design, it’s obviously gonna have an effect on the code that my engineer is going to have to create.

I think the pursuit of this for us has been something where We want to get to a point where an engineer, or anybody, quite honestly, could take code generated by play platform, put it into X code, and render the exact same thing that I’ve designed in play.

It needs to be 1 to 1. So what would the use of this be? Well, one of the things we hear from engineers that we’ve talked with, for those engineers listening, I would love feedback on this as well. Is the moment when an engineer, they have to look at a FIMA file or a sketch file. And then just lay out views. I have to take everything visual that I’m looking at, and I have to start writing code to just make that same visual thing in code. And that’s an arduous process. It’s not that much fun for engineers to do, especially the more senior they are. So if we could take that pain point away from them, it would give them, quite honestly, the thing that is most valuable, which is time.

If we could say to a designer, by the way, with certainty, what you’ve designed here in play is going to look exactly the same as what your engineer is gonna code because we’re going to give them that code, then there’s value for the designer. And it, again, gives them both back this thing that is very important, which is time because there’s less back and forth. Oh, I didn’t mean 16 point pad. Oh no, the corner radius wasn’t supposed to be this, it was the. There’s no confusion because at the end of the day, they’re just gonna have a straight line into what I’ve designed, and it’s gonna render the same thing in X code. So, This is some of the work we’ve been doing on the developer collaboration feature, as we’re calling it, because this really shouldn’t be a handoff. And I think that’s the other thing I can note quickly is how often does a designer design something and hand it to an engineer and then never touch it again. Never. So it’s really more how can we create a feedback loop of collaboration. What if there are ways where as I’m designing something, my engineer is beginning to develop it, and then I want to change spacing properties? Do I need to slack that to my engineer? Oh, by the way, like the 16 point gap is now a 20 point gap, or could I just make that modification in the design and my engineer knows that through maybe an endpoint that we allow them to hit, and then those properties are just updated for them. So I think there’s a lot of work that can be done in this space. When we answer the question, what value can we deliver to a designer and what value can we deliver to an engineer? And I think a lot of it is about giving them their time back to focus on other tasks.

00:45:14 - Speaker 3: This idea of a designer and engineer collaborating is really interesting. It reminds me of a bit of a pattern we developed in the lab and have used Muse to facilitate this collaboration.

So say a designer comes up with a design and there are certain architectural elements that they believe are basically set, and then there are parameters that they want to experiment with. Now, the classical way to do this is you eject the code from the design tool and then the designer looks at the real app and they say, oh, the font’s too small. Slack the developer, please make it bigger. And then you’re recompiling everything, and half a day later the build shows up. A cool pattern that we’ve used is identify the key parameters and put those parameters as configurable sliders in the code. And so that the designer can show me the debug panel, slide these things around, see them happen in real time, and then once everyone feels good about it, and nail those values into the code base where they’re more solid, but also harder to change. Sounds like a different way to implement the same. Logical flow that you’re suggesting for this collaboration.

00:46:16 - Speaker 1: Yeah, exactly.

00:46:18 - Speaker 2: Now how do you picture it working in the sense of does the engineer have a copy of play? And kind of the play, I’m not even sure what you call the app prototype document loaded up and then they can take those steps to export as this a place where the web version, I’m thinking of, you know, early kind of hand off tools, Zeppelin, I think was one that had pretty good traction for a while, and they don’t need to know or care about the design tool the designer is using potentially they just get this webpage that has a bunch of assets they can download and kind of screenshots and maybe even some copy pasteable code.

Increasingly nowadays I tend to see more either people engineers have a copy of sketch so they can load up the sketch file or they just click on the FIMA thing and they can kind of go through there, and in that sense they’re not in some kind of separate handoff mode, they just are getting different things from being in the same tool. How do you picture it working for play?

00:47:12 - Speaker 1: Yeah, I think this would be certainly an area where the desktop seems like an appropriate medium for this type of workflow for an engineer. So I think that’s probably the medium where this lives.

00:47:25 - Speaker 2: So then you can only use play for desktop in engineering mode if you have a sufficiently loud mechanical keyboard. That’s the right medium for programming.

00:47:33 - Speaker 1: Exactly, exactly. That’ll be the criteria that you that you need to fulfill in order to get a seat.

So it’s interesting, one of our engineers on our team, accidentally or whatever was updated to an editor role in FIMA. We use FIMA, you know, for a lot of the design work that we’re doing as well. And he was like, this is too much. Like, can you downgrade me? Because I don’t need all this stuff. I just, like, go back to my other view. It’s sort of an interesting moment and we were like, well, why? Like, what was overwhelming about this? And I was like, wow, there’s just all this thing that I don’t need, I don’t need to see all this, I just need what I need.

So I think for us as we’re designing this is, maybe an engineer would want this code that we’re able to generate, or maybe they just wanna have a High functioning inspector tool as well that gives them the opportunity to click on different components, be able to see the different states of those components, be able to see the different properties that have changed in those states, and then maybe if there are interactions, let them know what the interaction is. Oh, it’s a pan gesture. Here are some of the key parameters.

And in some of the engineers that we’ve talked with, that’s actually very helpful, versus here’s a few 100 or more lines of code to create this entire interaction that I’ve created. It’s like, well, no, just give me the different states, the properties that have changed, what type of gesture you’re using, what type of easing there is, and that’s actually really helpful for me. So, I think it looks very similar to what a designer would view, but as an engineer clicks on different objects on the page, we will probably serve up information that’s more relevant to them in a way that is not impaired by other panels, let’s say that a designer may need.

00:49:31 - Speaker 2: So we can see that you can already make pretty powerful interactions in play, and I noticed also as I was poking around the interface there’s a panel where you can create variables, global variables, and that pretty quickly leads my mind to think about, OK, so there’s state, and once there’s state, now you’re talking about a pretty sophisticated program. And so that makes me wonder how you think of yourself as being similar to in competition with or in a different part of the stack than no code or low code builders. You mentioned origami earlier as one example, or even these full fledged outbuilders. How do you see yourself in relation to those?

00:50:09 - Speaker 1: When we started play, the vision was to create the first design tool that was purpose-built for mobile product designers.

And that’s still the vision that we are fulfilling today.

A lot of users have asked us, I’d be amazing if I could just submit what I made to the app store, something similar to an Adalo or Glide or these app builders, whether they’re native apps or whether, you know, they’re cross-platform applications.

I think for us, the vision is something where we want to build a professional grade design tool in a market where I think product designers are underserved at a moment in their workflow that’s really important.

However, because of how we’re building this tool, it isn’t impossible for us to go the route of a more quote unquote app builder approach.

The web flow for apps, for example. It’s just a slightly different market and a different business to build. And I think that’s the fun part of the journey is We are building towards our vision. We have traction with users. We haven’t even launched much of the product ecosystem that we have road mapped, and we’re working to fulfill that vision.

But there is an interesting Opportunity could be a secondary business. It could be a separate business of using the technology that we’ve created to then build an app a builder.

Of course, it then requires We’re back in integration, commerce, etc.

But it’s not something that we’re setting out to build right now, so I wouldn’t call play an app builder because there isn’t a published to App Store button. But the closer that we get to, again, as we’re designing with real materials and as we are creating things that can generate usable code. There is an opportunity for that path to be pursued at some point in the future, should that be one that we want to go down.

00:52:11 - Speaker 3: Yeah, I think you can also think of app builders in terms of the ease with which one progresses down the development continuum versus the eventual limit on one’s ability in terms of the complexity of the app.

So the base case would be, you open up your plain text editor and you type out the apps from the very beginning of the prototyping all the way to the end.

Therefore, you can definitionally do anything you want that could be accomplished in the programming language at least, but it’s gonna be very expensive to do the initial prototyping.

Uh, and then you could use a tool that facilitates the initial prototyping, but Jeff’s code. And then you still have the full runway towards the eventual fully complex app.

When I think of app builders, I tend to think of tools to make a trade-off of making it even easier to do the prototyping and limited capability phases by walling off the future of eventual fully sophisticated, fully general apps.

And in some cases, that’s the right tradeoffs to make if you have a very basic use case, but a lot of reasonably want the option of the full power of the programming language eventually and And for that reason, they tend not to choose those tools in those cases.

You can think of it as a sort of technology problem in the sense of a technology frontier from economics where given a level of technology, which is your tools, you face a certain trade-off frontier, but perhaps with improved tooling and techniques, you can bring that frontier in so you have less of a fundamental trade-off. It can be arbitrarily easy to develop an arbitrarily complex product. That’s the dream. But for now in our world with our limited technology, we have to make a bit of a trade-off there.

00:53:33 - Speaker 2: And I would agree that it isn’t that something is better or worse because it is an app builder with a limited ceiling but easier to get started, maybe can be done by a kind of non-programmer all the way through FileMaker Pro is one of my favorite examples for kind of clunky and old school as it is.

It really has enabled a lot of businesses to build custom software built by domain experts that they just wouldn’t be able to get or afford otherwise, or Hypercard is obviously a kind of one that almost has a Mythical quality to it now and you know was used to make things like games and simple content presentation but you couldn’t do sophisticated logic and I actually almost wonder in the mobile app domain, I think setting aside games, I feel like websites you mentioned the web flow example, there there is a big class of websites which are really just content. And there’s certainly logic in making sure you know it’s responsive on different screen sizes and so on, but for the most part it really is just content.

So once you’ve done the design and copywriting, you’ve essentially done all of it, which is very different from a web app which has sophisticated logic and state and all that sort of thing, and I feel like mobile apps. are more often something that has more sophisticated logic and state, and so therefore, a team with dedicated designer and or a motion designer and a dedicated engineer or engineers is more likely to be needed.

So they’re just different domains without kind of different end states.

00:55:01 - Speaker 1: You see some of the other tools that are app builders, the capability of the tool is such that you generate a fairly straightforward app, and it begs the question, does this need to be an app, or could this just be a mobile website? And a lot of what we’ve talked about in the past is If we went this route, we wouldn’t necessarily change things dramatically from a technical perspective, but we would need to simplify the interface, almost hide more things for users, and then almost have a expert mode or an advanced mode where we would then give the user the opportunity to uncover more of these properties if they were inclined to update them, but If they were a novice, they can build something really sophisticated and great looking without having to tap into those properties.

So I think, Mark, to your point before, I think those are some of the trade-offs, like it would need to be easy enough for a novice in order to make the thing they wanted to make, but have the advanced capabilities of somebody that wanted them if they wanted those things exposed. And that’s the balancing act, I think, of a tool like that.

00:56:16 - Speaker 2: which I think does come back to the gradual enhancement concept you mentioned earlier, bitmark, which is we’ve given the example in the past of LiveJournal and and Friendster, and so on, where you had these things where you would make this very, you know, basically fill out a form, build a profile, but then eventually you can unlock the secret code where you can type in a little bit of CSS into a box, and then from there, you know, there’s the deep rabbit hole of going into full web development. It’s pretty infrequent that things are set up that way in computing, but I think it’s a very laudable thing when you can have that low floor but high ceiling.

00:56:52 - Speaker 3: Yeah, not only that, but minimal discontinuous jumps.

With gradual enhancement, we use the example of, you start with a blank page, you write something out by hand, and you eventually want to end up with a typed document.

Often that requires Two or 3 steps, you know, you write it out by hand and then you type it up in your brainstorming app and then you type it up again in your word processor. It would be amazing if you could actually smoothly evolve that in one document. Similar to how we’re talking about smoothly evolving the design in a way that kind of preserves the underlying code. Now, it’s a very hard engineering problem to get all that into one app. That is the dream, and I think it’s important to keep that ideal in mind and not blindly settle for constant discontinuous jumps in our tooling that jolt our creative process.

00:57:36 - Speaker 2: So you’ve had play in a waitless private beta state for quite some time, and I think that’s a really good way to quietly iterate on something we did the same from use in the early days. What can we expect in terms of a general release or whatever is next for the product?

00:57:53 - Speaker 1: Yes, so plays available for iOS and iPad on the App Store. Anyone could install it now.

There’s still, as you mentioned, an access gate route of beta in the beta sense. I think we’ve got a really stable product right now and we’re letting more users in, but we will be lifting that access gate relatively soon.

So we’re excited about that and it will be open for all to use.

It will be a free tier for everybody to use as well, which we’re excited about and Well, I can’t speak too specifically about some of the bigger things we’re working on.

We have be more features for iOS and iPad over the coming months this year. We’re excited about the charts and graphs for SWIFTUI and iOS 16, so when that comes out, we’ll be releasing some updates there and then some larger platform additions and work that will be rolling out in beta later this year.

00:58:53 - Speaker 2: We’re excited to see it, and certainly as a creator, it’s always a little bit, even if you’ve tested really thoroughly with lots of beta testers kind of a little bit behind closed doors, I think that there is always this act of vulnerability to come out into the world and kind of lift the curtain and say ta da, hope you like it. And of course, you get a huge variety of reactions from folks on the internet, but it can also be a very powerful moment and uniting for the team as well to feel proud about what you’ve put out into the world.

Yeah, great, we’re excited. Well, let’s wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at museAppHQ by email, hello at museapp.com. And Dan, I’m so glad that you’re pushing forward design tools in this interesting and provocative new way. Can’t wait to see what comes out of play next.

00:59:43 - Speaker 1: Thanks guys. I appreciate you having me.