Transcript

00:00:00 - Speaker 1: What I believe, which is that a product that comes with the manual implies it has depth, that it fits together with being a professional tool, where probably the things you want to do with it are things that require skill and take time to learn, even separately from the tool itself. Hello and welcome to Meta Muse. Use a software for your iPad that helps you with ideation and problem solving. This podcast isn’t about Muse the product, it’s about Muse, the company and the small team behind it. My name is Adam Wiggins. I’m here today with my colleague, Mark McGranaghan. And Mark, how are things today?

00:00:42 - Speaker 2: Doing all right, thanks, Adam. How are you?

00:00:44 - Speaker 1: Doing well, we just had uh the spring weather break here in Berlin, so even though we’re still on home lockdown, uh, going out to enjoy the flowers in bloom and trees, uh, in starting to turn green and the kids out, uh, families out and taking my dog out for a walk. It’s uh it’s a nice break after the the long winter. So I’m very excited about our topic today, and that is manuals. So we just finished, uh, really should say you and Leonard just finished the Muse interface handbook. Put a link to that in the show notes. And I think this is a, a lovely piece of work that sort of shows the command vocabulary gestures that you can, uh, you can use with the Muse application.

But the path that we took to get here is maybe an interesting one. I want to tell that story a little bit. When the team started talking about whether we needed some kind of manual or handbook or user’s guide or something like that, it really caused me to go and start reflecting a lot on what I thought makes a good manual.

One experience for me that really stuck in my mind was this experience of getting a rocket espresso machine. Do you know these devices?

00:01:49 - Speaker 2: I think I’ve maybe seen it at your place or I know of it, yeah.

00:01:53 - Speaker 1: I think I got this machine around the same time as I also got some other kitchen appliances. Maybe there was like um like a slow cooker, rice cooker thing, and there was a stark contrast where the, the slow cooker came with this.

Thin black and white tiny print thing that was like in 8 languages and I had to hunt through to find the English and even then it was. I don’t know, pages of boilerplate about, you know, plugging it into the right socket and don’t take it to the bathtub with you and so on, and just getting to the information I wanted, which was how to use the device to cook things, uh, was quite difficult.

The rocket machine by comparison, has this lovely, uh, manual that’s sort of this a full color, it’s bound and the right on the cover it says something along the lines of how to use your machine and and make beautiful coffee. And describing what I want to accomplish as a user and it’s, it’s a quite rich technical manual that covers a lot of, has a lot of depth and certainly I think it has the safety warnings and whatever in the back somewhere, but it really was this inspiring thing that gave me enthusiasm and excitement to uh get using this product versus such a stark contrast to the basically the very sad, uh, manuals that come with uh other kinds of kitchen appliances. So that was, that was a powerful experience for me. What for you Mark makes a good manual?

00:03:16 - Speaker 2: Well, I think your example points to a few things. One is the sense of like impute that you get from actually first seeing the manual.

You infer the quality of the product and the experience that you should expect from what you see in the manual. So it’s a very dull, poorly designed, uninspired manual. You might expect the same thing in the product reasonably, whereas if it’s a very, you know, well done, well designed, uh, well thought out, um, piece of work, you might again expect the same thing on the product side.

Two products that I have some experience with here. One is go by example, um, which is.

On the edge of being a manual, it’s kind of a website, you know, this is the site for learning the Go programming language, uh, but the idea there was to have a very example-based approach to learning. Uh, the Go programming language instead of a very abstract word-based approach. So here you go to the site, it’s basically a series of, of lightly annotated example programs so you can see just exactly how to do it. It’s a show don’t tell situation, which I think is by the way similar to the espresso machine manual you mentioned. You can imagine trying to work an espresso machine just on the basis of text. It’s like pull this lever, then depress that knob and put more water in here. It’s like what does that even mean, right? It’s so much better when you can actually see it illustrated.

00:04:30 - Speaker 1: So some examples of prior art, I think we collected we’re thinking about this, um, included uh things that we’ve worked on, of course. Go by example is a good one. for me, the, um, the early Hiroku documentation, which I think was just a little static website that had, I don’t know, a dozen pages on it, each one of which was describing how to do. Particular thing with the platform, very simple, but easy to easy to navigate.

Nowadays, uh, the product has this huge dev center that is, you know, fits the sort of complexity and and quantity of capabilities that exists in that product.

So sometimes maybe the the earlier products because they can have such simple manuals, uh, that can be that can be more fun.

When I was looking for prior art on, um, manuals, maybe more currently, particularly around the iOS and particularly iPad apps, I looked at Ulysses, a working copy has a pretty nice one that’s sort of embedded in the, like the, the settings menu, but you can also go to his website. Uh, Goodotes has some interesting documentation with some nice kind of animations and and visuals.

Um, and then Procreate was a really interesting one because they have this really beautifully made, um, so Procreates a sort of a professional art application. And fitting to that product, they have this really beautifully made, I think you can get it as an iBook, but it almost unfolds more like a presentation or something, something like that. So I think it fits the the visual style and the the beauty that you would expect from an art product.

00:05:56 - Speaker 2: Uh, another example that that I had thought about was the stripe API docs. And again, there’s this very example based practical approach where they give you, they literally give you commands that if you paste into your terminal, will execute completely the uh API endpoint in question. And for me, that’s always a huge thing with documentation. What is the specific series of actions that I need to undertake to get the result that I want, like enumerate step.

00:06:22 - Speaker 1: Yeah, instructions I think are a underrated thing. Format is huge, and I, I think that almost always you want multiple formats.

So for example, yeah, the Unix man pages for those that aren’t familiar, it’s basically the Unix is a command line driven environment so you type type commands. And you can type man, short for manual space, a command that you are interested in, and it will basically show you the documentation for that. So it’s very in line in, in, it’s right in the environment where you want it.

Um, and I think some of the folks some of the examples we went to look at, um, had a version of that as well. So I think the, you know, the, the working copy users' guide, you can look at it in the app, but you can also download it as a PDF, but you can also go view it on the web.

00:07:09 - Speaker 2: One other format that was actually an inspiration for me here was YouTube.

YouTube has become incredibly important for uh transmitting tacit knowledge on the web.

There’s actually an article we can link to this, uh, in the show notes, um, but video allows you to Um, understand all the implicit and subtle, you know, physical movements, um, you know, mental models people have in their head when they’re telling you how to do something. So for things like, you know, cooking or woodworking or playing a game, these are quite hard to explain like in text, even with diagrams, um, and having the, the video there is super helpful and um I think we’re just gonna see more and more uh things moving to video and YouTube because it’s such a powerful medium.

00:07:49 - Speaker 1: How did people figure out how to do like DIY things around the house before YouTube existed? I mean, YouTube didn’t exist for a lot of my life, and sometime I figured it, I figured it out, but I honestly can’t remember what I did back then.

Yeah, it’s an incredible repository for, as you said, tacit knowledge and things that certainly things that cannot be conveyed well in the abstract. Nature of just uh written prose.

One thing we talked about when we were thinking about the manual as well is the, let’s call it the bottom up versus the top down. And I think the uh the bottom up was more what you see when you view an individual man page, when you Google something and see a stack overflow, you’re looking for a solution to some specific problem in the moment, and you don’t want to see all the documentation, you just want your specific nugget of information.

But I think another, uh, maybe underappreciated role that manuals can serve, they or they serve for me is they provide this overview.

So we spent a good bit of time trying to figure out what the right table of contents would be, because there your information hierarchy or your taxonomy of how you’re sorting things out. Uh, offers a chance to give an overview of what is this product and what does it do.

So I imagine someone, for example, might go to the Muse handbook and look at that and get a sense for what actually is this thing, what are the, what, what are its capabilities in a very practical nuts and bolts sense.

00:09:16 - Speaker 2: This actually points to two things that I think are really important in manuals. One is if the manual is well done, it, it provides that comprehensive. Uh, enumeration of things that the tool can do.

So you can go to the manual and you can read it and then you know all the things, which sounds simple or obvious, but so many tools because there’s so many entry points to the functionality, you know, menus, hot keys, shortcuts, you kind of don’t know if you actually know everything yet and you’re always being surprised like, oh, this is a new, you know, button I didn’t know about before. Um, and I really like the feeling of I now.

You know, I know Kung Fu, you know, like from the Matrix, uh, but the, the other thing is this idea of reference versus narrative docs which I think is similar to what you were describing. Uh, so references like there’s a, a specific. Thing you want to do, you know, I want to move a card, but that that often needs to be situated in a broader workflow, a broader, you know, use case motivation, and so often you see documentation complement that uh the the reference with a more vertical slice and narrative of here’s how you do a X in this tool and it kind of touches many of the specific things that would be covered in more detail in the reference docs.

Those two types of documentation are potentially especially important with Muse, because yes, there’s a bunch of specific things that you need to know how to do, but there’s also this question of what is Muse for, which isn’t maybe as obvious as other tools like a word processor, like you know you’re going to go write a document in a word processor, whereas Muse is kind of a new type of tool, a new category, so we have some explaining to do on that front.

00:10:43 - Speaker 1: Now, do you think the handbook as it is right now accomplishes that? I felt like the even calling it the interface handbook, we really were more focused on the the nuts and bolts part rather than the broad, like what is this thing and what is it good for? Right?

00:10:56 - Speaker 2: I think right now it’s mostly reference and I could see it um expanding to include more narrative or having a complimentary source of documentation later that covers that.

00:11:06 - Speaker 1: One other memory from my past, uh.

Experience working on manuals is how it feeds into product design.

I think you, you brought this up when we were first brain storing the the manual. I think of it as almost like a hygiene or it brings a certain coherence when you’re forced, when you write down, even the table of contents can do that. Uh, one experience I had was working on the Hiroku add-on system, and I ended up essentially writing the manual for that in tandem with designing the way that the technical design for how the system worked.

And I found it incredibly helpful for sorting through these pretty abstract concepts and the the real unlocker was writing a glossary.

So I was trying to take down, I’m like, OK, I’m using all these special words throughout the throughout this documentation.

What does each one mean? And I actually found that taking inventory in this way.

I realized that I would use one word to mean two different things in two different places or other places. I had several words that referred to the same thing or basically the same thing, and so I forced myself to pare down to a set, a fixed set of con uh concepts, the primitives that really built up the design, and then went through and made sure I only ever used that one term. And that was, that was a much harder job than it it sounded. Um, but I felt like the, the end result was something simpler and more comprehensible.

00:12:29 - Speaker 2: Yeah, I totally agree. I think it’s a super valuable process, especially to get the, the glossary, the words right, and relatedly this idea of mental model, often when you’re having trouble writing clean docs or explaining a product to someone, it’s because you don’t have or it doesn’t exist a good mental model for how the product works. Um, and once you can write a really crisp glossary and a really crisp table of contents indicates that um there’s a, there’s a clean set of gears, you know, behind the clock face that, that, um, dictates how this product works.

00:13:00 - Speaker 1: Mental model is, is huge, particularly when you’re doing something that’s either highly technical product or a highly sophisticated power tool. Or just something that’s relatively new, that doesn’t have a clear, you get the mental model somewhat for free if you go to implement something well known in existing a to do list a word processor, when you’re doing something a little bit category breaking and a little bit new, like what we’re trying to do with Muse, that’s a much we need to develop that mental model fresh.

00:13:29 - Speaker 2: Then also more tactically, just when you go to, you know, basically test out every single thing that you’ve put in the manual, you might be surprised how many weird things you find. Like we found a couple of bugs in the course of doing the muse manual where it kind of basically works, but there was a little hesitation or you need to like do it twice, and that’s the sort of thing that you might be able to gloss over in the course of casual queueing. But once you’re, you know, filming in this case yourself, it becomes very obvious when there’s any sort of glitch.

00:13:55 - Speaker 1: Well, the filming side I’m super interested to hear about because you did some, uh, did some very interesting work on that. Uh, but before we jump forward to that, maybe we could start at the beginning of the story. Uh, I always like to hear war stories about how, uh, product features or product, uh, capabilities get developed. So maybe we can tell the story a little bit of, uh, why this handbook came to be.

00:14:18 - Speaker 2: Well, I feel like we’ve had this challenge for a while of um explaining news to our new users. And we’ve been thinking about and trying different things, you know, we’ve tried some onboarding material, which is sort of some example content with some instructions woven in. We’ve tried giving people advice over email, um. We’ve, we experimented and we thought about different, you know, more standard documentation formats like uh text with some diagrams, but we were having trouble really getting through to people basically, um, and the, the genesis of the handbook was maybe video is a especially good format for what we’re trying to show with Muse.

00:14:57 - Speaker 1: I’d previously grappled a bit with the how do you show an application, a tablet application that has sophisticated gestures and uses a stylist, more from, I guess like a marketing perspective. So for example, we have a video up on our website right now, which is just a screen recording. You can’t see the hands, and it’s a little, it works OK, but it’s a little confusing because how is the person doing these things that are happening.

And with a, for example, recording a desktop operating system, you have the mouse, and there’s other kinds of things built into screen recording software to help, for example, when you type keys, they can put basically cues, put annotations for what’s being typed. So it’s much easier to see that. Uh, and then I think with like phone applications, for example, you just tend to have a big button and it’s kind of clear when you tap on the button and that’s sort of it.

But for our chromeless interface where there’s not a lot of buttons and many of the um ways you do things are these sophisticated gestures, that’s that’s tough to show. So I had been down that road a little bit and went around and kind of looked at the way that lots of uh different uh companies that do have these kinds of applications do it. And there’s no real gold standard. Um, but it definitely showing the hands seems to be crucial. So we, we felt like, but, but that’s tough because we had done some video recordings in the past, both for the Muse design article, uh, as well as the capstone manuscript had some really bad low quality videos and I just knew that it was a, a pretty big production effort to to do that well. And so I kind of had the idea of, well, maybe we should stick to still images, and I experimented a bit with let’s do like a 123 that shows the steps of the gesture a little bit uh inspired actually by the rocket manual, which also has things like this where it’s, OK, turn the handle to the right and then push this button and then fill up this reservoir and they they would sort of imply motion or imply um the passage of time. So I did a version of that with uh what we called the shadow hands, which were basically um outlines of hands. Apple does this, of course, beautifully in some of their uh marketing stuff, uh, where you see some hands, but they’re sort of dark and uh maybe maybe slightly uh transparent, and the idea is you don’t want people to be focusing on the hands exactly, but you do need to see what the hands are, are doing, but you don’t want them to fully obscure the screen or the content. Um, so I experimented with that a little bit in a static format. Um, but I think that pretty quickly led to like, OK, this is OK, but we really just need to see the motion. But the idea of trying to do full motion animation using, I don’t know what after effects or something, that seemed like a huge production and sort of out of reach for our, you know, small team that has a lot we should be working on.

00:17:43 - Speaker 2: Yeah, we tried basically every way we could to avoid having to film live action hands. It’s quite hard, but none of them were quite satisfactory, and I think there are at least two reasons. Um, one is there’s this feeling you get when you use muse, like when you touch a card and it moves instant instantly or when you start pinching and it fluidly zooms in, that is really important, but it’s really hard to explain without just seeing it. I mean I really wanted to capture that. I felt like the only way to do it was video.

00:18:12 - Speaker 1: So yeah, you, you were inspired to do that and you dived in with your uh with your AV gear, which I know you’d already been kind of experimenting with in the past, partially at at I Switch, but also you’ve done a little bit with your uh virtual piano lessons here now and so I think you, you’d had interest in some of that stuff anyway, so you already had some of the gear. What, what was the final set up or what is your um hand recording studio now look like?

00:18:38 - Speaker 2: Yeah, so there are 3 pieces that are key. I found.

One is something to hold the camera. So we found that the top down shot is best. We tried other angles like looking at it from the side, looking at it like kind of over the shoulder, but when you have uh multiple hands and the screen, the most consistent way we found was just to shoot it overhead and I just use an iPhone camera works quite well. And so you have a tripod that’s on the floor and then it kind of booms over and there’s this little device that clamps onto the camera and it’s attached to this kind of ball and socket joint so you can move it around and so that altogether gives you the video recording.

Uh, the second really important piece is the lights, and so I use a couple uh commercial lights that are usually used by streamers for lighting themselves, but in this case I use it for lighting the hands and the desk, uh, and I use either 2 or 3. Um, lights from one from the left, one from the right, and one from kind of across the table from me.

Uh, and the third thing is something to put the iPad on. So an important difficulty we had back in the Ink & Switch days was we would try to film, I try to film the iPad on my wooden desk, but the thing is that then you have the horizontal line from the wood planks, the horizontal line from the iPad, and then the, you know, the horizontal line from wherever the camera is. Uh, located and so you need to line up all three of those things exactly or it looks really weird. And so I ended up putting the iPad on a leather surface which is sort of like directionless so you can basically um fix the camera and then line up the iPad exactly to line up with the camera and it doesn’t need to be lined up exactly with the desk at that point, um, and that was actually a pretty big uh unlock for us.

00:20:19 - Speaker 1: Hm. Yeah, that was something I struggled with a little bit was um even getting the the tablet square with the camera, which I guess you can, as I say, fix it in post, right, if you have sufficient video editing software, you can kind of even that out.

So I can see we’re having that many things I have to align would be a would be a problem.

And then the lights, uh, from all these different angles. I know that another huge one that we ran into even just giving a workshop, we would do kind of video chat uh workshops about progress on our research prototypes and the overhead lights in the room were just absolutely killer because that turns your, uh, turns your tablet into a little mirror and you see the person’s face, not to mention that smudges all over the place, you know, the finger smudges all over the place and it’s very hard to see what’s actually on the screen.

00:21:08 - Speaker 2: Yeah, so I’ve only partially solved this. So I turn off all the the lights in the apartment and I try to do it at night, and that gives you pretty good cover so you don’t have too much light coming in from overhead.

But if you actually turn off the iPad, you can see the reflection of the camera overhead. So currently it only really works when you’re on a fairly bright screen, which you’ll notice all of our videos have.

Um, I actually tried recording one with my stock, uh totally black iPad background, and there was a huge camera reflection in the middle of it, so I had to change it for the video. Um, but I think we could fix that with basically cutting out more of the external light so there’s less coming in from overhead.

00:21:42 - Speaker 1: And you say at night, is this about consistency that you want all the videos to have consistent lighting, or is it more about um the direction when it comes through the window, you can’t control the direction of the color temperature or whatever.

00:21:54 - Speaker 2: Yeah, just consistency and also the overhead thing. So if I have a huge window in this apartment, so if I do it during the day, you have some diffuse light coming in from overhead, which, which exacerbates that um reflection of the camera problem.

00:22:06 - Speaker 1: Do you imagine kind of going forward that when it comes time to add a new feature that we need to, um, then add a new kind of section in this handbook for? Will it be challenging to recreate these conditions? Do you have like everything’s written down of exactly where stuff should go or there’s tape on your floor or something like that, or is it not that important? Is it actually fine to have some videos that maybe have a slightly different. Feel or the tablets in a slightly different position in the frame or something.

00:22:36 - Speaker 2: I think there’s some forgiveness here, but I would like them to be pretty consistent.

Um, so as long as the equipment is sort of out, it’s not too bad.

And then in Muse, where I do the filming, I actually have a little checklists, you know, right in Muse, of course, um, and there’s quite a few things you got to get right. Like you got to, you know, make sure that uh your home screen isn’t weird, make sure that you’ve cleared out your, um, You know, iMessage contacts, they don’t show up in the share sheet. There’s a lot of little steps need to take um to actually do the filming, but once you figured it all out, it doesn’t take that long to run through the process.

00:23:06 - Speaker 1: Well, there’s the sample content element uh here as well and we’ve we’ve, there’s another one I’ve grappled with, um, when I’m often and for example, we want to show a new feature in one of the email updates and I want to show, uh, as much as possible, I try to show real boards either mine or other people’s when they, um, consent to share that and so you get a sense of what Muse is really used for in the real world rather than.

Something that’s kind of made up. Now, in this case, because I think this stuff was more, I guess, produced would be the word for it. It was supposed to be longer, um, it’s the word for it, a little more timeless. You did create boards that were not necessarily ones that uh you had in your, I guess your real used to call it that, is that, is that right?

00:23:49 - Speaker 2: Yeah, and we did them all around this theme of gardening, which is the same theme that we use for our onboarding sample content when you first open the app.

Uh, and we like that because it’s very, it’s very generalizable, it’s very relaxing, it’s very meditative, and those are, you know, properties that we want to encourage and use.

And also the I think the content that you would tend to want to film with is maybe not exactly the same as what you would use day to day and use, because basically, these videos get compressed down to pretty low resolutions and so things like bigger images work better for the video versus, you know, a whole page of handwriting.

It would just basically look like a bunch of scribbles from that far away. um, so it’s a, you have to kind of um be mindful of the medium.

00:24:28 - Speaker 1: Is it a problem at all that you, you’re filming a screen? Uh, I’ve seen techniques where you basically use a green screen, simulate the movements, and then do a screen recording that you composite in later so that you get the crispness of the pixels, but it seems like they came out, it seems like they came out pretty nice. That wasn’t necessarily a problem in the final video quality.

00:24:49 - Speaker 2: Yeah, that seems fine. And you know that the iPhone camera these days are are wild. Like this is a 4K camera with really high quality. Um, and so when you’re rendering down to something like 1080p, you have a lot of, uh, resolution to spare there. We have thought about actually doing the reverse and putting a green screen, like filming the iPad on top of a green screen so you can compos it in a different background, um, that’s either, you know, for example, maybe it’s always exactly the same, or maybe it’s actually transparent, so it just blends right into the the web page, um, but that’s, that’s pending, you know, our Amazon green screen order which because of the virus is.

00:25:24 - Speaker 1: Now, can you tell me a little bit about how, sort of, you, you and Leonard were the ones that ended up uh working on this towards the end, and you ended up with, first of all, that this is a web page as opposed to a PDF or something, so you need to load that browser separately alongside Muse in a split view or something.

And secondly, that most of the, um, you have all these videos that have, uh, they’re kind of these little cards that then have text, some explanatory texts below.

And I know some earlier iterations when I was working on it with you a little bit more, were much more classic heavy text manual, maybe the kind of stuff you and I have done in the past, like go by example or the rogu docs or whatever where it’s mostly text with a few figures. And at some point here, we realized this is just such a visual thing and especially if we get the videos, it’s really more Images and more imagery and just a little bit of text to explain, but I’d be curious to hear how you landed on this cards expository text attached to a video or a still.

00:26:21 - Speaker 2: Yeah, well, we knew we wanted the video from the beginning and so we started with something that was more like go by example or standard manual.

We have 1 or 2 videos per page and then a little bit of text, but then we found you only need maybe 123 sentences per. Video and so you have these pages that we mocked up and we did some HTML mockups, and it would just be very sparse and then you need this whole apparatus around navigating the documentation because you have multiple pages and then to get through all the docs and to get an overall sense we have to click through each of these individual links.

And so it was both more work for us and it was in a way less satisfying for the user because they didn’t um get everything they were looking for right away. And there was one site that we saw that was uh an inspiration. Uh, what was it?

00:27:06 - Speaker 1: Uh, Loom, kind of a new cool indie animation app.

00:27:09 - Speaker 2: Loom, yes, and they have a cool, um, manual page of sorts, which is in this style, but it’s all text. So I think it has the kind of two or three things per row and then a series of rows on the page, um, and we liked that one page idea, but then of course we want to bring our, our video. And then when we mocked it up, it it worked quite well, so we ran with it.

00:27:30 - Speaker 1: Another notable point on the cards that are shown, some of them are clearly news. Here’s how you move a card, here’s how you delete one, here’s how you navigate and out of boards. But then there’s also things like how to take a screenshot, which is an iPad or an iOS feature. Uh, there’s some other things that are, are like that as well, like search. How did you decide where the boundary between what you can do with Muse and the full capabilities of the operating system? What, what caused something to be in or out of that list?

00:28:01 - Speaker 2: Well, we wanted to include all the things that you might want to do with Muse, broadly defined.

So for example, bringing in a piece of content from another app on iOS into Muse is something that involves Muse is an important and our experience with iOS is that There are all these, these important platform features that people don’t know about. Even very experienced iOS developers and advanced users are surprised when they see uh some of these workflows, you know, whatever the magic gesture is for bringing up search or like sharing between apps or whatever.

Um, and so we thought it was quite important that we gave people those instructions because without it, they might be missing this key piece of how you actually use Muse in the context of iOS.

00:28:42 - Speaker 1: This is a good reminder that one of the challenges here is iPad OS is moving in this direction of becoming more, more, more capable, more powerful, trying to be a tool for professionals, but it comes from this, uh, legacy or this foundation of the iPhone. And the iPhone, of course, was the iPhone you could argue is maybe the most successful product, certainly the most successful tech product of all time, and partially that’s because it took the complex world of computers that was always. Just out of reach for maybe a lot of The mainstream world, people who weren’t um Sort of computer nerds, so to speak. The iPhone helped make it so that everything was kind of um comprehensible without a manual. And in fact, I would say it’s part of the design ethos in the mobile world. And probably for a good thing that if you need a manual or you have a manual of some sort, you failed, right? That the um the classic uh refrain from the computer message boards, RTFM right? that’s read the fabulous manual, is something that is a legacy of the desktop operating systems where things were just too complicated. And that now in this enlightened mobile era where everyone’s got smartphones and you expect to download and install an app, and you should be able to figure it out by kind of pawing at the obvious buttons on the screen within 10 seconds. And in fact, if you don’t figure it out, you probably delete it pretty quickly. But that’s not really viable. In fact, that’s not even desirable for professional tools. You want something, of course, they shouldn’t be specifically hard to learn, but a learning curve, if it pays off with more power, more flexibility is worthwhilele.

But now you have this, not only this, um, the whole operating system of iPad OS and the device and all that sort of thing, but actually a design ethos, a design um set of um values that comes from something needing a manual as a bug. Versus what I believe, which is that a product that comes with the manual implies it has depth, that it fits together with being a professional tool where probably the things you want to do with it are things that require skill and take time to learn, even separately from the tool itself. Whether you’re writing, whether you’re creating art, whether you’re doing science. These are not things that a person figures out by pushing a couple buttons, obvious brightly colored buttons on a screen. There are skills that you learn, and the tools that go with it are skills as well.

00:31:08 - Speaker 2: Exactly. We want the tool to be as easy to learn inherently, but no easier. We don’t want to sacrifice uh the power, and the capabilities on the high end. Um, for the sake of that those initial 2 minutes. That said, we have tried to meet our users, uh, somewhat in the middle because they often are coming from this mobile world where this expectation is very strong. So you can open this manual with one link, it has high production value, it has this kind of YouTube style, very quick to ingest video, um, so I think that helps a little bit bridge the gap between the standard mobile world and this world of professional tools.

00:31:43 - Speaker 1: That also reminds me of something you mentioned earlier, which is onboarding content, which is sort of the industry term or um as you likes to call it the out of box, AKA UI experience.

So the onboarding content is what you see the first time you open an application. Sometimes there’s a little tour, uh, but I think for creation applications, it’s kind of nice to show content that is in the format of the application itself. So, for example, I think Bear, uh, which is a really nicely designed notes app, it just comes with some default notes that are in there that essentially explain how to use the app and will show you what its capabilities are.

Notion, I think loads up with some templates, that sort of thing. So we explored this quite a bit. We, we had a couple of major iterations of our onboarding content where we tried to include sample boards and some instructions and we would walk you through all the things.

And I think it, I don’t know if it’s a legacy of that kind of iPhone world where people just want to try it, they skip all the tutorials, they just ignore anything you put on the screen.

They just want to start trying stuff out. And and I understand that because honestly I do the same thing, but what we discovered in some of these usability tests when we would try out our onboarding content is that people not only did not read it, they thought of that stuff as being in their way and they were pushing it out of the way, deleting it, erasing it, just trying to get past it, but then they would get frustrated and stuck because they didn’t, you know, the interface had these different uh approaches that they didn’t necessarily know, and then they would then they would sort of feel stuck.

And that led us to thinking. OK, we’re not gonna, we’re not gonna get it with the initial content. People just want to play, they want to try it out. And that led us to this garden themed, um, content we have now, which explains fairly little. It just gives you a little playground or it gives you some elements to play with. And then there’s a tips panel you can go read when you wanna kind of go to the next level.

And now we’ve got this handbook. I doubt that’s all we’ll need, but I thought it was interesting that we made this journey through trying to solve the, how does this thing work through onboarding content and eventually deciding that was a dead end.

00:33:47 - Speaker 2: Yeah, and I think it’s notable that in most Pro Tools you get the totally blank page.

So when you first fire up the eye, for example, it’s like the super intimidating black screen.

It’s actually quite hard to figure out how to do anything at all, um, and that’s, that’s kind of standard in the Pro Tools world, but that actually points to a third leg of the stool.

So there’s how is the tool, how easy is the total. on its own kind of intuitively, there’s the manual and there’s the kind of social element where with a tool like Photoshop or VI there’s often someone who’s basically teaching you or encouraging you or giving you pointers, and we haven’t explored that too much with Muse, but I think that will be an important uh third leg in terms of how people learn to use the app and learn to be productive with it in practice.

00:34:30 - Speaker 1: So looking forward to the future here as we add new capabilities to Muse, uh, we’ll want to document those.

My experience with documentation, one of the challenges there is keeping it up to date when you have a fast moving, agile team, you’re cranking stuff out, uh, and it’s easy to overlook that when you’re shipping new stuff or it feels. Maybe like a costly step or the people who are making the documentation aren’t totally plugged into what you’re creating.

We’re obviously a small team here, so maybe that helps avoid some of this, but then we have a new problem I guess which is that as you said, these have pretty good uh production value that you really invested a lot in.

How do you have ideas for how we’re going to keep this up to date, or do you expect there will be periods where they’re, we’re testing new features and those just aren’t documented, and then when we sort of decide they’re going to stick around or whatever, then we, then we lock it in by putting it in the handbook.

00:35:26 - Speaker 2: I certainly hope that the handbook continually converges to the real state of the app.

It’s tough though, you know, I’m tempted to just say be diligent about it, uh, but our mutual friend, Peter would say that diligence doesn’t work. Um, one, One idea I have here is leaning on the handbook for sort of marketing purposes. And in the same way that uh document, documenting your product forces you to think through the user experience, I think the uh the expectation that the material is going to be shared in a marketing capacity is going to encourage the team to like really think through the quality of it and make sure it’s complete.

Um, it’s just things like when someone asks, how do IX with Muse, you send them the anchor link in the handbook to that video. Um, I think that kind of constant exposure will help maintain the quality.

This, this actually reminds me of another adage about data quality in here the data quality is like kind of the handbook quality. It’s that data quality is a function of how often and how thoroughly the content is read, not how carefully it’s written, um, and so the more exposure we get on the read side to the handbook, I think the better it will be.

00:36:33 - Speaker 1: Canonical URL for something is an incredibly powerful thing in my experience, whether it’s internally in a team because I don’t know, you have someone new joins the team and they say, wait, how does X work? and you could send them the internal Wikilink or whatever that describes that. And then externally, yeah, when you’re doing support for your customers, someone asks on Twitter, whatever it is, and you can basically just respond with bang. Here’s a, here’s a URL that explains it all.

Often when you go to do that, you say, oh, this is, this is documented, it’s in our manual or whatever, but then you realize there isn’t a good link to it because there isn’t an anchor tag or it’s kind of spread around a couple of different areas. There isn’t one like single place to go to get that crisp answer. That’s exactly what they’re, what they’re looking for and, uh, that’s a chance to potentially go and prove it. Good. Well is there anything else on the topic of manuals we should, we should talk about today?

00:37:26 - Speaker 2: I think that covers it.

00:37:28 - Speaker 1: If any of our listeners out there have feedback, feel free to reach out to us at @museapphq on Twitter or hello at museApp.com via email. Love to hear your comments and ideas for future episodes. And Mark, congratulations on your new career as a hand model. Thank you. It’s great work and uh I’m really glad to have it out in the world. Thanks Adam. Alright, talk to you next time.