Loading summary
Transcript44 lines
- [00:00]
Andre Harasamchuk
There's a whole nother world of stuff that's about to happen. That's a new paradigm that none of us can think of. I've been lucky enough to go through pixels, to layers, to objects, and now to this thing I think is coming. This is why I still get excited about this business, even at my age. Who gets to say that they spend like 30, 40 years working in something where it's different every five years because magical things occur out of nowhere.
- [00:18]
Rid
Welcome to Dive Club. My name is Rid. And this is where designers never stop learning. This week's episode is with Andre Harasamchuk, who was the very first interface designer at both Adobe and Figma. So he shares some really fun stories about designing the earliest interfaces for Photoshop and Illustrator and what it was like seeing the original seed of an idea that became Figma. Not only that, but he gives us a behind the scenes of his new startup where he's yet again working on the future of design tools. So we get into some really fascinating discussions about where Andre believes the future of software creation is headed. But first you gotta hear about his first day at Adobe.
- [01:00]
Andre Harasamchuk
Well, the day one story was in 1995. I was working at a company in Massachusetts. The first company I worked with, it was a bunch of startups kind of doing a startup back in the days of computer graphics when it wasn't cool to do so. But anyway, I got my job and I promptly drove all the way across the country from Massachusetts, which is where I was, all the way to Mountain View, California. And I arrived at Adobe, showed up at like 7 in the morning because I was asked to show up at 7 in the morning. I was like, oh boy. I had just gotten into Mountain View the night before, so I was exhausted from driving, all kinds of stuff. And I show up and I get to the office and I ask the person, the admin there, like, hey, my name is Andre, I'm here for my first day. I'm looking for Brian Lamkin. He was going to be my manager. Brian at the time was the group product manager for Photoshop. Brian is notorious for having morning meetings. He does these meetings at like 7:30, 8:00 all the time with his team. I was like, this is not going to be fun. But we showed up and he said, hang on a second, Andre. He introduced me around to the, to the table. We start talking and he's like, okay, look, meeting's over. Let's go introduce you to the team. I was like, okay. So it is like now it's like 8:30 in the morning, we get up and we start walking across. So, and if you know these buildings in Mountain View, there's like four or five of them. We were building E, we were going to building C. Building C is actually where I think these days the Android team for Google does all their work. So we walk across Mountain View, this parking lot, go to the buildings. Brian walks in, I've got the visitor badge, I haven't got my real badge yet. And we walk into this meeting and there's a meeting happening for this engineering team. There's like 9 o'clock now, they're just starting their day, and there's, I don't know, a good 15 people sitting around the table. It turns out this was the Illustrator engineering team meeting. Along the way across the parking lot, Brian's like, hey, Andre, we had a slight hiccup. We're going to change up the Dave rule at first, but I want you to know that not only are we going to have you working on Photoshop, like we said, we want you to also work on Illustrator and then in the future on PageMaker, which then became InDesign. But rather than having you start in Photoshop, there's some things going on that I need to have you actually start with the Illustrator team. And this is while we're walking. And as walking into this room of engineers, he's telling me this, and I was just kind of like, oh, boy. Okay. I had heard rumors from my friends and people in the industry that the Illustrator team was notoriously picky, and they were really a different kind of team than the Photoshop team. And I had actually known the Photoshop engineers up at this point. We walk in, he opens this glass door, and everybody in the room just gets quiet. Now, first off, part of the story is that Brian is 6 foot 7, 6 foot 8. He's a tall guy, he's a really big guy. He walks in, he's got a booming voice, he's like, hey, everybody, how's it going? Good morning. And everybody's like, hi, Brian. And one of the engineers goes, what do you need? And then Brian goes, hey, look, folks, I just wanted you to meet Andre. He's our new interface designer that's joining us here at Adobe and just want to let you know that Andre is going to be helping you with the next release of Illustrator. Andre, this is the team. I have to go to another meeting, but I'll be right back in about an hour or two to come pick you up. Everybody, bring Andre on board. I'll Talk to you later. And he walks out. And I am standing there looking at these engineers and people, and they all looked at me. It was like a good 30 seconds of silence, I think. And one of them finally goes, what's your name? And what are you doing again? I was just like, oh, crap, this is not good. And I was like, my name's Andrew. And then I sat down on one of the empty chairs and I just was quiet the entire meeting. And that was my first, like, literally first couple hours at Adobe.
- [04:25]
Rid
Where was Illustrator even at? Like, in the product journey right now? Like, in those first, like, months? Like, what were you even working on?
- [04:31]
Andre Harasamchuk
Yeah. So Photoshop had just finished three and layers were a thing, and. But layers weren't fully implemented in a way that they needed to be. So we were. I was coming in to actually start on Photoshop 4 effectively, and Illustrator was about to get into version 7 and Brian needed me to kind of like, get to know the Illustrator team because the whole strategy of, like, we're going to put all these products in a box. If you look back at the products back then, Photoshop, Illustrator, page maker looked nothing like each other. They behaved differently. They had different interactions, different keyboard commands, different palette layouts, different dialogues, like, different everything. And I was brought on board because part of the strategy was like, they needed somebody who could do the design of the software for the engineers, specifically because the strategy was going to put them in a box, like, and to put them in a box, you kind of like what wanted, what Microsoft had done to that point, which is start to solidify at least common interactions, common behaviors, common approaches, but not everybody. Adobe was fully on board with that strategy. It was like, why are we doing this? This is crazy. Every product should just be only about itself. And that's how that works. And that was not the point. The point was that we were going to make this thing work because people used Photoshop, they use a pixel editor, a vector editor and a layout editor together. And so that was the new strategy, and that's what we're going to work on at that time. I had to get to know the teams. It was really, you know, about getting to know people. I was the first interface designer. So they had lots of designers at the time that did things like the packaging and the manuals. But I was the first one hired, literally. And they actually had to make a new thing in the HR book for me that was, I'm a designer, but I'm working in the engineering group, working on building the products.
- [06:06]
Rid
Real quick message and then we can jump back into it. For years I've been paying for third party website analytics, but I can finally cancel those subscriptions because Framer just released their all new analytics dashboard. It's built into every plan and it's even fully GDPR compliant without the need for a cookie banner. That way you can get a complete breakdown of how your site is performing, including live visitor activity bounce rates. You can see breakdowns by country, device, and even get a glimpse into refers and UTM sources. You can then filter data automatically by clicking on any of the individual metrics. Like users on a desktop who found your site through Google. It's super powerful, but most importantly, it's built directly into your dashboard. So you can't beat that. It's just another reason why I tell everyone to use Framer for their next website. And you can start using it today. Just head to Dive Club Slash Framer. There is so much more to good design than what it looks like. It's also how it feels and functions. And look, I can accomplish a lot in figma, but there's still a ceiling there. Which is why I'm so excited about Play 2.0. It allows you to create ultra realistic prototypes because for the first time, you can design interactions with native iOS gestures and Apple's core animation. So your prototypes feel real, because they are real. Which is why so many of the best designers that I know are all using Play to design and prototype their mobile apps. So if you want to join them, head to Dive Club Slash Play to get started today. Okay, now onto the episode you wrote about how a big part of being a designer is solving puzzles. And you know, nowadays there's so much precedent for what a design tool should be. But when you were first getting started at Adobe, like, what were some of those early puzzles that you were solving for the first time?
- [08:02]
Andre Harasamchuk
So I literally had spreadsheets and printouts of every keyboard shortcut for Page Maker, Illustrator and Photoshop. And the first thing to do is kind of reconcile what I would say are the obvious ones. The obvious ones on the Macintosh at the time were simple command, copy and paste. That's like, that's a Macintosh thing, it's not an Adobe thing. So that's clearly going to be Command X, command V, Command C. But then you get into like normal things, like arrangements. So bring to front, send to back, you know, up and down. Those were different between the three products. But changing those around was, you know, gonna hurt, you know, interrupt some people's flow. But relearning them would be easy because then once you learned how to do it, it would then work the same in all three products if you were using all of them at the same time or in conjunction with each other. The hard ones were the ones that were the ones that people thought of the product and it kind of becomes so ingrained in their mnemonic and they're kind of like flow and behavior that changing it was just like not going to happen. So the easiest example I could bring up of that was like Command D. So Command D on the American keyboard, the D is like where your thumb is and also either your pinky and finger or your thumb and finger. It's a very often used, you know, kind of golden shortcut. So in Photoshop, Command D meant deselect. I think it still does mean deselect. In Illustrator it means duplicate. Sake doesn't mean copy it. And in Page Maker and InDesign at the time they're they were doing design, it meant place because you often place text or you would. Placing was like a thing that you did all the time. I pushed on trying to make those the same, and I suddenly realized that there's a. There's. There's only so much of the puzzle you can do before you actually wind up breaking it. So that was one of those ones where, why don't we make that the same? Well, the answer was that the people at the time, the audience at the time, and the customers at the time revolted. So we tried to make them the same and literally it was just like, no, if you do this, I'm going to find somebody and hurt them. It's like, okay, we'll stop. So we had to push a lot of different ways. And that's where we ran into those issues. The more puzzle like ones which were more fun, which were brand new, for example, were like free transform. Because in Photoshop at the time, you couldn't skew or rotate or resize a layer like an OB easily. And one of the reasons why people don't know that you couldn't do that in Photoshop was because the way that you resize or transform pixels, if you stamp it down, you kind of flatten the math and you kind of create a result if you do that and do that again and then do it again, and then do it again and then do it again, it's the effect of recording something to tape and then re recording it on another microphone and then re recording that on another microphone and you get this kind of loss of data effect that occurs. So in Photoshop, it was like, we need a way to transform things that are object oriented people. And this is like 1995, you know, so people, they want to work with objects like they do in Illustrator or in other products as well. How do you solve the problem of making these objects do these things? And Mark Hamburg and I took an afternoon off and I went to his house actually, and we sat down and we just worked this like a puzzle. We wrote all the transforms on a board at his house and then we wrote down all the keyboard commands that we have that we could do this with. You know, the shift key, the command key, the option key, etc. The mouse, mouse up mouse, all the kind of inputs. And we kind of made a little bit of a matrix and we said, what can we assign these things to? And we just worked through the problem of the easy ones. Yeah, well, you grab a corner, you resize. If you click outside the bounding thing, you can rotate. But you have to be in a mode to do that, which is why it's called free transform mode. And you have to go into like this mode to apply it at the end. And the reason why you have to apply it at the end is because you do all the work and then when you apply, it's only doing one transformation to do the calculation rather than doing multiple steps and getting loss. And so, yeah, you sit there and you do that and you suddenly realize, oh, well, if we hold down the option key to like mirror, which is a standard Mac thing, we can actually make it so that if you, if you're distorting the corner, the option key plus the shift key will create a skew effect. And so that's how we get skew. It's like you have to do these kind of things.
- [11:51]
Rid
I got a smile on my face thinking about just how many different tools nowadays are derivatives from that whiteboarding session where you're figuring out all of the different pairings and keyboard shortcuts for the first time.
- [12:03]
Andre Harasamchuk
I got very lucky early in my career. I got to work on that stuff before it was the big thing, which is good and bad. But yeah, there was no precedent for some of the solutions like that one.
- [12:13]
Rid
Can you talk a little bit about how you arrived at what the visual language should be to tie these three products together?
- [12:20]
Andre Harasamchuk
The classic designer at the time, and I'm sure a lot of people will remember this, was you use Photoshop for pixels, you use Freehand for vectors, and you use QuarkXPress for layout. So when I joined Adobe, I was first told I think by Brian, actually. He's like, yeah, you're not using Freehand or Quark. And I was like, okay, yes, sir. Got it. It just doesn't look good, and it's not a good idea. I'm like, yeah, I understand. So. But I had the benefit of knowing the knowledge of those as well. So you take all the tools, this case, Illustrator, Freehand, Quark, Page Maker, the stuff they were doing in InDesign, which still had not been released yet. Photoshop and some of its competitors, there was enough maturity around these products that you could know what people liked, what they identified with, what they resonated with. Start there, take those things from all of them. What you don't do is you don't take it only from one. You have to actually sample it from all of them. And that's what I did. It's like, oh, we've got all these tools. We've got all this stuff going on. I'm just gonna take the best. We'll worry about the other stuff later. But let's just start with the best. So, for example, one of the things that everybody loved at the time was tab palettes in Photoshop. Tab palettes were, like, the biggest thing. They were done by a guy named Kevin Johnston and the photoshop team in 1993, 1994, they were a new paradigm convention on the Mac. There was, like, nothing like it really anywhere. And they worked wonderfully. Now they're kind of the bane of existence because everything in all the Adobe suite is like, new feature, put a tab palette for it. New feature, let's put a tab palette for it. So now there's like, there's too many. But, you know, back at the time, it was great. Start there. Once you have Tab palette, you now have a constraint. How do we put all these things into tab palettes? How do we take these things in dialogues and make them into palettes? And the idea is that tab palettes kind of need to be uniform in presentation to some degree, so you can stack them, because if you don't, then you get all this kind of crazy, stupid behavior. Well, you start there, go to Illustrator. Well, Illustrator's Layers palette was far more advanced than the Photoshop's Layers palette was at the time. So I started stealing stuff out of that. And by the way, the teams at Adobe did not like this. They were like, I don't want to do this the way that the other product does. And it was more just a familiarity thing. They didn't want to, like, have to deal with it. But I was, like, stealing all the good stuff from all the products and putting them into, like, this notion of a kind of a design framework.
- [14:22]
Rid
What do you have to do to get momentum behind these ideas, especially as the only designer? And you're kind of pulling whole teams out of their comfort zone and way of doing things.
- [14:30]
Andre Harasamchuk
Yeah, that's a good question. This is something that I have not seen change in 30 years. Personally, this has been the case. No matter where I've been. If the executive team is not on board, there's just nothing's going to happen. So I've been at companies where the executive team has been on board, like Adobe, and I've been at places where the executive team was not on board. You need somebody at the top who's making sure the company understands that this is not just something we think is a good idea. It's like, this is a business thing we're going to do. There's going to be a future and a vision behind this. Because when you make large changes, it's very difficult on your audience, especially when you have existing products. Ebay was notorious for having this problem. They would want to change and redesign the homepage or do all kinds of stuff, but they couldn't, because every time they change one little thing, the audience would scream, and then the executives would be like, okay, roll back. We'll just roll back. You see this. When people do brand redesigns, they do a brand redesign and then everybody flips out on them and they roll it back. So to give credit to the Adobe folks, the executives, they had the stomach. They knew what they wanted and they knew it was gonna be tough. And you saw that actually when they switched over to Creative Cloud, a lot of people don't like it, and there's reasons why. Maybe it's not good, or it is good, but the executive team has to be in on it. So my thing for designers. Yeah. Is that if you want something to happen, if you want to do it yourself or you want to push the executive team, you got to have a lot of patience and a really good ability to tell stories. But it has to be based in business and has to be based in solving customer problems.
- [15:53]
Rid
Let's jump ahead a little bit in your tooling adventure. Can you tell us the story of how you wound up at Figma? And what did you see that convinced you that it was spending some time on.
- [16:02]
Andre Harasamchuk
Yeah, so I just left Twitter, and I had been doing a whole stint at Yahoo and Twitter where I was the director of design, and at Twitter, I was reporting to Jack and doing some stuff. Both Twitter and Yahoo were exhausting. When I parted ways with Twitter, I was taking a break and trying to figure out what to do. And a friend of mine, Michael Abbott, who had been the VP of engineering at Twitter and one of the guys who helped recruit me, I wanted to grab coffee with him. And he was at Kleiner Perkins as a partner at that point. He invited me to have coffee. It was in December of 2012, I think. And it turns out, I think Mike sabotaged me and he did this on purpose. I was sitting in Mike's office at Kleiner Perkins on Sand Hill Road, just kind of chatting and talking and seeing what. Just, you know, just catching up. Basically in walks Dylan and Evan. And you know What? Dylan was 21 or 22 at the time, and Evan, I think, was 23 or 24 at the time. This is 2012, so they can tell you how old they were. But they walked in and Mike goes, hey, Dylan, glad you're here. I want to introduce you to Andre. I'm like, oh, great, this is a setup. And I looked at Dylan, I said, well, what are you guys working on? And Dylan, without, like flinching, looks straight at me in the face and says, we're gonna build Photoshop in a web browser. And I laughed. I was just like, sure, kid. Yeah, right. And he was like, no, no, no. We're gonna build Photoshop in a browser. You wanna see? And I'm like, okay, show me. I'm like, literally like, this is. This is nuts. Okay. What are you talking about? And so Evan pulled out his laptop and they showed me the demo that I think if you look online, they have this demo somewhere. It's like it's got the ball in the water and a bunch of other photo replacement kinds of things and whatnot. And as we're looking through the demo, I'm kind of watching this and kind of then start asking Evan some questions. And it suddenly dawned on me like, oh, you're not building Photoshop in a web browser. You're building Photoshop in gl. That. I get that. I was like, thinking to myself going, ah, I see what you're doing. You're banking on GL being in all the web browsers. And they're like, yes, exactly. And I was like, ah, okay. Well, I totally get that. And then they're like, can you help us with some ideas? I'm like, yeah, sure. So we went away a couple weeks later into a meeting room and some whiteboards and started just iterating Some ideas. And I was like, these two kids know what they're talking about. And I'm gonna say kids because they were like 21 and 23 at the time, and I was older. So to me, that. To me, they were still kids, but they clearly knew what they were talking about. And Evan was probably one of the smartest guys I had interacted with about computer graphics since Thomas Knoll. It's like Thomas Noel, who wrote Photoshop in Evan have a lot of the same characteristics. They think a lot along the same lines. And you could tell Evan had been living and breathing pixels and computer graphics since he was like, four or something like that. And Dylan was just, like, energetic and all these great ideas and things. I said, look, guys, you know, here's the deal. I'm taking a break. I am actually not looking to join a company where I'm the president or I would love to find a gig where I can just actually be a designer again. You guys raise the money, come find me, and we'll talk. And they're like, absolutely. And so they went away for, like, five months, and five months later, they came back and said, hey, Andre, we got 5 million. You want to join us? And I was like, you guys raised $5 million? What? And so, yeah, I was like, sure, I'll join. Let's do this. And I became the first employee, and we found, like, a Regis office in Palo Alto, like one of those rental offices, like, before we work. And we had this tiny little space where we're just planning out the first things. First parts of figma. I helped Evan build the pen tool and do some ideas there. We went through a lot of ideas, and I was kind of going down a route, more professional, more Photoshop tooling, like, because that's. That's my thing. I think Dylan wanted to have it be a little bit more friendly. That's a little bit tougher, but also just to be straightforward with it. Dylan always had the idea about community, always had the idea about, this is going to be for everybody. We, you know, the democratized design was something he told me in that first meeting in Kleiner Perkins.
- [19:50]
Rid
Wow.
- [19:51]
Andre Harasamchuk
So that was always the thing, because he actually, I think, understood that better than most. He understood, like, the power of Google Docs in a web browser and collaborative and all that kind of stuff.
- [20:01]
Rid
All right, so then let's zoom out, because you're coming full circle here and starting another design tool company. So talk to us about what you see in the broader landscape for tooling right now. And specifically, like, what's the opportunity that led you to be like, yeah, let's, let's. I'm going to start it. I'm going to build something from scratch again.
- [20:19]
Andre Harasamchuk
Yeah. So I've been lucky enough and I'm old enough to have started when all this kind of really started. So, for example, I was in, just started high school when the Macintosh came out. And so the Macintosh, you know, kind of brought pixels and GUIs, graphical user interfaces and mice to more mainstream. And so I went through the Pixel era, as I like to call it. So the Pixel era was like Mac Paint Pro and Pixel Paint Pro and Super Paint 8. Like, you had eight colors to choose from that you could paint with. And so that kind of went from like the 80s into the early 90s after that. So Photoshop came out in February of 1990, and Photoshop started off as a pixel tool. And then by Photoshop 3, we get layers happening in the mainstream. And so layers allow another level of functionality and ability to do things, not the least of which is blend modes. You can blend pixels together, you have transparency, you can slide things around so that they're not. They're not fixed. And it starts getting into now the mobile age, where we see object oriented programs come around, come around. And most people will probably remember Fireworks as being one of the first mainstream versions of those. There have been some others, but Fireworks was really the one that captivated people the most. And so Fireworks had this object mentality. So it was doing everything that you could do with layers and with Pixels, but it was now with objects. And now with objects, you can have things like a corner radius that was a value or how many points of a star do you have? And you can adjust it all the time. And so Fireworks goes, it kind of caps out a little bit, but sketch comes in, replaces it. And then Figma was right after that. So we get this like nice progression of all these tools taking objects and really doing amazing stuff for them. So Figma now has like auto layout and you can like put variables and start to do all kinds of behavioral things with the objects themselves. So for that to work, you have objects that have to do everything that Layers does and everything that pixels do. But I'm of the opinion objects caps out objects can only get you so far. And we even see today that people are trying to make objects behave like what I think is coming next, which has been the holy grail for a long time. I don't think it's the end, but I think it's the next progression. And that's components. So rather than having objects try to mimic and behave like components, you should just have a component. The problem is that components need to do everything that objects do and layers do and pixels do before they become useful and they can do stuff. So that's what Selden is about. We're building our entire model based off components, which I think is the next natural evolution of how this works. And the trick for us is to make sure that we can get components that feel as fluid as objects do, in the same way that figma and Sketch had to learn how to make objects feel as fluid as layers did in Photoshop. But once you have components, components have all kinds of unique things that are super useful, especially in the AI era. They have semantic kind of notions. And what I mean by semantic is that a component inherently has a role that it's trying to fulfill in your layout or in your project. By having a role, it has to, you know, you have to kind of describe what the role is once you do that. The LLM is really good at processing language and intent and things like that. So now your AI and interfaces and approaches can really supercharge what you're going after. The challenge with components is that you need a lot of them. You need a lot of things, a lot of different iterations. You need people to be able to redo them in different ways. They need to be flexible enough to have variations and variety, but still have enough guardrails that they don't break. And they're not just basically, you know, a collection of objects that are stitched together. So that's gonna be the challenge there. But that's what we're doing at Celton. I see the natural progression going to components and, you know, working with components in, you know, in the next five to 10 years will be like people today saying, why are you using layers? You know, you wouldn't use objects. Why are using layers for this? Layers can't do this stuff. If you're using components at some point in the future, you'll be looking back like, why are you doing this with an object based thing? It doesn't do all the things you need it to do.
- [23:59]
Rid
Hey, it's Rid. I'm constantly asked about my favorite products. So I'm gonna take just one minute and give you a quick rundown of my stack. Dessen 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 on to the rest of the episode. Can you talk a little bit more about what it means and what it takes to create components that feel fluid? Because I think some person, probably many people were listening to this, they hear you talk about components and they're like, yeah, that's the thing that I insert and then immediately detach because it doesn't do all the things that I want.
- [25:00]
Andre Harasamchuk
Yeah, so there's a couple of things there. I think the first thing to do is a little bit of a preface. If you look at video games, video games and people who build worlds today use like. I think they generally call them design kits, not design systems. And I like the word design kits better. I think that's a nice progression. If you're building a world like Hogwarts Legacy, or you're building like Spider Man 2, you know, one's in the city and one's in a fantastical Scottish landscape, you have all sorts of things you need to be able to deal with. The rooms, the furniture, the clothes, the trees, the banners, the cars, the bridges, the buildings, all of these things require. And it just takes time to build that up. So what happens is, what I'm trying to get at is that at the beginning stages, you need your components to just be built, basically building blocks, kind of like lego. So in that, in that instance, a button is a building block. Building a button so that it can do all the variations that you'd wanted to do from a designer's point of view is actually not that hard. It's kind of a solved problem. That's one of our first components that we've got, for example. And what I mean by doing what you wanted to do, I literally mean whatever corner style you want to, whatever border style you want to, whatever gradient, whatever, like make it pulse, like the old Mac OS X, like, you know, lickable default buttons did. All of those things are totally doable and are solved problem. As I would say, they're not rocket science, they're just tedious. But once you've done them, now you have all of this expressiveness in this component. And if you haven't, the people can take the code base fork, it and make another version that finishes the things that they don't want. So that's the first step, is that once you get all these building blocks that have the richness now, you need to go to the next level. If you're building a world they started with, how do we get trees? Like, how do we get these trees doing things? We have to build a good tree and then we have to build all these variations of trees. And building the variance of trees, then procedurally being able to manipulate them so that you now have something that looks like a forest in a video game took some time. So part of it is it's just going to take some time to get to the kind of richness that we need with components. At the same time, however, the issue with components is what you kind of bringing up with, which is that it doesn't do what I want it to do. That to me generally speaks to a notion of a component that needs to be more bespoke spoke when you get into more complicated components. This is an easy way for me to describe this is. Let's talk about maps. Like, so if you have a map, maps have all kinds of markers and things. Like, if you're just doing a general map, the ability to have a component system and a component model that has the map, that has all the controls, all the things you want to do, you can move them around. All that is actually pretty straightforward. What's hard is like the way Uber wants to use the map versus the way Google Maps wants to use the map. And what I mean by that is in Uber, they have to have a car that's driving, has a line, or a bicycle, or whatever it is that's delivering you your food. You need to be able to see what's going on. That's the part that gets really hard. But the foundational pieces around them are still roughly the same. So when you're building components, the challenge for us is going to be how do we get to a level of richness that we know how to stop? Because no matter what we do, people are going to need to do unique bespoke things anyway. And then the challenge there is how do they integrate their either design, their behavior or their code into the component that does everything else that they need. That's gonna take a little bit of time, but that's not. It's not a problem that I think is unsolvable by any stretch of the imagination. Just gonna take some time. So we're starting with all the easy stuff, the stuff that I would call the 80% stuff. The stuff that is like a nav bar, you know, a product card, a list, a sign in form. These are not things that are super difficult to do from a component point of view, but the richness is gonna.
- [28:23]
Rid
Take some time in this level of, like the 80% components. Is that something that you are building and giving people out of the box when they start to use Eldon?
- [28:32]
Andre Harasamchuk
That will be the intent, yes. How they use it is still something we're working through largely. We're probably going to package these up as code components and code libraries for them to be able to integrate with, but we're still playing with that notion. There's a bunch of things that we have to work out through naflisa, which is security or data leakage. Because we're actually, since we're using AI to manipulate the these things, we got to make sure that the data leakage doesn't happen too much. Where if you're an Airbnb and you're using it, you don't want somebody who's your competitor, say, make this look like Airbnb. It's like, no, no, no, no, no. You gotta watch out for that, that kind of thing.
- [29:04]
Rid
You mentioned the code piece. Can we talk about that a little bit? Because when I hear you talk like. One of the things that makes components particularly interesting is that it does kind of force designers to play in the playground where developers can build their designs really, really easily. So how do you think about the relationship between, like, this next phase of tooling as it relates to the actual code base?
- [29:27]
Andre Harasamchuk
Effectively, what we're doing is we're following the notion of a schema. So when you're doing a design, what you do is that you want to design something agnostic or abstract of any specific platform out of the gate when you're doing this. Where I think most designers make a mistake is they'll make a design and then they'll make another design, and then they'll make another design starting from scratch. What we do and what I tend to do for a lot of things that I've done is I tend to find the hero design and then start to find the exceptions and whittle those away. So you whittle away. This stuff here has to be native on iOS, because if it's not native, it's going to not feel right. It's going to be janky and jittery. It's not going to have the right rendering of the icons and fonts the way that Apple has done. Therefore, this part has to be iOS native over here that this difference is maybe a little bit less. So once you have those differences, you then go off and you make components and libraries that are actually native to those platforms. We're making schemas that design the components and then we're doing the native stuff natively. Like, look, this drawer is a native iOS drawer. So therefore it's going to behave a certain way. You should not expect this to work on Android the same way. But with AI you can also do kind of cool things like find the components in our system that would replace it in the best way that people find. Works just as good as the native iOS drawer. If you want to do this on Android.
- [30:40]
Rid
You've mentioned AI a couple times through the lens of helping you with some of the behind the scenes operations that you're performing. But how does AI fit into your product strategy for like the actual authoring experience in the tool?
- [30:55]
Andre Harasamchuk
Yeah, so basically the thing that we're doing is we're not, we're not building an app that says, hey, make me a dog walking app and then you get a magical app or make me a weather app and it just does, does it for you. That's not, I don't find that interesting. I actually find it kind of dystopian. The component model that I'm talking about, when you do components and use computer components as your base system over objects, like I said, components have inherent behaviors, they have inherent things that they're doing and they have semantic value, it behaves like this. I can describe those behaviors in English. So all of our components have, you know, what they're supposed to be used for, why they're there, what's the good things. And we can have the folks in the LLM also annotate more information onto them about what's working, what's not working, et cetera, et cetera. The AI, in my opinion, that we're building is one that is using all the richness of the data to help you find the solutions that you're looking for. Not to find a solution outside of you, not to find a solution in this random pool of solutions that I could have picked from. But literally I am trying to do this. This is my intent, this is what I want to execute. What is the thing that I need to do that with, and it will find that for you and put it there for you. If you are looking for solutions with components, you can now say, I need to mix these up in a way that behaves a certain way. And because all this is kind of like In a language of schemas and components and intent. At the kind of description level of our components, the AI is very good at going through things and finding stuff and then helping you figure that out. So the way we talk about it for Selden is that we've kind of got three levels. We're doing, we're doing a creation level, a control level, and a code level. And when we say control, we don't mean copiloting, just, just, we mean control. If you want to do something, you can do it. If you want to change all the cards to be something else, you can just tell it to do that, you know, Control. If you want to change the color of buttons by typing it in, you can do that. You can also just point and click and do some things with point and click and some things with speech. On the creation end, we've got sketching working. So if you sketch, pop it in, it'll create your components from the sketch. That's the way designers like to work. That's the way I like to work is I like to work with whiteboards and notebooks. But if you're a product manager, you can just describe it to it. Some people are using prompting to like, describe things, but we're saying like drop in a whole prd, whole problems document, combine it with a couple of sketches, and then take the research data from the spreadsheet of data that researchers are using and doing. Combine all that up and the AI can process all this. It's like, okay, it looks like this. Is these the components that are going to address this problem? Are these the ones you want? Here's like five suggestions. You pick the one you want and it drops it in. So we're using the AI to do that on the code level. We're using the AI to smartly configure and manipulate how these properties and schemas are interacting to find the solution that needs to go into your code base. A lot of AI stuff that I see these days is write me the code. And I don't find that super interesting. I mean, I guess it will be interesting in long ways, but there's a long road to go, a long road to travel to get the AIs to write code that over iterations is consistent enough that you can do the correct differencing that you can track, like the decision making process. Right now we can't, we don't understand the decision making process that an AI does. Whereas if you have a human being doing the code from version to version, it may not be the best code, but at least you know, they can tell you like, oh, I did this and I did this and I did this. And here's why. That's going to be coming in AI at some point, but it's not here yet. And so when you see all these apps out there writing code, my first reaction is like, great for a one off, but is that going to work for 10 versions over time? I don't know. So for me, AI and the way that we want to use it is about intent. I say it's like parsing human intent. We're not looking to replace people. I'm not looking to have AI be this magic genie that just gives you whatever you wish for. I think AI is really interesting when you have components that have behavior and intent and all this descriptive stuff with them, pairing that with AI and a human being and then letting them really find all these kinds of interesting, crazy solutions.
- [34:36]
Rid
There's so much about design tools now that is familiar. You have your layers on the left, you have your properties on the right. If we're going to move from this layers paradigm to components paradigm, how do you think about the right level of familiarity to capitalize on versus where it might make sense to really think outside the box and innovate in order to reach the ceiling of what a component world can create?
- [34:59]
Andre Harasamchuk
I was hoping you would not ask me that question. So the answer to that question, truthfully speaking, is that even with Seldon's first editor, that we're going to start showing people very soon. Here we have objects on the left, a hierarchy on the left, and property panels on the right. And that was done specifically because I want people who are starting to play with it to have a familiar base to kind of start from. I've told the team we cannot spend a lot of time refining and honing this interface because that's a solved problem. We can solve those problems later and fix those bugs and make some of the interactions work better. You know, that's actually really straightforward. I've done that multiple times. That's kind of like my wheelhouse. I know how to do that easy. What's hard is that AI is a paradigm shift the same way in that the mouse, when it came out to manipulate and draw pixels on a computer screen, was an entirely new interaction paradigm. It's like, oh, I've got this thing, I can hold my hand and I got buttons and I can press and click, and if I press and hold it, I can drag and paint and all this. Other kinds of crazy things that had never been dealt with before that time in personal computing, nobody knew what it meant. If you go back and look at early painting apps, they were all different. They all had different approaches. It was crazy. They had some familiarity, but nobody knew what they were doing just yet. AI is about to do the same thing. AI is a paradigm shift, and we're using it in a way right now that is kind of the same that everybody else is using. What I'm looking for is the tools that we've been thinking of. And the things that I want to play with is going to come in a little bit once we have more of the foundation and the structure in place, which is, what does it mean to be able to have any analog input, sketching, word, documents, text, your voice, data, spreadsheets? What does it mean to have all that in the mix while you're also manipulating all these things in the way that you're used to? What kind of new tools do you have there? What kind of new interaction paradigms do you have? Like, as you drag a product card on the screen, does it auto reflow like it did in the figma where they resize? You see a lot of apps doing this, where you resize a component and just fills in data. That's an easy one. But what if it does it in a way that is literally offering contextual suggestions based on what's around it to offer the right kinds of data models to explore and play with. So it's looking at the context around you, so it's doing a vision model around the whole thing as you're drawing and creating this thing on the screen. You know, we need speed, optimization, all kinds of stuff to make that work. But there's a whole nother world of stuff that's about to happen. That's a new paradigm that none of us can think of. And I think anybody who says they know, they know what it is, is just flat out, you know, kidding themselves. But that's what makes me excited about doing this. It's like, oh, great. I've been lucky enough to go through pixels, to layers, to objects, and now to this thing I think is coming, which is components, which has been happening for a while now. This is why I still get excited about this business even at my age. You know, who gets to say that they spend like 30, 40 years working in something where it's different every five years because magical things occur out of nowhere? I've been lucky enough to to say that and have been lucky enough to be in the trenches working on it. That Gets me excited. So yeah, the answer to your question is that who the hell knows? Who knows what's going to happen, what's the new paradigm? But that's what excites me. I don't want to be in this old world that even I helped create, which is like, you know, layers on the left and properties on the right. And I know how to do that. I want to do the new stuff.
- [38:12]
Rid
Let's talk about a little bit more future facing things and zoom out for a second because you wrote something earlier this year. You said what is coming is a simple change, but one that might blindside you if you're not ready for it yet.
- [38:23]
Andre Harasamchuk
Oh yeah.
- [38:24]
Rid
Can you talk a bit about what you're kind of seeing and thinking when you look into the future?
- [38:28]
Andre Harasamchuk
What I see coming is a world that's going to evolve in the same way that I think graphic design evolved. So graphic design used to be commercial art. The world of it was very fancy, lots of illustrations, lots of bespoke type, all these kinds of things where the craftsmanship behind it was pretty high. If you go back and look at the old ads from like 1910s and 1920s for like Coke Cola, they're like stuff I would hang on my wall. They're pretty amazing. Standardization comes around, all these kinds of things come around. The mechanical process evolves better. Printing processes evolve, evolve better. And over time you get what we know as graphic design today. Effectively in that process, I think what happened there is not an exact match, but it's reminiscent of what I think is going to happen to our design field. And I mean our design field, I mean the one that people ui, ux, product design, whatever people call it these days. So what I mean by that is that as things evolve and get more mechanical, as these processes get evolved, if components take off the way that I think they're going to, what you'll see is a place where people who design the components themselves, the buttons and the cards and the calendars and all that stuff will become similar to what is in graphic design as a typographer. So if you're doing graphic design, you don't design all the type that's to consume your life. Because designing typography and designing a font is a huge amount of work. There's a massive amount of work that goes into that. I view the designing of a font and the level of craftsmanship that takes to be what's going to happen when we have components. You don't need a million typographers, you only need like you know, 10,000 really good ones. And so you'll get component designers doing this sort of craftsmanship and they'll become more like design engineering. So I think if that happens, the business that we are in now is going to split into two. We're one type of designer who tends to be more business oriented, more customer oriented on the problem side of the fence, who enjoys more of the reasons why product exists and more of the branding aspects and more of the way this lives in the market. Those kinds of stuff. They're going to go off and probably become more akin and join the field with product management on the other side. I think you're going to see the people who are far more interested in the more quantitative aspects of design, like, does this work? Are people using it? Why aren't they using it? What's the actual problem that the human beings having at this kind of practical, pragmatic level? And that's, I think, where a lot of UX people tend to live these days. They tend to leave in that, live in that world and they're going to go off and do that. Because what you'll have in the middle is people designing the fonts, the components, and then the design field will split and it just makes sense. You don't need everybody designing the buttons, you don't need everybody designing like the mechanics of these things. Maybe I'm the old guy, but it's just a waste of time. You should only do it if you really care about it and you know all the details that go into what it takes to make those things. Not just like, oh, I like this way this looks. And therefore that's the design that's not good enough, and it's not gonna be good enough going forward. So if you want to do that, you should start to learn behaviors, code, how all this stuff works under the hood. Otherwise I think you're gonna see our field split off and become more product oriented or more research and UX oriented. And that's fine. I think that's a good thing in both those worlds. My hope is that we'll finally get back to designers solving problems. The people problems, the product business problems, the two of them working in concert together versus sitting in rooms arguing about whether the red is the right color or the button corners are around enough.
- [41:46]
Rid
Does that split mean that software products moving forward will probably become a little bit more homogenous? And in that world, where do you see the opportunity for creativity?
- [41:59]
Andre Harasamchuk
The same thing that your art teacher taught you when you took typography class. Like, you get One font, make a poster. You get massive amounts of creativity from young designers who are just not learning how to do this from the same typeface. I can do things like make negative space into the letters and have, like, little hidden symbols. I can be creative about the layout and what it means to have the breaks of letters read a certain way. I mean, there's like, all these other unique things that you can do, which I think are far more fun to play with as a designer and far more interesting to use and solve being in the trenches. So my hope is that it'll be the same thing. Like, people will see this split, that they'll get back to what being a designer is actually about. It'll be a lot more fun. It'll be a lot more like, how do we solve these problems with these things now? So to that point, though, the components themselves have to be rich enough so that they can be expressive in those ways. That is that one of the challenges? So it's not like, here's a calendar, you're stuck. No, it's like, here's a calendar, here's all the things you can do with it. It's got, like, a gajillion levers and things like that, which are all crazy. The AI can help you play around with these levers and see different configurations. You can try all these different pieces out. Maybe you want the header of the calendar to have a background animation of the weather of the day as it's occurring. There's all kinds of things you should be able to do with those components. It'll take time to get to that richness of it. But the point is that when the components are rich, then you can now use the component to figure out what you're trying to solve and how you want to solve it versus how does the engineer actually code this thing, which is, you know, we've done these. This work, and we've never done this calendar before, and we got like, 60% of it right, but this 40% is now not allowing us to change the colors of today to be a different color. And therefore, how do we solve. It's like, all those problems are not useful problems. They're. They're like, need to be solved once, and we all need to move on.
- [43:41]
Rid
Before I let you go, can we get a little bit of a glimpse and, like, where are you at right now in the Selden journey, and what are some of those next milestones look like for you?
- [43:49]
Andre Harasamchuk
Before the end of the year, we're going to release a couple of content videos and a few videos to start getting people's opinion. I want us and the team to design this out in the open. And so I've shown a few people what we're working on and how we're doing it. And we've got the process started now. So over the next couple of months, I want to engage with people to show them what's happening. Now, having said that, it's still really early days. There's still only certain things you can do, but we're looking to get that kind of feedback. And once we get the product to a point where we can actually let people play with it more, we're going to start asking for people to sign up and email accounts. Because of the nature of this tool and because of the nature of AI, I can't just open up the floodgates and say, hey, everybody, play with this. Because AI tokens and AI calls are cost money. So until we solve that problem, we can only take a few people. So we'll be looking for people who are really interested in helping us do a deep dive, because we need them to play with the AI as well, too. But that's the next steps is to get people out in the open and start having the discussion. I do want us to build a tool that is this evolution that does go to this next level, and I don't want this to be dumped on people. I think a lot of companies doing this right now, I think a few of them are just dumping these AI things on people, and they're doing it because they're excited about their product. They're excited about AI and they're excited about what this means. But I. I kind of want them to be careful and take a little bit of a holdback because some of the messaging that's coming out is like, oh, you don't need designers anymore, or, oh, you don't need engineers anymore. And I don't think that's what we want to do. We are looking to build a tool with the community and build a tool that everybody can use as the next progression. And pretty much by January of next year, we're going to be opening this thing up and getting lots of feedback from folks.
- [45:20]
Rid
Hey, quick note. If you're listening to this and you want to be one of the very first people to try out Selden, I asked Andre if we could set up a little early access list for Dive Club listeners, and he agreed. So head to Dive Club Selden to hop on that list. That's S E L D O N. All right, let's finish this episode because Andre still has one more answer that I love. Before I let you go, I have a one off question here.
- [45:45]
Andre Harasamchuk
Okay.
- [45:45]
Rid
And my goal is to kind of tap into your experience, you know, designing and leading design at some of the most prominent companies in the world. What's a trait that you've noticed in some of the best designers that you've worked alongside over the years?
- [46:00]
Andre Harasamchuk
Oh, that's a great question. It's actually one that I'm, I don't consider myself very good at. There's a level of understanding how much story to tell and how much story to show. If you show too much or you tell too much story in the attempt to sell the idea to a client or sell the idea to the executives or to get approval for the roadmap that you're planning out, et cetera, if you do too much, you set yourself up for failure down the road because invariably things are going to change. As I like to tell people when they hire me, it's like, well, you know, this is what we want, this is what we're doing. What do you think? Is this what we're going to get? And I'll be like, sure, maybe. And they're like, what do you mean maybe? This is what we need, this is what we're going to get, right? I'm like, we'll get something like it. But if I had the design, it would be shipping and we'd be done and therefore I wouldn't be needed. So there's a process in place that has to happen. A good designer understands that that process is going to change things, because if it doesn't, then you're just basically a cookie cutter person and you're not really solving problems. You can only solve problems that your cookie cutter process allows you to solve. Good designers understand how to tell enough story but leave themselves wiggle room so that when it changes, invariably down the road or during the process, at the end of it, they're not stuck with an unhappy executive customer, you know, whoever. The best designers I've worked with or managed have always been good at telling an inspiring story. Showing what's possible, but not showing what will be, only showing what could be. And enough in there that when they get to that point, they know enough about what they really, really want that when they get to the end point, it will actually resonate. And then people connect the dots like, oh, yeah, six months ago, this is exactly what we wanted. And you show them the thing six months ago, it's like, it's like 20% the same. That's a good designer. A good designer knows when to show enough and tell enough and when to stop. That's a skill that I don't know. If they teach in school, it's a hard one to learn. It's really one of those ones where you have to put yourself as a designer in positions where you are forced to deal with it. So if you are at a company where they want you to give the presentation to the company or they want to give you. They want you to give the presentation to the team, you should use those because those are your opportunities to learn how to tell the story, but also how to tell just enough of the story so that it's inspiring and not going to hurt you down the road, as well as show enough of the story such that you can also, you know, change and modify things along the way. Outside of that, I think the other ones are just really good at having a thick skin. You know, the worst part about our job is that it tends to be very visual. It tends to be very visceral in many ways. Engineering code is performant and it does things in certain ways when you're engineering stuff. But there's no visceralness or emotional attachment to an algorithm per se, unless you're an actually engineer. Ours people can see and touch and play with and, you know, everybody's got an opinion and you just got to just ride with it. And you should know that everybody has a right to their opinion and that's fine. And you got to just roll with it. I can't tell you how many times people tell me the stuff that I've done is like awful. It's like, yeah, now, it'll be better later, but, you know, I'll keep iterating.
- [49:02]
Rid
Well, Andre, thank you so much for coming on today and just sharing some pretty awesome stories. Like, I was definitely just smiling and super engaged, listening and really, really cool to hear about your journey, what you're thinking about, what you're working on next. I'm excited to see where you take it.
- [49:16]
Andre Harasamchuk
I can't wait to show the show the world all the stuff we're working on. It's gonna be a lot of fun. It really is. And I appreciate your time and all the questions as well too.
- [49:23]
Rid
Hey, it's Rid. Don't forget if you want to go even deeper. Each week I send an email out to over 10,000 designers with bonus resources and key takeaways from these conversations. So head to Dive Club email to sign up. Okay, I'll see you next week.