Rise of No-Code/Low Code Platforms

Dana Lawson, Catherine Cornell, David Hoang, Guy Dvir at UXDX USA. Video: https://www.youtube.com/watch?v=JuEdOJtm5OI

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introductions

[00:00:00] Guy: Wow, I'm super excited to be here, and I'm stoked to talk about this subject, but I'm completely biased. I'm a UX prototyper at Editor X, so from what I do, I know firsthand how powerful coding is, and also how no-code can give you tremendous velocity. What I think will be interesting for you guys watching is that we have these amazing people here from different perspectives to talk about it. I feel like we have our own private Justice League of people to talk with and hear their insights. So, guys, let's do a very quick introduction and I'll dive right into it. Let's start with you, Catherine.

[00:00:43] Catherine: Hi, everyone. I'm Catherine. As mentioned, I'm currently the director of product at Stash, which is a fintech company based in New York City. I've been a product manager for about seven years. The way I interact with low-code, no-code stuff now is through some tools that we maintain for our product marketing team, and that we also use in-house in product.

[00:01:08] Guy: Awesome, thank you very much. David, let's go to you.

[00:01:12] David: Hi, everyone. Thank you so much for having me. I'm David. I'm director of design at Webflow. I lead product design, user research and also brand design in-house [?]. My no-code background has been how I got up in the ranks of getting into design and prototyping, all the way back in the days of HyperCard and Dreamweaver. And Guy, I'm sure you can appreciate this: it's kind of meta now to design a design tool for designers and really think about that space. So that's where I've been spending my energy.

[00:01:45] Guy: For sure. And also, you already won the most designed room out of everyone. It's already way cooler than my setting. And last but certainly not least, Dana.

[00:01:53] Dana: Hi. Dana, VP of engineering and partnerships at GitHub. I don't do any low-code, no-code; I just do all code. Being the home for all developers, and thinking about open source, we just see this as the next generation of makers and builders to produce and innovate, so I'm very passionate about the subject. And yes, David wins for the coolest background. I went totally sterile.

[00:02:18] Guy: I'm with you, same here. Thank you, Dana.

Defining no-code

[00:02:22] Okay, so let's dive into it. And guys watching, if you have any thoughts, comments and questions, you can write in the chat. No-code and low-code, I'm going to call it no-code from now on, just for brevity. It's a really big term, so I really want to make it more down to earth. How do you define it? Dana, let's continue with you. How would you define no-code?

[00:02:48] Dana: No-code is really an abstraction of the programming language, built in a modular way, so that people without a traditional background in computer science or coding can build applications. I like to think of it as building blocks of the whole system, as a full stack. Typically they're demonstrated in a graphical interface, to make it really, really simple to use. Not all of them; it depends on the platform. But I think the simplest way to put it is a building block abstraction of code to build applications.

[00:03:14] Guy: Yeah, I really agree with that statement, and I want to hear what David has to say too. What's your take on it as a design person?

[00:03:25] David: I agree with that too. Often people associate no-code with anti-code, and I think that's not true at all. It's just different means and pathways to get there. When I was a designer, I loved using code, so I'm not anti-code. It's just different means to be able to get the job done. And plus one to how Dana articulates it, about the abstraction. The thing I would add is that no-code, for me, is not needing to know the mental models, or learn how to code, but still having the power and access to it through that graphical interface.

Why no-code is growing

[00:04:01] Guy: Yeah, I feel that power is getting more and more powerful and appealing. And I want to ask you: I feel like we've had no-code and low-code for a while, but it's getting more prevalent and bigger. What do you think is driving this growth in this area? Or maybe more specifically, do you feel like more people want to get into building things, or more people who build things want greater velocity doing it?

[00:04:28] David: I think for me it's more people wanting to build things, and it's really about having different pathways for where people start. I've heard people who use Webflow, or who've used Wix and other tools, say, hey, I actually learned how to code from this. So I think it's starting from that intention of, I want to create something, I want to be able to express something on the web. And now there are just more, different pathways to get there.

[00:04:53] Guy: Okay. And Catherine, I also want to ask you about this. Do you feel like the main appeal is, like David said, the power that it gives me, or also a way for me to get into understanding coding better, and also using that as a tool?

[00:05:12] Catherine: I think those are two sides of the same coin. Definitely, because you want to be empowered to do things yourself, or maybe try something that's outside your current programming skill set. But when I think of no-code, I also think of the children's games that are just building blocks, essentially, to teach you how to code. And adults like that too. There are all these no-code games you can find on the internet to teach you the fundamentals of Python or Ruby. I think a lot of times in professional settings, people come for the DIY: I don't have to bug an engineer, I can own this myself. And they end up staying and growing with the tool, and maybe even outgrowing the tool, because of the learning opportunities and the learn-by-doing that happens with them.

Benefits for product teams and for developers

[00:06:05] Guy: Okay, so I hear that you're saying it is something appealing, and also, like you're saying, I can do stuff on my own and I don't need someone else. Especially from your perspective, using those tools in a product process, what other benefits do you think of when you think of no-code?

[00:06:20] Catherine: Sure. In product building specifically, obviously the speed at which you can get something out, and the resource saving. To me, the most important is that usually you can utilize these tools and get something out there without needing to deploy. So you're not tied to your current deploy schedule. You don't need to incur the risks of having a deploy go out. So it frees up not only your engineering time, but potentially your DevOps time or your security team's time. And it lets you operate on a schedule that isn't tied to maybe other players at your company.

[00:07:03] Guy: That's interesting. So Dana, you hear what Catherine is saying. How do you see it as someone from the other side of the spectrum, as a developer? Do you feel there are also benefits that you as a developer agree with, or maybe not?

[00:07:19] Dana: I think for the most part developers, myself included, are inherently efficient. Some people may say lazy; I'm going to say we're efficient. The world's built on copy pasta, and to me this is taking those rudimentary tasks, those pieces that you can just leave to this modularized way. Because you're not going to utilize a platform for a really complex system, something that's so proprietary to your business. You may use pieces of it. You may use pieces for your business systems that support and enable that, and that's awesome. Depending upon what you need, you use the right tool.

[00:07:57] The part for me is that there's this fear that as these systems mature, and with the rise of artificial intelligence and machine learning, what about the curly bracket developer? I'm like, well, somebody still has to write that code. And being the most efficient developer, I think, hell yeah, let that happen, because I don't want to do that stuff over and over. I want to do the fun stuff. I want to do the creative stuff. I want to solve the problems where you have to really experiment. So there are two really different types of business needs when you think about these platforms.

[00:08:28] There's always going to be a level of skepticism. That's just who we are as humans: what's this platform you're introducing, and can it really do what it says? But you've seen the maturity of this happen over the years, because these systems have been around without the vernacular of no-code, low-code. Shocker, they've been around. This isn't a new revolutionary thing. It's just a better thing. From a developer experience, I think it's just going to really empower everybody, because it unlocks agency. Software development is a team sport. There are so many people involved. There's a huge orchestration across the company, especially for a technology company, in how you deliver product. And I'm all about this, because we forget sometimes as engineers: oh yeah, there's a billing aspect. Oh yeah, there's probably a marketing aspect. Oh yeah, a support aspect. Empower the whole life cycle.

[00:09:20] David: I just want to add, I think no-code has been the most developer-friendly innovation that's happened, and that's because, Dana, we're pro curly bracket developer. Let's be real: there are going to be things that are always going to be at the back of that Jira backlog that no one's ever going to get to, and now you're empowering teams to be able to get to that, so curly bracket engineers and developers can work on the fun stuff. I know there are so many engineers where you do the whiteboard interview, and you're learning about ML, and they're testing for that, and then you start your job and they're like, here, center this button, or fix these layout things. Having no-code helps developers really focus on some of the most complex problems. So I think it's one of the most pro-developer technologies available.

Risks: skipped QA and undocumented custom pieces

[00:10:13] Guy: Amazing. It's really great to hear it from someone from the opposite side. I want to ask about maybe the flip side of it. You're saying it's a way for people to do stuff in parallel to the developers. What about terms like rogue IT [?] and stuff like that, people doing it on the side? What do you see as the risks in those kinds of things, and how do you maybe mitigate those kinds of risks?

[00:10:39] Catherine: I can jump in first here. I mentioned before that you're able to operate outside of your normal deploy schedule, do stuff midday, intraday, if maybe you're a once-a-day shop. You might also miss the QA cycle, when someone can in theory go off and do this by themselves. I also think that, because no-code, low-code is so well adopted at places, and I'm thinking of instances where a company uses something that is no-code and then they move into low-code, where an engineer makes a custom template that a product marketer can use over and over again independently. What happens when that product marketer, who got really good at it and finessed it the way they like, leaves? You're left with this gap, where you now have this pseudo-proprietary [?] thing that isn't documented in a place like GitHub. Ideally it is in Confluence, but you can be really left with a gap in your system if you were using this critical custom piece for a while. Yeah, missing the QA cycle is a big one. And then there's also...

[00:11:54] Guy: If I could interrupt, sorry. I just wanted to ask about what you said. Are there any ways, maybe from your experience, that you find solutions to transition from no-code to low-code to maybe full code?

[00:12:09] Catherine: Yeah. I can give you an example of something that we've done over at Stash. We use a low-code, no-code marketing tool for in-app messaging, and we have some levels of customization, but we strive really hard to keep everything pretty straightforward. We train up our product marketers in basic HTML, basic CSS, so they can do some stuff if they want. But they follow a QA cycle as well, and it's something we had to introduce, because originally they were doing their own thing: why would I QA? I don't do that with other stuff; that's not part of my process. I'm not an engineer, I don't need to do that.

[00:12:53] So I think whenever you're moving from a no-code to a low-code situation, introduce other engineering principles into the process, the bare minimum being QA, the secondary being having some sort of documentation, some sort of readme, so that others can come in and understand what you've done and why you've done it that way. And then in terms of moving from low-code to total code, I think the best thing you can do is acknowledge what you're doing, and acknowledge you're no longer making a simple tool that everyone is going to be able to use. You have to acknowledge: all right, engineering is going to take this over. They're going to build it, they're going to maintain it, and it's not going to be this hybrid thing anymore.

Applying the engineering mindset to no-code

[00:13:38] Guy: So I see you talked about documenting what you do and preparing stuff for handoff, and I see Dana nodding really widely there. What do you think, Dana?

[00:13:47] Dana: I'm going to tell you, I'm very biased to the engineering workflows. Anything I do, even at home, I'm like, oh, here's the engineering process, because all process is software waiting to be built. That's what a process is. So just like Catherine said, make sure you have the right level of process. To me it's applying that engineering mindset to a no-code, low-code platform as far as change management is concerned. You have to build this culture, and you want this culture where you empower people, and you've made the constraints and the reasons very clear, and you've also built in the guardrails.

[00:14:26] Because we have this pressure on us to deliver and produce, and sometimes that pressure can override that "stop and wait for a second, make sure you've dotted your i's and crossed your t's." It just happens, especially in this day and age, when there is such an opportunity for innovation from everybody. That means it's a little bit more important for you to continue to produce. So we mix that together. To echo that: no-code, low-code is still an engineering process. You're building a digital asset. Use those principles, have change management, and think about it in the right way. Maybe you don't have to do a full-scale, sophisticated deployment pipeline, but you should still have the processes behind it that mimic it in the right places.

[00:15:13] Because not only can you introduce security problems, and bespoke solutions where it defeats the purpose of investing in one of these platforms, but thirdly, your brand. I hate to say it, but one of the killers is if you inadvertently produce something that is at odds because it's been rushed or it's sloppy. Have every designer on your team yell at you. Trust me, they will. You should get yelled at. But I think it starts with really producing a culture that says, hey, citizen developer, this is how we develop. We document, we test, and we ensure and inform, but we move fast. You have to set those principles throughout the company, because if you're taking these tools and making the ability to create more community-driven, then you're going to be following those principles. Seriously: congratulations, you're a developer now. This is what developers do. That's how you just have to approach it, in my opinion.

[00:16:11] David: I love it. I was going to say, I can confirm designers will yell at you, and talk about the experience consistency. I agree with what Dana and Catherine said. I just wanted to add the lens that when you think about user experience, trust is the most important thing, and if you're not thoughtful about change management at scale, that's where trust can be broken. If you're daisy-chaining a bunch of different no-code tools and there's some security flaw, that is the worst user experience you can have. At that point nobody cares if the border radius on the buttons is consistent. You've just lost trust. So the thing I want to add is: scale thoughtfully, and think about the threshold of, this can work for now, but when do we need to flip the engine and make that change?

Security and third-party plugins

[00:16:56] Guy: I think that's very insightful. And like Dana said, I really love that: let's use principles we're already using in the world of coding to try to preserve that kind of quality. I want to continue with what you said about security, David. I want to ask specifically about concerns with using third-party apps or plugins. You're saying try to be as smart as you can and make the whole process as good as you can, but what happens when you use external resources where you don't really know what control you have over the security? What are the risks there, and what can be done to help with it?

[00:17:33] David: There's a ton of risk. Before Webflow, I was at One Medical, talk about a very regulated place where security is super important, and I treat it the same way. The same way no-code is developer friendly, we want to be infosec friendly too, because there are a lot of challenges, and we need the smartest people in security to help us figure it out. My approach is to really offer up transparency and intention about where you want to be using these things, because again, there are a lot of unintended consequences. Like Dana said, really practice the same principles that you have in any other way of developing software. It's really vetting these things and seeing, okay, is this a workflow where there's little to low risk, or is this a high-risk area? And really collaborating with IT and security on what those things are.

Choosing the right tool for the job

[00:18:28] Guy: It's a great point, and I think transparency is a very insightful measure for understanding what you're handling and what you're dealing with. Okay, we talked about benefits and we talked about risks, so I have a way to weigh the pros and cons. Let's say I decided to use a no-code solution. How do I even decide what I want to consider when choosing the right tool for the job? Catherine, maybe you have some insights from the process you're running with no-code.

[00:19:03] Catherine: I would first make sure that it's going to solve the problem you have, and not just do the thing you want it to do, if that makes sense. I think a lot of no-code solutions are very slick, and because they're so easy to get started with, you maybe rush to try and get it implemented. Then you're in a spot where you find yourself making those custom templates and getting yourself into that low-code zone, which maybe isn't a bad thing, but at the front you could have done a little bit more problem thinking, and seen whether what you were getting out of the box is really going to solve your problem, or whether there is something else out there that could be a little bit more specific. And that's not a bad thing, if you have to go low-code at some point. But I think being realistic at the front about what the expectations are for the engineering team, and again, creating that life cycle of good change management principles and policies at the beginning, is very important.

[00:20:16] And then I would also sit down with the people that are going to be using this day to day. I think it's really easy to pick a no-code solution and assume that everyone's going to be really excited about it. I think most people are really excited at the chance to have more agency and own their own destiny, but some might feel like, this is a lot for me to handle, this is a lot of responsibility. So going into it without their input is usually not the way to go. Those would be my recommendations: make sure the problem's solved by this. If it's not totally solved, make sure you have an engineering plan for how to implement and maintain this long term. And make sure you're getting the input of the people that are going to be using the tool day to day.

[00:21:07] Guy: Cool. So I'm hearing: consider everyone on the team. And I also heard, if I got this correctly, try to think of value and not the short term, what I want to do tomorrow. It gives you a lot of velocity, so when you put the pedal to the floor, make sure the steering wheel is in the right position, if I get what you're saying.

[00:21:27] Catherine: Yes.

[00:21:27] Guy: And Dana, what do you think? From the side of developers who work with people who use no-code, are there considerations you would like them to take into account?

[00:21:39] Dana: But they own it. From a developer standpoint it's like, oh, come on, think about what you're doing before you go do something that's not out of the box, because we're busy too. No, but I think it just comes down to this. I'm not a designer, and Dave will love this: use design thinking. That's basically what Catherine's saying: solve for the long term, in the most polite way possible. I need you to use some design thinking about how you want the tool to be. But it gets so fast. I think we're under this immense amount of pressure, and humans naturally want to do their best. I'm a chronic insecure overachiever, and I think a lot of people that are makers and builders in our space are the exact same, at least in some way, because you want your babies out in the world. So you've got to make sure that it's done right, and done thoughtfully, and done for the right purpose, and that you're not doing something because of the pressure to get it done. It's really taking a breath and finding that balance.

[00:22:51] And then also the whole life cycle. It's hard to sit and say, what's your three-year strategic plan, when everything is so freaking unpredictable in the world right now. But I encourage people to sit there and think long term: that scalability, that support cycle. Because you have to be fiscally minded. You may go and say, I'm going to purchase this for 12 months because it's going to save X. At the end of the day, that's probably one of the biggest reasons you make these trade-offs for a lot of companies: it comes down to dollars and cents. Does it cost more money for me to have a whole engineering team, with a support life cycle and my own IP, to build whatever? Or do I buy this product that's already been built, and have people with a non-development background be able to do it, which will probably be a little bit more cost effective in some ways? But you can offset those savings by building the wrong thing. So it's really this deep thinking, and that's why I come back to: let's apply some design thinking when we make a solution choice, and start there. Don't start at the speed. Don't start at how much it costs. Start at the problem. And it's hard to pull yourself back when you just want to go, go, go, at least for me. I'll say that for me.

[00:24:02] Guy: I love it. That's why I called you the Justice League: we have a developer talking about design thinking. That's priceless. I really like it.

[00:24:10] David: You know what's funny? I feel like we're doing musical chairs, because what I was going to say is that you should think like a product manager. What you really need to think about is what the jobs to be done are. Is this something someone can use? What's that intention? Because there is such a thing as overbuilding, over-architecting for something you don't need, and every decision is going to be a cost. I was a little nervous, because I was wondering if Guy was going to ask whether people should use Editor X or Webflow. And it's really about what that use case is. So my suggestion is, start even before you make the purchase. There are free trials for all these things. Really find a way to put a proof of concept together and test it out. So Dana's telling you to do design thinking, and I'm saying think like a product manager and really, really nail those jobs to be done.

[00:25:03] Guy: Okay, so now it's Catherine's turn to tell everyone to do as a prototyper does. There you go.

Simplicity versus capability

[00:25:08] Okay, so David, I want to ask you something, again from the design perspective of someone who actually works on a platform for no-code. I want to talk about simplicity versus capabilities. I feel like there's always tension there. Speaking from experience at Editor X, when we, for example, tried to work on packaging CSS Grid and Flexbox and shipping them as something very powerful, as they are, but also very manageable and easy to use, we were trying to be very focused on this thin line. So I'm really interested to hear how you handle this, and how you approach that kind of tension.

[00:25:44] David: Oh man, we're still figuring it out. It's a tough problem, because everyone has different needs. There are different mental models. I thought, when I was going from building my own HTML and CSS sites, I'm going to stop having this paradox of choice about what CSS framework I'm going to use and just go into no-code tools. And for us at Webflow, it can be very complex. That's the thing: there's a lot of power that it offers, but not everyone needs that power, and everyone's coming from different ways of learning. If you have a front-end dev background, it's probably very comfortable in that regard, but if you're a designer who may be non-technical, or just anyone building a site, it can be challenging.

[00:26:25] So I think for us it's really understanding what that progressive power is. How does someone get started and continue to learn and master the tool itself, if they even need to? We're exploring what some elegant affordances are that we can add for people, where if you need that customization, it's still available, so you're not capping that power and taking it away. We don't ever want to take away the power from people. So it's very much a UX problem that we're trying to solve, and we've been doing a lot of prototyping work and understanding around this. But it's tough, because there are different personas, and as we continue to grow there are going to be different needs. What we've been leaning on is that progressive power, and understanding which areas we can simplify without completely removing things.

Extensibility and the option to code

[00:27:14] Guy: It's a great answer, and I do want to still challenge you a bit, because I also saw a question from people watching. Gary stated that he sometimes wants to create very advanced animations, for example, or interactions, and he's wondering if the tools are able to create those kinds of things and do the same things that raw code can do. But my question from that is: do you think putting the ability to code inside the no-code, low-code platform is a solution that you favor, or that you try to avoid? And will we always have the option to code? Is it something that will never disappear?

[00:28:02] David: Let me think of my principle for it. I think extensibility is important, forever, whatever extensibility means years from now too. With no-code you still want to be able to extend the code. So having abstractions is important, but also raw output, I believe, is always important. Again, I don't think we'd ever want to take that away. I think there's a question of how much that native offering should be available for people to do it, and then what the use cases are where you need to do something sufficiently complex. I don't know what type of animation this would be, but let's say it's something really complex, visualizations that you have to do with code. We'd have to decide what that trade-off is. But I do think, regardless of how sophisticated no-code gets, that concept of extensibility is always going to be crucial in whatever that next technology will be.

[00:29:04] Guy: Okay, so I want to bring it back to Dana and ask, regarding what we just discussed, the place where no-code and code actually meet: what difficulties do you find there, and how do you see it growing in the future, into something that includes everyone, not the no-coders only or the developers or curly bracket people only, each in a separate tool? How do you see it?

Lowering the barrier: everyone can be a developer

[00:29:31] Dana: I swear we did not plan this. I'm going to say it is about extensibility: having the ability to create, again, a modular, I don't want to say an extensible whole output, but I implore these platforms out there to have an ecosystem. Make a way to have an SDK, or another opportunity to have these extensible pieces, so you can have the feature set that you need. You're going to build to the 80%. You've got 10% that are always going to love you and say, this is the best thing, I don't need anything, it's amazing. You're going to have the 10% that think it sucks, that no-code, low-code is stupid, and that everything should be done by them, and forget about it, those guys are for losers. There's always going to be that subset too. But the 80% are going to see this opportunity and go, wait a minute, we're innovating. This is human form at its finest.

[00:30:21] Why not embrace it? Why not have this amazing platform that continues to lower the barrier? Being a developer should not be sacred, because you know what? The world is driven by technology, and that's our future, people. We all need to embrace it. Everything around you right now was built with some form of software. I'm saying, yes, let's continue to do it. Let's continue to make it so there are advanced notions. And for the developers out there, guess what: you're the ones getting to do this for people. You still have to go and program the low-code, no-code platforms. You still have to make the machine learning models. We're not there yet. We all don't have jet packs yet, but when we do, we'll be worried about the next thing, and Elon Musk will have already done it.

[00:31:03] So I'm going to tell you, I just want us to think about the ecosystem and create, as a place that really hopes that everybody is a developer, even though it shouldn't be sacred. The people that are super curious, get in there and start contributing to these projects. Go do some open source, go find a mentor, go learn how it works. If you are that into it, take the next step. There are a million resources at your hands. Go embrace that techie nerd part of you beyond the thing that you're building. So for me as a developer, I'm like, heck yeah, this is going to get more people interested in our careers. This is going to get those kids who didn't think they could be developers thinking, I wonder how this works. Because we're all tinkerers, every one of us.

Closing: code and no-code should coexist

[00:31:45] Guy: Nice. That's a very powerful statement. You're sounding like a superhero. I think what comes up from all this conversation is that we see no-code and code as a dichotomy, two opposing forces pitted against each other, and I think we're understanding that it doesn't have to be that way, and it shouldn't be that way. We also see that these two forces sometimes interact, sometimes overlap, and should even coexist. I think it's very interesting, and it raises a question for me that I want to leave with you guys watching as an open question.

[00:32:29] For you who are developers, what are our responsibilities in the no-code world? And for you who are no-coders, what are our responsibilities? How can we make this a synergetic process that involves all of the people together? And I think the biggest question is, if you imagine what the no-code world will be like in the future, thinking that it should coexist with the coders and no-coders, how do you imagine it? Where do you think it should go? You can comment or write to us. We'd love to see what you've been writing. So thank you, guys. I just wanted to finish up and say thank you for your participation and insights. I loved talking to you, and I'm really happy to hear all of the things you have to say. I'm going to bring it back to Rory. Thank you, guys.