Designing and Shipping Features Quickly

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

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.
2. Me.
3. Ben Bleikamp.
4. Find me on the internet.
5. Designer at GitHub, live in San Francisco, trying to make the Internet more awesome.
6. FAST, GOOD, CHEAP PICK TWO. Traditional engineering project triangle—pick two of these three.
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.
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.
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.
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.
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.
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.
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?
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.
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.
16. Get responsive layouts much faster, too.
17. HD Everything™. GitHub at ~5x zoom looks nice, still.
18. SHOW YOUR FIRST DRAFT
19. A story about Pixar.
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.
21. A really early mock up for a header. * 15 minutes * No one said “Redesign the header.” * Random idea turned into a big improvement.
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.
23. Dribbble is meant for pixel perfect designs. Your chat room with co-workers is not. Show work early, show work often.
24. ?! Show a design as soon as it can provoke a question.
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.
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.
27. #nav { font: bold 16px Helvetica, Arial; … li { float: left; display: block; } li ul { … } } nav.scss Typical CSS for a dropdown menu.
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.
29. But I hate reading code. Reading code sucks.
30. Solution: A Style Guide! A style guide sucks less.
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?
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.
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, …
34. (And we’re lazy.)
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
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
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 :)
38. USE YOUR DESIGNS
39. 1 2 3 No design is a single state or step. We are designing complicated, interactive user flows with lots of states.
40. Make staff only features and ideas easy to implement.
41. <% if preview_features? %> …stupid design idea… <% end %> _new_layout.html.erb Simple.
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.
43. LET ANYONE DEPLOY Designers can deploy, too.
44. `/deploy github to the cloud` Hubot is our butler. He does everything. Including deploys.
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.
46. DO NOT BREAK THE BUILD The one rule.
47. Doesn’t shit break, anyway? Rollbacks are simple!
48. `/deploy github/branch to the cloud`
49. Okay, the point: What’s the point here?
50. Anything that makes building things harder is toxic. Anything that makes deploying, fixing, or trying new things harder is toxic.
51. Design is every decision you make about your product. This is a good quote. But I’d add a little bit to it.
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.
53. Thanks! Thanks! I will put all of this online at bleikamp.com/talks and on SpeakerDeck!