Designing and Shipping Features Quickly

Aeb22e809b34e9c8a5623ba6c4738a63?s=47 Ben Bleikamp
February 27, 2012

Designing and Shipping Features Quickly

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

Aeb22e809b34e9c8a5623ba6c4738a63?s=128

Ben Bleikamp

February 27, 2012
Tweet

Transcript

  1. 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.
  2. 2.

    Me.

  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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?
  10. 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.
  11. 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.
  12. 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.
  13. 21.

    A really early mock up for a header. * 15

    minutes * No one said “Redesign the header.” * Random idea turned into a big improvement.
  14. 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.
  15. 23.

    Dribbble is meant for pixel perfect designs. Your chat room

    with co-workers is not. Show work early, show work often.
  16. 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.
  17. 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.
  18. 27.

    #nav { font: bold 16px Helvetica, Arial; … li {

    float: left; display: block; } li ul { … } } nav.scss Typical CSS for a dropdown menu.
  19. 28.

    // A basic menu with optional dropdowns // // ul#nav

    - Container for the nav // li - Top level item // li ul - Optional dropdown menu // // Example: // <ul id=”nav”> // <li><a href=”/home”>Home</a></li> // </ul> // // 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.
  20. 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?
  21. 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.
  22. 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, …
  23. 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
  24. 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: // <ul id=”nav”> // <li><a href=”/home”>Home</a></li> // </ul> // // Styleguide Section 2.4 KSS: Knyle Style Sheets Used at GitHub to build own styleguide automatically from CSS documentation
  25. 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 :)
  26. 39.

    1 2 3 No design is a single state or

    step. We are designing complicated, interactive user flows with lots of states.
  27. 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.
  28. 44.

    `/deploy github to the cloud` Hubot is our butler. He

    does everything. Including deploys.
  29. 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.
  30. 50.

    Anything that makes building things harder is toxic. Anything that

    makes deploying, fixing, or trying new things harder is toxic.
  31. 51.

    Design is every decision you make about your product. This

    is a good quote. But I’d add a little bit to it.
  32. 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.
  33. 53.

    Thanks! Thanks! I will put all of this online at

    bleikamp.com/talks and on SpeakerDeck!