“It's not going to be successful to say, no, this title can't do this. What you need to say is, this is the quality at which these different things need to be done. And as long as people can meet that quality, that's fine… I kind of think of this as design CI, the tooling that engineering had of continuous integration and automated tests. We need our version of that in design.”
Rosenfeld Review Podcast · User Experience · November 2026
Context
Asked whether blurring roles creates a need for more governance, David notes engineers have had tests and processes for decades that keep quality steady across contributors, and argues design now needs its own version as more people ship UI changes.
Transcript
…starting, and they're collaborating so close, they end up kind of doing little pieces of each other's thing and passing it on. And who's got time? And so I think that is kind of, it's almost the way you break down the work is the deeper seam than it is the titles, which certainly are blurring.
…think like there's an emergent push or maybe just an unmet need to have operations and governance more managed, more owned? Is that like another area that like it may not be product design? Engineering, or maybe it's product design engineering operations. There, we're good. We've got a new office.
Good. You heard it here first. The book book, too. Yeah, so I think maybe there's two ways to think about this, right? There's actually making sure that there are tools in place and operations in place that if everybody's working on stuff independently, that you're maintaining quality. And like engineers have had this for 25 years: different types of tests and tools and processes that allow different people to work on the same thing and generally maintain the same level of quality. And design and sometimes other places in the process, even necessarily product, didn't have that same need of formalizing their requirements and actually making them tests and these types of things because it was a small enough group and it was usually done before engineering was too far along so that they were able to kind of keep it within themselves. And you sort of said, well, engineers won't be doing this. And what we're seeing now is with the breakneck speed that things are going at, yeah, some engineers are going to be doing some like design stuff, you know, some of the design stuff, and some other people are going to do different things. And I think what's, it's not going…
Wow. I mean, you know, we're sort of moving from this world of design and execute to orchestrate and evaluate. And, you know, I don't know if that's going to settle. I don't think anyone knows the answer to that. But what we're going to do right now is settle on a quick break. Everyone, you're…
Well, so, you know, I initially had done, kind of tried to find a way to make this work with my team and stumbled a bit a few times how to kind of teach people to get to and get the right place and eventually got a model which I thought really worked with them. And that's where, you know, I went…
Well, I mean, you know, like, I mean, the book really gets into the nuts and bolts of, I guess you could just say vibe coding, but not really. I mean, like, it's more than that because you're really trying to unlock the language of engineering in a way that makes a designer a better partner. I…
More from Rosenfeld Review Podcast
