Architecture and #DesignInTech
Designer Dim Sum conversation led by Angel Steger and Gordon Chong
An online seminar led by designer and tech entrepreneur, Angel Steger, and former national president of the American Institute of Architects (AIA) and architect, Gordon Chong, led to a variety of viewpoints being shared in the Designer Dim Sum Network Seminar organized by Jackie Xu with John Maeda.
Angel Steger AS/ One of the challenges with tech is that it is still such a young field; many of the founding members of the tech community are still active participants. How do you teach digital or physical (or both with IoT) product design when you have such a short history to pull from? What are its design ancestors? While many of our research and development practices pull from industrial design, but what about architecture?
Gordon Chong GC/I’m thrilled to see an increasing number of architecturally trained individuals, like Angel, involved in “non traditional” professions! An educational psychologist once described how designers/architects think as being “whole-to-part-to-part to-whole.” She indicated that this was distinctly differentiated from most who problem solve by thinking “part-to-part-to-part-will-result-in-the-whole.” In our current environment favoring innovation, I think design education has provided the required balance between intuition and empirical thinking processes.
ARCHITECTURE AND PRODUCT DESIGN
AS/ To me, a well-designed product, like a well-designed building, empowers people to do what they want and need to do and emotionally enhances the experience. While the light and the walls matter in a building, you don’t stare at the walls — you do your thing, whatever that is, ideally enjoyably, quickly, and freely. The walls assist. Products and apps are similarly approached; people use them because they empower them to accomplish their goals, not because they want to engage with an interface.
Design serves to facilitate and amplify the user’s desires and in 1:many products, you’re also orchestrating group dynamics. Particularly with regards to social, could learnings from architecture be a powerful tool to approach how your product functions on multiple levels? Have any of you applied lessons or methodologies from architecture
David Nguyen DN/ I’m personally not well-versed in architecture, but the analogy above really resonates with me: A building serves its occupants and there are a lot of components (such as walls) that are oftentimes overlooked by the occupants, but to the experts how they are placed, designed, and built — they are essential.
DN/ I’d like to know (1) What are a few architectural details that you actively look for when evaluating whether a building is “well-designed”? (2) What are some well-designed buildings that inspire you?
AS/ In answer to your first question about evaluating what makes a building well-designed, the annoying answer is “everything”. I’ve heard it said that “God is in the details”, and that is also true. Generally, there’s a feeling of the makers (really multiple, though we tend to refer to the architect as singular) presence, particularly at a small scale. But a more structured approach might be like this:
- At the site level: A building in its landscape/cityscape is like a person amongst other people. How do they behave? How do they acknowledge others? Do they contribute to something meaningful? What’s their impact on the street experience, how do they manage movement patterns around/in/out? How does their presence change or support the reading of the city on the whole? To me, a really interesting project type that keeps cropping up (first in Paris and New York, now seen in many other cities) are the High Lines, where the project will take an existing piece of defunct rail infrastructure that had previously been a kind of unowned, wild space and integrated it as a shared public space — literally flipping it from something that divided parts of the city to something that stitches the urban fabric back together. DN/ This got really deep, really fast! The interconnectedness of each design element with its surroundings and “repurposing” something that existed for one function and flipping its purpose (aka The High Line in NYC) highlights the fact that you appreciate the “intent” behind the architect’s vision.
- On the program level: for the people who use the building, does it take into consideration their needs? Can it show them the way to do what they need to do? Can it celebrate moments for them? And what does it do socially? Robin Evans wrote a really interesting piece in the late 70s about the evolution of the corridor and how it got popularized by Puritans to avoid unnecessary (and potentially immoral) contact with others, when much architecture prior had people moving through a series of rooms to get to other rooms (which led to a lot of surprise social interactions).
- On the body level: does it fit us, does it fit me? The Exeter library by Louis Kahn is a really interesting example of creating fit with the study niches. I really appreciate buildings that are made to the scale of the body. DN/ This point focuses around how the architect’s vision “fits” the end user (aka Human-focused design). Essentially embracing the constraints of the human body when thinking of the design — I really want to read a book in the study niches.
- Aesthetics and materials — does it feel thought out, can you see/feel the system at work, or are there random details that seem all wrong? (The New Museum in NYC is an example of not thinking things through.) Humidity, sound, light, texture. How do those make you feel?
- Is it flexible enough to sustain change over time?
- The rigor of attention to detail. Carlo Scarpa’s Brion Cemetary is an amazing meditation on transition from life to death. There’s a bunch of things you can only experience by going there, because they happen in your participation with it, or when you watch the caretaker activate them. DN/ “Rigor of attention to detail” — I believe that this goes to your initial point of how “everything” matters. And only when the project is finished will people truly be able to take in the whole experience.
- Anticipation. I like the quote from the movie Gosford Park. “What makes a perfect servant? Anticipation. I know they’re hungry before they’re hungry…” Like the perfect assistant, knowing how to show up and how to disappear. DN/ “Anticipation” — I love, love that quote. I share your belief that great design anticipates every need. An example that I always think about are the door handles to a Tesla: normally, they are flush against the rest of the door, but when you approach, they extend out anticipating your desire to easily open the door and enter the car.
THE POWER OF AMBIGUITY
AS/ When my friends in Industrial Design were learning to draw, they were being taught how to render highlights, midtones, shadows, reflections in markers. With Architecture, we asked what a drawing was.
AS/ Rather than be taught drawing in a “this is how it works” kind of way, we were given an open-ended task, something like “Make a conical intersection with a rectangular void”. And then as students, we would try out how to do it, on our own and comparing notes with our studio mates. We learned orthographic drawing by discovering it, not by being told how it works. Then as we moved into using drawing as part of a larger project, the question became about how you can define something, first for yourself — and then ultimately, for others.
Emily Schwartzman ES/ This thought resonates with me in particular: “…how you can define something, first for yourself — and then ultimately, for others.”
ES/ I’ve found that a mixture of head’s down time and collaborative discussion helps me work through ambiguity. Head’s down time allows me to internalize and make sense of the problem in my own way. This can be a mix of looking out in the world for relevant information, inspiration and reference materials, and looking in to make sense of that gathered content through models, notes and sketches.
ES/ Sharing and communicating my understanding with my teammates or clients is when things really start to click. Hearing and building on their perspectives and ideas starts to create a shared understanding of a problem or solution, which minimizes ambiguity and makes things more concrete.
ES/ I’ve found there is a bit of a hurdle in the beginning of a project, when things are often undefined and the initial ideas come in the form of abstract concepts or individual features or functionality without a bigger framework or system. It’s an exciting moment when those pieces start fitting together into something concrete that others can respond to, whether that is a sketch, a scenario, a wireframe, a service blueprint, a prototype…
Matthew Beebe MB/ Tolerance of and the ability to work through ambiguity is something I definitely think I learned by studying design. I think of two types of ambiguity in design:
- It’s unclear what we should make (what exactly is the problem we are trying to solve?)
- It’s unclear how to solve this problem (will this thing work?)
MB/ Studying graphic design at the University of Cincinnati I learned to work tolerate/work through the “how should we make something” type of ambiguity. We were given a fairly narrowly defined problem (draw a symbol of an animal) and the professor (drill sergeant?) marched the class through a series of iterations on the solution until we called it “done”.
MB/ In grad school at the Institute of Design in Chicago I learned how to deal with the “it’s unclear what we should make” type of ambiguity. Which basically is the discipline/tools/methods to focus first on defining the problem to be solved.
MB/ I see the design process as bouncing back and forth between defining a problem and trying a solution. Each side of the equation informs the other. Eventually you eliminate enough ambiguity and you know you have a good solution to the right problem. Sure takes a long time sometimes. Which one of my favorite Christopher Alexander takeaway : that the way igloos were/are designed (very slowly, over many generations) is the best way to design stuff.
GC/ A little personal story: My father was trained at the California Art Institute and made a living as an artist. As a kid, whenever I tried to draw a horse or cow, he would “help” me by changing my drawing to make it better. After a while I quit competing with him and no longer wanted to be an artist so I turned to architecture! Point being, I think there is something magical, even as a kid, about discovery necessitated by ambiguity (how do you draw a cow, how do you make it proportional, where does your line start etc) ; having my Dad help me draw a “better” horse” wasn’t discovery.
GC/ As an older generation architect, I place high value on hand drawing skills in addition to computer generated drawing or modeling. For me, drawing is discovery. You have to look carefully to understand it before you can draw it. We use different line weights, shading, white space, outlines etc to express ourselves. A drawing is a language comparable to writing. By looking and thinking carefully before striking a line , you gather information that informs your drawing, or design (in the case of an architect). I’m sure you’ve heard older architects lament the fact that younger architects do perfect computer drawings and models but that they don’t understand how it goes together because the computer does that drawing rather than the individual. In some ways, the computer takes the ambiguity out of the drawing because it is “correct” but it may not remove the designer’s ambiguity because it is not thoroughly understood.
ARCHITECTURE AND PERMANENCE
John Maeda JM/ I’ll never forget when I spoke to Princeton’s Dean (or equivalent) of Architecture in the late 90s. He was slightly complaining about how his studios had just moved over to Windows NT to keep up, so I asked if the speed of change in computing bothered him. He said in this wonderfully dismissive tone to me, “You digital people think in months. We architects think in decades.” He was referencing how buildings take a much longer time to plan and build, and often stand for many years. Whereas websites kept popping up and needed to change so often. I was jealous of his ability to get to work in such a permanent medium.
Anand Sharma AS/: I’ve been thinking about that a lot lately. It’s tricky to aim for perfection when designing something that you know is going to be gone in a year or be totally rebuilt pretty soon. Like 90% of the stuff I’ve done no longer exists and it is kind of sad, but also somewhat liberating. I imagine most of it actually wasn’t that great or at least quickly became obsolete and old by today’s standards. Interesting to think that there are other industries where that isn’t the norm, though architecture is the only one I can think of right now that persists across such timescales. Who else thinks across decades? Maybe teaching? Or law?
Diogenes Brito DB/ One interesting thought experiment is considering how modern digital design and creation practices, which likely inherently evolve at a faster pace than architecture due to the medium, can be applied to architecture. e.g., What might an agile approach to architecture look like, over more of a waterfall approach.
AS/ Definitely can agree from experience — I was thrilled to be able to test and iterate not in a simulacrum, but for real — not usually available for things at the scale and expense of a building. Would also add that the opportunities for impact on people via tech products is significantly bigger in scale…my first job, designing a personalized news aggregator for MySpace, got me to switch into tech when my friend Dan asked me if I wanted to work on a product with 100M users ;)
GC/ This differences of “time” and permanence is so striking that I wonder if both architecture and technology should both be using the notion of design; seems very misleading, and provides missed expectations. As all of you have noted, architects have one shot to get it right — generally without a prototype and limited to modeling — so most of us adopt an ethic of under promise and over deliver. We don’t “release” the design until we are fairly confident with the probable outcome since it will live on. A recent experience I had with a V.C. funded technology group insisted that the technology need not be “ready” but that it should be rolled out faster and constantly fixed in subsequent versions. Clearly two different approaches to what each was calling design.
GC/ Perhaps the closest approach to acknowledging impermanence was articulated by Stewart Brand who said that:
- a building shell should be designed in the best possible manner to last in a community for 80–100 years
- the systems of the building should probably obsolesce in 15–20 years
- and the internal spaces of the building that relate to people should obsolesce in 1–3 years.
GC/ Makes me wonder if either architects or the tech industry needs to redefine the notion of “design.”
AS/ I like Stewart brand’s breakdown! There are definitely analogies in the tech world where certain components are long, medium, and short term investments (bets might also be a good term). Certainly the definition of “good enough” will vary significantly based on what they’re trying to do. For example, the MVP version of a game might require all those sound effects and animations because they’re part of the rewards psychology that makes a game function. The MVP of an ER triage app might not need that. A product architect might be someone who determines what is required for the user experience to be complete and launch-worthy. In tech, this responsibility is usually held by the product manager — I’d argue that a certain kind of designer can do this better.
Johnnie Manzari JMz/: In 1998, I was introduced to Terry Winograd’s (head of HCI at Stanford) book “Bringing Design to Software” (1995). He used this architect analogy, calling for the creation of a new profession in the software industry, with one foot in engineering and the other foot in liberal arts. It was like a light bulb turned on above my head. I knew this was what I wanted to do. I’ll see if I can find the relevant paragraph. I can’t believe the book is now 20 years old. It’s timeless. (edited) Here is that passage about architecture from Bringing Design to Software. It was written by Mitch Kapor about 20 years ago (speaking of things that last for decades).
JMz/ Another parallel I see to architecture is that it was not always an established profession with processes and educational pipelines and award banquets. A thousand years ago, you basically stacked bricks or stones on top of each other and if the building started to fall over you would add a buttress and hope that would solve the problem. Software design is like that today. We just need another thousand years to improve.
FINDING YOUR WAY
AS/ Professionally, architecture, being complex in nature, continues to mature through a guild system. You apprentice at a firm and gradually work your way up to being a senior IC or a partner in your own firm. To truly call yourself an “architect”, you need to earn and maintain a license — you get one through proof of hours spent on defined types of work and by passing a series of rigorous exams. There are also many types of other certifications that offer proof of skills and experience in those areas. To be an architect is something very well defined. This is very different from design in tech, which seems to have a relatively low barrier to entry.
Tim McCoy TM/ Years ago when I made the transition from “web designer/developer” to research-driven software interaction design consultant, I had the great fortune of working in a system at Cooper where new hires apprenticed through an entire first project under the mentorship of a senior designer. The company was small, and the field of interaction design was young enough that there were few formal training programs or accredited degrees.
TM/ Today, the demand for designers pressures us to put them on the front lines sooner. We demand more experience and polish on the way in, hoping for plug-and-play. It’s also a stress on an organization if you can only grow as organically as you can have current people train new ones.
TM/ These days I’m at Pivotal, and we put a lot of effort into professional development, but it’s more peer-to-peer than mentor-apprentice.
TM/ My evolution from front end developer to user-centered designer was aided by being in organizations early in my career that valued design as UX, not just presentation. The mindset of the designers I worked with rubbed off on me and I started hanging around them any chance I got. It was a gradual process that wove through an agency, a Y2K-era startup, and two stints as an independent contractor.
TM/ But it wasn’t until I got more formal mentorship at Cooper that I really made the full transition and considered myself “a designer.” I think it was the feeling that I wasn’t just figuring it out (making it up?) as I went along; rather, someone with experience was actively training me and critiquing my work. There was probably as much validation and confidence building as there was technical learning.
TM/ Cooper also taught me a host of collaborative pairing techniques, which, like pair programming, enable extremely fast feedback loops to accelerate learning. I find the design pairing we do at Pivotal has helped our folks mature much more quickly than if they were working solo. I can’t recommend it enough.
AS/ Interesting contrast with architecture is that the fundamental materials of building haven’t changed all that much, whereas I’d be very surprised if the design “materials” of tech are the same 10 years from now. If the materials are always changing, what’s the continuum? Likewise the need for shelter has always been there; tech seems to support an incredible breadth of needs/desires, perhaps including shelter as we move into IOT. Is there a fundamental need that is common to all tech?
AS/ Also wanted to share an offline conversation I had this morning…I posed the architecture has thousands of years of development vs. decades with tech to another friend in product design with an architecture background. His retort? “Maybe architecture should move a little faster.” While the guild system at its best provides powerful personal and professional mentorship, that’s for the people who are lucky enough to work with great people — not everyone is committed to developing you. Not to say that designers in tech don’t work crazy hours, but there is a holistic approach to sustaining your creativity, mind, and body that doesn’t seem to exist in architecture culture at large.
GC/ For better or worse, I think Architecture has a 150 year lead on the tech design profession. Guess what… it still isn’t perfect and we continue to tweek each of the steps (education, internship, licensure and practice). Architects believe strongly in the importance of evidence in some level of competence since we have an obligation for life safety and welfare. As a result the demand for licensure both defines who can perform what tasks and inadvertently limits, by stereotype, what an architect is permitted to do.
THANK YOU TO ANGEL AND GORDON!
FYI John Maeda and Jackie Xu are pleased to let you know that the #DesignInTech Report (launched in March 2015 at SXSW) is now available in English, Spanish, Chinese, and Japanese.
