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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
(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.
// 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.
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?
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, …
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
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
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 :)
“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.
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.
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.
bleikamp
akiramotomura
spindle
root_recruit
aguringo
onf
ikuhotamura
garyuten
uxaustralia
mct
transit_kix
jouykw
dougneiner
3n
philhawksworth
bermonpainter
lara
chrisshort
bryan
cromwellryan
tmm1
brettharned
jcasabona
soudai