Design Driven takes Airbnb, Google Ventures and Equinox to the UN

NEW YORK — Last July 12, Design Driven NYC made history when it held its meetup at the United Nations. Because of the security measure at the revered venue, it took some time for attendees to get inside but once everyone took their seats in one amphitheater–with hundreds of microphones for each attendee to use–the venue took on a halo of significance.

“I loved being in the giant UN conference room with the microphones and earpieces. It felt very much like a Soviet Era secret government gathering!” attendee Maria Stegner said.

Just as awed by the venue were Amber Cartwright, design manager at Airbnb;  Verena Haller, SVP of design at Equinox Hotels and Braden Kowitz, design partner at Google Ventures: Design Culture – Creating Workplaces Where Design Can Thrive.

Jeffrey Zeldman and Jen Simmons also talked about the Past, Present, and Future of Web & Interaction Design. Zeldman has been recognized as the king of web standards, while Simmons is a designer advocate at Mozilla and host of “The Web Ahead”.

Cartwright talked about her work at Airbnb and how she “works with machines (machine learning).“In tapping machine learning for a new pricing tool we wanted to build for our hosts, she and her team worked on a model that would answer the question, ‘What will the booked price of a listing be on any given day in the future’?”

Cartwright then showed a Smart Pricing regression model which explained the model made up of three parts.

Cartwright emphasized the importance of working with a team that consisted of a design manager (herself), product lead, data scientist lead, engineering manager and financial manager. “We collectively made decisions with each other’s disciplines in mind. I learned how the other worlds operate and how to leverage the expertise and capabilities of my partners to build something better.”

The work with her team takes many forms, from storyboards to prototypes, strategy decks and diagrams, which result in a shared understanding of a product vision. She believes a “shared knowledge allows innovation to happen as a step change on in micro steps. Visualizing the roles that data and the machine play in the discovery process is the first part of Invisible Design.”

Cartwright talks at length about Invisible Design in her piece on Medium. “I’m continuing to work with my teams to build data visualizations that tell stories along with the interfaces our users interact with. These visualizations tend to vary as much as the products we’re creating, but the outcome is always that they help to motivate, inspire and educate the broader product team.”

“After understanding what we’re designing and how it works, we can start building the product with a variety of tools. A carpenter has a hammer. A photographer, a camera. A product designer, sketch. A software engineer, code. What’s interesting about all of the examples above is only one of them has a tool with the ability to learn, change and grow over time.

“Most product designers today sculpt UI with reactive tools–shapes and pixels are drawn on screen input directly from a designer. We also use these tools for designing outputs that are controlled programmatically in systems like responsive platforms and components. Our data partners in product are adept with tools that evolve over time. Physical systems, economic models and algorithms organically grow as variables shape their outcomes.”

As a result, they have created a new Design Language System (DLS) at Airbnb.

Can machines do design? “No, because we are the arbiters of interpretation,” she said. “Machines are good with constraints but not with images ratios, brand, style and legibility, but our (DLS), we have an intelligent framework for creative expression.”.

Google Ventures’  Kowitz came from Silicon Valley to talk about creating workplaces where design can thrive. He showed an old video about “group norms.” In the video, a man facing the elevator turns his back when people coming in did the unconventional by facing the back of the elevator as everyone did.

He talked about setting 3 cultural values in an organization:

  1. Have faith in quality, even if it can’t be measured. Create a process around critiquing.
  2. Hold designers accountable. Designers go through this process in understanding design based on surface value, user value and  business value, the latter being what designers should focus on.
  3. Design is everyone’s job. Borrowing a quote, he said an employee should be exposed to customers for two hours..He added the importance of how an employee would need to write down a critique before every meeting

Haller of Equinox talked about how the fitness company is building a hotel that is rising on Hudson Yards. “We want people to maximize their potential,” adding how they are doing a “slightly hedonistic take on elevation.”

Airbnb envisions a better web experience with Rendr

By Dennis Clemente

Last July 2, the Cleanweb group at NYU-Poly in DUMBO, Brooklyn hosted a special talk with Spike Brehm, front-end engineer of Airbnb who flew in from San Francisco. The topic was Airbnb’s passion project–an open-source project called Rendr that it thinks will help make for a better web experience.

Presented by Brehm four months ago in the West Coast, Rendr now has some curious developers testing its library of running Backbone.js apps on both the client and the server sides.

What is Rendr? Under the hood it is JavaScript MVC on client & server; Backbone & Handlebars, Base View, Base Model, Base Collection, Base App,Client Router, ServerRouter with a set of Express middleware. What’s good about it, Brehm said, is that it has minimal glue between client and server.

Imagine a better Javascript, a better SEO (search engine optimization), a better, faster web experience used by everyone from a company known more for worldwide accommodations. Initially, the focus was on improving SEO, but it turns out that a new way of building web applications is much more interesting for them—and hopefully, the outcome is good for all.

Brehm clarifies that the intention is not to replace Rails, Meteor, Ember or Backbone, but to explore the problem of isomorphic Javascript applications and stimulate discussion in the community.

Here is Brehm’s simple set of design goals guiding Rendr’s development:

Write application logic agnostic to environment. Indicate what data to fetch, which template to render, which route to match, how to transform a model’s data. This logic can and should be abstracted from specific implementation details as much as possible.

Library, not a framework. In true Backbone style, Rendr strives to be a library as opposed to a framework. A small collection of base classes which can be built upon is easier to adopt and maintain than a batteries-included web framework. Solve the problem at hand without imposing unneeded structure on the application.

Minimize code like if (server) {…} else {…}.
If your application has a bunch of conditions that look like this, then it means you’re doing something wrong. It’s a sign of a leaky abstraction. Of course, sometimes it’s necessary to know which environment you’re in, but that logic should be consolidated and abstracted away as much as possible. Which leads us to…

Hide complexity in the library. There are a few really tricky problems that need to be tackled to achieve these other goals. The complexity of the solutions should be hidden in the library, keeping the application code clean, but remain accessible when it’s time to override core behaviors.

Talk to a RESTful API. Backbone is great at integrating with a RESTful API. Let’s follow that convention, keeping the data source separate from Rendr itself. It should be possible to write adapters for different data sources, such as Mongo, CouchDB, Postgres, or Riak, but the library shouldn’t impose structure on your model layer.

No server-side DOM. We prefer string-based templating over using a DOM on the server because DOM implementations are slow, and, well, because it feels hacky. You shouldn’t need a DOM to render HTML. However, I’m curious how this will change though once WebComponents become commonplace.

Simple Express middleware. Express is the de facto Node.js web server. Rendr should fit with Express convention, exposing a few simple middleware. A nice effect of this is that you can tack on Rendr routes onto any existing Express app, or have Rendr and non-Rendr content served from the same codebase as necessary.

With Rendr, it is hoped that developers could just concentrate on writing application code and the app could serve up genuine HTML on first pageload, resulting in an improved SEO.

Find out more about Rendr at