Panel Discussion: UX and the Design/Dev Overlap

Rate this content
Bookmark
Anjana Vakil
Anjana Vakil
Maggie Appleton
Maggie Appleton
Steve Ruiz
Steve Ruiz
28 min
20 Oct, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

The panel discusses the overlap between UX and developers, emphasizing the importance of collaboration and learning about design. The lack of decent developer and designer tooling is a big issue, and there is a need for a tool that bridges the gap between design and development. Understanding the promise and challenges of design systems and improving developer experiences requires a focus on UX and design as a discipline. Developers skilled in design can improve DX tooling, and getting involved in the design process and user testing is crucial. The language of React can help bridge the gap between developers and designers through conceptual modeling and object-oriented UX.

1. Introduction to Panelists and Discussion Topic

Short description:

Thank you to the panelists for being here. Steve is an insightful developer and creator of TLDraw. Maggie is a hybrid developer, designer, and anthropologist. Anjana has a holistic view on programming and is working on exciting projects. The panel discusses the overlap between UX and developers. While developers don't have to become designers, they should be open to learning more about design and working closely with designers. Developers can contribute their opinions on how things should work and participate in the design process based on user needs and product goals.

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.

2. Collaboration and Hybrid Thinkers

Short description:

Building complex systems requires collaboration and diverse perspectives. Early product definition benefits from hybrid thinkers who understand technical requirements and design thinking. Following conventions is common, but original designs require collaboration between designers and developers. Steve embodies a synchronous designer-developer workflow, combining intuition, taste, user research, and a methodical design process.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

The Whimsical Potential of JavaScript Frameworks
React Summit US 2023React Summit US 2023
28 min
The Whimsical Potential of JavaScript Frameworks
Top Content
When it comes to building whimsical interfaces, React is a surprisingly capable ally. In this talk, I'll show you how I use React to orchestrate complex interactions by digging into some examples from my blog.
Domain Driven Design with Vue Applications
Vue.js London 2023Vue.js London 2023
14 min
Domain Driven Design with Vue Applications
Top Content
Introduction to Domain Driven Design- What is DDD?- Key principles of DDD- Benefits of using DDD in web application developmentDomain Modeling in Vue 3 Applications- How to design and implement domain models in Vue 3- Strategies for integrating domain logic with Vue's reactive data model and component-based architectureBest Practices for Implementing DDD in Vue 3- Strategies for organizing code in a way that follows DDD principles- Techniques for reducing coupling between domain and application logic- Tips for testing and debugging domain logic in Vue 3 applications
Proven Pinia Patterns
Vue.js London 2023Vue.js London 2023
20 min
Proven Pinia Patterns
Top Content
With Vue's new-and-improved state management library, Pinia, we gain a much more modular tool. While being more flexible, leaner, and lacking the Mutations of Vuex, Pinia presents us with more opportunities to be creative, for better or worse, with our app architecture and how state management is conducted and organized within it.This talk explores some @posva-approved best practices and architectural design patterns to consider when using Pinia in production.
Asynchronous UX
React Advanced Conference 2021React Advanced Conference 2021
21 min
Asynchronous UX
Top Content
"Please do not close or leave this page" may send shivers down your spine, but coding the proper UX flow for async might make you question your daily job. How can we properly handle UX for asynchronous code in highly responsive applications? Let's explore how introducing asynchronous code creates a challenge for UX.
Component Design Patterns
Vue.js London 2023Vue.js London 2023
18 min
Component Design Patterns
How do you write a good component? In this talk we’ll explore several different patterns for writing better components. We’ll look at techniques for simplifying our components, making them easier to understand, and getting more out of the components we’ve already got.