Hey Matt and thanks! To answer your questions:

How was this approach to design pitched and subsequently received by stakeholders?

I can’t answer this fully, since I wasn’t part of all the discussions. Overall the company understood that we needed start this work sooner than later and native was the place to start it.

Was creating Airbnb's design system a complete overhaul? -- or injected into a current state of the UI and slowly brought along?

We both approached this bot as design and redesign project. Partly we changed the views and flows drastically and added new features that product teams were already planning to build. This meant that some major flows (home —> search -> booking a listing) were largely re-though, where as some other parts, like messaging followed the previous patterns, and just got update in the style.

Were there any noteworthy hurdles in setting up the teams to work this way? (design+engineering+management alike)

There was definitely lot of coordination we had to do getting everyone using the system. The core team, who designed and built the system, was largely aligned and we could make lot of progress. However, when the started sharing and including more teams to the system and building it, we started to see that communication and documentation came to much more important. This created some confusion that could have avoided with better documentation and communication.

I wrote blog post about this process, which just got published today http://airbnb.design/building-a-visual-language/

Steven,

I joined the Airbnb in October last year when the Design System project got started. Initially, I worked together with the team defining the basic style guide, like type, spacing, colors. After that, we worked closely together for a month of creating the new designs and defining the components.

Currently how the contributions work is that we work with teams that want to add something. We also ask them to submit a proposal on changes and a reasoning why they cannot use the existing components. We try to decide on how important is the use case and how universal the solution is. The best case is that the use case is very important, and solution is very universal (can be used in lot widely). When we find the request is sufficient, follows the system and our standards, we officially included into the component library.

We use git/github currently to facilitate the actual file updating process. We add the new components to our Sketch Library, work with the engineering to make sure we didn't miss something and submit a pull request with a changelog that document the changes.

We also Sketch templates that automatically update when update the design library, so all the designers have the access the the new files immediately.

Hey Jake :)

We generally want people to feel at home in unique places and meet local people when they travel. Personally, I think messaging plays a huge role in this since before you are actually at the place, you will connect with the host. I think there is a lot of opportunity for AI to help make these conversations more efficient but lot of Airbnb is about the human element in these relationships.

Hi Stephen,

I think it’s definitely a challenge to try to build the system at the same time as product work is happening. In our case, we kind of tried to minimize it by doing and releasing the system in a short timescale (months).

However, I think is entirely possible and overall easier approach to just build the system over time, and understand that there will be an transition period, where certain things are in the system, and some are not. If you can just get all the new experiences created using the system, over time you should be in a good spot.

If I would design a new product own my own, would a build a design system first? This is actually a question I’ve been thinking about as well. In a way it’s like a chicken and egg problem. It’s hard to create system if you don’t know what you’re building, and it’s hard to define the system after you have already build a lot.

After design and building several products, I do now see value of defining a simple system early on. Just even to restrict yourself. I’ve personally spend countless of hours of tweaking margins, types and color, trying to come up the best possible view for an app I can for an app. While do think craft and pixel perfection is important, in the end it won’t usually make or break your company. The wholistic experience and the value you can create to your users always trumps the pixels.

Most likely I’d try take some hybrid approach. Once I would have general idea of the style and structure of the app, I’d start defining basic things like spacings, type sizes, colors. Are there certain patterns and parts that could be re-used? Name them and define them. Rinse and repeat and try to stick to the system you created, so you can use your time for thinking about other things.

Hey Szymon,

I'm great, thanks!

airbnb it is a big community - definitly - and all design details are super important. How many tests you made before launched current version of website/app? (in meaning of A-B testing) Or maybe you always try to check something new and you testing all the time? Could you tell something about testing while working on that big project with that huge base of users like airbnb?

I don’t have an exact number, but we definitely tested a lot, almost on weekly basis. We have excellent researches that come great plans, and summarize what the results mean. We often test with users onsite, and we can also run experiments on our apps. Generally we always still try to think what we want to design or improve. Testing or research, is always tool we can use, but cannot provide us all the answers.

I have an idea for app - but I think it's could be useful to make mobile app and website - responsive of course. What do you think - it there sens to make two almost the same projects - one for web and one for mobile app? Is there any extra super profits in that case? We got 2016 - what I should design first? App + simple website or maybe website and next try to design app with no rush?

I think it depends at lot on your app and your resources. Often websites are a great way to test the interest in general. You can come up with a simple launch page, that describes the product, and asks to people to sign up for beta. That way you can see if there is any interest on what you are building. This kind of testing is much harder or often impossible to do on mobile platforms.

If you have the skills or resources, designing and building an app can work well too, but it can be more risky path.

What is important when you work with that big base of users like airbnb (except UI/UX)? Maybe do you have some protips for designers - how to reach out for users or how to keep them close? I mean something like "oooh, always try to put little kitty everywhere" ;)

I think one thing we try to keep in mind that Airbnb is used in many countries, by young and old, and with varying levels of technical skills. We make the product accessible to all of these people.

Another thing we do is to try to be more human. We have great content folks, that help us create clear and friendly messaging. Simple things like instead of saying “Rate your trip” we ask “How was your trip?”

Related to this system we created, we have seen it to increase collaboration. Designers, engineers and product people have a common language they. Also we have seen that designers are more eager to share and adopt solutions from other designers than before. I think it has shifted our thinking more towards boiling a system and experience together and away from individual projects.

I always think that physical proximity helps too. Also giving opportunities to people learn from each other. Ask engineers to to design meetings. Encourage designers to learn about engineering. More we can emphasize and learn each others viewpoints the more I think we can work together and come up great solutions.

Hi Kieran,

There is definitely more understanding what is design and how it works that many other companies. I think this mainly since the 2 of the 3 founders are designers by training.

I’d also agree that Airbnb is much more design driven organization. Design and exploration, is almost always considered the first step, and ongoing process, in any project we do. It’s not an after-though. We also pair the design with research, so we make informed decisions before we start building things.

Design thinking, appreciation for craft, and storytelling is something that visible in our marketing, operations and even the keynotes we do. I think the office design has been also a way to communicate the design mindset. They really want make it feel a good place to work and collaborate.

Hi Tuomas :)

And thanks, I'm definitely still learning how to give feedback to people.

As being designer myself and getting this feedback, I try to think what I’d want in that position and what would be useful.

1. If the designer doesn’t say, always ask first what kind feedback they want. Everything that comes to your mind might not be useful at that time. Feedback should be different in the beginning of the process (more conceptual) and trying to restrain giving very detailed feedback at the very end (something like fixing a margin).

2. I try to consider the skill level and personality of the designer. Some people like very direct feedback, some people don’t. Some people need more context and reasoning, some people get bored by it. When I give feedback to more junior designers, and try to give the feedback that they can use and improve on.

3. I also try to avoid giving direct solutions or prescribing how would I do it, but more framing them as questions “Have you considered doing it like this?”.

Hey Samo :)

The product teams generally do a lot of testing and user research, and from there had synthesized some basic lessons and our problems areas that we should avoid and possibly fix.

Since this project was more sweeping design, we had to make some large assumptions towards on the direction and designs. However, while we worked on it, our research teams had and tested the prototypes actual users. We would get this new data and learnings every week, and could fix and adjust the direction if necessarily. Luckily, lot of our initial assumptions ended up correct, and we didn’t find too many surprises from the research.

Hey Cody,

Did you use some sort of base (or golden) unit, cascading across all components? I'll assume you did:

We wanted to base our designs on 8 and 4 point grid (4 is mostly only used for our icons). However, we ended using 24pt a lot. Basically that was the unit we decided for our side gutters, and that way it ended up, being the normal spacing.

Tell me more about them! How did you use them?

How'd they influence typography?

The grid 8, and the 24 spacing, generally affected our type styles. I think spacing often goes with the typography. What we also knew that bounding boxes, basically the amount of space the type takes on native devices is generally the line-height. So we made sure that the line-heights would align with our grid, and our text size would work on those line-heights.

We're these units relative to the device size/breakpoint Pixels? Ems? Rems?

For native we are defining everything in 1x, in points. Basically currently our standard screen size is the iPhone 6 (375x667). The component width and positioning is related to the screen size with, but currently we are not scaling the components based on the screen size. Often the component is defined as relative to the screen size, but with fixed spacing and text sizes. For example a listing card on mobile, is always width: 100% - 48 (gutters), so in that way we always fit one full card on any screen. On tablet the rule changes to use 2 columns, so the size ends up being a width: 50% - 128 (gutters) - 24 (space between)

how did you handle sharing the style guide (not online but psd or sketch file) so others can do their work

I described this in another comment, but we use Git to facilitate the process of updating the files. After that we put the updated design component library in to a shared Box folder, which is available to everyone through the Sketch Templates. When ever designer wants the new updated library, they can just go to their chose Templates > DLS > DLS Phone.

We are also working on a documentation site, that would house our general style guide, as well as have screenshots of the components and have motion examples.

is Airbnb built on a component based framework as well?

Yes, for this new launch of our mobile apps and the design system, we build it to be component based. I describe the system a bit more here: http://airbnb.design/building-a-visual-language/

Thanks Santi!

Hi Bertrand!

I’ve been often thinking about writing about what happened with Kippt. People often still also contact me about it, when they are building something similar, which seems that this is an unsolved problem!

You’re right on the main cause. Like any other startup and company, we relied on growth and revenue, and just could find a way to hit the goals we had set. We had a great community, with lot of people actively using it, but didn’t achieve the scale we hoped to create. Basically run out of time.

Lessons learned in there, lead us to start considering Inc, basically a Kippt for companies, since we knew many teams and companies were already using Kippt. We decided go different route, developing the product with few companies, only focusing on our paying customers. That actually worked better than we hoped and we got great customers that way. Afterwards, we still decided to move on and got acquired by Coinbase.

Shutting down Kippt was definitely hard, but after Inc, and now with our new jobs, we just didn't have the time or energy to keep Kippt running in good shape. Rather than letting it limb along, we decided to end that chapter and hope someone could pick up where we left.