↵

Airbnb - "Don’t Go There. Live There."(airbnb.com)

7 years ago from Jeff Hilnbrand, Design Manager at Scale AI

  • Karri SaarinenKarri Saarinen, 7 years ago

    Great question!

    We have one design system, basically a set of shared principles, patterns and component library. This component library, is basically one sketch file, documenting every single component we have, these are like headers, navigation units, rows, listing cards. All of these are named and defined the same way in the Sketch files, and in iOS / Android code.

    Basically now, a designer can drag & drop different components to their design, tell the engineering that the design is using X, Y, Z components. They will know what those are, and can just drop them in without any redlining or specs.

    These components also defined states, they can adapt to different sized phones and tablets. As a designer and engineer, you get a lot for free by using the system and the components.

    11 points
    • Jay WycheJay Wyche, 7 years ago

      This sounds pretty interesting. I would love to see write up if you guys ever decide to talk a bit more about your process.

      2 points
    • Matthew DeutschMatthew Deutsch, 7 years ago

      I would also love to see a write up of this design->engineering process!

      1 point
    • Nicola RushtonNicola Rushton, 7 years ago

      How do you keep them both up to date? What's the process if you need to update an element?

      1 point
      • Karri SaarinenKarri Saarinen, 7 years ago (edited 7 years ago )

        With larger initiatives, we usually meet with the teams early on to help them use the system. After that if they feel like they need something more or change something, we ask them to submit a proposal on changes and a reasoning why they cannot use the existing components. When we feel like the proposal is good, follows the system and our standards, we officially include in to the component library.

        We use git/github currently to facilitate the actual file updating process. We make the design changes to the Sketch file, create new branch, and submit a pull request with a changelog that document the changes.

        We also have a script (just cmdline sketchtool) that exports all the component artboards as PNG's that are also added with the new design files. That way you can see which artboards/components have changed, and can use the github image tools to compare them to the previous version.

        After the pull request is merged to the master branch, everyone will have access to the new design files through their Sketch Templates.

        1 point
        • Michael Nino EvensenMichael Nino Evensen, 7 years ago

          This is one great example of a modern design process. In few years time engineering and design won't be two different tools / languages (Sketch, Swift/Obj-C and Java), but rather just one shared component library being adopted to different platforms with layout rules, contraints, colors, typography and states as the base of it. I'm curious, how did you as as designer feel about working within these very rigorous design constraints? And when presented to new designers what was their take on it? As a designer, I felt after working with Android and Google Material Design that given the very rigorous guidelines that it almost became "non-design" and what I was just basically doing was referencing elements and components in the Guidelines to the engineers.

          1 point
        • Matt Anderson, 7 years ago

          Would love to see a write up for this! Definitely something we've bee struggling with at my work.

          0 points
    • Richard Gazdik, 7 years ago

      This whole thing sounds pretty great. What do you mean by adapting components? Do you use the Fluid plugin in Sketch or you use something else? Do your adapting components only exist on iOS and Android? The biggest headache in our team right now is how to make reusable responsive components which could be used to build protos and test our quick mockups. I'm really curious about your approach and workflow...

      0 points
      • Karri SaarinenKarri Saarinen, 7 years ago

        I actually started with the Fluid plugin, but found bit too finicky do it for the whole app / component library. Also the plugin kept breaking after every Sketch update. It could be fine for prototyping.

        So in the end, we just documented rules per size class (phone and tablet). Something like a listing card, is defined by device width minus the paddings ($width = 100% - (24+24). The height just comes from the photo aspect ratio ($width/1.5) + paddings + text details.

        On tablet, the rules are pretty much the same, but instead always fitting one card per screen, it now fits 2, the the cards adapt from portrait to landscape to always fit two cards + paddings.

        Generally we use aspect ratios and min/max-heights to define many of the components. These components behave the same in iOS & Android.

        Overall I just had to manually try the components in different sizes and test if the rules work. Now since the components are built, I can actually run them in the native simulators but before that I imagined a web tool could have been helpful for this.

        0 points