♪♪ ♪♪ Thank you very much. Can we have a round of applause for our panelists? You bet. Oh, uh... Thanks for being here. There's a whole long introduction that I'm supposed to read for all of you, but instead I'm going to ignore that and start with a personal introduction, because you three might be some of the... a little bit of my developer design heroes, all of you, in different ways. Steve works at TLDraw, is the founder and the creator of TLDraw, and he's one of the most insightful, detail-oriented developers I've ever seen when it comes to creating incredible user interactions in TLDraw and elsewhere. So, glad to have you here, Steve. Thank you. Yes. And Maggie is a little bit of hybrid everything, a developer, a designer, anthropologist. She's an incredible deep thinker in the paradigms of computer-user interaction, computer-human interaction, but also just a wonderful designer and has contributed to so many projects and so many resources on the Internet, just as JavaScript. So, thanks for being here, Maggie. Can we have a round of applause for Maggie? Can I get a round of applause? Oh, did Steve not get a round of applause? Can we have a round of applause for Steve as well? And finally, Anjana joins us all the way from San Francisco. She is truly the polymath. She's done a little bit of everything from studying philosophy to teaching English to computational linguistics, and I think she brings all of these things together to a really holistic view on programming, and she's worked on some truly exciting projects, which I'm sure that we can hear during this panel. Thank you for being here, Anjana. All right. So, let's get going. The topic of this panel is UX and developer overlap, and I think the one cliche question that we always hear is, should designers code? And we don't really need to go into that here, but I want to pose the opposite question. Should every product engineer or front-end engineer design, and what does it mean to participate in a design process? Who wants to go first? Yeah, that's a good question. I mean, the simple answer is no, developers don't have to become designers. That's never the ask. That's why we all resent the question, should designers code? Should developers design? Everyone's like, well, I'm kind of drowning over here in JavaScript tooling. Please don't make me take on a whole new discipline. I think it's maybe more interesting to turn it into asking people to hold their developer or designer hat loosely and be very open to learning things outside of that very strict box that we put ourselves into, and just thinking developers should be open to learning more about design and working very closely with designers and learning to think like a designer, rather than becoming a designer, whatever that might mean. Yeah, I would agree with that. I see designers' kind of opinions about how things should work and how they should look and so forth, and then a lot of process. So how do we make those decisions based on our users and as a team, based on the product? And then there's the execution stage, the building things in Figma. Developers don't necessarily have to be on the last one, but should absolutely be part of the first two, either having opinions on what looks good and what doesn't and having those opinions be informed by their technical practice. And then, yeah, if there are processes around design, that might be a place for, even though you're a developer, a front-end developer, absolutely a place for you to participate. Do you have a mic? She doesn't have a mic. Can we get another microphone? I think it's over there. Yeah, and I think I'm totally plus one to what's been said already, and I think that there's also an aspect of the surface area of building web apps even, let alone the infinity of other products that we could be building and developing and designing, is getting so huge that there's no way that any one person can kind of hold all of the skills in themselves that are necessary to take into account when building these complex systems. So I think the other thing that we can really try to do better, and perhaps, as has sort of been hinted at already, is to really be able to collaborate with people who are taking a totally different approach or have a totally different perspective on the same thing that we're all trying to build. And so being able to work together in multidisciplinary teams and really making sure that we all value those differences in each other's backgrounds, in each other's perspectives, in each other's areas of focus and skill sets, and not falsely prioritize some over others and kind of think that the skills that we have are the only skills necessary to build a really great thing. And to build software, I think there are some natural constraints. If you're a team of one, you must do everything yourself. If you're a team of many, you can specialize a little bit. So maybe to this question of collaboration versus synchronously being able to make these product decisions in one head, where does the difference really become? What type of design tasks or what kind of product tasks require that one person or that tight, synchronous collaboration? And when can we be more split responsibilities among the team? Well, I feel like Steve's going to be the expert on this one. I'll maybe quickly say my initial take on it would be when products are early, I mean that really early phase when you're trying to describe the shape of something or define the shape of something, to have someone who can understand the technical requirements on a very deep level in a way that I think most designers just don't. If you haven't coded, you don't understand all the tiny things that are going to get tripped up in databases and front-end code. You just can't. And that's where having someone who intimately knows how to code and has been trained in design thinking or UX, it just makes an incredible difference to the quality of the product and being able to conceive of what is possible and the shape of what is possible. I think when you have a larger established product, maybe you can split up into teams, you get into specialization, and you're just maintaining or building out an existing thing, maybe not as important, but early product definition, if you're in any kind of agency or company that does that, that's where those hybrid thinkers are critical. Yeah. I would say that, well, most of design, like most of development, is following conventions. You're not starting from scratch every time. And that's especially true if you're designing for a very opinionated platform like iOS or something. You're kind of following the hag. You're copying other apps. And that's totally normal. I think the parts where you have to come up with an actual, like, original design can be really, really tricky for designers, as well as development teams, where it's like, well, how should this very custom part of our app feel? Not necessarily even like look, but how should this interaction be? Or what should our whatever pricing calculator look like, feel like? Very hard to do just from like Figma and just from Box. It's a place where you want to iterate with a developer or have a developer own that and do the whole hybrid thing. But yeah, the further you get away from conventions and the tracks, the more the hybrid design developer collaboration is important. If it's just a button, and if it's just a button in iOS, you don't need a designer who codes to make that. You might not even need a designer, which would probably be a good talk name or something. But yeah, once you start getting into weird stuff, then that's where it matters. So, Steve, I wanted to ask your personal take on this, because I feel like you embody this kind of like synchronous designer developer workflow. How many hours have you spent perfecting the arrows? Oh, many hours. And what does that process look like? Is there pure intuition and taste, or is there an element of user research and more methodical design process? Yeah, like I said earlier, design is a lot of processes. How do you make a decision if that decision is a color? If you've ever seen graphic designers work, they have libraries of color and source material. They are not just picking their favorite blue. It's a process. It's a lot of iteration. Designing a perfect arrow is the same. It's just that with all these sort of like hybrid design developer problems, being able to iterate and say, like, that's not exactly right or that's better, whatever, and kind of work your way towards a solution in the same way that you would with a layout, with a color scheme, or with like a design, like normal design system. That iterative process is just impossible to do if you're just doing this on something like from Mox. And it is really like, oh, well, that arrow feels better than the other one. Or like, oh, look what happens when they're too close together. That's a case that I didn't think of. And having the ability to do that iteration is like the only way to do the design to make that decision about this is the perfect arrow or this is the perfect ink. How much do you think that's a... We promised not to talk about tools. We're not talking about tools. But a complete lack of like decent developer and designer tooling, the fact that a designer cannot iterate in Figma in any meaningful interactive way. I always say like Figma is the worst design tool except for all the others. It still like profoundly does not meet our needs as designers and developers to build like really good products. And there's just a lack of a tool that is somewhere in between Figma and React. Yeah, I saw your tweet about that. Sorry. And I was like, that's bait. I think it's very tempting to think that... Not to criticize the feeling like, oh, I wish my... But it's really about having... Especially if you are designing within a convention or for a platform, the more that that tool knows about what you're designing, like the less you have to design. And that's a big issue with, for example, Figma normal kind of like mock based tooling. It's like you're just faking everything all the time. That's almost a... It's almost a separate issue to like, how would you have tooling that allows you to design whatever like an interactive pricing calculator, just as the example. I don't know if you can have something like that. Like you really, I think every product where this is important, the situation is normally unique enough that you really do need to do it in the same code base, almost as what you're going to ship. And I wonder if there's maybe some lessons also to learn and how we think about as engineers kind of baking in some of the conventions of a particular code base, a particular project, like particular style rules around how the code is written, particular conventions like with the advent of TypeScript and static typing around like what types of data is going to be passed around in our programs. Are there also ways that we can as a community really think differently about baking in some of the questions that we know a designer is going to be asking us or some of the iterations, some of the changes that we could imagine are possibly going to be asked for by the design team in the future. Is there a way to kind of help integrate those with our existing code base tooling to make it easier for us as developers to see those possibilities and stick to those constraints as they are developed, understanding that they might change, understanding that similarly to how we might tweak our lending rules once things become a problem, we might need to kind of codify more or less of the design choices into the code base in a way that we can easily move forward later when things change. This is sort of the promise of design systems, right? The promise. There's some deep hurt behind that. Is this design system in the room with us right now? Design systems are fine. They're good. They can also sort of, as I'm sure, some people in the room probably work for companies big enough where they have extensive design systems teams. My feeling is that small products often move fast enough that if you do a design system too early, it ends up being more of a problem than it solves. But, that said, if you can make the promise real, then it's quite effective at that kind of third language between developers and designers and, like you said, anticipating change and anticipating styles. As with everything. As with engineering in general, you know, premature optimization always being a problem. Weighing that trade-off between how much time do we spend ensuring the tooling is going to encode all of our current assumptions versus how much time do we spend actually validating those assumptions and seeing if we actually need those things that we thought that we need. I think it's almost like coming back full circle to the original problem of how do we create an iterative process that can move as quickly as we need it to. I think following this, I feel like the logical conclusion of this conversation is what is the relation between UX and DX in a way? They're often post-antithesis. There's a lot of moralistic, for example, web developers who think that building DX tools is putting the user second. But, I think, Maggie, you've been historically very critical of the user experience of the developer tools that we use. For example, it's completely impossible for a designer who doesn't have technical mentorship to even get a modern React project running most of the time. So, what do you think that everybody in this room should do to help along this collaboration? Okay, how do I answer it in a short way? I usually take the position that developer experience is, at the moment, really quite bad. I don't know if I'm allowed to swear on stage, so I won't, but I would use swear words. As developers, I'm a bad developer, but I'm a developer too. I feel bad for me and all of you for having to use these tools right now. They fundamentally don't take advantage of our very rich, visual, embodied understanding of the world. They're very limited. We're all stuck in text. It should be better. The kind of question is, how do you raise that quality bar? One is developers getting more interested in user experience and design as a discipline, getting better at UX and design, because designers are never going to build better developer tooling. Developers solve their own problems with tools. They're infamous for it, right? Like Vim, Emacs, right? They kind of go all out, really wild, crazy systems. But they're never coming at it with a very rich understanding of interaction design and visual design and the process of designing things for someone else and doing user testing and iterating on that. I think the way developer tooling gets built now doesn't have a lot of very sophisticated or nuanced design practice to it. And if there were a group of designers, I mean, developers, that were to skill up in design and then solve their own problems with tools and apply the design thinking process, I think DX tooling would level up. So that's kind of my current, I guess, hammer I'm wielding, is how do you get people who are already inclined towards design, like you're one who came from design first, but people who live at the hybrid of those two are probably the ones who are going to build the best DX tools in the future. Yeah. If I can piggyback on that, most DX tools are not designed. And I say that in that there's not a design process involved in the creation of this API or whatever. There's a design process that's founded on the idea that, well, I don't know how this should work. We should get the people in and figure it out that way. And so I would say it's really zero to one in most cases with DX. And you can tell when it's good. When it's good. And you're like, you involved some people not on the team in the design of this API or the design of this tool or workflow. But you can also tell when it was just some guy. And I think a lot of the most successful or most loved developer tooling comes from that one person, or a person who has a taste and a vision, who has an original insight about something. And then some of them end up being successful. But then there's all those thousands of other developer tools and libraries and packages and CLIs that don't end up being that useful. Do you think that applying a quote-unquote design process would help those projects that are struggling? Well, I mean, if you have something out there long enough, for example, like React. There's a great example of an API that has been in the wild long enough to be designed the hard way, which is to have the Davids of the world yelling at the team, like, this doesn't work. I'm like, please make this better. And just so much interaction with the community. New projects, small projects, aren't going to have that. And so, yeah, you could take your best guess at it, and maybe that's fine. But I think if DX is something that you want to have part of the, whatever your product's DNA, from the very beginning, then it shouldn't be the kind of solo. No matter how good your opinions are or whatever, it's just an incomplete data set on which to make that decision. And I think on that note, I think we need to follow our own advice and also ask our users, what is it that they actually need instead of pretending to know what they want. So thanks for getting the Slido up. That was good cue reading from whoever is in the booth. I think one question that we probably don't want to finish on, but I think we definitely do need to spend a little bit of time on, is what are some concrete tips that developers who are trying to learn the foundations of UI, UX, who are struggling with what this person calls poor creative skills, which I think is a very interesting self-deprecating description. I don't know that necessarily different humans have that large scale of their creative skills. They just may apply creativity in different ways. So what are some very concrete actions that developers who struggle to get into this could take? Do you want to try? Yeah, I'll keep them short. A couple. If you are someone who's like, oh, something about design appeals to me. I'm a developer. I love development. I want to stay a developer. But there's something over here that I want to explore. I'd say most online courses might not be the best way to go. But it depends on your current job situation. But your career is long and React developers are definitely in demand right now. So you kind of have a lot of leverage and power at the moment in terms of what job you want to work at and what the company is like. Working somewhere small where you are literally physically sitting next to a developer, even if that's remote, but working closely with them every day, is the best way to learn exactly how developers think and work and learn how to start thinking like a designer yourself and becoming a designer yourself because you can be both. If you can get yourself into one of those positions, that's really valuable and probably the most effective way to get good at design. I'm hiring. Call me. I would say a lot of design is imagining other people and imagining other people using it. So fiction? I would read fiction. That's actually a serious recommendation. Chances are whatever team you're on has a design process of some sort. Try and be a part of it, even if you're a silent person in the room. Getting involved in that process is how you do design. Yeah, and I love that about the suggestion about fiction because it is really about kind of empathizing with the user, whether the user is kind of an end user clicking on buttons on your website or whether it is a developer building with the tool that you're working on internally or externally. I think one of the things that we maybe don't do enough as a developer community is actually talk to and listen to our real users in the real world in addition to imagining our kind of potential users. If your team or your company has anyone doing user research, they are going to be a huge wealth of information on the things that they've heard from users, the things that they've found out. If you are in a position where you're going to conferences and talking to people who have used your product or your tool, find out from them what their experience has been and actually really listen. I think we tend to often get very defensive and justify, well, this is how it works this way, and if you didn't have a good experience, that's because you didn't read the docs enough or whatever it is. Really try to listen. Really try to understand what those struggles were, what those moments of joy were, and really listen to the actual people experiencing the thing you're trying to build. And I think how this conversation started also, developers today have a lot of leverage. If the design process where you work currently is not malleable to your needs, if there is a handover process, if anybody is sending you Photoshop files, then there are opportunities elsewhere. And Steve is hiring, so talk to Steve. Let's take another question. We kind of wanted to stray away from tools, but this is by far the most wanted question, so I'm going to ask it anyway. Where does user testing fit in the iterative process of designing the perfect arrow, and what tooling would you use for user testing a dynamic prototype? My most effective research tool is Twitter. I realize that that's not going to work for everyone, but at least in my experience. Building something in public, scaling it way down to the size of a code sandbox, and being able just to send that out, and little GIFs or whatever, and solicit opinions that way, has been enormously effective for me. I don't know how you do that for every product. You could probably do it internally. Again, if you're working on something that is small, interactive, and you're not sure really what feels good, and that's the North Star that you're chasing, having some way for other people, people other than yourself or the team that you're on, to give you feedback as soon as possible, even if it sucks. The product, not the feedback. That's the way to do it. Twitter is really good for that, for side projects. People love GIFs. Cool. Let me jump into the next question. We don't have a lot of time left, but I think this one is good to tie back to the React ecosystem. This is a React conference after all. The question here is, what resources would you recommend to speak the same language and think about components, reusability, composition, reusability, etc.? I'm going to broaden this question by asking, this kind of terminology that we use as React developers, is this useful as the kind of language of mindshare between development and design, or development and UX? Is the React ecosystem's focus on these particular attributes actually the best way of modeling these things, or is there some other language that we could be using? I'm looking at Maggie intently here, because I think she will have something interesting to say, but anybody, feel free to chime in. The question is, is the language we use for React useful when you're communicating with designers? Yeah, and I think the question here is, what resources you'd recommend to help speak the same language, but I wanted to question the premise of that and say, is that the language that we should be speaking? Okay, for resources to be tangible about it, there's a thread of design called conceptual modeling, or also called object-oriented UX, that's really, really great because it's essentially development, but masked as a thing for designers. And it was developed originally at Xerox PARC, on the very first graphical user interface, where the people building it were, there's no distinction between design and development, they were the same, they were also building the hardware, which is ridiculous, but they had a unified vision of how this computer worked, everything from the user interface down to the hardware, and they developed this system of how you design software, by starting with components and relationships and attributes and things that we would all recognize as developers of how we all think, and it kind of got lost somewhere in the 90s, and like all the mess, and now people are coming back to it through conceptual modeling, or even information architecture touches on a lot of this. But if you find a designer who knows those terms, they're going to speak the exact same language as you, they might have different buzzwords, but it's literally the same concepts. Cool, could you repeat the name of the research? Oh, if you Googled either conceptual modeling, or object-oriented UX, OOUX, you'll find a lot of stuff that will look very familiar to you. Incredible. We've been just given the flag for time, this conversation has been in-depth and titillating enough that we have basically overrun our time slot. So unfortunately we don't have time for any more questions, but there are tons of questions here from Slido. I guess you'll all be at the speaker Q
&A room now on this break, so please do and ask more questions from our panelists, who we want to thank now for coming here. So thank you panelists, thank you Steve, thank you Maggie, and thank you Anjana.
React Advanced Conference 2022