$30 off During Our Annual Pro Sale. View Details »

Designing and Shipping Features Quickly

Ben Bleikamp
February 27, 2012

Designing and Shipping Features Quickly

A talk about how GitHub designers design, build, and ship designs Pretty Quickly™

Ben Bleikamp

February 27, 2012
Tweet

More Decks by Ben Bleikamp

Other Decks in Design

Transcript

  1. DESIGNING AND SHIPPING FEATURES
    REALLY REALLY QUICKLY
    Today I am going to talk a little bit about how designers and developers are GitHub work
    together to ship features.

    View Slide

  2. Me.

    View Slide

  3. Ben Bleikamp.

    View Slide

  4. Find me on the internet.

    View Slide

  5. Designer at GitHub, live in San Francisco, trying to make the Internet more awesome.

    View Slide

  6. FAST, GOOD, CHEAP
    PICK TWO.
    Traditional engineering project triangle—pick two of these three.

    View Slide

  7. FAST, PRETTY, CONSISTENT
    PICK TWO.
    When I think about what designers are often forced to choose between I think of these three
    things.
    We shouldn’t have to choose, though.

    View Slide

  8. CHOOSING
    SUCKS
    FAST PRETTY
    CONSISTENT
    I don’t like to choose. I think you should be able to do all 3.
    We don’t need to be perfect, but we can do a pretty good job on all 3 of these things.

    View Slide

  9. 1. Skip Photoshop
    2. Show first drafts
    3. Document Designs
    4. Use your product
    5. Deploy Constantly
    These aren’t revolutionary ideas.
    For some reason people make excuses as to why they aren’t shipping faster. Doing these
    things would help, but a lot of companies don’t do them.

    View Slide

  10. SKIP PHOTOSHOP
    (It’s annoying to use, anyway)
    * Popular idea right now. Quora designers talk about this a lot.
    * Photoshop is tedious, even for an expert. It’s not built for UI design.

    View Slide

  11. HIRE DESIGNERS WHO CAN CODE
    * Designers should be expected to code.
    * “Familiarity” with a programming language is a really low bar to set. Demand that they
    implement their features.

    View Slide

  12. Settings Next in Photoshop
    * This example is a bit extreme, but this was my first (and only) Photoshop mock up of a
    settings redesign
    * Goal was to make editing user and organization settings easier.
    * General idea: Accordion menu, some stuff on the right, context switching.

    View Slide

  13. Settings Next in Production
    * Settings Next in production
    * Most of this was done in browser, a lot of it was done on production in Staff Only mode.
    * Real content, real navigation, real interaction. Were the Pjax transitions slow? Is it clear
    which page I’m on?

    View Slide

  14. Settings Next in Production
    Things like this are hard in Photoshop
    This is what Photoshop sucks at.
    * 3 or 4 layer shapes, lots of layer effects
    * I hope I don’t need the bottom border color to be different than the other sides.
    * Terrible text rendering
    * It’s not realistic.
    Photoshop is good for moving boxes in the early stages of a design.

    View Slide

  15. What about iOS and native apps?
    If you’re designing for a platform you should understand the code for that platform. Simple.
    * Native apps are harder to write code for. So what? Understand your medium.
    * Read a basic book, implement a basic button. Do something to understand how your design
    will be implemented.
    No one was born to code vs. not born to code. Learning to code is frustrating. It doesn’t
    mean you can’t do it.

    View Slide

  16. Get responsive layouts much faster, too.

    View Slide

  17. HD Everything™.
    GitHub at ~5x zoom looks nice, still.

    View Slide

  18. SHOW YOUR FIRST DRAFT

    View Slide

  19. A story about Pixar.

    View Slide

  20. In the process of making the film, we reviewed the
    material every day. Now this is counter-intuitive for a lot
    of people. Most people—imagine this: you can’t draw
    very well, but even if you can draw very well, suppose
    you come in and you’ve got to put together animation or
    drawings and show it to a world-class, famous animator.
    Well, you don’t want to show something that is weak,
    or poor, so you want to hold off until you get it right.
    And the trick is to actually stop that behavior.
    Ed Catmull
    The last few lines are what’s important.
    found via Ryan Singer’s blog, he’s a designer at 37s.

    View Slide

  21. A really early mock up for a header.
    * 15 minutes
    * No one said “Redesign the header.”
    * Random idea turned into a big improvement.

    View Slide

  22. The header that shipped.
    * I didn’t like this header, it was another “idea” that I figured we’d throw out.
    * People said, “That’s pretty cool.”
    * We tried it on production, we liked it.

    View Slide

  23. Dribbble is meant for pixel perfect designs.
    Your chat room with co-workers is not.
    Show work early, show work often.

    View Slide

  24. ?!
    Show a design as soon as it can provoke a question.

    View Slide

  25. (But polish is good)
    Once you have a great experience, it’s okay to perfect it and worry about pixels.
    Shipping should be your priority. Don’t hold a feature back because of a 2px vs 3px border
    radius. Release it.
    We can iterate quickly on the web. We’re not Apple trying to release the perfect piece of
    hardware on a global scale.

    View Slide

  26. DOCUMENT DESIGN
    I am not talking about PDF design.
    I am talking about documenting things related to your designs, e.g. CSS, markup, etc.

    View Slide

  27. #nav {
    font: bold 16px Helvetica, Arial;

    li {
    float: left;
    display: block;
    }
    li ul {

    }
    }
    nav.scss
    Typical CSS for a dropdown menu.

    View Slide

  28. // A basic menu with optional dropdowns
    //
    // ul#nav - Container for the nav
    // li - Top level item
    // li ul - Optional dropdown menu
    //
    // Example:
    //
    // Home
    //
    //
    // Styleguide Section 2.4
    nav.scss
    Comment your CSS as if it were a first class language.
    Example mark up makes this easy to implement.

    View Slide

  29. But I hate reading code.
    Reading code sucks.

    View Slide

  30. Solution: A Style Guide!
    A style guide sucks less.

    View Slide

  31. Bootstrap
    Twitter released this framework they call Bootstrap.
    Basic CSS, JS for building out web applications.
    This has been done before. What did Bootstrap do really well?

    View Slide

  32. Bootstrap’s main selling point is that it’s beautifully documented.
    They made a great framework, but it’s styleguide makes it reusable by anyone.

    View Slide

  33. But we’re Professionals™ and build our own tools
    Not everyone wants to use Bootstrap.
    Looks similar to other sites, don’t need it all, like full control, …

    View Slide

  34. (And we’re lazy.)

    View Slide

  35. KSS
    Knyle Style Sheets
    github.com/kneath/kss
    KSS: Knyle Style Sheets
    Automatically generated styleuides!
    Used at GitHub to build own styleguide automatically from CSS documentation

    View Slide

  36. KSS parses this:
    // A basic menu with optional dropdowns
    //
    // ul#nav - Container for the nav
    // li - Top level item
    // li ul - Optional dropdown menu
    //
    // Example:
    //
    // Home
    //
    //
    // Styleguide Section 2.4
    KSS: Knyle Style Sheets
    Used at GitHub to build own styleguide automatically from CSS documentation

    View Slide

  37. Easily browsable set of UI patterns
    Don’t have to go read CSS files to implement a basic page or prototype
    Quick reference for things like buttons, links, tabs, etc.
    Maybe not as nice as Bootstrap…but I am sure Kyle will accept Pull Requests :)

    View Slide

  38. USE YOUR DESIGNS

    View Slide

  39. 1 2 3
    No design is a single state or step.
    We are designing complicated, interactive user flows with lots of states.

    View Slide

  40. Make staff only features and ideas easy to implement.

    View Slide

  41. <% if preview_features? %>
    …stupid design idea…
    <% end %>
    _new_layout.html.erb
    Simple.

    View Slide

  42. “But I work on boring stuff…”
    Working on boring stuff means you won’t create great products that people love.
    Go work on something you’re excited about.

    View Slide

  43. LET ANYONE DEPLOY
    Designers can deploy, too.

    View Slide

  44. `/deploy github to the cloud`
    Hubot is our butler. He does everything. Including deploys.

    View Slide

  45. MASTER
    BRANCH
    We use a sane branching structure, no one gets confused
    Create a new branch for your feature. Deploy feature-branch to production. Looks good?
    Merge with master, deploy, and you just shipped.

    View Slide

  46. DO NOT BREAK
    THE BUILD
    The one rule.

    View Slide

  47. Doesn’t shit break, anyway?
    Rollbacks are simple!

    View Slide

  48. `/deploy github/branch to the cloud`

    View Slide

  49. Okay, the point:
    What’s the point here?

    View Slide

  50. Anything that makes building things harder is toxic.
    Anything that makes deploying, fixing, or trying new things harder is toxic.

    View Slide

  51. Design is every decision you make about your product.
    This is a good quote. But I’d add a little bit to it.

    View Slide

  52. Design is every decision you make about your product.
    …including backend architecture and deploy strategies.
    It loses it’s elegance and simplicity, but most people don’t consider backend systems to have
    an influence on design decisions.
    * If deploying is a big commitment I am less likely to make quick fixes
    * I can deploy earlier because I know if there is a mistake I can make the fix quickly.

    View Slide

  53. Thanks!
    Thanks!
    I will put all of this online at bleikamp.com/talks and on SpeakerDeck!

    View Slide