The Bitter Layout or: How I Learned to Love the Model Picker — Maximillian Piras, Yutori

Bitter Layout, or the alternative name for this talk: how I learned to love the model picker, and hopefully you will too. So the idea for this talk started when I was perusing all the AI-first apps I use all the time and just realizing how similar they're all starting to look.

Very consistent layout between them all, and it's not just the chatbots and the answer engines; it's also the creative tools, like coding assistants like V0 and even Canva. They're all starting to use this very similar layout. They've got an input field, they've got this turn-by-turn UX, they've got this dropdown with just way too many models to pick from, and it all feels like they're kind of retrofitting stuff into this chatbot UX.

But don't worry, this talk is not about if chat is the future or not. I think we've all heard that enough times, at least I have, and Swix did a good job of humbling all designers with this tweet where he basically called all the design thought leaders out who are saying chat is dead and then—or sorry, chat's not the future—and then they show off their cool demo and then shortly after, "We'll just go back to using ChatGPT."

So, fair point. I think thatright now we're in this state of a bit of a dualistic future of AI UX, so I've called this first section "Schrodinger's chat," because we all, you know, all designers know how many usability issues that chatbots have, but yet we all still use them every day.

So it's kind of like, obviously they are the future, but at the same time, obviously they shouldn't be. So I won't go into my thoughts on if they should be, but I'll do some anthropology here of just getting everybody up to speed in case you're not familiar with the great chatbot debate.

I'm not sure if people realize how long we've been debating this, but I can track it all the way back to 2022 with this post from Linus Lee, which—this is a great post, by the way—still holds up today, but he essentially says he doesn't think that exposing the raw text completion is really theright paradigm long term.

And so, you know, note the date: May 2022, because a couple months after that we have ChatGPT essentially saying, "Hold my beer." And, you know, if that's not theright UI paradigm, it certainly didn't bother them. And I think a lot of other designers have kind of taken note of the escape velocity of that.

But still, the next year, May 2023, we saw some other great posts from people like Amelia Wadenberger, and then the next month, Maggie Appleton, who are making great arguments about why chat's not the future. These, I think, hold up pretty well, but at the same time, yeah, obviously you have other designers who are arguing how intuitive it is, and then as we progress and ChatGPT hits escape velocity, we're kind of seeing everybody just start to meme the defense of chat, which is like, "Just look at the chart," you know?

It's like, obviously it's working,right? And I think there's something interesting about that. If you can kind of come to the debate with a meme, it means there's something a bit intuitive about your argument, so fair enough. But then still, even in March of this year, we've had people like Julian Lear writing very good reasons of why chat should not be the future, and he's, like, showing clock speed here relative to the different interface paradigms, so it's very convincing.

He pretty much says it's a bottleneck, but at the same time, you know, we'll all probably still go back to using chat after this, so the Schrodinger's chat remains. And so I'll segue into the next section here, which is called "Models and Modes," and this is on this idea of the model picker, which is this other UI paradigm that's been developing alongside chatbots' popularity.

It's that, you know, I'm sure everybody knows what it is, but to be clear, it's this dropdown where you just have to select from a million different models. And so I put this—I made this section in memory of Larry Tesler, if you're not familiar with him.

He's kind of a big deal, invented like copy and paste and stuff, but another thing he was famous for was apparently saying, "Don't mode me in." I don't actually believe he would say this, but I mean, the quote is, like, attributed to him, but, you know, he hated modes.

And if you're not familiar with modes, this is a setting in a UI where once you flip it, all of a sudden your inputs are mapping to drastically different outputs. And so Larry Tesler hated this, he thought it was unintuitive, and he wanted everything to be modeless.

And I don't know how many—or sorry, to give an example of a mode, just to be clear: Caps Lock. This is a mode,right? You hit Caps Lock and now your keyboard performs differently. And then a more recent mode—excuse me—I'm not sure how many people would agree with me on this, but I think that the model picker—sorry, this is my voice hitting like the worst time—I think that the model picker is a bit of a mode selector as well.

You know, it's—obviously we're dealing with stochastic output and generative AI applications, so everything is—it's kind of not a distinct change in setting, but once you flip a different model, you have a whole step change of output. So to me, that's kind of like a mode selector, and here's a quick video to illustrate this point.

This is a bit old, it's the an older version of ChatGPT, but you can see I'm trying to use certain modes and the model is not supporting it, so I have to go through this menu and find which model allows me to use this mode.

And so the argument here is, like, we're kind of putting modes on top of modes,right? You now have to match models to modes, and it's not super intuitive. They've actually done a great job of redesigning this lately, so this is certainly not, like, throwing shade at OpenAI.

I think they have a great design team, but I'm just trying to illustrate a moment in time when this was super frustrating to me. And, like, you kind of just want to talk to the model and be like, "Here's my use case, like, what mode and what model should I use?"

But I don't know, maybe the model will pick itself and so that won't work. So this is really illustrating the point of the flexibility/usability trade-off. This is a design principle where pretty much you're constantly trying to decide, like, how well do you understand user needs, and if you can pretty much pinpoint them down, then you can create a very, very usable, optimized UX for them.

But as you try to make a more flexible system, the usability tends to decrease because you're just increasing the amount of edge cases and the complexity and the requirements. And I think that this is a trade-off that doesn't get talked enough about in this "Is chat the future?"

debate. You know, we generally talk about it in terms of absolutes, but it's really less of a yes and a no, and more of, like, a time frame and, like, what trade-offs are we talking about. And so I'd like to segue into this next section, which is going to push the idea of, like, when we design interfaces, we really need to consider the zeitgeist that we're working in.

So what are the trade-offs of the time, you know, what constraints we're working with, what time frame could an interface be good for. The subtitle of this one is called "The Context of All In Which We Live and All That Came Before Us," Easter egg for anybody who remembers that.

And so to get into this section, I'd like to lean into a theory from "The Innovator's Solution." This is the follow-up to "The Innovator's Dilemma," and in this book they try to give you some guidelines on theory of how to approach building products with this idea of product architecture.

So the architecture is generally this idea that you have a system and you're trying to figure out how the components in the system are interacting with each other or interfacing with them. And so when you start to understand how they interact with each other, you can see different attributes, so they map them out to these two distinct sides of a spectrum.

You've got integrated architectures, and then you've got modular architectures. And, you know, generally integrated, this is more common in early-stage disruption, and you have proprietary technologies, they're very optimized, interdependent, it allows vertical scaling. And then to contrast that, you have modular, and this is generally when technologies start to commoditize and they can be more interdependent and you can allow horizontal scaling.

But the key point in their theory is that, you know, you're never really on one side of the spectrum or the other. You're instead kind of bouncing between the two, and the industry as well is having different parts of the tech stack commoditize and de-commoditize all at once.

So as a designer or anybody else building, you pretty much have to figure out where are the strategic points to be integrated versus modular. And so their theory uses, like, IBM as an example, when they started out making mainframe computers very integrated, then they shifted to personal computers and started to make it more modular, and then, of course, ended up the whole computer itself ended up commoditizing at some point and they got out of that business.

So thinking through today what parts of the AI industry are commoditizing and de-commoditizing can help us think about how to design interfaces. And so, of course, if the main question probably everybody would ask in this when you start to pose this prompt is, "Are the models themselves commoditizing?"

Right? Because this is kind of like the big topic that everybody debates. And it brings us to "The Bitter Lesson" from Rich Sudden. If you haven't read this, I definitely recommend doing so if it's not wise to build an AI today without knowing this lesson.

But I'll take the TL;DR for this talk is that you just we shouldn't assume that computation is constant as long as we're seeing scaling laws in effect,right? Like, as long as the next model is still important, which you can see it still is, like, every time a new model comes out, everybody's like, "Drop everything and let's check out the new model."

As long as the scaling laws are still in effect, then we can assume that the models themselves are not commoditized. And so "The Bitter Lesson" actually leads us to what I'll call the bitter design lesson, why not, which is this idea that if the basis of competition is inference performance, then the UI itself must be primarily focused on conforming to the next model.

So said plainly, if the model is not commoditized, it's actually the interface that's the commodity now. And until that changes, when, like, models overshoot user needs and you don't need a rocket scientist doing whatever use case you're doing on in ChatGPT, then we can start to explore different integrations within the interface.

But until then, the primary job of every interface is really has to be figuring out how to conform to the next model's capabilities. So it's kind of a bitter design lesson because then you get layouts like this, which, you know, "The Bitter Layout," pretty uninspiring, not super usable, just not very cool at all, but the one thing this does really well is it can absorb the next model's capabilities.

So as soon as that next model comes out, jam it into "The Bitter Layout" and then, you know, update your model picker and your app is more intelligent. So, you know, I hate this design, but, like, as a designer, like, you can't really hate on this ROI, which is you just add one line item and now your app is NX more intelligent.

So kind of hard to debate this as a design decision. So that's "The Bitter Design Lesson." And the takeaway from this, I think, is, you know, I'm not ready to eat my words on saying chat is not the future yet, but I think that it's quite clear that this one attribute of chat, which is that it can really conform to the next model very easily, is one of the key features we need to keep in mind.

And so the future of AI-UX until we see models stop commoditizing—or, excuse me, until models do commoditize—will be that the future of AI-UX must conform to the next model. So that's "The Bitter Design Lesson," but how do we go from bitter to sweet,right?

What comes next? And as most things in life, Brett Victor has already given a really good talk on this, so you should just watch this talk. It's much better than this one. But it's called "The Future of Programming," and he explains all of the kind of mistakes we've made over the past decades with thinking about programming, and specifically uses this—or for this context, he uses this example of how people found it very hard to go from binary to soap,right?

The binary programmers could not understand how you could give up control to the machine and use these abstraction layers efficiently, and they liked to hand-code everything. And, of course, like, making this mind shift was really important, as we can see in retrospect.

And so his lesson was, you should stop thinking in terms of procedures and start trying to think of programming in terms of goals and constraints, and pretty much guiding programs with these higher layers of abstraction. And so designers, I think, are actually pretty well suited to do this.

You know, it'll be a mindset shift to jump from thinking procedurally to goals and constraints. You know, we like to be very detailed in how we design user flows and consider all the edge cases and all that, and it's very important, but we are likely going to have to start to move up a layer of abstraction as we're seeing apps become more and more stochastic and dynamic and just more probabilistic.

So we can't really envision every possible path now, so we have to think a bit more in terms of what constraints can we set and what goals can we set to get people to the along the happy path.

And so, you know, design systems, these are already things we use to guide developers and other designers to goals and set constraints for them. So what happens when we start using this for generative UI,right? If we start to collaborate with a model, do we have a design system that keeps them within theright constraints?

Quality assurance, is that like reinforcement learning? I'm not really sure, but, like, maybe it is when you go to, like, critique a design that a model has created. Will this be, like, a reinforcement learning loop? User stories, these are, you know, we're very good as designers at thinking about how to envision what the user is trying to do via user stories.

And these are kind of like system prompts in a way, like, can the model become also a partner in helping set the goal for a user? And we can translate some of these user stories into the system prompts themselves.

So this is pretty speculative, but I think this is a nice prompt for the future of UI design in the AI age. And I'd like to end on this quote from Dario Amodai, who says he feels that generative AI systems are more grown than they are built.

And I like this as a prompt for inspiration for helping us do this shift mindsets and start to think about how the future of UX might be more one where we're it's less like a process of construction and perhaps more like a process of gardening.

So if we can embrace these types of lessons and start to think about design in a new way, a little at a higher level, perhaps then we can move beyond "The Bitter Layout." Thanks a lot.