Panel Discussion: UX and the Design/Dev Overlap

Thank you very much. Can we have a round of applause for our panelists? Thanks for being here. There's a whole long introduction that I'm supposed to read for all of you. Instead I'm going to ignore that and start with, you know, sort of like a personal introduction because you three might be, you know, some of the, you know, a little bit of my like developer design heroes, all of you in different ways.

Steve works at TLDraw as the founder and the creator of TLDraw. And he is one of the most sort of 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 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 as well 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 a 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 working on some truly exciting projects which I'm sure 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 questions 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 that design process? Who wants to go first?

I mean, the simple answer is no, developers don't have to become designers, right? 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 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.

I would agree with that. I see design as kind of opinions about how things should work and 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, like, the whatever 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 frontend developer, absolutely a place for you to participate. Oh, oh.

Can we get another microphone? I think it's over there. Yeah. And I think totally plus one to what's been said already. I think 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 like 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 multi-disciplinary 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.

To build software, I think, you know, 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 like 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 sort of 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 own 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, maybe you get into specialization and you're just maintaining or building out an existing thing may be 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, like, development teams, where it's like, well, how should this very custom part of our app feel? Not necessarily like look, but how should this interaction be? What should our 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, like, conventions and the tracks, like the more the kind of 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. And 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 sort of, like, workflow, right? Like, 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 sort of user research and sort of more methodical design process? Like I said earlier, design is a lot of processes.

How do you make a decision? If that decision is a color, right? Like, 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. Making a perfect arrow is the same. It's just that with all of these sort of 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 a design, a normal design That iterative process is just impossible to do if you're just doing this on something like from MOC's. 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.

Yeah. 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 decent developer and designer tooling. The fact that a designer cannot iterate in Figma in any meaningful interactive way. I always say Figma is the worst design tool except for all the others. It still profoundly does not meet our needs as designers and developers to build 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 and I was like, that's bait. I think it's very tempting to think that... not to criticize the feeling, like 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, the less you have to design. And that's a big issue with, for example, Figma normal kind of like mock based tooling is that you're just faking everything all the time. That's almost a separate issue to 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 like 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, you know, 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, you know, 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 based 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, you know, tweak our linting rules once things become a problem, we might need to kind of codify more or less of the design choices into the codebase 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. The promise. The never works. There's some deep hurts behind that. Is this design system in the room with us right now?

Design systems are fine. They're good. 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 if you can make the promise real, then it's quite effective at that kind of shared language between developers and designers, and anticipating change and styles. As with engineering in general, you know, premature optimization always being a problem. Weighing that tradeoff between how much time do we spend ensuring the tooling is going in code 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 just, it's almost like coming back full circle to the original problem of how do we create an iterative process that's, that can move as quickly as we need it to.

Yeah, I think like, following this sort of, I feel like the logical conclusion of this conversation is like what is the sort of relation between UX and DX in a way, right? I think it is, you know, they're often like, you know, post-antithesis, you know, there's a lot of moralistic, you know, for example, web developers who think that building DX tools is putting the user second. But I think Maggie, you've been kind of like historically very critical of the user experience of the developer tools that we use, you know, for example, it's completely impossible for a designer who doesn't have technical mentorship to even like get a modern React project running most of the time. So what do you think everybody in this room should do to sort of like help along this sort of collaboration? Okay. How do I answer it in a short way? I usually take the position that, yeah, developer experiences 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. I mean 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 are like fundamentally don't take advantage of our very rich, visual embodied understanding of the world. They're like very limited. We're all stuck in text. Like it's all like should be better. And the kind of question is how do you raise that quality bar? And 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 go 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 like 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 hammer I'm wielding is like, how do you get people who are already inclined towards design? Like, you're one who came from design first. But people who live with the hybrid of those two are probably the ones who are going to build the best DX tools in the future.

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. 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, you're like, oh, 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, a person who has a taste and a vision, who has like 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 sort of help those projects that are struggling? Well, I mean, you have, if you have something out there long enough, for example, React is 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. You should make this better and there's so much interactive or 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 or those decisions. 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 wanna finish on, but I think we definitely do need to spend a little bit of time on is, what are some like 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 like 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, right? 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 like 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, kind of, but working closely with them every day, it's 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. Yeah, 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. But yeah, 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 have heard from users, the things that they 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 like really listen. I think we tend to 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's 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 in 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 can probably do it internally. Again, like if you're if you're working on something that is small, interactive, not sure really what feels good, and that's the kind of the north star that you're kind of 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 that's the way to do it. Twitter. 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 kind of tie back to the React ecosystem. This is a React conference after all.

So the question here is what are what resources you'd recommend to speak the same language and think about components, reusability, composition, reusability, etc. And 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 mind share 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? And I'm looking at Maggie intently here because I think she will have something interesting to say, but anybody feel free to chime in.

Wait, so 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?

Well, 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 like the very first graphical user interface where the people building it were, there was 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 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 gonna speak the exact same language as you. They might have different buzzwords, but it's literally the same concepts. Could you repeat the name of the research? Oh, if you Googled either conceptual modeling or object-oriented UX or OUX, 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.