The 1916 Zoning Resolution
Architecturally, what is striking about the 1916 legislation is that it sought to articulate a logical formula for achieving a public good in the absence of a specific vision of exactly what would actually be produced.
Architecturally, what is striking about the 1916 legislation is that it sought to articulate a logical formula for achieving a public good in the absence of a specific vision of exactly what would actually be produced.
Work uses suggest another bugaboo: reeking smokestacks and flying ash. Of course reeking smokestacks and flying ash are harmful, but it does not follow that intensive city manufacturing (most of which produces no such nasty by-products) or other work uses must be segregated from dwellings. Indeed, the notion that reek or fumes are to be combated by zoning and land-sorting classifications at all is ridiculous. The air doesn’t know about zoning boundaries. Regulations specifically aimed at the smoke or the reek itself are to the point.
Local Code was Sorkin’s attempt to design a whole city from scratch—with one big twist. The whole thing had been written as if it were the byzantine, nearly impossible to follow codes and regulations for an entire, hypothetical metropolis. The effect is like stumbling upon the source code for SimCity. Sorkin’s exhaustively made point was that, if you know everything about a given metropolis, from its plumbing standards to its parking requirements, its sewer capacity to the borders of its school districts, then you could more or less accurately imagine the future form of that city from the ground up.
Since we launched FigJam back in April, teams having been using it to grow all kinds of ideas into great designs. We recently caught up with Figma's VP of Product, Yuhki Yamashita, to hear what it was like to build FigJam and how things have changed since then. Here, he reflects on the evolving role of design and product management, what it means to welcome “non-designers” into the process, and the future of FigJam.
When we’re thinking about where to take our product next, we actually take a lot of inspiration from our customers and the Figma Community, to see how they’re stretching our product in interesting or unexpected ways. We saw this happening in the early days of the pandemic. Our users were starting to use Figma for everything from brainstorming ideas to running team warm-up activities, to even putting on social events for people to get to know each other. We saw a lot of use cases that got us thinking.
The boundary between engineering, design, and product management is blurring. Some of us used to have a mental model in which roles and responsibilities dictated how things work—that designers do one thing and engineers do another, for example. Increasingly, more people are crossing team lines to problem solve together...Now, it’s not about who “owns” what—it’s more of a collective endeavor. And the roles have become more interlocked, and I think that’s fundamentally a good thing.
Design is non-linear. At Figma, we often talk about “embracing the mess,” and that really means leaning into the chaos and complexity that makes the design process what it is. Even once you have the seedling of an idea, you need to explore and iterate, then pull back and evaluate to see what’s working and what’s not. Sometimes you’ll scrap an idea after a brainstorm session, and other times you’ll get pretty far with a concept, but still need different perspectives and input to move forward.