Loading summary
Transcript47 lines
- [00:00]
A
When you're spending two, three hours a day in a tool, it's a little bit your digital home, your digital environment. It's almost like when you look at home offices, which people have, where they spend a lot of time, they're a lot more decorated, they look a lot nicer than they used to back in the days when we only spent a couple of hours. I think this is a very magical thing of being able to build a product you use every day very extensively is just that connection and that intuition of what could work is such a core part of figuring out how to move forward.
- [00:31]
B
Welcome to Dive Club. My name is Rid, and this is where designers never stop learning. This week's episode is with Ballant Oros, who's a co founder of craft, which in my opinion is one of the most beautiful products in the world today. But it's not just me. They've won countless awards, including Mac App of the Year. So we're going to do a little deep dive into how they work and what it takes to achieve this level of design excellence. And a big takeaway for me is just how the level of ownership and experimentation that's expected of designers. But before we get into all of those details, I asked Balin to give us a quick rundown of the CRAFT origin story.
- [01:12]
A
Every, you know, engineer, you know, person using computers always has this, you know, dream of creating a productivity tool they use every day. And. And I was no different. I think for me, this became a really exciting opportunity as I had a company which was acquired by another company, which was a lot bigger company called Skyscanner. This was in 2014. This company had 10 offices across the globe, which also meant that product engineering and my team was pretty much across the globe. And in my day to day work, this meant I needed to do a lot of asynchronous work. You know, nowadays it's totally normal, we do everything in Slack, everybody's remote. But at that time that was quite weird because usually everybody was at the office end and you could do all of this. But then I realized I need to use email for everything, right? You know, for short notes, for explaining long things. And eventually you realize that it's really, really hard to get deeper thoughts through email. And I think that was the point where I really, really started thinking about, okay, why do we still have this? Still this basic format, every document is this linear thing when clearly we're getting more and more information, we want to attach more and more data. And I think this was kind of the problem. I was Looking at there, I just couldn't really believe that we are in kind of like, I don't know, 30, 40 years of advanced computing and we still don't have anything better. And then I started thinking and of course I realized that we do have something better. That's how the Internet works, right? You know, it's hyperlink, it's hypertext. In fact, it was invented, I think in the 70s sometimes, you know, a long, long time ago. But eventually what happened is it's every time somebody tried to create a hypertext editor, it always became too complex. And kind of my idea was of if we create a hypertext editor for mobile, right? You know, that by definition needs to be simple because you can only have so many buttons you can put there. There's only, you know, so many things you can fit on a small screen. And once you figure it out for mobile, you can scale it up for desktop and it still remains simple. So that was the core idea, and I think that's how the whole thing started, of how can we create a system that is easier to manage information and thinking specifically while you're on the go on mobile? And then of course it grew and it evolved. But I think this kind of frustration of there must be some way better to represent information and to work on it across devices.
- [03:40]
B
It's interesting, that theme of starting from mobile and using that as a constraint in the early days to force yourself to arrive at a new simplicity and kind of break the mold of what has become the norm has been a theme like that's popped up multiple times. I was just having an episode with the co founder of Play recently and he shared the exact same thing. It's like, you know, we knew that this was probably going to be on web, but if we started on mobile, we would also guarantee that we'd arrive somewhere different.
- [04:08]
A
You know, I think by the time it was 2017 when I really started thinking about it, people already said mobilis figured out, right? Because, you know, it was no longer the new avenue. But I still think there's so many things to figure out, how it works efficiently. The way I would articulate it is the age of the free exponential growth of, you know, you needing to conquer another platform is over. But I think it's still such an interesting, you know, domain to think about.
- [04:37]
B
Real quick message and then we can jump back into it. One of my favorite parts of the recent episode with Smith and Diction was hearing about Mike's experience generating brand imagery using Visual Electric. I was already in Visual Electric because It looks like Figma, it feels like Figma, it operates like Figma. And that to me, I was just like, I was comfortable. I felt like I was like, I can move around in here with confidence. I think that's exactly why I love the product so much too. And sure, it's the most photorealistic image generator out there, but it's also so clearly built specifically for designers, and every single part of the UX is elite. So this is a reminder that you can get your first month for free using the code Dive Club. Just head to Dive Club slash Electric to get started. Look, I'm not a motion designer, but I'm working on a new product right now and I've been using Jitter for everything. And it's honestly a cheat code. I've been creating Lottie files, micro animation show reels for Twitter, and I didn't want to use After Effects because it would have taken me all day to figure that stuff out. But there's no steep learning curve with Jitter. The whole product is super intuitive. They even have incredible community templates that I've been using to jumpstart my project. So even though I wouldn't consider myself a motion designer, I feel like Jitter gives me superpowers, which is why I can't recommend this product enough. If you had to Dive Dot Club slash Jitter, you can spit up something stunning in a matter of minutes. Okay, now on to the episode. Well, I know when you were first starting, maybe this was a little bit more of a novel idea, but the fact is today, you know, we're recording this in 2025, the year of our Lord. This is a pretty competitive space now, so can you talk a little bit about how you think about differentiating craft in the market today? And then how does that differentiation influence the way that you design the interface?
- [06:28]
A
You know, this was a competitive space, I think 10 years ago, five years ago, 50 years ago. It's a little bit like, you know, wetter apps, right? Everybody builds one and there's tons there. I think for me, the biggest frustration and what really focused was one really important was, is I have a huge respect for the devices you purchase and the devices you buy. And I think we choose specific devices because assuming there's less of a monetarial constraint, which is for some people, but for a lot of people, specifically in the Apple ecosystem, that's less of a concern. They really want to get the most of it and they really buy it for the design language. And I think around when I started, but even Today there was this big trend of just build a web app and package it inside of a desktop product with electronics. And while there are nowadays, I think some products that do it very, very well, where you don't notice on mobile, it gets even worse. So I think one of the really strong differentiator we felt we have is we always want to be as close to the hardware as possible, which should result in the best possible performance. Now, this might be hard to measure because, because maybe from when you press a letter until then appears a screen, it's 5 milliseconds versus 10 milliseconds, which some people might say you cannot even measure. But when you add up all of those, how fluent the product feels and how it makes you feel when you use it, I think is really important. And when you're thinking about a tool for thinking, for writing, I mean, an Average user spends 2, 3 hours a day working in Craftsman, it adds up. All of the small unnoticeable frictions add up. The other part is eventually, I think as companies grow, there is this very strong pool of, okay, you now have a lot of user love from individual users. You need to scale. And one very trivial way of scaling in the past couple of years has been going into B2B. And that creates then not just a natural desire to grow the business, but a different set of principles of who you build for, who is your customer. Eventually you go from having individuals using your product, being your customers, to managers making buying decisions, making those customers. And however you try to balance user experience and all of those, the incentives, the culture, everything adds up to really building a product for the manager and for the business. And because they are the ones paying, they're the one making the request, and they're the ones you're talking to. And I think what, what we are trying to do very differently is we, we want to keep building for the customer for, for a long while. And even now, often the biggest question with these businesses is how big can they be? Right? Because B2B companies can pay a lot more. And you know, that's probably true, but I think there is a sufficiently large market of individuals who want to use amazing tools which can make a company like Kraft be successful and sustainable in the long term. And I think that is a fundamental value for us is we're not necessarily willing to chase growth because of the money or the profits it can do. And of course we're venture capital funded, so we do aim to grow. But we really want to be honest to those principles of just creating a really nice piece of software. And following that line of they always say it's not enough to build a good software, you need to market and everything. But there are examples where you build it, it gets better, people keep talking about it and growth eventually accumulates. So in other words, I think a big chunk of our focus, both when we look at what we prioritize in feature development or where we invest in hiring people, or what type of talent as a company is really around building the best product out there possible for the end user and saying no to all of the other things that are very shiny and potentially have a strong business growth potential, but also risk essentially the product diluting and becoming less streamlined and more clunky.
- [10:55]
B
I want to go a little bit deeper there because I think a lot of note taking apps, maybe even if they could say something similarly, what ends up happening is they design an interface where the goal is just to get out of the way. Like it's like the bare minimum UI possible and it's pretty clear that's not what you're doing. So can you share a little bit more about what are the north stars or principles that are guiding the way that you're designing craft?
- [11:21]
A
In some areas I always tend to refer to, you know, there are interactions in a product which you, I consider skip pages or skip interactions, like things you don't want to think about, you want to get over with and you want to use there. I think the UI elements, the UX patterns that you don't notice them, you make it unnoticeable. I think one of the really good example of this is the iPhone's pin or SIM pin entry screen, right? It's a plain text fill type of thing. It's so on iOS. But you can see, they say this screen is just so you see it once ideally in your lifetime and then you never see it again. So it's not about the light. And then there are other parts of the product where you do want to have a very positive emotion feedback loop. It makes you feel more connected to the product, it makes you feel better. And I think that is the hardest thing for us often to figure out is are we building a core interaction and are we doing something special here which deserves a very strong extra attention because too much of these just makes the product feel like popping everywhere. Like an animation here, an animation there. It's all not harmonized and it makes it feel too much. But if you don't have this, then it feels way too dry. So I think it's, it's around that balance. And we again, it's a little bit for us, we feel that when you're spending two, three hours a day in a tool, it's a little bit your digital home, your digital environment, like, you know, it's almost like when you look at home offices which people have where they spend a lot of time and they're a lot more decorated, they look a lot nicer than they used to back in the days when we only spent a couple of hours in. So I think there is. This also is in this nature because craft is, I think, a lot more than just note taking. People use it for thinking, sharing documents, creating long form content. They're spending a lot of time on it. And we really want people to feel home inside of it. And I think that is why we're not necessarily looking at everything on the bare minimum, but trying to balance and figure out what matters and what feels good versus what, what would be just too fancy or too much.
- [13:34]
B
I would imagine it's not always obvious where that line exists. Like something like the doodle separators comes to mind for me where it's like I've never seen that in any other kind of app. It's so playful in a way that really distances itself from utility and it feels fresh. But yeah, I could see how like that spectrum of like just how personalized and just how many abilities do we give users to make this their own is probably one of the core debates that's happening internally.
- [14:06]
A
It is, it is, I think. And we often get it wrong, you know, so we often have things that we do something and users say this is too much or we're using it for like six months and feel that this isn't working, this is too much. So I think it's a set of experiments and a lot of these come from our own, you know, way of doing things. Like the doodle separators came of one of our internal team members, you know, kept uploading PNGs as images which had these doodle separators because, you know, she wanted to use it and people start liking it more and more and more. And we were like, okay, but you know, could we make this then, you know, a core feature? And of course, when we're making it a core feature, when we think about it, okay, it's not just about we like doodle, but what if somebody else like something else? So that's where I think the customizable Washi tapes which, which open up a lot more variety came into place. But I think this is a A very magical thing of being able to build a product you use every day very extensively is just that connection and that intuition of what could work is such a core part of figuring out how to move forward.
- [15:15]
B
What are some of the challenges that come with designing a product where content is everything and pretty much all of it is user generated, so it can almost take any shape.
- [15:25]
A
I think one of the big challenge for us always has been is what is craft and what is your content and where is our brand and where is our brand Too much. And I think that resulted in us, for instance, we don't have, I think, a sufficiently strong brand, you know, nor visually in other ways. And it's really hard for us to figure it out because as I said, we want this to fill your space. And you might like our brand colors or you might not like, but we cannot be too aggressive with this. So I think early on, as I thought about how can we still make craft beautiful? Because it's a lot about text and documents and it's not like Netflix or Spotify, cover arts and all sorts of beautiful things. So from early days we said we should put your content everywhere as a design element. So essentially, if you create colorful documents, your craft should become colorful. If you create black and white documents, your craft should become black and white. And we really heavily invested in technology of being able to just render pixel perfect representation of your documents everywhere you are in the app using a lot of, when you enter a document, the whole window, you know, takes over like ambient lighting from that document from the background, current things like that. So as you move forward, the whole product in some way, you know, reflects the content you're looking at. And I think this is, this is what we're trying to do and emphasize and this is why we're moving also a lot in understanding options of how you can easily find, find styles and customize your documents. And through that, just make the app feel more like you. And it's so super interesting because when we look at some videos of Japanese users, for instance, do we have this grid format of you can view your documents as a grid on your home screen. And then if you have a cover image, we have a full size cover image. And their craft looks like a Pinterest word. They always add cover images and they want to have that layout. But my craft, I never add cover images. So it looks a lot more like, you know, traditional documents application. But it's just so fun, I think, to see of how people resonate with that and really customize it to make it feel again home for them.
- [17:49]
B
How does that influence the way that the team works? Like even just the way that you approach dummy data? Like whenever I'm designing products that are heavily user generated, it's always kind of a lot of work to make something feel real. How do you approach that problem?
- [18:04]
A
I have a few, you know, weird beliefs about me. Like, you know, I don't really believe that except for certain circumstances, user testing on non real product drives, you know, reasonable results. And one of the really good examples of that is again, in my previous job at this flight meta search engine, we tested two variants from the same product or the same feature and I wanted to hack the system. So I said, okay, let's have you know, the first variant has, you know, $100 flight prices and the second variant has $1,000 flight prices. And essentially the cheaper or the more expensive variant one, you know, and it became the better one. I was like, you know what our customers say? The only thing they come to the site is because they want to have the cheapest, you know, flight. So. So it's quite clear we've been testing with people who didn't have a real intent to use it and they engage very different because I show this to a real intent buyer person, they will be like, this is the worst product I have ever seen. So I think this grounded these things of. We prototype most of the things in the main product and we use it and we have beta programs. So actual users who use craft interface it and use it. We use FIGMA and design tools a lot, but we think about that as the initial phase of sketching and figuring out layouts and laying out concepts. But except for some very small minor features, we never, I think ever had a thing where the final Figma design, as it were translated one to one to the Reese features. More often than not we have significant changes in how certain things behave because it is really important to just use it in context and see the challenges and the benefits of a product in context. And it's interesting also because there are some of the things that we fall in love with the prototype with. We say it's a. It doesn't feel like a good idea, but the moment you touch it and interact with it, it just becomes something magical. So I'm very, very big fan of this. This part of move into the real product as quickly as possible. It might be in the web, in the app, but see your own data and see the exact workflows you have there.
- [20:20]
B
How does that impact the way that designers and developers Collaborate.
- [20:23]
A
Then most of the projects start in the traditional design phase, where we iterate a lot. In Figma, let's say that is 50% of the project, and then the other 50% is designers working really, really closely with engineers and having a very strong feedback loop. And it's challenging, I think, specifically when you're hiring. So the people we have kind of really, really enjoy that. And they have a deep respect for each other, design and engineering. And engineering's not pissed off if we need to throw away something. They're not saying, hey, you should have done a better job at designing in the first place. And kind of designers are not upset if they need to change the design for some performance considerations. But it is not that natural. Specifically in larger organizations, I think in smaller companies, you see this more often, but it is just something you have to calculate with. But the really good thing about this is that as the more engineers interact with designers and vice versa, each of them understands domain better. So our engineers know about paddings, the importance of them, animations, curves, how do they work? So you could also look at this as you do train people, right? They train each other, which results in having better partners in your work because you can move faster and you can do stuff. So we do have quite a few comments, for instance, from our designers in the code. And we do ask our engineers to create code that designers can read. So all of the variables around paddings and animation curves and colors, well named, separated, so any of them can go in and tweak those. So I think it's a lot of fun once you get used to it. But at the first, it can be intimidating for some.
- [22:08]
B
How much are designers getting into the code?
- [22:10]
A
It depends on the designer and on the shape of the project. So there are some designers who kind of prefer fix things themselves, and they prefer to tweak parameters and go into the code and build prototypes. And there are designers who do that if that's needed, but they'd rather sit next to somebody or have a call and explain, you know, how they think about it. And, you know, very quickly build and test it that way. So there's no real strong requirement around it. And kind of obviously then those designers who code less, they are better communicators. And, you know, they. They speak better with developers and smile more and engineers and designers who code more, they have less reliance on that. But it's funny because everybody figures out their way.
- [22:58]
B
Okay, so I want to keep going like way deeper into how you work. But maybe first we could just Give people a little bit of context. So what's the current state of the team right now? How big is the design team? Anything else that you want to share in that category? Just so people understand the lay of the land?
- [23:13]
A
Yes. So total in the product engineering, in the company, we have around 25 people who are doing the back end, the web, desktop and mobile apps. And kind of when we look at then you know, platforms and team, we have a, you know, three, four person design team. Three, four person app team, three, four person web team. I think, you know, a four person backend team and kind of, you know, two, three people in qa and we don't have product. So I think kind of most teams are part of this three, four people size. It's a fun size. Everybody knows about everything and very often team members can jump into each other. It's also a challenging size because you're enough people to do anything, but it's not enough people to do everything right. So it's a tight balance of what you want to get right.
- [24:06]
B
Okay, so I want to pick a project that we can talk about to use as a lens to learn a little bit more about how you work. I'd really like to hear about the quick add feature on mobile. I keep seeing that on Twitter. It's beautiful. Feels like a breakthrough pattern. And how does something like that go from the seed of an idea to hitting production?
- [24:26]
A
That was a very, very fun project. So essentially we had this big project called Crafts 3 where it was, you know, a very, very big update. We've been working on it for six months, new features and it included changing the navigation of the iPhone app. Right. So, so around one, one and a half weeks before the launch, we kept laying this project of, okay, but how will you create something new? Right? Because we knew our existing new screen as people don't like it. The way it worked is you press the plus button and then a list came up. Do you want to create a new task? A new reminder, A new document was too much cognitive load. So we said, okay, but kind of the solution is quite clear. We just need a context sensitive new button on every screen, right? So if you're on a task screen, it creates task. If your documents can create a document, a calendar, A calendar. And then if you long press it, it brings up the menu. And we kind of designed a prototype that and kind of our, our, our, you know, head of design was like, you know, this doesn't feel right. I mean, I mean I get all the logic behind of it and, and it should feel right, but it's not. And we were like, I think, you know, five days before launch at this point and, and, and kind of, you know, we have my co founder Victor, who's kind of the orchestration of. And we were telling them, you know, we have a problem. He was like, go figure it out. So when I first started craft, it was about quick capture. And the first part was I said, chat is the dominant interaction on mobile, so let's do tag text input like it is in chat. So when you press the plus, the keyboard opens up and you type in that small chat button and when you press send, then that content gets added to the document. And I had a screen recording of this prototype which I built like five, six years ago and I gave it to the designers of maybe there's something here. And I think three, four hours after there was a first Figma prototype, the next morning we did a basic interactive prototype. We said, something's there, but it's not perfect. But I think after two days of this very rapid iteration, we landed into understanding of the reason why this works is when you press the plus, you know what you want to add into. So you need to get that out on your head and you can choose afterwards because you're relieved. I have it out there now I can decide where I want to put it. But I also think this is a. It's. It's both a very common way of how we do things in a very uncommon way. So. So technically I believe that ideas are super fragile, right? You have this random idea and either you act on it almost in the moment and try to make it work, or it's going to fade away. It's not like ideas can be put on the shelf and we have a huge amount of these. Let's act on this, which totally don't work out and go in the bin. But some of our best features, some of our best concepts come out of these very fragile and very rapid interactions. So much so that from user feedback, from what we're seeing quick add, it's clear that it's becoming a lot more important in the product. And we have a lot of things planning which we can build on top of that. So it's fundamentally interesting how a fleeting feeling of this solution is not good enough. Let's try something radically new, have that idea do it can lead to. Then essentially we're going to have a three, four months more structured project around how to get a lot more of the quick add. And this type of let just people get from Their head into craft a lot faster.
- [28:04]
B
I love that because you're not just solving the problem in an interesting way in the 11th hour, but you're also identifying a building block that you can use throughout the rest of the system.
- [28:13]
A
Those are the best ones. Again, out of 10, 20, 50 of these ideas, one ends up being this successful. But you do have to do all of them because you never know up front. Right.
- [28:25]
B
So I'm a big believer in this, you know, acting on inspiration in the moment. And a lot of times when we're solving these problems, that's what sparks the ideas that, you know, send us down this rabbit trail. And yeah, maybe some of them do work out really well. Kind of the flip side of that is a little bit more of the strategic planning and roadmaping. Can you give us a sense about how you approach that at craft?
- [28:45]
A
So I like to joke, and there's always some truth in these jokes, that in craft, we have two roadmaps, we have the next two two weeks and we have the next one year. But it is in some ways true in a lot of ways, because we really want to be able to act on the things we learn and act on the insights we get while delivering things. And we also want to have space for experimentation. So if we would need to have a three month roadmap, the question is, okay, but you know, how do you fund non critical projects which might become something, you know, super, super important? And I think, you know, having this every two weeks, you can reevaluate. If you want to fund an idea more, fund the project more. There's no pressure that you like. We, as a leadership, let's say, need to commit to, you know, one project that seems powerful for three months. Every two weeks we can have a check in and see if we still believe in it. If the progress is, is, you know, going towards what feels good operating on.
- [29:49]
B
Two weeks in a year, like, I can see a lot of benefit of that. And there's like the flexibility, room for experimentation. Can you talk a little bit about how designers can either fill in the gaps or even like what it looks like to effectively make a case for why something is worthy of that level of investment?
- [30:09]
A
Yeah. So I think also a roadmap has around 50% of it is what I would call reactive. Right. So we do something, we realize something is missing. Like we release right now tasks and people really want to have recurring tasks. So that is a project that is reactive. It's more kind of a formal, let's say we fund that and we do that. And then there is this other part where let's say you know things about what we want to do with AI and it's clear we don't want to do just AI for the sake of AI. But we're starting to get a really good feeling of, of what could work and for instance how we could create an interface that merges voice with keyboard with mouse with touch and you can switch anytime. It's kind of a conceptual phase and kind of, you know, the designers who really want to do things like that, we a little bit expect them to take initiative, have come forward with idea and almost say, can I spend a week on this to figure out more? And then we say yeah, spend a week on it. And after a week they're like, what did you learn? And do we want to do another week of work? But next to AI, a really good example of this is we're now experimenting with shaders. So when you look at animation and design, it's quite clear that we're reaching peak moving rectangles beautifully on the screen. Apple is doing a really good job at showcasing how shaders on the screen can create really nice effects with the new Apple Intelligence. But also their airdrop effects. It has a, a new sense of magic and we feel for certain wow moments. We could use that very well as well. But we're never going to fund a three month project for that. Right. So what we kind of want is somebody to come forward of they feel, you know, for some reasons and I think for us to breakthrough is that LLMs can now generate shader code. Right. And because it's very hard for designers to understand shader code, even for engineers, it's hard. But with that insight we're saying of we actually have a shot at prototyping shaders and getting a feel of how they work so they come forward and usually it doesn't happen of, okay, you can do that from tomorrow, but in the next two week cycle we can already plan in a way that there's a couple of days, a full week or something like that where you can go and instrument with that. So in this sense we do expect designers to be a lot more ownership oriented of figuring out what they feel is right. This also means thinking more about the product as well and understanding customers. And I think this is also this designer engineering collaboration and designers taking lead is why we don't have a traditional product management layer. Because designers pretty much together with looking at engineers, collaborate with customer support, understand user feedback, end and kind of see the whole Picture which makes them able to detect and suggest these opportunities. And then for instance, I also have sometimes a few AIs drop those in, maybe somebody picks it up. So I think this is more of a 5050 type of ballpark rule of reactive versus trying to be more experimental.
- [33:14]
B
Yeah, I mean honestly, it sounds like a blast to work in that environment because you do have to wear the product strategy hat a little bit. Like you have to think about, okay, what do we need here and what can I push forward to make that happen?
- [33:27]
A
You know, these things are always. Because everybody wants ownership. But fundamentally a lot of people get scared when they see the responsibility that comes with ownership and decisions you need to make. It's very hard to take ownership on something. It's for people who don't do well. It's a lot of stress, they can get burned out. But if you. I always tell people of we are creating digital note taking software. We run, are really careful about data security, syncing, stability. Like we don't iterate there. Like everything is heavily tested so there's never ever any data loss. If we create the wrong type of animation, we're in that concept of we'll just remove it. So we want to be very playful here. And it's interesting because some customers like that and some users just hate it. They say like, you know, hey guys, you're changing something every six months or every three months and I just cannot take it anymore. And in some ways they're right. Right. Because when you change something, you need to relearn something. But we still feel where there's so much we need to figure out to arrive to a point where, where we're happy to, you know, spend a lot more time saying this is good enough, that it's just something we need to be very conscious of, of doing. So yeah, it's. I think it's a trade off. You get a lot of ownership, but we expect a lot of responsibility and expectations change.
- [34:47]
B
Can we talk about the scale of change that's happening? Because you've been working on this for like six years and even I have been able to notice some pretty significant interface overhauls. So is there an example you could talk through about like, hey, this is why we arrived at a somewhat larger change in how we approached it.
- [35:06]
A
Most of those are, are typically when the existing architectures start to break. So for instance, the very, very first version of Craft was just a stream and you had at the bottom a segmented control. One was recent and one was archived. And we said kind of your documents, your Note taking should be like email, right? You have search and then you have one stream of things because then it's very simple to navigate. But then people came and they said they want to have folders and we're like thinking of, you know, that's reasonable. People are used to folders. You know, Apple tried to avoid having files and folders on the iPhone. They resisted it, I think for 10 years. But even they said like, they cannot do it. So. And then you realize, okay, you need to redesign the navigation, right? Because, you know, folders don't fit well in the segmented control. And I think this is what we face is since we only, even when we talk about our vision, we really have a one year of more concrete understanding where we're going to be. I think I can paint a very good picture where we're going to be in one year, but I don't know where we're going to be in five years. And the thing that happens in a lot of companies is they end up as they expand and you know, shift focus areas is you open a screen and you have 36 buttons. So like, you know, all of them are beautiful because they have a design system, but it's 36 buttons. And eventually that complexity adds up. But because when you have a more mature user base changes so hard. So you always reach a phase when, you know, not changing ain't that bad because if you're making money, you're risking losing money. And there's a phase in life when, you know, Amazon had this. It's always day one where you just say aggressively, we want to change. And for us, whenever we introduce features or new concept, like, you know, even right now we already have five tabs in the iPhone app, right? So you cannot have six. That's too much. But if we really double down on quick capture, that probably needs to have its own tab as well. So then what do you do? You need to simplify something so you can expand in other areas. I think most of our redesigned are really about us looking of with every phase we want to have a somewhat scalable system, but we never really think about how it's going to scale for five years. We try to focus on how for the foreseeable future, this structure and this design handles what we want, knowing that we might in one or two years need to override it and we're okay with that.
- [37:34]
B
I want to talk about another project really quickly, which you have you mentioned briefly, which is the tasks in Craft three, because you've basically made those a first Class citizen now. And I'm always interested in hearing how teams design features that have like a ton of precedent online. Like in many ways tasks are a solved problem. There's so many examples to pull from. So how did you figure out what the design of tasks would be inside of craft and what your take should be?
- [38:02]
A
I was so shocked of the complexity of that project because as you say, it's a frickin task, it's a checkbox. What can be so complex about it, right? And these problems end up being the most complex problems because you know, the whole task project came in the way where, you know, people have been telling us they need databases in the product because they want to store more structured information. And we're like, why do you want it? And they're just I need it, I need it. Okay, okay, you need it. So we said, why don't we build, you know, more structure in the product? Because kind of that's what we felt. It's not databases they're after, but they want to have information easier to access recall in a more structured way rather than just free form search. So we built this thing called objects. So every document you created could have, you know, attributes and you could use create these very interesting systems inside of space. And we used this in a beta for like 2000 users. We've been talking to those users and things like that and we're realizing 90% of them were creating two type of object types there, projects and tasks. And the third one was people, right? So the CRM use case. So we're like, aha. Okay, so now we understand why people want more structure. Why? Because where do you need structure most? Like project management, right? You want to make sure you have an overview, you want to see that. So we were thinking of, okay, that's great, but there's probably when so many people want this functionality, we need to make it a core part of craft because we already have something called checkboxes which relate to that. So then we start looking at how do we solve this? Because fundamentally there's two ways you can solve this. If you solve it for the individual user, you have a checkbox, right? But if you want this to work collaboratively, you have this table type of thing where you have a status dropdowns and it's no longer a checkbox. And then we said, yeah, kind of we want to have the checkbox because we already have the checkbox and we don't want to have another type of thing. And I think through this thinking we also realized that the Reason people want so much overview of task and Craft because when they write their notes or documents, tasks come in there in context. They already have the surrounding context there, which other task manager apps don't have it, and that's why it's more valuable for them. So that's when they said, okay, everything should be built around the documents. So that's when the task page, you have, you know, everything organized from your documents. But there was this thing of the quick capture. Right. Of with tasks, you have this thing I just want to quickly added to my inbox, which is really much around the GTD mythology and that's where we ended up with that inbox. But it was a super long process from identifying there's something there to actually figuring out both what people want and what is, I think the way I'd say what feels natural inside of our product because there are so many ways to do this well and I think there are so many different implementations of this. And what was for us, very important that it works seamlessly so you don't have to change your workflow or as we introduced it, it won't upset your workflow. You can still keep using craft for notes. And almost like it was four months to figure this out and then we built it in two months.
- [41:15]
B
I love it as an example too of being able to understand the underlying why behind something that users are asking for.
- [41:23]
A
Yeah. Which we did and kind of again, it was a very interesting thing because what happened is I went on holidays after the beta reefs because we did that in August and I came back and again our head of design was like, I read through thousands of feedback, talk with customers and kind of, they don't want this object. This is not what they want. So essentially what they said is, let's roll back four months of work. And I think you really need people who are okay to say that to you of, hey, what we're doing is not working. But the silver lining is we kind of now know better what we need to do.
- [41:59]
B
Hey, it's Rid. I'm constantly asked about my favorite product. So I'm going to take just one minute and give you a quick rundown of my stack. Destin is how I ship design changes without having to code. Framer is how I build my websites. Genway is how I do research. Jitter is how I animate my designs and Play is how I design and prototype mobile apps. Visual Electric is how I generate all of my imagery and Raycast is my shortcut every step of the way. Now I've Hand selected these companies to partner with me so that I can do these episodes full time. So the best way by far to support the show is to check them out. You can find the full list at Dive Club slash partners. Okay, now onto the rest of the episode. Can you touch on briefly just the role that components and systems play in this world where you are pretty quick to reinvent the product each year?
- [42:55]
A
I think one thing we realized is because we like to tweak things, if we build components, they will get messy very quickly. And what ends up happening is you're essentially slower to build with components than starting from scratch, right? Because if you have a button that has 25 properties, when you add the 26th, it's just going to fall apart. So we want to give a tool chain to designers and developers to be able to build very quickly, very high quality experiences. And for some companies that manifest in atomic design system and components. But in our cases, I think it's a little bit different. So we do have some very standard things. I almost call them like we have an animation engine that is super powerful, the curves are super monitored and how animations are wrapped inside of each other and how they inherit is very well defined. Which means if you ever want to do an animation where the entire screen moves right, you know, Even if it's 25 components, all of them will be synchronized independent of what's happening in those components. We also realize that we're dealing with text and often we need to show a lot of text next to each other. Let's say a breadcrumb. And for instance, showing an ellipsis in a breadcrumb on a mobile takes like three, four characters. But for instance, having a gradient fader on top of it, you see two characters more. So we created this component that on any label with one line you can apply this faded clipping. So whenever you're with that problem, you can access it. But also we noticed that one of the things we use a lot is we use this more gradient, colorful material so that whatever you have, as I said in your document, you can take over the colors of that. So we build this material that again with one line, you can make any view participate in that glowing system. So we don't have a button component or we don't have a drop down component, but what we can do is we can build a segmented control that is just as beautiful or more beautiful than any out there in like one or two hours. And we're saying that is a lot more important for us to do because Essentially because of this, we have a little bit of too many corner radius differences in the product and, you know, it's not everything's on grid at the same time. We can do those very quick prototyping loops with new ideas, which we talked about at the start, and I think that has always been, for me, very important, is how fast can people create greenfield projects. You should still capture the feeling and overall essence of the environment you operate in in this perspective, craft. So you shouldn't bring a totally different visual style, but if you can create something new in one hour, then kind of, it doesn't really matter if you reuse it or not because you're not spending that much time there. So I like to be able to treat the screen as a canvas and paint it because that gives you an ultimate control and creativity. It adds to complexity. But that might be the cost of innovation. Right?
- [46:20]
B
I love that. I want to make sure we're not missing anything here because you've won Mac App of the Year, Apple Design finalists, you're obviously doing something right. You've talked a little bit about the engineering collaboration. We've also talked about the speed of the app itself and how much of an emphasis that is. What else are you doing to achieve this level of design excellence consistently?
- [46:46]
A
I don't think we ever think we're good enough. Okay. So that doesn't mean we're not proud of our work or we're not happy where we are, but every day, every release, we want to get better. Right. And we want to do it well. And we're super pragmatic about it. We're doing a lot of unorthodox stuff, like we still use manual layout. I think auto layout was introduced in 2014, 2013, since there's SwiftUI and all of those things. But we all look those of being abstractions, which the CPU technically can't take it now because we have faster CPUs than 10 years ago, but it still takes cycles away from it. The less free space, for instance, you have in your layout code, that means, let's say the data sync is going to be slower or the updates aren't going to be added that far. When we look at a new technology, we're always like, does it solve a problem we have? And if it doesn't, we just don't adopt it, if we don't need to adopt it. So I think in that way we're very conservative at the other side just because we have a solution that seems to be okay for one problem. We do try to create a better version of it. This is a very interesting thing because I think we're the only product of our complexity which uses the same code base across iPhone, iPad and Mac. Right. Most of the times people have a responsive web app, but then the native iPhone app is a completely different one. But because we had one code base and we had this principle of the iPhone app should do the exact same things as the Mac app. There should be no differences. Right. We had to iterate so much on figuring out what are the things that make this possible that we could just never really say of. We figured it now out. So I think that is a big chunk of why we keep getting better and I think that is appreciated by a lot of the people who are following us of consistently trying to tackle these problems again and again and again.
- [48:48]
B
Before I let you go, now that we have an understanding of just how you all think and how you work, I'd like to understand a little bit about what you believe about the types of designers that thrive in this environment. So can you just talk a bit about either the core skills or traits that you prioritize when thinking about the types of designers that you want to work alongside?
- [49:11]
A
Yeah, it's interesting because we don't have like one specific type, so all of our designers are super, super different and we're really looking to, you know, they complement each other. But really I think the most important thing for me is what I call strong values. Lucy Held So you need to, you know, really believe in things, but you really need to be open to reevaluate those things and, and learn new things. That is I think one thing and the other is which I found super powerful in designers is what I call systems thinking. There are designers who are just so make so beautiful animations and make the screen look like you want to lick it, but if you don't understand how things connect effortlessly and things get quite complicated quite soon, even with a note taking app, there's some serious depth inside of there. And once you start to untangle the problem, you get this dis maze. And since we require designers to think about product, you know, think about the impact of this, you know, talk with engineering, they are in the deep of this. So the designers I think who are most successful in craft really have this strong desire, the systems thinking. And also they continuously develop this through readings, through looking at new things. Being very curious.
- [50:36]
B
I know this is a hard follow up question, but I want to try to go a little bit deeper into the systems thinking piece and make that more Practical, because it's been a theme on the show where multiple design leaders have come on and said, yeah, we want to prioritize systems thinking. And I know that there's at least one person listening that's like, okay, great. What the heck does that even mean? Like, how do I grow that muscle? So I'm wondering if you could speak to that person before I let you go.
- [50:58]
A
So one of the really interesting example is for us, keyboard shortcuts. So you think it's a really simple thing because I press a keyboard shortcut and something should happen. But the thing is, how do you ensure that on every screen you have, you have the right keyboard shortcuts? How do you categorize keyboard shortcuts? Like, you know, maybe there's a category of there's, you know, window related keyboard shortcuts, they're selection related, and then there's screen related one. Or maybe there are keyboard shortcuts that are always available, like escape and return key. And there are keyboard shortcuts which are optionally available now then in the Mac, based on the keyboard shortcuts, you need to be able to map them to context menus, the right click menus, essentially. And now we're in our phase where we also have the slash menu. Most apps now have a command bar where you want to have the same action as you have in keyboard shortcuts. And potentially you also want to be able to activate them with voice. So you have this problem set and you need to able to somehow find a grouping that is very logical and can be executed very, very well. So I think this is an example where something, as trust users, it just feels so simple. But getting and understanding all of the complexity and creating a mapping of how this should work requires a very analytical thinking of understanding how the app works, how the user thinks, you know, what are the system requirements and how can you create one system that satisfies them all? That is, I think, one of the most recent example and we're struggling with that as well. So it's not an easy thing, but we're getting there.
- [52:38]
B
Well, this has been amazing. You all have built something really special and it's very evident the moment that you start using the product. So thank you for coming on and pulling back the curtain and talking a little bit about how you work and how you think, and it's been really fun.
- [52:52]
A
Thank you for having me. Enjoy the conversation.