On this episode, we talk with Hugh Dubberly, Principal of Dubberly Design Office, or DDO, in San Francisco, California. DDO focuses on making hardware, software, and services easier to use through their deep expertise in information and interaction design. Dubberly’s career has spanned many influential design leadership roles including Apple, Netscape, and Art Center College of Design. In our conversation, Hugh talks about the death of graphic design as we know it, gives thoughtful proposals for re-adapting designers’ skillsets, and the importance of understanding systems in the design practice of the 21st century.

---

Chad:

Hugh Dubberly, thank you for joining us on This is Design School today.

Hugh:

Glad to be here.

Chad:

Yeah, it’s been a joy.

Jp:

And it’s an honor. Thank you.

Hugh:

Thank you.

Chad:

One thing we wanted to start off with was what your path to finding design was and what your journey through that has been.

Hugh:

I started off studying architecture. I was at the University of Colorado for two years. Then, I went to RISD, I got an undergraduate degree in Graphic Design. And then, I went to Yale and I got a Master’s Degree in Graphic Design. But, my practice has always been in the computer industry. I worked for Xerox when I was a graduate student. And then, when I got out of school, I became the Design Director for Wang Laboratories, which was a fortune 100 Mini computer company. So, that was quite a long time ago. And then, I went out to work for Apple here in California just After Macintosh was launched. I was at Apple for about 10 years. I managed one of the three design groups at Apple—what is now the graphic design group there. And then, I went to work at Netscape, and I became Vice President of Design for Netscape. And, in about 2000, we started our own business with some Apple and Netscape alums.

Chad:

Which is the Dubberly Design Office.

Hugh:

Right.

Chad:

Which is where we are today.

Chad:

And, what does DDO focus on these days?

Hugh:

We design software and services. We’re particularly interested in integrated systems of hardware, software applications, network services, and human services.

Chad:

Yeah, so I’m curious. You know, graphic design, as a practice obviously, can wear a lot of hats or operate in a lot of different spaces. So, design operating in that context, I guess, what would Do you say are the key strengths or opportunities you bring to the table?

Hugh:

You’re raising a whole bunch of issues.

Chad & Jp:

(laugh)

Hugh:

So, I’m just gonna wander around here for a moment.

Chad:

Yeah, let’s start.

Listen on

Hugh:

A provocative place to start is perhaps to suggest that graphic design as we have known it is dead. Now, I don’t want to make anybody nervous or unhappy. So, I want to qualify that quickly.

I said, as we have known it.

So, a signal of this change is that, back in the day, when I was at Apple, there were half a dozen world class printers in California. Today, there’s maybe one. You know, you might argue that you actually have to go to Vancouver. So, that’s a signal of a big change. You know, we used to print at Apple and, even at Netscape, annual reports. One of the things we started doing at Netscape, almost immediately, was putting the report online. Now, annual reports are… that kind of lush printed annual report is a thing of the past.

Another signal is recently, this spring, there was a conference at Yale on the history of graphic design education. It was about graphic design from from the Bauhaus to the internet. And, it was kind of saying that, sort of, era has has come to a close and historians are starting to look at that now.

The good news, though, is when I was talking to Meredith Davis recently, who teaches at North Carolina State, or is an emeritus faculty there… And, Meredith was talking about looking at labor statistics, and the small number of jobs that will be available for traditional graphic designers, but the large number of jobs that will be available for some new kind of designer, where I’m not sure that the name has completely jelled yet for what this is. What’s ironic, I think, in what Meredith was sort of scratching her head about is, at the same time that people were saying, you know, “Well, graphic design jobs might be declining.” People involved in data science and data visualization were having trouble finding people to design data visualizations. And, you kind of go, “Well, wouldn’t that be a graphic designer?” And yet, it’s not clear to me that design schools have really changed what they’re doing to help students really have the background that they might need in, say, statistics, or machine learning, or even something as simple as Python or or, you know, the d3 libraries. And, I mean, there are exceptions of course to this, but schools tend to lag I think a little bit behind practice.

Jp:

Glacially. (laughs)

So, if design as we know it is dead

Hugh:

Well, or graphic design.

Jp:

Graphic design. So, if graphic design, as we know it, is dead what is it that we are doing right now? or what is the need for a designer, right now, to be doing?

Hugh:

I don’t think there’s one single answer. I think there are many answers. So, the truth is, we still need people with traditional graphic design skills to give shape to form, to give shape to content, to structure information. At the same time, we need people who can design software, who can design for interaction, who can design for service, who can design for the emerging world of platforms and product service ecologies. So, I’m making a distinction between really three, sort of, domains of design.

So, Jay Doblin has put forward a model which suggests, sort of, three scales of design. He talks about the design of artifacts, which could be products or communications. He talks about the design of what he calls unisystems, but, but really, systems, which are collections of objects that have some relation to each other. And then, he talks about multisystems or systems of systems. Joi Ito has talked about design moving from the design of objects to the design of systems, to the design of complex adaptive systems. John Maeda has talked about, kind of, classic design, design thinking, and computational design. Jackson has talked about first generation design, second generation design, third generation design. These all have, kind of, the same idea of an increasing scale of complexity. And, I think you could add on to that sort of another dimension.

When designers are dealing with sort of the classical, or first order, or product design, design of communication, that is traditional graphic design, they’re generally focused on the form. Education also focuses on the form of these objects. But, as soon as you get into practice, you start to see that the form has to have some relationship to meaning and structure. And, then as you have more experience, you see, “Oh. Well, that structure actually has some relation to context.” And so, you really get these three levels: context, structure, and form. Or, you know, to use the academic terms, you might say, the pragmatic, the semantic, and syntactic.

So, design moves in—has been moving—I think, in both directions from product to system, to system of systems, or product service ecology. And then, also from form to also structure, to also dealing with the context. So, it’s a change across both of these dimensions. And this necessitates, I think, a change in what designers do. It’s relatively easy for an individual designer to be, kind of, focused on the form of an object and to keep all of that in mind.

Jp:

Yeah.

Hugh:

But, when you’re looking at the context, and everything else for a product service ecology, then it’s not about individuals. It’s about teams. And, a bunch of things change. We have to be a lot more explicit about the process. We have to create artifacts which help align the team. We have to be concerned about facilitation. We move, perhaps, from solving problems to creating situations or conditions in which things can emerge.

Jp:

So, would you say that perhaps a designer in the 21st century is less of a creator, a maker, a physical maker, and more of a thinker, or more of a philosopher? Like, it feels as if we are doing more of the high level thinking that because we have always been involved in the systems of it, but now we can shed that light to a business, to an organization, or fill in the blank.

Hugh:

I think one of the things designers bring to the table is an ability to make things, a willingness to experiment. I often tell students they’re likely to find themselves, soon after graduation, in a meeting which will remind them of Groundhog Day, or at least the movie Groundhog Day, where we’re like, “Gee, I was in this meeting last week, and the week before, and the week before it.” You know, “We’re still talking about the same subject. Gosh, this is not fun.” What’s a young designer to do?

Well, one thing you might do is go to the board, you might say, “I hear you say something like this. Now, I’m probably not right. But, you know, is this what you’re talking about?” And, it probably won’t be right. The dirty little secret is there isn’t a right. The trick is to record something, and to then use that process of making to cause people to correct you—take it on yourself, or really themselves—so that you can iterate on this thing that you’ve just been yakking about for three weeks. And then, it has some tangible form that people could start to agree on, where you could start to converge on whatever it is that we’re talking about.

Chad:

You’re manifesting a conversation into some sort of artifact that can then…

Hugh:

…can circulate. It facilitates the conversation. It can be shared later. You can come back to it. You can compare an existing state with a prior state, or with a proposed future state. You can start to talk about a roadmap. You can start to talk about getting alignment, where people disagree, where they do agree, where we don’t have enough information. All of these things will help push the project forward.

Chad:

Yeah. Does that similar approach work at a higher scale of problem solving? So, for example, earlier, you were talking about going from artifacts to systems, and when we go up to that larger scale, does that process, does it work at that larger scale? And, does it maybe become even more important?

Hugh:

Absolutely. So, when you’re designing a physical artifact—whether that’s a product or a poster, book—part of the design process is to make prototypes. Traditionally, the process is to go from lower fidelity to higher fidelity, to increase the amount of detail in the prototype to make the prototype more and more like what you imagined the finished artifact will be. These prototypes are very tangible. They’re real things that you can can see and touch, and the thing that you’re going to manufacturer is a real thing that you can see and touch. When we move into the world of systems, and then further into the world of product service ecologies, or systems of systems, these things are less tangible. Systems can unfold over time, they can unfold over space. It’s very difficult to climb up to some hilltop and see the whole system. So, we need some kind of proxy for making approximations of the system. And, we have to rely, to some extent, on drawings for for doing this—on making representations. And, graphic designers can bring the skills that they have traditionally used to this new activity.

Chad:

Does that also manifest itself… So, from a from a systems level, mapping that out is one thing, but then isn’t another representation of that, similar to that concept, except more in real time, in terms of getting feedback, or…?

Hugh:

Well, so, there’s a couple of ideas we might want to distinguish here.

Chad:

Yeah.

Hugh:

One idea is just the process of beginning to design systems. Often in our practice, we encounter systems that already exist, but which were built in a very ad hoc fashion. And, sometimes when we’re brought in the, you know, we say “patient presents with some issue.” And, we have to go try to figure out what the problem is. And, one way to do that is to try to represent the existing system, to map that existing system. That might begin with interviews, it might begin with discussions with a product manager or with a product team, and at that point it might be scratches on a whiteboard. That might then become more formalized. If, as is true in many cases, there are many people involved in the system, many stakeholders, many people who own pieces of the system, as it were—if you interview them separately and then put it all together a likely event is that there will be arguments.

Chad:

(chuckles)

Hugh:

And, what will happen is you will surface that the team members do not have a common view of the system. They may not even have a common view of, like, the architecture of the system, how the pieces fit together. But, it’s almost certain that large parts of the details of how the system work will not be clear to individual team members.

Chad:

How do you facilitate the process of disagreeing in that, right? Because, in that situation where the system is somewhat of an intangible thing that you’re, kind of, trying to map out through, in some ways, secondhand accounts. How do you do that, and author that kind of view of the system without, in some ways, devaluing that the system could look different from different parts of being in the system. Does that make sense?

Hugh:

You’re absolutely right. The designer becomes part of the system. And so, there is a kind of subjectivity which is brought to it. And, it’s important to acknowledge that it may not be possible to have a, sort of, truly objective view of what the system is. It’s this compilation of points of view, or more precisely, it’s what the team agrees that it that the system is. Where the designer can be helpful, particularly as a facilitator, is by putting something on the table, or something on the wall, or in the shared folder, where we can all say, “Well, yeah, kind of. But, what about this?” And then, somebody else will say, “Well, that’s not the way I see it.” And then, the designer can kind of step back and let those two hash it out. Or, if one of them’s being, kind of, stepped on, can say, “Well, wait a minute.” You know. “I heard him say this, and I heard her say that,” and “Is that what you said?” And, I think that really becomes true facilitation.

Chad:

So then, once the system is mapped, that as, almost an artifact, or artifact representation of the system, how does that then help facilitate moving forward in probably another design process?

Jp:

Yeah.

Hugh:

Yeah, a couple of things. I think the… One of the values of creating maps of systems is that they enable conversation. They become what the sociologists call a boundary object. What Paul Kahn calls an alignment artifact, that can be used to mediate between people with different backgrounds. And, I believe that conversation is a key part of design, of the design process. And, it begins with, you know, traditionally designers have always had conversations with themselves, Shown talks about conversations with materials. The conversation continues when we want to think about what a preferred future state might be.

I think one thing I wanted to maybe follow up with was, there’s a complication that we should acknowledge to this mapping effort. The map is a snapshot at a point in time, the systems are very likely dynamic. And there becomes some effort to keep the map of the system up to date with the changes of the system, just as it often grows, sort of, organically, if you will.

Chad:

From my own experience, that’s always… Anytime I’ve tried to map a system like that, that process always becomes very onerous very quickly. Is there any way around that?

Hugh:

I think we will begin to see some ability of systems to map themselves or have software to be able to map systems. So, that’s one possible hope for this. You know, you could imagine at least better tools for designers for mapping systems.

Chad:

Yeah.

Jp:

Which is kind of an interesting way to perhaps conclude is the future. How do we see those systems in the future as part of the design system, as part of the overall system, as part of the design process that we teach in design education?

Hugh:

Yeah, there’s a lot to that question. You use the phrase design system. And, it’s a subject that’s very much on our minds these days.

We’re particularly interested in the history of design systems. I have a friend, Chuck Byrne, who says, “Oh, all that internet stuff, you know, that’s just like signage systems.” And he’s right in a way, the idea of design systems seems to grow out of somewhere. In the late 50s and early 60s, perhaps with the Milan subway signage system, the Schiphol Airport signage system by Benno Wissing, of course Massimo Vignelli’s work with with systems. I think, in a way, Massimo may be a kind of bridge from signage systems into corporate identity systems with his work with Unimark. Chermayeff & Geismar with the original Chase logo and that identity system, which led to other identity systems.

These identity systems are are forerunners. These signage systems and then identity systems are precursors to today’s software design systems. Things like Material Design at Google, and others. And, some of what’s changing there is that designers are learning to make reusable parts in the way that programmers have made reusable parts. So, we now have, not just collections of icons, but libraries of widgets, libraries have other kinds of elements that designers might use. You haven’t needed those as an individual designer, you can just go change something, until the point that, hey, you have an icon and it’s showing up on many different page and going and changing it individually on all those pages is really something of a pain. If you have it as a symbol, and you just change it once and that change propagates everywhere, that’s much better. If it’s in a library, and you have many designers working on something so that you can change it one place and then it changes in all of its instances, across all of these applications, that can be even more powerful.

So, that area, just of design systems, which is a really, I would say a very traditional area of design is still itself evolving. And, we’re seeing folks bringing very interesting, sort of, strategies—from using tools like GitHub, and using tools that would be used to manage the development of software libraries, bringing those tools to the management of design systems for software. And so, in that sense, the designer has taken on an even more sophisticated role as, not just a facilitator, but really building systems of governance to go along with the design system. Because, it doesn’t matter how beautiful the design system is if the programmers aren’t using it.

Jp:

What use is it then?

Hugh:

Yeah. What use is it, then?

Chad:

When you think about the idea of designing, having design systems, creating libraries of design elements, and stuff that can be used, but also updated and distributed at a larger scale. Then, when we think about the tools designers use today, and the way and method we design, you know, right now at least designers still go into a program like Sketch or Figma, or XD, or whatnot, and are still designing layouts following somewhat guided rules, but also still following individual instances where you need to solve interaction patterns or whatnot. But, as soon as you think about those things being resolved and brought into the system, then couldn’t essentially a designer be able to set the rules and tell the system how to design?

Hugh:

Absolutely. The technology already exists for that.

Chad:

Yeah.

Hugh:

The issues are much more social issues, which is a little bit why I was bringing up the governance kinds of things. I’m sure you’re familiar with the now infamous story of Doug Bowman, leaving Google when Marissa Mayer mandated that he test 42 different shades of blue. I think that actually set design back quite a ways. A couple of years after that happened, I spoke with Irene Au who was the head of design at Google and Irene said, “You know, well, that was kind of an unfortunate event. Certainly unfortunate to lose, Doug, and unfortunately there was this conflict. But, Marissa had a point that it turned out that the color of blue used could result in in millions of dollars one way or another for the company.” It’s just, what was it work here is just the enormous scale of an application like Google search. What I think designers need to get comfortable with is a world in which lots of variations are going to be tested. And, one of the things that you’re implying that kind of comes out of that is, you know, it doesn’t make sense for Doug or anybody else to be sitting there figuring out what to be tested.

In a way I agree with Doug. It’s like, “Well, Marissa, is the blue the most important thing that we could possibly be testing here? Probably not!” You know. Even though the blue might be worth millions of dollars, I mean, I bet there are other things that are worth even more than that. And there are all these combinations, you know. And so, for Doug or any other designer to sit there and figure out what the combinations are, it’s just a waste of time, particularly when you could have a computer do it. And so, I think the economics are gonna drive that computers… that designers will set up computers to generate these variations do the testing, see what works best. And then, even more sophisticated programs can actually evolve the design using, for example, genetic algorithms or cellular automata, to find kinds of solutions that designers might not even have thought of. And, that might be frightening and suggest designers are going to be replaced. But, I think designers actually will be at a level above that where the interesting work will be setting up these systems in which what we traditionally would have thought of as design, is actually being done by machines, or by other humans, or both.

Jp:

I think we’re going to see design education be an important… having to take an important role in preparing students for those for these things, as opposed to just preparing for the production. It’s preparing for the concepts, preparing for the facilitation, and preparing for those levels. Like you said, we’re going to have to live in the level above that is programming. And, I’m not sure if design education is there right now. And, this is that wake up call. This is that the call to action right here, which we’ve captured.

Chad:

But, I think it also comes back to, you know… As sometimes design programs can sometimes be a little bit behind. I think one thing that they do really well is prioritize that thinking is one of the most important skills, and critical thinking, more so than learning particular softwares that will continually change overnight. (chuckles)

Jp:

We’ve kind of started to see that. I don’t know if you have seen that like Yale or other institutions that learning which version of Illustrator and Photoshop and InDesign are not as important now as learning, here’s the way to learn a piece of software. Go do it. Now, let’s talk about where that fits into the scheme of things. I think that’s where we’re starting to rise to, but we are definitely needing to get higher, quicker. And I’m not sure if we’re ready for that. But, we need to be.

Hugh:

Yeah, absolutely. One of the things that seems to have to have happened is that design education has been asked to take on more and more without necessarily being allowed to drop anything. And my observation is that much of the practice of design education is literally medieval, that it has a kind of master apprentice, sort of, methodology.

When I was a student, I got in trouble for arguing with Armin Hofmann, he took me out to the type shop and pointed a finger at me, and lectured me. “Hugh, don’t argue with Armin, ya!” And, I just found that, and still find that, so odd. So, we were in the United States at a university in graduate school, and the professor’s expectation was that the students wouldn’t ask questions. And, you know, a little bit comes from the sort of context of the Allgemeine Gewerbeschule in Basel, which was, it came out of a, kind of, trade school, apprentice-master view of the world.

I think we no longer have time for that way of teaching things, where you learn by example and the the education is implicit, the knowledge transfer is implicit. I think we have to become much more explicit about the knowledge transfer. And, this raises some very difficult questions like what is knowledge and design? As we go into the future, what are the things that students will need to know? You know, if you have a student today, that student could be practicing for 50 years! What kinds of things can you teach them that will be valuable in 50 years? You know, how to do a filter in Photoshop? I don’t know?!

So, to be more specific about this, if you think about the way that typography is taught, going back to to Emil Ruder, was sort of moving text around at different sizes, and maybe translating that now to do that on the computer screen. That’s taught in a, in a way that’s very, it takes a long time to learn all the little rules. And, even then, it isn’t really taught as a kind of coherent, coherent idea. And, one of the reasons that you teach that way is that you want students to make things and that there really is learning in the making. So, I want to be careful, there’s value in the making, but we could do with a whole lot more principles and ideas from cognitive science about pop out effects and ideas about how you build structure of information on a page using Gestalt principles. You know, we could talk about that in a lot more coherent way and I think compress much of the, you know, teaching of typography which many graphic designers think takes, you know, like three years. There might be a way to make that take a lot less time. And then, we could open up some other curriculum.

Jp:

You are right in the mindset of what I’m struggling with as I come back from sabbatical. What is it that can be filtered out and somehow modularized, and then raise up higher, the thought process of being a designer and preparing them for a career in 30 years, that they’re not obsolete, that they are adaptable. And, I think adaptability is something that is very much in the forefront of my mind right now.

Hugh:

One of my favorite books is titled Learning How to Learn by Gowin and Novak. And, I think that just the title alone is kind of wonderful. To maybe talk about it for for just a minute. If you’re interested in the typography side of it… I found it baffling, when I was a student, to hear these different rules, you should hang your quotes. You need to letter space caps. I’d see then, people in the advertising world who would jam all of the caps very close together. It’s like, well, you know, there’s this sort of fight between the way graphic designers do typographic and the way advertising people, or the way book typographers do typography, in the way advertising people do typography… And, how do you resolve that? Or, you know, is one of them stupid? Or are they both right? What do you make of all these little rules?

I believe that typography can actually be simplified a great deal. Carl Dair gets at this idea with what he calls contrast, which is not a fancy idea at all. It’s big versus small, near versus far, roman versus italic, bold versus regular. And, I believe contrast is the single operation at the heart of typography. And, that contrast has, sort of, two sides like a coin, one side is to separate and at the same time that you’re separating, you’re joining. And, in this, you create groups. So, the separation of one group from another and the joining of a group of the elements of a group together. And, in that operation, then there’s a sort of iteration that happens. And, if you have a field, a page, which has typography on it, there are these moments of contrast which happen, which the reader perceives, and the reader can develop a hierarchy, a visual hierarchy that is implied in the contrast that the typographer has laid out the page. And, the measure of the fitness of the typography is literally the fitness of that tree, the perceived tree, with some implied tree in the content itself. And, that you can measure or see this contrast, you can compare these two trees.

Jp:

Yeah, the relationships that are happening with the contrast and the lack thereof.

Hugh:

Yeah.

Jp:

Yeah, very fascinating.

So Hugh, as we are concluding here, we usually like to end by asking for a couple of recommendations that we can take with us. And, my first recommendation is, what would you recommend, since we’re here in San Francisco, something culturally interesting or significant to you, especially being here for a while now, that you would recommend that we go see?

Hugh:

One of the things that’s nearby that’s a little bit new in the design world is something called the Letterform Archive.

Jp:

Oh!

Hugh:

And, that’s worth a look.

Jp:

Okay. Yeah, thank you.

Chad:

And, I always selfishly ask for a reading or an article that you’ve read recently that you felt made an impact for you that maybe hasn’t gotten enough read by everyone else yet, or you feel could make a broader impact.

Hugh:

Yeah, I’d love to recommend a book called Design by Concept: A New Way to Think About Software by Daniel Jackson. He teaches at MIT. The book asks the question, when we design software, what is it that we’re designing? Or, perhaps more specifically, when we talk about a product, what’s the core of a product? And, he gets into the idea of a product concept. And then, he gives some very interesting examples of what concepts are in products. And, I think this is aN extremely important question and he’s making contribution to an area of design that hasn’t been studied very much. Austin Henderson and Jeff Johnson have a related book, an earlier book, called User Conceptual Models: Core to Good Design. It’s interesting to see the difference between what Johnson and Henderson are doing and what Jackson’s doing.

So it’s a good book.

Chad:

Thank you.

Jp:

Well, we thank you so much for your time. It was Thank you pleasure and…

Hugh:

Glad to do it.

Jp:

…thank you very much.

Chad:

Thank you, Hugh.