Hugh Dubberly is the founder of Dubberly Design Office, an interaction design studio based in San Francisco. Hugh has a long trajectory in the design world. Before opening his studio, he did pioneering work at leading tech companies like Apple and Netscape. He is also a thinker and teacher of uncommon depth and breadth. He’s my colleague at the California College of the Arts, and I’m also lucky to call him a friend and mentor. I met with Hugh in his office to discuss his recent paper arguing against framing design as problem-solving, and that is the focus of this conversation.

Show notes

Show notes include Amazon affiliate links. We get a small commission for purchases made through these links.

If you're enjoying the show, please rate or review us in Apple's podcast directory:

This episode's transcript was produced by an AI. If you notice any errors, please get in touch.


Jorge: Hugh, welcome to the show.

Hugh: Thanks Jorge. Great to be here.

Jorge: And when you say here, we are physically at the Dubberly Design Office office, which is a great privilege. I want to start by just acknowledging how much influence your work has had on my work. I consider it an incredible privilege to think of you as a friend, a mentor, and a colleague, and I want to thank you and thank you for giving me the opportunity to have this conversation.

Hugh: Well, likewise. It’s great to have a chance to talk with you always. And, this will be fun.

Jorge: Yeah. Some folks who are listening in might not be aware of your work. How do you introduce yourself and what you do?

About Hugh

Hugh: We have a software, services, and systems design consulting business. There are 10 of us. I used to say here in San Francisco, but now it’s pretty distributed. And we’ve begun to come back into the office for meetings with clients. But probably things are changed forever by working from home.

Jorge: Before we ever met, I remember coming across your work in the form primarily of models. And models here, I mean diagrams that make complex things clear somehow. I’m trying to be very broad, right? Is that kind of central to the focus of the work that you all do here?

Hugh: Yes. Of course, models are key to what we do. As I said, we’re interested in software, services, and systems. But by software, I mean UI and UX design. So, the design of the way we interact with computer systems is a central part of what we do. And we believe that it’s imperative in doing that work to build models at a different level than the interface. So, abstractions that help describe what the interface itself will actually be like.

In this we follow Austin Henderson and Jeff Johnson and terms of user conceptual models. But also looking at a much broader notion of systems modeling. Bill Verplank has his great video describing interaction as a kind of feedback loop. He asked these three questions: how do we feel? How do we know? How do we do? Which are really sort of the three points of sensing, comparing to a goal, and acting to get closer to the goal. That notion of feedback is central to systems in particular to cybernetics and to the study of how information and feedback flow through the world.

Jorge: It is a very kind of systems-centered framing for the practice. Is that a fair read on that?

Systems-centered design practice

Hugh: Yeah, I think that’s a fair read. There’s a sense that the nature of design practice has moved from a concern with artifacts — and especially the form of artifacts — to delivering products as services, to the services starting to take greater precedent over the product, the products becoming channels in a sense, to the place where value is really added as in software and in connecting a series of touchpoints. Michael Porter sums it up well in his notion of smart, connected products; it’s a great Harvard Business Review article about that. John Rheinfrank and Jodi Forlizzi have talked about product service ecologies, or we might add another adjective in front of it that sort of say “information, product, service ecologies.”

And so, all of these things are systems and they unfold over time and space. And often to think about how you might want to interact with them, it becomes important to create some shared representation. So you need to have a mental model and then a representation of the mental model, and then we can iterate on the representations to come to some agreement about how we’re all thinking about the system. And all this work is done with teams of people who, also, as you were saying at the top, are often very distributed these days. And so making those representations more visible and putting them in shared spaces, whether those are physical spaces or virtual spaces is an increasingly important part of the process and therefore important for designers to learn how to do. And then it becomes part of teaching and the class that you teach and that I teach at CCA focuses on this a great deal.

Jorge: What I’m hearing there is that these models are in service to making these complex systemic situations, let’s call it, more tangible so that people can have conversations about them. Is that fair?

Modeling for conversation

Hugh: Yes, I think that’s exactly right. If we were to get super theoretical about it, the systems are all constructed; they’re agreements that the observers have. And why that matters is that the whole process of developing systems, services, products, software, is necessarily a highly political process. Not political in some adversarial sense or left versus right sense, but political in the sense that it is about deciding what’s important, deciding what we value, deciding what we want to carry forward, but also just having some understanding of where we are and where we want to go. Designers can be super helpful to product teams by making representations of that stuff to help the team crystallize it more quickly and then help them iterate it more quickly.

I think one of the things designers bring is a willingness to go to the board and draw something with no fear of it being wrong. Like knowing, well, it’s going to be wrong the first time and the second time and the third time. But putting something on the board takes it out of the ether, makes it more concrete, and it invites the engineer to say, “well, that’s stupid! And that’s great! That’s progress!” It’s like, “well, tell me more! What’s stupid about it?” “Well, you forgot this layer or that layer, or it’s not connected this way.” “Oh, really? So, I hear you saying A connects to C and F and then…” “No! That’s not what I said.” “Okay. Well, what did you say?” And that iteration, which may begin sometimes even a little bit as a challenge, can over time really become quite collaborative as people work with the models and see that the models really are useful in the process. And we’ve seen folks go from like, “can’t we just get down to designing this?” to calling up and asking, “Hey, I have a meeting with management and I need some of those things you do.”

Jorge: Give me some of that model stuff, right?

Hugh: Literally, yeah. “Could we have some models for management meetings?”

Jorge: Right. One of the things that I’ve long admired about your approach to the practice is that you do this as a consultant, as you’ve been describing, but I almost see it as though you have this kind of this parallel related life around furthering the practice from an academic perspective in that you’re prolific in writing about these issues and speaking about them very thoughtfully and deeply. And one of the things that prompted this conversation we’re having is a chapter that came out in a book called After the Bauhaus, Before the Internet: A History of Graphic Design Pedagogy. I haven’t read the book, but I read the chapter because you shared it very graciously on your website. And the chapter is called, “Why We Should Stop Describing Design as Problem Solving.” And I was hoping we’d talk a little bit about that because, as the chapter makes clear, design has long been framed as being in service to solving problems. And you argue in this work that that might not be the most generative approach, if I might characterize it in that way. What’s wrong with framing design as problem-solving?

Design is not problem-solving

Hugh: Well, the short answer is that it suggests that the designer can quickly find a place of being finished, of having an answer — that there’s a right answer and that the designer could wash their hands and move on. And that’s a little bit problematic and we could get into why that is.

Jorge: Well, I would love to. What I’m hearing there, though, is that at least one of the challenges with this framing is that it might give the impression that because it is framed as a problem, whatever you’re trying to address, a problem implies a solution, right?

Hugh: Absolutely. So there’s lots of different ways to approach this, and this is one of the things that makes it challenging. Maybe just step back for a second. The book that you mentioned, this History of Graphic Design Pedagogy, is interesting because Geoff Kaplan, the editor, had put together a conference at Yale sponsored not by the design folks but by the art history folks. And so, there’s this idea of a kind of history of graphic design which suggests in some ways that maybe a particular type of graphic design might be over, might be finished, might be done. And we might start there with like, “well, what’s that about?”

So, in many ways, the graphic design department at Yale exemplifies and follows the history of graphic design in the United States. But it’s largely in service of an industrial revolution — industrial era — conception of design and graphic design. That is a focus on preparing things for manufacture — books, posters, magazines — and certainly, in the first two cases there’s a sense of a thing which is finished.

Now, it’s a little bit amusing because, in a lot of ways, what graphic designers make is ephemera: it’s stuff which is just going to go away. Or at least historical graphic design has been, in large part, about ephemera. Dan Friedman talked about this quite nicely. But with the rise of computers and networks and the information revolution, the idea of finishing something in many ways changes. And as you well know, and as we’ve talked about many times, a software product is constantly evolving.

And so, I think that’s a starting point, is that this idea that designers are no longer finished with the thing that they’re working on. And there’s almost an aphorism or even a law or certainly a belief in the lore of Silicon Valley that if you wait to ship a product until you feel like the software is finished, that’s a disaster. And that this idea of achieving product-market fit is all about interaction with customers over time, which necessarily assumes that the product is going to change. And so that the designer is very much involved in that kind of conversation with customers and other stakeholders.

Jorge: What’s interesting is that this is of a piece with the way that you were talking about the design process earlier, that it’s a dialogue…

Hugh: Yeah.

Jorge: …whereby you go from not knowing, and this kind of miasma… like when you were describing like being with the engineer at the whiteboard, I got the sense that the challenges that you’re trying to address have not been articulated in a clear enough way for the people who are involved in addressing them to come to grips with what it is that they’re dealing with.

Hugh: Yes.

Jorge: So you take these tentative steps, which serve as fodder for the next iteration.

The messy front end of design

Hugh: Yes. And that’s well said. Patrick Whitney — and others — has talked about the idea of the messy front end of design. You see this as in a sense, in the popular double diamond model of the design process. Often, designers and design firms talk about a discovery phase. You know, anybody taking a human centered approach is going to want to be talking to customers ahead of time.

So, there’s a distinction between having a defined goal and what kind of process one uses when one has a defined goal and a situation where one does not have a clearly-defined goal and the process one uses to try to get to an agreement about a goal. In the language of systems, you might describe those as first- and second-order processes, where a first-order process has this notion of a defined goal. The thermostat has the goal given to it, and much of design education acts in this way. A teacher sets a problem and the students make a poster for this or make a website for that or make an app for this.

It’s more difficult for both students and for teachers to set up situations in which the students have to figure out what the goal should be. That’s really challenging for students the first time they run into that. But that’s much more like what practice becomes a few years after you get out of school, maybe immediately for some people, maybe a few years later for some others, but eventually, designers find themselves having to have discussions with their coworkers, with their clients, about, “well, what are we trying to do here? Why are we doing that? How does that fit into this context? What is the context?” And you know, the context has so many different levels. So, “which level of the context do we have permission to address? And what happens if we don’t address these other levels of the context?” you know? “What are those consequences going to be?”

Jorge: Yeah, I remember reading — and I can’t recall the quote exactly — but I remember reading something by Brian Eno where he said that you can choose to work on the work or you can choose to work on the frame around the work, right?

Hugh: That’s nice.

Jorge: Yeah. And you say, in the chapter — and I’m going to read back to you a sentence here or part of a sentence — you say, “most issues facing the world and designers are not isolated, not static, and not clear. They are systemic, connected in networks of cause and effect, ever-changing, and largely defined by one’s point of view.” And what I’m hearing here is that we can talk about the practice of design, but specifically coming back to education, you were talking about the way that design education has been framed, has been focused on problems that can be taught; addressing issues that can be taught within the context of a classroom, where you come with the point of view already pre-selected somehow.

Hugh: Yes, very much so.

Jorge: And what I got from that sentence that I read was that we’re not in Kansas anymore. The sort of situations that we’re dealing with as designers, like you said, like the industrial revolution; the things that you were mass-producing were predictable. The kind of situations that we’re dealing with — if you want to talk about things like climate change, socioeconomic inequality — there’s all these big problems that keep people up at night, and those don’t seem to be of the same order as these other things that design has traditionally dealt with.

Wicked problems

Hugh: Yeah, I think that’s exactly right. There’s some good models for this. Horst Rittel, certainly a hero for me, with West Churchman described this idea of wicked problems. So Rittel contrast wicked problems with tame problems. A tame problem is one where we could agree on some formulation of the problem. And almost all of design education, certainly for undergraduates at least in their first seven semesters, is with tame problems. The teacher sets the problem and there’s not a whole lot of opportunity for reframing of the problem, although good teachers would welcome that.

What Rittel means by a wicked problem is a problem for which, among other things, but principally, there is not agreement on the frame of the problem or the definition of the problem. And furthermore, there are various aspects of the situation which make it unlikely that the stakeholders are going to reach consensus anytime soon.

Very good negotiators can somehow sometimes set up situations in which people can be brought to the table and there can be reframing. I’m thinking of Northern Ireland as as a situation, which was thought of as a wicked problem for a long time, and where there was a kind of breakthrough and a kind of reframing. But that took perhaps more than a generation to get to that. And we’ve seen some other problems like that have gone on for several generations. So it isn’t merely the application of time.

Peter Rowe in his 1987 book, Design Thinking, so before that became kind of a kind of catchphrase, Rowe describes three levels: simple problems, complex problems, and wicked problems. And his slight difference is that a simple problem is of course the same as Rittel’s tame problems: the definition is given and you just need to crank out the solution. A complex problem is one that you often face in business where everybody — the key stakeholders — are all more or less working together but they still haven’t really figured out what they’re trying to do. They have some general idea, but it’s not clear and not yet actionable. And there’s a fair amount of effort in this messy front end to reduce it to something where everybody could sign off and say that this is what we agree on.

I should add also, Ackoff has a different name for wicked problems. Ackoff, who was a business management professor at Penn, talks about ‘messes.’ He says that managers don’t face a problem so much as a series of connected, ever-changing problems which are kind of a mess. And this idea of having to deal with the business in a continuously changing world, brings us back to this idea of problem-solving. Do managers in a business have to solve problems? Well, sometimes, sure. But managing a business is not problem-solving per se. There’s not some problem which when solved, will guarantee the business.

You’ve heard me be before say this is the relation of parents to children, that a child is not a problem to be solved. A child may have a problem from time to time. But the parent’s relation to the child, the manager’s relation to the business, and I would say the designer’s relationship to the work, is to create conditions in which the business can thrive. To create conditions in which the child can thrive. To create conditions in which the product service ecology can thrive.

Jorge: One of the images that I got from this chapter is the notion that if the designer is not a problem-solver — and I do very much agree with the notion that the situations that we’re dealing with oftentimes, like you say, are more like rearing children than it is solving a problem — the chapter argues for reframing the role to something that I would describe as the steward of an ongoing dialogue about the boundaries of a solution space.

Hugh: Yeah, that’s very nicely put. I wish I’d written that in that way.

Jorge: Well, thank you for that. But this notion of a solution space I think is very interesting and I was, wondering if you could elaborate a bit on that.

Solution spaces

Hugh: Well, you’ve brought in two of my sort of favorite things here — favorite topics. This idea of an ongoing dialogue, a conversation, I think is central. And we might come back to, “well, what is conversation and how does that work?” And one of the things that I value in working with you is that you encourage generative conversations. You mentioned a conversation about a solution space that might be one of the things or one of the ways of organizing or scaffolding generative conversations is to think about, “well, what is the solution space?”

This idea of solution space, I believe enters design discourse through Herbert Simon’s, Sciences of the Artificial. Right there you can see this is sort of at the high watermark of framing of design as science. So you get Herbert Simon, Nobel Prize-winning economist, early pioneer in artificial intelligence, Carnegie Mellon, writing about all of the professions being engaged in the practice of design — so not just architects, not just designers, but managers, teachers, lawyers, doctors, and and so forth. And he gives this classic definition that design is changing existing conditions to preferred conditions.

It’s interesting that sort of the high priest of design as a science, doesn’t call it ‘problem-solving.’ And I don’t know how one could interpret a ‘preferred condition’ as being anything other than the product of a political discourse. It’s preferred by somebody. And this goes back to a critique that we should have perhaps brought into this earlier. If you call design ‘problem-solving,’ it still raises the central question: whose problem? Who gets to define the problem? Who gets to say that it’s been solved? And of course this is connected with much of contemporary discourse.

Jorge: Yeah, it seems highly relevant and I’m wondering, just to try to bring it back to practical takeaways for folks listening in. I often hear designers — I was going to use the word complaining, but that’s not the right framing — but just noting the fact that design does not have as much clout in making some of the more strategic decisions in organizations, right? So what can designers do to move beyond this framing of design as problem-solving toward a more systemic approach, this more generative approach?

Hugh: Well, you raised this idea of the solution space. Sometimes people call it the problem space; sometimes folks call it an opportunity space. The word ‘space’ is curious. I believe that there’s evidence from Simon that he meant it literally, as a kind of geometric space with dimensions. And that he saw any particular instance — a so-called solution — as a point in a multidimensional Cartesian space, where you could create an X/Y graph or an X/Y/Z graph or a four- or five-dimensional graph and say, well, alright, what are the dimensions of scissors, for example, to pick one not entirely at random — the length of the blade; is there a spring?; the material; the color.

Another example we use is to talk about shoes and sort of the famous department store in San Francisco, the west coast’s Nordstroms, which has this huge shoe department and there’s gender and size and color and type. And this gives you a sort of ontology or taxonomy in a database schema of which any particular pair of shoes is a point. But in designing a pair of shoes, there’s a kind of question: are you working within the existing solution space, in which case you’re making a variation on a type. What is the variation on that type? Or have you found some way to enlarge the solution space by introducing a new material or a new technology? Suppose we added a bladder to the tennis shoe and you could suddenly pump up the pressure in the tennis shoe. Well, that changes the solution space. Suppose you could weave things in 3-D; well, that changes the solution space of tennis shoes.

Jorge: Or a new business model. I’m thinking of Uber, what it did to transportation in cities.

Hugh: Well, so the same thing could be applied at all these different levels. It’s turtles all the way down. So, what’s the solution space for the form of this part of the artifact? For the solution space for the artifact itself? For the service that the artifact is embedded in? What’s the solution space for the business which the product service ecology is embedded? What’s the solution space for the industry that the company is embedded in? And so, all of these can be modeled. And I think that brings us back to: what are the practical things people can do? And going to the board or going to the Mural, Miro, Figma, zoomable information space and building a collection of models, can be very valuable.

Jorge: And the models, in this case, represent not just the components of the system, or the solution, or whatever it is that you’re making; they can also represent the boundaries of the space that you’re somehow exploring. Is that fair?

Evolving solution spaces

Hugh: I think that’s a great way of saying it. They enable you to see a kind of context of possibilities. So, what exists today? What are competitors doing? Are those things all clustered together? Do the main competitors seem to be competing along different dimensions? Are there gaps? Is the space old and has been well developed in their houses on every lot, or is this a new space and there’s many places for building houses?

To make that more concrete in business terms, when transistors were first invented and Gordon Moore talks about the the price performance growth curve, he also is describing a particular solution space that he could envision really this space that will be built out. And the teams that were building transistors — and Intel in particular — created this kind of new language, the new technology, which opens up this new space and made possible this whole new industry. I mean… and really a whole new world, right?

Jorge: What’s been on my mind hearing you describe this is… I’m going to again reference Brian Eno, but he wrote a paper called “Axis Thinking” — and I’m hoping that it’s online so that I can point to it — which talks about what he calls ‘cultural addresses,’ which are points at the intersection of axes that I think are very much what you’re describing here with solution spaces. And I’ll give you an example. He talks about there being a range of possible haircuts.

Hugh: Yes. That’s a solution space, of course.

Jorge: And he said that the punk movement in the 1970s opened up a new axis that went from on one extreme, ‘professionally cut’ and on the other extreme, ‘hacked about by a mindless cretin,’ I think is the phrase he uses. Before the punk movement, that axis just did not exist. Everyone expected to have a professionally-cut haircut. Right? I’m just saying this because it might point again to possible directions for designers to think about what new dimensions to open up in these solution spaces.

Hugh: Yes. When you went to haircuts, I was thinking even earlier to the 1950s or 1960s. You know, when I was growing up in the 1960s, there was a pretty prescribed haircut for kids. By the time I got to high school in the early seventies, my hair was much longer. Embarrassingly so, today. But then, later, as you’re talking about with the punk movement in the sort of late seventies, then things changed again.

Jorge: Which is to say that these solution spaces evolve over time, right? Like, they’re not fixed; somehow the boundaries move.

Expanding the possibilities

Hugh: We haven’t talked about this before, but I would love to bring in Raymond Loewy’s notion of MAYA: Most Advanced Yet Acceptable. And by that, I think he talks about a sort of window of possibilities and the edge of the window of the solution space. So, if you imagine some solution space of what is possible, then Loewy’s MAYA suggests a smaller aperture where some things that are possible technically or from a designed aesthetic point of view are just not acceptable to some part of the population. They might be acceptable to one population but not another population.

So, I’m making two sets of analogies. I’m making an analogy between Raymond Loewy’s notion of MAYA and Herbert Simon’s notion of the solution space, but then I want to make an analogy between Raymond Loewy’s notion of MAYA and the Overton Window, which is a notion in politics about what’s acceptable to talk about.

And I’ll give you an example. You know, before Bernie Sanders… well, at least for probably eighty or a hundred years, it wasn’t acceptable in the United States to say that you were a socialist and be a serious politician. And Bernie changed that, you know? So, he moved the Overton Window. But also, Donald Trump moved the window.

So in some ways, the window got expanded. And you might like one part of the expansion and not another part. But that idea that that window of what’s acceptable to talk about in politics is a kind of solution space, and I think connects back to these sort of larger ideas about what designers are doing. And so, part of what designers are doing is always trying to move that window a little bit.

Jorge: Well, I’m going to try to end the conversation on a meta note, which is that this chapter did that for me in my own understanding of what design is about. In calling out the long history of design as a discipline that has been framed as being in service to solving problems, in calling that out and questioning it, I think that you’re doing that: you’re shifting the boundaries of what we consider to be the remit of design somehow.

Hugh: Yeah. Well, you’re kind on several levels here. I think first of all, that you understood this and helped me come to a better understanding of it. I want to say that I went to school… my first design classes were at the University of Colorado’s School of Environmental Design, which had all these expats from Berkeley’s school of Environmental Design, which was named ‘Environmental Design’ coming from the folks at Ulm.

And so, this is a long history of kind of design methods, which eventually becomes design thinking or rebranded as design thinking today. But my very first design class was scientific — I underline that — Scientific Problem-solving Design. So, I’ve spent much of my career getting over this trauma from my youth. And it is part of my recovery to see a reframing of, well, you could consider ‘design’ as many things. You could consider design as art. You could consider design as play. You could consider design as science. You could consider design as politics. Maybe more interestingly or more fruitfully, designed as conversation.

And this idea then of how do you create really valuable conversations, generative conversations. I think that’s one of the ways to think about what designers are trying to do is create situations in which it’s possible for people to have generative conversations because that’s where real value is created in the economy.

And so, to borrow your phrase ‘meta,’ this is moving design from the design of artifacts to the design of systems. And when you’re designing systems, it really becomes a kind of meta-design, to borrow a term. That is the design of situations in which others can design. And that necessarily involves some kinds of conversations: designing situations in which others have conversations. In which people have conversations with other people, or designing situations in which people have conversations with machines or other systems. And there we get into the current trending topic of GPT and DALL-E and of that. And maybe that’s a topic for another time.

Jorge: And maybe the next conversation we’ll have will be like the one with the AI that simulates Werner Herzog and Žižek; we’ll record our voices and have the AI go at it. But no, that’s a wonderful place to close this conversation, Hugh. Thank you so much. Where can folks find out more about your work and follow up with you?


Hugh: We publish everything that we write on our website,

Jorge: So folks can look that up. And I’m going to include links to everything that we’ve talked about in the show notes as well.

Hugh: Great. Well, thank you Jorge. It’s been a real pleasure. Always great to talk with you.

Jorge: No, same here. Thank you.